Bug#812236: CD-Image does not boot with Libreboot/GRUB

[Dane Forner]

GOOD DAY! mr. Watson,  hope all is well with you and your family, as well
thx for reading this message. Im still unable to utilize any of the
packages etc, I tried creating a kali+Tails+nethunter for myself and
failed to build from errors regarding kernels, Iso missing when i loaded
it from my persistent volume previously downloaded. Is it possible to
submit a document involving either ROOT COMMAND LINE or allow you access
to my secure shell? Im anxious to encrypt my anonymity up to date and
ensure anyone who comes in contact with me doesnt have anything that can
snoop my end of things. I would pay you btc providing you give me a price
and were to send it. Im losing my mind trying to download and install with
result in nothing accomplished:( my system is : I386
> ey bud, im still enduring difficulty successfully downloading kali rolling
> with grub...can you possibly access my laptop in the event i allow you in
> my secur shell?
>> ok can you help me build kali 2.0 + tails 1.8.2 off same boot? ill pay
>> in
>> btc
>>> On Sat, Jan 16, 2016 at 03:36:26PM +0100, Carsten Otto wrote:
Dear Debian CD admins,

I'm an administrator of ftp.halifax.rwth-aachen.de, and your project is
mirrored by us.

Right now I'm preparing a clean list of projects and corresponding
contact addresses, so that we can get into touch with you more easily.

As there are a few upcoming changes, news, and questions from our side,
please make sure to **confirm/update your contact address(es)** used
 for
this mail, also shown below. Another mail with more actual content will
be sent around next week or so.

  debian...@lists.debian.org
>> On Sun, Jan 24, 2016 at 07:36:27PM +0100, Frank Guthausen wrote:
>>> 2) Grub's chainloading depends on BIOS/UEFI:
>>> http://www.gnu.org/software/grub/manual/grub.html
>>> | Chain-loading is only supported on PC BIOS and EFI platforms.
>>
>> I don't know that this is fundamentally true.  "Supported" is of course
>> a word that can mean various things, but there is at least an
>> implementation of the "chainloader" command for coreboot (etc.).  See
>> grub-core/loader/i386/coreboot/chainloader.c.
>>
>> --
>> Colin Watson   [cjwat...@debian.org]
>>
>>
>
>
> --
> -BEGIN PGP PUBLIC KEY BLOCK-
> Version: BCPG C# v1.6.1.0
>
> mQENBFZjW4MBCACTr1LBzLZzck+le90wBoPcgo1yfSJkDehJweAH1Hv7N0A+O9zp
> n6Bs6Ejq/5T4pyPi+mWd5svWJBMDbEZZ1hMd5P49SFhe4RjxfEtDvSmoHZkkn2zj
> E81p/Vwj3iQ1LreQFjIyPo+nRNW/bQS3Lz92D8xqXMIrl0dZjshHURRuZZbhMqww
> aBor5BLdDupUVkJnU03H7VpeB4Gp2yKLnZGiz48OHQqwtRKmwsaYvrgYIHCK8K1p
> LrzW57LIjbxzpT98FLXgi/4YSh4i2W1ctruXTwfCBlf2Wi5+MmmylcoIDpcGyn5Y
> xoEilnu3pwCxtp56XEnVpzwHKWnkwKeRN+DBABEBAAG0FWtsb2Nrd2Vya0B0dXRh
> bm90YS5kZYkBHAQQAQIABgUCVmNbgwAKCRB/x6Vzi/BduJjtB/90i8qvr3BRKwYy
> mSpiQBgwv4xhx7rb7MdNEVtRfYlAS4S5nXU6v5BydpQyzPdBxFrWY26hULQWOGwE
> ACnKRFEMDoIAq/FXYd5ina0pO/lmsTz3uauiZ28rq/HxxVLZb9qLsO6VIIppr2HN
> aSISZpK0Ny5A3Fm9Y2Ff/92kFbj6FjQytJnyYlsh4Pfb8ymFQRwEfJH6awrlIb3y
> 3KhIc836fEPyXGePD2k6C79q/o9I0ijR/rQCUv8NVOIfznakgvYeexCWt+wJFclI
> 6Qh/sgxNIhpMWuF8rSHM0NY9teaGubTUFIK4GVG+s1FJzKIOUnwPhtIRfPHNWqhh
> 9xaJDQ7s
> =IMpu
> -END PGP PUBLIC KEY BLOCK-
>
>

Bug#814183: openmpi 1.10.2 is broken on powerpc

[Graham Inggs]

On 12 February 2016 at 01:17, Emilio Pozuelo Monfort  wrote:
> On Tue, 9 Feb 2016 21:49:29 +0200 Graham Inggs  wrote:
>> Petsc rebuilt successfully [1] a couple of hours ago on poulenc.d.o. [2].
>> My previous tests were done on partch.d.o. [3].  Partch has 2GB of RAM
>> vs Poulenc's 5GB, I don't know if this is significant.
>
> aces3 failed on powerpc-osuosl-01.
>
> poulenc is a PPC970FX
> patch is a POWER7
> powerpc-osuosl-01 is a POWER8
>
> Dunno if that is relevant.

It might be, thanks!  Is there any way to arrange for aces3 to be
rebuilt on poulenc?  That should tell us something.

Bug#814492: libgnome2-wnck-perl: FTBFS: Package 'xres', required by 'libwnck-1.0', not found

[Niko Tyni]

Package: libgnome2-wnck-perl
Version: 0.16-3
Severity: serious
Tags: stretch sid
X-Debbugs-Cc: libwnck-...@packages.debian.org

This package fails to build on current sid/amd64.  It looks like
libwnck-dev recently dropped its dependency on libxres-dev, making
things like 'pkg-config --cflags libwnck-1.0' fail.

