Bug#790690: Fwd: [Bug 94757] powerpc64 & 64Kb kernel pagesize not working with nouveau

[Mathieu Malaterre]

FYI


-- Forwarded message --
From:  
Date: Thu, Apr 7, 2016 at 12:05 AM
Subject: [Bug 94757] powerpc64 & 64Kb kernel pagesize not working with nouveau
To: mathieu.malate...@gmail.com


Comment # 6 on bug 94757 from Ben Skeggs

I have a WIP chunk of work which will hopefully address this issue as a
side-effect.  It's not ready for general consumption yet, but I'll update the
bug once it is.


You are receiving this mail because:

You reported the bug.

Bug#820201: nmu python-avro . all . -m "Rebuild with python3.5 as only python3 version"

[Afif Elghraoui]

Control: reassign -1 release.debian.org
Control: retitle -1 nmu python_avro-1.8.0+dfsg-1 . all . -m "Rebuild
with python3.5"
Control: user release.debian@packages.debian.org
Control: usertags -1 + binnmu
Control: severity -1 normal

Hello,
python3-avro as currently built depends on only python3.4, while the 3.5
transition has apparently finished. The package consequently needs to be
rebuilt with the new state of python3 in unstable.

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#820282: Please enable fpm by default on Apache

[Mathieu Parent]

Package: php7.0-fpm
Version: 7.0.5-2
Severity: normal

Hi Ondrej,

Currently, php7.0 depends on php7.0-fpm | libapache2-mod-php7.0 | php7.0-cgi.

FPM being the default, a smooth experience is expected. Also, this can be a 
security risk as PHP source is available.

Patch:
  git revert 4c4736beed2d0151d69aadbfc156a9d9b3df05c1

Side question: Why was the default changed from mod_php5 to php7.0-fpm?

Cheers

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

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

Bug#820175: jessie-pu: package tklib/0.6-1+deb8u1

[Sergei Golovan]

Hi Adam,

On Wed, Apr 6, 2016 at 11:20 PM, Adam D. Barratt
 wrote:
>
> Please go ahead.

Done. The package is uploaded.

Cheers!
-- 
Sergei Golovan

Bug#820225: libsqlite3-0: Segmentation fault (core dumped)

[GCS]

Hi Chris,

On Wed, Apr 6, 2016 at 11:47 PM, Chris Lamb  wrote:
>> libsqlite3-0: Segmentation fault (core dumped)
>
> Backtrace attached.
 In the log the entry points are missing, ie:
#0  0x7f5fda58df46 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x7f5fda58df46 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f5fd75f9125 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#2  0x7f5fd763e9fa in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#3  0x7f5fd76400e9 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#4  0x7f5fd7642714 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#5  0x7f5fd7669b5b in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0

Do you have libsqlite3-0-dbg installed?

Regards,
Laszlo/GCS

Bug#820281: python-qgis-common: Should Depends/Recommends python-shapely

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Nelson,

On 04/07/2016 06:44 AM, Nelson A. de Oliveira wrote:
> Unless python-shapely is installed, we won't have
> "Vector geometry tools → Polygonize" available in the QGIS geoalgorithms.
> 
> While gis-workstation Recommends python-shapely, an user who installed
> qgis "directly" (ie, without installing gis-workstation and pulling all
> the dependencies/recommendations) won't have this operation available.
> 
> Shouldn't python-qgis-common (or python-qgis?) Depends (or at least
> Recommends) python-shapely?

Yes it should. python-mathplotlib is already included in the
dependencies of python-qgis-common, and python-shapely should join it.

I've added the dependency in git and the fix will be uploaded to
unstable soon.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#820281: python-qgis-common: Should Depends/Recommends python-shapely

[Nelson A. de Oliveira]

Package: python-qgis-common
Version: 2.14.1+dfsg-1
Severity: minor

Hi!

Unless python-shapely is installed, we won't have
"Vector geometry tools → Polygonize" available in the QGIS geoalgorithms.

While gis-workstation Recommends python-shapely, an user who installed
qgis "directly" (ie, without installing gis-workstation and pulling all
the dependencies/recommendations) won't have this operation available.

Shouldn't python-qgis-common (or python-qgis?) Depends (or at least
Recommends) python-shapely?

Thank you!

Best regards,
Nelson

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

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

Versions of packages python-qgis-common depends on:
ii  gdal-bin   2.0.2+dfsg-5
ii  libqgis-customwidgets  2.14.1+dfsg-1
ii  python-gdal2.0.2+dfsg-5
ii  python-matplotlib  1.5.1-1+b1

python-qgis-common recommends no packages.

python-qgis-common suggests no packages.

-- debconf-show failed

Bug#820280: RM: shinken-mod-ws-arbiter -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820279: RM: shinken-mod-ui-graphite -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820276: RM: shinken-mod-pickle-retention-file-generic -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820278: RM: shinken-mod-simple-log -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820273: RM: shinken-mod-named-pipe -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820275: RM: shinken-mod-nsca -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820274: RM: shinken-mod-npcdmod -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820277: RM: shinken-mod-retention-mongodb -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820269: RM: shinken-mod-logstore-null -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820272: RM: shinken-mod-mongodb -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820271: RM: shinken-mod-logstore-sqlite -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820270: installation-reports: Reiser4 SFRN 4.0.1 successful Stretch/Sid installation on bare metal HP laptop.

[Jose R Rodriguez]

Package: installation-reports
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?

*** End of the template - remove these template lines ***


-- Package-specific info:

Boot method: USB stick
Image version: Custom Metztli IT Reiser4-enabled Debian-Installer netboot media
Date: April 06, 2016 

Machine: HP Pavilion dv6-6c53cl
Partitions:
Filesystem Type 1K-blocks Used Available Use% Mounted on
udev   devtmpfs   81816920   8181692   0% /dev
tmpfs  tmpfs  1638296  908   1637388   1% /run
/dev/sdast reiser4   92435000 10895504  81539496  12% /
tmpfs  tmpfs 51204  5116   1% /run/lock
tmpfs  tmpfs  386294014292   3848648   1% /run/shm
/dev/sdau  ext213626996556 32443  75% /boot
/dev/sdavw jfs   80317856 73154756   7163100  92% /home
cgroup tmpfs   12012   0% /sys/fs/cgroup
tmpfs  tmpfs  1638296   16   1638280   1% /run/user/117
tmpfs  tmpfs  1638296   24   1638272   1% /run/user/1000
/dev/sdaxy reiser4   9730 68427932  28872068  71% /mnt/sdaxy


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Burned the Reiser4-enabled netboot ISO image to a USB stick; media was used to
format root partition in Reiser4 SFRN 4.0.1 & subsequent Reiser4-enabled 
experimental kernel installation.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20160402-05:17"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux mictlantecuhtli 4.5.0-trunk-amd64 #1 SMP Debian 4.5-1~exp1 
(2016-03-25) x86_64 Xonecuiltzin
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core 
Processor Family DRAM Controller [8086:0104] (rev 09)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1658]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd 
Generation Core Processor Family Integrated Graphics Controller [8086:0116] 
(rev 09)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1658]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 6 
Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1658]
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 
Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1658]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series 
Chipset Family High Definition Audio Controller [8086:1c20] (rev 05)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:1658]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b5)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b5)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 3 [8086:1c14] (rev b5)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b5)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 
Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 05)
lspci -knn: Subsystem: Hewlett-Packard Company 

Bug#820265: RM: shinken-mod-graphite -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#818244: Request to close

[Erik Haller]

I compiled monitor.c and ran the following command:

cat <(monitor) <(xrandr) <(dpkg-query -l xserver-xorg) > 

I have one radeon X1300 card with a Y cable going to two monitors.

Attached to this email are the two output files.

On Wed, Apr 6, 2016 at 4:28 AM, Yves-Alexis Perez  wrote:

> On mer., 2016-04-06 at 13:13 +0200, Yves-Alexis Perez wrote:
> > On mer., 2016-04-06 at 04:04 -0700, Erik Haller wrote:
> > >
> > > I have never seen xrandr use monitor0|1. I am running lightdm.
> > That just means xfdesktop4 didn't get a monitor name. It gets a name
> > from gdk_screen_get_monitor_plug_name() [1,2] which in turns gets it from
> > X11
> > [3] using XRRGetCrtcInfo(). So my guess is that this behavior changed
> after
> > the xorg update.
> >
> Actually the name comes from XRRGetOutputInfo(), not XRRGetCrtcInfo() but
> the
> point still stands.
>
> Can you check with the attached program and report back the monitor names
> with
> both xorg versions?
>
> Regards,
> --
> Yves-Alexis
>
>


xserver-7.7+13
Description: Binary data


xserver-7.7+14
Description: Binary data

Bug#820267: RM: shinken-mod-livestatus -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820268: RM: shinken-mod-logstore-mongodb -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820264: RM: shinken-mod-collectd -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820263: RM: shinken-mod-booster-nrpe -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#820266: RM: shinken-mod-hot-dependencies -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#816775: #816775: ruby-xapian: Please depend on librubyX.Y

[Olly Betts]

On Thu, Mar 24, 2016 at 11:22:44PM +0100, Christian Hofstaedtler wrote:
> * Olly Betts  [160324 22:56]:
> > On Thu, Mar 24, 2016 at 07:52:56PM +0100, Christian Hofstaedtler wrote:
> > > BTW, there's a pkg-config file if you don't want to go via
> > > RbConfig::CONFIG; if you do, it appears the relevant snippet is:
> > > print RbConfig::CONFIG['DLDFLAGS'] + ' ' + 
> > > RbConfig::CONFIG['LIBRUBYARG_SHARED'] + ' ' + RbConfig::CONFIG['LIBS']

OK, so this doesn't help - we're already linking with -lruby2.x but
because no symbols are used, we don't get a dependency.

> > Thanks very much for this additional detail - I had had a brief look and
> > failed to grasp what was going awry with the automatic dependency.  I
> > think I now actually understand what's going on.
> 
> Yeah sorry about that, I was also confused what was going on. Still
> not too sure what the best way to fix this is.
> 
> In case your package only builds for a single ruby version (I think
> that's the case), putting this into debian/control is also an
> option:

Actually it'll build for all reported ruby versions - that's been a
list with just one entry for a while now, but it seems a shame to lose
this support unless the plan is that it'll always be a one entry list in
the future.

> | RUBY_DEPENDS := -Vruby:Depends="lib$(firstword $(shell dh_ruby 
> --print-supported))"
> |
> | override_dh_gencontrol:
> |dh_gencontrol -- $(RUBY_DEPENDS)
> 
> (Probably not the most stable thing to do.)

I've implemented something similar, but with alternates - e.g. if the list of
ruby versions were 2.1 2.2 2.3, the generated dependency would be:

Depends: libruby2.3|libruby2.1|libruby2.2

That should do the job, but I'm open to better ideas.
 
Cheers,
Olly

Bug#820262: RM: shinken -- ROM; Debian packaging team inactive

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

As the RFA [1] has not been taken, and without any effective action [2].

I don't want to keep this package outdated and unmaintained, so please remove 
it.

Regards


[1]: https://bugs.debian.org/799539
[2]: 
https://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20160111/000358.html

Bug#800212: cyclades-serial-client: Please migrate a supported debhelper compat level

[Logan Rosen]

Package: cyclades-serial-client
Version: 0.92
Followup-For: Bug #800212
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules:
- Remove legacy DH_COMPAT export.
- Use dh_prep instead of dh_clean -k.
- Don't allow $(MAKE) distclean to ignore errors.
- Add recommended build-arch and build-indep targets.
- Remove config.{cache,log} in clean.
  * debian/compat: Indicate compatibility level of 9.
  * debian/control:
- Build-depend on debhelper (>= 9).
- Depend on ${misc:Depends}.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-17-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru cyclades-serial-client-0.92ubuntu2/config.cache cyclades-serial-client-0.92ubuntu3/config.cache
--- cyclades-serial-client-0.92ubuntu2/config.cache	2002-10-17 20:26:36.0 +
+++ cyclades-serial-client-0.92ubuntu3/config.cache	1970-01-01 00:00:00.0 +
@@ -1,30 +0,0 @@
-# This file is a shell script that caches the results of configure
-# tests run on this system so they can be shared between configure
-# scripts and configure runs.  It is not useful on other systems.
-# If it contains results you don't want to keep, you may remove or edit it.
-#
-# By default, configure uses ./config.cache as the cache file,
-# creating it if it does not exist already.  You can give configure
-# the --cache-file=FILE option to use a different cache file; that is
-# what configure does when it calls configure scripts in
-# subdirectories, so they share the cache.
-# Giving --cache-file=/dev/null disables caching, for debugging configure.
-# config.status only pays attention to the cache file if you give it the
-# --recheck option to rerun configure.
-#
-ac_cv_c_const=${ac_cv_c_const=no}
-ac_cv_header_stdc=${ac_cv_header_stdc=yes}
-ac_cv_path_install=${ac_cv_path_install='/usr/bin/install -c'}
-ac_cv_prog_CC=${ac_cv_prog_CC=gcc}
-ac_cv_prog_CPP=${ac_cv_prog_CPP='gcc -nologo -E'}
-ac_cv_prog_CXX=${ac_cv_prog_CXX=c++}
-ac_cv_prog_CXXCPP=${ac_cv_prog_CXXCPP='c++ -E'}
-ac_cv_prog_cc_cross=${ac_cv_prog_cc_cross=no}
-ac_cv_prog_cc_g=${ac_cv_prog_cc_g=yes}
-ac_cv_prog_cc_works=${ac_cv_prog_cc_works=yes}
-ac_cv_prog_cxx_cross=${ac_cv_prog_cxx_cross=no}
-ac_cv_prog_cxx_g=${ac_cv_prog_cxx_g=yes}
-ac_cv_prog_cxx_works=${ac_cv_prog_cxx_works=yes}
-ac_cv_prog_gcc=${ac_cv_prog_gcc=yes}
-ac_cv_prog_gxx=${ac_cv_prog_gxx=yes}
-ac_cv_type_size_t=${ac_cv_type_size_t=yes}
diff -Nru cyclades-serial-client-0.92ubuntu2/config.guess cyclades-serial-client-0.92ubuntu3/config.guess
--- cyclades-serial-client-0.92ubuntu2/config.guess	2010-02-26 19:31:14.0 +
+++ cyclades-serial-client-0.92ubuntu3/config.guess	2016-04-07 03:08:11.0 +
@@ -1,14 +1,12 @@
 #! /bin/sh
 # Attempt to guess a canonical system name.
-#   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-#   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
-#   Free Software Foundation, Inc.
+#   Copyright 1992-2015 Free Software Foundation, Inc.
 
-timestamp='2009-06-10'
+timestamp='2015-08-20'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
+# the Free Software Foundation; either version 3 of the License, or
 # (at your option) any later version.
 #
 # This program is distributed in the hope that it will be useful, but
@@ -17,26 +15,22 @@
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
-# 02110-1301, USA.
+# along with this program; if not, see .
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
 # configuration script generated by Autoconf, you may include it under
-# the same distribution terms that you use for the rest of that program.
-
-
-# Originally written by Per Bothner .
-# Please send patches to .  Submit a context
-# diff and a properly formatted ChangeLog entry.
+# the same distribution terms that you use for the rest of that
+# program.  This Exception is an additional permission under section 7
+# of the GNU General Public License, version 3 ("GPLv3").
+#
+# Originally written by Per Bothner; maintained since 2000 by Ben 

