Bug#758983: akonadi-server: increased CPU utilization

[Salvo Tomaselli]

However, just sending the previous email, kept my cpu at 30% (so one core was 
busy) for 10 minutes. Akonadi can't really be run on laptops.

Overall, since I moved to icedove (because the mail filters don't work in 
akonadi) I don't know how often this happens because I'm not using it daily 
any more.



In data domenica 8 febbraio 2015 19:00:01, Sandro Knauß ha scritto:
> tags: 758983 +moreinfo
> 
> Hey,
> 
> is this still an issue? Normally akonadi should be getting quiet after
> indexing all emails, that can take a while. Also refreshing all emails can
> make akonadi take a lot CPU. So in short periods and at beginning akonadi is
> taking much CPU. Other than that we need logs of akonadi (akonadictl
> restart) and a idea what is going on (see akonadiconsole, debug tab / job
> tracker).
> 
> Regads,
> 
> sandro
> 
> --
> On Sat, 23 Aug 2014 16:00:42 +0200 Salvo Tomaselli 
> 
> wrote:
> > Package: akonadi-server
> > Version: 1.13.0-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > the new version of akonadi-server is using a lot of CPU. top reports often
> > ~50% (I have 4 logical cpus) to akonadi server and another 50% to mysql.
> > 
> > This makes my laptop heat, and my fan will start spinning, reducing my
> > battery time.
> > 
> > I don't know what the issue can be, but I'll provide the requested data.
> > 
> > Best
> > 
> > 
> > -- System Information:
> > Debian Release: jessie/sid
> > 
> >   APT prefers unstable
> >   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> > 
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 3.16.1d (SMP w/4 CPU cores; PREEMPT)
> > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > 
> > Versions of packages akonadi-server depends on:
> > ii  akonadi-backend-mysql   1.13.0-1
> > ii  libakonadiprotocolinternals11.13.0-1
> > ii  libboost-program-options1.55.0  1.55.0+dfsg-2
> > ii  libc6   2.19-9
> > ii  libgcc1 1:4.9.1-8
> > ii  libqt4-dbus 4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libqt4-network  4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libqt4-sql  4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libqt4-xml  4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libqtcore4  4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libqtgui4   4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libstdc++6  4.9.1-8
> > 
> > akonadi-server recommends no packages.
> > 
> > Versions of packages akonadi-server suggests:
> > ii  akonadi-backend-mysql   1.13.0-1
> > pn  akonadi-backend-postgresql  
> > pn  akonadi-backend-sqlite  
> > 
> > -- no debconf information

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di 
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/


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

Bug#764224: [Pkg-utopia-maintainers] Bug#764224: Fails ModemManager connections since 0.9.10.0-3

[Guido Günther]

On Mon, Feb 09, 2015 at 02:35:37AM +0100, Michael Biebl wrote:
> Am 06.10.2014 um 09:23 schrieb Guido Günther:
> > still works as expected. Any idea what could have triggered this?
> > Anything else you want me to try?
> 
> Hi, could you please try, if this problem is still reproducible on a
> up-to-date sid?
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Still the same:

Feb 10 08:29:56 foo NetworkManager[842]:  Failed to activate 
'MyProvider': Connection 'MyProvider' is not available on the device cdc-wdm0 
at this time.
Feb 10 08:29:56 foo gnome-session[1709]: (gnome-shell:1858): libnm-glib-WARNING 
**: Device activation failed: (32) Connection 'MyProvider' is not available on 
the device cdc-wdm0 at this time.

I'm also having:

Feb 10 07:29:56 foo gnome-session[1587]: ** (gnome-shell:1697): CRITICAL **: 
nma_mobile_providers_database_lookup_cdma_sid: assertion 'sid > 0' failed

when NM starts up.

I hope to find some time to prepare a better failure report
eventually.
Cheers,
 -- Guido


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

Bug#777584: wrap long lines

[Harald Dunkel]

Package: cron
Version: 3.0pl1-124

To avoid loosing cronjob mails with a "line too long" error
(exim4, for example) cron should wrap very long lines, e.g.
after 1024 chars.


Regards
Harri
-- 
aixigo AG, Karl-Friedrich-Strasse 68, 52072 Aachen, Germany
phone: +49 241 559709-79, fax: +49 241 559709-99
eMail: harald.dun...@aixigo.de, web: http://www.aixigo.de
Amtsgericht Aachen - HRB 8057, Vorstand: Erich Borsch, Christian Friedrich, 
Tobias Haustein, Vors. des Aufsichtsrates: Prof. Dr. Ruediger von Nitzsch


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

Bug#758983: akonadi-server: increased CPU utilization

[Salvo Tomaselli]

Hello,

it seems not, at this moment.

In data domenica 8 febbraio 2015 19:00:01, Sandro Knauß ha scritto:
> tags: 758983 +moreinfo
> 
> Hey,
> 
> is this still an issue? Normally akonadi should be getting quiet after
> indexing all emails, that can take a while. Also refreshing all emails can
> make akonadi take a lot CPU. So in short periods and at beginning akonadi is
> taking much CPU. Other than that we need logs of akonadi (akonadictl
> restart) and a idea what is going on (see akonadiconsole, debug tab / job
> tracker).
> 
> Regads,
> 
> sandro
> 
> --
> On Sat, 23 Aug 2014 16:00:42 +0200 Salvo Tomaselli 
> 
> wrote:
> > Package: akonadi-server
> > Version: 1.13.0-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > the new version of akonadi-server is using a lot of CPU. top reports often
> > ~50% (I have 4 logical cpus) to akonadi server and another 50% to mysql.
> > 
> > This makes my laptop heat, and my fan will start spinning, reducing my
> > battery time.
> > 
> > I don't know what the issue can be, but I'll provide the requested data.
> > 
> > Best
> > 
> > 
> > -- System Information:
> > Debian Release: jessie/sid
> > 
> >   APT prefers unstable
> >   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> > 
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 3.16.1d (SMP w/4 CPU cores; PREEMPT)
> > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > 
> > Versions of packages akonadi-server depends on:
> > ii  akonadi-backend-mysql   1.13.0-1
> > ii  libakonadiprotocolinternals11.13.0-1
> > ii  libboost-program-options1.55.0  1.55.0+dfsg-2
> > ii  libc6   2.19-9
> > ii  libgcc1 1:4.9.1-8
> > ii  libqt4-dbus 4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libqt4-network  4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libqt4-sql  4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libqt4-xml  4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libqtcore4  4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libqtgui4   4:4.8.6+git49-gbc62005+dfsg-1
> > ii  libstdc++6  4.9.1-8
> > 
> > akonadi-server recommends no packages.
> > 
> > Versions of packages akonadi-server suggests:
> > ii  akonadi-backend-mysql   1.13.0-1
> > pn  akonadi-backend-postgresql  
> > pn  akonadi-backend-sqlite  
> > 
> > -- no debconf information

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di 
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/


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

Bug#698821: linux-image-3.2.0-4-amd64: ARECA driver arcmsr is out of date - please update

[Teodor Milkov]

FTR,

It seems newest areca driver is finally merged into vanilla kernel 3.18: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/scsi/arcmsr/arcmsr_hba.c?id=b2776bf7149bddd1f4161f14f79520f17fc1d71d


Unfortunately, neither Wheezy nor Jessie have support for 1214 and 
there's even regression for 1882 in some configurations (doesn't work on 
supermicro X10 mobo's).


Please, consider backporting areca updates from 3.18/3.19 to Jessie 
kernel (3.16).



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

Bug#777583: Incorrect debian/copyright for smartmontools

[Mark H Weaver]

Package: smartmontools
Version: 6.3+svn4002-2+b2
Severity: serious

debian/copyright claims that smartmontools is distributed under GPLv2,
but the copyright notices in its source files include the "or (at your
option) any later version" language.


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

Bug#773727: [debian-mysql] Bug#773727: Bug#773727: mariadb-server-10.0: Mroonga & TokuDB plugins missing

[Arnaud Fontaine]

Hi Otto,

Otto Kekäläinen  writes:

> After thinking about it for a while, I am starting to think that the
> best policy would be to _not_ load bundled plugins by default if they
> are not compulsory for the server to run. It is better to keep the
> server lean and sleek, and let the user activate extra plugins if they
> need them.

Indeed.

> We could however facilitate the activation of plugins by shipping them
> in separate packages (e.g. like mariadb-connect-engine-10.0 is now) so
> all the user needs to do is run 'apt-get install
> mariadb-mroonga-search-10.0' or similar. These packages could then
> contain the plugin files itself, any configuration that need to be
> dropped in /etc/mysql/conf.d/ and potentially also install/remove
> scripts.
>
> What do you think, does this sound like a good policy?

Considering that  it is currently  inconsistent (eg CONNECT  and OQGRAPH
engines are in  separate packages but Mroonga and Spider  are not), then
it would be good to address  this inconsistency. Excluding the ones that
are already packaged separately (namely OQGRAPH and CONNECT engines):

> SELECT PLUGIN_NAME, PLUGIN_LIBRARY FROM information_schema.ALL_PLUGINS WHERE 
> PLUGIN_LIBRARY IS NOT NULL GROUP BY PLUGIN_LIBRARY;
+--++
| PLUGIN_NAME  | PLUGIN_LIBRARY |
+--++
| pam  | auth_pam.so|
| unix_socket  | auth_socket.so |
| handlersocket| handlersocket.so   |
| InnoDB   | ha_innodb.so   |
| SEQUENCE | ha_sequence.so |
| SPHINX   | ha_sphinx.so   |
| SPIDER   | ha_spider.so   |
| LOCALES  | locales.so |
| METADATA_LOCK_INFO   | metadata_lock_info.so  |
| QUERY_CACHE_INFO | query_cache_info.so|
| QUERY_RESPONSE_TIME  | query_response_time.so |
| rpl_semi_sync_master | semisync_master.so |
| rpl_semi_sync_slave  | semisync_slave.so  |
| SERVER_AUDIT | server_audit.so|
| SQL_ERROR_LOG| sql_errlog.so  |
+--++
15 rows in set (0.01 sec)

So, here are several solutions I could think of: 

  1. Create  one package  per plugin  as you  suggested, but  this would
 create many (some of them really small) packages though. Or perhaps
 one package containing several plugins,  because some of them, such
 as query_cache_info, are really small?

  2. Keep  it as it  is, eg let users  manage plugins by  themselves and
 thus not load any plugin by  default. This is not really convenient
 as  some plugins  requires  more than  a plugin-load  configuration
 option (mroonga does requires "CREATE FUNCTION" for example).

  3. Keep  all the plugins  in mariadb-server-10.0 but let  users choose
 which plugins to install (and then run necessary scripts) through a
 debconf menu.

What do you think?

Cheers,
-- 
Arnaud Fontaine


signature.asc
Description: PGP signature

Bug#777582: python-lldb-3.7 and python-lldb-3.6: error when trying to install together

[Ralf Treinen]

Package: python-lldb-3.6,python-lldb-3.7
Version: python-lldb-3.6/1:3.6~+rc2-2
Version: python-lldb-3.7/1:3.7~svn227076-1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2015-02-10
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Selecting previously unselected package libdb5.3:amd64.
(Reading database ... 10935 files and directories currently installed.)
Preparing to unpack .../libdb5.3_5.3.28-9_amd64.deb ...
Unpacking libdb5.3:amd64 (5.3.28-9) ...
Selecting previously unselected package libpython2.7-minimal:amd64.
Preparing to unpack .../libpython2.7-minimal_2.7.9-1_amd64.deb ...
Unpacking libpython2.7-minimal:amd64 (2.7.9-1) ...
Selecting previously unselected package python2.7-minimal.
Preparing to unpack .../python2.7-minimal_2.7.9-1_amd64.deb ...
Unpacking python2.7-minimal (2.7.9-1) ...
Selecting previously unselected package python-minimal.
Preparing to unpack .../python-minimal_2.7.8-3_amd64.deb ...
Unpacking python-minimal (2.7.8-3) ...
Selecting previously unselected package mime-support.
Preparing to unpack .../mime-support_3.58_all.deb ...
Unpacking mime-support (3.58) ...
Selecting previously unselected package libexpat1:amd64.
Preparing to unpack .../libexpat1_2.1.0-6+b3_amd64.deb ...
Unpacking libexpat1:amd64 (2.1.0-6+b3) ...
Selecting previously unselected package libffi6:amd64.
Preparing to unpack .../libffi6_3.1-2+b2_amd64.deb ...
Unpacking libffi6:amd64 (3.1-2+b2) ...
Selecting previously unselected package libpython2.7-stdlib:amd64.
Preparing to unpack .../libpython2.7-stdlib_2.7.9-1_amd64.deb ...
Unpacking libpython2.7-stdlib:amd64 (2.7.9-1) ...
Selecting previously unselected package python2.7.
Preparing to unpack .../python2.7_2.7.9-1_amd64.deb ...
Unpacking python2.7 (2.7.9-1) ...
Selecting previously unselected package libpython-stdlib:amd64.
Preparing to unpack .../libpython-stdlib_2.7.8-3_amd64.deb ...
Unpacking libpython-stdlib:amd64 (2.7.8-3) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up libpython2.7-minimal:amd64 (2.7.9-1) ...
Setting up python2.7-minimal (2.7.9-1) ...
Setting up python-minimal (2.7.8-3) ...
Selecting previously unselected package python.
(Reading database ... 11729 files and directories currently installed.)
Preparing to unpack .../python_2.7.8-3_amd64.deb ...
Unpacking python (2.7.8-3) ...
Selecting previously unselected package python-lldb-3.6.
Preparing to unpack .../python-lldb-3.6_1%3a3.6~+rc2-2_amd64.deb ...
Unpacking python-lldb-3.6 (1:3.6~+rc2-2) ...
Selecting previously unselected package python-lldb-3.7.
Preparing to unpack .../python-lldb-3.7_1%3a3.7~svn227076-1_amd64.deb ...
Unpacking python-lldb-3.7 (1:3.7~svn227076-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/python-lldb-3.7_1%3a3.7~svn227076-1_amd64.deb 
(--unpack):
 trying to overwrite '/usr/lib/python2.7/dist-packages/lldb', which is also in 
package python-lldb-3.6 1:3.6~+rc2-2
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
 /var/cache/apt/archives/python-lldb-3.7_1%3a3.7~svn227076-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/lib/python2.7/dist-packages/lldb

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://edos.debian.net/file-overwrites/.


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

Bug#777580: python-clang-3.7 and python-clang-3.5: error when trying to install together

[Ralf Treinen]

Package: python-clang-3.5,python-clang-3.7
Version: python-clang-3.5/1:3.5-9
Version: python-clang-3.7/1:3.7~svn227076-1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2015-02-10
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Selecting previously unselected package libdb5.3:amd64.
(Reading database ... 10935 files and directories currently installed.)
Preparing to unpack .../libdb5.3_5.3.28-9_amd64.deb ...
Unpacking libdb5.3:amd64 (5.3.28-9) ...
Selecting previously unselected package libpython2.7-minimal:amd64.
Preparing to unpack .../libpython2.7-minimal_2.7.9-1_amd64.deb ...
Unpacking libpython2.7-minimal:amd64 (2.7.9-1) ...
Selecting previously unselected package python2.7-minimal.
Preparing to unpack .../python2.7-minimal_2.7.9-1_amd64.deb ...
Unpacking python2.7-minimal (2.7.9-1) ...
Selecting previously unselected package python-minimal.
Preparing to unpack .../python-minimal_2.7.8-3_amd64.deb ...
Unpacking python-minimal (2.7.8-3) ...
Selecting previously unselected package mime-support.
Preparing to unpack .../mime-support_3.58_all.deb ...
Unpacking mime-support (3.58) ...
Selecting previously unselected package libexpat1:amd64.
Preparing to unpack .../libexpat1_2.1.0-6+b3_amd64.deb ...
Unpacking libexpat1:amd64 (2.1.0-6+b3) ...
Selecting previously unselected package libffi6:amd64.
Preparing to unpack .../libffi6_3.1-2+b2_amd64.deb ...
Unpacking libffi6:amd64 (3.1-2+b2) ...
Selecting previously unselected package libpython2.7-stdlib:amd64.
Preparing to unpack .../libpython2.7-stdlib_2.7.9-1_amd64.deb ...
Unpacking libpython2.7-stdlib:amd64 (2.7.9-1) ...
Selecting previously unselected package python2.7.
Preparing to unpack .../python2.7_2.7.9-1_amd64.deb ...
Unpacking python2.7 (2.7.9-1) ...
Selecting previously unselected package libpython-stdlib:amd64.
Preparing to unpack .../libpython-stdlib_2.7.8-3_amd64.deb ...
Unpacking libpython-stdlib:amd64 (2.7.8-3) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up libpython2.7-minimal:amd64 (2.7.9-1) ...
Setting up python2.7-minimal (2.7.9-1) ...
Setting up python-minimal (2.7.8-3) ...
Selecting previously unselected package python.
(Reading database ... 11729 files and directories currently installed.)
Preparing to unpack .../python_2.7.8-3_amd64.deb ...
Unpacking python (2.7.8-3) ...
Selecting previously unselected package python-clang-3.5.
Preparing to unpack .../python-clang-3.5_1%3a3.5-9_amd64.deb ...
Unpacking python-clang-3.5 (1:3.5-9) ...
Selecting previously unselected package python-clang-3.7.
Preparing to unpack .../python-clang-3.7_1%3a3.7~svn227076-1_amd64.deb ...
Unpacking python-clang-3.7 (1:3.7~svn227076-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/python-clang-3.7_1%3a3.7~svn227076-1_amd64.deb 
(--unpack):
 trying to overwrite '/usr/lib/python2.7/dist-packages/clang/enumerations.py', 
which is also in package python-clang-3.5 1:3.5-9
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
 /var/cache/apt/archives/python-clang-3.7_1%3a3.7~svn227076-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/lib/python2.7/dist-packages/clang/__init__.py
  /usr/lib/python2.7/dist-packages/clang/cindex.py
  /usr/lib/python2.7/dist-packages/clang/enumerations.py

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://edos.debian.net/file-overwrites/.


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

Bug#777581: python-clang-3.7 and python-clang-3.6: error when trying to install together

[Ralf Treinen]

Package: python-clang-3.6,python-clang-3.7
Version: python-clang-3.6/1:3.6~+rc2-2
Version: python-clang-3.7/1:3.7~svn227076-1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2015-02-10
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Selecting previously unselected package libdb5.3:amd64.
(Reading database ... 10935 files and directories currently installed.)
Preparing to unpack .../libdb5.3_5.3.28-9_amd64.deb ...
Unpacking libdb5.3:amd64 (5.3.28-9) ...
Selecting previously unselected package libpython2.7-minimal:amd64.
Preparing to unpack .../libpython2.7-minimal_2.7.9-1_amd64.deb ...
Unpacking libpython2.7-minimal:amd64 (2.7.9-1) ...
Selecting previously unselected package python2.7-minimal.
Preparing to unpack .../python2.7-minimal_2.7.9-1_amd64.deb ...
Unpacking python2.7-minimal (2.7.9-1) ...
Selecting previously unselected package python-minimal.
Preparing to unpack .../python-minimal_2.7.8-3_amd64.deb ...
Unpacking python-minimal (2.7.8-3) ...
Selecting previously unselected package mime-support.
Preparing to unpack .../mime-support_3.58_all.deb ...
Unpacking mime-support (3.58) ...
Selecting previously unselected package libexpat1:amd64.
Preparing to unpack .../libexpat1_2.1.0-6+b3_amd64.deb ...
Unpacking libexpat1:amd64 (2.1.0-6+b3) ...
Selecting previously unselected package libffi6:amd64.
Preparing to unpack .../libffi6_3.1-2+b2_amd64.deb ...
Unpacking libffi6:amd64 (3.1-2+b2) ...
Selecting previously unselected package libpython2.7-stdlib:amd64.
Preparing to unpack .../libpython2.7-stdlib_2.7.9-1_amd64.deb ...
Unpacking libpython2.7-stdlib:amd64 (2.7.9-1) ...
Selecting previously unselected package python2.7.
Preparing to unpack .../python2.7_2.7.9-1_amd64.deb ...
Unpacking python2.7 (2.7.9-1) ...
Selecting previously unselected package libpython-stdlib:amd64.
Preparing to unpack .../libpython-stdlib_2.7.8-3_amd64.deb ...
Unpacking libpython-stdlib:amd64 (2.7.8-3) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up libpython2.7-minimal:amd64 (2.7.9-1) ...
Setting up python2.7-minimal (2.7.9-1) ...
Setting up python-minimal (2.7.8-3) ...
Selecting previously unselected package python.
(Reading database ... 11729 files and directories currently installed.)
Preparing to unpack .../python_2.7.8-3_amd64.deb ...
Unpacking python (2.7.8-3) ...
Selecting previously unselected package python-clang-3.6.
Preparing to unpack .../python-clang-3.6_1%3a3.6~+rc2-2_amd64.deb ...
Unpacking python-clang-3.6 (1:3.6~+rc2-2) ...
Selecting previously unselected package python-clang-3.7.
Preparing to unpack .../python-clang-3.7_1%3a3.7~svn227076-1_amd64.deb ...
Unpacking python-clang-3.7 (1:3.7~svn227076-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/python-clang-3.7_1%3a3.7~svn227076-1_amd64.deb 
(--unpack):
 trying to overwrite '/usr/lib/python2.7/dist-packages/clang/enumerations.py', 
which is also in package python-clang-3.6 1:3.6~+rc2-2
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
 /var/cache/apt/archives/python-clang-3.7_1%3a3.7~svn227076-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/lib/python2.7/dist-packages/clang/__init__.py
  /usr/lib/python2.7/dist-packages/clang/cindex.py
  /usr/lib/python2.7/dist-packages/clang/enumerations.py

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://edos.debian.net/file-overwrites/.


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

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Erik Haller]

/etc/krb5kdc/kdc.conf:

[kdcdefaults]
kdc_ports = 750,88

[realms]
EXAMPLE.COM = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = aes256-cts:normal arcfour-hmac:normal
des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm
des:onlyrealm des:afs3
default_principal_flags = +preauth
}

The /var/lib/krb5kdc directory is empty. The /etc/krb5kdc directory must be
compiled into kadmind as a default because I do not see a conf file that
tells kadmind where to look.

On Mon, Feb 9, 2015 at 10:21 PM, Russ Allbery  wrote:

> Erik Haller  writes:
>
> > Incidentally, the output from krb5_newrealm (latest version) shows:
>
> > root@lime:t# krb5_newrealm
> > This script should be run on the master KDC/admin server to initialize
> > a Kerberos realm.  It will ask you to type in a master key password.
> > This password will be used to generate a key that is stored in
> > /etc/krb5kdc/stash.  You should try to remember this password, but it
> > is much more important that it be a strong password than that it be
> > remembered.  However, if you lose the password and /etc/krb5kdc/stash,
> > you cannot decrypt your Kerberos database.
> > Loading random data
> > Initializing database '/etc/krb5kdc/principal' for realm 'EXAMPLE.COM',
> > master key name 'K/m...@example.com'
> > You will be prompted for the database Master Password.
> > It is important that you NOT FORGET this password.
> > Enter KDC database master key:
>
> > Looks like krb5_newrealm is choosing a default location of /etc/krb5kdc
> > instead of /var ...
>
> Yeah, it sure does.
>
> I think that's the bug rather than the krb5-admin-server configuration,
> since that stuff is really supposed to be in /var/lib/krb5kdc.
>
> --
> Russ Allbery (r...@debian.org)   
>

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Russ Allbery]