Cc'ing the libwnck maintainers. Was this intentional?

  https://reproducible.debian.net/rb-pkg/unstable/amd64/libgnome2-wnck-perl.html

 dh_auto_configure
  perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z,relro"
  Package xres was not found in the pkg-config search path.
  Perhaps you should add the directory containing `xres.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'xres', required by 'libwnck-1.0', not found
   at Makefile.PL line 46.
  *** can not find package libwnck-1.0 >= 2.20.0
  *** check that it is properly installed and available in PKG_CONFIG_PATH
   at Makefile.PL line 46.
  dh_auto_configure: perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=-g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 LD=x86_64-linux-gnu-gcc -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z,relro returned exit code 1
  debian/rules:4: recipe for target 'build' failed
  make: *** [build] Error 1
  
-- 
Niko Tyni   nt...@debian.org

Bug#814342: lowmem should not block when in network-console d-i mode

[Roger Shimizu]

On Fri, Feb 12, 2016 at 9:38 AM, Martin Michlmayr  wrote:
> * Roger Shimizu  [2016-02-11 16:28]:
>> Now it's clear, since in d-i, file
>> build/pkg-lists/netboot/network-console/armel/orion5x.cfg
>>
>> oldsys-preseed
>> # sata and ext2/ext3 modules are needed by oldsys-preseed to read the disk
>> # -> disable due to size problems
>
> That doesn't explain what you're seeing.  If oldsys-preseed cannot
> read the disk on Buffalo devices, it should still generate a preseed
> file with DHCP and a fallback IP address (as well as the lowmem
> override).
>
> Please debug why (and what) is not working for you.

Thanks for your guide!
Now I trace to the following file:
- https://anonscm.debian.org/cgit/d-i/oldsys-preseed.git/tree/oldsys-preseed

It seems I need to write a block for device tree based Linkstation.

>> I think maybe it's necessary to split "orion5x" as:
>> - orion5x with serial console support, which keeps current config, so
>> as kuroboxpro can be supported
>> - orion5x without serial console support, re-enable sata and ext4, but
>> disable jffs2 and micro-evtd
>>
>> What's your idea?
>
> "with serial console support" would be the netboot image.  So you're
> suggesting that Kurobox Pro should use the netboot image whereas other
> Buffalo devices should use network-console.

I think network-console is a special variant of netboot. And serial
console install works well on network-console image.

> I don't know if Kurobox Pro all have a serial console.  I used to have
> such a device but I cannot remember anything about it.

I owned a Kurobox Pro long time ago, but I don't have it anymore.
I now it's simply Linkstation Pro (LS-GL) + one additional NAND flash
+ external SATA interface.
For d-i, we can treat Kurobox Pro the same thing as Linkstation Pro.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#812428: libgcrypt20: please make the build reproducible (timestamps)

[Andreas Metzler]

On 2016-01-24 Daniel Kahn Gillmor  wrote:
> On Sat 2016-01-23 16:52:09 -0500, Jérémy Bobbio wrote:
>> While working on the “reproducible builds” effort [1], we have noticed
>> that libgcrypt20 could not be built reproducibly.

>> The attached patch adds support for SOURCE_DATE_EPOCH to set the value
>> of BUILD_TIMESTAMP defined in the configure script. Once applied,
>> libgcrypt20 is nearly reproducible in our current experimental
>> framework—their might be remaining timestamps in the PDF documentation.

> Thanks for fixing this, Lunar.

> fwiw, libgcrypt upstream is the same folks as libgpg-error upstream.  In
> response to concerns about reproducible builds, libgpg-error 1.20
> switched to not embedding the build timestamp at all upstream by
> default.

> Perhaps they'd be open to the same approach for libgcrypt if it were
> proposed.
[...]

Hello,

FYI this had already happened on libgcrypt master branch when this bug
was submitted, Werner has already done this.
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=a785cc3db0c4e8eb8ebbf784b833a40d2c42ec3e

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#814222: openslide 3.4.1 is out

[Andreas Tille]

Hi Benjamin,

On Thu, Feb 11, 2016 at 06:37:44PM -0500, Benjamin Gilbert wrote:
> On Thu, Feb 11, 2016 at 08:20:38AM +0100, Andreas Tille wrote:
> > If you like to sneak a bit into Debian packaging and update the files in
> > Git/SVN (just tell me your preference) I'd consider this a nice solution.
> 
> I'm willing to maintain the Debian package if necessary, but if there's a
> feasible alternative I'd like to pursue that first.  IMO it provides a
> useful sanity check on the package when upstream and downstream are
> different people.  If someone else in the OpenSlide user community would be
> willing to maintain the package, would you be open to mentoring them through
> the MoM process?

For sure any help of a person somehow connected to OpenSlide is welcome
since I expect way more sensible testing than I could provide.  I do not
mind whether this person is from developers or users side.  The
knowledge requirements are some Git/SVN skills, knowing a bit about make
and patches.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#814473: [Debichem-devel] Bug#814473: elpa: FTBFS: find: '/usr/share/libtool/config/ltmain.sh': No such file or directory

[Graham Inggs]

On 12 February 2016 at 01:20, Andreas Beckmann  wrote:
> dh_autoreconf --as-needed
> find: '/usr/share/libtool/config/ltmain.sh': No such file or directory
> dh_autoreconf: find /usr/share/libtool/config/ltmain.sh . ! -ipath 
> "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' 
> -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} \; > 
> debian/autoreconf.before returned exit code 1
> debian/rules:14: recipe for target 'override_dh_autoreconf' failed
> make[1]: *** [override_dh_autoreconf] Error 2
> make[1]: Leaving directory '/«PKGBUILDDIR»'
> debian/rules:11: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 2
>
>
> I cannot reproduce this in a sid pbuilder environment.

Looks like #814063

Bug#812309: [PKG-Openstack-devel] Bug#812309: Bug#812309: python-trollius: upgrade to version 2.0

[Thomas Goirand]

On 02/09/2016 09:42 PM, Sandro Tosi wrote:
> On Fri, Feb 5, 2016 at 2:52 PM, Thomas Goirand  wrote:
>> On 02/05/2016 05:23 PM, Sandro Tosi wrote:
 I've been working on this, and there's an issue when running unit tests
>>>
>>> i see you just pushed the changes for 2.0 (they were not there when I
>>> sent my emails/bug)
>>
>> Yes, and the version 2.1~b1 currently in the Git should work. Though I
>> still prefer to wait for upstream to release before uploading to Debian.
>> Hopefully, this will happen today. If not, I'll upload 2.1~b1.
> 
> any idea why the release has been delayed? just lack of time or some
> tech issues?

As much as I understand, what's taking so long is that upstream insists
on providing Windows wheels, for win32 and win64, and with python 2.7,
3.3 and 3.4. This means 6 builds, which all have to be done with a
different build environment.

I've been looking and waiting for this version 2.1 to be released, but
it's still not coming. As you're waiting for it, and I don't want to
make you wait forever (especially considering it will take 5 days to
migrate to Testing before you'll be able to upload to backports), I
decided not to wait, and I uploaded 2.1~b1-1 to unstable, as normally,
the final release wont be any different.

> Also, I would like to have that version in Jessie: would you like to
> take care of the backport yourself or prefer me to do it?

Feel free to maintain the backport if you like. For the packages I
maintain, the older 1.0.1 which is already in Stable is enough, so I
have no interest in maintaining a backport for a newer version. I
maintain enough packages in Debian, so it's ok to give out some.

BTW, could you let me know why you need Trollius in Jessie-backports?
The fact that upstream declared it as deprecated, and will not do any
work on it but basic maintenance (which as you saw, he's not in a hurry
to do) isn't very engaging. I would therefore recommend to be very
cautious with this package.

I hope other dependencies in OpenStack will get rid of it, but probably
we need to wait that everything switches to Python3 (in which case they
can use asyncio directly), which is going to take probably a very long
time, but that's still the plan. Then I may either orphan or ask for
this package to be RM, unless a new person becomes the upstream. I'll
care to ping you when/if this happens. You've been warned! :)

Cheers,

Thomas Goirand (zigo)

Bug#814282: ports lists unofficial ports as official

[Paul Wise]

On Wed, Feb 10, 2016 at 7:04 PM, Adam D. Barratt wrote:

> They're all currently supported as part of wheezy, until it loses security
> support later this year. I'm not sure what the criteria for being counted as
> official are in this case, however.

Probably the page needs to be automatically generated based on the
current state of the main and ports archives. The page could then be
split up into more categories to more accurately portray the level of
support each port can expect.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#814491: tracker: Ubuntu logo is huge when CSS is off

[Paul Wise]

Package: tracker.debian.org
Severity: minor
Tags: newcomer

Ubuntu logo is huge (285x285) when CSS is turned off. The page has
inline CSS restricting it to 14x14 though. Probably the image should be
resized to reduce network usage and the CSS removed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#814490: os-prober: 50lilo fails to parse append= in lilo.conf, elading to corrupted grub.cfg

[Marc Lehmann]

Package: os-prober
Version: 1.65
Severity: normal

Dear Maintainer,

update-grub on my system fails to generate a valid grub.cfg. the culprit is
/usr/lib/linux-boot-probes/mounted/50lilo, which fails to parse my lilo.conf 
file, generating entries such as:

::4.3.3:/boot/vmlinuz-4.3.3-040303-generic:/boot/initrd.img-4.3.3-040303-generic:ro
 vga = 0 append = "root=/dev/vg_cerebro/root rootfstype=ext4 rootdelay=5 
relatime elevator=cfq transparent_hugepage=always kernelcore=6G 
ip=10.0.0.1::10.0.0.5:255.255.255.240:cerebro-preboot:eth0:off pcie_aspm=force 
3w-9xxx.use_msi=0 zswap.enabled=1 zswap.compressor=lz4 syscall.x32=y 
modprobe.blacklist=nouveau,nvidiafb

the problem here is the

   append = "...

which lacks a trailing ", causing grub to barf eventually.

disabling this script with an exit 0 at the top makes update-grub run through.

I debugged a bit, and found that at some point, dequoute is called with a
full line from the lilo.conf. Specifically, my lilo.conf contains this line:

   append = "root=/dev/vg_cerebro/root rootfstype=ext4 rootdelay=5 relatime 
elevator=cfq transparent_hugepage=always kernelcore=6G 
ip=10.0.0.1::10.0.0.5:255.255.255.240:cerebro-preboot:eth0:off pcie_aspm=force 
3w-9xxx.use_msi=0 zswap.enabled=1 zswap.compressor=lz4 syscall.x32=y 
modprobe.blacklist=nouveau,nvidiafb"

which is passed to the dequote function, which removes the trailing " and
nothing else, ultimately leading to the failure as this ends up directly
in grub.cfg.

I have not investigated further.

Greetings,
Marc

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

Kernel: Linux 4.1.13-040113-generic (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages os-prober depends on:
ii  libc6  2.21-7

os-prober recommends no packages.

os-prober suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/linux-boot-probes/mounted/50lilo (from os-prober 
package)

Bug#814489: tails-installer: fails with "Could not find the 'ifcpu64.c32' COM32 module"

[Satish BD]

Package: tails-installer
Version: 4.4.7+dfsg-1
Severity: normal

Dear Maintainer,

Running 'tails-installer-launcher' starts the GUI installer. I chose
tails-i386-2.0.iso. The installation failed with error message:

Could not find the 'ifcpu64.c32' COM32 module

The missing module in question is actually provided by 'syslinux-common'
package. I apt-get install'ed it and Tails installation successfully completed.

The bug is that 'syslinux-common' is not in Depends list of 'tails-installer'.
I'm not sure whether this was intentional or not, but at least it should be in
Recommends.

Thanks and regards,
--Satish



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

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

Versions of packages tails-installer depends on:
ii  dosfstools 3.0.28-2
ii  gdisk  1.0.1-1
ii  genisoimage9:1.1.11-3
ii  gir1.2-glib-2.01.46.0-3
ii  gir1.2-gtk-3.0 3.18.7-1
ii  gir1.2-udisks-2.0  2.1.6-2
ii  mtools 4.0.18-2
ii  p7zip-full 9.20.1~dfsg.1-5
ii  policykit-10.105-14.1
ii  python 2.7.11-1
ii  python-configobj   5.0.6-2
ii  python-gi  3.18.2-2
ii  python-urlgrabber  3.9.1-4.2
ii  syslinux   3:6.03+dfsg-11

tails-installer recommends no packages.

tails-installer suggests no packages.

-- no debconf information

Bug#814333: squid3: SSL error "sec_error_inadequate_key_usage" in the browser

[Amos Jeffries]

Control: severity 814333 important
Control: tags 814333 - newcomer
Control: forwarded 814333 http://bugs.squid-cache.org/show_bug.cgi?id=4102
Control: notfound 814333 3.4.8-6+deb8u1
Control: fixed 814333 3.5.10-1


I am dowgrading this bug on grounds that the issue *does not occur in
any of the official Debian packages*.
Nor is fiddling with the security parameters and operation of TLS a bug
activity suitable for newcomers.


On Tue, 09 Feb 2016 22:51:43 -0200 Y wrote:
>
> I downloaded and compiled the squid through apt-build by adding the
following lines in "/var/cache/apt-build/build/squid3-3.4.8/debian/rules":
> --enable-ssl \
> --enable-ssl-CRTD \
> --with-openssl \
>
> Some https sites aprsentam as error the
"sec_error_inadequate_key_usage" message as error code.
> The errors appear when using Firefox and Iceweasel browsers.

As you noted this was a Mozilla issue (yes *was*). It was fixed in
current Firefox/Iceweasel releases, but several workarounds were also
added to recent Squid versions to not trigger it so easily. Those fixes
are not all suitable for backport IIRC, or they would definitely have
happened already.

Upstream policy is that TLS/SSL users should track the laest releases.
This is particularly important for TLS MITM users such as you (seen in
your choice of build options). There are known vulnerabilities in TLS
MITM for all Squid older than 3.5.10. The non-existence of TLS/SSL in
official Debian packages makes these irrelevant to the Debian security
team. Security issues in the custom additions are *your* problem to
track and fix. I highly recommend building from the Stretch package
instead of patching.


Amos Jeffries
(Squid upstream)

Bug#722132: closed by Sylvestre Ledru (Bug#722132: fixed in iwyu 3.3-2)

[Paul Wise]

On Thu, 2016-02-11 at 21:58 -0500, Anders Kaseorg wrote:

> What are you imagining here?  You can’t have automatically generated 
> Build-Depends; furthermore, since (AIUI) iwyu 3.7 doesn’t build against 
> any version of llvm other than 3.7, they wouldn’t help anyway.

I'm imagining it Build-Depending on a package produced by llvm-defaults 
rather than a version-specific package.

Not building with any version other than 3.7 sounds like a bug too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#814488: go-mtpfs: Binary package depends on dev packages

[Vladimir Kudrya]

Package: go-mtpfs
Version: 0.0~git20150802.0.3ef47f9-2
Severity: normal

Dear Maintainer, package go-mtpfs depends on development packages.
Perhaps, build-depends and depends got swapped.

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

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

Versions of packages go-mtpfs depends on:
ii  golang-github-hanwen-go-fuse-dev  0.0~git20150627.0.324ea17-1
ii  golang-github-hanwen-usb-dev  0.0~git20141217.0.69aee45-2
ii  golang-go 2:1.5.3-1
ii  libc6 2.21-7
ii  libusb-1.0-0  2:1.0.20-1

go-mtpfs recommends no packages.

go-mtpfs suggests no packages.

-- no debconf information

Bug#813046: ifupdown2: No network connection on startup

[Sam Tannous]

Hello,

The fix for this problem seems to be a one line change in
/lib/systemd/system/networking.service:

Add "RemainAfterExit=yes" in the [Services] section of
this file.  After adding this line, do a

systemctl daemon-reload

Please try out this one line change.   We should have an updated
package next week.

(You've likely checked the followingbut just in case)
Check to make sure that NetworkManager is
stopped and disabled and that networking is started and enabled.

systemctl status NetworkManager
systemctl stop  NetworkManager
systemctl disable  NetworkManager
# check it to make sure
systemctl -l status NetworkManager

# check/start networking because that is what ifupdown2 expects
systemctl -l status networking
systemctl start  networking
systemctl enable  networking
# now check the output again.
systemctl -l status networking

If you still have issues after rebooting, please include the following
before you manually "ifup -a":

journalctl -l | grep network
ip addr show
systemctl -l status networking
cat /etc/network/interfaces
dpkg -l | grep ifupdown

Thanks,
Sam

On Thu, 28 Jan 2016 21:43:52 +0100 Thomas Mayer 
wrote:
> Package: ifupdown2
> Version: 1.0~git20151029-1
> Severity: important
>
> Dear Maintainer,
>
> after migration from ifupdown to ifupdown2, network connections are not
> available automatically after startup.
>
> ifconfig returns nothing, I have to manually execute ifup -a as root for
> network to come up.
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (701, 'stable'), (700, 'unstable'), (500,
'stable-updates')
> Architecture: i386 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages ifupdown2 depends on:
> ii  init-system-helpers  1.24
> ii  python-argcomplete   0.8.1-1
> ii  python-ipaddr2.1.11-2
> pn  python:any   
>
> ifupdown2 recommends no packages.
>
> Versions of packages ifupdown2 suggests:
> pn  python-gvgen  
> pn  python-mako   
>
> -- no debconf information
>
>

-- 
*Sam Tannous*

Bug#722132: closed by Sylvestre Ledru (Bug#722132: fixed in iwyu 3.3-2)

[Anders Kaseorg]

On Thu, 11 Feb 2016, Paul Wise wrote:
> On Wed, 2016-02-10 at 23:48 -0500, Anders Kaseorg wrote:
> > I would agree if there was a risk of the bug reappearing with an iwyu  
> > rebuild with no source changes against a new llvm-defaults.  But in 
> > fact, debian/control already hard-codes Build-Depends: 
> > libclang-3.7-dev, llvm-3.7-dev, so for the bug to reappear, someone 
> > would have to manually bump two of the 3.7s in debian/control without 
> > bumping the third.
> 
> I didn't see that, thanks for pointing it out.
> 
> That sounds like another thing that should be fixed.

What are you imagining here?  You can’t have automatically generated 
Build-Depends; furthermore, since (AIUI) iwyu 3.7 doesn’t build against 
any version of llvm other than 3.7, they wouldn’t help anyway.

Anders

Bug#814487: bochs: Fix debian/watch file

[Florian Tobias Schandinat]

Source: bochs
Version: 2.6-5
Severity: minor
Tags: patch

Dear Maintainer,

the attached patch fixes the uscan warning of this package to allow 
finding newer upstream versions. By joining the first and second 
field with / it switches from the alternative to the default syntax 
where the pattern does not need to match the whole href.
It also changes the pattern to be a bit more tight.


Best regards,

Florian Tobias Schandinat

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

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

-- no debconf information
--- bochs-2.6/debian/watch	2010-06-08 20:37:19.0 +0200
+++ bochs-2.6-watch/debian/watch	2016-02-12 01:47:49.584213564 +0100
@@ -1,4 +1,4 @@
 # You can run the "uscan" command to check for upstream updates and more.
 # Site		Directory		Pattern			Version	Script
 version=3
-http://sf.net/bochs bochs-([\d.]*).tar.gz debian uupdate
+http://sf.net/bochs/bochs-([\d.]*)\.tar\.gz debian uupdate

Bug#814486: gitk: option to start a terminal in the working directory

[Paul Wise]

Package: gitk
Severity: wishlist

It would be nice to have an option to start a terminal in the working
directory so that if there are git things that can only be done on the
command-line, then I can quickly get to that. I can get a terminal by
starting git gui and using the terminal menu option in that, but that
is a few extra clicks that can be annoying.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#814485: gitk: option to rebase branches from context menu

[Paul Wise]

Package: gitk
Severity: wishlist

It would be nice to have an option to rebase branches from the context
menu, for branches unchanged from upstream the reset feature works fine
but a rebase feature is needed for branches with commits on them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#814484: github-backup: option to use git fetch --all instead of fetching individual remotes

[Paul Wise]

Package: github-backup
Severity: wishlist

I often have remotes that get deleted by the author, but I want to keep
them on my system to review/merge later. To prevent them from causing
issues when fetching all remotes or other remotes, I disable fetching
these remotes using the commands below. github-backup fetches remotes
individually instead of using git fetch --all, so it still tries to
fetch the remotes I have disabled, which means that github-backup hangs
waiting for a password since github does something weird. This is
especially annoying when running github-backup via `mr -j5 backup`,
which I do fairly often and have to manually kill git commands.

git config --bool remote.something.skipDefaultUpdate true
git config --bool remote.something.skipFetchAll true

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#813381: fonts-wine: freetype_SelectFont can't find a single appropriate font

[Jens Reyer]

I tested it further: I completly emptied /usr/share/fonts. Then, only
the font family "Latin Modern (LM)" (installed in
/usr/share/texmf/fonts) is available and used. I checked this in the
font selection dialogs of libreoffice (Linux native) and winefile.

Then I installed wine 1.8-6 with fonts-wine 1.8-6:
this correctly adds several fonts in winefile.

However with wine 1.8.1-1 and fonts-wine 1.8.1-1 installed, even with
- libfontconfig1 (amd64 and i386) installed and
- enabled bitmapped fonts in "dpkg-reconfigure fontconfig-config",
there are no additional fonts available, neither in winefile, nor
in libreoffice.

For Wine to work either the system fonts or wine-fonts *must* work. The
system fonts imo provide a much superior result. I therefore committed
the change for libwine to always depend on libfontconfig1 (so you end up
with e.g. both the i386 and the amd64 version).
The 32-bit version inadvertently missing happens too easily and has too
severe drawbacks, compared to the benefits of not installing this
package and using only fonts-wine - imo this justifies the promotion
from recommends to depends.

However, to close this bug we should also fix fonts-wine. Even in an
afaics correctly set up system these fonts never show up, neither in
wine nor in the system. I have absolutely no clue how to make them in
the new position in /usr/share/fonts/wine work.
But I found this changelog entry from 2006:
---
 * Wine now install its fonts under /usr/share/wine/fonts, not
/usr/share/fonts/wine. (I've updated the packaging accordingly.)
This should stop them from being picked up by fontconfig et al.
Closes: #353495.
---
The fonts were removed from the new position previously on purpose,
because they weren't correctly rendered in some native apps.

Greets
jre

Bug#814483: bochs: Debian package should be built with SMP enabled

[Florian Tobias Schandinat]

Package: bochs
Version: 2.6-5
Severity: wishlist
Tags: patch

Dear Maintainer,

it would be nice if the Debian package of bochs could be built with 
SMP support enabled to allow emulation of multi processor systems  
including multi-cores and multi-threaded ones.
The attached patch does the required change by adding --enable-smp 
to configure in the debian/rules file. It was successfuly built and 
tested on amd64 with the bochs CPU configuration "cpu: count=2:2:2".


Best regards,

Florian Tobias Schandinat

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

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

Versions of packages bochs depends on:
ii  bochs-sdl [bochs-gui]   2.6-5
ii  bochs-term [bochs-gui]  2.6-5
ii  bochs-wx [bochs-gui]2.6-5
ii  bochs-x [bochs-gui] 2.6-5
ii  bochsbios   2.6-5
ii  libasound2  1.0.28-1
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18+deb8u2
ii  libcairo2   1.14.0-2.1
ii  libfontconfig1  2.11.0-6.3
ii  libfreetype62.5.2-3+deb8u1
ii  libgcc1 1:4.9.2-10
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u4
ii  libglib2.0-02.42.1-1
ii  libgtk2.0-0 2.24.25-3
ii  libltdl72.4.2-1.11
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libpangoft2-1.0-0   1.36.8-3
ii  libsdl1.2debian 1.2.15-10+b1
ii  libstdc++6  4.9.2-10
ii  vgabios 0.7a-5

Versions of packages bochs recommends:
ii  bximage  2.6-5

Versions of packages bochs suggests:
ii  bcc [c-compiler]  0.16.17-3.1
ii  bochs-doc 2.6-5
ii  debootstrap   1.0.67
ii  gcc [c-compiler]  4:4.9.2-2
ii  gcc-4.9 [c-compiler]  4.9.2-10
pn  grub-rescue-pc
ii  libc6-dev [libc-dev]  2.19-18+deb8u2

-- no debconf information
--- bochs-2.6/debian/rules	2016-02-11 23:50:20.716077963 +0100
+++ bochs-2.6-smp/debian/rules	2016-02-07 00:27:43.448014936 +0100
@@ -101,6 +101,7 @@
 	  --enable-usb-ohci \
 	  --enable-a20-pin \
 	  --enable-cpu-level=6 \
+	  --enable-smp \
 	  --enable-x86-64 \
 	  --enable-avx \
 	  --enable-vmx=2 \

Bug#722132: closed by Sylvestre Ledru (Bug#722132: fixed in iwyu 3.3-2)

[Paul Wise]

On Wed, 2016-02-10 at 23:48 -0500, Anders Kaseorg wrote:

> I would agree if there was a risk of the bug reappearing with an iwyu 
> rebuild with no source changes against a new llvm-defaults.  But in fact, 
> debian/control already hard-codes Build-Depends: libclang-3.7-dev, 
> llvm-3.7-dev, so for the bug to reappear, someone would have to manually 
> bump two of the 3.7s in debian/control without bumping the third.

I didn't see that, thanks for pointing it out.

That sounds like another thing that should be fixed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#814350: wine: recommended package libwine-gecko-2.40 is not in main

[Jens Reyer]

control: tags -1 + pending

On 02/10/2016 06:12 PM, Jens Reyer wrote:
> Imo the dependency on libwine-gecko-xxx should stay a recommends, a
> suggests imo doesn't meet the importance of Gecko in Wine.
> 
> So I'll commit a change to remove (comment) that from wine and
> wine-development.

Committed for both wine and wine-development. On a second thought I
decided to use suggests as you suggested. We should revert that as soon
as the correct version of libwine-gecko is available.

Greets
jre

Bug#776401: [pkg-golang-devel] Bug#776401: Bug#776401: [Pkg-golang-devel] Bug#776401: Bug#776401: src:golang: Set CGO_ENABLED for all platforms

[Michael Hudson-Doyle]

On 12 February 2016 at 12:44, Tianon Gravi  wrote:
> On 4 February 2016 at 16:56, Michael Hudson-Doyle
>  wrote:
>> I guess it could be fixed by going back to building lots of
>> golang-$GOOS-$GOARCH packages, but somehow that doesn't seem very
>> appealing, it would be nicer to allow the go install command to work
>> (which would also allow the user to use their choice of toolchain for
>> cgo, etc). But I don't know how to do that. Have a per-user overlayfs
>> over /usr/lib/go and set GOROOT to that? (not a serious suggestion!)
>
> IMO at this point, anything writing to GOROOT on "go install" ought to
> be considered an upstream bug. :(

I'm not sure I want to be the one that takes that one upstream.

> Any chance of tracking down what's causing those to try to go to
> GOROOT instead of GOPATH?

It's the standard library packages, GOARCH=arm go install runtime is
going to try to create $GOROOT/pkg/linux_arm/runtime.a.

Cheers,
mwh

Bug#814482: browse-url-emacs: The TLS connection was non-properly terminated.

[Vincent Lefevre]

Package: emacs24
Version: 24.5+1-6+b1
Severity: normal

When I do:

1. Start emacs.
2. M-x browse-url-emacs
3. Copy the URL: https://www.debian.org/
   (or another https URL)

I get after a few seconds:

gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly 
terminated.

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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 emacs24 depends on:
ii  emacs24-bin-common 24.5+1-6+b1
ii  gconf-service  3.2.6-3
ii  libacl12.2.52-3
ii  libasound2 1.1.0-1
ii  libatk1.0-02.18.0-1
ii  libc6  2.21-7
ii  libcairo-gobject2  1.14.6-1
ii  libcairo2  1.14.6-1
ii  libdbus-1-31.10.6-1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6.1-0.1
ii  libgconf-2-4   3.2.6-3
ii  libgdk-pixbuf2.0-0 2.32.3-1.2
ii  libgif75.1.2-0.2
ii  libglib2.0-0   2.46.2-3
ii  libgnutls303.4.9-2
ii  libgomp1   5.3.1-8
ii  libgpm21.20.4-6.1+b2
ii  libgtk-3-0 3.18.7-1
ii  libice62:1.0.9-1+b1
ii  libjpeg62-turbo1:1.4.2-2
ii  libm17n-0  1.7.0-3
ii  libmagickcore-6.q16-2  8:6.8.9.9-7+b1
ii  libmagickwand-6.q16-2  8:6.8.9.9-7+b1
ii  libotf00.9.13-3
ii  libpango-1.0-0 1.38.1-1
ii  libpangocairo-1.0-01.38.1-1
ii  libpng12-0 1.2.54-1
ii  librsvg2-2 2.40.13-2
ii  libselinux12.4-3
ii  libsm6 2:1.2.2-1+b1
ii  libtiff5   4.0.6-1
ii  libtinfo5  6.0+20151024-2
ii  libx11-6   2:1.6.3-1
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxml22.9.3+dfsg1-1
ii  libxpm41:3.5.11-1+b1
ii  libxrandr2 2:1.5.0-1
ii  libxrender11:0.9.9-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

emacs24 recommends no packages.

Versions of packages emacs24 suggests:
ii  emacs24-common-non-dfsg  24.4+1-2

-- no debconf information

Bug#814481: debian-maintainers: Please add Christian Seiler as a Debian Maintainer

[Christian Seiler]

Package: debian-maintainers
Severity: normal

Hi,

please add my key (0xD3284E4E61A9278A511ABC9655DB1ABC3818B08C) to
the Debian Maintainers keyring.

The jetring changeset is attached.

Thanks!

Regards,
Christian
Comment: Add Christian Seiler  as a Debian Maintainer
Date: Fri, 12 Feb 2016 02:21:15 +0100
Action: import
Recommended-By: 
  Ritesh Raj Sarraf 
Agreement: 
  https://lists.debian.org/debian-newmaint/2016/02/msg8.html
Advocates: 
  https://lists.debian.org/debian-newmaint/2016/02/msg9.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1
  
  mQINBFF4O0IBEADO1V0Vzf1WENssRy4fMU6m7vqm4gqxtfyJMlr2C6b+rNdBJIk1
  DD6arxwdl4QrJcI+Ut+JjWz3IeuP57UAAbMb90yQk1Tm/jR+pa13Sw9+kENigS6n
  YW7/fEIDlTykd8HxwRYpM70DaKOYHYaDGnBpkn29WrSYq758l0jqsJ2csNFydomP
  WdmvcryXxx7HGI6FUrxCO3xhZWzxQBsMlrkn6Jm+SQUM1SVEJ9M8qWQfhQ+GqaUc
  MZLDD38oa2xAtYcLblupy7KeZr3qDq9yf8f3PMIKivZUrK921a83B52/7CfG44ry
  C9//FajblMT1Gg5E6MxexFw2vwIHqSSI5f+UdttxBVZUG+VDEWWqt18pWK0xNWHT
  4sFR92frNqM9ps0jzhna/zM6Ef/LPoNk1WtsMEsmwgFzrjTakE/1YIbLbE3Feg+A
  2nRa06c6TsSdw7JpZGLvgfEuWWSLf1o6dQooIDA7X4PLd4tb/7sjjPLlL87+Qtyt
  9yy2IT92VdkrWrFsNn9Y3prxJmwi8q9fLYn3f0+ehv8QNNXKWLiZpIVJDrFcWN+g
  ev0srZVw7xAJTDd4hfkWq/+ve3IWYKjpQr9g6mCns0957aRAiBEkoZP64NX02sxQ
  cn721h5LHPiOb14TlVNDZJekKjDFW3Kj5Rd7oTktnxgChSmacvd/35aVNwARAQAB
  tCVDaHJpc3RpYW4gU2VpbGVyIDxjaHJpc3RpYW5AaXdha2QuZGU+iQI9BBMBCgAn
  AhsvBQkSzAMAAh4BAheABQJVrBT/BQsJCAcDBRUKCQgLBRYCAwEAAAoJEFXbGrw4
  GLCMmPMP/01CDY4gP5kuokLmjN5XvdkEfAwkjiFfmDYsvjVIcmB8W4E2VJyQx4Ht
  1lbplDBg+BicSGt/zV3xvBcwjno0fis32HxQ2Zb0bVgT4IvdBCrlDRzBUWlKWI46
  5JIm6J5tKFVmJY7NeYzYQa178qcrPssURRiU92+DtUb3S9bNhosnGZs2HWeJjzdF
  T+TreWGTFPPkySjv76fytXiPbDYozSRUD21dfZSehtQKSPJPutoIAbHLC/IJJMDp
  HIP0HtaLCqKi/fJ5TKdfHiC3+4tgNBzPDRKtMOT/LeOK1AxcTzzulTmRwG+zXTHw
  1IPrAZDtejG+gv0xAMywmiFSUqTubWLnywZKVZ+atTI8yHm4pigOQOXnS6o8GRvE
  IzUM2o1D1Jf6+X/uhhzGGUxmnznM2DoHzMl16MnSrQ8LyvqEUOJafVf87iZ8NS4c
  pRon6TPy1oRiyWdRvFUEcRIdy7okn7ERrZjHnDOWFrwc2eQAUlRmTQ7NaJYCcnxo
  0qEMjWPJdpBoYb+w7YDN5IQ0KZMtiUXm5nBjKqPQG6Bj2hSAfwbhHbG0f8ODeYUn
  mPEzmBbY+PSMz43o7C0yRLwBK9zO7UQMq+fPBmEsE87HXo2CO9Oztj8lr5GJGYoj
  RDlfrWPDpiLbEFYrxaI7hczBckX3eidt6af6XnEFRJLhYWnQQMY6iQI/BBMBAgAp
  BQJRkSetIhpodHRwOi8vc2VycGVkb24uZGUvcGdwLXBvbGljeS50eHQACgkQvCKt
  lv4Bz7fkwhAApMG2spbMVL9O0tV2MJ16cm84GON2L1v4Zl1oDNzY60bitW8mG0Gb
  v4L4eEju3PF8DrcEQST6cnXmTofWf36CwN8HYzFhPsl1n6SM9tHG1RV7EiHZuxbp
  8r8mQgxKoHR69DQlc0nqXXt/z7ZG92DrCRyQTCDOh7wD+jLeZVNTmrMBsL2f2BU7
  O80aTIBK+bplsS5qdPJGKVx7I0IIXphPBKYo/3nwa9d0hFEUT4+pjeUFTnCHKEf4
  Z41c5FZHOYi3nT17uk7DV+kXLg8fOD1L4nxsLRcQRVCJtrP+efuct7XjX9cdpg5F
  VyRgoK5VSo9nBxqD6Ic1ZK1Tyipn/cYn7RGvESLeIYPxnbAjxd4nBAJNNf4WGdW2
  ZgKMilsc3eeFDPQtQIzt6Vq7P1d+y/vYAXs9kw50ijnnA6A61hJhHOUivkU90rgD
  5L5zG3OxRXHCW1poWs2Yd8zu8wNmNs4rUO/w6ayxZaepck+XwaO47+bdXeU7F372
  /GYa1jZ4gumlrqoWgXQ7hsaE3KNSsNosv1nUaf/BDVovV+6Qhr2honVSDoTcIBW5
  kgXfTpXpA94HA2zWU25yHWMcjBTjkZvcHPssl0JY8/1OhpGdikxTuhSHj4DERf4z
  dbQf88UlxAwk5JsRSWUJNNK5ZrIxi0/CtmrBGEGwLeTbpolJh3ZL+LuJAhwEEAEC
  AAYFAlXQ5uIACgkQ8vEcI/AKK+aGjhAAl8VxiKeSAVgcz3MFAuLBmhul07ap+GIR
  MhZ43kmxE2z/hJS/nS86of/KBTCypm0LmUSygVKp91MZxPnyUk5TrKnyX1B6a5bg
  O4c9KV3hjxz5EJgBozt4h5US/mGwOUtdxteIv6dLHopte/UyndMJ/eNAiAbjpkab
  0+mlJzKs7Cc9C70DZlhOn4xPlM21NqdN0aMrjXiOqT59Qho+Pr13sYBOBYDY0Goe
  lUn/FvZuv/V1k/uM4k31HDkK0ALZAcvhvdPDAo5LYgH9nt8jpr8l4x6GnTVkjItQ
  CVsR6fwNRzYeW4Miqj9RtzdKSDspp5Y0zSdtKznpWZa4/cSQiD7zPlpzuSBKIaXE
  UF03r7IYs3Olb+5lIia9gHFeaywazgCqsnlTMZAQVbVg2sZYTAf5jU8CwG9Sd/qj
  vNASz68MpoeN3wBiR4m8n+fk8pq39e9BzBVqT5XWOu3P+q0C988k9VIut8GljuU2
  4UdkGKKR+G1YzLaPgn+hR5ccqrQ9mkwdytUl59Cd+KnoOtiO0Ql7whSIPQWVQ1Py
  PM5D4F84arovVxrHczE5km5ZL9WiIouFSVQaPiOwOx8EioNjzHXj0wulBukguoqR
  7z4ThhmVUHl5hbgvgaijDQLFuXnPejjfYP0+EDdrk9uvms05seMP5+fQwcuYmHy6
  dfjYibaCqSuJAj4EEwECACgCGy8FCRLMAwACHgECF4AFAlWsEckGCwkIBwMCBhUI
  AgkKCwQWAgMBAAoJEFXbGrw4GLCMDzQQAMgDzc2+BZJLCK6lRSlG3vsgEDsbS7Cn
  UFvG6jU9GryNoN4w7QJoMZyTKh6zaKltuzXhBmkq+fdywIa0SCWGyEAEXHMPc0Ym
  n4+qg47SFb6isDXGVAypBnqx0LWBMQVtrD9+Kf+OgCio16kZmHcu7fDiO2mEiNMx
  FyNgIrpnsSS70AZYDut7eTGYPr5XI04aWsdSmv4afBWAAr7uC7Eb+oN6e7J7zusO
  gGh5//XxHV9p2ZFDr+XtxqnPbg240mK9tcndVFbua4c4YOUlrEd7MF1ugRIMNbog
  XSixvdgFjaFQ/p+Gqb2ndQVz85W4rk2XPSvwlh/WaZ9HcaRidWsbHvk8YwJfkfAq
  oneJwhlCRhMI8Y8+Z2PkU1vzL8f/yPBwlj9OkOOKQG92JxsuNLsckS0KKLWI6h9F
  6mPFKAmp2FBCedOls6A0y0QIWAAR0VlHrbz4OVPcwUy+8/RqZZZqbRtVyXCAcpup
  2Jw10dyqySvTN2sJeRjKWTa1v5PER1lcHhq6ScWC0z3L7oQCjZ/PaMiahdg/Xcqo
  Fp29+NZyW52w7EUe8SwlXCD5MOscSKbopibHWxw5hYG8uIb7kNyjExSZgFD6+Ce/
  7/M4kaKrjs+1QOwIVKycytzQ0fFfovxzykceP4wcp6ySDK11eTfIIAJ7m4d4IlEk
  RWqcIcgQyukxiQI/BBMBAgApBQJReDtCAhsvBQkSzAMABwsJCAcDAgEGFQgCCQoL
  BBYCAwECHgECF4AACgkQVdsavDgYsIyqQxAAvW7NHlaFdq2ZYMY2XIT88feRHjJc
  cZZ5AE0zZ2rxD14OLvqQVxT7AS9nCyxp9Dg+qmxdyTYzUCeZn4h39Sg4g+4fCY4h
  15JJvbNSp6+K1GVUyMDGxlC9Qq3dvxJJ36QnZMcXsZfOyVXqMqJ/KNBaCfeS47U0
  3032ONAHXcWuYGptp3s6bVNxC4pIdnuhZhljfvCZfdE4/1JaCoMVC/ePisdwDGl9
  iTqHwVMzxTyO1ZqxX3kflqpSZjpF6trJFG5v2XpdB4tyMLcLPsHaYhXS90S1XpZY
  Q9QN2dtMOkVikMOSNRfvw5enyRn1/vPWL84lPLDTEJdUy17+o+HvQcQXAH19

Bug#814479: libbusiness-creditcard-perl: New upstream version 0.35 (including new MasterCard ranges)

[Ivan Kohler]

Package: libbusiness-creditcard-perl
Version: 0.33-1
Severity: important
Tags: upstream

New upstream version 0.35 is available.

The most important change in this release is recognition of new MasterCard
ranges which will be issued starting in October 2016.

I recommend also uploading this verison to wheezy-updates and jessie-updates
(aka the artist formerly known as "volatile").

-- 
Ivan Kohler
President and Head Geek, Freeside Internet Services, Inc.  http://freeside.biz/
Debian GNU/Linux developer  |  CPAN author  |  cat person  |  ski addict

Bug#814480: imagemagick: cannot upgrade: /usr/share/doc/imagemagick contains files not owned by package imagemagick:all

[Vincent Lefevre]

Package: imagemagick
Version: 8:6.9.2.10+dfsg-2
Severity: grave
Justification: renders package unusable

When upgrading, I get the following error:

dpkg-maintscript-helper: error: directory '/usr/share/doc/imagemagick' contains 
files not owned by package imagemagick:all, cannot switch to symlink
dpkg: error processing archive 
/var/cache/apt/archives/imagemagick_8%3a6.9.2.10+dfsg-2_all.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/imagemagick_8%3a6.9.2.10+dfsg-2_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- Package-specific info:
ImageMagick program version
---
animate: compare: convert: composite: conjure: display: identify: import: 
mogrify: montage: stream: 
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages imagemagick depends on:
iu  imagemagick-6.q16  8:6.9.2.10+dfsg-2

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information

Bug#814315: tracker.debian.org: Please switch URLs to https

[Paul Wise]

On Fri, Feb 12, 2016 at 11:09 AM, Guillem Jover wrote:
> On Wed, 2016-02-10 at 10:43:27 +0100, Raphael Hertzog wrote:
>> On Wed, 10 Feb 2016, Guillem Jover wrote:
>> > * the copyright link itself and its redirect points to http
>> >   http://deb.li/DTAuthors
>>
>> Fixed in git and in the custom template on tracker.debian.org.
>
> I guess the redirection itself still needs to be fixed, as it
> currently uses http: and points to gitweb.

Done:

ssh alioth.debian.org ~bzed/godebian-client/update_static_url
https://anonscm.debian.org/cgit/qa/distro-tracker.git/tree/COPYRIGHT
DTAuthors

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#813751: gpm patch for musl support

[Szabolcs Nagy]

Tags: patch

* Helmut Grohne  [2016-02-11 18:21:59 +0100]:
> On Fri, Feb 05, 2016 at 12:43:53AM +0100, Szabolcs Nagy wrote:
> > +This makes gpm compile against musl libc.
> 
> I cannot reproduce this. Even after applying your patch, the build still
> fails:
> 
> prog/display-buttons.c:69:4: error: unknown type name 'fd_set'
> 
> Can you update the patch and add the patch tag again?
> 

fixed.
diff -u gpm-1.20.4/debian/changelog gpm-1.20.4/debian/changelog
--- gpm-1.20.4/debian/changelog
+++ gpm-1.20.4/debian/changelog
@@ -1,3 +1,14 @@
+gpm (1.20.4-6.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use SA_NODEFER instead of its non-standard alias SA_NOMASK.
+  * Add missing sys/select.h and fcntl.h includes.
+  * Use standard sigemptyset unconditionally.
+  * Define SA_INTERRUPT if it's not defined (historical no-op).
+  * With these changes gpm builds against musl libc.
+
+ --Fri, 12 Feb 2016 00:47:02 +
+
 gpm (1.20.4-6.1) unstable; urgency=low
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/lib/liblow.c
+++ gpm-1.20.4/src/lib/liblow.c
@@ -173,7 +173,7 @@
   /* Reincarnation. Prepare for another death early. */
   sigemptyset(&sa.sa_mask);
   sa.sa_handler = gpm_suspend_hook;
-  sa.sa_flags = SA_NOMASK;
+  sa.sa_flags = SA_NODEFER;
   sigaction (SIGTSTP, &sa, 0);
 
   /* Pop the gpm stack by closing the useless connection */
@@ -350,7 +350,7 @@
 
  /* if signal was originally ignored, job control is not supported */
  if (gpm_saved_suspend_hook.sa_handler != SIG_IGN) {
-sa.sa_flags = SA_NOMASK;
+sa.sa_flags = SA_NODEFER;
 sa.sa_handler = gpm_suspend_hook;
 sigaction(SIGTSTP, &sa, 0);
  }
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/prog/display-buttons.c
+++ gpm-1.20.4/src/prog/display-buttons.c
@@ -36,6 +36,7 @@
 #include /* printf() */
 #include  /* time()   */
 #include /* errno*/
+#include/* fd_set, FD_ZERO  */
 #include   /* gpm information  */
 
 /* display resulting data */
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/prog/display-coords.c
+++ gpm-1.20.4/src/prog/display-coords.c
@@ -37,6 +37,7 @@
 #include /* printf() */
 #include  /* time()   */
 #include /* errno*/
+#include/* fd_set, FD_ZERO  */
 #include   /* gpm information  */
 
 /* display resulting data */
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/prog/gpm-root.y
+++ gpm-1.20.4/src/prog/gpm-root.y
@@ -1197,11 +1197,10 @@
 LOG_DAEMON : LOG_USER);
/* reap your zombies */
childaction.sa_handler=reap_children;
-#if defined(__GLIBC__)
-   __sigemptyset(&childaction.sa_mask);
-#else /* __GLIBC__ */
-   childaction.sa_mask=0;
-#endif /* __GLIBC__ */
+   sigemptyset(&childaction.sa_mask);
+#ifndef SA_INTERRUPT
+#define SA_INTERRUPT 0
+#endif
childaction.sa_flags=SA_INTERRUPT; /* need to break the select() call */
sigaction(SIGCHLD,&childaction,NULL);
 
only in patch2:
unchanged:
--- gpm-1.20.4.orig/src/prog/open_console.c
+++ gpm-1.20.4/src/prog/open_console.c
@@ -22,6 +22,7 @@
 #include "headers/message.h"/* messaging in gpm */
 #include "headers/daemon.h" /* daemon internals */
 #include 
+#include 
 
 int open_console(const int mode)
 {

Bug#814478: cups: OKI 320 print drivers not working correctly

[Kurt Theis]

Package: cups
Version: 1.7.5-11+deb8u1
Severity: important

Dear Maintainer,

The printer driver for the OKI Microline 320 turbo printer does not send
any recognizable output to the printer. This is a dot matrix printer.

In installing cups, I chose the USB connected OKI 320 driver. When I printed a
text file (a listing of ls-a) random characters were printed out along with a 
LOT
of FF's. 

When I switched the driver to generic the printer worked just fine. I switched 
back to the OKI
driver, got the same bad result. I switched back to generic and all works well.

FYI - Since 1994 the drivers NEVER worked for ANY oki dot matrix printer
I tried to use. This is not a new occurance. Guessing the old drivers were just 
copied 
every time since then (yes, i have had a working Linux installation since '94)

I very much want to use the driver for the OKI since it had features I want, 
that 
the generic driver does not.


Kurt
 

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

Kernel: Linux 4.1.13-v7+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups depends on:
ii  cups-client1.7.5-11+deb8u1
ii  cups-common1.7.5-11+deb8u1
ii  cups-core-drivers  1.7.5-11+deb8u1
ii  cups-daemon1.7.5-11+deb8u1
ii  cups-filters   1.0.61-5+deb8u3
ii  cups-ppdc  1.7.5-11+deb8u1
ii  cups-server-common 1.7.5-11+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  ghostscript9.06~dfsg-2+deb8u1
ii  libavahi-client3   0.6.31-5
ii  libavahi-common3   0.6.31-5
ii  libc-bin   2.19-18+deb8u1
ii  libc6  2.19-18+deb8u1
ii  libcups2   1.7.5-11+deb8u1
ii  libcupscgi11.7.5-11+deb8u1
ii  libcupsimage2  1.7.5-11+deb8u1
ii  libcupsmime1   1.7.5-11+deb8u1
ii  libcupsppdc1   1.7.5-11+deb8u1
ii  libgcc11:4.9.2-10
ii  libstdc++6 4.9.2-10
ii  libusb-1.0-0   2:1.0.19-1
ii  lsb-base   4.1+Debian13+rpi1+nmu1
ii  poppler-utils  0.26.5-2
ii  procps 2:3.3.9-9

Versions of packages cups recommends:
ii  avahi-daemon 0.6.31-5
ii  colord   1.2.1-1+b2
ii  cups-filters [ghostscript-cups]  1.0.61-5+deb8u3
ii  printer-driver-gutenprint5.2.10-3+b3

Versions of packages cups suggests:
ii  cups-bsd   1.7.5-11+deb8u1
pn  cups-pdf   
pn  foomatic-db-compressed-ppds | foomatic-db  
pn  hplip  
pn  printer-driver-hpcups  
pn  smbclient  
ii  udev   215-17+deb8u2

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

Bug#784673: cloud-utils: growpart fails with gpt

[Tiago Ilieve]

Hi Charles,

On 11 February 2016 at 11:19, Charles Plessy  wrote:
> Hi Tiago,
>
> this reminded your request for sponsoring the backport of cloud-utils; I just
> uploaded it.  (Build logs attached for the record).

This is awesome. Thank you very much!

It is on the NEW queue[1] right now. :-)

[1]: https://ftp-master.debian.org/backports-new.html

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#814342: lowmem should not block when in network-console d-i mode

[Martin Michlmayr]

* Roger Shimizu  [2016-02-11 16:28]:
> Now it's clear, since in d-i, file
> build/pkg-lists/netboot/network-console/armel/orion5x.cfg
> 
> oldsys-preseed
> # sata and ext2/ext3 modules are needed by oldsys-preseed to read the disk
> # -> disable due to size problems

That doesn't explain what you're seeing.  If oldsys-preseed cannot
read the disk on Buffalo devices, it should still generate a preseed
file with DHCP and a fallback IP address (as well as the lowmem
override).

Please debug why (and what) is not working for you.

> I think maybe it's necessary to split "orion5x" as:
> - orion5x with serial console support, which keeps current config, so
> as kuroboxpro can be supported
> - orion5x without serial console support, re-enable sata and ext4, but
> disable jffs2 and micro-evtd
> 
> What's your idea?

"with serial console support" would be the netboot image.  So you're
suggesting that Kurobox Pro should use the netboot image whereas other
Buffalo devices should use network-console.

I don't know if Kurobox Pro all have a serial console.  I used to have
such a device but I cannot remember anything about it.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#814477: python-pkg-resources: Package from backports break functioning of python apps

[Jaroslav Mikulík]

Package: python-pkg-resources
Version: 18.8-1~bpo8+1
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

Installing package from backports branch (and newer, i.e. from sid) break many
python software unusable.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Try to run apps, like bpython and many others. Try this for example:

Example in python:

>>> from pkg_resources import load_entry_point

   * What was the outcome of this action?

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3138,
in 
@_call_aside
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3124,
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3151,
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 652,
in _build_master
ws = cls()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 645,
in __init__
self.add_entry(entry)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 701,
in add_entry
for dist in find_distributions(entry, True):
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2139,
in find_on_path
path_item, entry, metadata, precedence=DEVELOP_DIST
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2521,
in from_location
py_version=py_version, platform=platform, **kw
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2835,
in _reload_version
md_version = _version_from_file(self._get_metadata(self.PKG_INFO))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2486,
in _version_from_file
line = next(iter(version_lines), '')
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2654,
in _get_metadata
for line in self.get_metadata_lines(name):
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2030,
in get_metadata_lines
return yield_lines(self.get_metadata(name))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2025,
in get_metadata
metadata = f.read()
  File "/usr/lib/python2.7/codecs.py", line 296, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xb6 in position 147:
invalid start byte

   * What outcome did you expect instead?

Importing from pkg_resources module OK, like in module from stable branch work.



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

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

Versions of packages python-pkg-resources depends on:
pn  python:any  

python-pkg-resources recommends no packages.

Versions of packages python-pkg-resources suggests:
ii  python-setuptools  18.8-1~bpo8+1

-- no debconf information

Bug#806595: aptitude: Changelog download throws warning: "W: Can't drop privileges for downloading as file '/tmp/aptitude-root.15442:qGi6mn/aptitudeDownload6J+8J:+PsVGmTNm^.^::Lz:%.Hi55VKA' couldn't b

[Manuel A. Fernandez Montecelo]

Hi,

2016-02-09 17:41 Matijs van Zuijlen:


Is there any way to avoid this warning? It is especially annoying in the TUI,
since it creates a pop-up that needs to be dismissed.



2016-02-11 22:21 Ben Finney:


There must be some extra difference, more than the ownership or
permission of those directories.



There are several problems and behaviours depending on which user
launches aptitude, and the version of apt being used (behaviours of apt
related with this changed, as reflected in the different messages of the
report).

The cause of the different warnings/messages merged in this report was
due to different problems as well, which makes things confusing when
replying to the reports, sorry if I misled you.


But in short, I think that I fixed this now after many a session trying
to sort out all of the related problems, hopefully to be released in the
next few days.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#814443: apt: Unable to parse package file /var/lib/apt/lists/..._Packages (1)

[Vincent Lefevre]

On 2016-02-11 19:46:07 +0100, Julian Andres Klode wrote:
> More details please. Save a backup of the file (and the InRelease
> file), then delete it, and run update again. Send the broken file (and
> InRelease) in, so we can look at it, or look at it yourself and see
> if/how it is broken.

I did that, but I can't reproduce the problem. But when I had looked
at the file when I got the error, there was one of the hashes on its
own line at the end of the file, after a blank line.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#814315: tracker.debian.org: Please switch URLs to https

[Guillem Jover]

On Wed, 2016-02-10 at 10:43:27 +0100, Raphael Hertzog wrote:
> On Wed, 10 Feb 2016, Guillem Jover wrote:
> > * several of the versioned links for package metadata like
> >   https://tracker.debian.org/media/packages/d/dpkg/changelog-1.15_1nypb7o.11
> >   (the tamporary pathname in the URL is reported in another bug).
> >   https://tracker.debian.org/media/packages/d/dpkg/rules-1.16.9~bpo60%2B1
> 
> The URL are relative as far as I know and so do not hardcode http or
> https... where do you see some http URL?

Hmm, it seems it's a problem with chromium, the URLs when copied or
accessed are fine, but when hovering over they are rendered lacking
the https. iceweasel or links seem to render them fine.

> > * the copyright link itself and its redirect points to http
> >   http://deb.li/DTAuthors
> 
> Fixed in git and in the custom template on tracker.debian.org.

I guess the redirection itself still needs to be fixed, as it
currently uses http: and points to gitweb.

> (Will deploy the changes soonish)

Cool, thanks.

Regards,
Guillem

Bug#792202: texlive-bin: Please make the CreationDate, ModDate and ID field deterministic

[Norbert Preining]

tag 792202 + wontfix
thanks

Hi Reiner,

thanks for contacting us and for your work on reproducible builds.
I agree that this might be a nice aim, but we cannot throw out
30 years of behaviour that might be expected by loads of people
as a default setting, so what you are asking for is not acceptable.

> Subject: Don't include "CreationDate:" in ps files generated by dvips
> 
> --- a/texk/dvipsk/dvips.h
> +++ b/texk/dvipsk/dvips.h
> @@ -7,7 +7,6 @@
>  
>  /*   This file is the header for dvips's global data structures. */
>  
> -#define CREATIONDATE
>  
>  #define MAX_CODE 0x11
>  #define MAX_2BYTES_CODE 0x1

For sure not by default, but Karl Berry agreed that if someone provides
a patch to have the creationdate removed via an option (disabled by default),
then he will include it.


> --- a/texk/web2c/pdftexdir/pdftex.web
> +++ b/texk/web2c/pdftexdir/pdftex.web
> @@ -14434,10 +14434,7 @@
>dvi_four(2540); dvi_four(473628672); {conversion ratio for sp}
>prepare_mag; dvi_four(mag); {magnification factor is frozen}
>old_setting:=selector; selector:=new_string;
> -  print(" TeX output "); print_int(year); print_char(".");
> -  print_two(month); print_char("."); print_two(day);
> -  print_char(":"); print_two(time div 60);
> -  print_two(time mod 60);
> +  print(" TeX output ");
>selector:=old_setting; dvi_out(cur_length);
>for s:=str_start[str_ptr] to pool_ptr-1 do dvi_out(so(str_pool[s]));
>pool_ptr:=str_start[str_ptr]; {flush the current string}

Definitely not, since this is expected behaviour from TeX and friends
since ages, again.

Please note, for reproducible builds one *can* use the option
-output-comment 
which should replace the time stamp with the provided comment.

Furthermore, the next release of pdftex (in TL2016) will have
patches inspired by reproducible build to mitigate the effects
(see SOURCE_DATE_EPOCH patches).

I hope that helps

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#311188: Delivery notification..(View the attachment for confirmation of your delivery address)

[FedEx Courier Service]

FedEx-Delivery Post (USA).docx
Description: MS-Word 2007 document

Bug#775578: systemd kills spamassassin on system start

[James Bottomley]

On Thu, 2016-02-11 at 23:41 +0100, Michael Biebl wrote:
> Control: tags -1 + moreinfo
> 
> On Sat, 17 Jan 2015 09:08:32 -0800 James Bottomley
>  wrote:
> > Package: systemd
> > Version: 215-8
> > Severity: normal
> > 
> > Almost every time the system reboots, spamassassin fails to start. 
> >  The systemd logs for this are:
> > 
> > # systemctl status -l spamassassin.service
> > ● spamassassin.service - Perl-based spam filter using text
> > analysis
> >Loaded: loaded (/lib/systemd/system/spamassassin.service;
> > enabled)
> >Active: failed (Result: timeout) since Sat 2015-01-17 08:49:04
> > PST; 3min 45s ago
> >   Process: 528 ExecStart=/usr/sbin/spamd -d -
> > -pidfile=/var/run/spamassassin.pid $OPTIONS (code=killed,
> > signal=TERM)
> > 
> > Jan 17 08:48:10 bedivere spamd[528]: logger: removing stderr method
> > Jan 17 08:49:04 bedivere systemd[1]: spamassassin.service start
> > operation timed out. Terminating.
> > Jan 17 08:49:04 bedivere systemd[1]: Failed to start Perl-based
> > spam filter using text analysis.
> > Jan 17 08:49:04 bedivere systemd[1]: Unit spamassassin.service
> > entered failed state.
> > Jan 17 08:49:04 bedivere spamd[748]: spamd: server killed by
> > SIGTERM, shutting down
> > Jan 17 08:49:04 bedivere spamd[748]: spamd: cannot unlink
> > /var/run/spamassassin.pid: No such file or directory
> > 
> > This server is still x86 and a big internet system, so it has lots
> > of
> > intensive processes on start, like fail2ban , clamd and apache.  It
> > looks like because of this, systemd gives spamassassin a few
> > seconds
> > (there's no log of how long; the logger message is from the pre
> > -reboot
> > os) to start and it takes longer.
> > 
> > As far as I can tell, this value doesn't seem to be configurable or
> > even package specific.  It looks remarkably silly for the init
> > system
> > to impose an absolute timeout on service start, particularly when
> > it
> > doesn't take into account the characteristics of the machine or ask
> > the package how long it might reasonably take.
> > 
> > So far, it's only spamassassin, so it's annoying but not serious to
> > have to log in and restart it after every reboot.  However, if
> > systemd
> > did this to a necessary service, it would become a serious bug
> 
> Can you provide instructions how this issue can be reproduced?

You mean reproduce this outside of booting the system? I have no idea
how to do that.  I suspect it's a load issue, so this is the system:

cat /prbedivere:~# cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 2
model name  : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping: 9
microcode   : 0x2e
cpu MHz : 2813.471
cache size  : 512 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
pebs bts cid xtpr
bugs:
bogomips: 5626.94
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 32 bits virtual
power management:

bedivere:~# cat /proc/meminfo 
MemTotal:1022016 kB
MemFree:   43816 kB
MemAvailable: 346924 kB
Buffers:   36980 kB
Cached:   295580 kB
SwapCached:39344 kB
Active:   528756 kB
Inactive: 395168 kB
Active(anon): 321488 kB
Inactive(anon):   306540 kB
Active(file): 207268 kB
Inactive(file):88628 kB
Unevictable:   0 kB
Mlocked:   0 kB
HighTotal:131016 kB
HighFree:   7628 kB
LowTotal: 891000 kB
LowFree:   36188 kB
SwapTotal:   1951892 kB
SwapFree:1582008 kB
Dirty:   120 kB
Writeback: 0 kB
AnonPages:568992 kB
Mapped:54324 kB
Shmem: 36664 kB
Slab:  36280 kB
SReclaimable:  21972 kB
SUnreclaim:14308 kB
KernelStack:3096 kB
PageTables: 4420 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 2462900 kB
Committed_AS:1973536 kB
VmallocTotal: 122880 kB
VmallocUsed:   11120 kB
VmallocChunk: 103032 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   4096 kB
DirectMap4k:   86008 kB
DirectMap4M:  823296 kB

You can probably configure a VM roughly to match that

James



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

Bug#811300: FTBFS: error: 'OBEX_TRANS_CUST' undeclared

[Andreas Beckmann]

Followup-For: Bug #811300
Control: found -1 0.5.4-2.3

Hi,

>   * Change B-D from libopenobex1-dev to libopenobex2-dev.

libsyncml-dev still Depends on the obsolete libopenobex1-dev.


Andreas

Bug#776401: [pkg-golang-devel] Bug#776401: Bug#776401: [Pkg-golang-devel] Bug#776401: Bug#776401: src:golang: Set CGO_ENABLED for all platforms

[Tianon Gravi]

On 4 February 2016 at 16:56, Michael Hudson-Doyle
 wrote:
> I guess it could be fixed by going back to building lots of
> golang-$GOOS-$GOARCH packages, but somehow that doesn't seem very
> appealing, it would be nicer to allow the go install command to work
> (which would also allow the user to use their choice of toolchain for
> cgo, etc). But I don't know how to do that. Have a per-user overlayfs
> over /usr/lib/go and set GOROOT to that? (not a serious suggestion!)

IMO at this point, anything writing to GOROOT on "go install" ought to
be considered an upstream bug. :(

Any chance of tracking down what's causing those to try to go to
GOROOT instead of GOPATH?

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#814403: ckeditor: FTBFS: /usr/bin/ckbuilder: 2: /usr/bin/ckbuilder: Syntax error: Unterminated quoted string

[Chris Lamb]

> The log is only 36 lines long (inlining below) and it does not have 
> information about build environment, downloaded Build-Deps etc.

The Reproducible Builds can also reproduce it in the same way; the log there 
should contain enough detail:

  
https://reproducible.debian.net/rbuild/unstable/amd64/ckeditor_4.5.6+dfsg-1.rbuild.log


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#814267: gosa: annoying warning on each login with debian-edu

[Holger Levsen]

forcemerge 794189 814267
thanks

Hi Mike,

great that we're having patches! This mail is now mostly about the bugs 
against release.debian.org needed, so we can get updated packages into 8.4.

On Donnerstag, 11. Februar 2016, Mike Gabriel wrote:
> For GOsa, I have a patch in the pipeline candidate for a jessie-pu:
> http://anonscm.debian.org/cgit/debian-edu/pkg-team/gosa.git/commit/?h=debia
> n/jessie/updates&id=3cd550d0ba36bff7106b9ae6f477f9571ab86535

I see there is
#796823: jessie-pu: package gosa/2.7.4+reloaded2-1+deb8u2
with no reply since August 2015… I think it's entirely appropriate to ping the 
bug now, I just don't if the proposed patch from "back then" is still what we 
need today. Is it?

> For debian-edu-config, this is already addressed in Git, too:
> http://anonscm.debian.org/cgit/debian-edu/debian-edu-config.git/commit/?h=j
> essie&id=a796ac7f3e3cf3775465340ab0d9f3e009d81878

There is no bugs against release.debian.org filed yet, I supposed we should 
file one for all the changes described in 
http://anonscm.debian.org/cgit/debian-edu/debian-edu-
config.git/tree/debian/changelog?h=jessie ?!


cheers,
Holger


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

Bug#814476: gitlab writes into /usr/share/gitlab during operation

[Johannes Schauer]

Package: gitlab
Version: 8.4.3+dfsg-3
Severity: serious
Justification: Policy 9.1.1

Hi,

as per Debian policy §9.1.1, packages must comply with the FHS 2.3 but
gitlab is writing log files to /usr/share/gitlab/log/ which violates
chapter 4 of the FHS. Quote:

"/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between various
FHS-compliant hosts and must not be written to. Any information that is
host-specific or varies with time is stored elsewhere."

this requirement is currently violated by gitlab.

No wonder I couldn't figure out where the log files were :D

Log files should go into /var/log/gitlab

Thanks!

cheers, josch

Bug#814403: ckeditor: FTBFS: /usr/bin/ckbuilder: 2: /usr/bin/ckbuilder: Syntax error: Unterminated quoted string

[Dmitry Smirnov]

> I don't think so; I can reproduce it on another machine.

Well, I re-built successfully several times in updated/clean pbuilder on 
amd64 and i386. I suppose if it works for me then there must be something 
wrong on my side? ;)


> > > The full build log is attached.
> > 
> > Ahhm, build log is not full ;)

> Sorry, I don't understand.

The log is only 36 lines long (inlining below) and it does not have 
information about build environment, downloaded Build-Deps etc.

I could use this information to identify differences between our build 
environments...


 dpkg-buildpackage -rfakeroot -D -us -uc -b
dpkg-buildpackage: source package ckeditor
dpkg-buildpackage: source version 4.5.6+dfsg-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Dmitry Smirnov 
 dpkg-source --before-build ckeditor-4.5.6+dfsg
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
   debian/rules override_dh_clean
make[1]: Entering directory '/home/lamby/temp/cdt.20160211091323.3ap86cQP05/
ckeditor-4.5.6+dfsg'
dh_clean
rm -f -r dev/builder/_build builtsamples
make[1]: Leaving directory '/home/lamby/temp/cdt.20160211091323.3ap86cQP05/
ckeditor-4.5.6+dfsg'
 debian/rules build
dh build
   dh_testdir
   dh_update_autotools_config
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/home/lamby/temp/cdt.20160211091323.3ap86cQP05/
ckeditor-4.5.6+dfsg'
dh_auto_build
cd dev/builder \
&& ckbuilder --no-zip --no-tar --overwrite \
--version="4.5.6" --revision="1" \
--build ../../ _build
/usr/bin/ckbuilder: 1: /usr/bin/ckbuilder: PK^C^D: not found
/usr/bin/ckbuilder: 2: /usr/bin/ckbuilder: Syntax error: Unterminated quoted 
string
debian/rules:19: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/home/lamby/temp/cdt.20160211091323.3ap86cQP05/
ckeditor-4.5.6+dfsg'
debian/rules:12: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2



-- 
Cheers,
 Dmitry Smirnov.

---

The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- Friedrich Nietzsche



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

Bug#814222: openslide 3.4.1 is out

[Benjamin Gilbert]

On Thu, Feb 11, 2016 at 08:20:38AM +0100, Andreas Tille wrote:
> If you like to sneak a bit into Debian packaging and update the files in
> Git/SVN (just tell me your preference) I'd consider this a nice solution.

I'm willing to maintain the Debian package if necessary, but if there's a
feasible alternative I'd like to pursue that first.  IMO it provides a
useful sanity check on the package when upstream and downstream are
different people.  If someone else in the OpenSlide user community would be
willing to maintain the package, would you be open to mentoring them through
the MoM process?

Thanks!

Bug#814475: nmu: vtk-dicom_0.7.1-1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu vtk-dicom_0.7.1-1 . ANY . unstable . -m "Rebuild against gdcm 2.6.3"

The maintainer uploaded binaries were sitting in NEW for a long time.
Requesting ANY instesd of amd64 due to M-A: same packages.


Andreas

Bug#814474: RM: fpc-2.6.4 [all] -- RoQA; obsolete arch:all package

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

please decruft fpc-2.6.4 manually, this should unlock automatic
decrufting of the obsolete arch:any packages built from src:fpc
(which is now at version 3.0 in sid).


Andreas

Bug#814183: openmpi 1.10.2 is broken on powerpc

[Emilio Pozuelo Monfort]

On Tue, 9 Feb 2016 21:49:29 +0200 Graham Inggs  wrote:
> Petsc rebuilt successfully [1] a couple of hours ago on poulenc.d.o. [2].
> My previous tests were done on partch.d.o. [3].  Partch has 2GB of RAM
> vs Poulenc's 5GB, I don't know if this is significant.

aces3 failed on powerpc-osuosl-01.

poulenc is a PPC970FX
patch is a POWER7
powerpc-osuosl-01 is a POWER8

Dunno if that is relevant.

Cheers,
Emilio

Bug#814473: elpa: FTBFS: find: '/usr/share/libtool/config/ltmain.sh': No such file or directory

[Andreas Beckmann]

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

elpa FTBFS everywhere on the buildds:

https://buildd.debian.org/status/package.php?p=elpa&suite=unstable
https://buildd.debian.org/status/fetch.php?pkg=elpa&arch=i386&ver=2015.05.001-1&stamp=1454891876

 debian/rules build-arch
dh build-arch --with autoreconf
   dh_testdir -a
   dh_update_autotools_config -a
   debian/rules override_dh_autoreconf
make[1]: Entering directory '/«PKGBUILDDIR»'
dh_autoreconf --as-needed
find: '/usr/share/libtool/config/ltmain.sh': No such file or directory
dh_autoreconf: find /usr/share/libtool/config/ltmain.sh . ! -ipath "./debian/*" 
-a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' -o -path 
'*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} \; > 
debian/autoreconf.before returned exit code 1
debian/rules:14: recipe for target 'override_dh_autoreconf' failed
make[1]: *** [override_dh_autoreconf] Error 2
make[1]: Leaving directory '/«PKGBUILDDIR»'
debian/rules:11: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2


I cannot reproduce this in a sid pbuilder environment.


Andreas

Bug#814471: ERROR 404: Not Found.

[積丹尼 Dan Jacobson]

Package: flashplugin-nonfree
Version: 1:3.6.1+b1
File: /usr/sbin/update-flashplugin-nonfree

# update-flashplugin-nonfree --install --verbose
options :  --install --verbose --
temporary directory: /tmp/flashplugin-nonfree.M7xWxtUhRv
importing public key ...
selected action = --install
installed version = 11.2.202.559
upstream version = 11.2.202.569
wgetoptions= -nd -P .   -v --progress=dot:default 
downloading 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.569.sha512.i386.pgp.asc
 ...
URL transformed to HTTPS due to an HSTS policy
--2016-02-12 07:06:08--  
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.569.sha512.i386.pgp.asc
Resolving people.debian.org (people.debian.org)... 5.153.231.30, 
2001:41c8:1000:21::21:30
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:443... 
connected.
HTTP request sent, awaiting response... 404 Not Found
2016-02-12 07:06:10 ERROR 404: Not Found.

wget failed to download 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.569.sha512.i386.pgp.asc
downloading 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.i386.pgp.asc
 ...
URL transformed to HTTPS due to an HSTS policy
--2016-02-12 07:06:10--  
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.i386.pgp.asc
Resolving people.debian.org (people.debian.org)... 5.153.231.30, 
2001:41c8:1000:21::21:30
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 1248 (1.2K) [text/plain]
Saving to: ‘./fp10.sha512.i386.pgp.asc’

 0K . 100% 2.03M=0.001s

2016-02-12 07:06:11 (2.03 MB/s) - ‘./fp10.sha512.i386.pgp.asc’ saved [1248/1248]

verifying PGP fp10.sha512.i386.pgp.asc ...
copying 
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.i386.tar.gz ...
verifying checksum install_flash_player_11_linux.i386.tar.gz ...
wgetoptions= -nd -P .   -v --progress=dot:default  -O 
/tmp/flashplugin-nonfree.M7xWxtUhRv/install_flash_player_11_linux.i386.tar.gz
downloading 
https://fpdownload.adobe.com/get/flashplayer/pdc/11.2.202.559/install_flash_player_11_linux.i386.tar.gz
 ...
verifying checksum install_flash_player_11_linux.i386.tar.gz ...
unpacking install_flash_player_11_linux.i386.tar.gz ...
verifying checksum contents of install_flash_player_11_linux.i386.tar.gz ...
moving libflashplayer.so to /usr/lib/flashplugin-nonfree ...
setting permissions and ownership of 
/usr/lib/flashplugin-nonfree/libflashplayer.so ...
Flash Player version: 11.2.202.559
moving install_flash_player_11_linux.i386.tar.gz to 
/var/cache/flashplugin-nonfree ...
flash-mozilla.so - auto mode
  link best version is /usr/lib/flashplugin-nonfree/libflashplayer.so
  link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so
  link flash-mozilla.so is /usr/lib/mozilla/plugins/flash-mozilla.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
calling update-alternatives ...
flash-mozilla.so - auto mode
  link best version is /usr/lib/flashplugin-nonfree/libflashplayer.so
  link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so
  link flash-mozilla.so is /usr/lib/mozilla/plugins/flash-mozilla.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
removing /usr/bin/flash-player-properties
removing /usr/share/applications/flash-player-properties.desktop
removing /usr/share/icons/hicolor/16x16/apps/flash-player-properties.png
removing /usr/share/icons/hicolor/22x22/apps/flash-player-properties.png
removing /usr/share/icons/hicolor/24x24/apps/flash-player-properties.png
removing /usr/share/icons/hicolor/32x32/apps/flash-player-properties.png
removing /usr/share/icons/hicolor/48x48/apps/flash-player-properties.png
removing /usr/share/pixmaps/flash-player-properties.png
installing /usr/bin/flash-player-properties
installing /usr/share/applications/flash-player-properties.desktop
installing /usr/share/icons/hicolor/16x16/apps/flash-player-properties.png
installing /usr/share/icons/hicolor/22x22/apps/flash-player-properties.png
installing /usr/share/icons/hicolor/24x24/apps/flash-player-properties.png
installing /usr/share/icons/hicolor/32x32/apps/flash-player-properties.png
installing /usr/share/icons/hicolor/48x48/apps/flash-player-properties.png
installing /usr/share/pixmaps/flash-player-properties.png
end of action --install
cleaning up temporary directory /tmp/flashplugin-nonfree.M7xWxtUhRv ...
end of update-flashplugin-nonfree

Bug#814472: RM: default-jdk-doc [all] -- RoQA; obsolete arch:all package

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

please decruft default-jdk-doc:all, this is now a arch:any package.


Andreas

Bug#814470: nmu: shibboleth-resolver_1.0.0-1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu shibboleth-resolver_1.0.0-1 . ANY . unstable . -m "Rebuild against the 
libstdc++ v5 transitioned shibboleth stack."

This doesn't seem to export any symbols affected by the libstdc++ v5
transition (but it needs several of them), so a binNMU should be
sufficient in this case, no rename required.


Andreas

Bug#814469: bootstrap-vz runs into a TypeError on Jessie

[kellerfuchs]

Package: bootstrap-vz
Version: 0.9.0-1
Severity: important

Dear Maintainer,

bootstrap-vz throws a TypeError on jessie while trying to build an image.
The version from git (commit 790f2d66bba2eaff5dddc57a84d388e7dd45ed55) works
  without any issue.

I'm not writing from the system I encountered the problem on, hence the
  deletion of the system information;  the enclosed info should be enough
  to localise the problem.


> sudo bootstrap-vz ebs-jessie-amd64-hvm.yml
>  

Traceback (most recent call last):
  File "/usr/local/bin/bootstrap-vz", line 9, in 
load_entry_point('bootstrap-vz==0.9.0', 'console_scripts', 'bootstrap-vz')()
  File "/usr/local/lib/python2.7/dist-packages/bootstrapvz/base/main.py", line 
33, in main
run(opts)
  File "/usr/local/lib/python2.7/dist-packages/bootstrapvz/base/main.py", line 
63, in run
manifest = Manifest(opts['MANIFEST'])
  File "/usr/local/lib/python2.7/dist-packages/bootstrapvz/base/manifest.py", 
line 24, in __init__
self.load()
  File "/usr/local/lib/python2.7/dist-packages/bootstrapvz/base/manifest.py", 
line 42, in load
provider_modname = 'bootstrapvz.providers.' + self.data['provider']
TypeError: cannot concatenate 'str' and 'dict' objects


> cat ebs-jessie-amd64-hvm.yml

---
name: 
debian-{system.release}-{system.architecture}-{provider.virtualization}-{%Y}-{%m}-{%d}-ebs
provider:
  name: ec2
  virtualization: hvm
  enhanced_networking: simple
  description: Debian {system.release} {system.architecture}
bootstrapper:
  workspace: /target
  tarball: true
  sources:
docker:
  - deb https://apt.dockerproject.org/repo debian-jessie main
  include_packages:
- apt-transport-https
- ca-certificates
- docker-engine
  trusted_keys:
- keys/docker.asc
system:
  release: jessie
  architecture: amd64
  bootloader: extlinux
  charmap: UTF-8
  locale: en_US
  timezone: UTC
volume:
  backing: ebs
  partitions:
type: none
root:
  filesystem: ext4
  size: 8GiB
packages:
  mirror: http://cloudfront.debian.net/debian
plugins:
  cloud_init:
metadata_sources: Ec2
username: admin

Bug#775578: systemd kills spamassassin on system start

[Michael Biebl]

Control: tags -1 + moreinfo

On Sat, 17 Jan 2015 09:08:32 -0800 James Bottomley
 wrote:
> Package: systemd
> Version: 215-8
> Severity: normal
> 
> Almost every time the system reboots, spamassassin fails to start.  The 
> systemd logs for this are:
> 
> # systemctl status -l spamassassin.service
> ● spamassassin.service - Perl-based spam filter using text analysis
>Loaded: loaded (/lib/systemd/system/spamassassin.service; enabled)
>Active: failed (Result: timeout) since Sat 2015-01-17 08:49:04 PST; 3min 
> 45s ago
>   Process: 528 ExecStart=/usr/sbin/spamd -d 
> --pidfile=/var/run/spamassassin.pid $OPTIONS (code=killed, signal=TERM)
> 
> Jan 17 08:48:10 bedivere spamd[528]: logger: removing stderr method
> Jan 17 08:49:04 bedivere systemd[1]: spamassassin.service start operation 
> timed out. Terminating.
> Jan 17 08:49:04 bedivere systemd[1]: Failed to start Perl-based spam filter 
> using text analysis.
> Jan 17 08:49:04 bedivere systemd[1]: Unit spamassassin.service entered failed 
> state.
> Jan 17 08:49:04 bedivere spamd[748]: spamd: server killed by SIGTERM, 
> shutting down
> Jan 17 08:49:04 bedivere spamd[748]: spamd: cannot unlink 
> /var/run/spamassassin.pid: No such file or directory
> 
> This server is still x86 and a big internet system, so it has lots of
> intensive processes on start, like fail2ban , clamd and apache.  It
> looks like because of this, systemd gives spamassassin a few seconds
> (there's no log of how long; the logger message is from the pre-reboot
> os) to start and it takes longer.
> 
> As far as I can tell, this value doesn't seem to be configurable or
> even package specific.  It looks remarkably silly for the init system
> to impose an absolute timeout on service start, particularly when it
> doesn't take into account the characteristics of the machine or ask
> the package how long it might reasonably take.
> 
> So far, it's only spamassassin, so it's annoying but not serious to
> have to log in and restart it after every reboot.  However, if systemd
> did this to a necessary service, it would become a serious bug

Can you provide instructions how this issue can be reproduced?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#813398: Uploaded

[Ryan Kavanagh]

Dear Leo,

I uploaded a fixed package this morning and received an email confirming that it
had been processed, though, oddly, I still haven't received an email from the
archive confirming it had been accepted. It should appear shortly I hope.

Best,
Ryan

-- 
|_)|_/  Ryan Kavanagh   | Debian Developer
| \| \  http://ryanak.ca/   | GPG Key 4A11C97A

Bug#814468: nmu: gnss-sdr_0.0.6-1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu gnss-sdr_0.0.6-1 . i386 . unstable . -m "Rebuild against gnuradio 3.7.9.1"

this was sitting in NEW for several months ...


Andreas

Bug#814467: python-urllib3-whl: depends on removed python-six-whl

[Andreas Beckmann]

Package: python-urllib3-whl
Version: 1.13.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

your package depends on python-six-whl which is no longer built by src:six.
python-urllib3-whl will become uninstallable once this gets decrufted from sid.


Cheers,

Andreas

Bug#806595: aptitude: Changelog download throws warning: "W: Can't drop privileges for downloading as file …"

[Ben Finney]

Control: found -1 aptitude/0.7.5-3
Control: retitle -1 aptitude: Changelog download throws warning: "W: Can't drop 
privileges for downloading as file …"

On 05-Dec-2015, Manuel A. Fernandez Montecelo wrote:

> That's because libapt attempts to drop privileges and perform
> operations as "_apt" user, but since the directory is owned by root,
> it cannot drop them (otherwise it would fail to write) and emits the
> warning.

That seems to imply that one solution is to set the ownership of the
temporary directory to “_apt:root”. Yes?

=
$ sudo aptitude changelog apt > /dev/null
W: Can't drop privileges for downloading as file 
'/tmp/aptitude-root.1524:QANJmE/aptitudeDownload6J+8J:+PsVGmTNm^.^::Lz:%.Hi55VKA'
 couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
=

> >% aptitude changelog apt > /dev/null
> >W: chmod 0700 of directory /var/lib/apt/lists/partial failed - 
> >SetupAPTPartialDirectory (1: Operation not permitted)
> >W: chmod 0700 of directory /var/cache/apt/archives/partial failed - 
> >SetupAPTPartialDirectory (1: Operation not permitted)
> 
> I suppose that as normal user, libapt doesn't do the check mentioned
> above (perhaps because uid!=root and assumes that it's "_apt").
> 
> In my system, both dirs' permissions are 700 and owned by _apt:root, it
> doesn't emit any error and changelog works fine, no warnings.

On this system, both directories are permissions 700 and owned by
“_apt:root”, just as you describe. Yet on this system the warnings occur:

=
$ ls -ld /var/lib/apt/lists/partial/ /var/cache/apt/archives/partial/
drwx-- 2 _apt root 20480 Feb 12 09:07 /var/cache/apt/archives/partial/
drwx-- 2 _apt root 12288 Feb 12 08:55 /var/lib/apt/lists/partial/

$ aptitude changelog apt > /dev/null
W: chmod 0700 of directory /var/lib/apt/lists/partial failed - 
SetupAPTPartialDirectory (1: Operation not permitted)
W: chmod 0700 of directory /var/cache/apt/archives/partial failed - 
SetupAPTPartialDirectory (1: Operation not permitted)
=

There must be some extra difference, more than the ownership or
permission of those directories.

-- 
 \   “As far as the laws of mathematics refer to reality, they are |
  `\not certain, and as far as they are certain, they do not refer |