Bug#800208: cvs-syncmail: Please migrate a supported debhelper compat level

[Logan Rosen]

Package: cvs-syncmail
Version: 2.3-1
Followup-For: Bug #800208
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules:
- Remove legacy DH_COMPAT export.
- Use dh_prep instead of dh_clean -k.
- Add recommended build-arch and build-indep targets.
  * debian/compat: Indicate compatibility level of 9.
  * debian/control:
- Build-depend on debhelper (>= 9).
- Depend on ${misc:Depends}.
- Change Build-Depends-Indep to Build-Depends, since both are used in the
  clean target.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-17-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u cvs-syncmail-2.3/debian/control cvs-syncmail-2.3/debian/control
--- cvs-syncmail-2.3/debian/control
+++ cvs-syncmail-2.3/debian/control
@@ -2,12 +2,12 @@
 Section: utils
 Priority: optional
 Maintainer: Christopher Sacca 
-Build-Depends-Indep: debhelper (>= 4.0.0), dpatch
+Build-Depends: debhelper (>= 9), dpatch
 Standards-Version: 3.6.2
 
 Package: cvs-syncmail
 Architecture: all
-Depends: ${shlibs:Depends}, python (>= 2.2.2)
+Depends: ${misc:Depends}, ${shlibs:Depends}, python (>= 2.2.2)
 Description: Notification program for CVS checkins
  syncmail is a CVS notification tool which can provide a diff for every 
  change to a CVS repository, mailed to specified email addresses. This 
diff -u cvs-syncmail-2.3/debian/rules cvs-syncmail-2.3/debian/rules
--- cvs-syncmail-2.3/debian/rules
+++ cvs-syncmail-2.3/debian/rules
@@ -1,7 +1,5 @@
 #!/usr/bin/make -f
 
-export DH_COMPAT=3
-
 # Include magic dpatch stuff to give us
 # patch and depatch targets
 include /usr/share/dpatch/dpatch.make
@@ -15,7 +13,9 @@
 	dh_testdir
 	touch configure-stamp
 
-build: build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
 
 build-stamp: configure-stamp 
 	dh_testdir
@@ -32,7 +32,7 @@
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 	install syncmail $(CURDIR)/debian/cvs-syncmail/usr/bin/
 
only in patch2:
unchanged:
--- cvs-syncmail-2.3.orig/debian/compat
+++ cvs-syncmail-2.3/debian/compat
@@ -0,0 +1 @@
+9

Bug#820261: Cvpcb error "BUILD_GITHUB_PLUGIN not enabled" when attempting to load footprints

[Marc-Alexandre Chan]

Package: kicad
Version: 4.0.2+dfsg1-4
Severity: important

Dear Mr Khaznadar,

I have recently installed KiCAD 4.0.2 fresh on this computer. Upon
opening Cvpcb, the following error appears:

Errors were encountered loading footprints
IO_ERROR: BUILD_GITHUB_PLUGIN not enabled in cmake build environment
from /home/georgesk/developpement/kicad/kicad-4.0.2+dfsg1/pcbnew/io_mgr.cpp
: PluginFind() : line 99
IO_ERROR: BUILD_GITHUB_PLUGIN not enabled in cmake build environment
from /home/georgesk/developpement/kicad/kicad-4.0.2+dfsg1/pcbnew/io_mgr.cpp
: PluginFind() : line 99
IO_ERROR: BUILD_GITHUB_PLUGIN not enabled in cmake build environment
from /home/georgesk/developpement/kicad/kicad-4.0.2+dfsg1/pcbnew/io_mgr.cpp
: PluginFind() : line 99
IO_ERROR: BUILD_GITHUB_PLUGIN not enabled in cmake build environment
from /home/georgesk/developpement/kicad/kicad-4.0.2+dfsg1/pcbnew/io_mgr.cpp
: PluginFind() : line 99
IO_ERROR: BUILD_GITHUB_PLUGIN not enabled in cmake build environment
from /home/georgesk/developpement/kicad/kicad-4.0.2+dfsg1/pcbnew/io_mgr.cpp
: PluginFind() : line 99
IO_ERROR: BUILD_GITHUB_PLUGIN not enabled in cmake build environment
from /home/georgesk/developpement/kicad/kicad-4.0.2+dfsg1/pcbnew/io_mgr.cpp
: PluginFind() : line 99
IO_ERROR: BUILD_GITHUB_PLUGIN not enabled in cmake build environment
from /home/georgesk/developpement/kicad/kicad-4.0.2+dfsg1/pcbnew/io_mgr.cpp
: PluginFind() : line 99

I believe the error is self-explanatory. If relevant, it occurs after
completing a schematic in Eeschema, exporting the netlist and then
opening Cvpcb from within Eeschema.

I imagine this also affects the layout editor, but did not test prior to
implementing a workaround.

No footprints are included with KiCAD it would appear. I can see various
footprint libraries like Air_Coils_SML_NE0SID, Buttons_Switches_SMD,
etc., in the left pane of Cvpcb but no footprints exist within them.
(Expectation being it will automatically download them via the GitHub
plugin?)

This prevents normal usage of the KiCAD PCB design workflow.

WORKAROUND (for any passers-by):

The workaround is to download the footprints manually and modify the
.config/kicad/fp-lib-table configuration file to point to the local copies
rather than the GitHub ones. A script in the KiCAD sources can do this:
https://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/scripts/library-repos-install.sh

Regards,

Marc-Alexandre Chan




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

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

Versions of packages kicad depends on:
ii  kicad-common4.0.2+dfsg1-4
ii  libboost-context1.58.0  1.58.0+dfsg-4.1
ii  libboost-date-time1.58.01.58.0+dfsg-4.1
ii  libboost-filesystem1.58.0   1.58.0+dfsg-4.1
ii  libboost-iostreams1.58.01.58.0+dfsg-4.1
ii  libboost-locale1.58.0   1.58.0+dfsg-4.1
ii  libboost-program-options1.58.0  1.58.0+dfsg-4.1
ii  libboost-regex1.58.01.58.0+dfsg-4.1
ii  libboost-system1.58.0   1.58.0+dfsg-4.1
ii  libboost-thread1.58.0   1.58.0+dfsg-4.1
ii  libc6   2.21-8
ii  libcairo2   1.14.6-1
ii  libgcc1 1:5.3.1-8
ii  libgl1-mesa-glx [libgl1]11.1.2-1
ii  libglew1.13 1.13.0-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgomp15.3.1-8
ii  libpython2.72.7.11-3
ii  libstdc++6  5.3.1-8
ii  libwxbase3.0-0v53.0.2+dfsg-1.2
ii  libwxgtk3.0-0v5 3.0.2+dfsg-1.2
ii  python-wxgtk3.0 3.0.2.0+dfsg-1+b1

kicad recommends no packages.

Versions of packages kicad suggests:
pn  extra-xdg-menus  
ii  kicad-doc-en 4.0.1+dfsg1-2

-- no debconf information

Bug#816325: [pkg-dhcp-devel] org.freedesktop.PolicyKit1 was not provided by any .service files

[Jörg Frings-Fürst]

Hi,


Am Dienstag, den 05.04.2016, 00:24 -0400 schrieb Michael Gilbert:
> control: severity -1 important
> control: tag -1 moreinfo, unreproducible
> 
> On Mon, Feb 29, 2016 at 4:11 PM, Joerg Frings-Fuerst wrote:
> > 
> > $ systemctl start isc-dhcp-server
> > Failed to start isc-dhcp-server.service: The name
> > org.freedesktop.PolicyKit1 was not provided by any .service files
> The org.freedesktop.PolicyKit1.service file is provided by the
> policykit-1 package.  Do you have that installed?
> 
> Anyway, I tried removing that, but the server still started fine for
> me with systemd.  Have you created your own isc-dhcp-server.service
> file?  If so, what does it contain?
> 
No I don't. 

It's a stretch system without any manual installs. Packages see
attachment.

At a short test this night a fresh install with the selections runs
into the same error.

> Best wishes,
> Mike
> 

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.

acl install
acpiinstall
acpi-support-base   install
acpid   install
adduser install
aideinstall
aide-common install
amd64-microcode install
apt install
apt-cacher-ng   install
apt-fileinstall
apt-listbugsinstall
apt-listchanges install
apt-utils   install
aptitudedeinstall
aptitude-common install
aspell  install
aspell-de   install
aspell-de-alt   install
at  install
avahi-autoipd   install
avahi-daemoninstall
bacula-common   install
bacula-fd   install
base-files  install
base-passwd install
bashinstall
bash-completion install
bc  install
bind9   install
bind9-doc   install
bind9-host  install
bind9utils  install
binutilsinstall
bsd-mailx   install
bsdmainutilsinstall
bsdutilsinstall
build-essential install
busybox install
bzip2   install
ca-certificates install
chkrootkit  install
console-setup   install
console-setup-linux install
coreutils   install
cpioinstall
cpp install
cpp-4.9 install
cpp-5   install
croninstall
curlinstall
dashinstall
db5.1-util  install
dbusinstall
dc  install
debconf install
debconf-i18ninstall
debconf-utils   install
debian-archive-keyring  install
debianutils install
debsecaninstall
dh-python   install
dictionaries-common install
diffutils   install
dirmngr install
discoverinstall

Bug#820162: w3m: SEGFAULT on bogus HTML

[Steve Kemp]

On Thu Apr 07, 2016 at 06:51:52 +0900, Tatsuya Kinoshita wrote:

> > Confirmed, thank you.
> 
> Fixed in the development repo.
> 
>   - 
> https://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=7bb2a4671503c41d63989dcef9ef54dea0c73b43
> 
> Will be fixed in the next upload for unstable.

  Thanks for your prompt attention, and fix!

Steve
-- 
http://www.steve.org.uk/

Bug#820260: nvidia-kernel-source: Module does not build with make-kpkg (kernel-package)

[Kevin Locke]

Package: nvidia-kernel-source
Version: 352.79-5
Severity: normal

Dear Maintainer,

Starting in version 352.79-2 I am unable to build the nvidia kernel
module for custom kernels using make-kpkg (part of the kernel-package
package).  I have confirmed that the issue is present in both 352.79-5
and 355.11-2.  The error which occurs is:

$ make-kpkg -j4 --rootcmd fakeroot --append_to_version +kevinoid1 --revision 
4.5+1 --added_modules nvidia-kernel modules_image
[...]
make[2]: Entering directory '/usr/src/modules/nvidia-kernel'
/usr/bin/make  KBUILD_VERBOSE=1 -C /lib/modules/4.5.0+kevinoid1/build 
M=/usr/src/modules/nvidia-kernel ARCH=x86_64 
NV_KERNEL_SOURCES=/lib/modules/4.5.0+kevinoid1/build 
NV_KERNEL_OUTPUT=/lib/modules/4.5.0+kevinoid1/build NV_KERNEL_MODULES="nvidia 
nvidia-uvm" INSTALL_MOD_DIR=kernel/drivers/video Q= modules
make[3]: Entering directory '/usr/src/modules/nvidia-kernel'
make[3]: *** /lib/modules/4.5.0+kevinoid1/build: No such file or directory.  
Stop.
make[3]: Leaving directory '/usr/src/modules/nvidia-kernel'
Makefile:81: recipe for target 'modules' failed
make[2]: *** [modules] Error 2

I have attached both a successful build log (with version 352.79-1) and
an unsuccessful one (with version 352.79-2) using the same command as
above.

I believe this is due to debian/rules not passing KSRC (/usr/src/linux
in my case) to the nVidia Makefile, which attempts to deduce it from the
version information.  This fails if the kernel is not yet installed,
which is always the case when building the module with the kernel using
make-kpkg.  I think this behavior was introduced in r6121.[1]

Thanks,
Kevin


1.  
https://anonscm.debian.org/viewvc/pkg-nvidia/packages/nvidia-graphics-drivers/trunk/debian/module/debian/rules.in?r1=6121=6120=6121


-- Package-specific info:
uname -a:
Linux kevinolos 4.4.1+kevinoid1+ #2 SMP Tue Feb 2 12:37:00 PST 2016 x86_64 
GNU/Linux

/proc/version:
Linux version 4.4.1+kevinoid1+ (kevin@kevinolos) (gcc version 5.3.1 20160121 
(Debian 5.3.1-7) ) #2 SMP Tue Feb 2 12:37:00 PST 2016

lspci 'VGA compatible controller [0300]':
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core 
processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo 3rd Gen Core processor Graphics Controller [17aa:21f4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

dmesg:
[0.00] Console: colour VGA+ 80x25
[0.166699] vgaarb: setting as boot device: PCI::00:02.0
[0.166701] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.166703] vgaarb: loaded
[0.166704] vgaarb: bridge control possible :00:02.0
[0.268481] Linux agpgart interface v0.103
[   89.266342] [drm] Replacing VGA console driver
[   89.272998] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem

Device node permissions:
crw-rw+ 1 root video 226,   0 Apr  6 10:25 /dev/dri/card0
crw-rw  1 root video 226,  64 Apr  6 10:25 /dev/dri/controlD64
crw-rw+ 1 root video 226, 128 Apr  6 10:25 /dev/dri/renderD128
video:x:44:kevin,sysacct

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   22 Dec 27 08:39 /etc/alternatives/glx -> 
/usr/lib/mesa-diverted
lrwxrwxrwx 1 root root   49 Jul 24  2015 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   51 Dec 27 08:39 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Jul 24  2015 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Jul 24  2015 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Dec 27 08:39 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   48 Dec 27 08:39 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Dec 27 08:39 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Dec 27 08:39 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   57 Dec 27 08:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 Dec 27 08:39 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 

Bug#818856: [Reproducible-builds] Bug#818856: diffoscope: crashes on broken symlinks

[Paul Wise]

On Thu, 2016-04-07 at 00:42 +0530, Satyam Zode wrote:

> Thank you for reviewing patch. I have made all the changes you
> mentioned above. Please find an attachment :-)

This will works better but will still give a crash when both symlinks
are broken and point to a filename of the same length; because open()
throws an IOError exception when it tries to open a broken symlink.

In addition, I think we need a test for this issue written before
fixing the issue, here are some test cases I can think of:

one broken symlink, one file

one file, one broken symlink
one broken symlink, one dir

one dir, one broken symlink
one working symlink to a file, one broken symlink
one broken symlink, one working symlink to a file
one working symlink to a dir, one broken symlink
one broken symlink, one
working symlink to a dir
two broken symlinks pointing at the same
location
two broken symlinks of the same size but different locations
two broken symlinks of different sizes

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#820165: RFS: libretro-genesisplusgx/1.7.4+git20160330 [ITP]

[Sérgio Benjamim]

Yeah, right, it may confuse people. I changed that in Copyright. Take a 
look again.



cheers,
sergio-br2


On 06/04/2016 11:36, PICCORO McKAY Lenz wrote:

2016-04-06 9:37 GMT-04:30 Sergio benjamim Rocha filho :

MAME changed its license, but Genesis Plus GX uses the old one.
Also, it's based on some portions of old mame code:
https://github.com/ekeeke/Genesis-Plus-GX/blob/master/LICENSE.txt#L7