Erik Haller  writes:

> Incidentally, the output from krb5_newrealm (latest version) shows:

> root@lime:t# krb5_newrealm
> This script should be run on the master KDC/admin server to initialize
> a Kerberos realm.  It will ask you to type in a master key password.
> This password will be used to generate a key that is stored in
> /etc/krb5kdc/stash.  You should try to remember this password, but it
> is much more important that it be a strong password than that it be
> remembered.  However, if you lose the password and /etc/krb5kdc/stash,
> you cannot decrypt your Kerberos database.
> Loading random data
> Initializing database '/etc/krb5kdc/principal' for realm 'EXAMPLE.COM',
> master key name 'K/m...@example.com'
> You will be prompted for the database Master Password.
> It is important that you NOT FORGET this password.
> Enter KDC database master key:

> Looks like krb5_newrealm is choosing a default location of /etc/krb5kdc
> instead of /var ...

Yeah, it sure does.

I think that's the bug rather than the krb5-admin-server configuration,
since that stuff is really supposed to be in /var/lib/krb5kdc.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Erik Haller]

The database was created fresh with krb5_newrealm in an lxc container. No
Kerberos KDC existed previously. I did not configure the database location
differently. This was my first Kerberos installation.

On Mon, Feb 9, 2015 at 9:52 PM, Russ Allbery  wrote:

> Erik Haller  writes:
>
> > Yes. These files reside under /etc/krb5kdc:
>
> > principal
> > principal.kadm5
> > principal.kadm5.lock
> > principal.ok
> > kdc.conf
> > .k5.EXAMPLE.COM
>
> Hm.  When was this KDC created / initialized?  (In other words, was it
> just now set up fresh, or is this an existing Kerberos KDC that you've
> upgraded?)
>
> Just to ask the obvious question, are you sure you didn't configure the
> database location somewhere?
>
> --
> Russ Allbery (r...@debian.org)   
>

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Erik Haller]

I setup kerberos a few months ago. My .bash_history file shows it was
installed with "apt-get install krb5-admin-server" The version of
krb5-admin-server was 1.12.1+dfsg-1 according to /var/log/apt.history. I
then installed krb5-kdc, "dpkg-reconfigure -plow krb5-kdc", and then
configured with "krb5_newrealm". I would look in the krb5_newrealm in
version 1.12.1+dfsg-1.  I have upgraded since then. This bug report  shows
version 1.12.1+dfsg-16.

Incidentally, the output from krb5_newrealm (latest version) shows:

root@lime:t# krb5_newrealm
This script should be run on the master KDC/admin server to initialize
a Kerberos realm.  It will ask you to type in a master key password.
This password will be used to generate a key that is stored in
/etc/krb5kdc/stash.  You should try to remember this password, but it
is much more important that it be a strong password than that it be
remembered.  However, if you lose the password and /etc/krb5kdc/stash,
you cannot decrypt your Kerberos database.
Loading random data
Initializing database '/etc/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/m...@example.com'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:

Looks like krb5_newrealm is choosing a default location of /etc/krb5kdc instead
of /var ...

On Mon, Feb 9, 2015 at 9:52 PM, Russ Allbery  wrote:

> Erik Haller  writes:
>
> > Yes. These files reside under /etc/krb5kdc:
>
> > principal
> > principal.kadm5
> > principal.kadm5.lock
> > principal.ok
> > kdc.conf
> > .k5.EXAMPLE.COM
>
> Hm.  When was this KDC created / initialized?  (In other words, was it
> just now set up fresh, or is this an existing Kerberos KDC that you've
> upgraded?)
>
> Just to ask the obvious question, are you sure you didn't configure the
> database location somewhere?
>
> --
> Russ Allbery (r...@debian.org)   
>

Bug#759361: freerdp-x11: Segfaults on too-long command line with old-style options

[Alex Goebel]

Looks like this is not going to happen in time for jessie? If not, in 
terms of cleaning up severity inflation, shouldn't we put this back to 
important?



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

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Russ Allbery]

Erik Haller  writes:

> Yes. These files reside under /etc/krb5kdc:

> principal
> principal.kadm5
> principal.kadm5.lock
> principal.ok
> kdc.conf
> .k5.EXAMPLE.COM

Hm.  When was this KDC created / initialized?  (In other words, was it
just now set up fresh, or is this an existing Kerberos KDC that you've
upgraded?)

Just to ask the obvious question, are you sure you didn't configure the
database location somewhere?

-- 
Russ Allbery (r...@debian.org)   


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

Bug#777579: Fwd: Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Erik Haller]

-- Forwarded message --
From: Erik Haller 
Date: Mon, Feb 9, 2015 at 9:42 PM
Subject: Re: Bug#777579: krb5-admin-server: kadmind reports Insufficient
access to lock database
To: Russ Allbery 


Yes. These files reside under /etc/krb5kdc:

principal
principal.kadm5
principal.kadm5.lock
principal.ok
kdc.conf
.k5.EXAMPLE.COM

On Mon, Feb 9, 2015 at 9:39 PM, Russ Allbery  wrote:

> Erik  writes:
>
> > The systemd krb5-admin-server.service file is missing the critical
> > directory /etc/krb5kdc used by kadmind in the ReadWriteDirectories
> > stanza.  The kerberose default database location is created under
> > /etc/krb5kdc.
>
> Er, it certainly shouldn't be.  The Kerberos KDC database goes under
> /var/lib/krb5kdc.  Is there some new bug here?
>
> > Attempting to use kadmin to add a kerberos principal will receive
> > the following error at the kadmin prompt:
>
> > kadmin:  add_principal -randkey host/somehost
> > ...
> > add_principal: Insufficient access to lock database while creating
> > "host/someh...@example.com".
>
> > Workaround:
>
> > 1) Add /etc/krb5kdc to the ReadWriteDirectories stanza.
> > 2) Restart krb5-admin-server systemd service.
>
> And that makes that error message go away?  Hrm.  I wonder what file is
> being locked.
>
> Are you sure that your database is in /etc/krb5kdc?  It's a file named
> principal.
>
> --
> Russ Allbery (r...@debian.org)   
>

Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Russ Allbery]

Erik  writes:

> The systemd krb5-admin-server.service file is missing the critical
> directory /etc/krb5kdc used by kadmind in the ReadWriteDirectories
> stanza.  The kerberose default database location is created under
> /etc/krb5kdc.

Er, it certainly shouldn't be.  The Kerberos KDC database goes under
/var/lib/krb5kdc.  Is there some new bug here?

> Attempting to use kadmin to add a kerberos principal will receive
> the following error at the kadmin prompt:

> kadmin:  add_principal -randkey host/somehost
> ...
> add_principal: Insufficient access to lock database while creating
> "host/someh...@example.com".

> Workaround:

> 1) Add /etc/krb5kdc to the ReadWriteDirectories stanza.
> 2) Restart krb5-admin-server systemd service.

And that makes that error message go away?  Hrm.  I wonder what file is
being locked.

Are you sure that your database is in /etc/krb5kdc?  It's a file named
principal.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#777579: krb5-admin-server: kadmind reports Insufficient access to lock database

[Erik]

Package: krb5-admin-server
Version: 1.12.1+dfsg-16
Severity: important
Tags: patch

The systemd krb5-admin-server.service file is missing the critical
directory /etc/krb5kdc used by kadmind in the ReadWriteDirectories stanza.
The kerberose default database location is created under /etc/krb5kdc.
The location must be writeable. The krb5-admi-server.service file makes
it readonly.

Attempting to use kadmin to add a kerberos principal will receive
the following error at the kadmin prompt:

kadmin:  add_principal -randkey host/somehost
...
add_principal: Insufficient access to lock database while creating
"host/someh...@example.com".

Workaround:

1) Add /etc/krb5kdc to the ReadWriteDirectories stanza.
2) Restart krb5-admin-server systemd service.

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

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 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)
11c11
< ReadWriteDirectories=/var/tmp /tmp /var/lib/krb5kdc /var/run /run
---
> ReadWriteDirectories=/var/tmp /tmp /var/lib/krb5kdc /var/run /run /etc/krb5kdc

Bug#755015: Same here

[Martín Ferrari]

I am experiencing the same issue. After a while trying to understand why
my v4tunnel was not coming up, I realised that NetworkManager was
screwing up, again.

I also have the managed=false statement, which is clearly ignored. But I
managed to make it understand by adding this (requires manual
synchronization of interface names, which sucks):


# cat NetworkManager.conf
[main]
plugins=ifupdown,keyfile
dns=dnsmasq

[ifupdown]
managed=false

[keyfile]
unmanaged-devices=interface-name:he-ipv6

At least, with this it stopped messing around with my tunnel.

-- 
Martín Ferrari (Tincho)


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

Bug#777578: Acknowledgement (broken install, incomplete initrd)

[jnq nfe]

Sorry, when I said that I'm using the latest "stable" version of d-i for
this, I mean I'm using the "current" version under sid as available in the
archives, not the daily build, and not a Wheezy build.

Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange

[Russ Allbery]

Karl Kornel  writes:

> The problem with that is, if I do that I'm putting all of my faith that
> GSSAPI will be working on both ends.  I don't want to trust in GSSAPI
> not working if something goes wrong on my client.  For example, if
> Kerberos is messed up on my workstation, I could still securely log in
> to the server, I'd just have a coworker log in and get the host key
> fingerprint for me.

I thought you said that your policy required Kerberos authentication?  If
Kerberos is messed up on your workstation, that's not going to work.  :)

But in any event there will certainly be people who want to enable GSSAPI
but not require it, so it seems like a useful fix.

> I was wondering if this would need to go upstream, but from what I
> understood, bug reporters are supposed to report bugs directly to
> Debian.

There isn't any particular policy about this.  It's always okay to report
the bug directly to upstream (well, unless upstream doesn't want the bug
reports, but pretty sure that's not the case here).  Some Debian package
maintainers really prefer reporters to send the bug there first.  I think
Debian should accept bugs for its packages, but once identified as an
upstream bug, often it's more effective for the reporter to talk to
upstream directly instead of Debian being in the middle of the discussion.

> Could you please tell me where "upstream" is in this case?

https://github.com/SimonWilkinson/gss-openssh/ so far as I know.  I'm not
sure why the latest commit there is from 2011, since I know there's a
newer version of the patch than that.  Maybe Colin did the last update
himself?

> Yeah, it's really depressing, but I guess that's what's gonna
> happen. Could it possibly make it into jessie-backports, or is that also
> too much to hope for?

That's certainly possible.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#777578: broken install, incomplete initrd

[jnqnfe]

Package: debian-installer
Severity: important

As already described in the users mailing list [1], I have a Debian sid
amd64 install in a VM, using EFI, GPT, btrfs and luks, which after
installation is left broken.

So far, I have identified:
1) that the initrd of this install is lacking at least cryptsetup.
2) that an identical install, with the exception of using ext4 instead
of btrfs, works perfectly fine (at least in terms of booting, I have not
checked issue #3 from the mailing list discussion).
3) that this is reproducible, having recreated the same btrfs install
from scratch, resulting in the same issues.

So it seems that under some scenarios, d-i is not creating a sufficient
initrd.

/conf/initramfs.conf states MODULES=most

All installs so far were done using the standard graphical install mode.

Just FYI, for the installation I am using a sid amd64 based live-cd
image generated with live-build with the latest stable d-i included (I'm
including the proper standard installer, not the "live" installer), and
due to the dev work I've been undertaking on live-build, I am in
possession of a live image with EFI support. Hence I am essentially
simulating use of a Jessie install disc here.

[1] https://lists.debian.org/debian-user/2015/02/msg00323.html


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

Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange

[Karl Kornel]

Hello!

Since three replies came in at once (from my perspective), I'm doing one 
email.


On 2/9/2015 6:53 PM, Russ Allbery wrote:

Alfred Karl Kornel  writes:


I am reporting an issue that I have discovered in Debian's OpenSSH
package:  It appears that setting GSSAPIKeyExchange overrides the
KexAlgorithms setting.


Yeah, I would expect this, since GSS-API key exchange *is* a key exchange
mechanism.  If you do GSS-API key exchange, that completely replaces the
normal ssh public key negotiation, since it instead uses Kerberos to
negotiate the encrypted channel with the server.


That's what I thought, but as I understood the patch, it seems that 
turning on GSSAPIKeyExchange is just working out what GSSAPI 
key-exchange methods are supported, and then prepending those to the 
default list of key-exchange algorithms (and then adding "null" at the 
end).  That way, if the server doesn't support GSSAPI key exchange, the 
client is able to fall back to one of the more traditional methods.



Is the problem that you want to be able to control the key exchange
algorithms that the server falls back on if GSS-API key exchange fails
(if, for example, the client doesn't support it)?


Yup, that's correct!


If you're happy to require all clients to do GSS-API key exchange, you can
just delete all public keys for the server.  They're not used at all with
GSS-API, and that will prevent the server from negotiating any public key
exchange mechanism as a fallback.


The problem with that is, if I do that I'm putting all of my faith that 
GSSAPI will be working on both ends.  I don't want to trust in GSSAPI 
not working if something goes wrong on my client.  For example, if 
Kerberos is messed up on my workstation, I could still securely log in 
to the server, I'd just have a coworker log in and get the host key 
fingerprint for me.



On 2/9/2015 7:09 PM, Christoph Anton Mitterer wrote:> On Mon, 2015-02-09 
at 18:53 -0800, Russ Allbery wrote:

><<>>
>
> Guess the main problem here is, that GSSAPI Kex should have become
> configurable via KexAlgorithms and not via a separate option.
> OTOH, The GSSAPI Kex is really quite special (IIRC the client
> authentication phase also happens during the kex then).

Well, I'm find with just having GSSAPIKeyExchange prepend all of the 
GSSAPI methods to the start of my chosen KexAlgorithms list.  You could 
easily get very complicated here, such as by having SSH recognize things 
like "gssapi-group1" or "gssapi-group-exchange", and then replace with 
the appropriate expansions (after working out the OIDs).


><<>>
>
> Anyway,... best chances are if Alfred would report this to upstream
> (which is here not OpenSSH, but the maintainers of the patchset).

I was wondering if this would need to go upstream, but from what I 
understood, bug reporters are supposed to report bugs directly to Debian.


Could you please tell me where "upstream" is in this case?  I did some 
quick searching, but the one place I found hadn't been updated in a few 
years.


Once I know where to send the bug report, I'm happy to file it upstream!


On 2/9/2015 7:18 PM, Russ Allbery wrote:
><<>>
>
> That's also true, particularly since it sounded from the second message
> like he has a proposed fix.  However, it's worth noting that any fix for
> this wouldn't make it into jessie at this point, so you'll want to be
> thinking about workarounds or planning on backporting a later version.

Yeah, it's really depressing, but I guess that's what's gonna happen. 
Could it possibly make it into jessie-backports, or is that also too 
much to hope for?


Either way, thanks very much for the quick reply to my bug report!

~ Karl


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

Bug#777553: pu: package libfcgi/2.4.0-8

[Joe Damato]

On Mon, Feb 9, 2015 at 1:16 PM, Salvatore Bonaccorso  wrote:
> Hi Joe,
>
> Not member of the release team here, so not authoritative ;-). So just
> giving some comments. Btw, thanks for preparing the package!

Thanks for your helpful comments. I have no idea what I'm doing as far
as Debian standards go, so your reply is much appreciated.

>> +libfcgi (2.4.0-8.2) wheezy-security; urgency=high
>
> The version should be 2.4.0-8.1+deb7u1. 2.4.0-8.2 cannot be used as
> 2.4.0-8.2 was already in the archive. For the s-t-u wheezy-security as
> distribution needs to be changed to wheezy.

fixed both of these, see attached debdiff. Wasn't sure what to set the
urgency to, so I set it to low.