_o__)  to reality.” —Albert Einstein, 1983 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#814011: yoshimi: FTBFS with gcc-6: multiple errors

[Will Godfrey]

The current 'master' has bugfixes that should clear these. However I haven't
issued a bugfix release as we will probably release V 1.3.9 long before GCC 6
becomes a done-deal, and I don't want to create unnecessary churn.

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.

Bug#814466: pithos: playback resumes on return from screensaver even when paused for other reasons

[Brian Ristuccia]

Package: pithos
Version: 0.3.17-3
Severity: normal

If the preferences option "Pause when screensaver is active" has been checked
and music has been paused via the pause control, sometimes music playback
resumes when returning from the screensaver. Playback should only resume on
return from the screensaver if music was playing when the screensaver
activated.



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

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

Versions of packages pithos depends on:
ii  gstreamer0.10-plugins-bad   0.10.23-7.4
ii  gstreamer0.10-plugins-good  0.10.31-3+nmu4+b1
ii  python  2.7.9-1
ii  python-dbus 1.2.0-2+b3
ii  python-gobject  3.14.0-1
ii  python-gst0.10  0.10.22-3
ii  python-gtk2 2.24.0-4
ii  python-keybinder0.3.0-3
ii  python-notify   0.1.1-4
ii  python-xdg  0.25-4