i already know, ok i not explain too much, but ...

i suggested to better put licence as only non-commercial due makes
more confused if put "mame" as licensed due now are gpl

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Mattia,

On 6 April 2016 at 19:58, Mattia Rizzolo  wrote:
> I see, cool.
>
> Then, uploaded :)

I saw that it is now on the NEW queue. Thank you very much!

P.s.: can you please push the release tag to the collab-maint repo? :-)

Regards,
Tiago.

-- 
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#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Paul Wise]

On Thu, Apr 7, 2016 at 1:57 AM, Diego M. Rodriguez wrote:

> On my earlier attempts (<=0.5.1-1) I did include some patches that were
> aimed towards fixing pep8/flake8 warnings, although I dropped them on
> the 0.5.3 package. The reason was that upstream has expressed his
> willingness to ignore E501 and E226 [2], and after a brief discussion at
> #debian-python I was under the impression that I should "patch it only
> if you must, pep8 is not a must", favouring closeness to upstream over
> style fixes.
>
> I'm wondering if you could provide a definitive answer on whether to
> patch or not patch those issues, as I'm a bit unsure and I'd be happy
> to proceed with either solution.

pep8 is solely checking against the PEP-8 Python style guide. It is
not in any way useful to have Debian patches for changing the style.
cats only runs pep8 so people ask upstream to make their code more
readable via PEP-8, but the style used by upstream is completely up to
them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#814578: laptop-mode-tools throttles pstate-managed CPUs to half speed on battery power

[Matthew Gabeler-Lee]

Package: laptop-mode-tools
Version: 1.69.2-1
Followup-For: Bug #814578

I have this problem too, but it's even worse for me.

The throttling to "50%" ends up mapping to "always stuck at the bog minimum
slowest speed possible".

cpufreq-info -c 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.00 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.00 GHz.
  The governor "powersave" may decide which speed to use
  within this range.

Even running burnP6 * nCPUs from cpuburn won't bump it off the bare minimum
800MHz when on battery.

My cpu is a:
model name  : Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz

Which I guess explains why "50%" is "800MHz" -- 3GHz is the max turbo freq,
800MHz is presumably the only step close to 1800/2=900 MHz.

>From what I've read, preventing the CPU from bumping up to higher
frequencies can actually *increase* power consumption because it forces the
CPU to stay awake longer before returning to an idle low power / sleep
state.

Needless to say I'm fixing this locally in my config files, but I would
suggest that the current defaults should be revisited as producing poor
behavior, and possibly being misguided.

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

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

Versions of packages laptop-mode-tools depends on:
ii  init-system-helpers  1.29
ii  lsb-base 9.20160110
ii  psmisc   22.21-2.1+b1
ii  util-linux   2.27.1-6

Versions of packages laptop-mode-tools recommends:
ii  ethtool 1:4.5-1
ii  hdparm  9.48+ds-1
ii  net-tools   1.60+git20150829.73cef8a-2
ii  python-qt4  4.11.4+dfsg-1+b3
pn  sdparm  
ii  udev229-3
ii  wireless-tools  30~pre9-9

Versions of packages laptop-mode-tools suggests:
ii  acpid  1:2.0.26-1

-- no debconf information

Bug#780081: BtrFS-progs transition

[Jack Underwood]

Just started learning about BtrFS now that I have a new hdd that I want 
to store my large research data files.


Anyway, I wondered if you needed any help with this, I see that 
btrfs-progs now has many new versions out since 4.4 with lots of 
bugfixes, currently 4.5.1 according to 
https://btrfs.wiki.kernel.org/index.php/Main_Page.  I guess this would 
also make it easier to make the switch, as we just upload btrfs-tools 
4.5.1 as a transitional package pointing to brtfs-progs, killing two 
birds with one stone, so to speak.


I should note my bias on this though as I want the most stable (aka 
up-to-date) version to reformat my hdd with.


Best,
Jack

Bug#820259: igtf-policy-classic: please make symlink location configurable and possible to disable them alltogether

[Christoph Anton Mitterer]

Package: igtf-policy-classic
Version: 1.73-1
Severity: wishlist


Hi.

Currently the package creates symlinks for all files in /etc/grid-security.
It would be nice if one could:
- disable this completely
- configure the location where they're created

The reasons are:
a) Even in grid environments, /etc/grid-security is no longer necessarily a
   fixed location, e.g. dcache allows other locations for CA and voms stuff.