>> +  * Non-maintainer upload.
>> +  * Apply path from Anton Kortunov to swap select with poll to avoid
>> +stack smashing (See: #681591 and LP: #933417).
>
> could you please reference as well the CVE in the changelog, and close
> the bug: you can use "Closes: #681591" to reach this.

fixed both of these, as well.

> Joe, if you get an ack from the release team on your upload for
> libfcgi I can happily sponsor the upload itself.

How do I go about doing that? Is there a separate email list I need to ping?

I don't have a GPG key that is connected to Debian in any way. I can
create a key and upload it to the MIT pgp server. Is that useful at
all for the upload of my changes file? Not sure if signing with my key
will help or just complicate things further. From what I read, I was
under the impression that changes without signatures from GPG keys in
the web of trust are not processed in the upload queue.

Joe


libfcgi_2.4.0-8.1_2.4.0-8.1+deb7u1.diff.gz
Description: GNU Zip compressed data

Bug#776746: gnome-session: GNOME crashes during a remote desktop access

[Vagrant Cascadian]

Control: affects -1 ldm

On 2015-01-31, GGaotx wrote:
> Suppose you installed GNOME as default DE and also with xrdp installed, when
> trying to use another computer to visit it by remote access(RDP or VNC),then
> GNOME crashes:
> "Oh, no! Something has gone wrong."
> In this case, it influences the using of RDP and VNC. They cannot use at all.
> When trying to use MATE as default DE, it works as it should. Cinnamon also
> crashes, but soft rendering works. So I think it's GNOME's soft rendering bug,
> it doesn't comptable with remote access.

This also affects LDM (the display manager used in LTSP), which uses ssh
X11Forwarding or remote X11 protocols. Basically, LTSP installations
have been encouraged to avoid using GNOME3 for quite some time due to
these sorts of issues.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange

[Russ Allbery]

Christoph Anton Mitterer  writes:

> Anyway,... best chances are if Alfred would report this to upstream
> (which is here not OpenSSH, but the maintainers of the patchset).

That's also true, particularly since it sounded from the second message
like he has a proposed fix.  However, it's worth noting that any fix for
this wouldn't make it into jessie at this point, so you'll want to be
thinking about workarounds or planning on backporting a later version.

It does make sense to me that it should be possible to both enable GSS-API
key exchange and otherwise restrict the key exchange methods that the
server will use in the absence of GSS-API.  (Ideally, you could restrict
which specific GSS-API key exchange algorithms would be used, but I think
there aren't many to choose from anyway.)

This whole thing is unnecessarily irritating due to the OpenSSH project's
unwillingness to take the key exchange patches, forcing every distribution
to apply them separately and meaning that they aren't considered when
upstream works on things like the configuration parameter for key exchange
methods.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange

[Christoph Anton Mitterer]

On Mon, 2015-02-09 at 18:53 -0800, Russ Allbery wrote: 
> Yeah, I would expect this, since GSS-API key exchange *is* a key exchange
> mechanism.  If you do GSS-API key exchange, that completely replaces the
> normal ssh public key negotiation, since it instead uses Kerberos to
> negotiate the encrypted channel with the server.
Well what is "normal"... the other KEX algos als differ quite a bit,
e.g. take DH-GEX where you have the additional group exchange.

Guess the main problem here is, that GSSAPI Kex should have become
configurable via KexAlgorithms and not via a separate option.
OTOH, The GSSAPI Kex is really quite special (IIRC the client
authentication phase also happens during the kex then).

> Is the problem that you want to be able to control the key exchange
> algorithms that the server falls back on if GSS-API key exchange fails
> (if, for example, the client doesn't support it)?
I think it would be a severe bug if SSH would fall back to something
else, when one can't configure this something else (i.e. to be nothing).
Cause that may very well be what's desired, i.e. GSSAPI KEX or fail.

Unfortunately SSH has some such "hidden" fallbacks, which I'm quite
unhappy with, from a security POV.

Anyway,... best chances are if Alfred would report this to upstream
(which is here not OpenSSH, but the maintainers of the patchset).

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#775799: RFS: libmodule-install-rtx-perl/0.37-1 [ITP]

[dai]

On Tue, Feb 10, 2015 at 09:07:00AM +0900, Satoru KURASHIKI wrote:
> Sorry for late, I've fixed these issue and update mentors' package.
> (I add new Files: entry, and README.Debian to refer them)

uploaded.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: Digital signature

Bug#774643: [Pkg-puppet-devel] Bug#774643: verify_active_connections is not present in ruby-activerecord 4.1.8

[Russ Allbery]

intrigeri  writes:

> For the record, what's been replied there is that Puppet 3.7 needs
> activerecord 3.x (found in Wheezy) for storeconfig to work without
> puppetdb, while Jessie has activerecord 4.1.8, and ruby-activerecord-3.2
> has been removed from unstable in May, 2014.

> This sounds RC to me.

> Adding the previous maintainers of ruby-activerecord-3.2 into the loop,
> in case they have an idea. E.g. would it be an option to reintroduce the
> 'verify_active_connections!' method from 3.2 into Jessie's
> ActiveRecord::Base:Class? (I guess not, but if it is, then it would
> possibly be the easiest way forward.)

Well, it's RC in the sense that it's a pretty serious regression, but it's
an optional feature in Puppet and it's entirely possible to use Puppet
without using storedconfig at all.  (I do both at home and at work.)  So
in that sense I wouldn't remove Puppet from the jessie release even if
this functionality were broken, so it falls short of RC in that sense.

But it's definitely something that we should fix if possible, since it's a
feature a lot of people use and it would be embarassing for it to not be
available.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange

[Russ Allbery]

Alfred Karl Kornel  writes:

> I am reporting an issue that I have discovered in Debian's OpenSSH
> package:  It appears that setting GSSAPIKeyExchange overrides the
> KexAlgorithms setting.

Yeah, I would expect this, since GSS-API key exchange *is* a key exchange
mechanism.  If you do GSS-API key exchange, that completely replaces the
normal ssh public key negotiation, since it instead uses Kerberos to
negotiate the encrypted channel with the server.

Is the problem that you want to be able to control the key exchange
algorithms that the server falls back on if GSS-API key exchange fails
(if, for example, the client doesn't support it)?

If you're happy to require all clients to do GSS-API key exchange, you can
just delete all public keys for the server.  They're not used at all with
GSS-API, and that will prevent the server from negotiating any public key
exchange mechanism as a fallback.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#777577: new upstream version available

[Antoine Beaupré]

Package: git-annex
Version: 5.20141125
Severity: wishlist

It seems that new releases of git-annex do not trickle down into
Debian anymore.

This package isn't orphaned yet, Joey: are you still planning on
publishing updates to it in Debian?

Thanks!

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

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

Versions of packages git-annex depends on:
ii  curl   7.38.0-4
ii  git1:2.1.4-2.1
ii  libc6  2.19-13
ii  libffi63.1-2+b2
ii  libgmp10   2:6.0.0+dfsg-6
ii  libgnutls-deb0-28  3.3.8-5
ii  libgsasl7  1.8.0-6
ii  libicu52   52.1-7
ii  libidn11   1.29-1+b2
ii  libxml22.9.1+dfsg1-4
ii  libyaml-0-20.1.6-3
ii  openssh-client 1:6.7p1-3
ii  rsync  3.1.1-2+b1
ii  wget   1.16-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages git-annex recommends:
ii  bind9-host 1:9.9.5.dfsg-8
ii  git-remote-gcrypt  0.20130908-7
ii  gnupg  1.4.18-6
ii  lsof   4.86+dfsg-1
ii  nocache0.9-2
ii  quvi   0.4.2-2

Versions of packages git-annex suggests:
pn  bup  
ii  graphviz 2.38.0-7
ii  libnss-mdns  0.10-6
ii  tahoe-lafs   1.10.0-2

-- no debconf information


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

Bug#777576: cupt: please make the build reproducible

[Chris Lamb]

Source: cupt
Version: 2.8.4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

While working on the "reproducible builds" effort [1], we have noticed
that cupt could not be built reproducibly.

The attached patch removes timestamps from the build system. Once
applied, cupt can be built reproducibly in our current experimental
framework.

 [1]: https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/doc/reference/Doxyfile b/doc/reference/Doxyfile
index e067512..366a19f 100644
--- a/doc/reference/Doxyfile
+++ b/doc/reference/Doxyfile
@@ -939,7 +939,7 @@ HTML_COLORSTYLE_GAMMA  = 80
 # page will contain the date and time when the page was generated. Setting
 # this to NO can help when comparing the output of multiple runs.
 
-HTML_TIMESTAMP = YES
+HTML_TIMESTAMP = NO
 
 # If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
 # documentation will contain sections that can be hidden and shown after the

Bug#777471: Bug#777405: perl: pod2man puts object references into man page headers when used inside a pipe

[Vincent W. Chen]

Hi,

Please retain the CC to 777471-forwar...@bugs.debian.org in your
response, so that the Debian BTS has a record.

When using "fvwm-perllib man", the title of the resulting manpage
shows the title

IO::File=IO(0x22d5320)(3)  Fvwm Perl library IO::File=IO(0x22d5320)(3)

with the stringified object reference instead of proper title. This is
caused by the following lines in [fvwm src]/bin/fvwm-perllib.in

open(MANPIPE, $do_cat ? "| pod2text '$file' | $pager" :
"| pod2man --section 3 --release 'fvwm $version$version_info'" .
" --center 'Fvwm Perl library' '$file'" .
" | @SED@ 's//perllib/ig'$man_converter")
or die "Can't open pipe to pod/man viewer\n";

pod2man needs the filename in order to format the title properly,
which is not available when it is used in a pipe. The name can be
explicitly specified by passing the argument "--name" to pod2man.

Upstream of Pod::Man (the backend of pod2man) has stated [1], "the
next version of Pod::Man that will
diagnose parsing POD from standard input without providing --name as
an error, and defaults the title to STDIN if error handling is set to
proceed despite errors."

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777471 for more
information.

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

Regards,

Vincent Chen


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

Bug#777479: subversion: svn diff outputs 2 chunks instead of 1 when there are 6 consecutive unmodified lines

[Vincent Lefevre]

On 2015-02-09 20:09:15 -0500, James McCoy wrote:
> On Sun, Feb 08, 2015 at 07:19:14PM +0100, Vincent Lefevre wrote:
> > Contrary to the "diff" utility, "svn diff" outputs 2 chunks instead
> > of 1 when there are 6 consecutive unmodified lines.
> 
> I don't think svn claims to produce identical diffs to that of the diff
> command, so this is at most a minor issue, if not wishlist.
> 
> Also, the diffs are functionally equivalent, so I'm not sure how this
> matters other than the diffs being different.

Well, actually, what initially confused me with the "svn diff" output
is that I thought that two output chunks were necessarily disjoint
and non adjacent[*]. So, it seemed to me that there was a problem
with my file, until I noticed that the chunks output by "svn diff"
were adjacent. I hope that my bug report is more clear now.

[*] AFAIK, this is always the case with GNU diff, and this is why
I thought that this was a general rule for the unified diff format.

Now, what's interesting is what POSIX says:

  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/diff.html

  "If -U n is specified, the output shall contain no more than
  n consecutive unaffected lines; and if the output contains an
  affected line and this line is adjacent to up to n consecutive
  unaffected lines in the corresponding file, the output shall
  contain these unaffected lines. -u shall act like -U3."

So, it appears that "svn diff" follows POSIX here (but it doesn't when
there are exactly 5 consecutive unaffected lines). And GNU diff more
generally doesn't follow POSIX, even though this page later says that
the -u and -U options come from GNU diff!

At least there is a lack of specification for "svn diff". But I think
that a rule requiring disjoint and non adjacent chunks is intuitively
better for a human reader.

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


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

Bug#777575: apticron: /etc/cron.daily/apticron fallback cron script missing

[Bruno Bierbaumer]

Package: apticron
Version: 1.1.57
Severity: normal

Dear Maintainer,
the manpage of apticron(1) mentions a fallback cron script in
/etc/cron.daily/apticron.
This file is missing on my systems and does't seem to get installed by the
package anymore.
Could there be an error in the package or is it just an outdated documentation.

Regards
Bruno



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

Kernel: Linux 3.19.0 (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 apticron depends on:
ii  apt1.0.9.6
ii  bsd-mailx [mailx]  8.1.2-0.20141216cvs-1
ii  bzip2  1.0.6-7+b2
ii  cron [cron-daemon] 3.0pl1-127
ii  debconf [debconf-2.0]  1.5.55
ii  dpkg   1.17.23
ii  ucf3.0030

Versions of packages apticron recommends:
ii  apt-listchanges  2.85.13+nmu1
ii  iproute2 3.16.0-2

apticron suggests no packages.

-- debconf information:
  apticron/notification: root


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

Bug#777574: xbrlapi: overwrites the Orca output as soon as the current window has its title changed

[Samuel Thibault]

Package: xbrlapi
Version: 5.2~20141018-3
Severity: important
Tags: patch

Hello,

In Debian, we automatically start xbrlapi -q so braille input works
fine, and then we start Orca.  If the user, for some reason, restarts
xbrlapi -q, that will take precedence over the Orca output, which should
not be a problem since the -q option makes xbrlapi not make any output.
But there is one case when xbrlapi is currently still making an output:
when the title of the current window changes.  The orca output is then
completely ignored, and the desktop completely inaccessible via Braille
until orca is restarted.  The attached patch fixes this.

Samuel

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

Kernel: Linux 3.19.0 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages xbrlapi depends on:
ii  libbluetooth3  5.23-2+b1
ii  libbrlapi0.6   5.2~20141018-3
ii  libc6  2.19-13
ii  libgpm21.20.4-6.1+b2
ii  libicu52   52.1-7
ii  libx11-6   2:1.6.2-3
ii  libxext6   2:1.3.3-1
ii  libxtst6   2:1.2.2-1+b1

xbrlapi recommends no packages.

xbrlapi suggests no packages.

-- no debconf information

-- 
Samuel
War doesn't prove who's right, just who's left.
diff --git a/Programs/xbrlapi.c b/Programs/xbrlapi.c
index 093f2c4..07d6ee0 100644
--- a/Programs/xbrlapi.c
+++ b/Programs/xbrlapi.c
@@ -643,7 +643,7 @@ static void toX_f(const char *display) {
if (window->wm_name)
  if (!XFree(window->wm_name)) fatal(gettext("XFree(wm_name) for 
change"));
if ((window->wm_name=getWindowTitle(win))) {
- if (win==curWindow)
+ if (!quiet && win==curWindow)
api_setName(window->wm_name);
} else fprintf(stderr,gettext("window %#010lx changed to NULL 
name\n"),win);
  }

Bug#777573: alsa-base: Sound works, then stops working

[Timothy M Dowd]

Package: alsa-base
Version: 1.0.27+1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***
Sorry I've posted this on an old bug and misidentified it as being vlc related. 
I think I'm finally in the right place, and I'm sorry if I'm still not.
   * What led up to the situation?
Playing sound using several applications (banshee and vlc) works for a short 
length of time, about 7-15 minutes, and then the sound cuts out. The 
application clearly still assumes that it's playing sound- the progress bar 
continues, everything looks normal, but a reboot is required.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The computer worked normally with Wheezy. It worked ok for about a week under 
Jessie, but it was the last kernel upgrade (sometime in the last week and a 
half) when it stopped working well

I've removed pulse audio but the problem remains.
   
Thank you for your time, and all y'all do to give us a gem like Debian.

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

Kernel: Linux 3.16.0-4-686-pae (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)

Versions of packages alsa-base depends on:
ii  dpkg  1.17.23
ii  kmod  18-3

alsa-base recommends no packages.

alsa-base suggests no packages.

-- no debconf information


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

Bug#777479: subversion: svn diff outputs 2 chunks instead of 1 when there are 6 consecutive unmodified lines

[James McCoy]

Control: severity -1 minor

On Sun, Feb 08, 2015 at 07:19:14PM +0100, Vincent Lefevre wrote:
> Contrary to the "diff" utility, "svn diff" outputs 2 chunks instead
> of 1 when there are 6 consecutive unmodified lines.

I don't think svn claims to produce identical diffs to that of the diff
command, so this is at most a minor issue, if not wishlist.

Also, the diffs are functionally equivalent, so I'm not sure how this
matters other than the diffs being different.

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


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

Bug#777513: unblock: openldap/2.4.40-4 (pre-approval)

[Ryan Tandy]

On Mon, Feb 09, 2015 at 02:52:37PM +0100, Julien Cristau wrote:

May we upload with these changes?


Please do.


Uploaded, accepted, and built (almost) everywhere.

Thanks for your work,

Ryan


signature.asc
Description: Digital signature

Bug#777572: diod: new upstream version available (v1.0.23)

[russm]

Package: diod
Version: 1.0.21-1
Severity: normal

Dear Maintainer,

Diod v1.0.23 was tagged and released in August of last year.

https://github.com/chaos/diod/releases



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

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages diod depends on:
ii  libc62.13-38+deb7u7
ii  libcap2  1:2.22-1.2
ii  liblua5.1-0  5.1.5-4+deb7u1
ii  libmunge20.5.10-1
ii  libncurses5  5.9-10
ii  libtinfo55.9-10
ii  libwrap0 7.6.q-24

diod recommends no packages.

diod suggests no packages.


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

Bug#777567: vim-gtk: Regions of text fail to redraw in gvim

[James McCoy]

On Mon, Feb 09, 2015 at 05:45:59PM -0500, Josef Boyd wrote:
> I'm using gVim on a fresh sid install. When I open up a file and scroll around
> (usually using the PgUp and PgDn keys), I'll often see large areas of text
> missing from the screen. What I'm seeing is very similar to what's in the
> linked video in this superuser question: http://superuser.com/questions/343599
> /gvim-redraw-failure

This is most likely an issue in the video driver or compositor.  Can you
include the output of running the “reportbug --template xserver-xorg”
command?

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


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

Bug#777571: debian/control: trailing whitespace breaks debchange(1)

[Simon McVittie]

Source: dnsmasq
Version: 2.72-2
Severity: minor

The debchange(1) utility in devscripts, commonly used via its dch(1) alias,
is a convenient tool to add changelog entries to a package. Unfortunately,
it cannot parse dnsmasq's control file due to a line at the end containing
only spaces, which Parse::DebControl interprets as an indented
line-continuation with nothing to continue:

% dch
Parse error: indented entry without previous line at line 46 of data (" ").

After jessie is released, it would be great if you could tidy up the
whitespace so that standard tools work on it - that makes NMUs a lot easier!

debian/changelog also has unusual formatting (probably because you
haven't been using debchange): there are various lines containing only
whitespace which might well confuse some changelog parsers, and the
bullet points are indented one space more than is conventional.

S


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

Bug#770674: systemd: encrypted disk passphrase prompt nearly unusable without plymouth

[Maximilian Gaukler]

merge 770674 768314
thanks

Hi Denis,

Thanks for reporting the bug. I also encountered it and believe it is 
the same as #768314.


Max


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

Bug#777570: unblock: debbugs/2.4.1.1

[Don Armstrong]

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

Please unblock package debbugs

This fixes the RC bug #775053 where examples in
/usr/share/doc/debbugs/examples were parsed in the postinst to
generate config files. This is pretty broken in general, but this
minimal fix fixes the issue until I really fix it with a new release
for jessie+1.

diff -Nru debbugs-2.4.1/debian/changelog debbugs-2.4.1.1/debian/changelog
--- debbugs-2.4.1/debian/changelog  2003-06-06 01:28:51.0 -0700
+++ debbugs-2.4.1.1/debian/changelog2015-02-05 09:37:34.0 -0800
@@ -1,3 +1,11 @@
+debbugs (2.4.1.1) unstable; urgency=medium
+
+  * Move examples out of /usr/share/doc/debbugs/examples which are parsed
+in postinst to /usr/share/debbugs/examples. Thanks to Vagrant
+Cascadian for the patch. (Closes: #775053).
+
+ -- Don Armstrong   Wed, 04 Feb 2015 18:04:08 -0800
+
 debbugs (2.4.1) unstable; urgency=low
 
   * Colin Watson:
diff -Nru debbugs-2.4.1/debian/control debbugs-2.4.1.1/debian/control
--- debbugs-2.4.1/debian/control2003-06-05 19:26:20.0 -0700
+++ debbugs-2.4.1.1/debian/control  2015-02-05 07:17:08.0 -0800
@@ -2,7 +2,7 @@
 Section: misc
 Priority: optional
 Maintainer: Debbugs developers 
-Uploaders: Josip Rodin , Colin Watson 

+Uploaders: Don Armstrong 
 Standards-Version: 3.2.1
 Build-Depends-Indep: debhelper
 
diff -Nru debbugs-2.4.1/debian/debbugsconfig 
debbugs-2.4.1.1/debian/debbugsconfig
--- debbugs-2.4.1/debian/debbugsconfig  2002-11-25 04:34:56.0 -0800
+++ debbugs-2.4.1.1/debian/debbugsconfig2015-02-04 18:08:27.0 
-0800
@@ -72,7 +72,7 @@
 sub template {
   my ($name, $destdir) = @_;
   if (! -f "$destdir/$name") {
-  system("cp /usr/share/doc/debbugs/examples/$name $destdir/$name") == 0 ||
+  system("cp /usr/share/debbugs/examples/$name $destdir/$name") == 0 ||
die "$!";
   print "created $destdir/$name from template.\n";
   }
diff -Nru debbugs-2.4.1/debian/dirs debbugs-2.4.1.1/debian/dirs
--- debbugs-2.4.1/debian/dirs   2002-11-17 09:09:40.0 -0800
+++ debbugs-2.4.1.1/debian/dirs 2015-02-04 18:08:27.0 -0800
@@ -2,7 +2,7 @@
 etc/debbugs/indices
 usr/lib/debbugs
 usr/sbin
-usr/share/doc/debbugs/examples
+usr/share/debbugs/examples
 var/lib/debbugs/indices
 var/lib/debbugs/www/cgi
 var/lib/debbugs/www/db
diff -Nru debbugs-2.4.1/debian/rules debbugs-2.4.1.1/debian/rules
--- debbugs-2.4.1/debian/rules  2002-11-25 04:25:05.0 -0800
+++ debbugs-2.4.1.1/debian/rules2015-02-04 18:08:27.0 -0800
@@ -28,6 +28,7 @@
$(MAKE) install_mostfiles DESTDIR=$(tmp_dir)
dh_installdocs
dh_installchangelogs
+   dh_link usr/share/debbugs/examples usr/share/doc/debbugs/examples
dh_strip
dh_compress -X examples/text
dh_fixperms
diff -Nru debbugs-2.4.1/Makefile debbugs-2.4.1.1/Makefile
--- debbugs-2.4.1/Makefile  2002-11-25 04:25:05.0 -0800
+++ debbugs-2.4.1.1/Makefile2015-02-04 18:08:27.0 -0800
@@ -8,7 +8,7 @@
 doc_dir:= $(DESTDIR)/usr/share/doc/debbugs
 man_dir:= $(DESTDIR)/usr/share/man
 man8_dir   := $(man_dir)/man8
-examples_dir   := $(doc_dir)/examples
+examples_dir   := $(DESTDIR)/usr/share/debbugs/examples
 
 scripts_in := $(filter-out scripts/config.in scripts/errorlib.in 
scripts/text.in, $(wildcard scripts/*.in))
 htmls_in   := $(wildcard html/*.html.in)


unblock debbugs/2.4.1.1

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

Kernel: Linux 3.16.0-4-amd64 (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)


-- 
Don Armstrong  http://www.donarmstrong.com

You could say to the Universe this is not /fair/. And the Universe
would say: Oh it isn't? Sorry.
 -- Terry Pratchett _Soul Music_ p357


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

Bug#775799: RFS: libmodule-install-rtx-perl/0.37-1 [ITP]

[Satoru KURASHIKI]

hi,

On Mon, Jan 26, 2015 at 11:13 AM,   wrote:
> describe its origin somewhere (changelog, README.Debian, etc.)

> you should add new entry about debian/patches/01-fix-plugindir.patch
> and describe its origin here. of cource, this patch's license stays GPL-2.

Sorry for late, I've fixed these issue and update mentors' package.
(I add new Files: entry, and README.Debian to refer them)

regards,
-- 
KURASHIKI Satoru


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

Bug#768314: systemd: encrypted disk passphrase prompt nearly unusable without plymouth

[Maximilian Gaukler]

found 768314 systemd/215-10
fixed 768314 systemd/218-8
retitle 768314 systemd: encrypted disk passphrase prompt nearly unusable 
without plymouth

severity important 768314
thanks


Hi everyone,


after half a day of testing and reproducing I would like to summarize 
this bug and add my own explanation:



Summary:

The way in which systemd queries for cryptsetup passwords is badly 
usable in multiple ways. There are two main problems:
- Other output is not suppressed, which may overwrite or hide the 
password prompt (except when plymouth io multiplexing is active)

- a 90 second startup timeout kills the password prompt after inactivity

For one disk, this is a slight usability problem. For multiple encrypted 
volumes with longer passwords, it is a nightmare that makes using the 
system annoying or impossible, often dropping to a rescue shell.




Steps to reproduce it without any special hardware:

- setup a simple debian jessie installation, unencrypted root+swap, no 
LVM or fancy stuff
   (e.g. in virtualbox, use snapshots for quickly rolling back after 
testing something)

- apt-get install cryptsetup
- run the attached reproducer script as root. It sets up 3 crypto disks 
from loopback files.

- reboot



test scenarios:

a) try to enter the password - it is "test" for each of the 3 disks
 -> If you enter your password correctly, it works most of the time.
screen shot is attached, please note that the last two password prompts 
are immediately overwritten by other messages.


b) just press enter randomly instead of typing a password
 -> even the next password prompts will not be visible, but overwritten 
by other messages!


c) just wait for >90sec
-> an emergency shell will be started and stopped, mixed with some 
password prompts and "A start job is running for..."
-> if you wait even longer, the system will perform a weird dance 
between "Give root password" and "Please enter passphrase for disk".



Test results:




Possible solutions and workarounds:

a) installing plymouth *and* enabling it by adding "splash" to the 
default kernel commandline.


Just installing plymouth will not help here due to bug #768329 in 
plymouth. If this were fixed we could add a dependency (recommends?) for 
plymouth to systemd/jessie or cryptsetup/jessie as a dirty workaround.


b) systemd 218-8 from experimental
solves the underlying problems good enough so that I consider the bug as 
fixed there:

- suppressing unnecessary output
- not having a timeout on password entry

For comparison, two screenshots are attached. In both I entered the 
first two passwords and then made a screenshot at the password prompt 
for the third disk. found-*.png is the problematic systemd version 
currently in jessie, notfound-*.png the one in experimental.



Thanks

Max

-
(Since I am not very familiar with the debian bug tracking system, 
please remind me if I do something wrong.)
#!/bin/bash
set -e
echo -n test > /root/cryptPassphrase

num_disks=3
for i in `seq 1 $num_disks`; do
echo "cryptTest$i /root/cryptTest$i none luks" >> /etc/crypttab
echo "/dev/mapper/cryptTest$i /mnt/cryptTest$i ext4 defaults 0 0" >> 
/etc/fstab
mkdir -p /mnt/cryptTest$i
fallocate /root/cryptTest$i -l 42M
cryptsetup --batch-mode luksFormat /root/cryptTest$i 
/root/cryptPassphrase 
cryptsetup luksOpen /root/cryptTest$i cryptTest$i 
--key-file=/root/cryptPassphrase 
mkfs.ext3 /dev/mapper/cryptTest$i
cryptsetup luksClose cryptTest$i
done

echo "now reboot. The crypto password is: test"

Bug#766686: gnome-orca: Please apply a patch applied upstream

[Jean-Philippe MENGUAL]

Package: gnome-orca
Version: 3.14.0-3
Followup-For: Bug #766686

Dear Maintainer,

Thanks Joanie's work, a workaround was committed in master (commit
9dc9b6dc8b6bb4d7092e2c0ad6e7973340fa023a). Could you apply it for gnome-orca
3.10.0-4? It doesn't seem to have a big colateral effects risk and improves
Orca. It's waiting for LibreOffice fixes in their a11y stack.

Thanks,


*** 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 ***


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

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

Versions of packages gnome-orca depends on:
ii  gir1.2-glib-2.01.42.0-2.2
ii  gir1.2-gtk-3.0 3.14.5-1
ii  gir1.2-pango-1.0   1.36.8-3
ii  gir1.2-wnck-3.03.4.9-3
ii  gsettings-desktop-schemas  3.14.1-1
ii  python33.4.2-2
ii  python3-brlapi 5.2~20141018-3
ii  python3-cairo  1.10.0+dfsg-4+b1
ii  python3-gi 3.14.0-1
ii  python3-louis  2.5.3-3
ii  python3-pyatspi2.14.0+dfsg-1
ii  python3-speechd0.8-7
pn  python3:any
ii  speech-dispatcher  0.8-7

Versions of packages gnome-orca recommends:
ii  libgail-common  2.24.25-1
ii  xbrlapi 5.2~20141018-3

gnome-orca suggests no packages.

-- no debconf information


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

Bug#747863: systemd service fails by default and causes package install failure

[Laurent Bigonville]

reopen 747863
thanks

Hello,

As explained, I don't think the patch is complete and dropping
the .service file so late in the release cycle doesn't seems a good
idea.

I've prepared a new upload that is actually restoring
the .service files and adding a wrapper around the executables.

Please see:
http://anonscm.debian.org/cgit/collab-maint/nut.git/log/?h=debian-jessie

What would be the opinion of the RT about this change?

Cheers,

Laurent Bigonville


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

Bug#777569: unblock: evolution-data-server/3.12.9~git20141128.5242b0-2+deb8u1

[Laurent Bigonville]

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

Hello,

Could you please unblock package evolution-data-server

The latest upload fixes different crashes:

* d/p/03_Use-after-free-gpg-verif.patch: Fix crash during GPG signature
  verification (Closes: #772802)
* d/p/04_sqlite-Track-pending-sync-requests.patch: Properly track pending
  sync requests before closing the sqlite files (Closes: #775701)

The 2 patches are coming from upstream.

Cheers,

Laurent Bigonville

unblock evolution-data-server/3.12.9~git20141128.5242b0-2+deb8u1

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

Kernel: Linux 3.18.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru evolution-data-server-3.12.9~git20141128.5242b0/debian/changelog evolution-data-server-3.12.9~git20141128.5242b0/debian/changelog
--- evolution-data-server-3.12.9~git20141128.5242b0/debian/changelog	2014-11-30 23:59:54.0 +0100
+++ evolution-data-server-3.12.9~git20141128.5242b0/debian/changelog	2015-01-30 00:57:21.0 +0100
@@ -1,3 +1,12 @@
+evolution-data-server (3.12.9~git20141128.5242b0-2+deb8u1) unstable; urgency=medium
+
+  * d/p/03_Use-after-free-gpg-verif.patch: Fix crash during GPG signature
+verification (Closes: #772802)
+  * d/p/04_sqlite-Track-pending-sync-requests.patch: Properly track pending
+sync requests before closing the sqlite files (Closes: #775701)
+
+ -- Laurent Bigonville   Fri, 30 Jan 2015 00:57:19 +0100
+
 evolution-data-server (3.12.9~git20141128.5242b0-2) unstable; urgency=medium
 
   * Fix brown paper bug in libcamel1.2-dev dependencies.
diff -Nru evolution-data-server-3.12.9~git20141128.5242b0/debian/patches/03_Use-after-free-gpg-verif.patch evolution-data-server-3.12.9~git20141128.5242b0/debian/patches/03_Use-after-free-gpg-verif.patch
--- evolution-data-server-3.12.9~git20141128.5242b0/debian/patches/03_Use-after-free-gpg-verif.patch	1970-01-01 01:00:00.0 +0100
+++ evolution-data-server-3.12.9~git20141128.5242b0/debian/patches/03_Use-after-free-gpg-verif.patch	2015-01-29 23:49:10.0 +0100
@@ -0,0 +1,21 @@
+From e46c53c21291f7844c72ce964f1eaaa0397abbe2 Mon Sep 17 00:00:00 2001
+From: Milan Crha 
+Date: Fri, 12 Dec 2014 14:11:04 +0100
+Subject: Bug 741434 - Use-after-free after error in GPG signature verification
+
+
+diff --git a/camel/camel-gpg-context.c b/camel/camel-gpg-context.c
+index 742e943..0b694a7 100644
+--- a/camel/camel-gpg-context.c
 b/camel/camel-gpg-context.c
+@@ -1888,6 +1888,7 @@ gpg_verify_sync (CamelCipherContext *context,
+ 
+ 	g_object_unref (filter);
+ 	g_object_unref (istream);
++	istream = NULL;
+ 
+ 	g_seekable_seek (G_SEEKABLE (canon_stream), 0, G_SEEK_SET, NULL, NULL);
+ 
+-- 
+cgit v0.10.1
+
diff -Nru evolution-data-server-3.12.9~git20141128.5242b0/debian/patches/04_sqlite-Track-pending-sync-requests.patch evolution-data-server-3.12.9~git20141128.5242b0/debian/patches/04_sqlite-Track-pending-sync-requests.patch
--- evolution-data-server-3.12.9~git20141128.5242b0/debian/patches/04_sqlite-Track-pending-sync-requests.patch	1970-01-01 01:00:00.0 +0100
+++ evolution-data-server-3.12.9~git20141128.5242b0/debian/patches/04_sqlite-Track-pending-sync-requests.patch	2015-01-30 00:03:29.0 +0100
@@ -0,0 +1,178 @@
+From a1bc3301e7e2d5ad810370f048c209d45f709017 Mon Sep 17 00:00:00 2001
+From: Milan Crha 
+Date: Fri, 5 Dec 2014 12:22:05 +0100
+Subject: [SQLite VFS] Track pending sync requests
+
+The sync request are done asynchronously, in a dedicated thread,
+which means that the database file can be closed meanwhile. The
+database has no reference counting, thus it's required to track
+whether there are any pending sync requests, to not free the
+structure too early.
+
+diff --git a/camel/camel-db.c b/camel/camel-db.c
+index fb0e581..0106741 100644
+--- a/camel/camel-db.c
 b/camel/camel-db.c
+@@ -53,6 +53,12 @@ typedef struct {
+ 	GRecMutex sync_mutex;
+ 	guint timeout_id;
+ 	gint flags;
++
++	/* Do know how many syncs are pending, to not close
++	   the file before the last sync is over */
++	guint pending_syncs;
++	GMutex pending_syncs_lock;
++	GCond pending_syncs_cond;
+ } CamelSqlite3File;
+ 
+ static gint
+@@ -91,6 +97,13 @@ sync_request_thread_cb (gpointer task_data,
+ 
+ 	call_old_file_Sync (sync_data->cFile, sync_data->flags);
+ 
++	g_mutex_lock (&sync_data->cFile->pending_syncs_lock);
++	g_warn_if_fail (sync_data->cFile->pending_syncs > 0);
++	sync_data->cFile->pending_syncs--;
++	if (!sync_data->cFile->pending_syncs)
++		g_cond_signal (&sync_data->cFile->pending_syncs_cond);
++	g_mutex_unlock (&sync_data->cFile->pending_syncs_lock);
++
+ 	done = sync_data->done;
+ 	g_free (sync_data);
+ 
+@@ -136,6 +149,10 @@ sync_push_request (CamelS

Bug#743310: rsnapshot: Program calls with arguments containing quotations mark don't work anymore

[Christoph Egger]

Package: rsnapshot
Version: 1.3.1-4
Followup-For: Bug #743310

Hi!

Guess it has something to do with additional quoting. Makes rsnapshot mostly 
useless for me.

/etc/rsnapshot.conf
# ssh has no args passed by default, but you can specify some here.
#
ssh_args-i /root/.ssh/id_rsa_backup


/bin/cp -al /srv/rsnapshot/daily.0 /srv/rsnapshot/daily.1 
/usr/bin/rsync -ax --delete --numeric-ids --relative --delete-excluded \
--rsh="/usr/bin/ssh -i /root/.ssh/id_rsa_backup" \
user@host:path \
/srv/rsnapshot/daily.0/entry/ 
rsync: Failed to exec /usr/bin/ssh -i /root/.ssh/id_rsa_backup: No such file or 
directory (2)
rsync error: error in IPC code (code 14) at pipe.c(85) [Receiver=3.1.1]
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in IPC code (code 14) at io.c(226) [Receiver=3.1.1]


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

Kernel: Linux 3.16.0-4-amd64 (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)

Versions of packages rsnapshot depends on:
ii  liblchown-perl  1.01-2+b1
ii  logrotate   3.8.7-1+b1
ii  perl5.20.1-5
ii  rsync   3.1.1-2+b1

Versions of packages rsnapshot recommends:
ii  openssh-client [ssh-client]  1:6.7p1-3

rsnapshot suggests no packages.

-- Configuration Files:
/etc/cron.d/rsnapshot changed [not included]
/etc/rsnapshot.conf changed [not included]

-- no debconf information


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

Bug#776735: error: no alternatives for gobby

[Philipp Kern]

On Sat, Jan 31, 2015 at 11:15:22PM +0100, Goswin von Brederlow wrote:
> Updating gobby from 0.4.13-1 to 0.5.0-4 fails with:
> 
> Preparing to unpack .../gobby_0.5.0-4_amd64.deb ...
> update-alternatives: error: no alternatives for gobby
> dpkg: error processing archive 
> /var/cache/apt/archives/gobby_0.5.0-4_amd64.deb (--unpack):
>  subprocess new pre-installation script returned error exit status 2

Did this legitimally happen upon upgrade? Because I would've expected
gobby-0.4 and gobby-0.5 to have been around. (Of course one can force
this to appear using dpkg -i and not satisfying dependencies, just
wondering if that happened here.)

I'll fix it anyhow, just trying to figure out if that needs to go into
jessie.

Kind regards and thanks for the report
Philipp Kern


signature.asc
Description: Digital signature

Bug#777500: RFS: birdie/1.1-1 [ITP]

[Tobias Frost]

Control: Tags -1 moreinfo
Control: Tags -1 owner !

Hi Kay,

Thanks for contributing to Debian

I see that this is your first package in Debian so,
http://mentors.debian.net/intro-maintainers might be a suggested
reading. (note that the above is a standard text I write always to new
sponsorees)
 

So lets start with birdie, here is a review.

- please always check the results on the mentors page:
http://mentors.debian.net/package/birdie tells you already that there
are some issues which should be fixed: UNRELEASED, no homepage, no
watchfile. Please check also all the "I" and "P" type warnings of
lintian and look if you can do something against them

- You need take ownership of the your ITP.

Into the package
- do not override "missing manpages lintian warnings" -- write them (the
man pages)
- please run "wrap-and-sort" on your debian directory -- it makes some
files easier to read.

- d/control: 
 * do not have a "." at the end of the short description, also the first
letter should not be capitalized. -- ref to  6.2.2 in the developers
reference. 
* are all those versions in your B-D's really required? (If the version
in Jessie is already newer than your requirement then drop it -- and
you're still nice to backporters)
* There is no homepage field.

- d/copyright:
 * it is not usual use the copyright-symbol ©, a Copyright: 
 is sufficient©  
 * The copyright is actually "Copyright: 2013-2014 Birdie Developers"
as stated in the source files, and upstream uses a odd (but valid)
license grant if which you should include a verbatim copy:
" This software is licensed under the GNU General Public License
  (version 3 or later). See the COPYING file in this distribution.
  .
  You should have received a copy of the GNU Library General Public
  License along with this software; if not, write to the
  Free Software Foundation, Inc., 59 Temple Place - Suite 330,
  Boston, MA 02111-1307, USA.
 .
 On Debian systems, the full text of the GNU General Public License
 version 3 can be found in the file `/usr/share/common-licenses/GPL-3'."

* the files in the dir cmake are not documented.

- the patch should have a proper dep3-style header. (and the bug
mentioned in your patch has nothing in common with it)
- why is this patch needed? why are you creating the file in the name of
the upstream authors?

- did not try: are the icons regnerated at build time? There is also an
oddity: icons/128x128/apps has the svg in it, also other dirs have the
svg 

Other:
 - There is no VCS-* field it is really really recommended to have
packaging in a vcs repositry those days, e.g in git (and using
git-buildpackage. )  Please not this is no requirement from Policy or
like; I just do not sponsor packages not in a VCS.) 

So there's some homework... Ping me again when ready or feel free to ask
if you need more details. Then I will complete the review -- (it's quite
late already)

Again, Thanks for contributing!
--
tobi


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

Bug#775456: ITP: sankore -- interactive whiteboard interface

[Mike Gabriel]

Hi David,

thanks for taking this into your hand!!!

- Original message -
> On Thu, Jan 15, 2015 at 11:22:16PM +, Mike Gabriel wrote:
> > I have some packaging work in Git somewhere [2].
> […]
> > [2] http://code.it-zukunft-schule.de/gitweb?p=sankore.git;a=summary
> 
> Great, is it possible to check it out without any SSH access (or can you
> upload it somewhere accessible if it isn’t)?


Yeah!
git clone git://code.it-zukunft-schule.de/sankore.git
 
> Thanks, do not hesitate to apply into Debian Edu team membership on
> Alioth, where I initially intend to share the packaging work (I’m of
> course open to other ideas), if you’re not already there. I’d like to
> recycle as much work as possible from the initial intent by Miriam and
> Mike, and rebase it on the latest upstream version, then we may share
> the various packaging bits (license checking, code patching for
> DFSG-compliance, make it actually buildable and usable, test it, etc.)

For the schools we support here in Germany, I have an economical interest in 
seeing sankore packaged. I am currently quite busy with a new project around 
remote desktop computing, but put me at least on the list of power testers. I'd 
also be happy to help out with writing debian/copyright.

Mike

-- 

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

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


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

Bug#725803: wireless-regdb: FTBFS: No private key found

[Jérémy Bobbio]

tags 725803 + patch
user reproducible-bui...@lists.alioth.debian.org
usertags 725803 + signature
thanks

Ben Hutchings:
> It is true that this package cannot be auto-built, but it does not
> need to be.  This is explained in debian/README.source.

A way to make the package build reproducibly, the database could be
built and signed once during the clean target (or another target). The
signature could then be shipped as part of the source package, and
re-inserted during the build.

The attached patch implements this solution. The package should then be
auto-buildable in a reproducible manner.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
From 2eb8fed0af2efd51c3a9ff1f1984335212022f4b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= 
Date: Mon, 9 Feb 2015 19:52:17 +0100
Subject: [PATCH] Allow the package to be built reproducibly

As wireless-regdb requires a signature, it needs to be recorded
during the first build and copied as is on subsequent rebuilds.

In order to do so, we first patch db2bin.py to allow saving and
re-using a signature. Then, another patch will make the Makefile
use an intermediate signature file.

Finally, the clean rule is modified to refresh the signature if
required.
---
 .gitignore |  2 +
 ...nable_recording_and_using_an_external_signature | 93 ++
 debian/patches/series  |  2 +
 debian/patches/split_signature_generation  | 43 ++
 debian/rules   | 15 +++-
 5 files changed, 154 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/enable_recording_and_using_an_external_signature
 create mode 100644 debian/patches/split_signature_generation

diff --git a/.gitignore b/.gitignore
index 2011007..7046ec5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,5 @@ dbparse.pyc
 *.pub.pem
 regulatory.bin
 sha1sum.txt
+signature
+debian/signature.b64
diff --git a/debian/patches/enable_recording_and_using_an_external_signature b/debian/patches/enable_recording_and_using_an_external_signature
new file mode 100644
index 000..2a72de8
--- /dev/null
+++ b/debian/patches/enable_recording_and_using_an_external_signature
@@ -0,0 +1,93 @@
+From: Jérémy Bobbio 
+Subject: [PATCH] Enable recording and using an external signature
+
+To make wireless-regdb build reproducibly, we need a way to save
+the signature of the database to an external file and later reuse
+it instead of requiring the private key.
+
+diff --git a/db2bin.py b/db2bin.py
+index 41d3741..0ae01f3 100755
+--- a/db2bin.py
 b/db2bin.py
+@@ -11,6 +11,8 @@ VERSION = 19
+ 
+ if len(sys.argv) < 3:
+ print 'Usage: %s output-file input-file [key-file]' % sys.argv[0]
++print '   %s -s signature-file input-file key-file' % sys.argv[0]
++print '   %s -i signature-file output-file input-file' % sys.argv[0]
+ sys.exit(2)
+ 
+ def create_rules(countries):
+@@ -48,8 +50,27 @@ class PTR(object):
+ def get(self):
+ return self._offset
+ 
++if sys.argv[1] == '-s':
++signature_path = sys.argv[2]
++input_path = sys.argv[3]
++output_path = None
++key_path = sys.argv[4]
++elif sys.argv[1] == '-i':
++signature_path = sys.argv[2]
++output_path = sys.argv[3]
++input_path = sys.argv[4]
++key_path = None
++else:
++signature_path = None
++output_path = sys.argv[1]
++input_path = sys.argv[2]
++if len(sys.argv) > 3:
++key_path = sys.argv[3]
++else:
++key_path = None
++
+ p = DBParser()
+-countries = p.parse(file(sys.argv[2]))
++countries = p.parse(file(input_path))
+ power = []
+ bands = []
+ for c in countries.itervalues():
+@@ -118,28 +139,37 @@ for alpha2 in countrynames:
+ # struct regdb_file_reg_country
+ output.write(struct.pack('>ccxBI', str(alpha2[0]), str(alpha2[1]), coll.dfs_region, reg_rules_collections[coll.permissions]))
+ 
+-
+-if len(sys.argv) > 3:
++if key_path:
+ # Load RSA only now so people can use this script
+ # without having those libraries installed to verify
+ # their SQL changes
+ from M2Crypto import RSA
+ 
+ # determine signature length
+-key = RSA.load_key(sys.argv[3])
++key = RSA.load_key(key_path)
+ hash = hashlib.sha1()
+ hash.update(output.getvalue())
+ sig = key.sign(hash.digest())
+-# write it to file
+ siglen.set(len(sig))
++
+ # sign again
+ hash = hashlib.sha1()
+ hash.update(output.getvalue())
+ sig = key.sign(hash.digest())
+ 
++if output_path:
++output.write(sig)
++else:
++with file(signature_path, 'w') as sigfile:
++sigfile.write(sig)
++elif signature_path and output_path:
++with file(signature_path) as sigfile:
++  sig = sigfile.read()
++siglen.set(len(sig))
+ output.write(

Bug#777568: unblock: libvirt/1.2.9-9

[Guido Günther]

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

Please unblock package libvirt

This upload fixes two bugs with qemu/kvm preventing VMs to start. The
cleanup is an upgrade issue while the caps probing is a race with
recent (as in jessie) qemu.

Please unblock libvirt.
Cheers,
 -- Guido

unblock libvirt/1.2.9-9

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

Kernel: Linux 3.16.0-rc6 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index 3f49894..5932017 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+libvirt (1.2.9-9) unstable; urgency=medium
+
+  * [4c14b83] qemu: Don't try to parse -help for new QEMU.
+Closes: #777138, #775773
+Thanks to Mathieu Malaterre for the debugging
+  * [1addae5] Force capability refresh on upgrades. This makes sure we
+refresh the capabilities at least once when upgrading from Wheezy.
+(Closes: #731815)
+
+ -- Guido Günther   Fri, 06 Feb 2015 15:40:21 +0100
+
 libvirt (1.2.9-8) unstable; urgency=medium
 
   * [885f33d] Fix CVE-2015-0236.
diff --git a/debian/libvirt-daemon-system.postinst 
b/debian/libvirt-daemon-system.postinst
index ff68fd3..5d3ebd0 100644
--- a/debian/libvirt-daemon-system.postinst
+++ b/debian/libvirt-daemon-system.postinst
@@ -108,6 +108,9 @@ case "$1" in
 if [ -d /run/systemd/system ] && systemctl status virtlockd.service 
>/dev/null; then
systemctl reload virtlockd.service
 fi
+
+# Force refresh of capabilties (#731815)
+rm -f /var/cache/libvirt/qemu/capabilities/*.xml
 ;;
 
 abort-upgrade|abort-remove|abort-deconfigure)
diff --git a/debian/patches/qemu-Don-t-try-to-parse-help-for-new-QEM.patch 
b/debian/patches/qemu-Don-t-try-to-parse-help-for-new-QEM.patch
new file mode 100644
index 000..cdadbaf
--- /dev/null
+++ b/debian/patches/qemu-Don-t-try-to-parse-help-for-new-QEM.patch
@@ -0,0 +1,39 @@
+From: Mathieu Malaterre 
+Date: Thu, 5 Feb 2015 16:05:49 +0100
+Subject: Description: qemu: Don't try to parse -help for new QEMU
+
+Since QEMU 1.2.0, we switched to QMP probing instead of parsing -help
+(and other commands, such as -cpu ?) output. However, if QMP probing
+failed, we still tried starting QEMU with various options and parsing
+the output, which was guaranteed to fail because the output changed.
+Let's just refuse parsing -help for QEMU >= 1.2.0.
+
+Author: Jiri Denemark 
+Bug-Debian: https://bugs.debian.org/777138
+Origin: upstream, 
https://www.redhat.com/archives/libvir-list/2014-November/msg00407.html
+Reviewed-By: Mathieu Malaterre 
+---
+ src/qemu/qemu_capabilities.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
+index a409aaf..9e0158c 100644
+--- a/src/qemu/qemu_capabilities.c
 b/src/qemu/qemu_capabilities.c
+@@ -1382,6 +1382,16 @@ int virQEMUCapsParseHelpStr(const char *qemu,
+ 
+ *version = (major * 1000 * 1000) + (minor * 1000) + micro;
+ 
++/* Refuse to parse -help output for QEMU releases >= 1.2.0 that should be
++ * using QMP probing.
++ */
++if (*version > 1002000) {
++virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
++   _("QEMU %u.%u.%u is too new for help parsing"),
++   major, minor, micro);
++goto cleanup;
++}
++
+ if (virQEMUCapsComputeCmdFlags(help, *version, *is_kvm, *kvm_version,
+qemuCaps, check_yajl) < 0)
+ goto cleanup;
diff --git a/debian/patches/series b/debian/patches/series
index fb694c9..fcb95a0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -26,3 +26,4 @@ lxc-Don-t-crash-on-NULL-ifname_guest_actual.patch
 upstream/vbox-fix-a-bug-in-_machineStateInactive.patch
 security/CVE-2015-0236-qemu-Check-ACLs-when-dumping-security-.patch
 security/CVE-2015-0236-qemu-Check-ACLs-when-dumping-securi-14.patch
+qemu-Don-t-try-to-parse-help-for-new-QEM.patch

Bug#777567: vim-gtk: Regions of text fail to redraw in gvim

[Josef Boyd]

Package: vim-gtk
Version: 2:7.4.488-4
Severity: important

Dear Maintainer,

I'm using gVim on a fresh sid install. When I open up a file and scroll
around
(usually using the PgUp and PgDn keys), I'll often see large areas of text
missing from the screen. What I'm seeing is very similar to what's in the
linked video in this superuser question:
http://superuser.com/questions/343599
/gvim-redraw-failure

If I navigate through the empty area with the arrow keys, each character
will
display as the cursor goes over it, one at a time. Hitting PgUp or PgDn
again
will usually restore the text, but will often result in a different region
becoming blank. `:redraw`, `:redraw!` and ^L exhibit the same behavior.

Alt-Tabbing out and back into the window always redraws everything
correctly.

Trying to figure out what was wrong, I ran strace on the gvim process. To my
surprise, I could not reproduce the issue while strace was running! I then
realized it was because strace was frequently outputting to a terminal
behind
gVim, and evidently was forcing rapid screen redraws. So that seems to be a
workaround (but certainly not a good one).

I don't know much about low-level display stuff, so I'm not sure whether
this
is a gVim problem or something else. My terminal (terminator) does not
exhibit
anything like this, and neither does regular vim. I'm running lightdm and
openbox. I'm also running xcompmgr, but the issue persists whether or not
xcompmgr is running.

I should also note that I'm running on a virtual machine (VMware tools). I
say
that because I have a system running sid at home that does not have this
problem.

Let me know if you have any ideas.

Thanks!

Joe



-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.gtk
/usr/bin/vim is /usr/bin/vim.gtk
/usr/bin/gvim is /usr/bin/vim.gtk

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

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

Versions of packages vim-gtk depends on:
ii  libacl1 2.2.52-2
ii  libc6   2.19-15
ii  libgdk-pixbuf2.0-0  2.31.1-2+b1
ii  libglib2.0-02.42.1-1
ii  libgpm2 1.20.4-6.1+b2
ii  libgtk2.0-0 2.24.25-1
ii  libice6 2:1.0.9-1+b1
ii  liblua5.2-0 5.2.3-1.1
ii  libpango-1.0-0  1.36.8-3
ii  libperl5.20 5.20.1-5
ii  libpython2.72.7.9-1
ii  libruby2.1  2.1.5-1
ii  libselinux1 2.3-2
ii  libsm6  2:1.2.2-1+b1
ii  libtcl8.6   8.6.2+dfsg-1
ii  libtinfo5   5.9+20140913-1+b1
ii  libx11-62:1.6.2-3
ii  libxt6  1:1.1.4-1+b1
ii  vim-common  2:7.4.488-4
ii  vim-gui-common  2:7.4.488-4
ii  vim-runtime 2:7.4.488-4

vim-gtk recommends no packages.

Versions of packages vim-gtk suggests:
pn  cscope
ii  gnome-icon-theme  3.12.0-1
pn  ttf-dejavu
pn  vim-doc   

-- no debconf information

Bug#777566: RM: gobby [all] -- ROM; NVIU

[Philipp Kern]

Package: ftp.debian.org
Severity: normal

Please delete the gobby arch:all binary package 0.4.13-2 from sid.
It has been superseded by the 0.5.0-4 arch:any binary package built
by gobby-infinote.

Please also delete the gobby source package 0.4.13-2, along with the
other binaries built from it (gobby-0.4 and gobby-0.4-dbg) from sid.

Kind regards and thanks
Philipp Kern


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

Bug#777565: Incorrect warning shown about file size mismatch of GPG key

[Paul Menzel]

Package: apt
Version: 1.0.9.6
Severity: important

Dear Debian folks,


with, for example, the following package archive mirror entry

$ more /etc/apt/sources.list.d/tox.list
deb https://repo.tox.im/ nightly main

updating the package cache(?) by running `sudo apt update` shows the
following warning.

W: Size of file 
/var/lib/apt/lists/partial/repo.tox.im_dists_nightly_Release.gpg is not what 
the server reported 473 168

Looking at the “final” file it seems to have the correct size though.

$ ls -l /var/lib/apt/lists/repo.tox.im_dists_nightly_Release*
-rw-r--r-- 1 root root 1572 Feb  9 22:48 
/var/lib/apt/lists/repo.tox.im_dists_nightly_Release
-rw-r--r-- 1 root root  473 Feb  9 22:48 
/var/lib/apt/lists/repo.tox.im_dists_nightly_Release.gpg

Looking at the file on the server it also has a size of 473 bytes [1].

So the warning seems to be incorrect? I saw it with other mirrors too.


Thanks,

Paul


[1] https://repo.tox.im/dists/nightly/


-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

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

Versions of packages apt depends on:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.18-6
ii  libapt-pkg4.12  1.0.9.6
ii  libc6   2.19-13
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.6.11-1+b1
ii  dpkg-dev1.17.23
ii  python-apt  0.9.3.11
ii  synaptic0.81.3

-- no debconf information


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

Bug#777347: RFS: pidgin-gnome-keyring/2.0-1 [ITP] [RFP #714018] -- integrates pidgin (and libpurple) with the system keyring

[Luca Boccassi]

On 9 February 2015 at 10:55, Michael Fladischer  wrote:
> Hi Luca,

Hello Michael, thanks for taking the time to have a look!

> On 2015-02-07 16:45, luca.bocca...@gmail.com wrote:
>> I am looking for a sponsor for my package "pidgin-gnome-keyring"
>
> I'm not a DD yet, so I can't sponsor your package, but I did a review on
> what to improve to attract more potential sponsors:
>
> * Create a debian/watch file for use with `uscan` so automatic checks
> for newer upstream releases are possible.

Done.

> * The Vcs-* fields do not point to a repository that contains the
> packaging. Furthermore, the use of services like github is disputed for
> packaging in Debian. Maybe collab-maint on Alioth is a better place to
> keep your VCS, but that's up to you and your sponsor.

I changed the master branch, now it tracks the "debianised" version of
the repo so that the landing page and default branch have the
packaging bits. If the sponsor objects to GitHub I'll switch. Thanks
for pointing out Alioth, I'll be ready if needed. I picked GitHub
because the upstream code is there as well and it makes sending back
contributions easier.

> * You do not have to use overrides for dh_auto_install and
> dh_installdocs in debian/rules. Youc can use debian/.install
> and debian/.docs for a source package with multiple binary
> packages.

Took out the install override, but I couldn't find an alternative for
" dh_installdocs --link-doc" that will make the -dbg package symlink
the doc directory to the binary package. Any idea how to do it?

> * The PHONY target declaration is not really necessary.

Took it out.

> * Is the packaging (debian/*) really from Ali Ebrahim as described in
> debian/copyright or was it your work?

Good point, the original control file comes from Ali's Ubuntu
packages, but I changed it and added other files, so I added myself
under the debian/* copyright listing.

One more change I did, I added "export DEB_BUILD_MAINT_OPTIONS =
hardening=+all" to the debian/rules file since by default "Immediate
binding" is not turned on. A new upload with the changes is on
mentors.

Final question, the changelog lists the package as "UNRELEASED", I
think it's right since it's never been in any Debian distro, but on
mentors it's raised as a red flag, any idea if I should change it?

Thank you very much for the tips, I really appreciate them!

Kind regards,
Luca Boccassi


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

Bug#712920: quota: Unable to get quotas via RPC (connection refused)

[Christian Seiler]

Control: clone -1 -2
Control: retitle -1 libtirpc: breaks ABI compatibility w.r.t. libc6 on 64bit
Control: reassign -2 quota 4.01-7
Control: found -2 4.01-2
Control: retitle -2 quota: use libtirpc's headers when linking against it
Control: severity -2 important
Control: tags -2 + patch security
Control: thanks

(CC to maintainers of both quota and libtirpc packages)

Hi,

I ran across this very problem and started to debug it. I isolated the
problem to the following issue: libtirpc defines its 'struct svc_req'
differently compared to libc. libc's version is:

typedef unsigned long rpcprog_t;
typedef unsigned long rpcvers_t;
typedef unsigned long rpcproc_t;
typedef unsigned long rpcprot_t;
typedef unsigned long rpcport_t;

struct svc_req {
  rpcprog_t rq_prog;
  rpcvers_t rq_vers;
  rpcproc_t rq_proc;
  struct opaque_auth rq_cred;
  caddr_t rq_clntcred;
  SVCXPRT *rq_xprt;
};

whereas libtirpc's version is:

struct svc_req {
/* ORDER: compatibility with legacy RPC */
u_int32_t   rq_prog;/* service program number */
u_int32_t   rq_vers;/* service protocol version */
u_int32_t   rq_proc;/* the desired procedure */
struct opaque_auth rq_cred; /* raw creds from the wire */
void*rq_clntcred;   /* read only cooked cred */
SVCXPRT *rq_xprt;   /* associated transport */

/* New with TI-RPC */
caddr_t rq_clntname;/* read only client name */
caddr_t rq_svcname; /* read only cooked service cred */
};

On x86_32 this is fine, but on x86_64 unsinged long != u_int32_t.
Therefore, libtirpc and rpc.rquotad see two different record
structures.

The solution for the quota package is simple: if you link against
tirpc, use its compiler flags, i.e. -I/usr/include/tirpc, so that its
headers are used. Then there is no conflict when linking this. Since
the quota package started linking against tirpc in 4.01-2 in order to
have IPv6 support, I think this should definitely be fixed in the quota
package, because if you use both the functions and headers of either
libc6 or libtirpc, this problem does not occur, only if you mix them.
I've attached a patch that augments configure{,.in} of quota to use the
CFLAGS of libtirpc so that the include gets added automatically. I
tested this and this fixes the quota issue. (The patch applies on top
of the other quilt patches in the series, especially the libnl one.)
This is the minimal fix needed to get it working for Jessie; in the
long term I would suggest to properly support this in the build system
upstream.

I raised the severity to 'important' because the quota package still
works on non-NFS filesystems (or against servers with older versions of
quota), but I think you could easily make an argument that this is RC
because:

 - rpc.rquotad is completely useless in its current state in Jessie
   (doesn't work at all in normal operation)
   The quota client tool itself works as expected btw., regardless of
   this patch.

 - I think this could be classified as a security bug (hence the tag),
   since the same struct is interpreted in two different ways. I don't
   know whether this is actually exploitable (I'm not a security
   researcher), but since the struct is on the stack, I'd be really
   worried. (Also: the contents of the struct comes from the network!)

@Michael Meskes: since you don't use NFS yourself, as you said in this
bug report, and would like to solve the problem in quota in a
different manner than I did, I can test that for you.




For tirpc:

I've left open the report against libtirpc and left the severity
normal, because most programs that use both CFLAGS and LDLIBS of
libtirpc will never stumble upon this problem, but I do find it really
curious that libtirpc orders the fields in svc_req the same as in
libc6's (see comments), in order to claim that its compatible, but in
reality that's only the case if unsigned long is the same size (if you
include padding) as u_int32_t. Even more curious, in libc's sources,
there's a comment that rpcprog_t etc. should at some point be changed
to uint32_t, so we have reached maximum confusion here. Also, libtirpc
has had this forever, I checked the Wheezy version and already there
the structure was like that. I think that on the libtirpc level there
should at least be a documentation update that it is NOT ABI compatible
with libc6.

Thanks!

Christian
Index: quota-4.01/configure.in
===
--- quota-4.01.orig/configure.in
+++ quota-4.01/configure.in
@@ -186,6 +186,20 @@ AC_ARG_ENABLE(rpc,
 	[  --enable-rpc=[yes/no]   Enable RPC support [default=yes].],
 	,
 	enable_rpc="yes")
+if test "x$enable_rpc" != "xno"; then
+	PKG_CHECK_MODULES([RPC], [libtirpc])
+
+	if test -z "$RPC_CFLAGS" ; then
+		if test "x$enable_rpc" = "xyes"; then
+			AC_MSG_ERROR([Required libraries for RPC support not found.])
+		else
+			AC

Bug#777558: tex-common: Redundant function in postinst

[Norbert Preining]

On Mon, 09 Feb 2015, David Wright wrote:
> The following lines (50--55) in the postinst script appear to be
> redundant since the removal of a large chunk of postinst.

Thanks, removed in the git repo.

Norbert


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



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

Bug#777563: pm-utils: Thinkpad E130 reboots on resume

[Rychkov Valentin]

Package: pm-utils
Version: 1.4.1-9
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
The difference appeared after the last system update
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
used https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/648832
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_sleep=nonvs"
   * What was the outcome of this action?
nothing
   * What outcome did you expect instead?
fix


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

Kernel: Linux 3.2.0-4-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

Versions of packages pm-utils depends on:
ii  powermgmt-base  1.31

Versions of packages pm-utils recommends:
ii  hdparm   9.39-1+b1
ii  kbd  1.15.3-9
ii  procps   1:3.3.3-3
ii  vbetool  1.1-2

Versions of packages pm-utils suggests:
pn  cpufrequtils
ii  ethtool 1:3.4.2-1
ii  radeontool  1.6.2-1.1
ii  wireless-tools  30~pre9-8

-- no debconf information


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

Bug#777453: tracker.debian.org: Reset forgotten password not working

[ge...@riseup.net]

Hi Raphael,

Thanks for looking into this!

On 15-02-09 22:39:06, Raphael Hertzog wrote:
> On Sun, 08 Feb 2015, ge...@riseup.net wrote:
> > However, it seems, that the mail in question never gets sent; maybe
> > it's stuck somewhere or it doesn't get created. 
> 
> It's sent but it gets rejected because of:
> 
> [...]
> 
> I have pushed a fix to the tracker to use ow...@tracker.debian.org as
> sender address.

Seems appropriate... :)

> Please try again and let me know if it works better.

Works as expected now, thus closing this bug, thanks for the fast fix.

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#777562: python-nose-exclude: Enable tests during build of python-nose-exclude

[Corey Bryant]

Package: python-nose-exclude
Version: 0.2.0-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu vivid ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to enable tests to run during
build of python-nose-exclude.

Thanks for considering the patch.


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

Kernel: Linux 3.16.0-29-generic (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
=== modified file 'debian/rules'
--- debian/rules	2014-06-19 12:01:29 +
+++ debian/rules	2015-02-09 21:59:20 +
@@ -7,3 +7,6 @@
 
 %:
 	dh $@ --with python2,python3 --buildsystem=pybuild
+
+override_dh_auto_test:
+	python setup.py test

Bug#772551: Suricata: missing library libhtp-0.5.12.so.1

[Ralph J.Mayer]

* How this could happen? Aren't these errors supposed to show up on build logs?


suricata (2.0.4-1) was released 10.10.14, libhtp (0.5.15-1) six days later.

I think the problem is libhtp for setting the wrong SONAME.
Theres even a override in lintian, "upstream soname version is not correct"

I opened 777540 for this on libhtp after some discussion on #debian.de


rm


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

Bug#772551: Suricata: missing library libhtp-0.5.12.so.1

[Arturo Borrero Gonzalez]

On 9 February 2015 at 15:05, Pierre Chifflier  wrote:
> This bug is solved by the next (pending) uploading, to be validated by
> the release team.

I have a some questions:

* How this could happen? Aren't these errors supposed to show up on build logs?
* Why this doesn't seem to affect the version in wheezy-backports?

I would give suricata a basic autopkgtest support.
-- 
Arturo Borrero González


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

Bug#777453: tracker.debian.org: Reset forgotten password not working

[Raphael Hertzog]

Hi,

On Sun, 08 Feb 2015, ge...@riseup.net wrote:
> However, it seems, that the mail in question never gets sent; maybe it's
> stuck somewhere or it doesn't get created. 

It's sent but it gets rejected because of:

2015-02-09 20:01:17 1YKuWD-0002cK-2M ** ge...@riseup.net R=dnslookup 
T=remote_smtp: SMTP error from remote mail server after RCPT 
TO:: host mx1.riseup.net [198.252.153.129]: 504 5.5.2 
: Sender address rejected: need fully-qualified address

I have pushed a fix to the tracker to use ow...@tracker.debian.org as sender
address.

Please try again and let me know if it works better.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


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

Bug#775456: ITP: sankore -- interactive whiteboard interface

[Miriam Ruiz]

2015-02-09 20:09 GMT+01:00 David Prévot :

> Thanks Miriam, I indeed missed it since it had been renamed a year ago.
> You still own that ITP, are you still working on or interested in this
> package (based on any upstream fork of Open-Sankoré)?

Well, I'm certainly interested in having this package in Debian, of
course! Feel free to hijack my ITP though, if you want. If you want a
helping hand or plan to maintain it inside a team, feel free to count
on me :)

As some schools seem to be already using my packages, though they are
certainly not official, I'm periodically asked to upgrade them. My
last version is from september 2014, if you want to have a look at it:
http://miriamruiz.es/debian/sankore/

Greetings,
Miry


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

Bug#777553: pu: package libfcgi/2.4.0-8

[Salvatore Bonaccorso]

Hi Joe,

Not member of the release team here, so not authoritative ;-). So just
giving some comments. Btw, thanks for preparing the package!

> diff -Nru libfcgi-2.4.0/debian/changelog libfcgi-2.4.0/debian/changelog
> --- libfcgi-2.4.0/debian/changelog2011-08-20 14:44:38.0 -0700
> +++ libfcgi-2.4.0/debian/changelog2015-02-05 22:19:52.0 -0800
> @@ -1,3 +1,11 @@
> +libfcgi (2.4.0-8.2) wheezy-security; urgency=high

The version should be 2.4.0-8.1+deb7u1. 2.4.0-8.2 cannot be used as
2.4.0-8.2 was already in the archive. For the s-t-u wheezy-security as
distribution needs to be changed to wheezy.

> +  * Non-maintainer upload.
> +  * Apply path from Anton Kortunov to swap select with poll to avoid
> +stack smashing (See: #681591 and LP: #933417).

could you please reference as well the CVE in the changelog, and close
the bug: you can use "Closes: #681591" to reach this.

> diff -Nru libfcgi-2.4.0/debian/patches/poll libfcgi-2.4.0/debian/patches/poll
> --- libfcgi-2.4.0/debian/patches/poll 1969-12-31 16:00:00.0 -0800
> +++ libfcgi-2.4.0/debian/patches/poll 2015-02-05 22:18:28.0 -0800
> @@ -0,0 +1,81 @@
> +diff --git a/libfcgi/os_unix.c b/libfcgi/os_unix.c
> +index 73e6a7f..af35aee 100755
> +--- a/libfcgi/os_unix.c
>  b/libfcgi/os_unix.c
> +@@ -42,6 +42,7 @@ static const char rcsid[] = "$Id: os_unix.c,v 1.37 
> 2002/03/05 19:14:49 robs Exp

Not a strict requirement but would be nice to add some patch headers
to the atual patch, see http://dep.debian.net/deps/dep3/ for the patch
tagging guidelines.

Joe, if you get an ack from the release team on your upload for
libfcgi I can happily sponsor the upload itself.

Regards,
Salvatore


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

Bug#777561: banshee: Volume is set to 100% after file not found error

[Julian]

Package: banshee
Version: 2.6.1-3
Severity: important

If a file in the playlist can't be opened the volume is set to 100% before
Banshee continues playing the next available file.

The bug seems to be identical to the one mentiones here:
https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/64460
Launchpad states the bug to be fixed in 2008. But seems to be back in Debian
now.



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

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

Versions of packages banshee depends on:
ii  gnome-icon-theme 3.10.0-1
ii  gstreamer1.0-plugins-bad [gstreamer1.0-audi  1.2.1-1
ii  gstreamer1.0-plugins-base1.2.1-2
ii  gstreamer1.0-plugins-good [gstreamer1.0-aud  1.2.1-1
ii  gstreamer1.0-pulseaudio [gstreamer1.0-audio  1.2.1-1
ii  libboo2.0.9-cil  0.9.5~git20110729.r1.202a430-2
ii  libc62.17-97
ii  libcairo21.12.16-2
ii  libdbus-glib-1-2 0.100.2-1
ii  libdbus-glib1.0-cil  0.5.0-4
ii  libdbus1.0-cil   0.7.0-5
ii  libgconf2.0-cil  2.24.2-3
ii  libgdata2.1-cil  2.2.0.0-1
ii  libgdk-pixbuf2.0-0   2.28.2-1+b1
ii  libgkeyfile1.0-cil   0.1-4
ii  libglib2.0-0 2.40.0-3
ii  libglib2.0-cil   2.12.10-5
ii  libgpod4 0.8.3-1.1
ii  libgstreamer-plugins-base1.0-0   1.2.1-2
ii  libgstreamer1.0-01.2.1-1
ii  libgtk-sharp-beans-cil   2.14.1-3
ii  libgtk2.0-0  2.24.23-1
ii  libgtk2.0-cil2.12.10-5
ii  libgudev1.0-cil  0.1-3
ii  libkarma00.1.2-2.3
ii  libmono-addins0.2-cil1.0+git20130406.adcd75b-3
ii  libmono-cairo4.0-cil 3.0.6+dfsg2-10
ii  libmono-corlib4.5-cil3.0.6+dfsg2-10
ii  libmono-posix4.0-cil 3.0.6+dfsg2-10
ii  libmono-sharpzip4.84-cil 3.0.6+dfsg2-10
ii  libmono-system-core4.0-cil   3.0.6+dfsg2-10
ii  libmono-system-xml4.0-cil3.0.6+dfsg2-10
ii  libmono-system4.0-cil3.0.6+dfsg2-10
ii  libmono-zeroconf1.0-cil  0.9.0-4
ii  libmtp9  1.1.6-20-g1b9f164-1
ii  libnotify0.4-cil 0.4.0~r3032-6
ii  libpango-1.0-0   1.36.0-1
ii  libpangocairo-1.0-0  1.36.0-1
ii  libsoup-gnome2.4-1   2.44.1-1
ii  libsoup2.4-1 2.44.1-1
ii  libsqlite3-0 3.8.1-1
ii  libtaglib2.1-cil 2.1.0.0-3
ii  libwebkitgtk-1.0-0   2.2.2-1
ii  libwnck222.30.7-1
ii  libx11-6 2:1.6.2-1
ii  libxrandr2   2:1.4.1-1
ii  libxxf86vm1  1:1.1.3-1
ii  mono-runtime 3.0.6+dfsg2-10

Versions of packages banshee recommends:
ii  avahi-daemon 0.6.31-4
ii  brasero  3.8.0-2
ii  gstreamer1.0-pulseaudio  1.2.1-1
ii  media-player-info19-1

Versions of packages banshee suggests:
pn  banshee-dbg
pn  gstreamer1.0-ffmpeg
ii  gstreamer1.0-plugins-bad   1.2.1-1
ii  gstreamer1.0-plugins-ugly  1.2.1-1

-- no debconf information


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

Bug#776928: unblock: debian-installer-netboot-images/20150107

[Didier 'OdyX' Raboud]

Hi all,

Le dimanche, 8 février 2015, 21.54:04 Cyril Brulebois a écrit :
> Niels Thykier  (2015-02-06):
> > A debhelper compat is an explicit no-go per the freeze policy.
> > 
> > Otherwise, looks good to me.
> 
> It's a bit unfortunate that d-i-n-i is huge and not too useful to
> upload during the release cycle in that we get to only notice this
> kind of things ("woops, we bumped the debhelper version compat in
> that package too but it never reached testing") during the freeze;
> sorry about that.
> 
> Since d-i-n-i is basically about collecting files in packages (see
> get-images.sh), and about shipping them through various binaries, this
> kind of things is /possibly/ harmless, but I really didn't check
> anything. It would probably be helpful to double check that dh 7 and
> dh 9 lead to identical binaries, and maybe think about letting this
> change slide with the rest (but so far I really have no opinion on
> this).

So I've gone and done that (twice), the result of all debdiffs is exactl 
identical:

> File lists identical (after any substitutions)
> 
> No differences were encountered between the control files

This show that the change (but also that the revert) is harmless. 
Frankly, I'd find the "explicit no-go therefore imposing a revert" quite 
silly in this specific case.

> In case the explicit no-go stays (which I'd consider fair, to be
> honest), I'd rather avoid doing nasty things with the release version
> numbering (see Holger's reply), and get the revert through an upload
> matching RC 2. Which means getting d-i-n-i even later in testing but
> that would probably be safer.

That's technically correct. I'd find it quite sad to postpone a 
migration to testing for d-i-n-i, especially as every d-i upload [or at 
the very least, the final d-i] will impose a d-i-n-i upload and 
migration, again.

> On a slightly different note: Why we're still using a non-debian.org
> mirror (MIRROR in debian/rules) is still beyond me.

Using http.debian.net accelerates my builds by a big margin. I don't 
care enough though, so feel free to commit a change.

Cheers,
OdyX


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

Bug#777560: epiphany-browser: Epiphany doesn't show pocket button

[Roberto De Oliveira]

Package: epiphany-browser
Version: 3.14.1-1
Severity: normal

Dear Maintainer,

I like to use epiphany for web browsing and I was very happy with
announcement of pocket support. I already set up my pocket account in
gnome-online-accounts but I can't see any "save for later" button on
epiphany. 

Thanks in advance.


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

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

Versions of packages epiphany-browser depends on:
ii  dbus-x11 1.8.12-3
ii  epiphany-browser-data3.14.1-1
ii  gnome-icon-theme 3.12.0-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  gsettings-desktop-schemas3.14.1-1
ii  iso-codes3.57-1
ii  libatk1.0-0  2.14.0-1
ii  libavahi-client3 0.6.31-4+b2
ii  libavahi-common3 0.6.31-4+b2
ii  libavahi-gobject00.6.31-4+b2
ii  libc62.19-13
ii  libcairo-gobject21.14.0-2.1
ii  libcairo21.14.0-2.1
ii  libgcr-base-3-1  3.14.0-2
ii  libgcr-ui-3-13.14.0-2
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.1-1
ii  libgnome-desktop-3-103.14.1-1
ii  libgtk-3-0   3.14.5-1
ii  libjavascriptcoregtk-4.0-18  2.6.2+dfsg1-3
ii  libnotify4   0.7.6-2
ii  libnspr4 2:4.10.7-1
ii  libnss3  2:3.17.2-1.1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libsecret-1-00.18-1+b1
ii  libsoup2.4-1 2.48.0-1
ii  libsqlite3-0 3.8.7.1-1
ii  libwebkit2gtk-4.0-37 2.6.2+dfsg1-3
ii  libwnck-3-0  3.4.9-3
ii  libx11-6 2:1.6.2-3
ii  libxml2  2.9.1+dfsg1-4
ii  libxslt1.1   1.1.28-2+b2

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20141019
ii  evince   3.14.1-1
ii  yelp 3.14.1-1

epiphany-browser suggests no packages.

-- no debconf information


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

Bug#777559: [aufs-tools] auplink crashes

[Török Edwin]

Package: aufs-tools
Version: 1:3.2+20130722-1.1
Severity: normal

--- Please enter the report below this line. ---

Using a standard Debian kernel I noticed these crashes in dmesg:

[Mon Feb  9 18:27:58 2015] docker0: port 1(vethd6af4f5) entered forwarding state
[Mon Feb  9 18:27:58 2015] docker0: port 1(vethd6af4f5) entered forwarding state
[Mon Feb  9 18:28:13 2015] docker0: port 1(vethd6af4f5) entered forwarding state
[Mon Feb  9 18:30:17 2015] auplink[26764]: segfault at 7fffd11217f8 ip 
0031eb6db479 sp 7fffd1121800 error 6 in libc-2.19.so[31eb60+19f000]
[Mon Feb  9 18:30:17 2015] docker0: port 1(vethd6af4f5) entered disabled state
[Mon Feb  9 18:30:17 2015] device vethd6af4f5 left promiscuous mode
[Mon Feb  9 18:30:17 2015] docker0: port 1(vethd6af4f5) entered disabled state
[Mon Feb  9 18:30:17 2015] aufs au_plink_put:454:docker[9960]: pseudo-link is 
not flushed
[Mon Feb  9 18:30:32 2015] device vethb483b2f entered promiscuous mode
[Mon Feb  9 18:30:32 2015] IPv6: ADDRCONF(NETDEV_UP): vethb483b2f: link is not 
ready
[Mon Feb  9 18:30:32 2015] IPv6: ADDRCONF(NETDEV_CHANGE): vethb483b2f: link 
becomes ready
[Mon Feb  9 18:30:32 2015] docker0: port 1(vethb483b2f) entered forwarding state
[Mon Feb  9 18:30:32 2015] docker0: port 1(vethb483b2f) entered forwarding state
[Mon Feb  9 18:30:48 2015] docker0: port 1(vethb483b2f) entered forwarding state
[Mon Feb  9 18:42:32 2015] auplink[28259]: segfault at 7fff86fb8078 ip 
0031eb6db479 sp 7fff86fb8080 error 6 in libc-2.19.so[31eb60+19f000]
[Mon Feb  9 18:42:32 2015] aufs au_plink_put:454:docker[2727]: pseudo-link is 
not flushed
[Mon Feb  9 18:42:32 2015] docker0: port 1(vethb483b2f) entered disabled state
[Mon Feb  9 18:42:32 2015] device vethb483b2f left promiscuous mode
[Mon Feb  9 18:42:32 2015] docker0: port 1(vethb483b2f) entered disabled state
[Mon Feb  9 19:12:38 2015] device vethe4f62d0 entered promiscuous mode

$ uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 
GNU/Linux

Similar crashes reported here with some more info:
https://github.com/docker/docker/issues/10595

The testcase from that report reproduces the issue for me:
# auplink / flush
auplink:plink.c:341: no aufs mount point
Segmentation fault

# gdb auplink
(gdb) r / flush
Starting program: /sbin/auplink / flush
/sbin/auplink:plink.c:341: no aufs mount point

Program received signal SIGSEGV, Segmentation fault.
__strncpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy-ssse3.S:43
43  ../sysdeps/x86_64/multiarch/strcpy-ssse3.S: No such file or directory.
(gdb) bt
#0  __strncpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy-ssse3.S:43
#1  0x0040178c in strncpy (__len=20, __src=0x0, __dest=0x7fffe4f0 
"") at /usr/include/x86_64-linux-gnu/bits/string3.h:120
#2  au_plink (cwd=cwd@entry=0x604010 "/", cmd=cmd@entry=0, flags=flags@entry=1, 
fd=fd@entry=0x0) at plink.c:342
#3  0x004013ae in main (argc=, argv=) at 
auplink.c:64

I don't know why docker would call auplink on something that is not an aufs 
mountpoint (race condition?), but the crash when called on / reproduces 
everytime.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.0
  500 testing-updates ftp.ro.debian.org 
  500 testing security.debian.org 
  500 testing ftp.ro.debian.org 
  100 jessie-backports ftp.ro.debian.org 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#777338: Bug#764200: Bug#777338: game-data-packager: please add support for Doom3 BFG

[Tobias Frost]

Am Montag, den 09.02.2015, 11:25 + schrieb Simon McVittie:
> On 08/02/15 18:47, Alexandre Detiste wrote:
> +  doom3-data:
> +debian:
> +  engine: doom3-dhewm3
> 
> I would personally have just called the engine package dhewm3 (like the
> way I packaged ioquake3, iortcw and openjk), but it's up to you.

Name of the package is not fixed yet. (probably I will switch to dhwem3)

> +install_to: usr/share/games/doom3bfg
> 
> Again, I'd have used doom3-bfg-data here.

> If the upstream versions of dhewm3 and rbdoom3bfg, or the proprietary
> Linux binaries from id Software (if any), have default search paths in
> /usr/share or /usr/local, you can use "try_repack_from:" (see
> quake3.yaml) to add those to g-d-p's list. That might help to automate
> the process for some people.

Game's default search patch is /usr/share/games/doom3bfg.

> Regards,
> S


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

Bug#777558: tex-common: Redundant function in postinst

[David Wright]

Package: tex-common
Version: 5.03
Severity: minor

Dear Maintainer,

The following lines (50--55) in the postinst script appear to be
redundant since the removal of a large chunk of postinst.

--8>

cleanup()
{
  rc=$?
  [ -n "$tempdir" ] && rm -rf "$tempdir"
  exit $rc
}

--8>

cleanup used to be called from this snippet:

tempdir=`mktemp -d`
tempfile=`mktemp -p $tempdir`
trap 'cleanup' HUP INT QUIT BUS PIPE TERM

in the wheezy version.

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

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

Versions of packages tex-common depends on:
ii  debconf [debconf-2.0]  1.5.55
ii  dpkg   1.17.23
ii  ucf3.0030

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  9.20141022

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.55
ii  dpkg   1.17.23
ii  libpaper-utils 1.1.24+nmu4
ii  texlive-binaries   2014.20140926.35254-6
ii  ucf3.0030
ii  xdg-utils  1.1.0~rc1+git20111210-7.3

Versions of packages texlive-base recommends:
ii  lmodern  2.004.4-5

Versions of packages texlive-base suggests:
ii  evince [postscript-viewer]   3.14.1-1
ii  ghostscript [postscript-viewer]  9.06~dfsg-2
ii  gv [postscript-viewer]   1:3.7.4-1
ii  perl-tk  1:804.032-3+b3
ii  xpdf [pdf-viewer]3.03-17+b1

Versions of packages texlive-binaries depends on:
ii  dpkg  1.17.23
ii  install-info  5.2.0.dfsg.1-6
ii  libc6 2.19-13
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-2
ii  libgcc1   1:4.9.1-19
ii  libgmp10  2:6.0.0+dfsg-6
ii  libgraphite2-31.2.4-3
ii  libgs99.06~dfsg-2
ii  libharfbuzz-icu0  0.9.35-2
ii  libharfbuzz0b 0.9.35-2
ii  libice6   2:1.0.9-1+b1
ii  libicu52  52.1-7
ii  libkpathsea6  2014.20140926.35254-6
ii  libmpfr4  3.1.2-2
ii  libpaper1 1.1.24+nmu4
ii  libpixman-1-0 0.32.6-3
ii  libpoppler46  0.26.5-2
ii  libpotrace0   1.11-2
ii  libptexenc1   2014.20140926.35254-6
ii  libsm62:1.2.2-1+b1
ii  libstdc++64.9.1-19
ii  libsynctex1   2014.20140926.35254-6
ii  libx11-6  2:1.6.2-3
ii  libxaw7   2:1.0.12-2+b1
ii  libxext6  2:1.3.3-1
ii  libxi62:1.7.4-1+b2
ii  libxmu6   2:1.1.2-1
ii  libxpm4   1:3.5.11-1+b1
ii  libxt61:1.1.4-1+b1
ii  libzzip-0-13  0.13.62-3
ii  perl  5.20.1-5
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages texlive-binaries recommends:
ii  python2.7.8-3
ii  ruby  1:2.1.0.4
ii  texlive-base  2014.20141024-2
ii  tk [wish] 8.6.0+8

-- debconf information:
  tex-common/check_texmf_missing:
  tex-common/check_texmf_wrong:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  texlive-base/texconfig_ignorant:


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

Bug#764200: Bug#777338: game-data-packager: please add support for Doom3 BFG

[Tobias Frost]

Am Sonntag, den 08.02.2015, 19:47 +0100 schrieb Alexandre Detiste:
> Le samedi 7 février 2015, 18:07:34 Tobias Frost a écrit :
> > Am Samstag, den 07.02.2015, 15:21 + schrieb Simon McVittie:
> > > I'm happy to merge a patch, but I don't have Doom 3 (either the original
> > > or the BFG edition) so someone else will have to contribute the
> > > necessary file-list and checksums.
> > 
> > As I own both, maybe I can help here.
> > Gianfranco gave me some instructions how to generate the yaml file,
> > but I'm not sure if it's complete and what else is required. 
> > (It's still "building", so I follow up later)
> 
> Thansk for the files, I only needed to remove the references to doom.wad, 
> doom2.wad
> and nerve.wad; these are already handled by other yaml files.

note sure what's the effect... but the bfg edition includes those games
as well, so they also need to be installed.


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

Bug#777557: RFS: yosys/0.5.0-1

[Ruben Undheim]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: yosys
  Version : 0.5.0-1
  Upstream Author : Clifford Wolf 
* URL : http://www.clifford.at/yosys/
* License : ISC
  Section : electronics

 It builds those binary packages:

   yosys - Framework for Verilog RTL synthesis

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

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


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

   dget -x
http://mentors.debian.net/debian/pool/main/y/yosys/yosys_0.5.0-1.dsc

 or from the git repository:

git clone git://anonscm.debian.org/debian-science/packages/yosys.git

 More information about yosys can be obtained from
http://www.clifford.at/yosys/


 Changes since the last upload:

  * New upstream release
  * Added d/watch
  * Updated copyright years in d/copyright
  * Changed dependency from tcl8.5-dev to tcl-dev
  * Added d/gbp.conf
  * Added link from /usr/bin/yosys-abc to /usr/bin/berkeley-abc
- Also added man page for yosys-abc
  * Fixed paths returned by yosys-config
- fix included in 04_installpath.patch

 Regards,
  Ruben Undheim

Bug#749416: RFP: libhdt-it -- Library for RDF HDT file manipulation

[Kjetil Kjernsmo]

Hi!

I had a second look at this package, as I am soon going to code something 
around it, and I realized that I might not have understood fully what the 
different components do.

HDT-It seems to be a GUI tool to explore the data. While interesting, I 
don't think it is the most interesting, nor urgent part of the package, 
the most urgent is the underlying library, which seems to be stuff 
downloadable from here:
https://code.google.com/p/hdt-it/downloads/detail?name=hdt-lib-rc1-src.tgz

The HDT-It is something that can be done later once the libraries are in 
good shape.

Best,

Kjetil


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

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Bill Allombert]

On Mon, Feb 09, 2015 at 08:37:43PM +0100, Ansgar Burchardt wrote:
> Hi,
> 
> Bill Allombert  writes:
> > On Fri, Nov 21, 2014 at 12:23:17AM +0500, Andrey Rahmatullin wrote:
> >> On Sat, Aug 04, 2012 at 11:19:15AM +0900, Charles Plessy wrote:
> >> > How about the attached patch, that adds "Its value must not be empty."
> >> > after "The field ends at the end of the line or at the end of the last
> >> > continuation line".
> >> Seconded.
> >
> > Would you second the attached version that was posted in this bug
> > already ?
> 
> Looks fine to me, so seconded.
> 
> You might want to fix the commit message: it currently states the
> opposite of the change, i.e. that empty values are *not* allowed in
> source packages whereas that should be the only place where they *are*
> allowed.

Thanks for noticing!
I have updated the git branch to say

Document that empty field values are only allowed in debian/control.

Policy: [5.1] empty field values in control files are only permitted in
the debian/control file of a source package.
Wording:  Bill Allombert 
Seconded: Henrique de Moraes Holschuh 
Seconded: Andrey Rahmatullin 
Closes: #666726

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


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

Bug#776632: pulseaudio: fails to add bluetooth speakers as audio output device

[Stefan Nagy]

After finding a related bug report [1] (reported against bluez) I tried
to connect the speakers after boot several times (around 20 attempts
with two different notebooks). Before that I didn't realize that I
_always_ have to restart bluetoothd (or deactivate and reactivate the
bluetooth adapter) so that the speakers are added as output device when
I connect them… So now I can confirm that.

This report is probably a duplicate of #772717.



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


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

Bug#777338: Bug#764200: Bug#777338: game-data-packager: please add support for Doom3 BFG

[Alexandre Detiste]

> >> Adding .desktop files and icons for Doom WADs and ScummVM/ResidualVM
> >> games does stretch that rule, because .desktop files can have bugs (e.g.
> >> lack of Keywords, or a low-quality icon).
> > So we should contact these teams and ask if there would be ok to do it;
> > or provide a game-data-packager-data or game-data-packager-runtime
> > with those... then the generated games would depend on this new package.
> 
> Yeah, one of those is probably a good idea.

As an aftertought, game-DATA-packager-DATA is dumb name ...
I would go for game-data-packager-runtime .
Can I stuff the Doom2 master levels launcher in it ?


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

Bug#777481: [Pkg-clamav-devel] Bug#777481: clamav-daemon: /etc/clamav/freshclam.conf corruped after fresh installing clamav-daemon

[Andreas Cadhalpun]

Hi,

On 09.02.2015 19:27, Sebastian Andrzej Siewior wrote:

- I made a gzipped tar archive of the VM ready to send to you.
   please advice!


https://breakpoint.cc/bts_777481/Clamav-daemon-bug.tar.xz
c6753fb7fbb93533edfcdf4a6e6ad4ad  Clamav-daemon-bug.tar.xz
I repacked the archve to .xz 1.5GiB. It unpacks to 4.4 GiB.


Unfortunately the vdi disk seems to be broken. When I try to start the 
VM I just get:

FATAL: No bootable medium found! System halted.

Looking at the disk from a booted live medium
 shows no partitions, not even a partition table.

Best regards,
Andreas


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

Bug#776528: BackendException: ssh connection to user@hostname:22 failed: No authentication methods available

[Alexander Zangerl]

On Sun, 01 Feb 2015 20:47:04 +1300, Francois Marier writes:
>Here's the exact command line I have problems with, with only the GPG
>passphrase removed:
>
>$ PASSPHRASE= duplicity cleanup 
>--ssh-options="-oIdentityFile=/home/francois/backup/identity 
>-oUserKnownHostsFile=/home/francois/backup/known_hosts" --verbosity 1 --force 
>sftp://user@hostname/duplicity
>BackendException: ssh connection to user@hostname:22 failed: No authentication 
>methods available

hmm. i still can't reproduce it, neither with stable's duplicity (and 
paramiko), nor with sid's :-((

i created a testuser of your name, same directory structure (as far as keys are 
concerned), new unpassphrased
rsa key, but no luck. the only difference that i see in -v9 is that my target 
ssh server is older, 6.0 from 
stable versus your 6.6.1.

here's my paramiko log, pretty much the same as yours:

ssh: starting thread (client mode): 0xc522550L
ssh: Connected (version 2.0, client OpenSSH_6.0p1)
ssh: kex algos:[u'ecdh-sha2-nistp256', u'ecdh-sha2-nistp384', 
u'ecdh-sha2-nistp521', u'diffie-hellman-group-exchange-sha256', 
u'diffie-hellman-group-exchange-sha1', u'diffie-hellman-group14-sha1', 
u'diffie-hellman-group1-sha1'] server key:[u'ssh-rsa', u'ssh-dss'] client 
encrypt:[u'aes128-ctr', u'aes192-ctr', u'aes256-ctr', u'arcfour256', 
u'arcfour128', u'aes128-cbc', u'3des-cbc', u'blowfish-cbc', u'cast128-cbc', 
u'aes192-cbc', u'aes256-cbc', u'arcfour', u'rijndael-...@lysator.liu.se'] 
server encrypt:[u'aes128-ctr', u'aes192-ctr', u'aes256-ctr', u'arcfour256', 
u'arcfour128', u'aes128-cbc', u'3des-cbc', u'blowfish-cbc', u'cast128-cbc', 
u'aes192-cbc', u'aes256-cbc', u'arcfour', u'rijndael-...@lysator.liu.se'] 
client mac:[u'hmac-md5', u'hmac-sha1', u'umac...@openssh.com', 
u'hmac-sha2-256', u'hmac-sha2-256-96', u'hmac-sha2-512', u'hmac-sha2-512-96', 
u'hmac-ripemd160', u'hmac-ripemd...@openssh.com', u'hmac-sha1-96', 
u'hmac-md5-96'] server mac:[u'hmac-md5', u'hmac-sha1', u'umac...@openssh.com', 
u'hmac-sha2-256', u'hmac-sha2-256-96', u'hmac-sha2-512', u'hmac-sha2-512-96', 
u'hmac-ripemd160', u'hmac-ripemd...@openssh.com', u'hmac-sha1-96', 
u'hmac-md5-96'] client compress:[u'none', u'z...@openssh.com'] server 
compress:[u'none', u'z...@openssh.com'] client lang:[u''] server lang:[u''] kex 
follows?False
ssh: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
ssh: using kex diffie-hellman-group14-sha1; server key type ssh-rsa; cipher: 
local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; 
compression: local none, remote none
ssh: Switch to new keys ...
ssh: Trying key 79efd8a14d23dff17696585ccb2009c9 from 
/home/francois/backup/identity
ssh: userauth is OK

at this point my suspicion is that there's something wrong in paramiko, but i 
can't explain why 
it works for you if and only if you specify the (totally ignored!) knownhosts 
ssh option as a separate item.

regards
az


-- 
Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/
REAL*8 RESPONSE(8)
DATA /RESPONSE/ 8HYOU EVER,8H DONE IT,8H IN FORT,8HRAN IV?$
 -- Peter da Silva about the joys of string handling


signature.asc
Description: Digital Signature

Bug#777556: perl: regexp performance regression since 5.18

[Niko Tyni]

Package: perl
Version:: 5.20.1-5
Severity: serious
Tags: upstream
Forwarded: https://rt.perl.org/Ticket/Display.html?id=123743

This should possibly be considered a release critical performance
regression. Marking as 'serious' for now.

  (wheezy)$ seq -f "%01000.0f: 0c" 1000 | /usr/bin/time perl5.14.2 -ne 
'/.*:\s*ab/i'
  0.02user 0.00system 0:00.02elapsed 96%CPU (0avgtext+0avgdata 3260maxresident)k
  0inputs+0outputs (0major+168minor)pagefaults 0swaps
  
  (sid)$ seq -f "%01000.0f: 0c" 1000 | /usr/bin/time perl5.20.1 -ne 
'/.*:\s*ab/i'
  7.41user 0.00system 0:07.41elapsed 99%CPU (0avgtext+0avgdata 4100maxresident)k
  0inputs+0outputs (0major+204minor)pagefaults 0swaps
  
Upstream is working on a fix.
-- 
Niko Tyni   nt...@debian.org


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

Bug#777537: leaves files in /var/cache/pbuilder/result/ after build

[Guillem Jover]

On Mon, 2015-02-09 at 17:53:36 +0100, Joost van Baal-Ilić wrote:
> On Mon, Feb 09, 2015 at 04:38:35PM +0100, Holger Levsen wrote:
> > On Montag, 9. Februar 2015, David Prévot wrote:
> > > They are purposely built then uploaded and installed separately in the
> > > archive:
> > [...]
> > > Maybe this bug should rather be reassigned to the reproducible effort.
> > 
> > I dont think this bug is in any way related to the reproducible effort, 
> > that's 
> > just how I noticed it. As a mere user I'd be equally surprised if some 
> > build 
> > leaves stuff in the pbuilder results dir.
> > 
> > Maybe its just a very seldom used feature of pbuider.
> > 
> > > From the end of debian/rules:
> > > # list them in the .changes file, so that they'll get uploaded properly:
> > > dpkg-distaddfile debian-faq.en.html.tar.gz byhand -
> > > dpkg-distaddfile debian-faq.en.txt.gz byhand -
> > > dpkg-distaddfile debian-faq.en.ps.gz byhand -
> > > dpkg-distaddfile debian-faq.en.pdf.gz byhand -
> > 
> > I see. I'm not sure this should be part of the standard binary targets 
> > then...

The whole point of BYHAND processing is that it allows to include
non-standard files in the archive, if those are not included in the
*.changes file for every upload then the archive docs would always be
out-of-date compared to the package. If there's a problem, then it's in
pbuilder's (or whoever is in charge of) cleaning up, it should be
removing any artifacts referenced from the *.changes file.

> AFAIK, this is some ancient way to make sure these documents end up in
> ftp://ftp.debian.org/debian/doc/FAQ/ .  Could be this practice is obsolete now
> and/or should be dealt with differently.

I don't think there's any automatic way to pull stuff that is not
source or binary packages into the archive, no.

Regards,
Guillem


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

Bug#777555: live-config: not setting locale properly (gnome)

[jnqnfe]

Package: live-config
Version: 4.0.4-1

With a Debian sid amd64 live image, based on the gnome-desktop
live-image config, I cannot load gnome terminal. It turns out that this
is due to the locale not being set correctly.

The workaround is to click on the locale in the gnome control center (to
actually set it), and allow gnome to reload.

The locale that should be set is the default applied by live-config, I
am not setting an alternative in any way. live-config just appears to
not be applying the locale properly (in gnome at least).

Is there a fix that can be applied to live-config to solve this instead
of requiring users to resort to the hack discussed in the mailing list?

Previous mailing list discussions:
https://lists.debian.org/debian-live/2015/02/msg00026.html
https://lists.debian.org/debian-live/2015/01/msg00188.html


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

Bug#446688: Fixed upstream prior to 0.48.3.1

[Vincent Lefevre]

Control: reopen -1
Control: found -1 0.48.5-3

On 2015-02-09 17:34:07 +, Alex Valavanis wrote:
> The upstream developers believe this bug was fixed upstream sometime
> before 0.48.3.1-1. Please feel free to reopen if it's still present in
> more recent versions.

I started to write that I could no longer reproduce the bug... until
I remembered that font config could have some effect, which was
confirmed when I looked at fonts used in the generated PDF file.

If I use


  Helvetica
  
Arial
  


in my ~/.config/fontconfig/fonts.conf file, then everything is fine.
But if I do not use this, then the spacing is wrong when I open the
SVG file in inkscape.

Note: I initially used the above code to avoid bitmap fonts. Indeed,
without the above code:

$ fc-match Helvetica
helvR12-ISO8859-1.pcf.gz: "Helvetica" "Regular"

and with the above code:

$ fc-match Helvetica
Arial.ttf: "Arial" "Normal"

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


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

Bug#777269: more info

[Nicolas Kuttler]

On Mon, Feb 09, 2015 at 07:24:35AM +0100, Michael Biebl wrote:
> control: tags -1 moreinfo unreproducible
> [...]
> As far as I could test, everything just works.

Thank you for looking into this. I tried to reproduce the problem
myself in a vm and failed to do so as well. Further testing indicates
that I may be dealing with an intermittent hardware/firmware bug.


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

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Ansgar Burchardt]

Hi,

Bill Allombert  writes:
> On Fri, Nov 21, 2014 at 12:23:17AM +0500, Andrey Rahmatullin wrote:
>> On Sat, Aug 04, 2012 at 11:19:15AM +0900, Charles Plessy wrote:
>> > How about the attached patch, that adds "Its value must not be empty."
>> > after "The field ends at the end of the line or at the end of the last
>> > continuation line".
>> Seconded.
>
> Would you second the attached version that was posted in this bug
> already ?

Looks fine to me, so seconded.

You might want to fix the commit message: it currently states the
opposite of the change, i.e. that empty values are *not* allowed in
source packages whereas that should be the only place where they *are*
allowed.

Ansgar

> commit ec38643c34333231a2e179ba1e135fd2ebccbf7a
> Author: Bill Allombert 
> Date:   Sun Nov 23 16:16:21 2014 +0100
>
> Document that empty field values are only allowed in debian/control.
> 
> Policy: [5.1] empty field values in control files are not allowed in the
> debian/control file of a source package.
> Wording:  Bill Allombert 
> Seconded: Henrique de Moraes Holschuh 
> Closes: #666726
>
> diff --git a/policy.sgml b/policy.sgml
> index 947a1e1..4adee0b 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2558,7 +2558,9 @@ Package: libc6
> the field name is Package and the field value
> libc6.
>   
> -
> + Empty field values are only permitted in source package control 
> files
> +   (debian/control). Such fields are ignored.
> +
>   
> A paragraph must not contain more than one instance of a
> particular field name.
> @@ -2701,6 +2703,7 @@ Package: libc6
> file. These tools are responsible for removing the line
> breaks from such fields when using fields from
> debian/control to generate other control files.
> +   They are also responsible for discarding empty fields.
>   
>  
>   


signature.asc
Description: PGP signature

Bug#777549: Issue also appears in 6.7p1-3 on sid

[Karl Kornel]

found 777549 openssh/1:6.7p1-3
thank you


Hello!

It looks to me like this issue also exists in the latest version, on sid.

I checked this by grabbing openssh_6.7p1.orig.tar.gz and 
openssh_6.7p1-3.debian.tar.xz off of packages.debian.org, and then 
applying gssapi.patch to the source.


I see that the GSSAPI key-exchange algorithms are added to the head of 
the proposal in sshconnect2.c lines 170-188.  Then, on lines 222-223, 
the client checks to see if any key-exchange algorithms were specified 
as options; if they were, the existing contents of the proposal get 
blown away.


I was wondering if the block of code from lines 170-188 could be merged 
into the "#ifdef GSSAPI" block that exists at lines 227-236.  Those 
lines appear after the key-exchange algorithms proposal gets potentially 
blown away, so I think it would be safe to change at that point.


I'm sorry that I'm unable to build and test right now, but I don't have 
any hardware (physical or virtual) that I can test on.  If that changes, 
I'll let you know!


~ Karl


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

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Bill Allombert]

On Tue, Feb 10, 2015 at 12:07:32AM +0500, Andrey Rahmatullin wrote:
> On Mon, Feb 09, 2015 at 07:14:07PM +0100, Bill Allombert wrote:
> > On Fri, Nov 21, 2014 at 12:23:17AM +0500, Andrey Rahmatullin wrote:
> > > Control: tags -1 + patch
> > > 
> > > On Sat, Aug 04, 2012 at 11:19:15AM +0900, Charles Plessy wrote:
> > > > How about the attached patch, that adds "Its value must not be empty."
> > > > after "The field ends at the end of the line or at the end of the last
> > > > continuation line".
> > > Seconded.
> > 
> > Hello Andrey and Ansgar (and others)
> > 
> > Would you second the attached version that was posted in this bug already ?
> 
> > commit ec38643c34333231a2e179ba1e135fd2ebccbf7a
> > Author: Bill Allombert 
> > Date:   Sun Nov 23 16:16:21 2014 +0100
> > 
> > Document that empty field values are only allowed in debian/control.
> > 
> > Policy: [5.1] empty field values in control files are not allowed in the
> > debian/control file of a source package.
> > Wording:  Bill Allombert 
> > Seconded: Henrique de Moraes Holschuh 
> > Closes: #666726
> > 
> > diff --git a/policy.sgml b/policy.sgml
> > index 947a1e1..4adee0b 100644
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -2558,7 +2558,9 @@ Package: libc6
> >   the field name is Package and the field value
> >   libc6.
> > 
> > -
> > + Empty field values are only permitted in source package 
> > control files
> > + (debian/control). Such fields are ignored.
> > +
> > 
> >   A paragraph must not contain more than one instance of a
> >   particular field name.
> > @@ -2701,6 +2703,7 @@ Package: libc6
> >   file. These tools are responsible for removing the line
> >   breaks from such fields when using fields from
> >   debian/control to generate other control files.
> > + They are also responsible for discarding empty fields.
> > 
> >  
> > 
> Seconded.

Thanks, I have created a git branch bug666726-bill with this patch.
If nothing happen, I will commit it in a few day.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


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

Bug#770009: severity

[Bastien ROUCARIES]

control: severity -1 important


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

Bug#730216: please consider allowing pypy to build on machines with less ram.

[John Paul Adrian Glaubitz]

Hi Stefano!

On 02/09/2015 08:07 PM, Stefano Rivera wrote:

Hi John (2015.02.09_00:36:31_+0200)

Please let the decision whether a certain package should be built on
a certain architecture up to the porters.


OK, you make persuasive arguments. I'll remove it.


Thank you very much! I appreciate that.


At the time this check was implemented, many of Debian's architectures
had a wide range of RAM in buildds. There are far fewer "small" buildds
in the supported architectures these days. I think by now, most
architecture that do have some small buildds have blacklisted pypy on
them, so I am not too worried about blocking up the build queue.


Well, it isn't really an issue either way. The m68k buildds have 768 MiB
RAM at most, for example. However, we can use very fast swap areas
(RAM disk boards etc) such that the amount of RAM isn't much of an
issue.


I was more concerned about wasting time architectures with varying RAM
in buildds than archs that only have small buildds, where it'd be
unlikely to build anyway. But I can see why this would be an issue on
those archs.


Yeah, I understand. But normally we will just blacklist the package per
arch or build it manually so that isn't really an issue.

Thanks a lot for your help!

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


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

Bug#777554: nginx: add a new stream variant including RMTP module

[Christian Pointner]

Source: nginx
Severity: wishlist
Tags: patch

Dear Maintainer,

I'm using the nginx-rtmp-module on a regular basis and it works like a
charm. I maintain a little patch for the nginx package which i use to
build a nginx-stream variant. This variant contains RTMP as well as MP4, FLV 
and Lua modules enabled. Besides this changes it's a copy of the light variant.

It would be very nice to have this changes in Debian as i think this variant
is also very useful for other people. If you think adding a new variant
just for this purpose is too much maintenance work please consider to at
least add the RTMP module to nginx-extras. 

My patch only includes changes to the git repo and doesn't contain the 
module itself. Please download the module source from upstream Github repo
using the following commands:


mkdir -p debian/modules/nginx-rtmp-module
cd debian/modules/nginx-rtmp-module
wget https://github.com/arut/nginx-rtmp-module/archive/v1.1.6.tar.gz
tar --strip-components=1 -xzf v1.1.6.tar.gz
rm v1.1.6.tar.gz
cd ../../..


regards
 Christian Pointner

-- System Information:
Debian Release: jessie/sid
  APT prefers utopic-updates
  APT policy: (500, 'utopic-updates'), (500, 'utopic-security'), (500, 
'utopic'), (100, 'utopic-backports')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-30-generic (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
>From 81f0da9cffa875e9c6b6a8003c96d69c4c6b15be Mon Sep 17 00:00:00 2001
From: Christian Pointner 
Date: Mon, 9 Feb 2015 19:28:31 +0100
Subject: [PATCH] added variant for streaming applications

Signed-off-by: Christian Pointner 
---
 debian/changelog   | 10 +-
 debian/control | 66 --
 debian/copyright   |  5 +++
 debian/modules/README.Modules-versions |  4 +++
 debian/nginx-stream.dirs   |  1 +
 debian/nginx-stream.install|  1 +
 debian/nginx-stream.lintian-overrides  |  1 +
 debian/nginx-stream.postinst   | 37 +++
 debian/nginx-stream.prerm  | 22 
 debian/rules   | 22 +++-
 debian/source/include-binaries |  7 
 debian/tests/control   |  3 ++
 12 files changed, 166 insertions(+), 13 deletions(-)
 create mode 100644 debian/nginx-stream.dirs
 create mode 100644 debian/nginx-stream.install
 create mode 100644 debian/nginx-stream.lintian-overrides
 create mode 100644 debian/nginx-stream.postinst
 create mode 100644 debian/nginx-stream.prerm
 create mode 100644 debian/source/include-binaries

diff --git a/debian/changelog b/debian/changelog
index e5efd5b..c49e68e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,6 @@
 nginx (1.6.2-6) UNRELEASED; urgency=medium
 
-  [Michael Lustfield]
+  [ Michael Lustfield ]
   * debian/conf/sites-available/default:
 + Add comment about disabling gzip in HTTPS. (Closes: #773332)
 + Add comment about checking ssl_ciphers. (Closes: #765782)
@@ -17,6 +17,14 @@ nginx (1.6.2-6) UNRELEASED; urgency=medium
   * debian/ngx-conf/*
 + Added configuration utility. (Closes: #652108)
 
+  [ Christian Pointner ]
+  * added new variant stream as a copy of light with additonal modules
++ RTMP
++ FLV
++ MP4
++ Embedded Lua
+  * added RTMP module to extras as well.
+
  -- Michael Lustfield   Sun, 11 Jan 2015 14:49:36 -0600
 
 nginx (1.6.2-5) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 58f951d..29f5c75 100644
--- a/debian/control
+++ b/debian/control
@@ -34,10 +34,12 @@ Package: nginx
 Architecture: all
 Depends: nginx-full   (>= ${source:Version}) |
  nginx-light  (>= ${source:Version}) |
- nginx-extras (>= ${source:Version}) ,
+ nginx-extras (>= ${source:Version}) |
+ nginx-stream (>= ${source:Version}) ,
  nginx-full   (<< ${source:Version}.1~) |
  nginx-light  (<< ${source:Version}.1~) |
- nginx-extras (<< ${source:Version}.1~) ,
+ nginx-extras (<< ${source:Version}.1~) |
+ nginx-stream (<< ${source:Version}.1~) ,
  ${misc:Depends}
 Description: small, powerful, scalable web/proxy server
  Nginx ("engine X") is a high-performance web and reverse proxy server
@@ -64,11 +66,13 @@ Depends: lsb-base (>= 3.2-14), ${misc:Depends}, python
 Replaces: nginx (<< 0.8.54-4),
   nginx-extras (<< 0.8.54-4),
   nginx-full (<< 0.8.54-4),
-  nginx-light (<< 0.8.54-4)
+  nginx-light (<< 0.8.54-4),
+  nginx-stream (<< 0.8.54-4)
 Breaks: nginx (<< 0.8.54-4),
 nginx-extras (<< 0.8.54-4),
 nginx-full (<< 0.8.54-4),
-nginx-light (<< 0.8.54-4)
+nginx-light (<< 0.8.54-4),
+nginx-stream (<< 0.8.54-4)
 Suggests: fcgiwrap, nginx-doc, ssl-cert
 Description: small, powerful, scalable web/proxy server - common files
  Nginx ("engine X") is a high-performance web and 

Bug#775456: ITP: sankore -- interactive whiteboard interface

[David Prévot]

Hi,

> 2015-01-15 21:41 GMT+01:00 David Prévot :
> > Package: wnpp
[…]
> > * Package name: sankore

On Fri, Jan 16, 2015 at 12:04:49AM +0100, Miriam Ruiz wrote:
> Maybe you might want to have a look at https://bugs.debian.org/673322

Thanks Miriam, I indeed missed it since it had been renamed a year ago.
You still own that ITP, are you still working on or interested in this
package (based on any upstream fork of Open-Sankoré)?


On Thu, Jan 15, 2015 at 11:22:16PM +, Mike Gabriel wrote:
> I have some packaging work in Git somewhere [2].
[…]
> [2] http://code.it-zukunft-schule.de/gitweb?p=sankore.git;a=summary

Great, is it possible to check it out without any SSH access (or can you
upload it somewhere accessible if it isn’t)?


On Tue, Jan 20, 2015 at 10:45:21AM +0100, Andrea Colangelo wrote:
> On Fri, Jan 16, 2015 at 12:22 AM, Mike Gabriel wrote:
> > Then there was this openboard fork which became very promising...
> > and vanished soon again
[…]
> It looked a really promising project, then […] the work stopped.

I guess I should “bts forcemerge 775456 673322” since openboard is again
out of the picture, but I don’t want to steal ownership of the bug
report without Miriam permission first.


On Fri, Jan 16, 2015 at 12:11:08PM +0100, Georges Khaznadar wrote:
> I am enthusiastic about your ITP. If I can help, please tell me!

Thanks, do not hesitate to apply into Debian Edu team membership on
Alioth, where I initially intend to share the packaging work (I’m of
course open to other ideas), if you’re not already there. I’d like to
recycle as much work as possible from the initial intent by Miriam and
Mike, and rebase it on the latest upstream version, then we may share
the various packaging bits (license checking, code patching for
DFSG-compliance, make it actually buildable and usable, test it, etc.)

Regards

David


signature.asc
Description: Digital signature

Bug#776904: please mark chromium as unsupported in wheezy

[Stephen Dowdy]

(Holger: thanks for submitting bug, i was about to, but realized
'debian-security-support' is not in wheezy base, but in backports)

Make that "in wheezy-backports", and "jessie, too".

# lsb_release -cs
wheezy

# apt-cache policy debian-security-support
debian-security-support:
  Installed: 2014.09.07~bpo70+1
  Candidate: 2014.09.07~bpo70+1
  Version table:
 *** 2014.09.07~bpo70+1 0
100 http://MY-REPO-MIRROR/ wheezy-backports/main amd64 Packages
100 /var/lib/dpkg/status

# grep -i chromium /usr/share/debian-security-support/*
#

However, this applies as well to Jessie:

# grep -i chromium /usr/share/debian-security-support/*
# lsb_release -cs
jessie
# apt-cache policy debian-security-support
debian-security-support:
  Installed: 2014.12.17
  Candidate: 2014.12.17
  Version table:
 *** 2014.12.17 0
500 http://MY-REPO-MIRROR/ jessie/main amd64 Packages
100 /var/lib/dpkg/status
# grep -i chromium /usr/share/debian-security-support/*
#


thanks,
--stephen
-- 
Stephen Dowdy  -  Systems Administrator  -  NCAR/RAL
303.497.2869   -  sdo...@ucar.edu-  http://www.ral.ucar.edu/~sdowdy/


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

Bug#730216: please consider allowing pypy to build on machines with less ram.

[Stefano Rivera]

Hi John (2015.02.09_00:36:31_+0200)
> Please let the decision whether a certain package should be built on
> a certain architecture up to the porters.

OK, you make persuasive arguments. I'll remove it.

At the time this check was implemented, many of Debian's architectures
had a wide range of RAM in buildds. There are far fewer "small" buildds
in the supported architectures these days. I think by now, most
architecture that do have some small buildds have blacklisted pypy on
them, so I am not too worried about blocking up the build queue.

> They (we) are in a much better decision to decide that and if we
> actually don't want a package to be built at all on a certain
> architecture, we just set it to "Not-For-Us" in the wanna-build
> database on the buildd master. There is no need for a package
> maintainer to influence that.

I was more concerned about wasting time architectures with varying RAM
in buildds than archs that only have small buildds, where it'd be
unlikely to build anyway. But I can see why this would be an issue on
those archs.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272


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

Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not

[Andrey Rahmatullin]

On Mon, Feb 09, 2015 at 07:14:07PM +0100, Bill Allombert wrote:
> On Fri, Nov 21, 2014 at 12:23:17AM +0500, Andrey Rahmatullin wrote:
> > Control: tags -1 + patch
> > 
> > On Sat, Aug 04, 2012 at 11:19:15AM +0900, Charles Plessy wrote:
> > > How about the attached patch, that adds "Its value must not be empty."
> > > after "The field ends at the end of the line or at the end of the last
> > > continuation line".
> > Seconded.
> 
> Hello Andrey and Ansgar (and others)
> 
> Would you second the attached version that was posted in this bug already ?

> commit ec38643c34333231a2e179ba1e135fd2ebccbf7a
> Author: Bill Allombert 
> Date:   Sun Nov 23 16:16:21 2014 +0100
> 
> Document that empty field values are only allowed in debian/control.
> 
> Policy: [5.1] empty field values in control files are not allowed in the
> debian/control file of a source package.
> Wording:  Bill Allombert 
> Seconded: Henrique de Moraes Holschuh 
> Closes: #666726
> 
> diff --git a/policy.sgml b/policy.sgml
> index 947a1e1..4adee0b 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -2558,7 +2558,9 @@ Package: libc6
> the field name is Package and the field value
> libc6.
>   
> -
> + Empty field values are only permitted in source package control 
> files
> +   (debian/control). Such fields are ignored.
> +
>   
> A paragraph must not contain more than one instance of a
> particular field name.
> @@ -2701,6 +2703,7 @@ Package: libc6
> file. These tools are responsible for removing the line
> breaks from such fields when using fields from
> debian/control to generate other control files.
> +   They are also responsible for discarding empty fields.
>   
>  
>   
Seconded.


-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#777553: pu: package libfcgi/2.4.0-8

[Joe Damato]

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

Hi:

There is a stack smashing/corruption bug in libfcgi/2.4.0-8. The bug was fixed 
in: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681591, however this package 
is currently
in unstable as other changes were added as well. This bug is a security issue 
as you can DoS
a server process quite easily.

A CVE has been assigned (CVE-2012-6687): 
http://www.openwall.com/lists/oss-security/2015/02/07/4.

Ubuntu accepted my patched version of their  package into 12.04 
precise-security: 
https://bugs.launchpad.net/ubuntu/precise/+source/libfcgi/+bug/1418778

Instructions for setting up a PoC: 
https://gist.github.com/ice799/abc2522397b1605a5d7f.

I sent my changes to the security team who told me this should be fixed with an 
's-p-u' so I 
am trying to follow directions found online on how to do this.

I've attached a debdiff I generated against the version in stable.

Let me know how else I can help.

Thanks,
Joe

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

Kernel: Linux 3.2.0-4-amd64 (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


libfcgi_2.4.0-8.1_2.4.0-8.2.diff.gz
Description: GNU Zip compressed data