pithos recommends no packages.

pithos suggests no packages.

-- no debconf information

Bug#814465: grub-pc: grub fails to boot "partition not recognized" on upgrade to 2.02~beta2-36

[Joe Public]

Package: grub-pc
Version: 2.02~beta2-36
Severity: important

Dear Maintainer,

Upgrading to grub 2.02~beta2-36 seemed successful, "Installation finished. No
error reported." followed by a listing of the kernels installed and then
"done".

But on reboot, instead of the usual grub menu, there was only a message
"Partition not recognized" and the grub-rescue prompt.  Grub-rescue commands
like "insmod normal" failed with "Partition not recognized."

Booting the system from rescue CD and downgrading grub to 2.02~beta2-22+deb8u1
worked perfectly on reboot, so the problem may have been something in the new
version.

For what it's worth this is debian testing on a thinkpad edge with a Hitachi
Travelstar Z7K320 320GB (2.5") hard drive partitioned into an ext4 and a swap
partition.

Peace,

Joe Public



-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sdc1 /media/joe/E4D0-414A vfat 
rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,showexec,utf8,flush,errors=remount-ro
 0 0
/dev/sdb1 /media/joe/My\040Passport fuseblk 
rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
55594683-61f6-4b57-99da-c1d418455040
else
  search --no-floppy --fs-uuid --set=root 55594683-61f6-4b57-99da-c1d418455040
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
55594683-61f6-4b57-99da-c1d418455040
else
  search --no-floppy --fs-uuid --set=root 55594683-61f6-4b57-99da-c1d418455040
fi
insmod png
if background_image /usr/share/images/desktop-base/lines-grub.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-55594683-61f6-4b57-99da-c1d418455040' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
55594683-61f6-4b57-99da-c1d418455040
else
  search --no-floppy --fs-uuid --set=root 
55594683-61f6-4b57-99da-c1d418455040
fi
echo'Loading Linux 4.4.1-xanmod4 ...'
linux   /boot/vmlinuz-4.4.1-xanmod4 
root=UUID=55594683-61f6-4b57-99da-c1d418455040 ro  quiet

Bug#814464: tweepy: Upstream Test Suite is disabled

[Ross Gammon]

Source: tweepy
Version: 3.4.0-1
Severity: wishlist

Dear Maintainer,

I have just finished packaging 3.5.0 of tweepy, and I have disabled the
upstream tests in order to close an RC bug and prevent the reverse dependencies
from being removed from testing.

Once the Python 2 & # versions of unittest2, vcr & nose are added as build
dependencies, the build fails because the tests require internet access (which
is not allowed when building Debian packages).

It would be good to alter the tests so that if there is no internet access, the
tests are skipped instead of failed.

Regards,

Ross



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

Kernel: Linux 3.16.0-4-amd64 (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/dash
Init: systemd (via /run/systemd/system)

Bug#814267: gosa: annoying warning on each login with debian-edu

[Mike Gabriel]

Hi Holger,

On  Di 09 Feb 2016 20:47:05 CET, Holger Levsen wrote:


package: gosa
severity: important
version: 2.7.4+reloaded2-1+deb8u1
x-debbugs-cc: debian-...@lists.debian.org

On Montag, 7. September 2015, Wolfgang Schweer wrote:

One drawback: each time logging into the GOsa² web gui a misleading (and
annoying) warning pops up stating that the configuration has changed.
just click it away as Debian Edu isn't concerned. (This is due to gosa
package version 2.7.4+reloaded2-1+deb8u1 fixing a bug concerning default
Debian gosa installs.)

Edit the line containing the config version in /etc/gosa/gosa.conf
(head of the file) to look like this:


 will be OK as well.

The message won't appear any more.


It would be more than nice to have this fixed for our Debian Edu Jessie
release.


cheers,
Holger


For GOsa, I have a patch in the pipeline candidate for a jessie-pu:
http://anonscm.debian.org/cgit/debian-edu/pkg-team/gosa.git/commit/?h=debian/jessie/updates&id=3cd550d0ba36bff7106b9ae6f477f9571ab86535

For debian-edu-config, this is already addressed in Git, too:
http://anonscm.debian.org/cgit/debian-edu/debian-edu-config.git/commit/?h=jessie&id=a796ac7f3e3cf3775465340ab0d9f3e009d81878

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de


pgpppuZ8MIgac.pgp
Description: Digitale PGP-Signatur

Bug#814463: irker: does not start when /dev/log and /var/run/syslog exist

[Neil Muller]

fixed irker/2.13+dfsg-1
thank you


This bug was fixed upstream before the 2.13 release - See
https://gitlab.com/esr/irker/commit/5fe9b5a2c54bfd13cade0fd2d412768a0fe5e3bf

This bug can also be worked around by specifying a logfile for irkerd,
for what it's worth.

Bug#814458: I'll fix it in next upload

[Pirate Praveen]

Thanks for the report. This is because of the following line,

echo "Initializing database..."
su ${gitlab_user} -s /bin/sh -c 'bundle exec rake gitlab:setup
RAILS_ENV=production force=yes'

I will remove that force=yes (created during the testing phase, but
never gotten to remove it).

Also because package update case is still in todo list
https://gitlab.com/debian-ruby/TaskTracker/issues/52



signature.asc
Description: OpenPGP digital signature

Bug#514005: Patch available

[Thomas Klute]

I have a patch for this problem in my development repository [1], the
fix will be included in mod_gnutls 0.7.3 (to be released soon).

[1]
https://github.com/airtower-luna/mod_gnutls/commit/8ac7c0dbd1357a8acadafc2aab8568bdebe7ae8f

Bug#814463: irker: does not start when /dev/log and /var/run/syslog exist

[rohieb]

Package: irker
Version: 2.12+dfsg-1
Severity: normal

Dear Maintainer,

lines 989-993 of `/usr/bin/irkerd' look like this:

logdev = [x for x in ('/dev/log', '/var/run/syslog', '/var/run/log')
  if os.path.exists(x)]
if len(logdev) != 1:
sys.stderr.write("can't initialize log device, bailing out!\n")
raise SystemExit(1)

However, on my host running jessie and systemd, both /dev/log and /var/run/log
exist:

  $ ls -ld '/dev/log' '/var/run/syslog' '/var/run/log'
  ls: cannot access /var/run/syslog: No such file or directory
  lrwxrwxrwx 1 root root 28 Jun 22  2015 /dev/log -> 
/run/systemd/journal/dev-log
  drwxr-xr-x 3 root root 60 Jun 22  2015 /var/run/log

As a result, irker exits with the respective failure message right after it has
been started.

A trivial patch, which forks for me, is attached.

Cheers, 
 - Roland


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

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

Versions of packages irker depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
pn  python:any   

irker recommends no packages.

irker suggests no packages.

-- no debconf information
--- /home/rohieb/irkerd.orig	2016-02-11 21:35:18.90800 +0100
+++ /usr/bin/irkerd	2016-02-11 21:35:52.89600 +0100
@@ -988,7 +988,7 @@
 # The Linux, Mac, and FreeBSD values of the logging device.
 logdev = [x for x in ('/dev/log', '/var/run/syslog', '/var/run/log')
   if os.path.exists(x)]
-if len(logdev) != 1:
+if len(logdev) < 1:
 sys.stderr.write("can't initialize log device, bailing out!\n")
 raise SystemExit(1)
 # There's a case for falling back to address = ('localhost', 514)

Bug#814462: ITP: codecrypt -- Post-quantum encryption and signing tool.

[Mirek Kratochvil]

Package: wnpp
Severity: wishlist
Owner: Mirek Kratochvil 

* Package name: codecrypt
  Version : 1.7.3
  Upstream Author : Mirek Kratochvil 
* URL : https://github.com/exaexa/codecrypt
* License : LGPLv3
  Programming Lang: C++
  Description : Post-quantum encryption and signing tool.

Codecrypt is a quantum-computer-resistant cryptography tool that can be used
to encrypt, decrypt, sign and verify documents and communications in a manner
similar to GnuPG or PGP.

Several users requested inclusions of the software in Debian; the packages
are already available (from ./build-debian-package.sh), working & passing
lintian checks.

Bug#808593: [Help]: Bug#808593: htsjdk: FTBFS: [testng] FAILED: testHTTPNotExist

[Emmanuel Bourg]

Le 11/02/2016 21:01, Andreas Tille a écrit :

> any hint why this test that worked before might fail since end of
> December?

I got a quick look and I can't explain this test failure. It doesn't
seem very important though, you could just disable this test.

Emmanuel Bourg

Bug#794945: drivers: Sense Key Medium Error in 8.1 not in 7 for same media

[Ernest Sales]

I am no longer running into this issue for some time now. Checking two
media that failed earlier confirms the error is gone.

Actually, Jessie has bumped two point versions since the bug report:
$ cat /etc/debian_version 
8.3
Moreover I am running kernel from backports:
$ uname -a
Linux [...] 4.3.0-0.bpo.1-amd64 #1 SMP Debian 4.3.3-7~bpo8+1
(2016-01-19) x86_64 GNU/Linux

So my hearty thanks to someone and, as far as I am concerned, this bug
is solved.

Ernest

Bug#814461: base: system stops responding after it falls asleep, in all flavors and no set time.

[Jim Cote]

Package: base
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

 Every time the laptop goes into screensaver or sleep it stops reponding.
I have waited up to 10 min for it to repond - so i have to reboot it.


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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)

Bug#809685: lvm2 on sparc64 = bus error

[Anatoly Pugachev]

On Tue, Feb 9, 2016 at 10:58 PM, John Paul Adrian Glaubitz
 wrote:
>
> On 02/09/2016 08:15 PM, Anatoly Pugachev wrote:
> > continue from https://bugs.debian.org/809685
>
> You don't have to mention the previous bug report here, your
> message is automatically appended to the existing bug report
> the moment you CC the bug report's address :).
>
> > if I get lvm2 source from git , compile and try to run , there's no "bus 
> > error":
> > (...)
> > root@deb4g:/mnt/1/lvm2# tools/lvm version
> >   LVM version: 2.02.142(2)-git (2016-01-25)
> >   Library version: 1.02.116-git (2016-01-25)
> >   Driver version:  4.34.0
>
> Interesting. Can you post the version numbers for lvm2 taken from
> the Debian package? I have had a look at the lvm2 git repository
> and there don't seem be any big changes after 2.02.142 which
> could cause this issue. If we can pinpoint the change that fixed
> the bug, we could just cherry-pick the necessary patch.


upstream commit
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=0baf66a992fbac92fa2c30e9bb8e74a5535ff45a

pulling latest git source code for lvm2 , compiling with debian
./configure options (taken from last lvm2 package log from
https://buildd.debian.org/status/fetch.php?pkg=lvm2&arch=sparc64&ver=2.02.141-2&stamp=1454711070
) and running , does not return bus error.

PS: thanks for fix to Zdenek Kabelac 

Bug#814450: [Debian-ha-maintainers] Bug#814450: Bug#814450: pcs: FTBFS: install: omitting directory 'pcs/'

[Ferenc Wágner]

Christoph Berg  writes:

> IMHO the best fix would be to move /usr/lib/$ARCH/pacemaker to
> /usr/lib/pacemaker in the pacemaker package

We can do that, I'm butchering up the pacemaker package anyway.

> (Multi-Arch for programs doesn't work anyway),

(And the pacemaker package is not multi-arch for that reason.)

> and then simply use a fixed path in pcs and crmsh

I'm mildly surprised.  What do those shells do in /usr/lib/()/pacemaker?
Those sub-executables are hardly part of the external interface...  At
least I've never thought they could be.
-- 
Regards,
Feri.

Bug#814460: alot: please package new upstream release 0.3.7

[Jonas Smedegaard]

Package: alot
Version: 0.3.6-1
Severity: wishlist
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As subject says, please package new upstream release 0.3.7.

It depends on python-setuptools and (separately packaged)
python-urwidtrees, and unfuzzing of the one Debian patch, but seems to
need no other adaptations for the Debian packaging.


 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWvOw9AAoJECx8MUbBoAEh6qAQAIrpW/pTpoJ3K/iWb9GdvNA/
n1/3keKFQb4bMzTfhaRAcAImov0Vv8noMl4H8UfCn87UQEwKXFS9pFwMG0IPTEGV
LxzWuenf7Mqq2tYeUViBw8oaMHedE0sgyDSmokY8fQi+qLiewym2TfaHi3O01RAj
reyjmov7zRpb+NoBYW5xwBk+4rHFNcXcWLDbVFBz7RKnZ3I7VzUh0GQe+Rshhtan
UMeCsktUUqgjDuxZQCCODHLePDyEUQVAyhJYPvewH1UUPn46uo5menNLhnvoqeZB
zac8GWMRe76YpflehU+9orwM9DnEjhMRDTc0iA9w6zgh2JZ9uPoffPX9YckvCzqm
pfFTa2d2UD7h7O4dXF6cwzAs/X3ZhlyXnV+0y3d+WPm1/ZwWHa7/Us6nfXsnMMZs
unfPxqFBwgsWD+8K8aJhNWmmuCs0h0y4MnXEY8m10T+lYuTB0dPS6vZ7Hu3MHmns
jo1Z8Ir2IQIFZnW986A5mZYpANTHVQviVh0EXK3DIy6osPnkCcO07V6h1gMY6CJc
KO4ZFXVt7ZhO9YbEFIIjFpUXwUQtAyByeWQjT3Nlx8vpbclyKWz76AbxzlYc/B6i
fQ9mhTf+gANZrP8yWkCXdJxdA1QbXAPgPHfQyCy/r+Lz+x0Zzb3W9XsCMdeE/5da
0AXW/lNGfHnSCH9Oquyi
=bDdU
-END PGP SIGNATURE-

Bug#750586: syslinux-common: Boot fails. Failed to load ldlinux.c32. File must be in /. Upstream bug

[Christian Seiler]

Control: tags -1 + patch

Hi,

I've investigated this bug a bit because of a posting to debian-user@;
the original fix that went into Jessie fixes the netboot.tar.gz images.
The problem is that the installer data in the mirror doesn't contain
ldlinux.c32.

(For a more detailed analysis of the problem that I posted to
debian-user, see [1].)

Additionally, the default pxelinux.0 image from jessie onwards doesn't
support HTTP via gPXE/iPXE anymore, it only supports TFTP. So directly
using a HTTP mirror for PXE booting with gPXE/iPXE is possible up to
Wheezy, but not possible starting with Jessie anymore. I've reported
this against pxelinux as:


But there is an alternative image, lpxelinux.0, which implements HTTP
directly (and doesn't call out to gPXE/iPXE) that may be used instead
of pxelinux.0; it's already included in the pxelinux package from
Jessie onwards.

I've attached a patch against d-i git master that adds the ldlinux.c32
and lpxelinux.0 files to the mirror itself (and not just to the
netboot.tar.gz as before).

I verified that a Jessie installer created in a clean pbuilder
environment with that patch applied works as expected and has
ldlinux.c32 as well as lpxelinux.0 in both netboot.tar.gz files as
well as the mirror file system proper.

It would be great if this patch could be applied not only to Stretch
but also be part of the next point release in Jessie, so that booting
the Jessie installer directly from HTTP works again.

Thanks!

Regards,
Christian

[1] https://lists.debian.org/debian-user/2016/02/msg00295.html
From dd2670702f183b77037060f32255b7449a5d2ed6 Mon Sep 17 00:00:00 2001
From: Christian Seiler 
Date: Thu, 11 Feb 2016 20:31:46 +0100
Subject: [PATCH] Add ldlinux.c32 and lpxelinux.0 to netboot files on mirrors

Closes: #750586
---
 build/config/amd64/netboot-gtk.cfg | 2 +-
 build/config/amd64/netboot.cfg | 2 +-
 build/config/i386/netboot-gtk.cfg  | 2 +-
 build/config/i386/netboot.cfg  | 2 +-
 build/config/x86.cfg   | 2 ++
 5 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/build/config/amd64/netboot-gtk.cfg b/build/config/amd64/netboot-gtk.cfg
index 4a88b6a..900c158 100644
--- a/build/config/amd64/netboot-gtk.cfg
+++ b/build/config/amd64/netboot-gtk.cfg
@@ -1,7 +1,7 @@
 MEDIA_TYPE = netboot image
 
 NETBOOT_DIR_TARGETS = $(TEMP_INITRD) $(TEMP_KERNEL)
-NETBOOT_DIR_LINKS = pxelinux.0 pxelinux.cfg
+NETBOOT_DIR_LINKS = pxelinux.0 lpxelinux.0 ldlinux.c32 pxelinux.cfg
 
 TYPE = netboot/gtk
 
diff --git a/build/config/amd64/netboot.cfg b/build/config/amd64/netboot.cfg
index 706b7bb..c83225f 100644
--- a/build/config/amd64/netboot.cfg
+++ b/build/config/amd64/netboot.cfg
@@ -1,7 +1,7 @@
 MEDIA_TYPE = netboot image
 
 NETBOOT_DIR_TARGETS = $(TEMP_INITRD) $(TEMP_KERNEL)
-NETBOOT_DIR_LINKS = pxelinux.0 pxelinux.cfg
+NETBOOT_DIR_LINKS = pxelinux.0 lpxelinux.0 ldlinux.c32 pxelinux.cfg
 TARGET = $(NETBOOT_DIR) $(NETBOOT_TAR) $(MINIISO)
 EXTRANAME = $(MEDIUM)/
 
diff --git a/build/config/i386/netboot-gtk.cfg b/build/config/i386/netboot-gtk.cfg
index 144f2fe..570a871 100644
--- a/build/config/i386/netboot-gtk.cfg
+++ b/build/config/i386/netboot-gtk.cfg
@@ -1,7 +1,7 @@
 MEDIA_TYPE = netboot image
 
 NETBOOT_DIR_TARGETS = $(TEMP_INITRD) $(TEMP_KERNEL)
-NETBOOT_DIR_LINKS = pxelinux.0 pxelinux.cfg
+NETBOOT_DIR_LINKS = pxelinux.0 lpxelinux.0 ldlinux.c32 pxelinux.cfg
 
 TYPE = netboot/gtk
 
diff --git a/build/config/i386/netboot.cfg b/build/config/i386/netboot.cfg
index 706b7bb..c83225f 100644
--- a/build/config/i386/netboot.cfg
+++ b/build/config/i386/netboot.cfg
@@ -1,7 +1,7 @@
 MEDIA_TYPE = netboot image
 
 NETBOOT_DIR_TARGETS = $(TEMP_INITRD) $(TEMP_KERNEL)
-NETBOOT_DIR_LINKS = pxelinux.0 pxelinux.cfg
+NETBOOT_DIR_LINKS = pxelinux.0 lpxelinux.0 ldlinux.c32 pxelinux.cfg
 TARGET = $(NETBOOT_DIR) $(NETBOOT_TAR) $(MINIISO)
 EXTRANAME = $(MEDIUM)/
 
diff --git a/build/config/x86.cfg b/build/config/x86.cfg
index 998aed3..28ee614 100644
--- a/build/config/x86.cfg
+++ b/build/config/x86.cfg
@@ -354,6 +354,7 @@ arch_netboot_dir: x86_syslinux x86_grub_efi
 	cp $(TEMP_INITRD) $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)
 	cp $(TEMP_KERNEL) $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)/linux
 	cp /usr/lib/PXELINUX/pxelinux.0 $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)
+	cp /usr/lib/PXELINUX/lpxelinux.0 $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)
 	mkdir -p $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)/pxelinux.cfg
 	mkdir -p $(TEMP_NETBOOT_DIR)/$(BOOT_SCREEN_DIR)
 	cp /usr/lib/syslinux/modules/bios/vesamenu.c32 $(TEMP_NETBOOT_DIR)/$(BOOT_SCREEN_DIR)
@@ -395,6 +396,7 @@ arch_netboot_dir: x86_syslinux x86_grub_efi
 	# dhcp server setups to work without modification.
 	rm -f $(TEMP_NETBOOT_DIR)/pxelinux.0
 	ln -sf $(NETBOOT_PATH)/pxelinux.0 $(TEMP_NETBOOT_DIR)/pxelinux.0
+	ln -sf $(NETBOOT_PATH)/lpxelinux.0 $(TEMP_NETBOOT_DIR)/lpxelinux.0
 	# This link is required because pxelinux only looks in the tftp root
 	# for this library (it does a PATH search for any others).
 	

Bug#808593: [Help]: Bug#808593: htsjdk: FTBFS: [testng] FAILED: testHTTPNotExist

[Andreas Tille]

Hi,

any hint why this test that worked before might fail since end of
December?

Kind regards

 Andreas.

On Mon, Dec 21, 2015 at 10:59:11AM +, Chris Lamb wrote:
> Source: htsjdk
> Version: 1.138+dfsg.1-4
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> htsjdk fails to build from source in unstable/amd64:
> 
>   [..]
> 
>  [testng] PASSED: testReadAndSkipWithMultipleBlocks([null of CHAR, null 
> of CHAR, null of FLOAT])
>  [testng] PASSED: testReadAndSkipWithMultipleBlocks([null of CHAR, null 
> of CHAR, null of CHAR])
>  [testng] FAILED: testHTTPNotExist
>  [testng] java.lang.AssertionError: expected [false] but found [true]
>  [testng] at org.testng.Assert.fail(Assert.java:94)
>  [testng] at org.testng.Assert.failNotEquals(Assert.java:496)
>  [testng] at org.testng.Assert.assertEquals(Assert.java:125)
>  [testng] at org.testng.Assert.assertEquals(Assert.java:288)
>  [testng] at org.testng.Assert.assertEquals(Assert.java:298)
>  [testng] at 
> htsjdk.tribble.util.ParsingUtilsTest.tstExists(ParsingUtilsTest.java:142)
>  [testng] at 
> htsjdk.tribble.util.ParsingUtilsTest.testHTTPNotExist(ParsingUtilsTest.java:137)
>  [testng] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>  [testng] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>  [testng] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  [testng] at java.lang.reflect.Method.invoke(Method.java:606)
>  [testng] at 
> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>  [testng] at 
> org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>  [testng] at 
> org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>  [testng] at 
> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>  [testng] at 
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
>  [testng] at 
> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>  [testng] at org.testng.TestRunner.privateRun(TestRunner.java:773)
>  [testng] at org.testng.TestRunner.run(TestRunner.java:623)
>  [testng] at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>  [testng] at 
> org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>  [testng] at 
> org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>  [testng] at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>  [testng] at 
> org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>  [testng] at 
> org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>  [testng] at 
> org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>  [testng] at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>  [testng] at org.testng.TestNG.run(TestNG.java:1018)
>  [testng] at org.testng.TestNG.privateMain(TestNG.java:1325)
>  [testng] at org.testng.TestNG.main(TestNG.java:1294)
>  [testng] 
>  [testng] SKIPPED: basic
>  [testng] org.testng.TestNGException: 
>  [testng] Method public void 
> htsjdk.samtools.util.IupacTest.basic(java.lang.String) throws 
> java.lang.Exception requires a @DataProvider named : basicDataProvider
>  [testng] at 
> org.testng.internal.Parameters.findDataProvider(Parameters.java:262)
>  [testng] at 
> org.testng.internal.Parameters.handleParameters(Parameters.java:418)
>  [testng] at 
> org.testng.internal.Invoker.handleParameters(Invoker.java:1276)
>  [testng] at 
> org.testng.internal.Invoker.createParameters(Invoker.java:992)
>  [testng] at 
> org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1082)
>  [testng] at 
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
>  [testng] at 
> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>  [testng] at org.testng.TestRunner.privateRun(TestRunner.java:773)
>  [testng] at org.testng.TestRunner.run(TestRunner.java:623)
>  [testng] at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>  [testng] at 
> org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>  [testng] at 
> org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>  [testng] at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>  [testng] at 
> org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:

Bug#811708: pong on update-rc.d

[Adam Borowski]

On Fri, Feb 12, 2016 at 12:47:09AM +0900, Benda Xu wrote:
> Thanks for the report.  update-rc.d in OpenRC is a hack based on that
> from sysv-rc.  I think the right way forward is to extend
> init-system-helpers to support OpenRC.

Great, that answers the question about which way to fix the bug.  This
wasn't a decision that should be done in a NMU without your input.

> I will try to figure it out.  If I couldn't make it in time, Svante's
> patch will be upload to close this bug.

The patch would require some fixing.  Note that the two versions do differ:
the first one overwritten existing postrm.  The second one still does some
stuff specific to file-rc.

But as you decided to go the other way, this matters only if we'd need to
use it as a fallback.

-- 
A tit a day keeps the vet away.

Bug#814450: [Debian-ha-maintainers] Bug#814450: pcs: FTBFS: install: omitting directory 'pcs/'

[Christoph Berg]

Re: Aaron M. Ucko 2016-02-11 
<145520979664.9622.11989946250615470307.report...@ghostwheel.internal.ucko.debian.net>
> Source: pcs
> Version: 0.9.148-1
> Severity: important
> Justification: fails to build from source
> 
> Builds of pcs for architectures other than amd64 all failed:
> 
>   install -m755 pcs/ 
> /«PKGBUILDDIR»/debian/tmp/usr/lib/python2.7/dist-packages/pcs/settings.py
>   install: omitting directory 'pcs/'
>   Makefile:85: recipe for target 'install' failed
> 
> It looks like the upstream makefile incorporates fragile logic that
> only attempts to support amd64 and i386, and mishandles the latter
> (failing to account for the fact that uname -m can and often does
> report a higher number, typically i686).  I'd suggest instead using a
> single template settings.py.in and arranging to substitute the value
> of dpkg-architecture -qDEB_HOST_MULTIARCH.  This template approach
> should also permit filling the version number in automatically, rather
> than having to hardcode it.

Hi,

thanks for the report.

IMHO the best fix would be to move /usr/lib/$ARCH/pacemaker to
/usr/lib/pacemaker in the pacemaker package (Multi-Arch for programs
doesn't work anyway), and then simply use a fixed path in pcs and
crmsh (which has exactly the same problem at run time).

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#812841: systemd checking was not foolproof

[Antonio Terceiro]

On Fri, Feb 12, 2016 at 12:12:40AM +0530, Pirate Praveen wrote:
> Control: found -1 gitlab/8.4.0+dfsg-2
> Control: forcemerge -1 814413
> 
> Since I had init=/bin/systemd in my /proc/cmdline, as I moved to systemd
> before it became default, the check in postinst was not correct. I will
> switch to checking in /proc/1/cmdline and upload.

note sure that is correct either. On my system I get

$ cat /proc/1/cmdline ; echo
/sbin/init

I think the correct way to test if the system is currently running
systemd if by checking if "/run/systemd/system" is an existing directory
i.e. `-d "/run/systemd/system"` in shell (that is how
/usr/sbin/update-rc.d does it).

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature

Bug#814459: pxelinux: doesn't use gPXE/iPXE anymore to load files

[Christian Seiler]

Package: pxelinux
Version: 3:6.03+dfsg-5
Severity: important
Tags: upstream

Dear Maintainer,

[ this is a regression from wheezy ]

pxelinux up to the version in wheezy supported loading files via upcalls
to gPXE/iPXE. For example, one could use gPXE/iPXE to load pxelinux via
HTTP, set a HTTP URI as the pxelinux prefix and pxelinux would be able
to load that URI because it could ask gPXE/iPXE to do that for itself.

With pxelinux 5.10 an own implementation for many network protocols was
now introduced, the binary 'lpxelinux.0' contains that implementation,
as opposed to 'pxelinux.0', which contains the legacy implementation.

Unfortunately, the current version of pxelinux in jessie, stretch and
sid doesn't support calling out to gPXE/iPXE any more from the legacy
implementation (there is source code for that still there, see
gpxe_open, but there's also #define GPXE 0 in core/fs/pxe/pxe.h because
the code doesn't actually compile any more); the legacy implementation
hence only supports TFTP now, and e.g. HTTP is not supported any more
with gPXE/iPXE.

I see three options:

 - fix this and reenable fetching files via gPXE/iPXE from the legacy
   'pxelinux.0'

 - completely drop the legacy version and make 'lpxelinux.0' the only
   implementation (and call it 'pxelinux.0' again)

 - document very _clearly_ that setups that aren't purely TFTP now have
   to use the newer 'lpxelinux.0'

Regards,
Christian

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

Kernel: Linux 4.3.0-0.bpo.1-amd64 (SMP w/8 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)

pxelinux depends on no packages.

Versions of packages pxelinux recommends:
ii  syslinux-common  3:6.03+dfsg-5+deb8u1

Versions of packages pxelinux suggests:
pn  tftpd-hpa  

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#813318: ibneon27-gnutls: Undefined symbol: gnutls_mac_set_priority

[GCS]

Control: tag -1 +unreproducible

Hi Mel, Antonio,

On Sun, Jan 31, 2016 at 4:16 PM, Mel Davis  wrote:
> Package: libneon27-gnutls
> Version: 0.30.1-3
> Severity: normal
[...]
> This morning, I ran 'apt full-upgrade'. The following is from the apt
> history:
[...]
> After the upgrade, I am unable to run mail.  The following is reported
> mail: symbol lookup error: /usr/lib/x86_64-linux-gnu/libmu_auth.so.4:
> undefined symbol: gnutls_mac_set_priority
>
>
> The problem could be with gnutls or with isc-dhcp, since both were updated.
> I'm unsure how to make that determination.
 I could not reproduce it in an up-to-date Stretch/amd64 install. If I
issue 'mail':
~# mail
No mail for root

Checking libmu_auth.so.4 is part of libmailutils4 and checking all
libs it linked with that and contains 'gnutls':
~# ldd /usr/lib/x86_64-linux-gnu/libmu_auth.so.4 | grep gnutls
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30
(0x7f8c6de9a000)

As such, it has nothing to do with libneon27-gnutls as that lib is
part of libgnutls30; which has symbols starting with gnutls_mac:
~# nm -D /usr/lib/x86_64-linux-gnu/libgnutls.so.30 | grep gnutls_mac
00050670 T gnutls_mac_get
000c8150 T gnutls_mac_get_id
000c81c0 T gnutls_mac_get_key_size
000c8060 T gnutls_mac_get_name
000c8200 T gnutls_mac_get_nonce_size
000c8240 T gnutls_mac_list
000c7fd0 T _gnutls_mac_to_entry

But not the mentioned gnutls_mac_set_priority one. Reading man
pages[1] shows that yes, it should be or simply was part of GnuTLS.
Why do you both think this bug is because of the neon update?

Cheers,
Laszlo/GCS
[1] http://man7.org/linux/man-pages/man3/gnutls_mac_set_priority.3.html

Bug#812782: dpkg: Please add

[Guillem Jover]

Hi!

On Fri, 2016-01-29 at 12:14:30 +0100, Bálint Réczey wrote:
> 2016-01-29 0:42 GMT+01:00 Guillem Jover :
> > On Tue, 2016-01-26 at 15:23:43 +0100, Balint Reczey wrote:
> > > For hardened1-* the major difference from the amd64 ABI is enabling ASAN
> > > and I will stick to that.
> > > I also #define __GNU_FEATURESET_HARDENED1__ in libc to let config.guess
> > > detect the gnuhardened1 variant, but this does not need changes in dpkg
> > > and will be upstreamed to GNU config project.
> >
> > I'd probably just define something that makes it clear that glibc is
> > being built with ASAN which implies that everything else needs to as
> > well. Perhaps something like __GNU_ASAN_ABI or __GLIBC_USING_ASAN or
> > something similar, although it would be nice to get glibc upstream
> > to decide or agree with such a macro so that it can be used by others?

> Originally I had this idea, too, but UBSAN is also enabled which may deserve
> its own flag. Since the ABI is defined by a set of features it seemed to be
> an even better solution to come up with a macro unique to this ABI.
> This makes the detection of the ABI much simpler in config.guess.
> I indeed will discuss that with upstream and settle on a solution satisfying 
> all
> parties. I the meantime using this unique macro seems to be one good solution.

Are UBSAN and TSAN really ABI changing features? But in any case yeah,
please get this upstreamed first.

> >> Many of the patches I'm filing enable sanitized rebuild of the amd64
> >> archive, but I think a separate port would be an ideal solution both for
> >> the Debian project and for our users.
> >
> > Perhaps, I'm still unsure about the actual demand of such thing, time
> > will tell, and OTOH we support ports with very low popcon numbers so…

> I would like to assess the demand in the coming weeks. If there is only very 
> few
> people interested I won't push it as an official port. I respect your
> and other's
> time more than pushing something that would not be used.

Well most of the time is in getting the details right, once that's
done there's not much to do from my side. :) And I'm afraid we are
already spending time getting the details right, which can only be
a good thing anyway. :)

In any case, thanks for canvassing if the port has support.

> >> >From 452b9127410427837428e75062cc9fa17633d974 Mon Sep 17 00:00:00 2001
> >> From: Balint Reczey 
> >> Date: Sun, 20 Sep 2015 19:24:23 +0200
> >> Subject: [PATCH 1/2] Add hardened1-linux- ports support
> >>
> >> Those ports ar based on simple  ports with a set of defaults
> >> changed to provide better security.

> >> diff --git a/ostable b/ostable
> >> index 10e0d3a..678196a 100644
> >> --- a/ostable
> >> +++ b/ostable
> >> @@ -23,6 +23,7 @@ gnuabi64-linux  linux-gnuabi64  
> >> linux[^-]*-gnuabi64
> >>  gnuspe-linux linux-gnuspelinux[^-]*-gnuspe
> >>  gnux32-linux linux-gnux32linux[^-]*-gnux32
> >>  gnu-linuxlinux-gnu   linux[^-]*(-gnu.*)?
> >> +gnuhardened1-linux   linux-gnuhardened1  linux[^-]*(-gnuhardened1.*)?
> >
> > Given that the thing defining the ABI difference here is the enabled
> > ASAN I think it would make more sense and be more clear to name the
> > GNU triplet something like «-linux-gnuasan». BTW why hardened_1_,
> > is this to prepare for a possible ABI break? That to me seems a bit
> > concerning?

> After if evolved like gnuasan -> gnuausan ->gnutausan->... in my private repo
> I just tried to pick something simple, unique enough and considered ASN.1 as
> an example of finding future-proof names. :-)
> I chose gnuhardened1 as the unique string to allow a gnuhardened2 port in case
> there is a very different, incompatible set of hardening features found and we
> also want to keep the old set as a port. I have no plans for hardened2 BTW,

It's a bit concerning that many of these features are ABI breaking (if
that is really the case for UBSAN and TSAN too, as I asked above, for
ASAN last time I looked around it was not very clear from the sparse
documentation I could find), because it means if some other new feature
appears that also breaks the ABI, we can either not use it or have to
create a new port, which seems very suboptimal.

> linux[^-]*(-gnuhardened.*)? without the _1_ would match ...hardened2, too,
> which would complicate things, too.

We can always just use an exact match, though. The 1 there just looks
very arbitrary and ugly to me. At least something like the MIPS R6
ports have a defined meaning.

Thanks,
Guillem

Bug#814443: apt: Unable to parse package file /var/lib/apt/lists/..._Packages (1)

[Julian Andres Klode]

Control: tag -1 moreinfo

On 11 February 2016 at 16:22, Vincent Lefevre  wrote:
> Package: apt
> Version: 1.2.3
> Severity: important
>
> Each time I do an "apt-get update", I get the error:
>
> [...]
> Reading package lists... Error!
> E: Unable to parse package file 
> /var/lib/apt/lists/ftp.fr.debian.org_debian_dists_unstable_contrib_binary-amd64_Packages
>  (1)
> W: You may want to run apt-get update to correct these problems
> E: The package cache file is corrupted
>
> There is no such problem on another machine, using the same mirror.
>
> And contrary to what is said, "apt-get update" does not correct
> these problems.
>

More details please. Save a backup of the file (and the InRelease
file), then delete it, and run update again. Send the broken file (and
InRelease) in, so we can look at it, or look at it yourself and see
if/how it is broken.


-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Bug#814431: tests fail on i386

[Lev Lamberov]

Hi Mattias,

11.02.2016 19:38, Matthias Klose пишет:
> Package: src:swi-prolog
> Version: 7.2.3-1
> Severity: serious
> Tags: sid stretch
>
> tests fail on i386:
>
> ERROR: /«PKGBUILDDIR»/packages/jpl/test_jpl.pl:1185:
> test threads3: received error: jpl:jFindClass/2: Undefined
> procedure: jpl:jni_func/3
> ERROR: /«PKGBUILDDIR»/packages/jpl/test_jpl.pl:1203:
> test jref1: received error: plunit_jpl:'unit body'/2: Undefined
> procedure: jpl:jni_term_to_jref/2
> ERROR: /«PKGBUILDDIR»/packages/jpl/test_jpl.pl:1213:
> test jref2: received error: plunit_jpl:'unit body'/2: Undefined
> procedure: jpl:jni_term_to_jref/2
> Makefile:60: recipe for target 'check_pl' failed
> make[2]: *** [check_pl] Error 1
> make[2]: Leaving directory '/«PKGBUILDDIR»/packages/jpl'
> debian/rules:134: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 2
> make[1]: Leaving directory '/«PKGBUILDDIR»'
> debian/rules:70: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 2
>

Hmmm... As I can see it cannot find libjpl.so, because on i386 it fails
to build that library, see:


gcc -shared -rdynamic -Wl,-z,relro -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -pthread  -L/«PKGBUILDDIR»/src/../lib/i386  -o 
libjpl.so src/c/jpl.o  -ljava -lverify -ljvm -lswipl
/usr/bin/ld: cannot find -ljava
/usr/bin/ld: cannot find -lverify
/usr/bin/ld: cannot find -ljvm
collect2: error: ld returned 1 exit status
Makefile:43: recipe for target 'libjpl.so' failed
make[4]: *** [libjpl.so] Error 1
make[4]: *** Waiting for unfinished jobs


And compare it to log for amd64:


gcc -shared -rdynamic -Wl,-z,relro -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -pthread  -L/«PKGBUILDDIR»/src/../lib/amd64 
-L'/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server' 
-L'/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64' -o libjpl.so src/c/jpl.o  
-ljsig -ljava -lverify -ljvm -lswipl



Something wrong with Makefile generation on i386. Will look at it.
Thanks! Lev Lamberov



signature.asc
Description: OpenPGP digital signature

Bug#812841: systemd checking was not foolproof

[Pirate Praveen]

Control: found -1 gitlab/8.4.0+dfsg-2
Control: forcemerge -1 814413

Since I had init=/bin/systemd in my /proc/cmdline, as I moved to systemd
before it became default, the check in postinst was not correct. I will
switch to checking in /proc/1/cmdline and upload.



signature.asc
Description: OpenPGP digital signature

Bug#814458: gitlab postinst deletes existing data from postgresql database

[Johannes Schauer]

Package: gitlab
Version: 8.4.3+dfsg-1
Severity: critical
Justification: causes serious data loss

Hi,

I previously encountered bug #812841, so I left gitlab as unconfigured
by apt/dpkg and started it manually using `systemctl start gitlab.target`

This seems to have worked well and gitlab was able to make use of the
existing database table from my old manual installation of version
7.8.4.

Then later I wanted to install an unrelated package, so apt/dpkg were
running the gitlab postinst again. As part of the postinst, the database
seems to be completely overwritten with new content. All my existing
content would've been lost if I hadn't made a backup beforehand.

That I now have an empty gitlab instance can be seen from the following
output:

gitlab@22gitlab:~$ rake gitlab:check RAILS_ENV=production
fatal: Not a git repository (or any of the parent directories): .git
Checking GitLab Shell ...
GitLab Shell version >= 2.6.10 ? ... OK (2.6.10)
Repo base directory exists? ... yes
Repo base directory is a symlink? ... no
Repo base owned by gitlab:gitlab? ... yes
Repo base access is drwxrws---? ... yes
hooks directories in repos are links: ... can't check, you have no 
projects
Running /usr/share/gitlab-shell/bin/check
Check GitLab API access: FAILED. code: 302
gitlab-shell self-check failed
  Try fixing it:
  Make sure GitLab is running;
  Check the gitlab-shell configuration file:
  sudo -u gitlab -H editor /usr/share/gitlab-shell/config.yml
  Please fix the error above and rerun the checks.
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Reply by email ...
Reply by email is disabled in config/gitlab.yml
Checking Reply by email ... Finished
Checking LDAP ...
LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab ...
Git configured with autocrlf=input? ... yes
Database config exists? ... yes
Database is SQLite ... no
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory setup correctly? ... skipped (no tmp uploads folder 
yet)
Init script exists? ... yes
Init script up-to-date? ... yes
projects have namespace: ... can't check, you have no projects
Redis version >= 2.8.0? ... yes
Ruby version >= 2.1.0 ? ... yes (2.2.4)
Your git bin path is "/usr/bin/git"
Git version >= 1.7.10 ? ... yes (2.1.4)
Active users: 1

Checking GitLab ... Finished


This should not happen!

Thanks!

cheers, josch

Bug#814408: aptitude uses all disk space (12G) with recursive trace-dump in /tmp

[Chris Tillman]

Sorry, I guess filling disk is not such a bad thing after all. "Everyone
else does it."

Disregard my sarcasm, you are of course right that the system is now
designed to
withstand such poorly behaved applications.

I also thought configs were usually attached by reportbug, but in any case
here is

$ cat /etc/apt/sources.list
deb http://ftp.citylink.co.nz/debian/ testing main non-free contrib
deb-src http://ftp.citylink.co.nz/debian/ testing main non-free contrib

deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

# jessie-updates, previously known as 'volatile'
deb http://ftp.citylink.co.nz/debian/ jessie-updates main contrib non-free
deb-src http://ftp.citylink.co.nz/debian/ jessie-updates main contrib
non-free


$ cat ~/.aptitude/config
Aptitude "";
Aptitude::ProblemResolver "";
Aptitude::ProblemResolver::Trace-File "/tmp/aptitude.trace";
Aptitude::ProblemResolver::Remove-Level "10001";

I also attached the tarred remainder of the offending aptitude-trace
directory in tmp. (Recall I had truncated the recursive directory at
aptitude-trace-dumpubvton/usr/bin/X11/X11/X11/X11/X11 ).

After removing the
Aptitude::ProblemResolver::Trace-File "/tmp/aptitude.trace";
line, I went back in to aptitude to try the same thing again.

Upon starting, it immediately suggested 2 installs, 1 keep, 1 upgrade.
Remember I had cancelled the pending actions. This action was not suggested
last time I was in.
keep: libilmbase6v5
install: libilmbase12, libopenexr22
upgrade: libgeg-0.3-0

I entered ! to accept the suggestion, and verified that these actions are
now pending, along with removal of libopenexr6v5 (libilmbase6v5 is also
being removed because no longer used).

I also have a list of 34 packages being held back, including apt and
apt-utils at 1.2.1. And 96 being automatically held, the list of which
includes many xserver-xorg packages (and xserver-xorg-legacy at 2:1.173-2).

I tried hitting + on the Upgradeable line again, and this time the
resolution was swift: Suggest 23 keeps. This was all the xserver-xorg
packages again. I accepted. I hit the + sign again, and the same suggestion
was offered again.

I think that must be where the recursiveness is coming in.

Let me know if there's something else I can try in this state.



On Fri, Feb 12, 2016 at 12:57 AM, Manuel A. Fernandez Montecelo <
manuel.montez...@gmail.com> wrote:

> Control: severity -1 minor
>
>
> Hi,
>
> 2016-02-11 10:00 Chris Tillman:
>
>> Package: aptitude
>> Version: 0.7.5-3
>> Severity: critical
>> Justification: breaks unrelated software
>>
>
> This is not a critical bug by any strectch, anymore than wget or any
> browser might break unrelated software if you download a partition
> without enough space (when other packages depend on empty space in that
> partition to work fine).  Many packages use /tmp and can cause this
> problem under various circumstances, even with much smaller files.
>
> Simply downloading files in aptitude for an upgrade can fill up
> /var/cache/apt/archives, which might mean / and /tmp if it's a single
> partition, and aptitude never stopped to be released because of that
> behaviour.
>
> There is a simple workaround for that, I suspect, which is to use the
> defaults and not enable options related with trace-dumps.
>
> It would be useful though if you could mention the exact config or
> command line options that you enabled to make this happen.
>
>
> Cheers.
> --
> Manuel A. Fernandez Montecelo 
>



-- 
Chris Tillman
Developer


aptitude-traces.tgz
Description: GNU Zip compressed data

Bug#814244: dpkg: provide a flag to determine the dpkg 'status'

[Guillem Jover]

Hi!

On Tue, 2016-02-09 at 13:36:14 +, Sandro Tosi wrote:
> Package: dpkg
> Version: 1.18.3
> Severity: wishlist

> when a pkg installation fails, and then you run another apt-get command, it 
> will
> check the content of /var/lib/dpkg/updates and if there is any file, requests
> you to run sudo dpkkg --configure -a
> 
> The directory content check seems rather fragile, so it would be great if dpkg
> could provide a cli switch to inspect its internal status. This could be used 
> by
> apt, but also by alerting tools (such as nagios/icinga) or config mgmt tools
> (like pupper/cfengine) to assess the system status.

Hmm, I'm a bit conflicted by this request because the
/var/lib/dpkg/updates directory is used as a package metadata journal
or an update log. dpkg works perfectly fine with it as it parses the
status file and all journal entries and constructs the current state
in memory. It will also integrate those into the main status file once
any write operation is performed, such as removal or install for example.

apt is doing that check because it wants to be safe I guess, and
because files in the journal imply an abrupt termination of dpkg. But
the way to attest that the system is fine is by checking the status
contents through a dpkg interface, such as that all packages are in a
good known state through dpkg-query, or better via dpkg --audit.

Thanks,
Guillem

Bug#814457: python-urwid: New homepage: http://urwid.org/

[Jonas Smedegaard]

Package: python-urwid
Version: 1.3.1-2
Severity: minor
Tags: newcomer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package control file include this:

Homepage: http://excess.org/urwid/

That URL redirects to http://urwid.org/ - please update.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWvNJrAAoJECx8MUbBoAEhh4IQAJtRiPgjtJWgWTaOp70i64bn
BSCQ6hpFa2b2X/Cj5Z9Lxx4ugskQTpD3Vw11KhLiTHEz/Pij+MGkg4OsH+ccZ85s
0QXNUp5sMcp/0bcvJzOXzA4isS+AlM4DibWyJe/lhWcC2ejcLOJMhLx7Ag0hi3rZ
5TSvE+gn3mg5zQvr6VrbDq1OEKENVluTiLwZwKuxS2d7V6r9db+sODaPbVAvUo10
mMIRc22+LG2uKRrSh/GsudU0VM8L8GcBd1t/pT95YziclNCv4Y2miFJm0WzsgJT9
mM+mTJDc7Sgo2Nnmlkrpb7t6EV3akfVMi2FHYFY1kwDlCpVo6SbvcQm9VAzszEwA
u0sQ+BbZ6MycjPHwexTxNRtk/Mj+IPKezGnRexXDuW07lDM7yHsIiPABxwDX8cTd
lilo8Amrsg2nekgcYBHUrpjMLlEZPEVy3U7hpyb7rpyFSRJ2y35KCKLcSVpw92MD
p0cAOl3LIHVgKwsJfUJWMP28VmH+hElhC7uq8WJP8HJBOa8h619z/MxPu4PmI5Mw
eJcuiM+nXISgN8SIDF+pSGPuR1GZ85auJvZGDPryjt3uOOcenuw6e/YmMVyvsad4
+bNnP/1eI1Vr6OzarXH8rpKJJoDoGNhq9ywxiBI+rphfB2I34nAEVbl7Wd7bP+hx
jNRHAVIVWslRhdXXFg+N
=wnIv
-END PGP SIGNATURE-

Bug#814430: dpkg: please define cloudabi architecture

[Guillem Jover]

Control: tags -1 moreinfo

On Thu, 2016-02-11 at 14:34:27 +, Alex Willmer wrote:
> Package: dpkg
> Version: 1.18.4
> Severity: wishlist
> Tags: patch

> Please could you add the attached definition for CloudABI, a new POSIX-like 
> runtime (currently) for amd64/x86_64 and arm64/aarch64.
> 
> I'm requesting this as a step in getting a CloudABI toolchain packaged on
> Debian.  I'm not seeking to introduce a new Debian port or multiarch.
> 
> I've posted [1] with some background info and am happy to answer queries,
> comments etc. there; or whereever you'd prefer.
> 
>  [1] https://lists.debian.org/debian-mentors/2016/02/msg00126.html

Great! I see it already covers most of the points in

but I've got some inguiries.

(I've done some updates there just now. :)

> --- ostable   2015-11-26 23:53:38.0 +
> +++ ostable   2016-02-09 14:30:44.0 +
> @@ -37,3 +37,4 @@
>  uclibceabi-uclinux   uclinux-uclibceabi  uclinux[^-]*-uclibceabi
>  uclibc-uclinux   uclinux-uclibc  uclinux[^-]*(-uclibc.*)?
>  tos-mint mintmint[^-]*
> +cloudabi-unknown unknown-cloudabiunknown[^-]*-cloudabi

Oh so this means the same binary could be run on FreeBSD, Linux, the
Hurd, etc. (as long as the system has been ported to support those
executables? Nice.

(BTW this reminds me a bit of my GNU/Any proposal!
 :)

In any case I assume the unkwown here is referring to the vendor? Such
as «pc» or similar, instead of the kernel? In which case this should
not be present at all.

If this refers to the kernel, I'd use «none» instead which hopefully
should be less confusing.

Thanks,
Guillem

Bug#814456: RFS: pam-ufpidentity/1.0-debian2~unstable [ITP] -- UFP Identity PAM Module

[Richard Levenberg]

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "pam-ufpidentity"

 * Package name: pam-ufpidentity
   Version : 1.0-debian2~unstable
   Upstream Author : Richard Levenberg 
 * URL : https://github.com/ufpidentity/pam_ufpidentity
 * License : GPL-2+
   Section : libs

  It builds those binary packages:

pam-ufpidentity - Package UFP Identity PAM module
 pam-ufpidentity1 - PAM library for UFP identity

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/pam-ufpidentity


  Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/p/pam-ufpidentity/pam-ufpidentity_1.0-debian2~unstable.dsc

  More information about pam-ufpidentity can be obtained from
https://github.com/ufpidentity/pam_ufpidentity.

  Changes since the last upload:

  pam-ufpidentity (1.0-debian2~unstable) unstable; urgency=low

  * adding named package

 -- richardl   Tue, 09 Feb 2016 11:28:41 -0800

n.b. This package has a dependency on

  http://mentors.debian.net/package/identity4c

  One can also download this package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/i/identity4c/identity4c_1.0-debian1~unstable.dsc

  More information about hello can be obtained from
https://github.com/ufpidentity/identity4c

  Changes since the last upload:

  identity4c (1.0-debian1~unstable) unstable; urgency=low

  * building with sbuild

 -- richardl   Thu, 04 Feb 2016 00:36:51 -0800


  Regards,
   Richard Levenberg
-- 
Richard Levenberg

UFP Identity, Inc.
https://www.ufp.com/

Bug#814447: devscripts: uscan(1) github example is rejected with "potentially unsafe or malformed filenamemangle pattern"

[James McCoy]

On Thu, Feb 11, 2016 at 11:40:09AM -0500, Daniel Kahn Gillmor wrote:
> the github example in uscan(1) appears to be rejected by uscan as
> having a "potentially unsafe or malformed filenamemangle pattern".
> 
> It's not clear to me what the problem is or how i should resolve it.
> either the documentation or the definition of safe_replace() in
> scripts/uscan.pl should be updated so that they're aligned.
> 
> Here is an example:
> 
> 0 dkg@alice:~/src/win-iconv/win-iconv$ man uscan | grep -A10 'For GitHub 
> based'
>For GitHub based projects, you can use the tags or releases page.  The
>archive URL uses only the version as the filename.  You can rename the
>downloaded upstream tarball from into the standard
>-.tar.gz using filenamemangle:
> 
>  version=4
>  
> opts="filenamemangle="s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%-$1.tar.gz%" \
^
There's an extraneous " in the example.  This was originally reported in
#814049, but that has been repurposed to fix the wording of the error.

The example itself is fixed in git, which we'll be uploading soon.

Cheers,
James

Bug#812513: please add E1M8b.wad to the doom-wad_*.deb package

[Fabian Greffrath]

Am Sonntag, den 24.01.2016, 17:39 +0200 schrieb Alexandre Detiste:
> maybe someone wants to play this level with freedoom?

Hm, on the other hand one could argue that this map was clearly meant
as a replacement for E1M8 of the original Doom and thus owners of the
original version should get it added to their package.

If people want to play the map with Freedoom, they most probably have
read about it somewhere and are able to figure out where to download it
on their own. 

TL/DR: I think this map is really explicitely meant as an Addon to
Doom, not Freedoom.

Hm?

 - Fabian


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

Bug#814455: python3-pip: Unnecessary dependency on python-3.4

[Thia Wyrod]

Package: python3-pip
Version: 8.0.2-5
Severity: minor

Dear Maintainer,

The python3-pip package has an unnecessary explicit dependency
on python3.4 in addition to python3 (>=3.4~). This leads to the
installation of python3.4 packages on systems where python3 is >3.4,
such as sid.

This bug report's information does not report it as a dependency because
I have been manually apt-get downloading the python3-pip package,
removing the python3.4 dependency in DEBIAN/control, and then repackaging and
installing the modified package. pip3 still functions as expected.


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

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

Versions of packages python3-pip depends on:
ii  ca-certificates  20160104
ii  python-pip-whl   8.0.2-5
pn  python3:any  

Versions of packages python3-pip recommends:
pn  build-essential  
ii  python3-dev  3.5.1-1
pn  python3-wheel

python3-pip suggests no packages.

-- no debconf information

Bug#814429: geneweb: debian/mktemplates may fail due to grep binary matching: iconv: conversion from `Binary' is not supported

[Christian PERRIER]

Quoting Peter Gervai (g...@grin.hu):
> Package: geneweb
> Version: 6.08dfsg-3.1
> Severity: serious
> Tags: patch
> Justification: fails to build from source (but built successfully in the past)
> 
> Build fails with
> iconv: conversion from `Binary' is not supported
> on ca language file. The problem is that grep matches the file as binary, and
> outputs "Binary file matches", which gets (mis)parsed and screw up iconv 
> params.
> Probably dependent on the version of grep, and the phase of the moon 
> possibly. :-)
> 
> This should fix it anyway:


Indeed the reverse patch fixes the problem, but I got the point anywa,
thanks!

This ca.po file is weird. It has something strange which I can't catch
in its first line, which explains why grep thinks it's binary data, I
guess.

Anyway, building the package right now. It's quite some time since I
did so, so I hope that nothing else weird happens..:-)




signature.asc
Description: PGP signature

Bug#814454: reportbug: Crash when trying to configure non-ASCII characters for realname via CLI

[Linus Luessing]

Package: reportbug
Version: 6.6.3
Severity: normal

Dear Maintainer,

During the initial configuration of reportbug I was prompted for a real name.
Unfortunately using umlauts results in the following exception:

-
What real name should be used for sending bug reports?
[root]> Linus Lüssing
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2211, in 
main()
  File "/usr/bin/reportbug", line 1081, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1197, in user_interface
offer_configuration(self.options)
  File "/usr/bin/reportbug", line 578, in offer_configuration
realname = realname.decode(charset, 'replace')
  File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 7: 
ordinal not in range(128)
-

Regards, Linus


-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /root/.reportbugrc:
reportbug_version "6.6.3"
mode standard
ui text
realname "Linus Luessing"
email "linus.luess...@c0d3.blue"
no-check-uid
no-cc
header "X-Debbugs-CC: linus.luess...@c0d3.blue"
smtphost reportbug.debian.org

-- System Information:
Debian Release: 8.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i586)

Kernel: Linux 3.16.0-4-586
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt   1.0.9.8.2
ii  python2.7.9-1
ii  python-reportbug  6.6.3
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
pn  debconf-utils
pn  debsums  
pn  dlocate  
pn  emacs23-bin-common | emacs24-bin-common  
ii  file 1:5.22+15-2+deb8u1
ii  gnupg1.4.18-7
ii  msmtp-mta [mail-transport-agent] 1.4.32-2
pn  python-gtk2  
pn  python-gtkspell  
pn  python-urwid 
pn  python-vte   
pn  xdg-utils

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.8.2
ii  python-debian 0.1.27
ii  python-debianbts  1.12
pn  python:any

python-reportbug suggests no packages.

-- no debconf information