b) The following scenario I use at our Tier-2:
   - I basically want to have on location where I canonically set up the trusted
 CAs/voms files and where fetch CRL runs.
   - all other nodes on the cluster, pull their files from that node, e.g. via
 rsync, and deploy it to their respective /etc/grid-security (this is even
 done like that by the host, where I keep the canonical repo of the certs.
   Why? Well, several reasons:
   - one central point where I can remove trusted CAs if I want to
   - one central point where fetch-crl runs, which has the minor benefit of
 less services running on other nodes, and the major benefit, that it's
 guaranteed that all nodes have the same CRLs.
 It happens pretty often the the CRL servers fail sometimes and even if
 they'd not, I'd want all nodes to have exactly the same CRLs (which is
 not fully guaranteed if each of them runs fetch-crl, at possibly different
 times).
 Accesses shouldn't be allowed on one node, but denied on another because
 of different CRLs.
   Problems with the current way the package installs symlinks to 
/etc/grid-security:
   - They're all symlinks... so either I still have to install the package on
 each node (which again makes it possible that they're out of sync)
   - It doesn't work anymore, that the one node that holds the canonical 
location
 of my trusted CAs (which needs to be /etc/grid-security right now) pulls
 his CAs via the same mechanism as all other nodes.


Cheers,
Chris.

Bug#820248: Please switch from softhsm to softhsm2

[Ondřej Surý]

Control: tags -1 +patch

And here's tested patch.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Thu, Apr 7, 2016, at 00:23, Ondřej Surý wrote:
> Package: src:mod-gnutls
> Version: 0.7.2-2
> Severity: serious
> Justification: fails to build from source (but built successfully in the
> past)
> 
> Daniel,
> 
> could you please switch the mod-gnutls to use (lib)softhsm2 (>= 2.1.0-2)?
> 
> I am going to kill softhsm(1) from the archive and yours and some
> golang pkcs11 library are the only users of the old softhsm(1) (and
> both just for the tests).
> 
> Cheers,
> Ondrej
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.5.0-rc7-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
From d9e31a6cc70c64b5f9f3d6fc095a8a36592e679e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ond=C5=99ej=20Sur=C3=BD?= 
Date: Wed, 6 Apr 2016 21:49:05 -0300
Subject: [PATCH] Use libsofthsm2.so instead of libsofthsm.so

---
 debian/control |  2 +-
 ...e-libsofthsm2.so-instead-of-libsofthsm.so.patch | 41 ++
 debian/patches/series  |  1 +
 3 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/0002-Use-libsofthsm2.so-instead-of-libsofthsm.so.patch

diff --git a/debian/control b/debian/control
index a2a1c59..d1c31f8 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Build-Depends: apache2-bin ,
pandoc,
pkg-config,
procps ,
-   softhsm 
+   libsofthsm2 
 Standards-Version: 3.9.6
 Homepage: https://mod.gnutls.org/
 Vcs-Git: https://mod.gnutls.org/git/mod_gnutls
diff --git a/debian/patches/0002-Use-libsofthsm2.so-instead-of-libsofthsm.so.patch b/debian/patches/0002-Use-libsofthsm2.so-instead-of-libsofthsm.so.patch
new file mode 100644
index 000..1783da9
--- /dev/null
+++ b/debian/patches/0002-Use-libsofthsm2.so-instead-of-libsofthsm.so.patch
@@ -0,0 +1,41 @@
+From: =?utf-8?q?Ond=C5=99ej_Sur=C3=BD?= 
+Date: Wed, 6 Apr 2016 21:48:57 -0300
+Subject: Use libsofthsm2.so instead of libsofthsm.so
+
+---
+ test/softhsm.bash | 5 ++---
+ test/tests/24_pkcs11_cert/apache.conf | 2 +-
+ 2 files changed, 3 insertions(+), 4 deletions(-)
+
+diff --git a/test/softhsm.bash b/test/softhsm.bash
+index e306ec2..155d599 100755
+--- a/test/softhsm.bash
 b/test/softhsm.bash
+@@ -87,12 +87,11 @@ esac
+ 
+ set -e
+ 
+-# Guess location of libsofthsm based on softhsm binary. The path
++# Guess location of libsofthsm2 based on softhsm binary. The path
+ # matches SoftHSM upstream, but this might fail if someone changes the
+ # libdir or bindir of the SoftHSM installation independently of its
+ # general prefix.
+-softhsm_prefix="$(realpath $(dirname ${softhsm})/..)"
+-softhsm_lib="${softhsm_prefix}/lib/softhsm/libsofthsm.so"
++softhsm_lib="/usr/lib/softhsm/libsofthsm2.so"
+ 
+ # fail if SOFTHSM_CONF is not set
+ if [ -z "${SOFTHSM_CONF}" ]; then
+diff --git a/test/tests/24_pkcs11_cert/apache.conf b/test/tests/24_pkcs11_cert/apache.conf
+index 6117c31..6a60b69 100644
+--- a/test/tests/24_pkcs11_cert/apache.conf
 b/test/tests/24_pkcs11_cert/apache.conf
+@@ -2,7 +2,7 @@ Include ${srcdir}/base_apache.conf
+ 
+ GnuTLSCache dbm cache/gnutls_cache
+ 
+-GnuTLSP11Module	/usr/lib/softhsm/libsofthsm.so
++GnuTLSP11Module	/usr/lib/softhsm/libsofthsm2.so
+ 
+ 
+  ServerName ${TEST_HOST}
diff --git a/debian/patches/series b/debian/patches/series
index 5ae5469..47d661d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 0001-let-a-failed-diff-be-verbose.patch
+0002-Use-libsofthsm2.so-instead-of-libsofthsm.so.patch
-- 
2.8.0.rc3

Bug#820239: vim-gnome: uses obsolete GNOME 2 libraries

[James McCoy]

Thanks for the report.  I was actually just looking into this some the
other day.  Hopefully you'll be able to provide some more clarity to my
musings.

On Wed, Apr 06, 2016 at 09:53:47PM +0100, Simon McVittie wrote:
> The difference between vim-gtk and vim-gnome is that vim-gnome links
> libgnome, a library for integration with old GNOME technologies. However,
> we haven't shipped GNOME 2 since squeeze,

The bits of functionality that Vim is using aren't honored at all by
Gnome3?

> making libgnome rather useless,
> and the best vim version for GNOME 3 users at this point is vim-gtk (or
> vim-gtk3, if/when it's stable enough - I've sent a patch on a separate
> bug to stop it crashing on Wayland).

Thanks for that.  It's been applied upstream, with a slight tweak to the
version check, and will be included in the next upload.

> I suspect the vim-gnome name might
> be misleading vim-on-GNOME users into installing the wrong one.
> 
> The GNOME maintainers would like to get rid of libgnome and libbonobo, but
> there's a really long tail of packages that still link to them. Because
> there's already a replacement (vim-gtk or vim-gtk3), I would suggest
> turning vim-gnome into a transitional package to one of those.

Based on my reading of the source and docs, below are the knobs that
vim-gnome offers (or at least intends to) over vim-gtk.

- Session preservation/restoration (via GnomeApp & GnomeClient)
  + If Gnome support isn't enabled, this attempts to fallback to using
libsm6, but there are comments that indicate it doesn't work very
well and only saves the session instead of also being able to
restore it.
  + Gtk3's GtkApplication has a register-session property which may
simplify some of the code in this area, but as far as I can tell it
still doesn't provide the means to restore the session.

- Tweaks behavior of the toolbar/menu in the dock (via Bonobo & GnomeApp)
  + Disables floating behavior of menu/toolbar dock items
  + Saves/restores layout of the dock
  + This seems to be replaced by gdl, but those APIs all seem to be
marked "unstable unless otherwise indicated", which doesn't give me
much confidence.

I'm fairly unfamiliar with the Gtk/Gnome libraries, so I may be missing
something.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#820228: digikam: Digikam crash immediatly when I try to rotate an image right.

[Steve M. Robbins]

On April 6, 2016 09:15:27 PM you wrote:
> Package: digikam
> Version: 4:4.14.0-4
> Severity: important
> 
> There is nothing more to say.

Can you provide an example picture where it crashes?
Does it happen with all pictures?


Thanks,
-Steve


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

Bug#820258: linux-image-3.16.0-4-amd64: multiple oops. froze. had to reboot. null chars in log files.

[gofloss gofloss]

Package: src:linux
Version: 3.16.7-ckt25-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

i am running a pretty vanilla jessie (but with an nvidia firmware).

the computer froze.

web browsing both times.  today it was an unintentional drag
of a url in iceweasel.  (grr, firefox.)

it never did this before Apr 4, which i believe is after the
recent kernel upgrade.

therefore, may i suspect the new kernel upgrade is the cause
of this?  if it's instead hardware or user error, i'd like
to know about it.

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

rebooted.

   * What was the outcome of this action?

it froze in mid-unintentional-drag.  rebooting fixed it.

   * What outcome did you expect instead?

working computer?

here is the log starting one line above the oops.  take it
easy on me as ianakh.  ask me for anything else you want.

is normal priority correct for a system freeze that requires
a reboot?

thanks.


Apr  4 21:52:27 stinky kernel: [189404.722726] PGD 0
Apr  4 21:52:27 stinky kernel: [189404.724004] Oops: 0002 [#1] SMP
Apr  4 21:52:27 stinky kernel: [189404.724004] Modules linked in:
pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) xt_tcpudp
ip6table_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat xt_TCPMSS xt_LOG ipt_REJECT iptable_mangle
xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp
nf_conntrack ip6table_filter ip6_tables iptable_filter ip_tables
x_tables binfmt_misc xts gf128mul ppdev iTCO_wdt iTCO_vendor_support
evdev radeon ttm coretemp drm_kms_helper kvm_intel
snd_hda_codec_analog snd_hda_codec_generic kvm drm i2c_algo_bit
i2c_i801 dcdbas i2c_core serio_raw pcspkr snd_hda_intel lpc_ich
snd_hda_controller snd_hda_codec snd_hwdep snd_pcm tpm_tis parport_pc
shpchp snd_timer snd parport mfd_core tpm mei_me mei soundcore button
processor thermal_sys loop autofs4 ext4 crc16 mbcache jbd2
sha256_ssse3 sha256_generic ecb cbc algif_skcipher af_alg dm_crypt
dm_mod ses enclosure hid_generic usbhid hid sg sd_mod crc_t10dif
crct10dif_generic sr_mod crct10dif_common cdrom usb_storage ahci
libahci ata_generic e1000e uhci_hcd ehci_pci psmouse ehci_hcd libata
ptp usbcore scsi_mod pps_core usb_common
Apr  4 21:52:27 stinky kernel: [189404.724004] CPU: 0 PID: 2995 Comm:
Xorg Tainted: G   O  3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-1
Apr  4 21:52:27 stinky kernel: [189404.724004] Hardware name: Dell
Inc. OptiPlex 755 /0GM819, BIOS A04 11/05/2007
Apr  4 21:52:27 stinky kernel: [189404.724004] task: 8800c8ccc190
ti: 8800ca37 task.ti: 8800ca37
Apr  4 21:52:27 stinky kernel: [189404.724004] RIP:
0010:[]  []
radeon_fence_ref+0xd/0x50 [radeon]
Apr  4 21:52:27 stinky kernel: [189404.724004] RSP:
0018:8800ca373b18  EFLAGS: 00010292
Apr  4 21:52:27 stinky kernel: [189404.724004] RAX: 
RBX: 8800c8b7d5f8 RCX: 8800c8b7cd08
Apr  4 21:52:27 stinky kernel: [189404.724004] RDX: 0001
RSI:  RDI: 
Apr  4 21:52:27 stinky kernel: [189404.724004] RBP: 8800c8b7d550
R08: 8800c8b7c000 R09: 
Apr  4 21:52:27 stinky kernel: [189404.724004] R10: 0002
R11: 8800ca373e08 R12: 0020
Apr  4 21:52:27 stinky kernel: [189404.724004] R13: 8800ca373be0
R14: 8800ca373bb0 R15: 8800c8b7d5f8
Apr  4 21:52:27 stinky kernel: [189404.724004] FS:
7f7190131980() GS:880127c0()
knlGS:
Apr  4 21:52:27 stinky kernel: [189404.724004] CS:  0010 DS:  ES:
 CR0: 80050033
Apr  4 21:52:27 stinky kernel: [189404.724004] CR2: 0008
CR3: 35c47000 CR4: 07f0
Apr  4 21:52:27 stinky kernel: [189404.724004] Stack:
Apr  4 21:52:27 stinky kernel: [189404.724004]  a05ae0bc
002c2280 ef200100 8800ca373cd0
Apr  4 21:52:27 stinky kernel: [189404.724004]  8800c8b7c000
8800c8ccc190 8800c8ccc190 0001
Apr  4 21:52:27 stinky kernel: [189404.724004]  
  
Apr  4 21:52:27 stinky kernel: [189404.724004] Call Trace:
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
radeon_sa_bo_new+0x25c/0x460 [radeon]
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
radeon_ib_get+0x2e/0xd0 [radeon]
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
radeon_cs_ioctl+0x13c/0x730 [radeon]
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
drm_ioctl+0x1c7/0x5b0 [drm]
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
__do_page_fault+0x1d1/0x4f0
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
radeon_drm_ioctl+0x46/0x80 [radeon]
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
do_vfs_ioctl+0x2cf/0x4b0
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
SyS_ioctl+0x81/0xa0
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
page_fault+0x28/0x30
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

[Steven Chamberlain]

Hi,

> Steven Chamberlain  writes:
> > Could someone with access to the hurd-i386 or kfreebsd porter boxes
> > try the attached patch please?

Christoph Egger wrote:
> Start 284: RunCMake.Configure
> 284/371 Test #284: RunCMake.Configure 
> ...***Failed3.19 sec

I have a wild idea what might be happening here.  Please could you try
the attached instead?  You don't need to recompile the whole thing but
only run the single test again with this change, if you still have the
build tree around.

The test was designed to detect cases of CMake running 'again'
unexpectedly, after the explicit run_cmake(RerunCMake).

After writing a new value "2" to CustomCMakeInput.txt, which is not a
declared dependency, it is expected that CMake will not run again and
copy it to the output file (CustomCMakeStamp.txt).

My guess is... if the declared dependency (CustomCMakeDepend.txt) and
output (CustomCMakeOutput.txt) have exactly the same timestamp, it
doesn't know for sure that the output is up-to-date, so it errs on the
side of running again, triggering the bug.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#820257: linux-image-3.16.0-4-amd64: multiple oops. froze. had to reboot. null chars in log files.

[gofloss gofloss]

Package: linux-image-3.16.0-4-amd64

X-Debbugs-Cc: debian-ker...@lists.debian.org, goflossgo+ker...@gmail.com
Package: src:linux
Version: 3.16.7-ckt25-1
Severity: normal

please don't make me fight this bts.

Dear Maintainer,

   * What led up to the situation?

i am running a pretty vanilla jessie (but with an nvidia firmware).

the computer froze.

web browsing both times.  today it was an unintentional drag
of a url in iceweasel.  (grr, firefox.)

it never did this before Apr 4, which i believe is after the
recent kernel upgrade.

therefore, may i suspect the new kernel upgrade is the cause
of this?  if it's instead hardware or user error, i'd like
to know about it.

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

rebooted.

   * What was the outcome of this action?

it froze in mid-unintentional-drag.  rebooting fixed it.

   * What outcome did you expect instead?

working computer?

here is the log starting one line above the oops.  take it
easy on me as ianakh.  ask me for anything else you want.

is normal priority correct for a system freeze that requires
a reboot?

thanks.


Apr  4 21:52:27 stinky kernel: [189404.722726] PGD 0
Apr  4 21:52:27 stinky kernel: [189404.724004] Oops: 0002 [#1] SMP
Apr  4 21:52:27 stinky kernel: [189404.724004] Modules linked in:
pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) xt_tcpudp
ip6table_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat xt_TCPMSS xt_LOG ipt_REJECT iptable_mangle
xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp
nf_conntrack ip6table_filter ip6_tables iptable_filter ip_tables
x_tables binfmt_misc xts gf128mul ppdev iTCO_wdt iTCO_vendor_support
evdev radeon ttm coretemp drm_kms_helper kvm_intel
snd_hda_codec_analog snd_hda_codec_generic kvm drm i2c_algo_bit
i2c_i801 dcdbas i2c_core serio_raw pcspkr snd_hda_intel lpc_ich
snd_hda_controller snd_hda_codec snd_hwdep snd_pcm tpm_tis parport_pc
shpchp snd_timer snd parport mfd_core tpm mei_me mei soundcore button
processor thermal_sys loop autofs4 ext4 crc16 mbcache jbd2
sha256_ssse3 sha256_generic ecb cbc algif_skcipher af_alg dm_crypt
dm_mod ses enclosure hid_generic usbhid hid sg sd_mod crc_t10dif
crct10dif_generic sr_mod crct10dif_common cdrom usb_storage ahci
libahci ata_generic e1000e uhci_hcd ehci_pci psmouse ehci_hcd libata
ptp usbcore scsi_mod pps_core usb_common
Apr  4 21:52:27 stinky kernel: [189404.724004] CPU: 0 PID: 2995 Comm:
Xorg Tainted: G   O  3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-1
Apr  4 21:52:27 stinky kernel: [189404.724004] Hardware name: Dell
Inc. OptiPlex 755 /0GM819, BIOS A04 11/05/2007
Apr  4 21:52:27 stinky kernel: [189404.724004] task: 8800c8ccc190
ti: 8800ca37 task.ti: 8800ca37
Apr  4 21:52:27 stinky kernel: [189404.724004] RIP:
0010:[]  []
radeon_fence_ref+0xd/0x50 [radeon]
Apr  4 21:52:27 stinky kernel: [189404.724004] RSP:
0018:8800ca373b18  EFLAGS: 00010292
Apr  4 21:52:27 stinky kernel: [189404.724004] RAX: 
RBX: 8800c8b7d5f8 RCX: 8800c8b7cd08
Apr  4 21:52:27 stinky kernel: [189404.724004] RDX: 0001
RSI:  RDI: 
Apr  4 21:52:27 stinky kernel: [189404.724004] RBP: 8800c8b7d550
R08: 8800c8b7c000 R09: 
Apr  4 21:52:27 stinky kernel: [189404.724004] R10: 0002
R11: 8800ca373e08 R12: 0020
Apr  4 21:52:27 stinky kernel: [189404.724004] R13: 8800ca373be0
R14: 8800ca373bb0 R15: 8800c8b7d5f8
Apr  4 21:52:27 stinky kernel: [189404.724004] FS:
7f7190131980() GS:880127c0()
knlGS:
Apr  4 21:52:27 stinky kernel: [189404.724004] CS:  0010 DS:  ES:
 CR0: 80050033
Apr  4 21:52:27 stinky kernel: [189404.724004] CR2: 0008
CR3: 35c47000 CR4: 07f0
Apr  4 21:52:27 stinky kernel: [189404.724004] Stack:
Apr  4 21:52:27 stinky kernel: [189404.724004]  a05ae0bc
002c2280 ef200100 8800ca373cd0
Apr  4 21:52:27 stinky kernel: [189404.724004]  8800c8b7c000
8800c8ccc190 8800c8ccc190 0001
Apr  4 21:52:27 stinky kernel: [189404.724004]  
  
Apr  4 21:52:27 stinky kernel: [189404.724004] Call Trace:
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
radeon_sa_bo_new+0x25c/0x460 [radeon]
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
radeon_ib_get+0x2e/0xd0 [radeon]
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
radeon_cs_ioctl+0x13c/0x730 [radeon]
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
drm_ioctl+0x1c7/0x5b0 [drm]
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
__do_page_fault+0x1d1/0x4f0
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
radeon_drm_ioctl+0x46/0x80 [radeon]
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?
do_vfs_ioctl+0x2cf/0x4b0
Apr  4 21:52:27 stinky kernel: [189404.724004]  [] ?

Bug#820256: ITP: espr -- Building performance modelling software

[Wookey]

Package: wnpp
Severity: wishlist
Owner: Wookey 

* Package name: esp-r
  Version : 12.3
  Upstream Author : Energy Systems Research Unit, University of Strathcycle
* URL : http://www.esru.strath.ac.uk/Programs/ESP-r_central.htm
* License : GPL2+
  Programming Lang: C, Fortran
  Description : Building performance modelling software

 ESP-r is a multi-domain building performance simulation program. It
 can model heat, air, moisture light and electrical power flows at
 user specified spatial and temporal resolution. It comprises a
 central Project Manager around which are arranged support databases,
 a simulator, various performance assessment tools and a variety of
 third party applications for CAD, visualisation and report
 generation.


This is useful scientific/building software, and the only Free
Software for doing thermal modelling on GNU/Linux (until Therm get
round to their proposed licence change 'sometime in the next two
years').

It has taken me several years (of very sporadic efforts) to get this
packaged as upstream have such a shitty build system. It has improved
significantly (to merely crappy) since I first started prodding it so
the effort is now much less herculean.

Bug#792165:

[Jesse Rhodes]

After discussing the patches from the debian xchat tree with hexchat
upstream it seemed like a better approach to not include any of them
in the hexchat package. Rather, upstream has some more permanent fixes
on their roadmap, which will be included when they're done. Anyway,
this issue hardly ever shows up so I'm dropping the severity down to
minor.

sney

Bug#819650: mirror submission for mirror.ba

[Emir Beganovic]

Hi Donald,

I did the changes as you said.

I've removed /debian and left only the /debian-cd.

Also the rsync works now. How do you check if the mirror has been updated?
I can see it has, but you say it hasn't :)

I was using debian.sil.at but it seems old (2 days at least). I've switched
to LeaseWeb's mirror (mirror.de.leaseweb.net) and updated the mirror.

Hope it looks good now!

Regards


On Tue, Apr 5, 2016 at 10:36 PM Donald Norwood 
wrote:

> Hi Emir,
>
> Do you change the mirror structure? I swear I accessed this differently
> yesterday.
>
> The alias listed: debian.mirror.ba no longer works. It does not have to
> be included and is only a minor fix.
>
> The /debian-cd/ directory has not updated yet. Please check your
> upstream provider if you are syncing and it has not updated.
>
> The rsync mechanism fails:
> rsync rsync://mirror.ba/debian-cd
> @ERROR: chroot failed
>
> It would be ideal to remove the /debian/ directory to avoid user
> confusion as it appears on your http and ftp listings.
>
> Best regards,
>
> Donald Norwood
> -Debian Mirrors Team
>
>
>
> On Tue, 05 Apr 2016 11:59:58 + Emir Beganovic
>  wrote:
> > Hi Donald,
> >
> > Our application might have been mistaken a little bit - we're applying
> only
> > for Debian CD archive, not the Debian packages archive. We'd like to
> appear
> > only on the debian-cd archives list: https://www.debian.org/CD/http-ftp/
> >
> > The /debian-cd/ directory should now be current and updating, please
> > re-check. I've also reconfigured it so it syncs twice a day. :-)
> >
> > The available bandwidth of the mirror is 100 Mbit/s.
> >
> > Regards,
> > Emir Beganovic
> >
> > On Mon, Apr 4, 2016 at 7:01 PM Donald Norwood 
> wrote:
> >
> > > control: tag -1 +moreinfo
> > >
> > > Hello Emir,
> > >
> > > Thank you for your interest in mirroring Debian.
> > >
> > > There are a few items that need resolution for your mirror entry.
> > >
> > > The /debian/ directory need not hold /debian-cd/. The archive is served
> > > as /debian/ for the Debian archive and /debian-cd/ for the Debian CD
> > > archive. I.E.  /debian/ and /debian-cd/
> > >
> > > The /debian-cd/ directory is not current, please update.
> > >
> > > Archive mirrors need to update 4 times per 24 hours, the CD mirrors do
> > > not need to as the images don't change that often. :) Twice a day is
> fine.
> > >
> > > What is the available bandwidth of the mirror?
> > >
> > >
> > > Looking forward to hearing from you.
> > >
> > > Best regards,
> > >
> > > Donald Norwood
> > > -Debian Mirrors team
> > >
>
>

Bug#820253: diaspora-installer: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: diaspora-installer
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#820255: joe: Character range searching doesn't work in UTF8 locale

[Matthew Gabeler-Lee]

Package: joe
Version: 4.1-2
Severity: normal

Create a file with some text ...  e.g.  this bug report ...  with lots of
upper and lower case letters.

Start editing with LANG=en_US.UTF-8

Search for "\[a-z]" or "\[A-Z]" or "\[0-9]" -- no matches found.

Search for "\[0123456789]" -- matches found!

Change LANG to C, try again -- both work properly.

Change LANG to en_US.ISO-8859-15 -- both work properly.

Seems to be a problem with UTF8 I infer.

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

Kernel: Linux 4.4.0-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)

Versions of packages joe depends on:
ii  libc62.22-5
ii  libncurses5  6.0+20160319-1
ii  libtinfo56.0+20160319-1

joe recommends no packages.

joe suggests no packages.

-- Configuration Files:
/etc/joe/ftyperc changed [not included]
/etc/joe/joerc changed [not included]

-- no debconf information

Bug#820254: hitting h causes user-error: Info file bbdb does not exist

[積丹尼 Dan Jacobson]

Package: bbdb3
Version: 3.1.2-5
Severity: wishlist

hitting h causes
user-error: Info file bbdb does not exist

Bug#820251: metche: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: metche
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#820252: manila: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: manila
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#820234: RFS: cligh/0.2-4 ITP

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi,

>Vcs-Browser: https://anonscm.debian.org/cgit/users/kaction-guest/complexity.git
>Vcs-Git: https://anonscm.debian.org/cgit/users/kaction-guest/complexity.git


please fix


please note: std-version is 3.9.8 now.

g.





Il Mercoledì 6 Aprile 2016 22:12, Dmitry Bogatov  ha scritto:

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "cligh"

* Package name: cligh
  Version : 0.2-4
  Upstream Author : Christopher M. Brannon 
* Url : http://the-brannons.com/software/cligh.html
* Licenses: BSD-3-clause, GPL-3+
  Section : vcs

It builds those binary packages:

cligh -- Command-line interface to GitHub

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

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

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

http://mentors.debian.net/debian/pool/main/c/cligh/cligh_0.2-4.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/cgit/users/kaction-guest/complexity.git

More information about cligh can be obtained from 
http://the-brannons.com/software/cligh.html

Changes since last upload:

  * Change section from python to vcs (Closes: #811127)
  * Bump standards version (no changes needed)
  * Change insecure git:// uri in Vcs-Git field to secure https://
  * Check GPG signature

Regards,
  Dmitry Bogatov

Bug#820212: iproute2: Colons in ethernet names under /sbin/ifconfig and /sbin/ip are not being recognized in Stretch

[Justin McZeal]

Hello Bob,
Now we're on the same page, that was an excellent read.

If I could change the script, I would. But it's maintained by the company who 
makes the firewall agent and application, so a simple awk or cut will break the 
whole operation of the agent if it's not made upstream. Their source code is 
viewable but when I edited it, it failed miserably.

I took a guess at the package, I knew it would be either iproute2 or net-tools. 
I'm glad you understood which direction to take.

So yes, ultimately, the goal is to have that unnecessary colon removed from the 
end of the interface name. That in turn should likely fix this agent and I 
won't have to downgrade some servers to deb8 to make it compatible for one 
thing. I actually intended to make the server debian 8, but I mistakenly didn't 
create an apt preferences file in my image to only use the sid repo for apache 
and another program. So it ended up upgrading all packages to make it a debian 
9 installation. In any case, this is the only thing I am having a bottleneck at.

On Wed, Apr 06, 2016 at 5:49 PM, Bob Proulx 
> wrote:


reassign 820212 net-tools
found 820212 1.60+git20150829.73cef8a-2
retitle 820212 ifconfig output format change breaks downstream programs
thanks

Hi Justin,

Justin McZeal wrote:
> Starting from the beginning, ...

:-)

> there is this firewall agent we have

Reading your latest I think I understand better.  Let me rephrase what
you are saying.

In Jessie 8 from net-tools version 1.60-26+b1:

  # ifconfig --version
  net-tools 1.60
  ifconfig 1.42 (2001-04-13)

In Stretch Testing today net-tools version 1.60+git20150829.73cef8a-2:

  # ifconfig --version
  net-tools 2.10-alpha

The 'ifconfig' output format has changed to add a colon after the
device name.

In net-tools 1.60 ifconfig 1.42 (2001-04-13):

  # ifconfig eth0 | grep ^eth0
  eth0  Link encap:Ethernet  HWaddr 00:50:56:b5:00:23

In net-tools 2.10-alpha:

  # ifconfig eth0 | grep ^eth0
  eth0: flags=4163  mtu 1500

The problem you have is that new ":" in the first field is causing
problems for a tool that is processing the output of ifconfig and
never having had to deal with the colon before and doesn't strip it
off and therefore hands the resulting string "eth0:" off to further
processing which fails because the colon isn't part of the device
name.

  eth0: flags=4163  mtu 1500
  ^ colon is causing you problems

I hope that sums up the basic facts.  Please correct any
misunderstanding in the above if so.

I think you got distracted in the cascade of problems downstream of
that because then the tool causing you problems is apparently trying
to use "eth0:" without stripping the colon off of it in order to get a
handle on the device name.  But "eth0:" isn't the device name.  That
colon is just there as an indicator.

Note that the problem you are having is with an output format change
of 'ifconfig' which is part of the 'net-tools' package but you filed
this bug against the 'iproute2' package.  I am a long time complainer
when long time tools change without significant reason.  But that is
the best reason to be running Sid Unstable so as to be able to detect
these problems and file a bug before they hit Testing and become a
potential release candidate.  Better to catch it in Sid than Testing.

I think this bug should be reassigned to the net-tools package with a
request to revert the output format change of ifconfig.  Sure parsing
the output of this legacy command arguably isn't a good idea.  But
changing the output format is going to catch a lot of programs that
have been parsing it for decades.  [[However if the goal is to
deprecate ifconfig then forcing changes is one way to force people to
move.  Because they will have to update their parsing in order to work
at all.]]

> This agent is proprietary, so I can only share the basic cases it
> uses to get the interfaces.

Worse I am sure it is only approved on other platforms but you are
running it on Debian because you prefer Debian and it works there.
And so you are working at a support disadvantage because you want to
upgrade to Testing for some reason and are trying to make things work.
At least that has been my case many times with proprietary software.
Hopefully I am close on this analysis.

Questions: Can you make any modifications to the software locally?  Is
it a script?  It must be because you seem to have deep knowledge of
it.  Or did you find this by running 'strings' on the binary?  I have
some possible suggestions for working around this depending upon what
additional information you provide.

> Now, back to the first case, if that "ifconfig |grep flags="
> worked, which it only did on Debian 9 Stretch, it would use the
> below command to grab the interface information. But note, it's
> running based on the output of eth0: and not just eth0.

If you can modify the parsing code then why not 

Bug#817815: drupal7-mod-civicrm: directory vs. symlink conflict: /usr/share/drupal7/sites -> /etc/drupal/7/sites

[Andreas Beckmann]

Followup-For: Bug #817815
Control: found -1 4.7.4+dfsg-1

Hi,

the situation has improved in the last upload, but is not yet completely
resolved:

1m40.5s INFO: dirname part contains a symlink:
  /etc/drupal/7/sites/default/files/civicrm (drupal7-mod-civicrm) != 
/var/lib/drupal7/files/civicrm (?)
/etc/drupal/7/sites/default/files -> /var/lib/drupal7/files


Andreas


drupal7-mod-civicrm_4.7.4+dfsg-1.log.gz
Description: application/gzip

Bug#715426: Version 0.10.1

[Roderick W. Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/06/2016 05:59 PM, Tianon Gravi wrote:
> On 6 April 2016 at 14:23, Tianon Gravi  wrote:
>> This isn't really as important in the context of Debian, since
>> we'll supply a separate "debian/", but it's definitely nice to
>> keep them in parity, so I'll go do a re-sync and see where we're
>> at!
> 
> dh_install: Cannot find (any matches for) "refind-mkdefault" (tried
> in "." and "debian/tmp") dh_install: refind missing files:
> refind-mkdefault dh_install: missing files, aborting
> 
> Was this file added after 0.10.2 was cut?  Should I be syncing
> against 0.10.2's source tree instead of just master?

Yes, I added that file after releasing 0.10.2. I'm planning to do a
0.10.3 release soon that will include it. If you want to get this
pushed into Debian soon, I could put something together by this
weekend; or you could go with 0.10.2 (from the source tarball) and
then deal with refind-mkdefault for a subsequent version bump.

- -- 
Rod Smith
Server and Cloud Certification Engineer
rod.sm...@canonical.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJXBZC4AAoJEFgyRI+V0FjmDG8H/iaksACKstwQcOLXxubPFyem
C2GZDuybQn35avRghTc5r3y7HpzB96kmCDTTrJmkWcg91ShDD2hiQs7QRwdO9Fsb
ZZrn5UeRBYHsJBWPzYtv5X6T8ZFWe5l8IEp+FfH+Oh6YphJN1QVvBeZidrvf58IT
7Qb45cxsnbwsNGdr1LL0IaroKiS9jLpuso42JfEQRWWnRKPX0ROVLLp4x92OEWlI
Y3YiwcjY1GeJOc/FX3wZidHQwMlGq+2bRaaSgDa1mjb4+CWEUPCZTVu1s8H6Xwvd
XvtbmYmBeXoI8JZUDcuPSi9WJYDdemwNgjjd5Axqvm0sN0nKkySTX2TNykIfazk=
=HAkB
-END PGP SIGNATURE-

Bug#820212: iproute2: Colons in ethernet names under /sbin/ifconfig and /sbin/ip are not being recognized in Stretch

[Bob Proulx]

reassign 820212 net-tools
found 820212 1.60+git20150829.73cef8a-2
retitle 820212 ifconfig output format change breaks downstream programs
thanks

Hi Justin,

Justin McZeal wrote:
> Starting from the beginning, ...

:-)

> there is this firewall agent we have

Reading your latest I think I understand better.  Let me rephrase what
you are saying.

In Jessie 8 from net-tools version 1.60-26+b1:

  # ifconfig --version
  net-tools 1.60
  ifconfig 1.42 (2001-04-13)

In Stretch Testing today net-tools version 1.60+git20150829.73cef8a-2:

  # ifconfig --version
  net-tools 2.10-alpha

The 'ifconfig' output format has changed to add a colon after the
device name.

In net-tools 1.60 ifconfig 1.42 (2001-04-13):

  # ifconfig eth0 | grep ^eth0
  eth0  Link encap:Ethernet  HWaddr 00:50:56:b5:00:23

In net-tools 2.10-alpha:

  # ifconfig eth0 | grep ^eth0
  eth0: flags=4163  mtu 1500

The problem you have is that new ":" in the first field is causing
problems for a tool that is processing the output of ifconfig and
never having had to deal with the colon before and doesn't strip it
off and therefore hands the resulting string "eth0:" off to further
processing which fails because the colon isn't part of the device
name.

  eth0: flags=4163  mtu 1500
  ^ colon is causing you problems

I hope that sums up the basic facts.  Please correct any
misunderstanding in the above if so.

I think you got distracted in the cascade of problems downstream of
that because then the tool causing you problems is apparently trying
to use "eth0:" without stripping the colon off of it in order to get a
handle on the device name.  But "eth0:" isn't the device name.  That
colon is just there as an indicator.

Note that the problem you are having is with an output format change
of 'ifconfig' which is part of the 'net-tools' package but you filed
this bug against the 'iproute2' package.  I am a long time complainer
when long time tools change without significant reason.  But that is
the best reason to be running Sid Unstable so as to be able to detect
these problems and file a bug before they hit Testing and become a
potential release candidate.  Better to catch it in Sid than Testing.

I think this bug should be reassigned to the net-tools package with a
request to revert the output format change of ifconfig.  Sure parsing
the output of this legacy command arguably isn't a good idea.  But
changing the output format is going to catch a lot of programs that
have been parsing it for decades.  [[However if the goal is to
deprecate ifconfig then forcing changes is one way to force people to
move.  Because they will have to update their parsing in order to work
at all.]]

> This agent is proprietary, so I can only share the basic cases it
> uses to get the interfaces.

Worse I am sure it is only approved on other platforms but you are
running it on Debian because you prefer Debian and it works there.
And so you are working at a support disadvantage because you want to
upgrade to Testing for some reason and are trying to make things work.
At least that has been my case many times with proprietary software.
Hopefully I am close on this analysis.

Questions: Can you make any modifications to the software locally?  Is
it a script?  It must be because you seem to have deep knowledge of
it.  Or did you find this by running 'strings' on the binary?  I have
some possible suggestions for working around this depending upon what
additional information you provide.

> Now, back to the first case, if that "ifconfig |grep flags="
> worked, which it only did on Debian 9 Stretch, it would use the
> below command to grab the interface information. But note, it's
> running based on the output of eth0: and not just eth0.

If you can modify the parsing code then why not simply remove the
trailing colon from the field name?  At the same time convert from
using 'ifconfig' to 'ip'.  If an old dog like me can learn the new
tricks then that should show that it isn't impossible for others.

'ifconfig' only knows about the legacy networking and can't manage or
report on the newer networking features that have been added to the
kernel in recent years.  If making any changes at all then it is
better to migrate from 'ifconfig' to 'ip' at that time.

> /sbin/ip -o link show eth0: |grep ether - This will NOT run on my
> Debian 9 Stretch because from the output it got from ifconfig with
> the eth0:, eth0: becomes invalid as a device name. The whole point
> of the bug report is to point out that extra colon that throws
> everything off. The only way for this to work on Stretch is without
> the colon at the end.

I now understand your complaint and I see the issue but I see the
issue differently than you described it.  Your description makes it
appear that you think the colon must be part of the device name
because it appears in the first field and then are trying to use it
with the 'ip' command as the device 

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

[Christoph Egger]

Hi

FWIW on the 3.2 build (with the patch) I started untill I noticed it
wasn't quite the right version

Steven Chamberlain  writes:
> Andreas Beckmann wrote:
>>  292 - RunCMake.Configure (Failed)
>
> Could someone with access to the hurd-i386 or kfreebsd porter boxes
> try the attached patch please?

Start 284: RunCMake.Configure
284/371 Test #284: RunCMake.Configure ...***Failed  
  3.19 sec

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Bug#820222: asterisk-config: Please set context on default

[Jonas Smedegaard]

Quoting asu (2016-04-07 00:15:50)
> 
> 
> On 04/06/2016 11:05 PM, Jonas Smedegaard wrote:
> > Hi Corcodel,
> >
> > Quoting Corcodel Marian (2016-04-06 19:56:35)
> >> On asterisk context is set on public relative to examples from
> >> users.conf which require default context(aka local).
> >> When an new user try to use extensions bellow 6000 is hard to handle
> >> this situation.On users.conf have context=international which is more
> >> inapropiate.
> > Not sure I understand exactly what it is you describe (english is not my
> > native language, and it seems it isn't yours either).
> >
> > It sounds like you understand this issue well: Could you perhaps provide
> > a concrete suggestion of what you believe should be changed?
> >
> >
> > Regards,
> >
> >   - Jonas
> On sip.conf file replace "context=public " with ";context=default"

Ahh.  Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#820222: asterisk-config: Please set context on default

[asu]

On 04/06/2016 11:05 PM, Jonas Smedegaard wrote:

Hi Corcodel,

Quoting Corcodel Marian (2016-04-06 19:56:35)

On asterisk context is set on public relative to examples from
users.conf which require default context(aka local).
When an new user try to use extensions bellow 6000 is hard to handle
this situation.On users.conf have context=international which is more
inapropiate.

Not sure I understand exactly what it is you describe (english is not my
native language, and it seems it isn't yours either).

It sounds like you understand this issue well: Could you perhaps provide
a concrete suggestion of what you believe should be changed?


Regards,

  - Jonas

On sip.conf file replace "context=public " with ";context=default"

Bug#820250: calibre: rebuild against Qt 5.6

[Marc J. Driftmeyer]

Source: calibre
Version: 2.54
Severity: normal

Dear Maintainer,

When you have time I would appreciate being able to move a large portion of my 
Qt installation to 5.6.0, but Calibre/Calibre-bin are holding everything up 
with its build depends. The sooner it gets rebuilt against Qt 5.6.0 the better.

- Marc J. Driftmeyer


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

Kernel: Linux 4.4.0-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)

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

[Christoph Egger]

Steven Chamberlain  writes:
> Steven Chamberlain wrote:
>> Could someone with access to the hurd-i386 or kfreebsd porter boxes
>> try the attached patch please?
>
> Here's how to run that test on its own, verbosely, in an already-built
> Debian build tree:
>
> $ Build/bin/cmake "-DCMAKE_MODULE_PATH=Tests/RunCMake"
> "-DRunCMake_GENERATOR=Unix Makefiles" "-DRunCMake_GENERATOR_PLATFORM="
> "-DRunCMake_GENERATOR_TOOLSET="
> "-DRunCMake_MAKE_PROGRAM=/usr/bin/make"
> "-DRunCMake_SOURCE_DIR=$(pwd)/Tests/RunCMake/Configure"
> "-DRunCMake_BINARY_DIR=$(pwd)/Build/Tests/RunCMake/Configure" "-P"
> "Tests/RunCMake/Configure/RunCMakeTest.cmake"

I have the build running on falla currently and it's already in the
testsuite so I'll just wait for it to finish

  Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer


signature.asc
Description: PGP signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

[Steven Chamberlain]

Steven Chamberlain wrote:
> Could someone with access to the hurd-i386 or kfreebsd porter boxes
> try the attached patch please?

Here's how to run that test on its own, verbosely, in an already-built
Debian build tree:

$ Build/bin/cmake "-DCMAKE_MODULE_PATH=Tests/RunCMake" 
"-DRunCMake_GENERATOR=Unix Makefiles" "-DRunCMake_GENERATOR_PLATFORM=" 
"-DRunCMake_GENERATOR_TOOLSET=" "-DRunCMake_MAKE_PROGRAM=/usr/bin/make" 
"-DRunCMake_SOURCE_DIR=$(pwd)/Tests/RunCMake/Configure" 
"-DRunCMake_BINARY_DIR=$(pwd)/Build/Tests/RunCMake/Configure" "-P" 
"Tests/RunCMake/Configure/RunCMakeTest.cmake"

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#811707: gcc-6 fails to compile a valid code

[Gianfranco Costamagna]

Hi Robert,



>Actually it was me, who posted the code. I've just seen your e-mail
>after the issue was re-assigned back to ucl.


oops, sorry!

>I can still reproduce the issue on i386, but I guess you use amd64. In


true, indeed

>such a case you need to replace `4' with `8' (the value `4' was expanded>from 
>sizeof(long) by the macro included at the bottom of my previous
>e-mail):


oops, sure

>(experimental_amd64-dchroot)robert@barriere:~$ gcc-5 ./test.c
>/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o: In
>function `_start':
>(.text+0x20): undefined reference to `main'


you need a -c there :)

>
>I've  found quite similar gcc bug
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55009
>
>The reasoning given there suggests that you are right, and this is not
>gcc bug, as the expression 1l << 63 on amd64 or 1l << 31 on i386
>involves undefined behaviour.
>
>I'll try to fix the issue at ucl side by switching to _Static_assert.


not sure, feel free to investigate more :)
thanks for the heads up!

cheers,

Gianfranco

Bug#816215: more info

[Dima Kogan]

Hi. Instead of trying to figure out why "sudo wpa_gui" works for you and
not me, I just looked to see what it would take to make wpa_gui for for
the non-root user.

You mentioned something about the netdev group, but none of the wpa
control files have this group; I don't know if this is a bug in the
wpasupplicant package. Specifically, I had

$ ls -ld /run/wpa_*
-rw-r--r-- 1 root root  6 Apr  6 15:08 /run/wpa_action.wlp3s0.pid
drwxr-x--- 2 root root 60 Apr  6 15:08 /run/wpa_supplicant
-rw-r--r-- 1 root root  6 Apr  6 15:08 /run/wpa_supplicant.wlp3s0.pid

$ ls -l /run/wpa_supplicant/wlp3s0 
srwxrwx--- 1 root root 0 Apr  6 15:08 /run/wpa_supplicant/wlp3s0

Manually giving access to all users makes this work:

$ sudo chmod 777 /run/wpa_supplicant
$ sudo chmod 777 /run/wpa_supplicant/wlp3s0

After this I can run wpa_gui as a regular user, and things continue to
work. Is this closer to how wpa_gui is supposed to be used? Is there a
bug in the supplicant packaging?

If this IS closer to the intent, then wpa_gui should be shipped in
/usr/bin, not /usr/sbin.

Thanks

Bug#820249: Please switch from softhsm to softhsm2

[Ondřej Surý]

Package: src:golang-github-miekg-pkcs11
Version: 0.0~git20151009.0.793689b
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

could you please switch the golang-github-miekg-pkcs11 to use
(lib)softhsm2 (>= 2.1.0-2)?

I am going to kill softhsm(1) from the archive and yours + mod-gnutls
library are the only users of old softhsm(1) (and both just for the
tests).

Cheers,
Ondrej

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

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

Bug#820248: Please switch from softhsm to softhsm2

[Ondřej Surý]

Package: src:mod-gnutls
Version: 0.7.2-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Daniel,

could you please switch the mod-gnutls to use (lib)softhsm2 (>= 2.1.0-2)?

I am going to kill softhsm(1) from the archive and yours and some
golang pkcs11 library are the only users of the old softhsm(1) (and
both just for the tests).

Cheers,
Ondrej

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

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

Bug#820247: mount: fails to upgrade from 'sid' - trying to overwrite /usr/share/bash-completion/completions/umount

[Andreas Beckmann]

Package: mount
Version: 2.28~rc2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../mount_2.28~rc2-1_amd64.deb ...
  Unpacking mount (2.28~rc2-1) over (2.27.1-6) ...
  dpkg: error processing archive 
/var/cache/apt/archives/mount_2.28~rc2-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/bash-completion/completions/umount', which 
is also in package bash-completion 1:2.1-4.2
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/mount_2.28~rc2-1_amd64.deb


cheers,

Andreas


bash-completion=1%2.1-4.2_mount=2.28~rc2-1.log.gz
Description: application/gzip

Bug#820213: console-setup: The non breaking space has a bad symbol with fr_FR charset

[Anton Zinoviev]

On Thu, Apr 07, 2016 at 01:06:10AM +0300, Anton Zinoviev wrote:
> 
> Unfortunately, at the moment I have no idea what might have caused this 
> strange behaviour.

Ah, it just occured to me that maybe you have observed the following:

1. fsck displays its messages with correct non-break space.

2. A second later console-setup changes the font and only then the 
   non-break space is replaced with "strange" symbol.

Am I right?  If so, then I think I understand the cause of the problem 
and the possible fixes.

Anton Zinoviev

Bug#820062: orthanc and orthanc-doc: error when trying to install together

[Andreas Beckmann]

On 2016-04-05 19:29, Ralf Treinen wrote:
> How it got there I cannot tell. AFAIK, arch=all packages are not rebuild
> by autobuilders, so the -doc package in the archive should be the one
> that you have uploaded. Maybe that has changed, as the mail by anbe seems

arch:all packages can be build by the buildds for sid and experimental:

https://lists.debian.org/debian-devel-announce/2015/08/msg7.html


Andreas

Bug#819976: [Xymon] [PATCH] Fix debian init script problem for Container based virtualization

[Axel Beckert]

Hi Joel,

On Mon, Apr 04, 2016 at 03:50:04PM +0200, Joel Brunenberg wrote:
> I just now submitted a debian bug for this because I hope that it gets
> fixed in Debian stable,
[...]
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819976

Bugs of severity "normal" usually don't get fixed/backported to
stable. The risk that the fix breaks something else and makes the
situation even worse in stable is too high.

But we will very likely fix this in Unstable/Testing and hence for the
next Debian Stable release dubbed "Stretch" (Debian 9).

Kind regards, Axel Beckert
-- 
Axel Beckert    support: +41 44 633 26 68
IT Services Group, HPT H 6  voice: +41 44 633 41 89
Departement of Physics, ETH Zurich
CH-8093 Zurich, Switzerlandhttp://nic.phys.ethz.ch/

Bug#820246: tiptop: pressing 'e' triggers "floating point exception"

[Tomasz Buchert]

Package: tiptop
Version: 2.3-2+b1
Severity: normal

Dear Maintainer (myself),

if you run tiptop as the root user and then hit 'e' to list errors,
then it will trigger a floating point exception and tiptop will exit.
Presumably, this happends because there no errors to show if you run
by root, and a division by zero happens somewhere.

It's a guess which has to be verified.

Tomasz

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

Kernel: Linux 4.4.6 (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 tiptop depends on:
ii  libc62.22-5
ii  libncurses5  6.0+20160319-1
ii  libtinfo56.0+20160319-1
ii  libxml2  2.9.3+dfsg1-1

tiptop recommends no packages.

tiptop suggests no packages.

-- no debconf information

Bug#820213: console-setup: The non breaking space has a bad symbol with fr_FR charset

[Anton Zinoviev]

On Wed, Apr 06, 2016 at 07:02:03PM +0200, rpnpif wrote:
> 
> In fr_FR.UTF-8 charset, Lat15 for console-setup or also guest charset, 
> console-setup change the non-breaking space in the boot message of 
> systemd to garbage character.

Unfortunately, at the moment I have no idea what might have caused this 
strange behaviour.  Moreover, I am unable to reproduce it.  I booted my 
system with French locale and fsck displayed the non-break space 
correctly.

Could you check the following two things.  First, is everything correct 
after the system has booted?  Try for example on the text console as 
root the following commands:

  dd if=/dev/zero of=/tmp/test.hdi count=10
  mkfs.ext4 /tmp/test.hdi
  fsck.ext4 /tmp/test.hdi

Second, when do the following messages occur?

> /dev/sda2€: propre ...
> /dev/sda3€: propre ...

Before the framebuffer is activated (big letters) or afterwards (small 
letters)?  Can you observe the exact time when console-setup modifies 
the font (not the size of the letters but their shape)?

> Whatever the font, a non-breaking space should be displayed in fr_FR 
> before this colon or at least a simple space. The non-breaking space 
> is better.

On the console 'non-breaking space' = 'space'.

Anton Zinoviev

Bug#820162: w3m: SEGFAULT on bogus HTML

[Tatsuya Kinoshita]

Control: tags -1 + patch pending


pgpBq9KCZoqJl.pgp
Description: PGP signature

Bug#820245: ITP: groestlcoin -- peer-to-peer network based digital currency

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: groestlcoin
  Version : 2.11.0
  Upstream Author : The Groestlcoin developers
* URL : http://www.groestlcoin.org/
* License : Expat
  Programming Lang: C++
  Description : peer-to-peer network based digital currency

 Groestlcoin is an experimental new digital currency that enables
 instant payments to anyone, anywhere in the world. Groestlcoin uses
 peer-to-peer technology to operate with no central authority: managing
 transactions and issuing money are carried out collectively by the
 network. Groestlcoin Core is the name of open source software which
 enables the use of this currency.
 .
 Grøstl is a cryptographic hash function submitted to a NIST competition
 - and was chosen as one of the five finalists of the competition.  The
 name is a word play on the researchers being from Austria (the dish
 "gröstl") and Denmark (the letter "ø")).

The package will be maintained in the Debian Bitcoin Team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXBYjmAAoJECx8MUbBoAEhqOQP/2iSDYEqGAMdf5Ge/X9YB5Ba
ItuBcuDAvZNEhaykBlG0PR1Jmnmav1l0A7q9eGH8n+vrbTwT/oGnGerXVODX7Hy5
rRa+FoIQOnUkYs2VfAe2M68KsN8G4zxieyLANHuUE6ufNUmJSf+3QWWWRtH8WQiw
vw474fUtoBp1W8TXCHKm7ZRwXbnHCCRWy08iW29XcUXroJCQE/yM32a4yVhcHOPu
kLqfM9EM478PVjYu0iU4sNLq4P3+XELIlmABpJeF1RFWRCNIbKyIiQG3+2PzhsNt
OwS+/6cym6CcwPOVPeoqUzsMTJb0YtpYzU8LXZV1Ng8z5lDERlMqg2A4vaChP0I1
bCzKqtXRrZltCBAn8p1MZFmBnWsPgbUCIzfvUz205/kIDTuHSmKZ1dE66lnsz7z4
gBNNSNE9tg0agFeE6qWLLUYiF+T6APYpi9xAhcEM2JQY1vF6ANwglcvUMkhk6XzB
GlDlF6GpbzHm7jA3ylwpgtdBd35lji/urc3njFVzI0mNAj6gXKkuVSkSmBy7irfn
oOqD70OWtdWpqznFfiAA3QBd/7gopMO2aiANDtUfL9cSL9bCWFmlVYUwIlSNnAL1
BkrHOgMc36TnUN3s/CWn1YVbUiHzDuku1H0Xwq27jTfwV3d2EwpGLm9z8hFeuRS8
qD7akoOswm4pxMG+VDoq
=8nTQ
-END PGP SIGNATURE-

Bug#820244: libldap: use-after-free in GnuTLS-related code (patch available)

[Maciej Puzio]

Package: openldap
Version: 2.4.42+dfsg-2

Code located in file libraries/libldap/tls_g.c, containing an
interface to GnuTLS, suffers from a bug causing the configuration
variable tls_reqcert to be read from previously freed memory, thus
assuming random values or causing a segfault. This has been observed
in slapd during syncrepl connection retries, but may possibly happen
in other circumstances. Depending on the configuration, this can lead
to TLS handshake failures, a silent omission of certificate
verification (a security issue) or slapd unexpectedly crashing. This
bug cannot be worked around by configuration changes. In order to
avoid it, it is necessary to recompile package openldap either with a
patch or with OpenSSL support (in which case the problematic code path
is avoided).

Known affected versions are 2.4.41 to 2.4.44, but it is likely that
earlier versions also contain this bug. The bug has been reported to
OpenLDAP project and fixed in their git master:
OpenLDAP commit: 283f3ae1713df449cc170965b311b19157f7b7ea
Link: 
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=283f3ae1713df449cc170965b311b19157f7b7ea
More details are available on OpenLDAP bug tracker at:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8385

Related Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557248

Thank you

Bug#820093: tiptop: does not display any task when running as root

[Tomasz Buchert]

Hi again Lucas,

so I did some digging and it seems that it actually works the same way
in Grid5000 and my machine.

If you add a user (eg., adduser test) and then start some processes as
by user, they will be shown in "tiptop -i -U", if you run it by root.

If you look into the code, when run by root, tiptop shows all
processes of *non-root* users. The relevant code is in process.c:340:

if (((my_uid != 0) && (uid == my_uid)) || /* not root, monitor mine */
((my_uid == 0) && (uid != 0)))/* I am root, monitor all others*/
  skip_by_user = 0;

What happens is that if the user running tiptop is root (my_uid == 0)
*and* the process to watch is owned by root (uid == 0) then the
process wil be skipped.  This is consistent on my personal machine, where
when run by root, tiptop shows only my regular user's processes.

This is still buggy, there seems to way to trace root processes AFAICT.
Moreover, the "-K" option (show kernel processes) seems to not work at all.
I'm letting the upstream know about it.

Cheers,
Tomasz

PS. I also found another, unrelated bug which I'm going to submit now.


signature.asc
Description: PGP signature

Bug#805701: clisp on hurd

[Flávio Cruz]

It has been sent upstream, but the clisp project has no maintainers at the
moment.

Thanks
Flavio

On 3 April 2016 at 23:20, Christoph Egger  wrote:

> Control: severity -1 important
> Control: tag -1 +patch
>
> Hi!
>
> I'll include that in the next upload for sure .. hopefully this
> week. Ideally we find a arm solution untill then. Has this patch been
> sent upstream?
>
>   Christoph
>
> --
> 9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
> Debian Developer | Lisp Hacker | CaCert Assurer
>



-- 
Flávio Cruz / flavioc...@gmail.com

Bug#715426: Version 0.10.1

[Tianon Gravi]

On 6 April 2016 at 14:23, Tianon Gravi  wrote:
> This isn't really as important in the context of Debian, since we'll
> supply a separate "debian/", but it's definitely nice to keep them in
> parity, so I'll go do a re-sync and see where we're at!

dh_install: Cannot find (any matches for) "refind-mkdefault" (tried in
"." and "debian/tmp")
dh_install: refind missing files: refind-mkdefault
dh_install: missing files, aborting

Was this file added after 0.10.2 was cut?  Should I be syncing against
0.10.2's source tree instead of just master?


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

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

[Steven Chamberlain]

Hi,

Andreas Beckmann wrote:
>   292 - RunCMake.Configure (Failed)

Could someone with access to the hurd-i386 or kfreebsd porter boxes
try the attached patch please?

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++ b/Tests/RunCMake/Configure/RunCMakeTest.cmake
@@ -16,7 +16,7 @@
 file(WRITE "${input}" "1")
 file(WRITE "${depend}" "1")
 run_cmake(RerunCMake)
-execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
+execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 2) # handle 1s resolution
 file(WRITE "${input}" "2")
 run_cmake_command(RerunCMake-build1 ${CMAKE_COMMAND} --build .)
 file(WRITE "${depend}" "2")


signature.asc
Description: Digital signature

Bug#820162: w3m: SEGFAULT on bogus HTML

[Tatsuya Kinoshita]

Control: -1 + patch pending

>>cat $file | w3m -dump
>> (gdb) bt
>> #0  wc_any_to_ucs (cc=...) at ucs.c:274
>
> Confirmed, thank you.

Fixed in the development repo.

  - 
https://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=7bb2a4671503c41d63989dcef9ef54dea0c73b43

Will be fixed in the next upload for unstable.

Thanks,
--
Tatsuya Kinoshita


pgpwc5SaBkHiG.pgp
Description: PGP signature

Bug#820225: libsqlite3-0: Segmentation fault (core dumped)

[Chris Lamb]

Hi,

> libsqlite3-0: Segmentation fault (core dumped)

Backtrace attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
lamby@d0a58556b1e8(lamby-debian-sid):/tmp/buildd/python-django-1.9.5/tests% gdb 
/usr/bin/python ./core  
  0 [ 22:45 ]
GNU gdb (Debian 7.10-1+b1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python...Reading symbols from 
/usr/lib/debug/.build-id/8d/04a3ae38521cb7c7928e4a7c8b1ed385e763e4.debug...done.
done.
[New LWP 2806]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `python2.7 ./runtests.py --verbosity=2 --parallel=1'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f5fda58df46 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x7f5fda58df46 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f5fd75f9125 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#2  0x7f5fd763e9fa in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#3  0x7f5fd76400e9 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#4  0x7f5fd7642714 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#5  0x7f5fd7669b5b in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#6  0x7f5fd766e397 in sqlite3_step () from 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#7  0x7f5fd78e207e in pysqlite_step (statement=0xcbffb98, 
connection=) at 
/build/python2.7-Cem15J/python2.7-2.7.11/Modules/_sqlite/util.c:37
#8  0x7f5fd78e5402 in _pysqlite_query_execute (self=0x7f5fcb141050, 
multiple=, args=) at 
/build/python2.7-Cem15J/python2.7-2.7.11/Modules/_sqlite/cursor.c:639
#9  0x004b1683 in PyObject_Call () at ../Objects/abstract.c:2546
#10 0x004cf000 in PyEval_CallObjectWithKeywords () at 
../Python/ceval.c:4219
#11 0x0053f518 in methoddescr_call.lto_priv () at 
../Objects/descrobject.c:247
#12 0x004b1683 in PyObject_Call () at ../Objects/abstract.c:2546
#13 0x004cab8a in do_call (nk=, na=2, 
pp_stack=0x7ffc373fe090, func=0x7f5fd7b87488) at ../Python/ceval.c:4567
#14 call_function (oparg=, pp_stack=0x7ffc373fe090) at 
../Python/ceval.c:4372
#15 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#16 0x004c32e5 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#17 0x004cac76 in fast_function (nk=0, na=, n=, pp_stack=0x7ffc373fe2a0, func=0x7f5fd7b1f578) at ../Python/ceval.c:4445
#18 call_function (oparg=, pp_stack=0x7ffc373fe2a0) at 
../Python/ceval.c:4370
#19 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#20 0x004c32e5 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#21 0x004cac76 in fast_function (nk=0, na=, n=, pp_stack=0x7ffc373fe4b0, func=0x7f5fd93182a8) at ../Python/ceval.c:4445
#22 call_function (oparg=, pp_stack=0x7ffc373fe4b0) at 
../Python/ceval.c:4370
#23 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#24 0x004ca95f in fast_function (nk=, na=, n=, pp_stack=0x7ffc373fe600, func=0x7f5fd7b921b8) at 
../Python/ceval.c:4435
#25 call_function (oparg=, pp_stack=0x7ffc373fe600) at 
../Python/ceval.c:4370
#26 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#27 0x004ca95f in fast_function (nk=, na=, n=, pp_stack=0x7ffc373fe750, func=0x7f5fd7b92398) at 
../Python/ceval.c:4435
#28 call_function (oparg=, pp_stack=0x7ffc373fe750) at 
../Python/ceval.c:4370
#29 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#30 0x004ca95f in fast_function (nk=, na=, n=, pp_stack=0x7ffc373fe8a0, func=0x7f5fd8b33c08) at 
../Python/ceval.c:4435
#31 call_function (oparg=, pp_stack=0x7ffc373fe8a0) at 
../Python/ceval.c:4370
#32 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#33 0x004c32e5 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#34 0x004cb364 in fast_function (nk=0, na=, n=, pp_stack=0x7ffc373feab0, func=0x7f5fd82ca140) at ../Python/ceval.c:4445
#35 call_function (oparg=, pp_stack=0x7ffc373feab0) at 
../Python/ceval.c:4370
#36 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#37 0x004c32e5 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#38 0x004cb364 in fast_function (nk=0, na=, n=, pp_stack=0x7ffc373fecc0, func=0x7f5fd82ca410) at 

Bug#817874: Bug#819881: radeon_fence_ref BUG: unable to handle kernel NULL pointer dereference

[Michael Lange]

On Sun, 03 Apr 2016 14:32:59 +0100
Ben Hutchings  wrote:

(...)
> Sorry about this.  There was one earlier similar report which I meant
> to investigate but didn't find time before the point release.
> 
> All three call traces are very similar and, based on the functions
> listed, I believe the attached patch (taken from the next 3.16.7-ckt
> stable update) should fix the bug.  Please test that, following the
> instructions at
> 

Thanks Ben (and sorry for the late reply). The patch you sent seems to
also fix 817874, no more frozen screens here, good work :)

Kind regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

[Steven Chamberlain]

Hi,

Andreas Beckmann wrote:
> The following tests FAILED:
>   113 - BuildDepends (Failed)

I finally figured this out!

The BuildDepends test will fail when run on a filesystem not having
sub-second granularity.  So for example, it fails on kfreebsd UFS, and
whatever filesystem the hurd-i386 buildds have, and also maybe some
Linux fileystems too.

| if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
|   if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
|   IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
| message(STATUS "multi2-real.txt is newer than multi2-stamp.txt")
|   else()
| message(SEND_ERROR "Project did not initially build properly: "
|   "multi2-real.txt is not newer than multi2-stamp.txt")

If multi2-real.txt and multi2-stamp.txt are created within 1 second of
each other, the test will most likely fail on those filesystems.

I think the testcase should allow something like "newer or equal to".
I don't know if there's a CMake macro to do exactly that.

By reversing the operands and the logic, it is possible to test for
"multi2-stamp.txt newer than multi2-real.txt" as a failure condition,
and therefore "multi2-real.txt newer or equal to multi2-stamp.txt" will
be regarded a success, which is exactly what we want here.

A patch is attached.  I can't test it fully, because my kfreebsd systems
are not affected by this bug:  they use ZFS, which does have sub-second
file timestamps.  At least with this patch applied I didn't see any
regression, and on UFS... I feel lucky that this will fix it.


>   292 - RunCMake.Configure (Failed)

I didn't look at that other test failure yet...

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
Date: Wed, 06 Apr 2016 22:28:55 +0100
From: Steven Chamberlain 
Subject: Tests: allow newer or equal timestamps in BuildDepends

Allow timestamps to be newer *or equal* in BuildDepends, in case the
filesystem lacks sub-second granularity (such as UFS on FreeBSD).

The test logic is changed from A > B, to !(B > A), i.e. A >= B

--- a/Tests/BuildDepends/CMakeLists.txt
+++ b/Tests/BuildDepends/CMakeLists.txt
@@ -202,12 +202,12 @@
 endif()
 
 if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
-  if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
-  IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
-message(STATUS "multi2-real.txt is newer than multi2-stamp.txt")
-  else()
+  if(${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt
+  IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
 message(SEND_ERROR "Project did not initially build properly: "
-  "multi2-real.txt is not newer than multi2-stamp.txt")
+  "multi2-real.txt timestamp is not >= multi2-stamp.txt")
+  else()
+message(STATUS "multi2-real.txt timestamp is >= multi2-stamp.txt")
   endif()
 else()
   message(SEND_ERROR "Project did not initially build properly: "
@@ -216,12 +216,12 @@
 
 if(TEST_MULTI3)
   if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi3-real.txt)
-if(${BuildDepends_BINARY_DIR}/Project/multi3-real.txt
-IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi3-stamp.txt)
-  message(STATUS "multi3-real.txt is newer than multi3-stamp.txt")
-else()
+if(${BuildDepends_BINARY_DIR}/Project/multi3-stamp.txt
+IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi3-real.txt)
   message(SEND_ERROR "Project did not initially build properly: "
-"multi3-real.txt is not newer than multi3-stamp.txt")
+"multi3-real.txt timestamp is not >= multi3-stamp.txt")
+else()
+  message(STATUS "multi3-real.txt timestamp is >= multi3-stamp.txt")
 endif()
   else()
 message(SEND_ERROR "Project did not initially build properly: "
@@ -405,12 +405,12 @@
 endif()
 
 if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
-  if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
-  IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
-message(STATUS "multi2-real.txt is newer than multi2-stamp.txt")
-  else()
+  if(${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt
+  IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
 message(SEND_ERROR "Project did not rebuild properly: "
-  "multi2-real.txt is not newer than multi2-stamp.txt")
+  "multi2-real.txt timestamp is not >= multi2-stamp.txt")
+  else()
+message(STATUS "multi2-real.txt is >= multi2-stamp.txt")
   endif()
 else()
   message(SEND_ERROR "Project did not rebuild properly: "
@@ -419,12 +419,12 @@
 
 if(TEST_MULTI3)
   if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi3-real.txt)
-if(${BuildDepends_BINARY_DIR}/Project/multi3-real.txt
-IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi3-stamp.txt)
-  message(STATUS "multi3-real.txt is newer than multi3-stamp.txt")
-else()
+if(${BuildDepends_BINARY_DIR}/Project/multi3-stamp.txt
+IS_NEWER_THAN 

Bug#820212: iproute2: Colons in ethernet names under /sbin/ifconfig and /sbin/ip are not being recognized in Stretch

[Justin McZeal]

Hello Bob,
I went ahead and removed eth0:1 as we don't use it. So let's negate that factor 
and start over.

Starting from the beginning, there is this firewall agent we have installed 
that uses some custom coding to grab the interfaces on our server. Their agent 
is only working on Debian 8 (Jessie) and below. It doesn't work on Debian 9 
(stretch), which are the packages we are using on our server.

When you start with a regular Debian 8 image, you get output similar to the 
below. And this is just Debian 8.3 server with iproute2=3.16.0-2. Please note, 
my debian 8 and debian 9 servers are completely different, so deb8 has 
eth0/eth1 and deb9 has just eth0.


# ifconfig
eth0  Link encap:Ethernet  HWaddr 00:50:56:b5:00:23
  inet addr:10.X.X.X Bcast:10.X.X.X  Mask:255.255.255.0
  inet6 addr: fe80::250:56ff:feb5:23/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:326656 errors:0 dropped:756 overruns:0 frame:0
  TX packets:11764 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:34993035 (33.3 MiB)  TX bytes:1650044 (1.5 MiB)

eth1  Link encap:Ethernet  HWaddr 00:50:56:b5:00:02
  inet addr:10.X.X.X  Bcast:10.X.X.X  Mask:255.255.255.0
  inet6 addr: fe80::250:56ff:feb5:2/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:609769 errors:0 dropped:39962 overruns:0 frame:0
  TX packets:8863 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:47317216 (45.1 MiB)  TX bytes:11631004 (11.0 MiB)

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:6493582 errors:0 dropped:0 overruns:0 frame:0
  TX packets:6493582 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:733170898 (699.2 MiB)  TX bytes:733170898 (699.2 MiB)


If you upgrade said system from Debian 8 Jessie to Debian 9 Stretch, using 
apt-get dist-upgrade, you get complete package upgrades across the board. 
That's when your /sbin/ifconfig output changes to the below, where eth0 now 
becomes eth0: and so on. There is also some extra fields in there such as 
flags= and mtu on the first line.

# ifconfig
eth0: flags=4163  mtu 1500
inet 96.126.108.191  netmask 255.0.0.0  broadcast 96.255.255.255
inet6 2600:3c03::f03c:91ff:fe70:989d  prefixlen 64  scopeid 0x0
inet6 fe80::f03c:91ff:fe70:989d  prefixlen 64  scopeid 0x20
ether f2:3c:91:70:98:9d  txqueuelen 1000  (Ethernet)
RX packets 1788  bytes 697207 (680.8 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2168  bytes 873594 (853.1 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 0  (Local Loopback)
RX packets 828  bytes 530016 (517.5 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 828  bytes 530016 (517.5 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This agent is proprietary, so I can only share the basic cases it uses to get 
the interfaces.

1st case)
/sbin/ifconfig | grep flags= | awk '{print $1}'  -- On a Debian 8 system, this 
outputs nothing, as flags= is not on the ifconfig of these debian versions. It 
IS however on Debian 9 Stretch.
Debian 9 Stretch Output:

eth0:
lo:

If this doesn't give an output, like on Debian 8 Jessie, it moves on to the 
below check:
/sbin/ifconfig | grep Ethernet | awk '{print $1}' -- On a Debian 8 system, this 
outputs:

eth0
eth1


Notice, we have eth0 and lo with a colon at the end on Debian 9 Stretch. This 
is from stock package upgrades, where that colon is now in there after doing a 
dist-upgrade. This is not normal format for Debian 8 and below (when you run 
ifconfig).


Now, back to the first case, if that "ifconfig |grep flags=" worked, which 
it only did on Debian 9 Stretch, it would use the below command to grab the 
interface information. But note, it's running based on the output of eth0: and 
not just eth0.

/sbin/ip -o link show eth0: |grep ether - This will NOT run on my Debian 9 
Stretch because from the output it got from ifconfig with the eth0:, eth0: 
becomes invalid as a device name. The whole point of the bug report is to point 
out that extra colon that throws everything off. The only way for this to work 
on Stretch is without the colon at the end.

Debian 9 Stretch:
# /sbin/ip -o link show eth0: |grep ether
RTNETLINK answers: No such device
Cannot send link get request: No such device

# /sbin/ip -o link show eth0 |grep ether
2: eth0:  mtu 1500 qdisc 

Bug#820227: NPE on keyevent in josm

[Samuel Thibault]

Samuel Thibault, on Wed 06 Apr 2016 23:37:57 +0200, wrote:
> 820227 is another issue, apparently related to an entirely different
> codepath than the previously-reported issues.

And at worse for Stretch we can just disable the keyevent codepath as
done in the attached workaround patch.  It'll harm accessibility a bit,
but much less than disabling it completely by default.

Samuel
--- a/wrapper/org/GNOME/Accessibility/AtkWrapper.java.in
+++ b/wrapper/org/GNOME/Accessibility/AtkWrapper.java.in
@@ -664,6 +664,7 @@ public class AtkWrapper {
 if (!accessibilityEnabled)
   return;
 
+/*
 toolkit.addAWTEventListener(globalListener,
 AWTEvent.WINDOW_EVENT_MASK |
 AWTEvent.FOCUS_EVENT_MASK |
@@ -697,6 +698,7 @@ public class AtkWrapper {
 super.dispatchEvent(e);
   }
 });
+*/
   }
 
   public static void main(String args[]) {

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[Graham Inggs]

On 6 April 2016 at 20:31, Peter Colberg  wrote:
> Graham, should we remove these two archs from testing for the time
> being as you suggested?

I managed to get it building on armhf again in Ubuntu with a minor
change [1] and I have tested that it builds on a Debian armhf
porterbox.  I'll upload this to Debian soon, after the new openlibm
has built.

I don't think this will help with armel though.


[1] 
https://launchpadlibrarian.net/251298934/julia_0.4.5-1_0.4.5-1ubuntu1.diff.gz

Bug#813143: openjdk-7-jre-headless: Please re-disable atk bridge

[Samuel Thibault]

Control: close 813143 java-atk-wrapper/0.33.3-6
Control: reopen 820227
Control: reassign 820227 java-atk-wrapper
Control: retitle 820227 NPE on keyevent in josm

Hello,

Sebastiaan Couwenberg, on Wed 06 Apr 2016 21:58:36 +0200, wrote:
> It seems the changes in java-atk-wrapper (0.33.3-6) were not sufficient
> to resolve the issues it causes in JOSM.

Apparently so, yes.

> Today we got a new bugreport for josm (#820227) which is also caused by
> the ATK bridge, and resolved by disabling the assistive_technologies
> option in /etc/java-8-openjdk/accessibility.properties.

Ok, I can reproduce the issue indeed.

> Do you have any suggestions to fix java-atk-wrapper

I'll have a look.

> or should this issue be reassigned to openjdk-8-jre-headless to
> request disabling the option by default again?

The goal is to fix issues, not to work around them, so we need to keep
the atk bridge enabled by default, otherwise we won't even know about
the bugs, and thus never manage to enable it by default... I'm glad that
this particular bug does not make the application crash, at least.

> I've reopened #813143 because the issues experienced in JOSM are not
> fixed by java-atk-wrapper (0.33.3-6).

The issues that were reported in the past *are* fixed by 0.33.3-6, so
#813143 shouldn't be reopened.

820227 is another issue, apparently related to an entirely different
codepath than the previously-reported issues.

> I'm closing this issue because it's not an issue in JOSM can be easily
> worked around by disabling the assistive_technologies option.

Please don't do it this way: the information which is needed to fix the
bug is in #820227, so it's a reassign which makes sense, which I've just
done here.

Samuel

Bug#811707: gcc-6 fails to compile a valid code

[Robert Luberda]

control: tags -1 - moreinfo
control: tags -1 - unreproducible


On Mon, 4 Apr 2016 10:22:54 + (UTC) Gianfranco Costamagna
 wrote:
> 
> Hi, the code you posted fails on unstable/experimental with gcc-4.9, gcc-5 
> and gcc-6

Actually it was me, who posted the code. I've just seen your e-mail
after the issue was re-assigned back to ucl.


> gcc-6 test.c 
> test.c:1:12: error: size of array '__acc_cta' is negative
> extern int __acc_cta[1-2*!((1l << (8*4 -1)) < 0)];

I can still reproduce the issue on i386, but I guess you use amd64. In
such a case you need to replace `4' with `8' (the value `4' was expanded
from sizeof(long) by the macro included at the bottom of my previous
e-mail):

(experimental_amd64-dchroot)robert@barriere:~$ gcc-6 ./test.c
./test.c:1:12: error: variably modified '__acc_cta' at file scope
 extern int __acc_cta[1-2*!((1l << (8*8 -1)) < 0)];
^
(experimental_amd64-dchroot)robert@barriere:~$ gcc-5 ./test.c
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'

> 
> 
> not sure what is wrong, but seems not a bug in gcc.

I've  found quite similar gcc bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55009

The reasoning given there suggests that you are right, and this is not
gcc bug, as the expression 1l << 63 on amd64 or 1l << 31 on i386
involves undefined behaviour.

I'll try to fix the issue at ucl side by switching to _Static_assert.

Regards,
robert

Bug#787146: ITP: Gambatte - Game Boy and Game Boy Color emulator

[PICCORO McKAY Lenz]

the package in mentos was gone, please re-upload

mentors packages that has a related ITP must be mantain event erased
in the time!

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#820243: please build using lua5.2 instead of lua5.1

[Matthias Klose]

Package: src:apache2
Version: 2.4.18-2

looking at the sources, apache2 can be built using lua5.2 instead of lua5.1. 
Please use the more recent version.

Bug#784191: RFA: pgfouine - PostgreSQL log analyzer

[Christoph Berg]

Control: tags -1 moreinfo

Re: William Bonnet 2016-02-18 <56c5eb94.6040...@theitmakers.com>
> Hi Luis,
> 
> I am really interested in helping for this package. I am a PG user and
> i use pgfouine or pgbadger from time to time.
> 
> Are you still looking for help ?

Hi William,

pgfouine hasn't seen a new upstream release for half a decade, while
pgbadger is actively being developed. Is pgfouine doing anything for
you that pgbadger doesn't? If not, I'd propose to get pgfouine removed
instead.

Christoph


signature.asc
Description: PGP signature

Bug#820242: RM: libcorosync-dev libcorosync4 [all] -- RoQA; NBS; obsolete transitional arch:all packages

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

corosync no longer builds the transitional arch:all packages
libcorosync-dev and libcorosync4, manually decrufting them should
unblock automatic decrufting of a bunch of obsolete arch:any
packages no longer built by corosync, too.


Andreas

Bug#715426: Version 0.10.1

[Tianon Gravi]

On 12 December 2015 at 18:00, Rod Smith  wrote:
> * Steve Langasek , who maintains Ubuntu's shim
>   package, has stated that public keys are not subject to copyright
>   (which I'd gathered from other sources, too), and has suggested
>   omitting explicit mention of them from the debian/copyright file.
>   I've followed this advice, which clears up the last of the lintian
>   errors and warnings. If somebody who reviews the package objects,
>   we can add back the information we had before and omit the
>   remaining keys. Since the maintainer of Ubuntu's shim package
>   has suggested this solution, though, I'd like to run with it.

Awesome, that makes sense to me!  (and vorlon's usually pretty reliable :D)

> * I've tweaked a few files in the debian directory on my own git
>   archive and in the tarball release to reflect my own PPA needs.
>   The biggest of these is debian/changelog, but I've also made a
>   couple of changes to debian/control. I figure these differences
>   can be handled via diffs when creating the official Debian
>   package. If that's a problem, then I'm sure we can work something
>   out. If necessary, I'll do a 0.10.1.1 release with Debian packaging
>   tweaks and we can base the first Debian release off of it.

This isn't really as important in the context of Debian, since we'll
supply a separate "debian/", but it's definitely nice to keep them in
parity, so I'll go do a re-sync and see where we're at!

> I think that's about it. Unless there are other outstanding issues. I'm
> ready to push this version for inclusion in Debian! Tianon, if you can
> advise me on the next step, I'd appreciate it. Thanks!

Sorry for being so badly delayed on this!  Your patience is
appreciated.  Always way too much going on at any given time... D:

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

Bug#772047: RFH: pgpool2 -- connection pool server and replication proxy for PostgreSQL

[Christoph Berg]

Re: William Bonnet 2016-03-22 <56f1b23f.8020...@theitmakers.com>
> Hi Christoph,
> 
> Thanks for your answer. Is there some urgent things to do ? Any advice
> about what I should  start with ?
> 
> Maybe we can talk about this on IRC ?  my Nick is _william_ on
> irc.debian.org (also on freenode).

Hi William,

sorry that it took me a long time to answer again.

Pgpool is a complex piece of software, and the problem with the
package is that it could use a lot of general attention. There is a
whole series of testsuites in there, but it is yet unclear, which of
parts these should be run at build time, and which from autopkgtest in
debian/tests/*. I'd greatly appreciate if someone could untangle
these so we could have more confidence that the packages built are
really working.

There are only two bugs open, but both need checking if they still
apply (or in the case of #87222, if it makes sense at all, given it's
only a subject with a reference to a pgpool upstream bug number).

Also, we are still on 3.4, though Marco has already packaged 3.5 in
git. Getting that finished, tested, and uploaded would be nice.

debian/rules looks pretty complex, maybe it could be simplified.

So, lots of things to do, pick one to start at ;)

Thanks for your offer to help! If you have any questions, ask me
(Myon) on IRC. I'll see if I can find you there to say hello.

Cheers,
Christoph


signature.asc
Description: PGP signature

Bug#810392: 0xffff: please switch to libusb 1.0

[Pali Rohár]

On Tuesday 15 March 2016 23:08:26 Aurelien Jarno wrote:
> On 2016-03-15 22:50, Pali Rohár wrote:
> > On Tuesday 15 March 2016 22:47:23 Aurelien Jarno wrote:
> > > On 2016-03-15 22:25, Pali Rohár wrote:
> > > > On Tuesday 15 March 2016 22:12:18 Aurelien Jarno wrote:
> > > > > > Aurelien, I would suggest to have libusb-dev (libusb 0.1)
> > > > > > package in Debian repository, because it is stable and is
> > > > > > working, not like new libusb-1.0-0-dev which is slow and
> > > > > > unusable.
> > > > > 
> > > > > I disagree with this statement, libusb 1.0 is used in many
> > > > > applications without any problem. Contrary to libusb 0.1, it
> > > > > is a maintained library, so if you encountered any bug that
> > > > > makes it slow, unusable or whatever, please report a bug and
> > > > > a testcase, I am sure we'll find a solution.
> > > > 
> > > > 3 days ago I sent email to libusb-de...@lists.sourceforge.net
> > > > ML, now waiting for reply. So hope that this problem of slow
> > > > device listing will be fixed... If you want I can CC you next.
> > > 
> > > I don't see your mail on the mailing list, it seems it hasn't
> > > arrived. Did you got any bounce message?
> > 
> > I got "Your message to libusb-devel awaits moderator approval".
> 
> If it doesn't get accepted in the next days, please send it to me,
> I'll forward it there.
> 
> Aurelien

I already forwarded email to you, but did not received any relevant 
response about this problem (slow listing of devices)...

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#820240: lua-ldoc: please honour SOURCE_DATE_EPOCH

[Alexis Bienvenüe]

Source: lua-ldoc
Version: 1.4.3-5
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Control: forwarded -1 https://github.com/stevedonovan/LDoc/pull/233

Dear Maintainer,

While working on the “reproducible builds” effort [1], we have noticed
that some packages (like lua-posix) use LDoc in their building process,
resulting in timestamps in documentation files that break reproducibility.

To solve this kind of issues, it would be nice to have LDoc support
the SOURCE_DATE_EPOCH environment variable [2].

See the attached patch for a solution to this issue.

Regards,
Alexis Bienvenüe.

[1] https://wiki.debian.org/ReproducibleBuilds
[2] https://reproducible-builds.org/specs/source-date-epoch/

diff -Nru lua-ldoc-1.4.3/debian/changelog lua-ldoc-1.4.3/debian/changelog
--- lua-ldoc-1.4.3/debian/changelog	2015-11-01 10:17:35.0 +0100
+++ lua-ldoc-1.4.3/debian/changelog	2016-04-06 08:57:58.0 +0200
@@ -1,3 +1,9 @@
+lua-ldoc (1.4.3-5.0~reproducible1) unstable; urgency=medium
+
+  * Honour the SOURCE_DATE_EPOCH environment variable
+
+ -- Alexis Bienvenüe   Wed, 06 Apr 2016 08:57:58 +0200
+
 lua-ldoc (1.4.3-5) unstable; urgency=medium
 
   * Fix header used by lua-any adding 5.1 (Closes: #802248) 
diff -Nru lua-ldoc-1.4.3/debian/patches/0005-honour-SOURCE_DATE_EPOCH.patch lua-ldoc-1.4.3/debian/patches/0005-honour-SOURCE_DATE_EPOCH.patch
--- lua-ldoc-1.4.3/debian/patches/0005-honour-SOURCE_DATE_EPOCH.patch	1970-01-01 01:00:00.0 +0100
+++ lua-ldoc-1.4.3/debian/patches/0005-honour-SOURCE_DATE_EPOCH.patch	2016-04-06 08:57:21.0 +0200
@@ -0,0 +1,26 @@
+Description: Honour the SOURCE_DATE_EPOCH environment variable
+ Honour the SOURCE_DATE_EPOCH environment variable for even simpler
+ reproducible builds.
+ See https://reproducible-builds.org/specs/source-date-epoch/
+Author: Alexis Bienvenüe 
+
+--- lua-ldoc-1.4.3.orig/ldoc.lua
 lua-ldoc-1.4.3/ldoc.lua
+@@ -783,10 +783,14 @@ ldoc.modules = module_list
+ ldoc.title = ldoc.title or args.title
+ ldoc.project = ldoc.project or args.project
+ ldoc.package = args.package:match '%a+' and args.package or nil
+-if args.date == 'system' then
+-ldoc.updatetime = os.date("%Y-%m-%d %H:%M:%S")
++if os.getenv("SOURCE_DATE_EPOCH") == nil then
++   if args.date == 'system' then
++  ldoc.updatetime = os.date("%Y-%m-%d %H:%M:%S")
++   else
++  ldoc.updatetime = args.date
++   end
+ else
+-ldoc.updatetime = args.date
++   ldoc.updatetime = os.date("!%Y-%m-%d %H:%M:%S",os.getenv("SOURCE_DATE_EPOCH"))
+ end
+ 
+ local html = require 'ldoc.html'
diff -Nru lua-ldoc-1.4.3/debian/patches/series lua-ldoc-1.4.3/debian/patches/series
--- lua-ldoc-1.4.3/debian/patches/series	2015-11-01 10:17:35.0 +0100
+++ lua-ldoc-1.4.3/debian/patches/series	2016-04-06 08:55:47.0 +0200
@@ -2,3 +2,4 @@
 0002-Remove-non-existing-one-1.md-from-tests-config.ld.patch
 0003-Fix-broken-template-missing-closing-bracket.patch
 0004-make-system-date-override-able-via-date.patch
+0005-honour-SOURCE_DATE_EPOCH.patch