Bug#982809: ITP: dodge-the-creeps -- Dodge the Creeps! tutorial game for the Godot engine

[beuc]

Package: wnpp
Owner: pkg-games-de...@lists.alioth.debian.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: dodge-the-creeps
  Version : 3.2
  Upstream Author : http://kidscancode.org/contact.html
* URL : 
http://docs.godotengine.org/en/latest/getting_started/step_by_step/your_first_game.html
* License : MIT
  Programming Lang: GDScript
  Description : Dodge the Creeps! tutorial game for the Godot engine

This game is a companion to the Godot Engine Getting Started Guide.
It is a game intended to demonstrate the following fundamental
concepts of Godot development:
 * Node and scene structure
 * Instancing scenes
 * Input
 * Signals
 * UI
This package serves as a sample Debian packaging for Godot games.

Package development happens at:
https://salsa.debian.org/games-team/dodge-the-creeps

Bug#938937: O: freedink-dfarc -- frontend and .dmod installer for GNU FreeDink

[beuc]

Package: wnpp
Severity: normal

I orphaned the freedink-dfarc package.
See https://lists.debian.org/debian-devel-games/2019/08/msg00014.html

The package description is:
 Dink Smallwood is an adventure/role-playing game, similar to Zelda,
 made by RTsoft. Besides twisted humor, it includes the actual game
 editor, allowing players to create hundreds of new adventures called
 Dink Modules or D-Mods for short.
 .
 DFArc2 makes it easy to play and manage the Dink Smallwood game and
 its numerous D-Mods.
 Dink Smallwood is an adventure/role-playing game, similar to Zelda,
 made by RTsoft. Besides twisted humor, it includes the actual game
 editor, allowing players to create hundreds of new adventures called
 Dink Modules or D-Mods for short.
 .
 DFArc2 makes it easy to play and manage the Dink Smallwood game and
 its numerous D-Mods.

Bug#938934: O: freedink -- humorous top-down adventure and role-playing game

[beuc]

Package: wnpp
Severity: normal

I orphaned the freedink package.
See https://lists.debian.org/debian-devel-games/2019/08/msg00014.html

The package description is:
 Dink Smallwood is an adventure/role-playing game, similar to classic
 Zelda, made by RTsoft. Besides twisted humor, it includes the actual
 game editor, allowing players to create hundreds of new adventures
 called Dink Modules or D-Mods for short.
 .
 GNU FreeDink is a new and portable version of the game engine, which
 runs the original game as well as its D-Mods, with close
 compatibility, under multiple platforms.
 .
 This package is a metapackage to install the game, its data and a
 front-end to manage game options and D-Mods.

Bug#938935: O: freedink-data -- adventure and role-playing game (assets)

[beuc]

Package: wnpp
Severity: normal

I orphaned the freedink-data package.
See https://lists.debian.org/debian-devel-games/2019/08/msg00014.html

The package description is:
 Dink Smallwood is an adventure/role-playing game, similar to Zelda,
 made by RTsoft. Besides twisted humour, it includes the actual game
 editor, allowing players to create hundreds of new adventures called
 Dink Modules or D-Mods for short.
 .
 This package contains the original game story, along with free sound
 and music replacements.

Bug#919724: cxxtest: git snapshot breaks compatibility with official release

[beuc]

Package: cxxtest
Version: 4.4+git171022-1

Hi,

I could not find information about this behavior change.

cxxtest has historically a limitation with
TS_ASSERT_EQUALS/TS_ASSERT_DIFFERS, which validates the following test:

    char str[] = "toto";
    char* str2 = strdup(str);
    TS_ASSERT_EQUALS(str, str2);
    TS_ASSERT_DIFFERS(str, str2);

With the new Git snapshot, this test now does not pass.
Whether this is a sensible result or not, this breaks existing
testsuites, AFAICS without notice from the package or the maintainer
(the ChangeLog is still from 4.4), nor a way to determine the cxxtest
variant (release/snapshot) installed by the end user.

Could you document the reason why Debian ships a Git snapshot rather
than an official release?

In addition, do you think it is better to revert the Debian version,
document this behavior change, or check with upstream how to implement
an upgrade plan?

Cheers!
Sylvain

Bug#911652: inkscape: crashes on shift+click with ellipse or rectangle

[beuc]

Hi!

On 23/10/2018 11:01, Mattia Rizzolo wrote:
> I'll wait for them to approve your patch before incorporating it.
> Be aware that these days you may have some more luck in getting your
> patch reviewed by opening a MR at https://gitlab.com/inkscape/inkscape

Good idea, https://gitlab.com/inkscape/inkscape/merge_requests/377

>> (I contributed to the Ubuntu bug as it's referenced at upstream's
>> http://wiki.inkscape.org/wiki/index.php/1.0_Release_Bug_Fix_List)
> But it's not an Ubuntu bug ;)
Aha, having to log with a "Ubuntu One" account confused me :)

- Sylvain

Bug#911652: inkscape: crashes on shift+click with ellipse or rectangle

[beuc]

Package: inkscape
Version: 0.92.3-5+b1
Severity: normal

Dear Maintainer,

The current Debian package is affected by the annoying bug described at:
https://bugs.launchpad.net/inkscape/+bug/1522085

I attached a patch to that bug report.
(I contributed to the Ubuntu bug as it's referenced at upstream's
http://wiki.inkscape.org/wiki/index.php/1.0_Release_Bug_Fix_List)

Cheers!
Sylvain

Bug#900920: stretch-pu: package freedink-dfarc/3.12-1+deb9u1

[beuc]

On 09/06/2018 22:29, Adam D. Barratt wrote:
> On Fri, 2018-06-08 at 20:12 +0200, Sylvain wrote:
>> On 08/06/2018 19:55, Adam D. Barratt wrote:
>>> Control: tags -1 + confirmed
>>>
>>> On Wed, 2018-06-06 at 19:54 +0200, b...@debian.org wrote:
 Please consider this update to freedink-dfarc for stretch.
 It fixes a security issue that can overwrite arbitrary user
 files.
 Sending to stable following security team's directions from 2018-
 06-
 01.
>>> +freedink-dfarc (3.12-1+deb9u1) stable; urgency=high
>>>
>>> Please use "stretch" as the distribution.
>>>
>>> +  * Fix directory traversal in D-Mod extractor (CVE-2018-0496)
>>> +  * Upload to 'stable' as security team rejected a DSA to
>>> +'stretch-security' (no justification)
>>>
>>> The changelog is not the place for such commentary - please remove
>>> it.
>>>
>>> With the above changes made, and assuming that the resulting
>>> package
>>> has been tested on stretch, please feel free to upload.
>> As per Social Contract #3 I do have to explain to my users why they
>> get the security fix after the disclosure.
> As with basically all core teams, Debian's security team is generally
> stretched in terms of manpower and can't handle every possible update
> that's security-related. Things have to be prioritised and sometimes
> those updates end up being provided via proposed-updates. That's always
> going to be the case in a volunteer project, and even larger and/or
> commercially-backed projects will still have to decide which updates
> they handle before others. This isn't a problem as such, just the way
> things are.

Workload: that's not what they say. When asked on IRC, they said the
team was "fine".

Priorities: I do accept them. However I can report that they are neither
documented nor explained:
- "In the past, uploads to |stable| were used to address security
problems as well. However, this practice is deprecated"
 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-stable
- "I don't think this warrants a DSA."
  is the sole explanation I could get.
Plus, as I'm learning this 2-tier security support after years in
Debian, I deemed this all-the-more relevant to the changelog.

Incidentally, are you part of the Security Team?
If yes, I'd appreciate that you say so.
If not, that you don't speak for them.


>> This is not a commentary, this is purely factual.
> It's not a description of a change made to the package, nor information
> that users need in order to decide whether they should be installing
> it. As such, it is commentary. That has nothing to do with its  
> factuality or otherwise.

It's a description of where the package is uploaded and why.
Moreover I fail to see how adding this information is causing any harm,
and in what way it's good to waste both our time complaining about it
rather than just accepting the upload as-is.

Since each question here needs a day or two to be answered, and since
I'm not going to stall the update any more, I'll apply what will only
look like helping hiding problems, as well as the AFAICS undocumented
(https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable)
stable->stretch change.

Working on Debian is so depressing these days.

- Sylvain

Bug#900920: stretch-pu: package freedink-dfarc/3.12-1+deb9u1

[beuc]

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

Hi,

Please consider this update to freedink-dfarc for stretch.
It fixes a security issue that can overwrite arbitrary user files.
Sending to stable following security team's directions from 2018-06-01.

Attached is the debdiff.
Let me know if I can push the upload to stable.

Cheers!
Sylvain

diff -Nru freedink-dfarc-3.12/debian/changelog 
freedink-dfarc-3.12/debian/changelog
--- freedink-dfarc-3.12/debian/changelog2014-10-16 23:04:34.0 
+0200
+++ freedink-dfarc-3.12/debian/changelog2018-06-05 21:41:38.0 
+0200
@@ -1,3 +1,11 @@
+freedink-dfarc (3.12-1+deb9u1) stable; urgency=high
+
+  * Fix directory traversal in D-Mod extractor (CVE-2018-0496)
+  * Upload to 'stable' as security team rejected a DSA to
+'stretch-security' (no justification)
+
+ -- Sylvain Beucler   Tue, 05 Jun 2018 21:41:38 +0200
+
 freedink-dfarc (3.12-1) unstable; urgency=medium
 
   * New Upstream Release
diff -Nru freedink-dfarc-3.12/debian/patches/CVE-2018-0496.patch 
freedink-dfarc-3.12/debian/patches/CVE-2018-0496.patch
--- freedink-dfarc-3.12/debian/patches/CVE-2018-0496.patch  1970-01-01 
01:00:00.0 +0100
+++ freedink-dfarc-3.12/debian/patches/CVE-2018-0496.patch  2018-06-05 
21:41:38.0 +0200
@@ -0,0 +1,232 @@
+Description: Fix directory traversal in D-Mod extrator (CVE-2018-0496)
+Author: Sylvain Beucler
+Origin: upstream
+Last-Update: 2018-06-05
+
+commit 40cc957f52e772f45125126439ba9333cf2d2998
+Author: Sylvain Beucler 
+Date:   Tue Jun 5 23:07:56 2018 +0200
+
+Fix directory traversal in D-Mod extractor (CVE-2018-0496)
+
+diff --git a/src/InstallVerifyFrame.cpp b/src/InstallVerifyFrame.cpp
+index 64964e1..494ba53 100644
+--- a/src/InstallVerifyFrame.cpp
 b/src/InstallVerifyFrame.cpp
+@@ -3,7 +3,7 @@
+ 
+  * Copyright (C) 2004  Andrew Reading
+  * Copyright (C) 2005, 2006  Dan Walma
+- * Copyright (C) 2008  Sylvain Beucler
++ * Copyright (C) 2008, 2018  Sylvain Beucler
+ 
+  * This file is part of GNU FreeDink
+ 
+@@ -55,7 +55,10 @@ InstallVerifyFrame::InstallVerifyFrame(const wxString& 
lDmodFilePath)
+ {
+   // Prepare the tar file for reading
+   Tar lTar(mTarFilePath);
+-  lTar.ReadHeaders();
++  if (lTar.ReadHeaders() == 1) {
++this->EndModal(wxID_CANCEL);
++return;
++  }
+  
+   // Get and display the dmod description
+   wxString lDmodDescription = lTar.getmDmodDescription();
+@@ -122,7 +125,20 @@ void InstallVerifyFrame::onInstall(wxCommandEvent )
+ destdir = mConfig->mDModDir;
+ 
+   Tar lTar(mTarFilePath);
+-  lTar.ReadHeaders();
++  if (lTar.ReadHeaders() == 1) {
++this->EndModal(wxID_CANCEL);
++return;
++  }
++
++  if (wxDirExists(destdir + wxFileName::GetPathSeparator() + 
lTar.getInstalledDmodDirectory())) {
++wxString question;
++question.Printf(_("Directory '%s' already exists. Continue?"), 
lTar.getInstalledDmodDirectory());
++int lResult = wxMessageBox(question, _("DFArc - Installing"),
++ wxYES_NO | wxICON_WARNING, this);
++if (lResult == wxNO)
++  return;
++  }
++
+   int lError = lTar.Extract(destdir, );
+   if (lError == 0)
+ {
+diff --git a/src/Tar.cpp b/src/Tar.cpp
+index b919ae7..8147b8a 100644
+--- a/src/Tar.cpp
 b/src/Tar.cpp
+@@ -3,7 +3,7 @@
+ 
+  * Copyright (C) 2004  Andrew Reading
+  * Copyright (C) 2005, 2006  Dan Walma
+- * Copyright (C) 2008, 2014  Sylvain Beucler
++ * Copyright (C) 2008, 2014, 2018  Sylvain Beucler
+ 
+  * This file is part of GNU FreeDink
+ 
+@@ -31,6 +31,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include 
+ #include 
+@@ -427,7 +428,15 @@ int Tar::ReadHeaders( void )
+   wxString lPath(lRecord.Name, wxConvUTF8);
+   if (mInstalledDmodDirectory.Length() == 0)
+ {
+-mInstalledDmodDirectory = lPath.SubString( 0, lPath.Find( '/' ) );
++// Security: ensure the D-Mod directory is non-empty
++wxString firstDir = GetFirstDir(lPath);
++if (firstDir.IsSameAs("", true) || firstDir.IsSameAs("..", true) || 
firstDir.IsSameAs("dink", true))
++{
++wxLogError(_("Error: invalid D-Mod directory.  Stopping."));
++  return 1;
++}
++  mInstalledDmodDirectory = firstDir;
++
+ lDmodDizPath = mInstalledDmodDirectory + _T("dmod.diz");
+ lDmodDizPath.LowerCase();
+ }
+@@ -472,10 +481,6 @@ int Tar::Extract(wxString destdir, wxProgressDialog* 
aProgressDialog)
+ wxString strBuf;
+ int lError = 0;
+ 
+-// Remember current directory
+-wxString strCwd = ::wxGetCwd();
+-
+-
+ // Open the file here so it doesn't error after changing.
+ wxFile wx_In(mFilePath, wxFile::read);
+ 
+@@ -495,8 +500,6 @@ int Tar::Extract(wxString destdir, wxProgressDialog* 
aProgressDialog)
+   wxLogFatalError(_("Error: Cannot create directory '%s'.  Cannot 

Bug#893157: planet-venus: django.template.exceptions.TemplateDoesNotExist

[beuc]

Package: planet-venus
Version: 0~git9de2109-4
Tags: patch

Hi,

When processing a .dj template with planet-venus under Debian 9.4/Stretch, I 
got:
 DEBUG:planet.runner:Processing template 
/var/www/planet.gnu.org/git/debian/templates/index.html.dj using dj
Traceback (most recent call last):
  File "./code/venus/planet.py", line 158, in 
splice.apply(doc.toxml('utf-8'))
  File "/usr/lib/python2.7/dist-packages/planet/splice.py", line 142, in apply
output_file = shell.run(template_file, doc)
  File "/usr/lib/python2.7/dist-packages/planet/shell/__init__.py", line 66, in 
run
module.run(template_resolved, doc, output_file, options)
  File "/usr/lib/python2.7/dist-packages/planet/shell/dj.py", line 41, in run
t = get_template(script)
  File "/usr/lib/python2.7/dist-packages/django/template/loader.py", line 25, 
in get_template
raise TemplateDoesNotExist(template_name, chain=chain)
django.template.exceptions.TemplateDoesNotExist: 
/var/www/planet.gnu.org/git/debian/templates/index.html.dj

AFAICS this is related to:
https://docs.djangoproject.com/fr/1.10/ref/templates/upgrading/

The attached patch applies that documentation and fixes the issue:
--- dj.py~  2018-03-16 20:34:34.019196399 +
+++ dj.py   2018-03-16 22:37:35.015027892 +
@@ -23,7 +23,24 @@
 try:
 settings.configure(
 DEBUG=True, TEMPLATE_DEBUG=True, 
-TEMPLATE_DIRS=(os.path.dirname(script),)
+TEMPLATES = [
+{
+'BACKEND': 
'django.template.backends.django.DjangoTemplates',
+'DIRS': (os.path.dirname(script),),
+'APP_DIRS': True,
+'OPTIONS': {
+'context_processors': [
+'django.contrib.auth.context_processors.auth',
+'django.template.context_processors.debug',
+'django.template.context_processors.i18n',
+'django.template.context_processors.media',
+'django.template.context_processors.static',
+'django.template.context_processors.tz',
+
'django.contrib.messages.context_processors.messages',
+],
+},
+},
+]
 )
 except RuntimeError:
 pass


Works for me.

Cheers!
Sylvain

--- dj.py~	2018-03-16 20:34:34.019196399 +
+++ dj.py	2018-03-16 22:37:35.015027892 +
@@ -23,7 +23,24 @@
 try:
 settings.configure(
 DEBUG=True, TEMPLATE_DEBUG=True, 
-TEMPLATE_DIRS=(os.path.dirname(script),)
+TEMPLATES = [
+{
+'BACKEND': 'django.template.backends.django.DjangoTemplates',
+'DIRS': (os.path.dirname(script),),
+'APP_DIRS': True,
+'OPTIONS': {
+'context_processors': [
+'django.contrib.auth.context_processors.auth',
+'django.template.context_processors.debug',
+'django.template.context_processors.i18n',
+'django.template.context_processors.media',
+'django.template.context_processors.static',
+'django.template.context_processors.tz',
+'django.contrib.messages.context_processors.messages',
+],
+},
+},
+]
 )
 except RuntimeError:
 pass

Bug#860754: gzip: zcmp considers '-' empty if passed as a second argument

[beuc]

Package: gzip
Version: 1.6-5+b1
Severity: normal

Hi,

$ cat a.gz | zcmp - b.gz 
/dev/fd/5 - differ: char 1, line 1
$ cat a.gz | zcmp b.gz -
cmp: EOF on -
$ cat a.gz | zdiff - b.gz 
1c1
< a
---
> b
$ cat a.gz | zdiff b.gz -
1d0
< b

For reference 'zcmp' from zutils does not have this issue.

Cheers!
Sylvain


*** 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: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-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 gzip depends on:
ii  dpkg   1.18.23
ii  libc6  2.24-9

gzip recommends no packages.

Versions of packages gzip suggests:
ii  less  481-2.1

-- no debconf information

Bug#860428: reprotest: use an existing HOME in the control build

[beuc]

Hi,

On Sun, Apr 16, 2017 at 07:11:08PM +0200, Mattia Rizzolo wrote:
> On Sun, Apr 16, 2017 at 06:55:34PM +0200, b...@debian.org wrote:
> > After several tests (and then more) I eventually tracked it to HOME
> > being invariably non-existant in reprotest
> > (HOME=/nonexistent/first-build and HOME=/nonexistent/second-build),
> > while my normal compilation environment has an existing home (duh!).
> 
> Consider that both sbuild and pbuilder have HOME pointing to something
> non-existent.

I'm using reprotest outside of Debian packaging.  See e.g.:
http://blog.beuc.net/posts/Practical_basics_of_reproducible_builds_2/


> > - non-existing home: ./configure attempts to run conftest.exe, wine
> >   can't create '.wine', conftest.exe fails, configure assumes:
> >   checking whether we are cross compiling... yes
> 
> This feels quite buggy behaviour.  I suggest you consider this another
> bug in your package.

Yeah I wrote that this is fixed by specifying both --build and --host
to ./configure.  Btw this is one of the first ./configure tests from
autoconf, so nothing specific to my application.


> > To detect this issue, and probably others, I'd suggest making the
> > control build's HOME point to an existing directory.
> 
> By all means, I suggest instead having one build with an existent and
> writable HOME, and one with a non-existent one (this leaves out the case
> of an existent but not writable, though).

I believe we have the same thing in mind - I suggested an existing
(and indeed writable) directory only for the control build, not the
experiment build.

Cheers!
Sylvain

Bug#860428: reprotest: use an existing HOME in the control build

[beuc]

Package: reprotest
Version: 0.6
Severity: normal

Hi,

I was investigating why reprotest would report a reproducible build,
but still produce a different executable than when compiling directly.

After several tests (and then more) I eventually tracked it to HOME
being invariably non-existant in reprotest
(HOME=/nonexistent/first-build and HOME=/nonexistent/second-build),
while my normal compilation environment has an existing home (duh!).

This caused a subtle bug when cross-compiling with mingw and
wine-binfmt:

- existing home: ./configure attempts to run conftest.exe, wine can
  create '.wine', conftest.exe runs OK, configure assumes:
  checking whether we are cross compiling... no

- non-existing home: ./configure attempts to run conftest.exe, wine
  can't create '.wine', conftest.exe fails, configure assumes:
  checking whether we are cross compiling... yes

The respective binaries were very different notably due to a different
config.h.

(and now I understand why one should specify both --host *and* --build
when cross-compiling from autoconf ahah..)


To detect this issue, and probably others, I'd suggest making the
control build's HOME point to an existing directory.


Cheers!
Sylvain

Bug#860131: unblock: freedink/108.4+dfsg-3

[beuc]

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

Please unblock package freedink


It fixes the 'symlink_to_dir' from the previous upload, which was
incomplete (i.e. not done in all cases for the -dbg package).


diff -Nru freedink-108.4+dfsg/debian/changelog 
freedink-108.4+dfsg/debian/changelog
--- freedink-108.4+dfsg/debian/changelog   2017-04-09 23:10:58.0 
+0200
+++ freedink-108.4+dfsg/debian/changelog   2017-04-11 19:35:07.0 
+0200
@@ -1,3 +1,10 @@
+freedink (108.4+dfsg-3) unstable; urgency=medium
+
+  * Properly implement /usr/share/doc/freedink symlink_to_dir - thanks anbe
+  (Closes: #860114)
+
+ -- Sylvain Beucler   Tue, 11 Apr 2017 19:35:07 +0200
+
 freedink (108.4+dfsg-2) unstable; urgency=medium
 
   * Don't symlink /usr/share/doc/freedink to support binNMU
diff -Nru freedink-108.4+dfsg/debian/freedink-engine-dbg.maintscript 
freedink-108.4+dfsg/debian/freedink-engine-dbg.maintscript
--- freedink-108.4+dfsg/debian/freedink-engine-dbg.maintscript   1970-01-01 
01:00:00.0 +0100
+++ freedink-108.4+dfsg/debian/freedink-engine-dbg.maintscript   2017-04-11 
19:33:49.0 +0200
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/freedink-engine-dbg freedink-engine 
108.4+dfsg-3~~
diff -Nru freedink-108.4+dfsg/debian/freedink.maintscript 
freedink-108.4+dfsg/debian/freedink.maintscript
--- freedink-108.4+dfsg/debian/freedink.maintscript   2017-04-09 
23:10:58.0 +0200
+++ freedink-108.4+dfsg/debian/freedink.maintscript   2017-04-11 
19:35:07.0 +0200
@@ -1,2 +1 @@
-symlink_to_dir /usr/share/doc/freedink freedink-engine 108.4+dfsg-2~~
-symlink_to_dir /usr/share/doc/freedink-engine-dbg freedink-engine 
108.4+dfsg-2~~
+symlink_to_dir /usr/share/doc/freedink freedink-engine 108.4+dfsg-3~~


unblock freedink/108.4+dfsg-3


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

Kernel: Linux 4.9.0-2-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

Bug#860129: unblock: cytadela/1.1.0-4

[beuc]

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

Please unblock package cytadela


It fixes binary-indep-only builds that the previous upload broke.
Also it better implements the symlink_to_dir migration.


diff -Nru cytadela-1.1.0/debian/changelog cytadela-1.1.0/debian/changelog
--- cytadela-1.1.0/debian/changelog   2017-04-09 18:01:11.0 +0200
+++ cytadela-1.1.0/debian/changelog   2017-04-11 19:37:18.0 +0200
@@ -1,3 +1,10 @@
+cytadela (1.1.0-4) unstable; urgency=medium
+
+  * Fix binary-indep build (Closes: #860113)
+  * Fix symlink_to_dir migration
+
+ -- Sylvain Beucler   Tue, 11 Apr 2017 19:37:18 +0200
+
 cytadela (1.1.0-3) unstable; urgency=medium
 
   * Drop --link-doc from dh_installdocs as it breaks binNMU (Closes: #859349)
diff -Nru cytadela-1.1.0/debian/cytadela-dbg.maintscript 
cytadela-1.1.0/debian/cytadela-dbg.maintscript
--- cytadela-1.1.0/debian/cytadela-dbg.maintscript   1970-01-01 
01:00:00.0 +0100
+++ cytadela-1.1.0/debian/cytadela-dbg.maintscript   2017-04-11 
19:37:18.0 +0200
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/cytadela-dbg cytadela-data 1.1.0-4~~
diff -Nru cytadela-1.1.0/debian/cytadela.maintscript 
cytadela-1.1.0/debian/cytadela.maintscript
--- cytadela-1.1.0/debian/cytadela.maintscript   2017-04-09 
18:01:16.0 +0200
+++ cytadela-1.1.0/debian/cytadela.maintscript   2017-04-11 
19:37:18.0 +0200
@@ -1,2 +1 @@
-symlink_to_dir /usr/share/doc/cytadela cytadela-data 1.1.0-3~~
-symlink_to_dir /usr/share/doc/cytadela-dbg cytadela-data 1.1.0-3~~
+symlink_to_dir /usr/share/doc/cytadela cytadela-data 1.1.0-4~~
diff -Nru cytadela-1.1.0/debian/README.source 
cytadela-1.1.0/debian/README.source
--- cytadela-1.1.0/debian/README.source   2017-04-09 17:59:34.0 
+0200
+++ cytadela-1.1.0/debian/README.source   2017-04-11 19:26:00.0 
+0200
@@ -18,7 +18,9 @@
 git checkout master
 git-import-orig --pristine-tar ../cytadela_$VERSION.orig.tar.gz
 # - Fix stuff...
-# - git-buildpackage --git-ignore-new ...
+#gbp buildpackage --git-builder="pdebuild --buildresult ../" --git-ignore-new
+#gbp buildpackage --git-builder="pdebuild --buildresult ../ -- --binary-arch" 
--git-ignore-new
+#gbp buildpackage --git-builder="pdebuild --buildresult ../ -- --binary-indep" 
--git-ignore-new
 git commit -am "New upstream release - v$VERSION"
 KEYID=...
 gbp buildpackage \
@@ -30,4 +32,4 @@
 # http://mentors.debian.net/cgi-bin/maintainer-intro
 debrelease --dput mentors
 
- -- Sylvain Beucler , Sun,  9 Apr 2017 17:59:24 +0200
+ -- Sylvain Beucler , Tue, 11 Apr 2017 19:19:17 +0200
diff -Nru cytadela-1.1.0/debian/rules cytadela-1.1.0/debian/rules
--- cytadela-1.1.0/debian/rules   2017-04-09 18:01:16.0 +0200
+++ cytadela-1.1.0/debian/rules   2017-04-11 19:37:18.0 +0200
@@ -33,6 +33,9 @@
 
 override_dh_installdocs:
dh_installdocs
-   # lintian extra-license-file
+   # lintian extra-license-file - only if cytadela is built
+   # (i.e. not for binary-indep/cytadela-data builds)
+ifneq ($(filter cytadela, $(shell dh_listpackages)), )
   rm debian/cytadela/usr/share/doc/cytadela/COPYING
   rm debian/cytadela/usr/share/doc/cytadela/GNUFDL
+endif


unblock cytadela/1.1.0-4


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

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

Bug#860114: freedink-engine-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[beuc]

Hi,

I don't understand, I used symlink_to_dir and tested it locally
without issue.

What is wrong?

Cheers!
Sylvain

On Tue, Apr 11, 2017 at 05:17:21PM +0200, Andreas Beckmann wrote:
> Package: freedink-engine-dbg
> Version: 108.4+dfsg-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> an upgrade test with piuparts revealed that your package installs files
> over existing symlinks and possibly overwrites files owned by other
> packages. This usually means an old version of the package shipped a
> symlink but that was later replaced by a real (and non-empty)
> directory. This kind of overwriting another package's files cannot be
> detected by dpkg.
> 
> This was observed on the following upgrade paths:
> 
>   stretch -> sid
> 
> For /usr/share/doc/PACKAGE this may not be problematic as long as both
> packages are installed, ship byte-for-byte identical files and are
> upgraded in lockstep. But once one of the involved packages gets
> removed, the other one will lose its documentation files, too,
> including the copyright file, which is a violation of Policy 12.5:
> https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
> 
> For other overwritten locations anything interesting may happen.
> 
> Note that dpkg intentionally does not replace directories with symlinks
> and vice versa, you need the maintainer scripts to do this.
> See in particular the end of point 4 in
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
> 
> It is recommended to use the dpkg-maintscript-helper commands
> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
> to perform the conversion, ideally using d/$PACKAGE.maintscript.
> Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
> See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.
> 
> 
> >From the attached log (usually somewhere in the middle...):
> 
> 0m35.7s ERROR: FAIL: silently overwrites files via directory symlinks:
>   /usr/share/doc/freedink-engine-dbg/changelog.Debian.gz 
> (freedink-engine-dbg) != /usr/share/doc/freedink-engine/changelog.Debian.gz 
> (freedink-engine)
> /usr/share/doc/freedink-engine-dbg -> freedink-engine
>   /usr/share/doc/freedink-engine-dbg/changelog.gz (freedink-engine-dbg) != 
> /usr/share/doc/freedink-engine/changelog.gz (freedink-engine)
> /usr/share/doc/freedink-engine-dbg -> freedink-engine
>   /usr/share/doc/freedink-engine-dbg/copyright (freedink-engine-dbg) != 
> /usr/share/doc/freedink-engine/copyright (freedink-engine)
> /usr/share/doc/freedink-engine-dbg -> freedink-engine
> 
> 
> cheers,
> 
> Andreas

Bug#859983: unblock: freedink/108.4+dfsg-2

[beuc]

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

Please unblock package freedink

The upload applies a fix from upstream for a segfault due to an
off-by-one overflow.  The latest rebuild makes the game segfault on
savegame reload, making the game mostly unusable.

Also the upload fixes binNMU support which is currently harmed by a
/usr/share/doc symlink from the "all" meta-package to the "arch" main
package.

diff -Nru freedink-108.4+dfsg/debian/changelog 
freedink-108.4+dfsg/debian/changelog
--- freedink-108.4+dfsg/debian/changelog   2017-01-22 21:06:51.0 
+0100
+++ freedink-108.4+dfsg/debian/changelog   2017-04-09 23:10:58.0 
+0200
@@ -1,3 +1,10 @@
+freedink (108.4+dfsg-2) unstable; urgency=medium
+
+  * Don't symlink /usr/share/doc/freedink to support binNMU
+  * Fix segfault when loading game and exiting editor.
+  
+ -- Sylvain Beucler   Sun, 09 Apr 2017 23:10:58 +0200
+
 freedink (108.4+dfsg-1) unstable; urgency=medium
 
   * Stub out share/freedink/LiberationSans-Regular.ttf (Closes: #851110)
diff -Nru freedink-108.4+dfsg/debian/freedink.maintscript 
freedink-108.4+dfsg/debian/freedink.maintscript
--- freedink-108.4+dfsg/debian/freedink.maintscript   1970-01-01 
01:00:00.0 +0100
+++ freedink-108.4+dfsg/debian/freedink.maintscript   2017-04-09 
23:10:58.0 +0200
@@ -0,0 +1,2 @@
+symlink_to_dir /usr/share/doc/freedink freedink-engine 108.4+dfsg-2~~
+symlink_to_dir /usr/share/doc/freedink-engine-dbg freedink-engine 
108.4+dfsg-2~~
diff -Nru freedink-108.4+dfsg/debian/patches/segfault.patch 
freedink-108.4+dfsg/debian/patches/segfault.patch
--- freedink-108.4+dfsg/debian/patches/segfault.patch   1970-01-01 
01:00:00.0 +0100
+++ freedink-108.4+dfsg/debian/patches/segfault.patch   2017-04-09 
23:01:18.0 +0200
@@ -0,0 +1,36 @@
+commit 2516bb7c16066d432bf287567f30d533cd067337
+Author: Sylvain Beucler 
+Date:   Wed Jun 18 23:20:23 2014 +0200
+
+Don't access callback[MAX_CALLBACKS] (overflow)
+
+diff --git a/src/dinkc.c b/src/dinkc.c
+index 74c1e6d..fdf1f19 100644
+--- a/src/dinkc.c
 b/src/dinkc.c
+@@ -64,7 +64,6 @@ struct call_back
+   unsigned long timer;
+ };
+ static struct call_back callback[MAX_CALLBACKS];
+-/* TODO: Used 1->100 in the game, should it be MAX_CALLBACKS+1 ? */
+ 
+ /* DinkC script buffer */
+ static char *rbuf[MAX_SCRIPTS]; //pointers to buffers we may need
+@@ -779,7 +778,7 @@ int add_callback(char name[20], int n1, int n2, int script)
+ 
+ void kill_callback(int cb)
+ {
+-  if (cb >= 0 && cb <= 99)
++  if (cb >= 0 && cb < MAX_CALLBACKS)
+ callback[cb].active = /*false*/0;
+ }
+ 
+@@ -870,7 +869,7 @@ void kill_all_scripts_for_real(void)
+   kill_script(k);
+ }
+   
+-  for (k = 1; k <= MAX_CALLBACKS; k++)
++  for (k = 1; k < MAX_CALLBACKS; k++)
+ {
+   callback[k].active = 0;
+ }
diff -Nru freedink-108.4+dfsg/debian/patches/series 
freedink-108.4+dfsg/debian/patches/series
--- freedink-108.4+dfsg/debian/patches/series   1970-01-01 
01:00:00.0 +0100
+++ freedink-108.4+dfsg/debian/patches/series   2017-04-09 
23:08:56.0 +0200
@@ -0,0 +1 @@
+segfault.patch
diff -Nru freedink-108.4+dfsg/debian/rules freedink-108.4+dfsg/debian/rules
--- freedink-108.4+dfsg/debian/rules   2014-10-17 17:15:09.0 +0200
+++ freedink-108.4+dfsg/debian/rules   2017-04-09 23:10:58.0 +0200
@@ -46,9 +46,5 @@
   # Install XPM icon
   cp -a src/freedink_xpm.c 
debian/freedink-engine/usr/share/pixmaps/freedink.xpm
 
-override_dh_installdocs:
-   # --link-doc requires debhelper 7.4.2
-   dh_installdocs --link-doc=freedink-engine
-
 override_dh_installchangelogs:
dh_installchangelogs ChangeLog

unblock freedink/108.4+dfsg-2

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

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

Bug#859956: unblock: cytadela/1.1.0-3

[beuc]

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

Please unblock package cytadela.

As other game packages such as tworld, the current packaging breaks
binNMU due to /usr/share/doc symlink from the main cytadela "arch"
package to the secondary cytadela-data "all" package.


diff -Nru cytadela-1.1.0/debian/changelog cytadela-1.1.0/debian/changelog
--- cytadela-1.1.0/debian/changelog   2014-06-07 20:30:47.0 +0200
+++ cytadela-1.1.0/debian/changelog   2017-04-09 18:01:11.0 +0200
@@ -1,3 +1,13 @@
+cytadela (1.1.0-3) unstable; urgency=medium
+
+  * Drop --link-doc from dh_installdocs as it breaks binNMU (Closes: #859349)
+  * Install docs into cytadela package instead of cytadela-data
+  * Depends on vlc-plugin-base instead of transitional vlc-nox (Closes: 
#845583)
+  * Fix typo in description
+  * Bump Standards-Version to 3.9.8 (no changes)
+
+ -- Sylvain Beucler   Sun, 09 Apr 2017 18:01:16 +0200
+
 cytadela (1.1.0-2) unstable; urgency=medium
 
   * Re-upload to experimental (closes: #639765)
diff -Nru cytadela-1.1.0/debian/control cytadela-1.1.0/debian/control
--- cytadela-1.1.0/debian/control   2014-06-07 20:30:47.0 +0200
+++ cytadela-1.1.0/debian/control   2017-04-09 17:38:04.0 +0200
@@ -4,14 +4,14 @@
 Maintainer: Debian Games Team 
 Uploaders: Sylvain Beucler 
 Build-Depends: debhelper (>= 9), libsdl1.2-dev, libsdl-mixer1.2-dev, 
mesa-common-dev, libglu1-mesa-dev, libvlc-dev (>= 2.0)
-Standards-Version: 3.9.5
+Standards-Version: 3.9.8
 Homepage: http://cytadela.sf.net/
 Vcs-Git: git://anonscm.debian.org/pkg-games/cytadela.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-games/cytadela.git
 
 Package: cytadela
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, cytadela-data (= 
${source:Version}), vlc-nox
+Depends: ${shlibs:Depends}, ${misc:Depends}, cytadela-data (= 
${source:Version}), vlc-plugin-base
 Description: old-school first person shooter game
  Cytadela is a single player game in which the player fights against
  computer-controlled (AI) enemies. The goal of the game is to find six
diff -Nru cytadela-1.1.0/debian/cytadela-data.docs 
cytadela-1.1.0/debian/cytadela-data.docs
--- cytadela-1.1.0/debian/cytadela-data.docs   2014-06-07 
20:26:13.0 +0200
+++ cytadela-1.1.0/debian/cytadela-data.docs   1970-01-01 
01:00:00.0 +0100
@@ -1,4 +0,0 @@
-NEWS
-README
-AUTHORS
-data/doc/*
diff -Nru cytadela-1.1.0/debian/cytadela.docs 
cytadela-1.1.0/debian/cytadela.docs
--- cytadela-1.1.0/debian/cytadela.docs   1970-01-01 01:00:00.0 
+0100
+++ cytadela-1.1.0/debian/cytadela.docs   2017-04-09 17:24:46.0 
+0200
@@ -0,0 +1,4 @@
+NEWS
+README
+AUTHORS
+data/doc/*
diff -Nru cytadela-1.1.0/debian/cytadela.maintscript 
cytadela-1.1.0/debian/cytadela.maintscript
--- cytadela-1.1.0/debian/cytadela.maintscript   1970-01-01 
01:00:00.0 +0100
+++ cytadela-1.1.0/debian/cytadela.maintscript   2017-04-09 
18:01:16.0 +0200
@@ -0,0 +1,2 @@
+symlink_to_dir /usr/share/doc/cytadela cytadela-data 1.1.0-3~~
+symlink_to_dir /usr/share/doc/cytadela-dbg cytadela-data 1.1.0-3~~
diff -Nru cytadela-1.1.0/debian/README.source 
cytadela-1.1.0/debian/README.source
--- cytadela-1.1.0/debian/README.source   2014-06-07 20:30:47.0 
+0200
+++ cytadela-1.1.0/debian/README.source   2017-04-09 17:59:34.0 
+0200
@@ -21,11 +21,13 @@
 # - git-buildpackage --git-ignore-new ...
 git commit -am "New upstream release - v$VERSION"
 KEYID=...
-git-buildpackage \
-  --git-builder="pdebuild --buildresult ../  --auto-debsign --debsign-k $KEYID 
" \
+gbp buildpackage \
+  --git-builder="pdebuild --buildresult ../ --auto-debsign --debsign-k $KEYID" 
\
   --git-tag --git-keyid=$KEYID
 git push origin master pristine-tar upstream
 git push --tags
 
 # http://mentors.debian.net/cgi-bin/maintainer-intro
-debrelease mentors
+debrelease --dput mentors
+
+ -- Sylvain Beucler , Sun,  9 Apr 2017 17:59:24 +0200
diff -Nru cytadela-1.1.0/debian/rules cytadela-1.1.0/debian/rules
--- cytadela-1.1.0/debian/rules   2014-06-07 20:30:47.0 +0200
+++ cytadela-1.1.0/debian/rules   2017-04-09 18:01:16.0 +0200
@@ -32,11 +32,7 @@
   dh_install -Xcytadela/doc/
 
 override_dh_installdocs:
-   # Group all documentation in the -data arch-indep package
-   dh_installdocs --link-doc=cytadela-data
-# dh_listpackages uses DH_INTERNAL_OPTIONS that is set to '-a'/'-i'/''
-ifneq (,$(findstring cytadela-data, $(shell dh_listpackages)))
+  dh_installdocs
   # lintian extra-license-file
-  rm debian/cytadela-data/usr/share/doc/cytadela-data/COPYING
-  rm debian/cytadela-data/usr/share/doc/cytadela-data/GNUFDL
-endif
+   rm debian/cytadela/usr/share/doc/cytadela/COPYING
+   rm debian/cytadela/usr/share/doc/cytadela/GNUFDL

unblock 

Bug#767839: debian-policy: Linking documentation of arch:any package to arch:all

[beuc]

Hi,

There are a few new bugs related to this, perhaps because it's common
practice in game packages, that split  and -data,
and move all the doc to -data.

I ended here reading:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857974#15
"That is broken by design: #766711"
though apparently this is more a problem of implementation rather than
a design issue.

I see that DH now generates an error with compat=10, but the
documentation doesn't hint at this issue.

Also AFAICS the current binNMU changelogs created with such a
configuration are lost (the binary package just contain the 
-> -data symlink and no changelog.).
This looks like the main/only issue to me.

Would you provide a status update?
(are changes/clarifications planned?)

Cheers!
Sylvain

Bug#859303: pristine-tar: failed to reproduce build of freedink-data-1.08.20170401.tar.xz

[beuc]

Package: pristine-tar
Version: 1.38
Severity: normal

Hi,

Not sure if it's due to switching to .tar.xz or to my use of 'pixz -7':

# Get the tarball:
user@debian:~$ git clone git://git.sv.gnu.org/freedink/freedink-data.git -b 
v1.08.20170401
user@debian:~$ cd freedink-data/
user@debian:~/freedink-data$ make dist VERSION=1.08.20170401
...
tar -c --sort=name \
  --mtime="@1491004800" \
  --owner=root --group=root --numeric-owner \
  freedink-data-1.08.20170401/ | pixz -7 > freedink-data-1.08.20170401.tar.xz
...
# reproducible source tarball (not very helpful per se... but it may help here) 
:
user@debian:~/freedink-data$ wget 
ftp.gnu.org/gnu/freedink/freedink-data-1.08.20170401.tar.xz.sig
user@debian:~/freedink-data$ gpg --verify freedink-data-1.08.20170401.tar.xz.sig
gpg: assuming signed data in 'freedink-data-1.08.20170401.tar.xz'
gpg: Signature made sam. 01 avril 2017 22:12:26 CEST
gpg:using RSA key 42273C1AE37FC4347CF079128FF1CB6E8D89059F
gpg: Good signature from "Sylvain Beucler " [unknown]
...
# or: wget ftp.gnu.org/gnu/freedink/freedink-data-1.08.20170401.tar.xz  directly

# Call pristine-tar (long):
user@debian:~/freedink-data$ pristine-tar commit 
freedink-data-1.08.20170401.tar.xz v1.08.20170401
pristine-xz failed to reproduce build of freedink-data-1.08.20170401.tar.xz
(Please file a bug report.)
pristine-tar: command failed: pristine-xz --no-verbose --no-debug --no-keep 
gendelta freedink-data-1.08.20170401.tar.xz /tmp/pristine-tar.ncEmWw6MEa/wrapper
pristine-tar: failed to generate delta


Previous .tar.tz tarballs of freedink-data are available in the
'pristine-tar' branch.


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

Kernel: Linux 4.9.0-1-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 pristine-tar depends on:
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.24-9
ii  perl5.24.1-2
ii  tar 1.29b-1.1
ii  xdelta  1.1.3-9.1+b1
ii  xdelta3 3.0.11-dfsg-1+b1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages pristine-tar recommends:
ii  bzip2 1.0.6-8.1
pn  pbzip2
ii  xz-utils  5.2.2-1.2+b1
ii  pixz  1.0.6-2+b1  

pristine-tar suggests no packages.

-- no debconf information

Bug#859103: strip-nondeterminism: does not replace all timestamps in zip archives

[beuc]

Package: strip-nondeterminism
Version: 0.032-1

Hi,

It seems strip-nondeterminism replaces correctly replaces timestamps
in Unix-specific extra fields, however this may only happen in the
central directory and not in the individual members themselves.


reprotest - using a 0x timestamp (2004-09-10) for clarity:

$ reprotest 'mkdir test; touch test/a test/b; zip -r test.zip test; 
strip-nondeterminism -T 1094795585 test.zip; chmod 644 test.zip; cp test.zip 
/tmp; sleep 2' 'test.zip'
STARTING VIRTUAL SERVER ['/usr/lib/python3/dist-packages/reprotest/virt/null']
reprotest [12:29:15]: version @version@
reprotest [12:29:15]: host decision; command line: /usr/bin/reprotest 'mkdir 
test; touch test/a test/b; zip -r test.zip test; strip-nondeterminism -T 
1094795585 test.zip; chmod 644 test.zip; cp test.zip /tmp; sleep 2' test.zip
reprotest [12:29:15]: testbed dpkg architecture: amd64
reprotest [12:29:15]: testbed running kernel: Linux 4.9.0-1-amd64 #1 SMP Debian 
4.9.6-3 (2017-01-28)
will vary: environment
will vary: fileordering
will vary: home
will vary: kernel
will vary: locales
will vary: exec_path
will vary: time
will vary: timezone
will vary: umask
copying /home/me/workdir/test/ over to virtual server's 
/tmp/autopkgtest.L1evFW/control/
copying /home/me/workdir/test/ over to virtual server's 
/tmp/autopkgtest.L1evFW/experiment/
starting build with source directory: /tmp/autopkgtest.L1evFW/control/, 
artifact pattern: test.zip
executing: ( umask 0022 && cd /tmp/autopkgtest.L1evFW/control/ && linux64 
--uname-2.6 sh -ec 'mkdir test; touch test/a test/b; zip -r test.zip test; 
strip-nondeterminism -T 1094795585 test.zip; chmod 644 test.zip; cp test.zip 
/tmp; sleep 2' )
  adding: test/ (stored 0%)
  adding: test/a (stored 0%)
  adding: test/b (stored 0%)
starting build with source directory: /tmp/autopkgtest.L1evFW/experiment/, 
artifact pattern: test.zip
executing: if ( mv /tmp/autopkgtest.L1evFW/experiment/ 
/tmp/autopkgtest.L1evFW/experiment-before-disorderfs/ && mkdir -p 
/tmp/autopkgtest.L1evFW/experiment/ && sh -ec 'disorderfs --shuffle-dirents=yes 
--multi-user="$(if [ $(id -u) = 0 ]; then echo yes; else echo no; fi)" "$@"' - 
/tmp/autopkgtest.L1evFW/experiment-before-disorderfs/ 
/tmp/autopkgtest.L1evFW/experiment/ && umask 0002 && cd 
/tmp/autopkgtest.L1evFW/experiment/ && faketime +373days+7hours+13minutes 
linux32 sh -ec 'mkdir test; touch test/a test/b; zip -r test.zip test; 
strip-nondeterminism -T 1094795585 test.zip; chmod 644 test.zip; cp test.zip 
/tmp; sleep 2' ); then
( __c=0; fusermount -u /tmp/autopkgtest.L1evFW/experiment/ || __c=$?; rmdir 
/tmp/autopkgtest.L1evFW/experiment/ || __c=$?; mv 
/tmp/autopkgtest.L1evFW/experiment-before-disorderfs/ 
/tmp/autopkgtest.L1evFW/experiment/ || __c=$?; exit $__c; );
else
__x=$?;
if ( __c=0; fusermount -u /tmp/autopkgtest.L1evFW/experiment/ || __c=$?; 
rmdir /tmp/autopkgtest.L1evFW/experiment/ || __c=$?; mv 
/tmp/autopkgtest.L1evFW/experiment-before-disorderfs/ 
/tmp/autopkgtest.L1evFW/experiment/ || __c=$?; exit $__c; ); then exit $__x; 
else
echo >&2; "cleanup failed with exit code $?"; exit $__x;
fi;
fi

disorderfs: shuffling dirents
disorderfs: reversing dirents
  adding: test/ (stored 0%)
  adding: test/b (stored 0%)
  adding: test/a (stored 0%)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
  LANGUAGE = "fr_CH.UTF-8:fr",
  LC_ALL = "fr_CH.UTF-8",
  LANG = "fr_CH.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
copying /tmp/autopkgtest.L1evFW/control-dist/ back from virtual server's 
/tmp/tmpnnnyuzyg/control_artifact/
copying /tmp/autopkgtest.L1evFW/experiment-dist/ back from virtual server's 
/tmp/tmpnnnyuzyg/experiment_artifact/
Running diffoscope: ['diffoscope', '/tmp/tmpnnnyuzyg/control_artifact/', 
'/tmp/tmpnnnyuzyg/experiment_artifact/']
--- /tmp/tmpnnnyuzyg/control_artifact/
+++ /tmp/tmpnnnyuzyg/experiment_artifact/
│   --- /tmp/tmpnnnyuzyg/control_artifact/test.zip
├── +++ /tmp/tmpnnnyuzyg/experiment_artifact/test.zip
│┄ No file format specific differences found inside, yet data differs (Zip 
archive data, at least v1.0 to extract)
│ @@ -1,18 +1,18 @@
│  : 504b 0304 0a00   a22e 2a31   PK..*1..
│  0010:      0500 1c00 7465  ..te
│  0020: 7374 2f55 5409 0003 4141 4141 4141 4141  st/UT...
│  0030: 7578 0b00 0104   0400  0050  ux.P
│  0040: 4b03 040a   00a2 2e2a 3100   K..*1...
│  0050:     0006 001c 0074 6573  .tes
│ -0060: 742f 6155 5409 0003 fbdd dc58 fbdd dc58  t/aUT..X...X
│ +0060: 742f 6155 5409 0003 fddd dc58 fddd dc58  t/aUT..X...X
│  0070: 7578 0b00 0104 e803  04e8 0300 0050  ux.P
│  0080: 4b03 040a   00a2 2e2a 3100   K..*1...
│  0090:     0006 001c 

Bug#851111: gargoyle-free: violates font license

[beuc]

Hi,


Globally we agree but I can't help but correct a few things.


On Sun, Feb 12, 2017 at 07:38:47PM +0800, Paul Wise wrote:
> On Fri, 20 Jan 2017 20:20:46 +0100 Sylvain wrote:
> Yes, that is likely the case, except I thought I forwarded the initial
> bug report to the maintainer addresses. Perhaps I forgot to do that for
> gargoyle-free. I am very sorry about that, my MUA is annoying at times.

I received another removal notice for freedink, so not just
gargoyle-free :/

OK, it's weird though that the BTS doesn't notify maintainers when a
bug is reassigned to their package.

> > A mass bug filling, when the freeze is in effect.
> 
> This wasn't a mass bug filing.

What do you call this?

> > This will take additional time for both the maintainer and the Debian
> > Release team.
> 
> As per normal.

It seems to me that outside of the freeze, the Debian Release team is
not involved.  Anyway I need to say the freeze was only in "soft"
phase hence not a problem actually.

> > No patch.
> 
> The needed changes are trivial.

That depends, for another package the presence of the file was
necessary for the build system (as it's normally installed in pkgdir,
then removed in debian/rules).

> > Wait, Debian is distributing the source code of Liberation, on the
> > same servers as the source and binaries packages.
> 
> Yes, in a different source package and directory.

Hence, compliant?

> It is likely to be a different version and if it isn't already then in
> the future when Liberation is updated, it will be a different version.
> 
> In addition, when people mirror by source package, they will be missing
> the source code for the font unless they manually mirror deps too.

Sounds like a corner case a bit outside of the Debian goal but ok.

> > Doesn't this comply with the GPL already?
> 
> Given the version issue above, I doubt it.

Yes.

> > What threats are we trying to address?
> 
> Losing our ability to distribute Liberation fonts at all.
> 
> The same for Debian derivatives and other redistributors.
> 
> Users not being able to exercise their GPL/DFSG-promised rights
> and our reputation suffering as a result.

That sounds dramatic. RedHat suing Debian over this?

Interestingly enough, last time I used Liberation font, the .sfd could
be created from the .ttf and vice-versa - consequently isn't the .ttf
already a source form?

> > Unless they ship the source on the same server as their tarball.
> > (like a binary package with [L]GPL'd deps)
> 
> I was referring to the source package here.

So did I. I read "upstream is violating the license". I say "not if
they distribute the source on the same server".

> > This sounds like an automated mail with little effort on the sending
> > side while expecting decent effert on the receiving side.
> 
> This is incorrect, I spent a lot of effort tracking down which packages
>  were probably violating the GPL and confirming that for each one.

OK, that didn't convey in the bug report.

> OTOH, it should be a very minor amount of work for package maintainers,
> just repacking the tarball and adding the dependencies.

I mentioned build system issues, plus testing, plus possibly scripting
if upstream doesn't change and this has to be done at each upload.
(depending on distro-provided version though, that was covered long ago)

> > I never heard of the Debian Fonts Task Force
> 
> The team maintains a lot of different fonts (232 src pkgs) in Debian.
> 
> > for all these reasons this was quite a bad first impression :(
> 
> I have to say I wasn't expecting a maintainer response either, almost
> all the other bug reports I filed about this issue in other packages
> were promptly fixed with no extra communication with maintainers.

Wait - sending a lot of release-critical bugs marking packages for
deletion just before a freeze and... not expecting to be involved? :/

Cheers!
Sylvain

Bug#853009: wxglade: generates invalid C++ code when there is ID generation

[beuc]

Package: wxglade
Version: 0.7.2-2
Severity: important

Hi,

The C++ generation produces code that doesn't compile when there is ID
generation:

$ cat test.wxg





frame_1

wxVERTICAL

0
0

button_1
mybutton=?






$ python /usr/share/wxglade/wxglade.py -g C++ test.wxg -o test.cpp
INFO: Starting wxGlade version "0.7.2" on Python 2.7.13
INFO: Base directory: /usr/share/wxglade
INFO: Documentation directory:/usr/share/wxglade/docs
INFO: Icons directory:/usr/share/wxglade/icons
INFO: Build-in widgets directory: /usr/share/wxglade/widgets
INFO: Template directory: /usr/share/wxglade/templates
INFO: Credits file:   /usr/share/wxglade/CREDITS.txt
INFO: License file:   /usr/share/wxglade/LICENSE.txt
INFO: Manual file:/usr/share/wxglade/docs/html/index.html
INFO: Tutorial file:  /usr/share/wxglade/docs/tutorial.html
INFO: Home directory: /home/me
INFO: Application data directory: /home/me/.wxglade
INFO: Configuration file: /home/me/.wxglade/wxgladerc
INFO: History file:   /home/me/.wxglade/file_history.txt
INFO: Log file:   /home/me/.wxglade/wxglade.log
INFO: Current locale settings are:
INFO:   Language code: fr_FR
INFO:   Encoding: UTF-8
INFO:   Filesystem encoding: UTF-8
INFO: Module custom_widget.wconfig not found.
INFO: Module menubar.wconfig not found.
INFO: Module spacer.wconfig not found.
INFO: Load code generators:
INFO: Module calendar_ctrl.lisp_codegen not found.
INFO: Module generic_calendar_ctrl.lisp_codegen not found.
INFO: Load sizer generators:

$ g++ -c -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__  test.cpp
test.cpp: In constructor ‘MyFrame::MyFrame(wxWindow*, wxWindowID, const 
wxString&, const wxPoint&, const wxSize&, long int)’:
test.cpp:23:31: error: lvalue required as left operand of assignment
 mybutton = wxID_HIGHEST + 1000button_1 = new wxButton(this, mybutton, 
_("button_1"));
   ^~~~

AFAICS this is fixed in the development (f172c83ff51d) version of wxGlade.

Cheers!
Sylvain

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

Kernel: Linux 4.8.0-2-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 wxglade depends on:
ii  python   2.7.13-1
ii  python-wxgtk3.0  3.0.2.0+dfsg-3

wxglade recommends no packages.

wxglade suggests no packages.

-- no debconf information

Bug#853000: wxglade wrapper ignores command line parameters

[beuc]

Package: wxglade
Version: 0.7.2-2
Severity: important

Hi,

/usr/bin/wxglade was patched to a much simpler version.
So simple that it ignores all commande line parameters!

Please change the last line of debian/patches/wxglade.patch from
+exec python /usr/share/wxglade/wxglade.py
to
+exec python /usr/share/wxglade/wxglade.py "$@"

(or possibly see with the upstream maintainer about having a wrapper
 that works for both standalone and packaged releases)

Cheers!
Sylvain

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

Kernel: Linux 4.8.0-2-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 wxglade depends on:
ii  python   2.7.13-1
ii  python-wxgtk3.0  3.0.2.0+dfsg-3

wxglade recommends no packages.

wxglade suggests no packages.

-- no debconf information

Bug#850096: Make git snapshot? (2011 → 2016)

[beuc]

Hi,

> It's been a LONG time since upstream garglk had a stable release.
> 
> The current git master includes major interpreter upgrades (below),
> as well as bugfixes for some specific games.

It's something to keep in mind for after the release.  I don't know
how usable the git master is though, it's best to bug upstream into
making a proper release, this would benefit to everybody.

Cheers!
Sylvain

Bug#744972: lintian: source-is-missing is too strict/naive for finding files

[beuc]

Hi,

http://sources.debian.net/src/fusionforge/6.0.3-1/
https://lintian.debian.org/maintainer/lola...@debian.org.html#fusionforge
E source-is-missing
plugins/wiki/www/themes/default/moacdropdown.js
plugins/wiki/www/themes/default/toolbar.js
vendor/jquery-jqplot/plugins/jqplot.dateAxisRenderer.js
vendor/jquery-jqplot/plugins/jqplot.pyramidAxisRenderer.js
vendor/jquery-storage/jquery.Storage.js
vendor/jquery-teamwork-gantt/libs/dateField/jquery.dateField.js
vendor/jquery-teamwork-gantt/libs/platform.js
www/docman/scripts/DocManController.js

Cheers!
Sylvain

On Thu, Oct 22, 2015 at 11:49:22AM +, Bastien Roucaries wrote:
> Coule you send US sources.debian.net links to thèse files?
> 
> Le 21 octobre 2015 14:16:04 GMT+02:00, b...@debian.org a écrit :
> >Hi,
> >
> >FusionForge got 8 false positives since a month or so.
> >
> >Most of them are source files that are believed not to be source
> >files.
> >
> >Should I override them all?
> >
> >Cheers!

Bug#744972: lintian: source-is-missing is too strict/naive for finding files

[beuc]

Hi,

FusionForge got 8 false positives since a month or so.

Most of them are source files that are believed not to be source
files.

Should I override them all?

Cheers!
Sylvain

Bug#773246: closed by IOhannes m zmölnig (Debian/GNU) <umlae...@debian.org> (Re: hydrogen-drumkits: DFSG-ness of the drumkits)

[beuc]

Hi,

> From: "IOhannes m zmölnig (Debian/GNU)" 
> today hydrogen-drumkits_2015.09.28-1 has been accepted into unstable.
> thus all included drumkits are now clearly DFSG-free, and i'm closing
> this bug report.

Thanks for clearing this out!

Cheers!
Sylvain

Bug#793683: unowned files after purge (policy 6.8, 10.8)

[beuc]

Control: severity -1 wishlist
thanks

Hi,

On Fri, Sep 18, 2015 at 02:06:44PM +0200, Andreas Beckmann wrote:
> On 2015-09-16 16:15, b...@debian.org wrote:
> > Same for
> > user-uploaded attachments in #793683.  Can you elaborate?
> 
> I primarily spoke about empty directories here ...
> 
> But since you are asking about the content you expect to be stored
> there: Several packages that "store user generated stuff" (e.g.
> databases servers) have debconf questions about removing these things on
> purge (check e.g. mysql). They usually default to "no" (the safe
> solution), but in piuparts I preseed them to "yes".

These empty directories are program data created part of running
FusionForge, if only a little bit.  They are not installed by the
package per-se.

AFAIU you're requesting removing program data optionally on purge, so
I move this ticket to 'wishlist'.

Cheers!
Sylvain

Bug#798706: unowned files after purge (policy 6.8, 10.8)

[beuc]

Hi,

On Fri, Sep 18, 2015 at 06:21:06PM +0200, Andreas Beckmann wrote:
> On 2015-09-18 14:30, b...@debian.org wrote:
> >>>   /etc/fusionforge/ssl-cert-scm.keynot owned
> >>>   /etc/fusionforge/ssl-cert-scm.pemnot owned
> >>>   /etc/fusionforge/ssl-cert.keynot owned
> >>>   /etc/fusionforge/ssl-cert.pemnot owned
> > 
> > I disagree, because those are certificates, plus they may be installed
> > by the user.
> 
> Right now I don't remember any package leaving around certificates ...

As a matter of fact, I don't remember any package that does the same
level of automated install and/or external components integration as
FusionForge.  Other forges either:

- reinvent the wheel (e.g. redmine comes with its own re-coded repository
  browser and its own re-coded wiki)

- just didn't make the effort to be included in Debian (e.g. hertzog's
  packages for Tuleap, or yeupou's packages for Savane)

(- or both, e.g. gitlab :))

There's also the option to disable all the post-install scripts and
ask the user to run /usr/share/fusionforge/bin/post-install.sh .
That'd make the packages clean from the piuparts perspective (and avoid
quite some harassment ;)), but worse from the user perspective.

For these reasons I consider FusionForge is tackling pretty unique
packaging tasks.

Cheers!
Sylvain

Bug#798706: unowned files after purge (policy 6.8, 10.8)

[beuc]

Hi,

On Fri, Sep 18, 2015 at 01:58:24PM +0200, Andreas Beckmann wrote:
> All these I consider as "configuration files".
>  
> > 2m9.6s ERROR: FAIL: Package purging left files on system:
> >   /etc/apache2/sites-available/fusionforge.conf ->
> /etc/fusionforge/httpd.confnot owned

Indeed.

> >   /etc/fusionforge/ssl-cert-scm.key  not owned
> >   /etc/fusionforge/ssl-cert-scm.pem  not owned
> >   /etc/fusionforge/ssl-cert.key  not owned
> >   /etc/fusionforge/ssl-cert.pem  not owned

I disagree, because those are certificates, plus they may be installed
by the user.

-- 
Sylvain

Bug#798973: anonscm: AH01630: client denied by server configuration

[beuc]

Control: tags -1 fixed-upstream
thanks

Hi,

I fixed this in the stable branch as:
https://scm.fusionforge.org/anonscm/gitweb/?p=fusionforge/fusionforge.git;a=commitdiff;h=98b2e2fe2748245a61ea3f33ceda099055775dc2

Cheers!
Sylvain

On Wed, Sep 16, 2015 at 12:53:18PM +0200, Christoph Martin wrote:
> Hi Sylvain,
> 
> Am 15.09.2015 um 16:59 schrieb b...@debian.org:
> > This looks like an issue in the Apache 2.4 configuration (missing
> > 'Require all granted' or similar).  Make sure configuration files in
> > /etc/gforge/httpd.d/ were updated.
> 
> Ich checked the config files against the versions in
> /usr/share/gforge/etc/httpd.conf.d-fhs/ and could see no differences.
> But I introduces a line
> 
> Require all granted
> 
> in plugin-generic.inc and it works now. So I think it is really missing
> in the delivered configuration or something else is broken.
> 
> Yours
> Christoph

> begin:vcard
> fn:Christoph Martin
> n:Martin;Christoph
> email;internet:mar...@uni-mainz.de
> tel;work:+49-6131-3926337
> tel;fax:+49-6131-3926407
> tel;cell:+49-179-7952652
> version:2.1
> end:vcard
> 

Bug#793683: unowned files after purge (policy 6.8, 10.8)

[beuc]

Hi,

On Fri, Sep 11, 2015 at 09:58:47PM +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package left unowned files on
> the system after purge, which is a violation of policy 6.8 (or 10.8):
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

The sections you reference mention removing installed files,
configuration files, and log files.  I don't see any reference to
application data such as #798706's web certificates.  Same for
user-uploaded attachments in #793683.  Can you elaborate?

Cheers!
Sylvain

Bug#798973: anonscm: AH01630: client denied by server configuration

[beuc]

Hi,

This looks like an issue in the Apache 2.4 configuration (missing
'Require all granted' or similar).  Make sure configuration files in
/etc/gforge/httpd.d/ were updated.

If the problem persists, since the 5.3 version in Debian is now frozen
and FF 6.0 available, I'd suggest either:

- use the latest 5.3.3 release from fusionforge.org, which may contain
  configuration fixes

- upgrade to 6.0 stable, using packages from jessie-backports or
  directly from the upstream APT repo, see:
  
https://fusionforge.org/plugins/mediawiki/wiki/fusionforge/index.php/DEB_Installation

Cheers!
Sylvain

On Mon, Sep 14, 2015 at 05:29:48PM +0200, Christoph Martin wrote:
> Package: fusionforge-minimal
> Version: 5.3.2+20141104-3+deb8u1
> Severity: normal
> 
> After upgrade from wheezy (with backports packages) to jessie
> https://version.zdv.uni-mainz.de/anonscm/git/ is not allowed
> anymore:
> 
> You don't have permission to access /anonscm/git/miles/miles.git/info/refs on 
> this server
> 
> miles is a repository with public access. that is
> the roles anonymous and logged in users have read permissions.
> 
> Log says:
> 
> [authz_core:error] [pid 42024] [client 
> 2001:4c80:40:4b3:3617:ebff:fecb:d1db:60226] AH01630: client denied by server 
> configuration: /var/lib/gforge/chroot/scmrepos/git/miles/miles.git/info/refs
> 
> I can see a file plugin-generic.inc in /etc/gforge/httpd.conf.d/
> which refers /var/lib/gforge/chroot/scmrepos ...
> but I can't see where it is used/referenced.
> 
> When I include it in 10-vhosts-main.conf it does not change anything.
> 
> Do you have any idea what could have gone wrong?
> 
> Yours
> Christoph
> 
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable-updates
>   APT policy: (700, 'stable-updates'), (700, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages fusionforge-minimal depends on:
> ii  debconf [debconf-2.0] 1.5.56
> ii  gforge-common 5.3.2+20141104-3+deb8u1
> ii  gforge-db-postgresql [gforge-db]  5.3.2+20141104-3+deb8u1
> ii  gforge-web-apache2 [gforge-web]   5.3.2+20141104-3+deb8u1
> ii  ucf   3.0030
> 
> Versions of packages fusionforge-minimal recommends:
> pn  gforge-lists-mailman  
> 
> fusionforge-minimal suggests no packages.
> 
> -- no debconf information
> 

Bug#798363: fusionforge-web: fails to install: /usr/share/fusionforge/post-install.d/web/web.sh: line 77: openssl: command not found

[beuc]

Control: severity -1 normal

Hi,

Lowering severity since only piuparts is stumbling upon this (i.e.:
neither the FusionForge rebuild testsuite nor any of our production
installs triggered this issue, hence widespread usage works).

I wish you didn't wait until right when FusionForge is back in testing
to report this.  This has been around for ages, we didn't touch the
package for 2 months, and it's much more efficient to group reports.

(For the record, I find templated messages displeasing, and one that
calls a package "too buggy" for such an issue, disrespectful :/)

Patch onwards.

Cheers!
Sylvain


On Tue, Sep 08, 2015 at 02:57:29PM +0200, Andreas Beckmann wrote:
> Package: fusionforge-web
> Version: 6.0.2+20150901-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
> 
> >From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package fusionforge-web.
>   (Reading database ... 
> (Reading database ... 12482 files and directories currently installed.)
>   Preparing to unpack .../fusionforge-web_6.0.2+20150901-1_all.deb ...
>   Unpacking fusionforge-web (6.0.2+20150901-1) ...
>   Setting up fusionforge-web (6.0.2+20150901-1) ...
>   Enabling site fusionforge.
>   To activate the new configuration, you need to run:
> service apache2 reload
>   /usr/share/fusionforge/post-install.d/web/web.sh: line 77: openssl: command 
> not found
>   dpkg: error processing package fusionforge-web (--configure):
>subprocess installed post-installation script returned error exit status 
> 127
>   Errors were encountered while processing:
>fusionforge-web

Bug#793683: fusionforge-db-local: unowned directories after purge: /var/lib/fusionforge/*

[beuc]

Here's a root cause investigation:

The files are created by the DB upgrade process
(post-install.d/db/db.sh ->
db/20140710-forum-migrate-attachments-to-fs.php
db/20120603-docman-file-moved-in-fs.php
db/20120409-tracker-attachement-moved-in-fs.php)

They are normally created by fusionforge-web as empty dpkg
directories.

Removing /var/lib/fusionforge/* from the db-local package sounds like
a bad idea.

Creating the directories from db-local dpkg also sounds like a bad
idea since the package doesn't use them besides old data migration.

We may make the upgrade procedure skip the creation of the directories
is there's no data to migrate (during fresh installs).

-- 
Sylvain

Bug#789778: fusionforge-db-local: unconditionally starts systasksd upon install

[beuc]

Hi,

On Sun, Jul 26, 2015 at 03:17:26PM +0200, Andreas Beckmann wrote:
 Followup-For: Bug #789778
 Control: found -1 6.0.2-1
 
 On Wed, 24 Jun 2015 13:14:06 +0200 Andreas Beckmann a...@debian.org wrote:
  during a test with piuparts I noticed your package left processes
  running after the package has been removed and/or purged.
 
 This has been worked around in 6.0.2-1 with
   * Stop fusionforge-systasksd on uninstall (closes: #789778)
 
  The real problem is in the postinst which unconditionally starts this
  service, i.e. without using incoke-rc.d.
 
 But this has not been addressed at all.

As you probably noticed, the packaging merely forwards postinst events
to the upstream post-install scripts, which uses the distro-portable
'service' command to start and stop services.

Does this mean the Debian maintainer has to patch upstream to
special-case Debian?

Also are you interested in working on such a fix, since you have
enough time to reopen bugs one month after closing (through an
upstream patch, or making 'service' consistent with 'update-rc.d')?

Regards,
Sylvain


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

Bug#726209: closed by b...@debian.org (Re: ballz: missing icon entry in menu file Jessie Release Goal)

[beuc]

I mean a complete patch, including conversion tools and such.

If the team isn't working on a bug for 2 years, that's just
cluttering the BTS for the actual maintainer.

I'm having a hard time assessing how much time you made me waste on
something apparently only you cares about.

- Sylvain

On Tue, Jul 28, 2015 at 12:49:14AM +0200, Markus Koschany wrote:
 Control: reopen -1
 
 I have provided a patch two years ago.
 
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726209#27
 
 Please stop closing valid bug reports of team maintained packages. If
 you are unwilling to apply this trivial patch, I will do it within the
 next couple of weeks.


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

Bug#726209: closed by b...@debian.org (Re: ballz: missing icon entry in menu file Jessie Release Goal)

[beuc]

Hi,

I salvaged upstream from google code, converted svn to git, refreshed
the autotools, integrated appstream contribution from Fedora,
coordinated with usptream, made a new release, extensively tested, and
packaged.

You only complained, and now you're trying to provoke me by
questioning my usefulness.

I don't wish to complexify the packaging and add dependencies such as
imagemagick for an old menu system.  I don't see why this is such a
big issue for you.

To be fair, I give you 1 day to find the 1 minute you estimated for
applying, testing and uploading your patch.  Passed this delay, I'll
close the bug.

Regards,
Sylvain

On Tue, Jul 28, 2015 at 11:52:20AM +0200, Markus Koschany wrote:
 Am 28.07.2015 um 10:11 schrieb b...@debian.org:
  I mean a complete patch, including conversion tools and such.
 
 The patch was complete back then and the fix includes adding a single
 line to your already existing menu file. You can either convert the png
 icon to a xpm icon during build time with imagemagick or you can add it
 to your debian directory. Solutions are documented on the wiki.
 
 https://wiki.debian.org/Games/JessieReleaseGoal#Solutions
 
  If the team isn't working on a bug for 2 years, that's just
  cluttering the BTS for the actual maintainer.
 
 You are also part of this team, at least on paper. If you were a helpful
 team member, you would have fixed this trivial bug years ago. Applying
 my patch takes only a minute. Not every Debian contributor can upload
 every package in the archive. Your aggressive bug closing behaviour is
 stunning.
 
  I'm having a hard time assessing how much time you made me waste on
  something apparently only you cares about.
 
 Obviously that is entirely your fault but then apparently there is a
 pattern and I am not the only one who has made this experience.
 
 https://bugs.debian.org/789772


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

Bug#793598: lxc-debian: only enable free section by default

[beuc]

Package: lxc
Version: 1:1.0.7-4
Severity: normal
Tags: patch

Hi,

By default, upstream's 'lxc-debian' template enables 'contrib' and
'non-free' sections which are not part of the Debian distribution.

The attached patch only enables 'main'.  This avoids installing
proprietary packages by mistake.

Cheers!
Sylvain
Index: lxc-1.0.7/templates/lxc-debian.in
===
--- lxc-1.0.7.orig/templates/lxc-debian.in
+++ lxc-1.0.7/templates/lxc-debian.in
@@ -172,8 +172,8 @@ write_sourceslist()
 fi
 
 cat  ${rootfs}/etc/apt/sources.list  EOF
-${prefix} $MIRROR  ${release} main contrib non-free
-${prefix} $SECURITY_MIRROR ${release}/updates main contrib non-free
+${prefix} $MIRROR  ${release} main
+${prefix} $SECURITY_MIRROR ${release}/updates main
 EOF
 }
 

Bug#759725: #759725: postgresql-common: non-synchronous service postgresql start/stop/reload

[beuc]

Control: reopen -1

I explained in detail that the bug is only partially fixed and how
this is causing issues.

I provided 2 fixes:
- reverting back to init.d is a fix.
- applying the systemd rules from RHEL is another fix.

Please explain your behavior, I can't find a good faith explanation
for it.

- Sylvain

On Mon, Apr 13, 2015 at 12:24:31PM +0200, Christoph Berg wrote:
 Re: b...@debian.org 2015-04-08 20150408154517.ga12...@mail.beuc.net
  Here's my patch:
rm -f /lib/systemd/system/postgresql*
  and fallback to init.d/.
  
  Package worked perfectly fine until systemd was introduced in it.
  
  Please apply.
 
 I don't know what to say.


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

Bug#759725: #759725: postgresql-common: non-synchronous service postgresql start/stop/reload

[beuc]

Hi,

On Mon, Apr 13, 2015 at 05:50:54PM +0200, Christoph Berg wrote:
 Re: b...@debian.org 2015-04-13 20150413103816.ga15...@mail.beuc.net
  Control: reopen -1
  
  I explained in detail that the bug is only partially fixed and how
  this is causing issues.
  
  I provided 2 fixes:
  - reverting back to init.d is a fix.
  - applying the systemd rules from RHEL is another fix.
  
  Please explain your behavior, I can't find a good faith explanation
  for it.
 
 Reverting is not an option. And throwing in a lengthy file from a
 different operating system is not a patch.
 
  On Mon, Apr 13, 2015 at 12:24:31PM +0200, Christoph Berg wrote:
   Re: b...@debian.org 2015-04-08 20150408154517.ga12...@mail.beuc.net
Here's my patch:
  rm -f /lib/systemd/system/postgresql*
and fallback to init.d/.
 
 Sarcastic comments like this are not particularly helpful.

I don't allow you to call me sarcastic when I'm not.

Also if you want to discuss this more precisely, I suggest elaborating
more than Reverting is not an option (because I don't see why not).

Last but not least, I don't know enough about systemd and postgresql
to provide a patch.  Nonetheless, there is a Debian-specific
regression, hence this bug needs to stay open.


 So let's get back on topic. What do you think should be fixed in
 detail in the package?

Let me know what is unclear in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759725#37
(namely: - However 'stop' is not fixed (still async).)
completed with a use case in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759725#46
(namely: Can you make the 'stop' procedure synchronous as well ?)
and I'll elaborate.

Cheers!
Sylvain


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

Bug#759725: #759725: postgresql-common: non-synchronous service postgresql start/stop/reload

[beuc]

Here's my patch:
  rm -f /lib/systemd/system/postgresql*
and fallback to init.d/.

Package worked perfectly fine until systemd was introduced in it.

Please apply.

- Sylvain

On Wed, Apr 08, 2015 at 05:30:48PM +0200, Christoph Berg wrote:
 Control: severity -1 normal
 
 Re: b...@debian.org 2015-04-08 20150408150359.ga11...@mail.beuc.net
  I need to introduce sleep 1's in FusionForge to work-around this
  issue, so I believe this is not on par with Debian quality standards
  for a release.  I'm raising the severity to serious accordingly.
  
  For reference, this issue is not present in CentOS7, while they
  migrated to systemd (their .service is attached).
 
 This is not an issue that affects typical usage so much that it breaks
 the package. I'll revert the severity accordingly.
 
 Fixing would be much easier if you provided a patch :)


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

Bug#759725: #759725: postgresql-common: non-synchronous service postgresql start/stop/reload

[beuc]

Control: severity -1 serious

Hi,

I need to introduce sleep 1's in FusionForge to work-around this
issue, so I believe this is not on par with Debian quality standards
for a release.  I'm raising the severity to serious accordingly.

For reference, this issue is not present in CentOS7, while they
migrated to systemd (their .service is attached).

Regards,
Sylvain

On Wed, Mar 11, 2015 at 05:44:34PM +0100, b...@debian.org wrote:
 Hi,
 
 I currently get a race condition when stopping postgresql and backing
 up /var/lib/postgresql.  We use this backup to quickly reset the DB to
 a saved state in a lenghty testsuite.
 
 cp: cannot stat '/var/lib/postgresql/9.4/main/postmaster.pid': No such file 
 or directory
 
 In other words, the init system tells me postgresql is properly down,
 I even have additional tests in my script to try and connect to the DB
 to ensure the service is actually down, but really the service is
 still up, and the .pid file is eventually removed in the background by
 the init system, during the 'cp'.
 
 Can you make the 'stop' procedure synchronous as well ?
 
 - Sylvain
 
 
 On Wed, Oct 08, 2014 at 12:04:33PM +0200, b...@debian.org wrote:
  Hi,
  
  Thanks for the recent patch.
  
  - It fixes 'start' and 'restart'.
I'm not sure about 'reload' but I couldn't make it fail, so OK :)
  
  - However 'stop' is not fixed (still async).
  
  - Also after
service postgresql stop ; rm -rf /var/lib/postgresql ; service postgresql 
  start
- 'status' will still happily declare the service 'active'
  
  These tests show the bug is not completely fixed, so I'm reopening it.
  
  Cheers!
# It's not recommended to modify this file in-place, because it will be
# overwritten during package upgrades.  If you want to customize, the
# best way is to create a file /etc/systemd/system/postgresql.service,
# containing
#   .include /lib/systemd/system/postgresql.service
#   ...make your changes here...
# For more info about custom unit files, see
# 
http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F

# For example, if you want to change the server's port number to 5433,
# create a file named /etc/systemd/system/postgresql.service containing:
#   .include /lib/systemd/system/postgresql.service
#   [Service]
#   Environment=PGPORT=5433
# This will override the setting appearing below.

# Note: changing PGPORT or PGDATA will typically require adjusting SELinux
# configuration as well; see /usr/share/doc/postgresql-*/README.rpm-dist.

# Note: do not use a PGDATA pathname containing spaces, or you will
# break postgresql-setup.

# Note: in F-17 and beyond, /usr/lib/... is recommended in the .include line
# though /lib/... will still work.

[Unit]
Description=PostgreSQL database server
After=network.target

[Service]
Type=forking

User=postgres
Group=postgres

# Port number for server to listen on
Environment=PGPORT=5432

# Location of database directory
Environment=PGDATA=/var/lib/pgsql/data

# Where to send early-startup messages from the server (before the logging
# options of postgresql.conf take effect)
# This is normally controlled by the global default set by systemd
# StandardOutput=syslog

# Disable OOM kill on the postmaster
OOMScoreAdjust=-1000

ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA}
ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o -p ${PGPORT} -w -t 300
ExecStop=/usr/bin/pg_ctl stop -D ${PGDATA} -s -m fast
ExecReload=/usr/bin/pg_ctl reload -D ${PGDATA} -s

# Give a reasonable amount of time for the server to start up/shut down
TimeoutSec=300

[Install]
WantedBy=multi-user.target

Bug#759725: #759725: postgresql-common: non-synchronous service postgresql start/stop/reload

[beuc]

 51340 postgresql_9.4+162_all.deb
   890006a4d530ef8b80d061bc4042e6cd798a3f00 51360 
  postgresql-client_9.4+162_all.deb
   34b2d39d1f6022cd96876f9b97ad987afee38ff9 51350 
  postgresql-doc_9.4+162_all.deb
   8ee08a4781b7e6a4b8e02dcd61fccf1313754fdf 51348 
  postgresql-contrib_9.4+162_all.deb
   37cdc985a272f14601430965e0a4b0c51077945b 200776 
  postgresql-common_162_all.deb
   4fd33e920efd5753e91b33bf9c616e3934b56534 72972 
  postgresql-client-common_162_all.deb
  Checksums-Sha256:
   60ad532f39e13d151ef7f1fcd41c827c881db8a6930bdf293cb6bc7e895aab8b 2240 
  postgresql-common_162.dsc
   b5346242d7c3704002d6ca9f1339cdd029a7835ef91edadeb33c78efe3b4b96b 186148 
  postgresql-common_162.tar.xz
   a8ae6a6a98bbf55e6ce7bda3ad9f80d72b74363b0178d450daeaeac1e746c62c 58446 
  postgresql-server-dev-all_162_all.deb
   e4fa20fae0095a92b18673edc31f26c93b8dddecb4a5f0dfdea3ab661d29173e 51340 
  postgresql_9.4+162_all.deb
   58c7da68cf06e36cdd98442a937c671278d5f6f8cdd24a062c2b80a05966f315 51360 
  postgresql-client_9.4+162_all.deb
   3f2078e2beeb6d8ad9155415772fd650a85852a502cc3a8d9e360bcbcbc3b089 51350 
  postgresql-doc_9.4+162_all.deb
   3234f193a5a1645c56f860776a1ab9420d0e0eff932864ad93776d1bcf60db63 51348 
  postgresql-contrib_9.4+162_all.deb
   aac562a550a831661d477b20cbe43510fadb699fdcc330a50b6ca71e510ddbb6 200776 
  postgresql-common_162_all.deb
   fd0ec54bdab7318795134ec98bba6127c656fe38efefe3d8a52f1241e203a79b 72972 
  postgresql-client-common_162_all.deb
  Files:
   abfe957bd81f3d68aec0205233ff609e 58446 database optional 
  postgresql-server-dev-all_162_all.deb
   9c3efc223baa8258cad326470d523b74 51340 database optional 
  postgresql_9.4+162_all.deb
   d5bc60b95fbee06b77f930ce66425ec9 51360 database optional 
  postgresql-client_9.4+162_all.deb
   5b651fecba32a54ab5b316a168f72b66 51350 doc optional 
  postgresql-doc_9.4+162_all.deb
   fc840fdb116d0081c38d157e85d8f073 51348 database optional 
  postgresql-contrib_9.4+162_all.deb
   3d6c3f20e3e1a91bfb2ad1ad3461f617 200776 database optional 
  postgresql-common_162_all.deb
   bdd30524c1444521f3eb9db7823153cd 72972 database optional 
  postgresql-client-common_162_all.deb
   62e59e4d5652fe62dd9b836d0e78c901 2240 database optional 
  postgresql-common_162.dsc
   9c6f016609e8a4f74228b3f024d7f5c2 186148 database optional 
  postgresql-common_162.tar.xz
  
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1
  
  iQIcBAEBCAAGBQJUND53AAoJEExaa6sS0qeudI4P/26SGgCyyzCpp9td6F2hlLwF
  /pNLvS87A0fNlKz6GzRbd9osKxLe9SWteZwKdgjYtUzeCvr8awQLrLNdpLtzg6ru
  VJZWyiA/ixX8KEIXL1Ze5EfnDCdxyS5keTmzZG/mmoyzH4qeAeTMcLYQc38r4w2o
  VXB6wgizt4Ua4mzKLOU7OlhfwfAY9e5VQjEDoYpsJ24Xdt8kLTD8tXkn1HgeajO7
  GCKrU0YLkd9Q2aj9B1+qtMYwTf7PLqH1Lzu+Fwg+2mee14bo22cMecROmSKV7yFp
  BtlNCEtBV1z1AHHrK0kzwzsME4BzKbXNxKoSA35YWzll/DOIeO3uUMDitHVIK/AL
  pyK7pMyeUkdyHHKFJ+YriUelX3Q1yMePxZqp6O541LkWje5aA/8ZTZjyLGbHhQ/5
  /w4cJVHAO3rG4hByc6pAXCrtJOjNFYGewHb+oc8mTdbEHRbPK+aRgC2ugDN8+JKA
  xNVTfykF/0vdPH6+Qsm0deQDgHuHkx58jawivjaSuoVKsCKCmKjGH46CzuLfqfkK
  +Upr8oX0lCJFfgGapVKySjk31BRAFmGicnTzYCSzWwXFOkaoTQydzUJ4gYug5pfK
  mQGGLz3J9RiSJaAyF5BOAfespx9PnAz2H24gb7iPazfzxWm31WIz+mzt00F09UCg
  ukCm6ezkAR8adS0f/lqH
  =vmXR
  -END PGP SIGNATURE-
 
  Date: Fri, 29 Aug 2014 20:28:50 +0200
  From: beuc b...@debian.org
  To: Debian Bug Tracking System sub...@bugs.debian.org
  Subject: postgresql-common: non-synchronous service postgresql
   start/stop/reload
  X-Mailer: reportbug 6.5.0
  
  Package: postgresql-common
  Version: 160
  Severity: important
  
  Hi,
  
  When working on the FusionForge installation system today I noticed
  that in Debian Jessie, running:
  
service postgresql start
  
  (or stop, or reload), is now asynchronous, due to using the new
  PostgreSQL systemd init scripts.
  
  Previously I could rely on the init script to come back when the
  database was properly stopped and flushed.  Right now the command
  returns immediately and starts/stops/reloads in the background.
  
  My scripts need to modify the PostgreSQL listen address and reload it
  before populating the database through the PHP application.  They also
  need to stop/backup/start the server for quick load/restore during our
  testsuite.  Due to this change the installation system fails randomly
  due to race condition.
  
  I found it basically impossible to work-around this issue in a
  portable manner:
  
  - 'service postgresql status' is not reliable: it usually says the
service is stopped far before the shutdown is complete. I also got a
few cases where it reported active service with no running daemon.
  
  - the 'postgresql' process may be stopped already, but pg_ctl still
doing a faststop (especially when there's data to flush to disk) -
there may also be other PostgreSQL processes I don't know about;
so 'ps' is not reliable either.
  
  - the postgresql control commands vary between Debian and RedHat
(pg_ctl vs. pg_clusterctl), and they need a data directory that can
be in varied, possibly multiple

Bug#771944: closed by Michael Gilbert mgilb...@debian.org (Re: Bug#771944: Following FusionForge 5.3 stable branch)

[beuc]

Control: reopen -1

 don't complain about the communication style of the release team
 when they have to cope with hundreds of inquiries

Let's reopen the bug and discuss this after the freeze period, you're
not in a situation to accept comments AFAICS.

- Sylvain

On Mon, Feb 16, 2015 at 11:29:34AM +0100, Michael Banck wrote:
 (Uh, for the record, I am not a release team members, either)
 
 On Mon, Feb 16, 2015 at 11:24:39AM +0100, Michael Banck wrote:
  On Mon, Feb 16, 2015 at 10:57:04AM +0100, b...@debian.org wrote:
   Hi,
   
   On Mon, Feb 16, 2015 at 09:29:28AM +, Adam D. Barratt wrote:
On 2015-02-16 9:20, b...@debian.org wrote:
On Sat, Feb 14, 2015 at 10:46:11AM -0500, Michael Gilbert wrote:
If you want more changes to be considered, don't they need to be
uploaded first?  In that case, now is quite late.

is a bit easy, I believe we made the effort to contact you as
mentioned in your FAQ.  Don't blame us :/

There appears to be some confusion here, so for clarity - Michael is
not a member of the release team.
   
   Should this be a showcase of everything that could go wrong when
   contacting the release team?
  
  Why?  I think there were a lot of inquiries like yours - and basically
  all of them were turned down for the freeze. (Maybe you can discuss this
  again after the jessie release for a stable update, I don't know whether
  that might work).
  
  If anything, maybe don't complain about the communication style of the
  release team when they have to cope with hundreds of inquiries, and you
  only with your own one and don't point at PostgreSQL and threaten to
  upload beta software just before the next freeze might be useful points
  to keep in mind.


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

Bug#771944: closed by Michael Gilbert mgilb...@debian.org (Re: Bug#771944: Following FusionForge 5.3 stable branch)

[beuc]

Hi,

On Sat, Feb 14, 2015 at 10:46:11AM -0500, Michael Gilbert wrote:
 On Sat, Feb 14, 2015 at 8:24 AM:
  You got it all wrong.
 
 So other than the typo s/font/fusion/, I don't really understand that
 statement.  There were two unstable fusionforge uploads post-freeze
 that were in fact accepted into testing [0], and there are no other
 proposed changes currently to review, so I'm not sure what you're
 asking for.

I asked:
 It makes sense that users benefit from the quality of this branch,
 so we'd like to know to what extent following this [stable] branch
 is compatible with the Freeze.

Bottom line: we wanted to include stable bugfixes.

Given that we:
  - were given a RTFM (which says no bugfix),
  - had to wait 2 months and a half to get another follow-up,
we had to not include the bugfixes, but a special Debian branch that
only fixes a couple serious nitpicks from piuparts.

Additionally, in the case of submitting e.g. 5.3.3 and getting the
transition to freeze rejected, it would be quite a hassle to revert to
5.3.2 or switch to proposed-updates, hence why we asked here
beforehand.


So saying:

 If you want more changes to be considered, don't they need to be
 uploaded first?  In that case, now is quite late.

is a bit easy, I believe we made the effort to contact you as
mentioned in your FAQ.  Don't blame us :/

-- 
Sylvain


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

Bug#771944: closed by Michael Gilbert mgilb...@debian.org (Re: Bug#771944: Following FusionForge 5.3 stable branch)

[beuc]

Hi,

On Mon, Feb 16, 2015 at 09:29:28AM +, Adam D. Barratt wrote:
 On 2015-02-16 9:20, b...@debian.org wrote:
 On Sat, Feb 14, 2015 at 10:46:11AM -0500, Michael Gilbert wrote:
 If you want more changes to be considered, don't they need to be
 uploaded first?  In that case, now is quite late.
 
 is a bit easy, I believe we made the effort to contact you as
 mentioned in your FAQ.  Don't blame us :/
 
 There appears to be some confusion here, so for clarity - Michael is
 not a member of the release team.

Should this be a showcase of everything that could go wrong when
contacting the release team?

-- 
Sylvain


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

Bug#771944: closed by Michael Gilbert mgilb...@debian.org (Re: Bug#771944: Following FusionForge 5.3 stable branch)

[beuc]

Hi,

You got it all wrong.

I wrote:
 So, I take it we need to maintain a branch off the upstream stable
 branch, that will not include most user-related bugfixes (but include
 the piupart-related nitpicks ;))?

Short of an answer from you, that's exactly what happened, and Jessie
has a sub-par version of FusionForge (btw, not fontforge).

But I see that PostgreSQL got frozen as a beta, and was allowed to
follow its stable branch during the freeze, so next time I'm going to
push betas in testing for all my packages ;)

- Sylvain

On Sat, Feb 14, 2015 at 03:51:06AM +, Debian Bug Tracking System wrote:
 This is an automatic notification regarding your Bug report
 which was filed against the release.debian.org package:
 
 #771944: Following FusionForge 5.3 stable branch
 
 It has been closed by Michael Gilbert mgilb...@debian.org.
 
 Their explanation is attached below along with your original report.
 If this explanation is unsatisfactory and you have not received a
 better one in a separate message then please contact Michael Gilbert 
 mgilb...@debian.org by
 replying to this email.
 
 
 -- 
 771944: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771944
 Debian Bug Tracking System
 Contact ow...@bugs.debian.org with problems

 Date: Fri, 13 Feb 2015 22:46:19 -0500
 From: Michael Gilbert mgilb...@debian.org
 To: 771944-cl...@bugs.debian.org
 Subject: Re: Bug#771944: Following FusionForge 5.3 stable branch
 
 On Thu, Dec 4, 2014 at 5:12 AM:
  I already read the policy, and since it sounds sensible to follow the
  upstream Stable branch for the debian Stable release, I'm asking.
 
 It looks like your fontforge updates were accepted into testing.
 
 Best wishes,
 Mike

 Date: Wed, 3 Dec 2014 18:52:26 +0100
 From: b...@debian.org
 To: sub...@bugs.debian.org
 Cc: lola...@debian.org
 Subject: Following FusionForge 5.3 stable branch
 User-Agent: Mutt/1.5.21 (2010-09-15)
 
 Package: release.debian.org
 User: release.debian@packages.debian.org
 Severity: normal
 
 Hi,
 
 We're (upstream-ly) maintaining a stable branch for FusionForge,
 called 5.3, which the Debian package currently follows.
 (incidentally Lolando and I are both upstream and debian devs)
 
 We're currently pushing only bugfixes to this branch (some of them
 qualify as RC, some don't), because it's deployed at several large
 client installs already and we want to make sure we don't break
 anything.
 
 It makes sense that users benefit from the quality of this branch, so
 we'd like to know to what extent following this branch is compatible
 with the Freeze.


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

Bug#775588: [Pkg-haskell-maintainers] Bug#775588: darcs: Missing copyright information

[beuc]

Hi,

How about lowering the severity of this bug?

I just received this:
  fusionforge 5.3.2+20141104-3 is marked for autoremoval from testing on 
2015-03-02
  
  It (build-)depends on packages with these RC bugs:
  775588: darcs: Missing copyright information

Cheers!
Sylvain


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

Bug#776328: cytadela won't start

[beuc]

Hi,

I can reproduce the issue on my amd64 computer.

A work-around I've found is to press Enter twice rapidly when being
asked for the language (so that skips the intro completely).


More generally there seem to be an issue in the libvlc code:

#0  0x766729f3 in malloc_consolidate (av=av@entry=0x7699d620 
main_arena) at malloc.c:4157
#1  0x766734d1 in _int_free (av=0x7699d620 main_arena, 
p=optimized out, have_lock=0) at malloc.c:4057
#2  0x72117f8c in ?? () from /usr/lib/libvlccore.so.8
#3  0x7211417b in ?? () from /usr/lib/libvlccore.so.8
#4  0x7209a832 in libvlc_InternalCleanup () from 
/usr/lib/libvlccore.so.8
#5  0x771ccb8e in libvlc_release () from /usr/lib/libvlc.so.5
#6  0x0042f38a in play (filename=filename@entry=0x431496 
video/intro_en.webm, screen=0x773c20, offOnFinish=true, audio=optimized 
out) at videoplayer.cpp:191
#7  0x00422324 in CSDLClass::playVideo (this=optimized out, 
fileName=fileName@entry=0x431496 video/intro_en.webm, offOnFinish=optimized 
out, 
audio=optimized out) at CSDLClass.cpp:521
#8  0x0041a90d in CCytadelaMain::playIntro (this=0x7fffb6a0) at 
CCytadelaMain.cpp:985
#9  0x0041abb8 in CCytadelaMain::runMain 
(this=this@entry=0x7fffb6a0) at CCytadelaMain.cpp:1058
#10 0x00405163 in main (argc=optimized out, argv=0x7fffe3d8) at 
main.cpp:138

This may be because Cytadela was using libvlc 2.0, and Debian now uses
2.2.0~rc2.

I'm adding Cytadela's maintainer in copy - Tomasz, did you get a
similar report already?

Cheers!
Sylvain

On Mon, Jan 26, 2015 at 11:11:25PM +0100, Javier Barroso wrote:
 package:cytadela
 version: 1.1.0-2
 Severity: important
 
 At Debian Sid, with a Intel Card, After game intro, when you press enter key:
 
 $ cytadela
 
 Welcome to the Citadel!
 
 
 Reading the OpenGL vrsion and extensions...
 libGL: screen 0 does not appear to be DRI3 capable
 libGL: pci id for fd 8: 8086:0166, driver i965
 libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so
 libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
 libGL: Can't open configuration file /home/javi/.drirc: No such file
 or directory.
 libGL: Can't open configuration file /home/javi/.drirc: No such file
 or directory.
 Done
 Switching to 2D video mode...   Ok!
 Initializing configuration menu...
 Done
 Cheching the OpenGL version and extensions...
 
 OpenGL version: 3.0 Mesa 10.4.2
 OpenGL renderer: Mesa DRI Intel(R) Ivybridge Mobile
 Checking for available localizations (at locale/)...   Done
 Entering the config menu main loop...
 Chosen localization: ENGLISH
 Initial check and configuration finished successfuly!
 
 [7f2d5c001268] core vout display error: Failed to change zoom
 [7f2d5c001268] core vout display error: Failed to set on top
 [7f2d5c001268] core vout display error: Failed to change source AR
 Violación de segmento
 
 (Segmentation Fault)
 
 Do you have any tip ?
 
 Thank you
 


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

Bug#774799: sysv-rc: Unit my-service.service failed to load: No such file or directory, using install from source + update-rc.d

[beuc]

Package: sysv-rc
Version: 2.88dsf-58
Severity: important
X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org

Hi,

I'm currently working on the next version of FusionForge, which
installs a new service in /etc/init.d/ and starts it as part of the
installation process.

So I:
- Installed a new Debian 8
- git clone'd FusionForge and installed it
- Ran 'make post-install' which:
-- installs /etc/init.d/fusionforge-systasksd
-- detects Debian (not RedHat) and registers it using 'update-rc.d'
-- restarts the service using 'service fusionforge-systasksd restart'
(note: same result with 'invoke-rc.d fusionforge-systasksd restart')

Result:
Failed to start fusionforge-systasksd.service: Unit 
fusionforge-systasksd.service failed to load: No such file or directory.

Expected:
/etc/init.d/fusionforge-systasksd is executed

After searching the web to understand why on earth systemd dropped
compatibility with init.d, I eventually got advice from
#debian-systemd to just 'systemctl daemon-reload'.

It seems that update-rc.d does not tell systemd about the new init.d
script (and that invoke-rc.d only does so when
$DPKG_MAINTSCRIPT_PACKAGE is set).  FusionForge follows the Debian way
to install and activate a service, hence I expect it works without
having to introduce init-system-specific handling.

So, I suggest that update-rc.d tells systemd about the new init script
it just activated.

CC-ing pkg-systemd-maintain...@lists.alioth.debian.org as per request
on IRC :)

Cheers!
Sylvain


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

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[beuc]

Hi,

On Sun, Dec 14, 2014 at 02:28:26PM +0100, Guillem Jover wrote:
 On Fri, 2014-12-12 at 17:35:36 +0100, Thorsten Glaser wrote:
  So, with -noawait, the triggers just run later, but the dependency
  is satisfied early, right?
 
 Think of it as an asynchronouse notification that something changed in
 another package vs a notification that the triggering package needs
 something to be processed to be able to declare itself as configured.
 
 In case of -noawait, the triggering package never gets placed in a
 triggers-awaited state, so it can always satisfy dependencies when it
 has been configured.

So far my tests show that 'apt-get upgrade' doesn't start the noawait
triggers.  The fusionforge-plugin-mediawiki is marked
'triggers-pending' but apparently the user has to do something more
manually, which is not satisfying.
Any suggestion?


 On Fri, 2014-12-12 at 17:40:43 +0100, b...@debian.org wrote:
  There's one point I'd like to clarify: how comes we never had any
  issues with this?
  
  E.g. I don't see any warning here:
  http://buildbot.fusionforge.org/job/fusionforge-53-functests-deb/os=debian7/33/consoleFull
 
 dpkg was buggy and never performed dependency satisfiability checks
 when trying to process triggers. This was fixed in dpkg 1.17.17.

Well we didn't have any issue here either :/
http://buildbot.fusionforge.org/job/fusionforge-53-functests-deb/os=debian8/33/consoleFull

However I can reproduce the problem by upgrading/downgrading mediawiki.
How exactly did you trigger this bug? ;)

-- 
Sylvain


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

Bug#773210: unblock: fusionforge/5.3.2+20141104-3

[beuc]

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

Please unblock package fusionforge which fixes RC #772870.

Interdiff:
diff -u fusionforge-5.3.2+20141104/debian/changelog 
fusionforge-5.3.2+20141104/debian/changelog
--- fusionforge-5.3.2+20141104/debian/changelog
+++ fusionforge-5.3.2+20141104/debian/changelog
@@ -1,3 +1,12 @@
+fusionforge (5.3.2+20141104-3) unstable; urgency=medium
+
+  * Support dpkg-1.17.17 and avoid a trigger loop by replacing 'interest'
+triggers by 'interest-noawait' ones (closes: #772870)
+  * Do bump Standards-Version to 3.9.6 by regenerating debian/control (no
+changes)
+
+ -- Sylvain Beucler b...@debian.org  Mon, 15 Dec 2014 11:46:30 +0100
+
 fusionforge (5.3.2+20141104-2) unstable; urgency=medium
 
   * Start Debian-specific branch without important bugfixes (cf. #771944)
diff -u fusionforge-5.3.2+20141104/debian/control 
fusionforge-5.3.2+20141104/debian/control
--- fusionforge-5.3.2+20141104/debian/control
+++ fusionforge-5.3.2+20141104/debian/control
@@ -5,7 +5,7 @@
 Uploaders: Christian Bayle ba...@debian.org, Olivier Berger 
ober...@debian.org, Sylvain Beucler b...@debian.org
 Build-Depends-Indep: sharutils, docbook-to-man, devscripts, gettext, isoquery, 
iso-codes
 Build-Depends: debhelper (= 7.0.50~), quilt (= 0.40), perl, confget, 
moreutils
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
 Homepage: https://fusionforge.org/
 Vcs-Git: https://fusionforge.org/anonscm/git/deb-packaging/deb-packaging.git
 Vcs-Browser: https://fusionforge.org/scm/browser.php?group_id=9
only in patch2:
unchanged:
--- 
fusionforge-5.3.2+20141104.orig/plugins/mediawiki/packaging/triggers/plugin-mediawiki
+++ 
fusionforge-5.3.2+20141104/plugins/mediawiki/packaging/triggers/plugin-mediawiki
@@ -1,3 +1,3 @@
 # Triggers for @PACKAGE@-plugin-mediawiki
-interest /usr/share/mediawiki
-interest /usr/share/mediawiki-extensions
+interest-noawait /usr/share/mediawiki
+interest-noawait /usr/share/mediawiki-extensions


unblock fusionforge/5.3.2+20141104-3

Cheers!
Sylvain


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

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[beuc]

On Mon, Dec 15, 2014 at 05:12:08PM +0100, Guillem Jover wrote:
 On Mon, 2014-12-15 at 14:00:36 +0100, b...@debian.org wrote:
  So far my tests show that 'apt-get upgrade' doesn't start the noawait
  triggers.  The fusionforge-plugin-mediawiki is marked
  'triggers-pending' but apparently the user has to do something more
  manually, which is not satisfying.
  Any suggestion?
 
 I don't understand the problem, can you expand? Or is this simply a
 problem of using dpkg from testing, if so, please just test with sid.

Well when a dpkg fix is on the way, make sure to mention it clearly :)
   dpkg was buggy and never performed dependency satisfiability checks
   when trying to process triggers. This was fixed in dpkg 1.17.17.

Also I suppose using 'triggers-pending' won't work correctly in Debian 7?

-- 
Sylvain


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

Bug#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[beuc]

On Mon, Dec 15, 2014 at 05:40:35PM +0100, Thorsten Glaser wrote:
 On Mon, 15 Dec 2014, b...@debian.org wrote:
 
  Also I suppose using 'triggers-pending' won't work correctly in Debian 7?
 
 What is “triggers-pending”?

I meant:
  Also I suppose using 'interest-nowait' will also not be triggered
   on 'apt-get upgrade' in Debian 7?,
sorry.

-- 
Sylvain


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

Bug#773246: hydrogen-drumkits: DFSG-ness of the drumkits

[beuc]

Package: hydrogen-drumkits
Version: 0.9.3.20070703-3
Severity: normal

Hi,

I can't find information about the licensing of the
drumkits. 'debian/copyright' says it's BSD-licensed, but the upstream
tarball doesn't contain licensing information ; the original upstream
URL now redirects to Hydrogen's homepage, and I can't find the
individual drumkits in upstream's sourceforge download area.

Chief concern is the presence of Roland and Yamaha drumkits which
according to their drumkit.xml files are direct recordings of
individual samples straight from the equipment -- which sounds pretty
risky to use in a DFSG environment, unless that's explicitely
permitted by the manufacturer.

Do you have more copyright and licensing information about these
drumkits?

Cheers!
Sylvain

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

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

hydrogen-drumkits depends on no packages.

hydrogen-drumkits recommends no packages.

Versions of packages hydrogen-drumkits suggests:
ii  hydrogen  0.9.6.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#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing

[beuc]

On Fri, Dec 12, 2014 at 05:29:17PM +0100, Guillem Jover wrote:
 On Fri, 2014-12-12 at 11:30:59 +0100, Thorsten Glaser wrote:
  On Thu, 11 Dec 2014, Guillem Jover wrote:
   This package can get involved in a trigger cycle. The problem is that
   it installs interests on /usr/share/mediawiki with files there
   provided by mediawiki and mediawiki-classes, which are directly or
   transitively depended on byfusionforge-plugin-mediawiki itself.
  
  Can you please explain how/why this can make trigger cycles?
 
 Sure. The fusionforge-plugin-mediawiki package is interested in a path,
 that path is provided by say mediawiki, when installing mediawiki,
 that package gets placed in triggers-awaited state (which does not
 satisfy dependencies), and because to process the pending triggers in
 fusionforge-plugin-mediawiki all dependencies need to be satisfied
 dpkg cannot progress, and thus the trigger cycle. Hope that clarifies.

There's one point I'd like to clarify: how comes we never had any
issues with this?

E.g. I don't see any warning here:
http://buildbot.fusionforge.org/job/fusionforge-53-functests-deb/os=debian7/33/consoleFull

-- 
Sylvain


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

Bug#772556: unblock: fusionforge/5.3.2+20141104-2

[beuc]

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

Please unblock package fusionforge which fixes RC #771619.

Attached:
- debdiff
- diff

fusionforge (5.3.2+20141104-2) unstable; urgency=medium

  * Start Debian-specific branch without important bugfixes (cf. #771944)
  * Use Debian-specific 'invoke-rc.d' instead of portable 'service'
(closes: #771619)
  * Really bump Standards-Version to 3.9.6 (no changes)

 -- Sylvain Beucler b...@debian.org  Mon, 08 Dec 2014 12:18:07 +0100

unblock fusionforge/5.3.2+20141104-2

Cheers!
Sylvain
diff -u fusionforge-5.3.2+20141104/debian/changelog 
fusionforge-5.3.2+20141104/debian/changelog
--- fusionforge-5.3.2+20141104/debian/changelog
+++ fusionforge-5.3.2+20141104/debian/changelog
@@ -1,3 +1,12 @@
+fusionforge (5.3.2+20141104-2) unstable; urgency=medium
+
+  * Start Debian-specific branch without important bugfixes (cf. #771944)
+  * Use Debian-specific 'invoke-rc.d' instead of portable 'service'
+(closes: #771619)
+  * Really bump Standards-Version to 3.9.6 (no changes)
+
+ -- Sylvain Beucler b...@debian.org  Mon, 08 Dec 2014 12:18:07 +0100
+
 fusionforge (5.3.2+20141104-1) unstable; urgency=medium
 
   * New upstream snapshot following the 5.3 stable branch.
diff -u fusionforge-5.3.2+20141104/debian/dsf-in/plugin.postinst 
fusionforge-5.3.2+20141104/debian/dsf-in/plugin.postinst
--- fusionforge-5.3.2+20141104/debian/dsf-in/plugin.postinst
+++ fusionforge-5.3.2+20141104/debian/dsf-in/plugin.postinst
@@ -29,7 +29,7 @@
@BINARY_PATH@/upgrade-db.php @PLUGSHORTNAME@
# Restart apache if there is some change in config
if [ -f @CONFIG_PATH@/httpd.conf.d/plugin-@PLUGSHORTNAME@.inc ]; then
-   service apache2 reload
+   invoke-rc.d apache2 reload
fi
# Run plugin-specific install
if [ -f @PLUGINS_PATH@/@PLUGSHORTNAME@/bin/install.sh ]; then
only in patch2:
unchanged:
--- fusionforge-5.3.2+20141104.orig/packaging/control/000source
+++ fusionforge-5.3.2+20141104/packaging/control/000source
@@ -5,7 +5,7 @@
 Uploaders: Christian Bayle ba...@debian.org, Olivier Berger 
ober...@debian.org, Sylvain Beucler b...@debian.org
 Build-Depends-Indep: sharutils, docbook-to-man, devscripts, gettext, isoquery, 
iso-codes
 Build-Depends: debhelper (= 7.0.50~), quilt (= 0.40), perl, confget, 
moreutils
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
 Homepage: https://fusionforge.org/
 Vcs-Git: https://fusionforge.org/anonscm/git/deb-packaging/deb-packaging.git
 Vcs-Browser: https://fusionforge.org/scm/browser.php?group_id=9
File lists identical (after any substitutions)

Control files of package fusionforge-full: lines which differ (wdiff format)

Conflicts: gforge, gforge-common ( [-5.3.2+20141104-1),-] 
{+5.3.2+20141104-2),+} gforge-cvs, sourceforge
Depends: debconf (= 1.0.32) | debconf-2.0, ucf, gforge-common (= 
[-5.3.2+20141104-1),-] {+5.3.2+20141104-2),+} gforge-web-apache2 | gforge-web, 
gforge-web-apache2-vhosts, gforge-db-postgresql | gforge-db, gforge-mta-exim4 | 
gforge-mta, gforge-shell-postgresql | gforge-shell, gforge-lists-mailman | 
gforge-lists, fusionforge-plugin-contribtracker, fusionforge-plugin-headermenu, 
fusionforge-plugin-globalsearch, fusionforge-plugin-mediawiki, 
fusionforge-plugin-moinmoin, fusionforge-plugin-projectlabels, 
fusionforge-plugin-scmarch, fusionforge-plugin-scmbzr, 
fusionforge-plugin-scmcvs, fusionforge-plugin-scmdarcs, 
fusionforge-plugin-scmgit, fusionforge-plugin-scmhg, fusionforge-plugin-scmsvn, 
fusionforge-plugin-blocks, fusionforge-plugin-hudson, fusionforge-plugin-scmhook
Version: [-5.3.2+20141104-1-] {+5.3.2+20141104-2+}

Control files of package fusionforge-minimal: lines which differ (wdiff format)
---
Conflicts: gforge, gforge-common ( [-5.3.2+20141104-1),-] 
{+5.3.2+20141104-2),+} gforge-cvs, sourceforge
Depends: debconf (= 1.0.32) | debconf-2.0, ucf, gforge-common (= 
[-5.3.2+20141104-1),-] {+5.3.2+20141104-2),+} gforge-web-apache2 | gforge-web, 
gforge-db-postgresql | gforge-db
Version: [-5.3.2+20141104-1-] {+5.3.2+20141104-2+}

Control files of package fusionforge-plugin-admssw: lines which differ (wdiff 
format)
-
Version: [-5.3.2+20141104-1-] {+5.3.2+20141104-2+}

Control files of package fusionforge-plugin-authcas: lines which differ (wdiff 
format)
--
Version: [-5.3.2+20141104-1-] {+5.3.2+20141104-2+}

Control files of package fusionforge-plugin-authhttpd: lines which differ 
(wdiff format)

Installed-Size: [-127-] {+128+}
Version: [-5.3.2+20141104-1-] {+5.3.2+20141104-2+}

Control files of package 

Bug#771944: Following FusionForge 5.3 stable branch

[beuc]

Hi,

On Wed, Dec 03, 2014 at 11:03:59PM +, Jonathan Wiltshire wrote:
 On Wed, Dec 03, 2014 at 06:52:26PM +0100, b...@debian.org wrote:
  We're (upstream-ly) maintaining a stable branch for FusionForge,
  called 5.3, which the Debian package currently follows.
  (incidentally Lolando and I are both upstream and debian devs)
  
  We're currently pushing only bugfixes to this branch (some of them
  qualify as RC, some don't), because it's deployed at several large
  client installs already and we want to make sure we don't break
  anything.
  
  It makes sense that users benefit from the quality of this branch, so
  we'd like to know to what extent following this branch is compatible
  with the Freeze.
 
 The compatibility benchmark you need to meet is the freeze policy, which
 you can find at https://release.debian.org/jessie/freeze_policy.html.
 
 If there are exceptional circumstances it's worth asking on a case-by-case
 basis.

I already read the policy, and since it sounds sensible to follow the
upstream Stable branch for the debian Stable release, I'm asking.

So, I take it we need to maintain a branch off the upstream stable
branch, that will not include most user-related bugfixes (but include
the piupart-related nitpicks ;))?

(Btw, by all means I suggest you improve your communication. This
 no_greetings+RTFM answer you just gave is as close to my support
 team's initial auto-reply as one can be :/)

Cheers!
Sylvain


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

Bug#771619: fusionforge: plugin postinst script uses 'service' instead of invoke-rc.d

[beuc]

Hi,

I'm going to fix the bug but... by all means, can you postpone these
piuparts tests?  I appreciate the effort you put into this, but doing
them during the freeze make them very ill-suited for a proper
(upstream) fix, especially considering we revamped the buildinstall
system completely for the next version.  Also getting a RC bug with
copy/paste first thing on Monday morning, for something no human user
ever reported, just makes me want to stop my Debian packaging work.

Regards,
Sylvain


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

Bug#771944: Following FusionForge 5.3 stable branch

[beuc]

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

Hi,

We're (upstream-ly) maintaining a stable branch for FusionForge,
called 5.3, which the Debian package currently follows.
(incidentally Lolando and I are both upstream and debian devs)

We're currently pushing only bugfixes to this branch (some of them
qualify as RC, some don't), because it's deployed at several large
client installs already and we want to make sure we don't break
anything.

It makes sense that users benefit from the quality of this branch, so
we'd like to know to what extent following this branch is compatible
with the Freeze.

Cheers!
Sylvain


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

Bug#767541: jenkins: CVE-2014-3665

[beuc]

Hi from the Paris Bugs Squashing Party :)

In order to help people who participate, can you (jenkins' maintainer)
describe what you intend to do, and if help is possible?

From what I understand:
- The security ~fix is a new slave-master access control system
- Jenkins releases a LTS version every 3 months
- Debian currently doesn't ship the current LTS from last month, but
  the one before, which doesn't seem supported anymore.
- Options that I see are either pushing the current LTS in Debian,
  backporting the new access control system, or drop the package.

Let us know what is your suggested course of action.

Cheers!
Sylvain


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

Bug#750716: coffeescript: FTBFS against uglify 2.x series - Cannot call method 'parse' of undefined

[beuc]

Control: tag -1 +patch 

Hi from the Paris Bugs Squashing Party :)

It seems that the current code relies on functions not available in
Uglify anymore:

$ grep -ir ast_mangle /usr/lib/nodejs/uglify-js/
$ grep -ir ast_squeeze /usr/lib/nodejs/uglify-js/

So probably the package.json is incorrect.


The attached attached patch appears to work, I just followed
https://github.com/mishoo/UglifyJS2#the-simple-way


Cheers!
Sylvain
Index: coffeescript-1.4.0/Cakefile
===
--- coffeescript-1.4.0.orig/Cakefile
+++ coffeescript-1.4.0/Cakefile
@@ -125,8 +125,9 @@ task 'build:browser', 'rebuild the merge
 }(this));
   
   unless process.env.MINIFY is 'false'
-{parser, uglify} = require 'uglify-js'
-code = uglify.gen_code uglify.ast_squeeze uglify.ast_mangle parser.parse code
+uglify = require 'uglify-js'
+result = uglify.minify(code, {fromString: true});
+code = result.code
   fs.writeFileSync 'extras/coffee-script.js', header + '\n' + code
 
 

Bug#767892: subtitleeditor: Cannot type or edit subtitles

[beuc]

Great.
Btw you can ping me if you need an upload.

- Sylvain

On Tue, Nov 11, 2014 at 08:50:28AM +0100, Philip Rinn wrote:
 Hi,
 
 I uploaded the fixed version to m.d.n:
 
 http://mentors.debian.net/package/subtitleeditor
 
 I'll bother my sponsor now ;)
 
 Best,
 Philip


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

Bug#768460: unblock: fusionforge/5.3.2+20141104-1

[beuc]

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

Please unblock package fusionforge,

The new upload follows the upstream stable branch which only contain
bugfixes, notably 4 RC #767931, #754791, #767688, #767683.

Attached:
- debdiff
- diff

fusionforge (5.3.2+20141104-1) unstable; urgency=medium

  * New upstream snapshot following the 5.3 stable branch.
  (closes: #767931, #754791, #767688, #736157, #637217)
  (closes: #674567, #675042, #744202, #597610)
  * Bump Standards-Version to 3.9.6 (no changes)
  * Remove reference to README.Custom (closes: #599289)

 -- Sylvain Beucler b...@debian.org  Tue, 04 Nov 2014 11:44:47 +0100

unblock fusionforge/5.3.2+20141104-1

Cheers!
Sylvain


debdiff.gz
Description: Binary data


diff.gz
Description: Binary data

Bug#767892: subtitleeditor: Cannot type or edit subtitles

[beuc]

Package: subtitleeditor
Version: 0.33.0-2
Severity: important

Hi,

When creating a new project, or editing existing subtitles, it's not
possible to type or edit the subtitles.
The text field doesn't appear, and the console says:


(subtitleeditor:3230): GLib-GObject-WARNING **: When installing property: type 
'gtkmm__CustomObject_12TextViewCell' already has a property named 
'editing-canceled'

(subtitleeditor:3230): GLib-GObject-WARNING **: attempting to add an interface 
(GtkCellEditable) to class (gtkmm__CustomObject_12TextViewCell) after class_init

(subtitleeditor:3230): GLib-GObject-WARNING **: 
/build/glib2.0-dt6trg/glib2.0-2.42.0/./gobject/gsignal.c:2461: signal 
'editing_done' is invalid for instance '0x16d4930' of type 
'gtkmm__CustomObject_12TextViewCell'

(subtitleeditor:3230): GLib-GObject-WARNING **: 
/build/glib2.0-dt6trg/glib2.0-2.42.0/./gobject/gsignal.c:2461: signal 
'remove_widget' is invalid for instance '0x16d4930' of type 
'gtkmm__CustomObject_12TextViewCell'

(subtitleeditor:3230): Gtk-CRITICAL **: 
gtk_tree_view_column_cell_process_action: assertion 'GTK_IS_CELL_EDITABLE 
(*editable_widget)' failed


So subtitleeditor is not usable in the current state :/

Cheers!
Sylvain


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

Kernel: Linux 3.16-2-amd64 (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/dash

Versions of packages subtitleeditor depends on:
ii  gstreamer0.10-plugins-base   0.10.36-2
ii  gstreamer0.10-plugins-good   0.10.31-3+nmu4+b1
ii  gstreamer0.10-x  0.10.36-2
ii  libatkmm-1.6-1   2.22.7-2.1
ii  libc62.19-11
ii  libcairomm-1.0-1 1.10.0-1.1
ii  libenchant1c2a   1.6.0-10.1
ii  libgcc1  1:4.9.1-16
ii  libglademm-2.4-1c2a  2.6.7-4
ii  libglib2.0-0 2.42.0-2
ii  libglibmm-2.4-1c2a   2.42.0-1
ii  libgstreamer-plugins-base0.10-0  0.10.36-2
ii  libgstreamer0.10-0   0.10.36-1.4
ii  libgtk2.0-0  2.24.25-1
ii  libgtkmm-2.4-1c2a1:2.24.4-1.1
ii  libpangomm-1.4-1 2.34.0-1.1
ii  libsigc++-2.0-0c2a   2.4.0-1
ii  libstdc++6   4.9.1-16
ii  libsubtitleeditor0   0.33.0-2

subtitleeditor recommends no packages.

Versions of packages subtitleeditor suggests:
pn  gstreamer0.10-ffmpeg  none

-- 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#759725: closed by Christoph Berg m...@debian.org (Bug#759725: fixed in postgresql-common 162)

[beuc]

 51340 
 postgresql_9.4+162_all.deb
  58c7da68cf06e36cdd98442a937c671278d5f6f8cdd24a062c2b80a05966f315 51360 
 postgresql-client_9.4+162_all.deb
  3f2078e2beeb6d8ad9155415772fd650a85852a502cc3a8d9e360bcbcbc3b089 51350 
 postgresql-doc_9.4+162_all.deb
  3234f193a5a1645c56f860776a1ab9420d0e0eff932864ad93776d1bcf60db63 51348 
 postgresql-contrib_9.4+162_all.deb
  aac562a550a831661d477b20cbe43510fadb699fdcc330a50b6ca71e510ddbb6 200776 
 postgresql-common_162_all.deb
  fd0ec54bdab7318795134ec98bba6127c656fe38efefe3d8a52f1241e203a79b 72972 
 postgresql-client-common_162_all.deb
 Files:
  abfe957bd81f3d68aec0205233ff609e 58446 database optional 
 postgresql-server-dev-all_162_all.deb
  9c3efc223baa8258cad326470d523b74 51340 database optional 
 postgresql_9.4+162_all.deb
  d5bc60b95fbee06b77f930ce66425ec9 51360 database optional 
 postgresql-client_9.4+162_all.deb
  5b651fecba32a54ab5b316a168f72b66 51350 doc optional 
 postgresql-doc_9.4+162_all.deb
  fc840fdb116d0081c38d157e85d8f073 51348 database optional 
 postgresql-contrib_9.4+162_all.deb
  3d6c3f20e3e1a91bfb2ad1ad3461f617 200776 database optional 
 postgresql-common_162_all.deb
  bdd30524c1444521f3eb9db7823153cd 72972 database optional 
 postgresql-client-common_162_all.deb
  62e59e4d5652fe62dd9b836d0e78c901 2240 database optional 
 postgresql-common_162.dsc
  9c6f016609e8a4f74228b3f024d7f5c2 186148 database optional 
 postgresql-common_162.tar.xz
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 
 iQIcBAEBCAAGBQJUND53AAoJEExaa6sS0qeudI4P/26SGgCyyzCpp9td6F2hlLwF
 /pNLvS87A0fNlKz6GzRbd9osKxLe9SWteZwKdgjYtUzeCvr8awQLrLNdpLtzg6ru
 VJZWyiA/ixX8KEIXL1Ze5EfnDCdxyS5keTmzZG/mmoyzH4qeAeTMcLYQc38r4w2o
 VXB6wgizt4Ua4mzKLOU7OlhfwfAY9e5VQjEDoYpsJ24Xdt8kLTD8tXkn1HgeajO7
 GCKrU0YLkd9Q2aj9B1+qtMYwTf7PLqH1Lzu+Fwg+2mee14bo22cMecROmSKV7yFp
 BtlNCEtBV1z1AHHrK0kzwzsME4BzKbXNxKoSA35YWzll/DOIeO3uUMDitHVIK/AL
 pyK7pMyeUkdyHHKFJ+YriUelX3Q1yMePxZqp6O541LkWje5aA/8ZTZjyLGbHhQ/5
 /w4cJVHAO3rG4hByc6pAXCrtJOjNFYGewHb+oc8mTdbEHRbPK+aRgC2ugDN8+JKA
 xNVTfykF/0vdPH6+Qsm0deQDgHuHkx58jawivjaSuoVKsCKCmKjGH46CzuLfqfkK
 +Upr8oX0lCJFfgGapVKySjk31BRAFmGicnTzYCSzWwXFOkaoTQydzUJ4gYug5pfK
 mQGGLz3J9RiSJaAyF5BOAfespx9PnAz2H24gb7iPazfzxWm31WIz+mzt00F09UCg
 ukCm6ezkAR8adS0f/lqH
 =vmXR
 -END PGP SIGNATURE-

 Date: Fri, 29 Aug 2014 20:28:50 +0200
 From: beuc b...@debian.org
 To: Debian Bug Tracking System sub...@bugs.debian.org
 Subject: postgresql-common: non-synchronous service postgresql
  start/stop/reload
 X-Mailer: reportbug 6.5.0
 
 Package: postgresql-common
 Version: 160
 Severity: important
 
 Hi,
 
 When working on the FusionForge installation system today I noticed
 that in Debian Jessie, running:
 
   service postgresql start
 
 (or stop, or reload), is now asynchronous, due to using the new
 PostgreSQL systemd init scripts.
 
 Previously I could rely on the init script to come back when the
 database was properly stopped and flushed.  Right now the command
 returns immediately and starts/stops/reloads in the background.
 
 My scripts need to modify the PostgreSQL listen address and reload it
 before populating the database through the PHP application.  They also
 need to stop/backup/start the server for quick load/restore during our
 testsuite.  Due to this change the installation system fails randomly
 due to race condition.
 
 I found it basically impossible to work-around this issue in a
 portable manner:
 
 - 'service postgresql status' is not reliable: it usually says the
   service is stopped far before the shutdown is complete. I also got a
   few cases where it reported active service with no running daemon.
 
 - the 'postgresql' process may be stopped already, but pg_ctl still
   doing a faststop (especially when there's data to flush to disk) -
   there may also be other PostgreSQL processes I don't know about;
   so 'ps' is not reliable either.
 
 - the postgresql control commands vary between Debian and RedHat
   (pg_ctl vs. pg_clusterctl), and they need a data directory that can
   be in varied, possibly multiple, locations. Using 'pg_*ctl' manually
   is error-prone and long.
 
 - in any case that will require fare more code and testing than
   'service postgresql xxx'
 
 Please consider maintaining 'service postgresql start/stop/reload'
 synchronous even with systemd.
 
 Cheers!
 Sylvain
 
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers testing-updates
   APT policy: (500, 'testing-updates'), (500, 'testing')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386
 
 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
 Locale: LANG=eo.UTF-8, LC_CTYPE=eo.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages postgresql-common depends on:
 ii  adduser   3.113+nmu3
 ii  debconf [debconf-2.0] 1.5.53
 ii  init-system-helpers   1.21
 ii  lsb-base  4.1+Debian13
 ii  postgresql-client-common  160
 ii  procps1:3.3.9-7
 ii  ssl-cert  1.0.34
 ii  ucf

Bug#762162: gdb output (2)

[beuc]

Same issue here since I made a dist-upgrade yesterday.

Geeqie crashed on start-up with previous configuration files.  After
removing them (and the cache for good measure), it now crashes as soon
as you load an image.

Run this in a directory containing a picture:

$ gdb -batch -n -ex run -ex bt -ex 'thread apply all bt full' --args geeqie
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Creating Geeqie dir:/home/personnel/.config/geeqie
Creating Geeqie dir:/home/personnel/.cache/geeqie/thumbnails
[New Thread 0x7fffebaa0700 (LWP 10436)]
[New Thread 0x7fffeb08f700 (LWP 10437)]

Program received signal SIGSEGV, Segmentation fault.
append_escaped_text (length=optimized out, text=optimized out, 
str=0xa34ba0) at /build/glib2.0-tWPgvS/glib2.0-2.40.0/./glib/gmarkup.c:2162
2162/build/glib2.0-tWPgvS/glib2.0-2.40.0/./glib/gmarkup.c: No 
such file or directory.
#0  append_escaped_text (length=optimized out, text=optimized out, 
str=0xa34ba0) at /build/glib2.0-tWPgvS/glib2.0-2.40.0/./glib/gmarkup.c:2162
#1  g_markup_escape_text (text=optimized out, length=optimized out, 
length@entry=-1) at /build/glib2.0-tWPgvS/glib2.0-2.40.0/./glib/gmarkup.c:2238
#2  0x779e0317 in gtk_widget_set_property (object=0x91ced0, 
prop_id=optimized out, value=0x7fffd120, pspec=optimized out) at 
/build/gtk+2.0-zztKf7/gtk+2.0-2.24.24/gtk/gtkwidget.c:2739
#3  0x761690a1 in object_set_property (nqueue=optimized out, 
value=optimized out, pspec=optimized out, object=optimized out) at 
/build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gobject.c:1378
#4  g_object_set_valist (object=0x91ced0, first_property_name=0x76e190 
\340\206u, var_args=0x7fffd1d0) at 
/build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gobject.c:2104
#5  0x76169934 in g_object_set (_object=0x91ced0, 
first_property_name=0x77a5be06 tooltip-text) at 
/build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gobject.c:2214
#6  0x7798b52d in gtk_tool_button_update (activatable=0x77aab0, 
action=0x801e30, property_name=0x77af5c4c tooltip) at 
/build/gtk+2.0-zztKf7/gtk+2.0-2.24.24/gtk/gtktoolbutton.c:821
#7  0x779830c7 in gtk_toggle_tool_button_update (activatable=0x77aab0, 
action=0x801e30, property_name=0x77af5c4c tooltip) at 
/build/gtk+2.0-zztKf7/gtk+2.0-2.24.24/gtk/gtktoggletoolbutton.c:329
#8  0x76161415 in g_closure_invoke (closure=0x91e7a0, return_value=0x0, 
n_param_values=2, param_values=0x7fffd4d0, invocation_hint=0x7fffd470) 
at /build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gclosure.c:768
#9  0x761739dc in signal_emit_unlocked_R (node=node@entry=0x757280, 
detail=detail@entry=578, instance=instance@entry=0x801e30, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffd4d0) at 
/build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gsignal.c:3551
#10 0x7617c208 in g_signal_emit_valist (instance=optimized out, 
signal_id=optimized out, detail=optimized out, 
var_args=var_args@entry=0x7fffd660) at 
/build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gsignal.c:3307
#11 0x7617c46f in g_signal_emit (instance=optimized out, 
signal_id=optimized out, detail=optimized out) at 
/build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gsignal.c:3363
#12 0x76165b35 in g_object_dispatch_properties_changed 
(object=0x7fffea641010, n_pspecs=1, pspecs=0x0) at 
/build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gobject.c:1053
#13 0x761653ae in g_object_notify_queue_thaw (object=0x801e30, 
nqueue=optimized out) at 
/build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gobject.c:290
#14 0x76169105 in g_object_set_valist (object=0x801e30, 
first_property_name=0x0, var_args=0x7fffd930) at 
/build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gobject.c:2110
#15 0x76169934 in g_object_set (_object=0x801e30, 
first_property_name=first_property_name@entry=0x4e399a tooltip) at 
/build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gobject.c:2214
#16 0x00474382 in layout_util_sync_color (lw=0x78a580) at 
layout_util.c:2292
#17 0x0046865f in layout_status_update_image (lw=0x78a580) at 
layout.c:530
#18 0x0045cbf3 in image_update_util (imd=optimized out) at image.c:91
#19 image_post_process_color (start_row=optimized out, run_in_bg=optimized 
out, imd=optimized out) at image.c:350
#20 image_change_pixbuf (imd=0x885200, pixbuf=0x967820, 
zoom=5.411089589487498e-312, zoom@entry=0, lazy=10234784) at image.c:1107
#21 0x0045d8b3 in image_load_area_cb (il=optimized out, x=0, y=0, 
w=optimized out, h=optimized out, data=optimized out) at image.c:607
#22 0x76161415 in g_closure_invoke (closure=0x9c45a0, return_value=0x0, 
n_param_values=5, param_values=0x7fffdd80, invocation_hint=0x7fffdd20) 
at /build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gclosure.c:768
#23 0x761739dc in signal_emit_unlocked_R (node=node@entry=0x756dd0, 

Bug#762079: apt: Hash Sum mismatch while sum checks since security update

[beuc]

Package: apt
Version: 0.9.7.9+deb7u3
Severity: important

Dear Maintainer,

I seems something is wrong with the new apt update and sum checks:

root@xxx:~# apt-get update
Get:1 file: local/ Release.gpg [287 B]
Hit http://security.debian.org wheezy/updates Release.gpg   

Get:2 file: local/ Release [1,471 B]
Hit http://security.debian.org wheezy/updates Release 
Hit http://ftp.debian.org wheezy Release.gpg  
Ign file: local/ Translation-en_US
Ign file: local/ Translation-en
Hit http://security.debian.org wheezy/updates/main Sources
Hit http://security.debian.org wheezy/updates/contrib Sources   
Hit http://ftp.debian.org wheezy Release
Hit http://security.debian.org wheezy/updates/main amd64 Packages
Hit http://security.debian.org wheezy/updates/contrib amd64 Packages
Hit http://ftp.debian.org wheezy/main Sources   
Hit http://security.debian.org wheezy/updates/contrib Translation-en
Hit http://security.debian.org wheezy/updates/main Translation-en 
Hit http://ftp.debian.org wheezy/contrib Sources  
Hit http://ftp.debian.org wheezy/main amd64 Packages
Hit http://ftp.debian.org wheezy/contrib amd64 Packages
Hit http://ftp.debian.org wheezy/contrib Translation-en
Hit http://ftp.debian.org wheezy/main Translation-en
W: Failed to fetch file:/usr/src/debian-repository/local/Packages  Hash Sum 
mismatch

E: Some index files failed to download. They have been ignored, or old ones 
used instead.


root@xxx:~# cat /usr/src/debian-repository/local/Release
Origin: root
Label: root
Suite: local
Codename: local
Date: Wed, 17 Sep 2014 15:53:51 UTC
Architectures: all i386
MD5Sum:
 8e878e4ff6933df115026949de317553   75827 Packages
 4539db44508cb66e34b59516519e1516   16753 Packages.gz
 b54ee5c8994ad13c8e538bad87fcb334   15236 Packages.bz2
 b823c7a2ec075192b82dd8b30917bb545114 Sources
 9ac6e47c74527fde317c72fd9e7f67df1511 Sources.gz
 d5ecdab0fc193a0b6d3f0bb4f2ce587a1599 Sources.bz2
SHA1:
 b7d698856537d0d48cc0adfa91e2b7c3c3de21a9   75827 Packages
 08660371326be41b9109c1fec749f29c9472a071   16753 Packages.gz
 c6c48bcf903f931e48010ef698e400021870014c   15236 Packages.bz2
 c53c66bca6443739352767c6b48dc1a60e4c506b5114 Sources
 eb7aff7b0da1e2f884bad478cbcf0cd9158024221511 Sources.gz
 eabaaa0ae948e10e4bc8a116ac4673137f17783f1599 Sources.bz2
SHA256:
 25ce372e36b9e923562e57f14af9bfccb89d8876eff61e74679b1376966f81b2   
75827 Packages
 cbedb4a366c27d8dfc6f840c58a788d170f1aed8591436de466604b9aca25fc8   
16753 Packages.gz
 4504e5e72afa28586425046185f21d0f0afacc9f05827fe0befafcc1c6506c4d   
15236 Packages.bz2
 046c1502172ffaa972e0ccfa5b5f30bdb33960b5fab76814f2c73973e020e721
5114 Sources
 41bf248d8c2ce060e61529f6f130a588a1032b0ea813879565b799a75b5aff1a
1511 Sources.gz
 690a70a052f38de0608fe3dde97d59a9448748b9b61c2f3af9fe9e966b04bdc0
1599 Sources.bz2


root@xxx:~# md5sum 
/usr/src/debian-repository/local/{Packages,Packages.gz,Packages.bz2,Sources,Sources.gz,Sources.bz2}
8e878e4ff6933df115026949de317553  /usr/src/debian-repository/local/Packages
4539db44508cb66e34b59516519e1516  /usr/src/debian-repository/local/Packages.gz
b54ee5c8994ad13c8e538bad87fcb334  /usr/src/debian-repository/local/Packages.bz2
b823c7a2ec075192b82dd8b30917bb54  /usr/src/debian-repository/local/Sources
9ac6e47c74527fde317c72fd9e7f67df  /usr/src/debian-repository/local/Sources.gz
d5ecdab0fc193a0b6d3f0bb4f2ce587a  /usr/src/debian-repository/local/Sources.bz2

root@xxx:~# sha1sum 
/usr/src/debian-repository/local/{Packages,Packages.gz,Packages.bz2,Sources,Sources.gz,Sources.bz2}
b7d698856537d0d48cc0adfa91e2b7c3c3de21a9  
/usr/src/debian-repository/local/Packages
08660371326be41b9109c1fec749f29c9472a071  
/usr/src/debian-repository/local/Packages.gz
c6c48bcf903f931e48010ef698e400021870014c  
/usr/src/debian-repository/local/Packages.bz2
c53c66bca6443739352767c6b48dc1a60e4c506b  
/usr/src/debian-repository/local/Sources
eb7aff7b0da1e2f884bad478cbcf0cd915802422  
/usr/src/debian-repository/local/Sources.gz
eabaaa0ae948e10e4bc8a116ac4673137f17783f  
/usr/src/debian-repository/local/Sources.bz2

root@xxx:~# sha256sum 
/usr/src/debian-repository/local/{Packages,Packages.gz,Packages.bz2,Sources,Sources.gz,Sources.bz2}
25ce372e36b9e923562e57f14af9bfccb89d8876eff61e74679b1376966f81b2  
/usr/src/debian-repository/local/Packages
cbedb4a366c27d8dfc6f840c58a788d170f1aed8591436de466604b9aca25fc8  
/usr/src/debian-repository/local/Packages.gz
4504e5e72afa28586425046185f21d0f0afacc9f05827fe0befafcc1c6506c4d  
/usr/src/debian-repository/local/Packages.bz2
046c1502172ffaa972e0ccfa5b5f30bdb33960b5fab76814f2c73973e020e721  
/usr/src/debian-repository/local/Sources

Bug#762079: apt: Hash Sum mismatch while sum checks since security update

[beuc]

Hi Michael,

On Thu, Sep 18, 2014 at 11:25:40AM +0200, Michael Vogt wrote:
 On Thu, Sep 18, 2014 at 10:26:41AM +0200, b...@debian.org wrote:
  Package: apt
  Version: 0.9.7.9+deb7u3
  Severity: important
 
 Thanks for your bugreport.
 
 [..] 
  W: Failed to fetch file:/usr/src/debian-repository/local/Packages  Hash Sum 
  mismatch
  
  E: Some index files failed to download. They have been ignored, or old ones 
  used instead.
 [..]
  Interestingly, right after building the local packages, my autobuild
  script issue a 'apt-get update' that completes successfully.  But when
  I issue another 'apt-get update' even one second later I get the above
  behavior.  Regenerating the packages produced the same behavior.
 
  
  But everything checks! What's wrong?
 
 There is a regression in the recent security update that causes
 file:/// uris that are on a different partition (or nfs) than the apt
 lists dir to misbehave. The fix is commited as 
 http://anonscm.debian.org/cgit/apt/apt.git/commit/?h=debian/wheezyid=3fa61cd604da1a4d744cebf3fbb747bf7c80bf91
 
 and we will upload fixed packages shortly. If you could test the fix
 that would be much appreciated.
 
 Sorry for the trouble,

Thanks for the fast answer.
The repository is indeed located on an NFS share.

I confirm that recompiling from the debian/wheezy branch fixes the
issue.

Cheers!
Sylvain


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

Bug#759725: postgresql-common: non-synchronous service postgresql start/stop/reload

[beuc]

Hi,

I also got an issue today where PostgreSQL failed to load, but systemd
didn't realize it and marked the service status as active even
though there was no postgresql process.

This was difficult to diagnose (service is said to be up and running,
so why can't I connect!?).

Cheers!
Sylvain

On Mon, Sep 08, 2014 at 08:22:49PM +0200, b...@debian.org wrote:
 Hi Christoph,
 
 Can you share a bit your motivations for decreasing the severity of
 this bug?
 
 I don't think FusionForge is the only package that will be kicked in
 the balls when installed on a brand new, systemd-enabled Debian 8
 box next year :(
 
 Is that asynchronous behavior Debian-specific?


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

Bug#759725: Acknowledgement (postgresql-common: non-synchronous service postgresql start/stop/reload)

[beuc]

Hi Christoph,

Can you share a bit your motivations for decreasing the severity of
this bug?

I don't think FusionForge is the only package that will be kicked in
the balls when installed on a brand new, systemd-enabled Debian 8
box next year :(

Is that asynchronous behavior Debian-specific?

Cheers!
Sylvain


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

Bug#759725: postgresql-common: non-synchronous service postgresql start/stop/reload

[beuc]

Package: postgresql-common
Version: 160
Severity: important

Hi,

When working on the FusionForge installation system today I noticed
that in Debian Jessie, running:

  service postgresql start

(or stop, or reload), is now asynchronous, due to using the new
PostgreSQL systemd init scripts.

Previously I could rely on the init script to come back when the
database was properly stopped and flushed.  Right now the command
returns immediately and starts/stops/reloads in the background.

My scripts need to modify the PostgreSQL listen address and reload it
before populating the database through the PHP application.  They also
need to stop/backup/start the server for quick load/restore during our
testsuite.  Due to this change the installation system fails randomly
due to race condition.

I found it basically impossible to work-around this issue in a
portable manner:

- 'service postgresql status' is not reliable: it usually says the
  service is stopped far before the shutdown is complete. I also got a
  few cases where it reported active service with no running daemon.

- the 'postgresql' process may be stopped already, but pg_ctl still
  doing a faststop (especially when there's data to flush to disk) -
  there may also be other PostgreSQL processes I don't know about;
  so 'ps' is not reliable either.

- the postgresql control commands vary between Debian and RedHat
  (pg_ctl vs. pg_clusterctl), and they need a data directory that can
  be in varied, possibly multiple, locations. Using 'pg_*ctl' manually
  is error-prone and long.

- in any case that will require fare more code and testing than
  'service postgresql xxx'

Please consider maintaining 'service postgresql start/stop/reload'
synchronous even with systemd.

Cheers!
Sylvain


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

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

Versions of packages postgresql-common depends on:
ii  adduser   3.113+nmu3
ii  debconf [debconf-2.0] 1.5.53
ii  init-system-helpers   1.21
ii  lsb-base  4.1+Debian13
ii  postgresql-client-common  160
ii  procps1:3.3.9-7
ii  ssl-cert  1.0.34
ii  ucf   3.0030

Versions of packages postgresql-common recommends:
ii  logrotate  3.8.7-1

postgresql-common suggests no packages.

-- debconf information excluded


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

Bug#666236: gforge-web-apache2: fails to install: manage-apache-config.sh: line 75: [: too many arguments

[beuc]

Control: severity -1 important
Thanks

 severity 666236 serious
 # justification: https://release.debian.org/jessie/rc_policy.txt - 5a

https://release.debian.org/jessie/rc_policy.txt
 5. General
   (a) Supportable
   Packages in the archive must not be so buggy or out of date that we
   refuse to support them.

There is a circular dependency in raising the bug severity on the
basis that the bug should not have a high severity :)

Cheers!
Sylvain


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

Bug#750001: freedink-dfarc: Updated patch

[beuc]

Hi,

Thanks for your patch, but how is a patch modifying generated files
suitable for upstream?

I'm still interested in a status update on the Python and wxGlade
wxWidgets3 transition.  That's where work is needed IMHO and where I
could give a hand if necessary.

Cheers!
Sylvain

On Sat, Jun 28, 2014 at 06:01:12PM +1200, Olly Betts wrote:
 tags 750001 + patch
 thanks
 
 Thanks for your feedback.  I've updated the patch to just define
 wxTHICK_BORDER as wx2.8 does, so it should work fine with wxGlade.


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

Bug#750001: freedink-dfarc: Please update to wxwidgets3.0

[beuc]

Control: severy 750001 normal
thanks

Hi,

wxGlade does not support wxWidgets 3 because upstream says so:
https://bitbucket.org/agriggio/wxglade/commits/acbfabfba67bc795a6ccecaabda933ecb0d0f63d#chg-wxglade.py

For instance it adds wxTHICK_FRAME by itself, in the .wxg and the
generated .cpp.

Can you add to your list the packages that depend on wxPython
(apt-rdepends counts 70) to get a clearer understanding of the
situation.  Please don't change the severity of this bug until then.
You'll get a bug dependency on wxglade, I'll be able to depend on it.

Good news about MXE.

I think you don't have to worry about bugs on 2.8 - if upstream
doesn't want to fix bugs, you could recommend (not enforce) impacted
people to upgrade?

- Sylvain

On Thu, Jun 26, 2014 at 02:12:47AM +0100, Olly Betts wrote:
 # blocks the on-going wxwidgets3.0 transition
 severity 750001 serious
 thanks
 
 On Sat, May 31, 2014 at 04:23:12PM +0200, b...@debian.org wrote:
  I (as upstream) do not wish to update to wxWidgets2.8 yet because
  wxGlade (used to generate the *_Base.cpp files) doesn't support it,
  and because MXE (for the Windows cross-build) doesn't seem to either
  (though it builds 2.9 already).
 
 In what way does wxGlade not handle the patched code?  The changes
 I made in that area were just updating things which were deprecated in
 2.8 and have been removed in 3.0; if wxGlade doesn't handle them, it's
 likely broken for wx2.8 too.
 
 As upstream, you don't have to drop wx2.8 support to add wx3.0 support
 (the patch I sent should work with both), but FWIW MXE appears to
 support wx3.0:
 
 https://github.com/mxe/mxe/blob/master/src/wxwidgets.mk
 
  So while such a move is planned, it's too early to make it.
  Please consider supporting both 2.8 and 3.0 in Jessie (as with 2.6/2.8).
  It will also make backports easier.
 
 It's really not feasible to support two different wx releases in Jessie
 - there are only two people in the wx team who have been at all active
 in recent times.  Since there's no upstream interest in wx2.8, and a
 number of packages actually require wx3.0, wx3.0 is the sane choice.
 
 Having 2.6 and 2.8 in a release together didn't work out well -
 bugs in 2.6 just piled up because upstream weren't interested.  That's
 not what we want in a large and complex library package.
 
  Last, I (as package maintainer) would object to Debian diverging from
  upstream, especially with forwarded:no patches, so no NMU please.
 
 Since you are upstream maintainer, we can now consider the patch as
 forwarded.
 
 The patch I sent doesn't break compatibility with wx2.8 - I did a test
 build to verify this.
 
 Note that in wx2.8 wxTHICK_FRAME is just defined to wxRESIZE_BORDER, so
 changing wxRESIZE_BORDER|wxTHICK_FRAME to wxRESIZE_BORDER makes no
 different to behaviour.


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

Bug#750131: SDL2_gfx: patch for pkg-config support

[beuc]

Control: tags -1 + fixed-upstream

Hi,

SDL2_gfx 1.0.1 is out with pkg-config support :)
http://www.ferzkopp.net/Software/SDL2_gfx/SDL2_gfx-1.0.1.tar.gz

Cheers!
Sylvain


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

Bug#750706: libsdl2-mixer: Music with TiMidity backend plays at wrong speed

[beuc]

B1;2802;0cControl: tags -1 + patch fixed-upstream

This was independently reported here:
https://bugzilla.libsdl.org/show_bug.cgi?id=2140
and fixed upstream with this patch:
https://hg.libsdl.org/SDL_mixer/rev/8ef083375857

Would you consider including this bugfix in the current release?

Cheers!
Sylvain


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

Bug#750706: libsdl2-mixer: Music with TiMidity backend plays at wrong speed

[beuc]

Package: libsdl2-mixer-2.0-0
Version: 2.0.0+dfsg1-3
Severity: normal

Dear Maintainer,

I'm experimenting with SDL2_mixer and I'm facing something very
similar to #726912.

As we can see at the end of that bug, you eventually reverted the
following patch in SDL_mixer 1.2:
http://lists.alioth.debian.org/pipermail/pkg-sdl-commits/2013-July/000703.html
http://hg.libsdl.org/SDL_mixer/rev/0ff9b7b8ba7bb3eb8d15915dc405f161a3d3fde6

Did you mention it to upstream so he reverts it too?  Otherwise he may
well have included it in SDL2_mixer (chronologically possible AFAICS)
:/

Cheers!
Sylvain

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

Kernel: Linux 3.14-1-amd64 (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/dash

Versions of packages libsdl2-mixer-2.0-0 depends on:
ii  libc6  2.18-7
ii  libflac8   1.3.0-2
ii  libfluidsynth1 1.1.6-2
ii  libmad00.15.1b-8
ii  libmodplug11:0.8.8.4-4.1
ii  libsdl2-2.0-0  2.0.2+dfsg1-3
ii  libvorbisfile3 1.3.2-1.4
ii  multiarch-support  2.18-7

Versions of packages libsdl2-mixer-2.0-0 recommends:
ii  freepats  20060219-1

libsdl2-mixer-2.0-0 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#640804: gforge-shell-postgresql: Ucf questions on changes to nss related conf files should provide correct default choice

[beuc]

Hi,

On Wed, Sep 07, 2011 at 04:48:11PM +0200, Olivier Berger wrote:
 
 Hi.
 

 Much like in #556188, changes to nsswitch.conf should be made by
 providing a default choice to the user that is most likely to need a
 custom template for ucf with a different default.
 
 Of course, if possible, it wouldn't harm if changes to nsswitch.conf
 could be avoided.
 
 I heard that a possible solution would be not to use
 libnss-postgresql but I don't have a reference for this so far.

I faced this problem recently when installing from Puppet (hence,
noninteractively).

I resorted to the following work-around involving /etc/ucf.conf:

[code]
class fusionforge {
  file { '/etc/ucf.conf':
ensure  = file,
content = '# Make sure FusionForge can install pre-configured files from 
Puppet
case $DPKG_MAINTSCRIPT_PACKAGE in
gforge-shell-postgresql|gforge-mta-exim4|gforge-mta-postfix)
conf_force_conffnew=YES
;;
esac
';
  }
  File['/etc/ucf.conf'] - Package| |
[/code]

If there's a better way to implement this I'm interested.

-- 
Sylvain


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

Bug#750131: libsdl2-gfx-dev: pkg-config support

[beuc]

Package: libsdl2-gfx-dev
Version: 1.0.0-2
Severity: normal
Tags: patch

Hi,

I added support for pkg-config in SDL_gfx, cf. attached patch.
Please consider applying it.

I'm going to forward it to the upstream maintainer as soon as I get
this bug ID.

Cheers!
Sylvain
--- t1/libsdl2-gfx-1.0.0/debian/changelog	2014-02-03 21:27:32.0 +0100
+++ t2/libsdl2-gfx-1.0.0/debian/changelog	2014-06-01 22:42:06.747288467 +0200
@@ -1,3 +1,10 @@
+libsdl2-gfx (1.0.0-3) UNRELEASED; urgency=medium
+
+  [ Sylvain Beucler]
+  * Add SDL2_gfx.pc pkg-config file
+
+ --
+
 libsdl2-gfx (1.0.0-2) unstable; urgency=medium
 
   [ Gianfranco Costamagna ]
--- t1/libsdl2-gfx-1.0.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ t2/libsdl2-gfx-1.0.0/debian/patches/series	2014-06-01 22:01:14.547525609 +0200
@@ -0,0 +1 @@
+SDL2_gfx.pc.patch
--- t1/libsdl2-gfx-1.0.0/debian/patches/SDL2_gfx.pc.patch	1970-01-01 01:00:00.0 +0100
+++ t2/libsdl2-gfx-1.0.0/debian/patches/SDL2_gfx.pc.patch	2014-06-01 22:24:56.747963008 +0200
@@ -0,0 +1,47 @@
+Description: Add pkg-config support to SDL2_gfx
+Forwarded: 2014-06-01 to aschiff...@ferzkopp.net
+Author: Sylvain Beucler b...@debian.org
+Last-Update: 2014-06-01
+
+--- svn/configure.in	(révision 14)
 svn/configure.in	(copie de travail)
+@@ -140,6 +140,7 @@
+ # Finally create all the generated files
+ AC_OUTPUT([
+ Makefile
++SDL2_gfx.pc
+ ])
+ 
+ echo
+--- svn/Makefile.am	(révision 14)
 svn/Makefile.am	(copie de travail)
+@@ -30,6 +30,9 @@
+ # Rule to build tar-gzipped distribution package
+ $(PACKAGE)-$(VERSION).tar.gz: distcheck
+ 
++pkgconfigdir = $(libdir)/pkgconfig
++pkgconfig_DATA = SDL2_gfx.pc
++
+ # Additional cleanup rules
+ DISTCLEANFILES =		\
+ 	SDL2_gfx.sdf		\
+@@ -38,4 +41,3 @@
+ 	autom4te.cache/*	\
+ 	Win32/Debug/*		\
+ 	Win32/Release/*
+-		
+\ No newline at end of file
+--- svn/SDL2_gfx.pc.in	(révision 0)
 svn/SDL2_gfx.pc.in	(copie de travail)
+@@ -0,0 +1,11 @@
++prefix=@prefix@
++exec_prefix=@exec_prefix@
++libdir=@libdir@
++includedir=@includedir@
++
++Name: SDL2_gfx
++Description: drawing and graphical effects extension for SDL
++Version: @VERSION@
++Requires: sdl2 = @SDL_VERSION@
++Libs: -L${libdir} -lSDL2_gfx
++Cflags: -I${includedir}/SDL2

Bug#750131: libsdl2-gfx-dev: pkg-config support

[beuc]

Attached fixed patch with the missing .install file.

-- 
Sylvain
--- t1/libsdl2-gfx-1.0.0/debian/changelog	2014-02-03 21:27:32.0 +0100
+++ t2/libsdl2-gfx-1.0.0/debian/changelog	2014-06-01 22:42:06.747288467 +0200
@@ -1,3 +1,10 @@
+libsdl2-gfx (1.0.0-3) UNRELEASED; urgency=medium
+
+  [ Sylvain Beucler]
+  * Add SDL2_gfx.pc pkg-config file
+
+ --
+
 libsdl2-gfx (1.0.0-2) unstable; urgency=medium
 
   [ Gianfranco Costamagna ]
--- t1/libsdl2-gfx-1.0.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ t2/libsdl2-gfx-1.0.0/debian/patches/series	2014-06-01 22:01:14.547525609 +0200
@@ -0,0 +1 @@
+SDL2_gfx.pc.patch
--- t1/libsdl2-gfx-1.0.0/debian/patches/SDL2_gfx.pc.patch	1970-01-01 01:00:00.0 +0100
+++ t2/libsdl2-gfx-1.0.0/debian/patches/SDL2_gfx.pc.patch	2014-06-01 22:24:56.747963008 +0200
@@ -0,0 +1,47 @@
+Description: Add pkg-config support to SDL2_gfx
+Forwarded: 2014-06-01 to aschiff...@ferzkopp.net
+Author: Sylvain Beucler b...@debian.org
+Last-Update: 2014-06-01
+
+--- svn/configure.in	(révision 14)
 svn/configure.in	(copie de travail)
+@@ -140,6 +140,7 @@
+ # Finally create all the generated files
+ AC_OUTPUT([
+ Makefile
++SDL2_gfx.pc
+ ])
+ 
+ echo
+--- svn/Makefile.am	(révision 14)
 svn/Makefile.am	(copie de travail)
+@@ -30,6 +30,9 @@
+ # Rule to build tar-gzipped distribution package
+ $(PACKAGE)-$(VERSION).tar.gz: distcheck
+ 
++pkgconfigdir = $(libdir)/pkgconfig
++pkgconfig_DATA = SDL2_gfx.pc
++
+ # Additional cleanup rules
+ DISTCLEANFILES =		\
+ 	SDL2_gfx.sdf		\
+@@ -38,4 +41,3 @@
+ 	autom4te.cache/*	\
+ 	Win32/Debug/*		\
+ 	Win32/Release/*
+-		
+\ No newline at end of file
+--- svn/SDL2_gfx.pc.in	(révision 0)
 svn/SDL2_gfx.pc.in	(copie de travail)
+@@ -0,0 +1,11 @@
++prefix=@prefix@
++exec_prefix=@exec_prefix@
++libdir=@libdir@
++includedir=@includedir@
++
++Name: SDL2_gfx
++Description: drawing and graphical effects extension for SDL
++Version: @VERSION@
++Requires: sdl2 = @SDL_VERSION@
++Libs: -L${libdir} -lSDL2_gfx
++Cflags: -I${includedir}/SDL2
--- t1/libsdl2-gfx-1.0.0/debian/libsdl2-gfx-dev.install	2014-02-03 21:01:13.0 +0100
+++ t2/libsdl2-gfx-1.0.0/debian/libsdl2-gfx-dev.install	2014-06-01 21:53:28.096480077 +0200
@@ -1,4 +1,4 @@
 usr/include
 usr/lib/*/lib*.a
 usr/lib/*/lib*.so
-#usr/lib/*/pkgconfig
+usr/lib/*/pkgconfig

Bug#750131: SDL2_gfx: patch for pkg-config support

[beuc]

Hi Andreas,

Here's a patch to add pkg-config support in SDL2_gfx, that is add a
SDL2_gfx.pc on install.  It's mostly a merge being the old one in
SDL_gfx and the new ones in SDL_Mixer  cie.

It is useful for people who use PKG_CHECK_MODULES in their autoconf.
Would you consider including it in SDL2_gfx?

I'm submitting it to Debian too.

Cheers!
Sylvain
Description: Add pkg-config support to SDL2_gfx
Forwarded: 2014-06-01 to aschiff...@ferzkopp.net
Author: Sylvain Beucler b...@debian.org
Last-Update: 2014-06-01

--- svn/configure.in	(révision 14)
+++ svn/configure.in	(copie de travail)
@@ -140,6 +140,7 @@
 # Finally create all the generated files
 AC_OUTPUT([
 Makefile
+SDL2_gfx.pc
 ])
 
 echo
--- svn/Makefile.am	(révision 14)
+++ svn/Makefile.am	(copie de travail)
@@ -30,6 +30,9 @@
 # Rule to build tar-gzipped distribution package
 $(PACKAGE)-$(VERSION).tar.gz: distcheck
 
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = SDL2_gfx.pc
+
 # Additional cleanup rules
 DISTCLEANFILES =		\
 	SDL2_gfx.sdf		\
@@ -38,4 +41,3 @@
 	autom4te.cache/*	\
 	Win32/Debug/*		\
 	Win32/Release/*
-		
\ No newline at end of file
--- svn/SDL2_gfx.pc.in	(révision 0)
+++ svn/SDL2_gfx.pc.in	(copie de travail)
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: SDL2_gfx
+Description: drawing and graphical effects extension for SDL
+Version: @VERSION@
+Requires: sdl2 = @SDL_VERSION@
+Libs: -L${libdir} -lSDL2_gfx
+Cflags: -I${includedir}/SDL2

Bug#750001: freedink-dfarc: Please update to wxwidgets3.0

[beuc]

Hi,

I (as upstream) do not wish to update to wxWidgets2.8 yet because
wxGlade (used to generate the *_Base.cpp files) doesn't support it,
and because MXE (for the Windows cross-build) doesn't seem to either
(though it builds 2.9 already).

So while such a move is planned, it's too early to make it.
Please consider supporting both 2.8 and 3.0 in Jessie (as with 2.6/2.8).
It will also make backports easier.

Last, I (as package maintainer) would object to Debian diverging from
upstream, especially with forwarded:no patches, so no NMU please.

- Sylvain

On Sun, Jun 01, 2014 at 01:44:35AM +1200, Olly Betts wrote:
 Package: freedink-dfarc
 Version: 3.10-1.1
 Severity: important
 Tags: patch
 User: freewx-ma...@lists.alioth.debian.org
 Usertags: wx3.0
 
 Dear maintainer,
 
 We're aiming to migrate the archive to using wxwidgets3.0 instead of
 wxwidgets2.8, and intend to drop wxwidgets2.8 before jessie is released.
 
 I've rebuilt your package using the attached patch, and exercised the
 GUI, though I don't have the dink game itself installed, so didn't I
 didn't test actually launching a game.
 
 I'm happy to NMU this change if you wish me to - just let me know.
 
 Cheers,
 Olly

 diff -Nru freedink-dfarc-3.10/debian/changelog 
 freedink-dfarc-3.10/debian/changelog
 --- freedink-dfarc-3.10/debian/changelog  2012-09-28 01:55:08.0 
 +1200
 +++ freedink-dfarc-3.10/debian/changelog  2014-06-01 01:05:13.0 
 +1200
 @@ -1,3 +1,10 @@
 +freedink-dfarc (3.10-1.2) unstable; urgency=low
 +
 +  * Non-maintainer upload.
 +  * Update to use wxwidgets3.0.  New patch: wx3.0-compat.patch
 +
 + -- Olly Betts o...@survex.com  Sun, 01 Jun 2014 01:05:05 +1200
 +
  freedink-dfarc (3.10-1.1) unstable; urgency=low
  
* Non-maintainer upload
 diff -Nru freedink-dfarc-3.10/debian/control 
 freedink-dfarc-3.10/debian/control
 --- freedink-dfarc-3.10/debian/control2012-04-28 01:17:26.0 
 +1200
 +++ freedink-dfarc-3.10/debian/control2013-11-22 16:38:55.0 
 +1300
 @@ -3,7 +3,7 @@
  Priority: extra
  Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org
  Uploaders: Sylvain Beucler b...@debian.org
 -Build-Depends: debhelper (= 7.0.50~), autotools-dev, libbz2-dev, 
 libwxgtk2.8-dev, intltool (= 0.31)
 +Build-Depends: debhelper (= 7.0.50~), autotools-dev, libbz2-dev, 
 libwxgtk3.0-dev, intltool (= 0.31)
  Standards-Version: 3.9.3
  Homepage: http://www.gnu.org/software/freedink/
  Vcs-Git: git://git.debian.org/git/pkg-games/freedink-dfarc.git
 diff -Nru freedink-dfarc-3.10/debian/.gitignore 
 freedink-dfarc-3.10/debian/.gitignore
 --- freedink-dfarc-3.10/debian/.gitignore 2008-08-26 08:13:37.0 
 +1200
 +++ freedink-dfarc-3.10/debian/.gitignore 1970-01-01 12:00:00.0 
 +1200
 @@ -1,9 +0,0 @@
 -# rules:
 -build-stamp
 -build
 -dfarc2
 -# debhelper:
 -files
 -dfarc2.postinst.debhelper
 -dfarc2.postrm.debhelper
 -dfarc2.substvars
 diff -Nru freedink-dfarc-3.10/debian/patches/series 
 freedink-dfarc-3.10/debian/patches/series
 --- freedink-dfarc-3.10/debian/patches/series 1970-01-01 12:00:00.0 
 +1200
 +++ freedink-dfarc-3.10/debian/patches/series 2013-11-22 16:57:14.0 
 +1300
 @@ -0,0 +1 @@
 +wx3.0-compat.patch
 diff -Nru freedink-dfarc-3.10/debian/patches/wx3.0-compat.patch 
 freedink-dfarc-3.10/debian/patches/wx3.0-compat.patch
 --- freedink-dfarc-3.10/debian/patches/wx3.0-compat.patch 1970-01-01 
 12:00:00.0 +1200
 +++ freedink-dfarc-3.10/debian/patches/wx3.0-compat.patch 2014-06-01 
 01:22:43.0 +1200
 @@ -0,0 +1,285 @@
 +Description: fix to build with wxwidgets 3.0
 + wxLogError, etc are macros in wx 3.0.
 +Author: Olly Betts o...@survex.com
 +Forwarded: no
 +Last-Update: 2013-11-22
 +
 +--- a/src/InstallVerifyFrame.cpp
  b/src/InstallVerifyFrame.cpp
 +@@ -166,7 +166,7 @@
 + }
 +   else
 + {
 +-  ::wxLogError(_(An error occured while extracting the .dmod file.));
 ++  wxLogError(_(An error occured while extracting the .dmod file.));
 + }
 +   ::wxRemoveFile(mTarFilePath);
 +   // TODO: return error code instead of wxID_OK if something goes wrong
 +--- a/src/DFArcFrame.cpp
  b/src/DFArcFrame.cpp
 +@@ -343,7 +343,7 @@
 + {
 +   wxString description = _(D-Mod files (*.dmod));
 +   wxFileDialog FileDlg(0, _(Select a .dmod file), _T(), _T(), 
 description + _T(|*.dmod),
 +-wxOPEN | wxFILE_MUST_EXIST);
 ++wxFD_OPEN | wxFD_FILE_MUST_EXIST);
 +  
 +   if (FileDlg.ShowModal() == wxID_OK)
 + {
 +@@ -912,7 +912,7 @@
 + {
 +   if (::wxRmdir(mConfig-mSelectedDmod) == false)
 + {
 +-  ::wxLogError(_(Unable to remove D-Mod directory. All 
 other files were removed.));
 ++  wxLogError(_(Unable to remove D-Mod directory. All other 
 files were removed.));
 +   lSuccess = false;
 + }
 + }
 +--- a/src/RecursiveDelete.cpp
  

Bug#585205: gforge-web-apache2: Python string exceptions no more allowed in Python 2.6

[beuc]

For reference: this was triggered by our old bundled ViewVC copy.

-- 
Sylvain


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

Bug#748090: libsdl-mixer1.2: leaks lots of memory with fluidsynth, rendering system unresponsive

[beuc]

Control: retitle -1 libsdl-mixer1.2: leaks lots of memory with fluidsynth, 
rendering system unresponsive
Control: reassign -1 libsdl-mixer1.2
Control: found -1 1.2.12-11+b1

Hi SDL_Mixer maintainers,

I got a report of memory leak in the FreeDink package, which only
happens when using the fluidsynth backend for SDL_Mixer (which
apparently is now default).

I don't know if this bug comes from SDL_Mixer or in Fluidsynth itself,
so I'm forwarding it an upstream-step above :)

Ben: would you be so kind as to provide your saved game and some more
instructions on how to reproduce the problem?

Cheers!
Sylvain

On Wed, May 14, 2014 at 12:41:58AM -0700, Ben Longbons wrote:
 Package: freedink-engine
 Version: 1.08.20120427-2.1+b1
 Severity: important
 
 Dear Maintainer,
 
 After running freedink for a while, it allocates several gigabytes of
 memory, which makes the system unresponsive due to lots of swapping.
 
 The problem is particularly noticable in the Edge of the World when
 walking between the church and the dangerous parts to the left.
 
 It leaks over 100 MB each time.
 
 valgrind gives a bunch of different backtraces from libfluidsynth.so,
 but they all come from the same part of freedink:
 
 ==11711==by 0x4E3FE72: Mix_LoadMUS (in 
 /usr/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0.12.0)
 ==11711==by 0x404CAD: PlayMidi (bgm.c:218)
 ==11711==by 0x404F78: check_midi (bgm.c:312)
 ==11711==by 0x4168CB: load_map (dinkvar.c:1014)
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers testing
   APT policy: (600, 'testing'), (500, 'unstable'), (1, 'experimental')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages freedink-engine depends on:
 ii  freedink-data1.08.20111016-1
 ii  freepats 20060219-1
 ii  libc62.18-5
 ii  libfontconfig1   2.11.0-5
 ii  libfreetype6 2.5.2-1
 ii  libsdl-gfx1.2-5  2.0.25-4
 ii  libsdl-image1.2  1.2.12-5+b2
 ii  libsdl-mixer1.2  1.2.12-11+b1
 ii  libsdl-ttf2.0-0  2.0.11-3
 ii  libsdl1.2debian  1.2.15-9
 ii  ttf-liberation   1.07.4-1
 
 Versions of packages freedink-engine recommends:
 ii  freedink-dfarc  3.10-1.1
 
 freedink-engine suggests no packages.
 
 -- no debconf information
 

On Wed, May 14, 2014 at 11:44:33AM +0200, b...@debian.org wrote:
 Can you check if you have the same behavior with the traditional
 TiMidity backend?
 
 I think you can force it with:
 SDL_FORCE_SOUNDFONTS=1 freedink ...
 
 You should hear a noticeable difference in the music - and possibly a
 difference in matter of RAM usage ;)
 
 If no leak, this means the leak comes from the new fluidsynth backend
 in libsdl-mixer.

On Fri, May 16, 2014 at 11:12:52AM +0200, b...@debian.org wrote:
 On Thu, May 15, 2014 at 09:56:59PM -0700, Ben Longbons wrote:
  On Wed, May 14, 2014 at 2:44 AM,  b...@debian.org wrote:
   SDL_FORCE_SOUNDFONTS=1
  
  There is no leak with that in the environment.
 
 Thanks for checking.
 
 Would you mind retitlingreassigning the bug to libsdl-mixer or
 libfluidsynth?
 
 Cheers!
 Sylvain


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

Bug#748090: freedink-engine: leaks lots of memory, rendering system unresponsive

[beuc]

Hi,

On Thu, May 15, 2014 at 09:56:59PM -0700, Ben Longbons wrote:
 On Wed, May 14, 2014 at 2:44 AM,  b...@debian.org wrote:
  SDL_FORCE_SOUNDFONTS=1
 
 There is no leak with that in the environment.

Thanks for checking.

Would you mind retitlingreassigning the bug to libsdl-mixer or
libfluidsynth?

Cheers!
Sylvain


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

Bug#748090: freedink-engine: leaks lots of memory, rendering system unresponsive

[beuc]

Hi,

On Wed, May 14, 2014 at 12:41:58AM -0700, Ben Longbons wrote:
 Package: freedink-engine
 Version: 1.08.20120427-2.1+b1
 Severity: important
 
 Dear Maintainer,
 
 After running freedink for a while, it allocates several gigabytes of
 memory, which makes the system unresponsive due to lots of swapping.
 
 The problem is particularly noticable in the Edge of the World when
 walking between the church and the dangerous parts to the left.
 
 It leaks over 100 MB each time.
 
 valgrind gives a bunch of different backtraces from libfluidsynth.so,
 but they all come from the same part of freedink:

Can you check if you have the same behavior with the traditional
TiMidity backend?

I think you can force it with:
SDL_FORCE_SOUNDFONTS=1 freedink ...

You should hear a noticeable difference in the music - and possibly a
difference in matter of RAM usage ;)

If no leak, this means the leak comes from the new fluidsynth backend
in libsdl-mixer.

Cheers!
Sylvain


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

Bug#747002: libfreetype6: incorrectly free()s winfnt fonts with external stream source, leading to double free segfault

[beuc]

Package: libfreetype6
Version: 2.5.2-1
Severity: important
Tags: upstream

Hi!

I just rediscovered https://savannah.nongnu.org/bugs/?40997
winfont driver overrides face_flags (EXTERNAL_STREAM)
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=5f577462
which is fixed in 2.5.3, so please upgrade :)

It may be the cause of #698313 too.

- Sylvain

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

Kernel: Linux 3.13-1-amd64 (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/dash

Versions of packages libfreetype6 depends on:
ii  libc6  2.18-5
ii  libpng12-0 1.2.50-1
ii  multiarch-support  2.18-4
ii  zlib1g 1:1.2.8.dfsg-1

libfreetype6 recommends no packages.

libfreetype6 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#743897: gargoyle-free: please remove unneeded fonts-* dependencies

[beuc]

Hi,

On Wed, Apr 09, 2014 at 12:51:13PM +0800, Paul Wise wrote:
 On Tue, 2014-04-08 at 23:57 +0200, Sylvain Beucler wrote:
  Anyway, selecting *specific* *free* fonts for Gargoyle was discussed
  at length with upstream at the time I contributed the fontconfig
  support, and they're pretty concerned about what fonts are used,
  especially since it can break a game rendering/layout.
 
 The folks I was discussing this issue with apparently used it with the
 DejaVu fonts for years without issues so perhaps upstream's concerns are
 slightly overinflated?
 
 Looking at the available screenshots I can't see how fonts like DejaVu
 could break layout/rendering.
 
 https://screenshots.debian.net/package/gargoyle-free
 http://ccxvii.net/gargoyle/screenshots.html

Different final font size in complex game layouts (not the basic .z5,
multimedia ones like MoonWatch).

People who disagree with upstream can discuss with them.  As a Debian
package (and DFSG-derivate) maintainer I strive to maintain
consistency.

  So let's keep the specific font dependencies.
 
 How about dropping them to recommends, so that most people will get the
 default chosen fonts and people who prefer other fonts can use those?

So that's the issue.  Well, these people can edit their
/etc/garglk.ini.

-- 
Sylvain


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

Bug#743897: gargoyle-free: please remove unneeded fonts-* dependencies

[beuc]

On Tue, Apr 08, 2014 at 10:00:50AM +0800, Paul Wise wrote:
 Package: gargoyle-free
 Severity: wishlist
 
 As far as I can tell, gargoyle-free uses fontconfig to find font paths
 at runtime. As a result it doesn't need to depend on specific fonts
 since fontconfig will return the default fonts if the asked for fonts
 are not available on the system. Please drop the fonts packages from the
 gargoyle-free dependencies.

That's the second mail I receive this week about fonts dependencies
(previous was questionning the need to depend on 2 rather than 1).
Is there anything going on about fonts these days?
I don't really understand why we spend energy on this.

Anyway, selecting *specific* *free* fonts for Gargoyle was discussed
at length with upstream at the time I contributed the fontconfig
support, and they're pretty concerned about what fonts are used,
especially since it can break a game rendering/layout.

So let's keep the specific font dependencies.

-- 
Sylvain


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

Bug#741082: apache2: Includes+MultiViews+mod_deflate = Content Encoding Error

[beuc]

For reference, here's the original, complete use case:
https://gna.org/support/?3126


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

Bug#603904: Fresh installation of mailman has wrong permissions, causes archiving to fail

[beuc]

I confirm the problem.  FYI here's the permissions at Gna(.org) that
have been working for at least 2 years, more likely 10:

  drwxrws--- 4065 www-data list 139264 Mar  8 17:30 
/var/lib/mailman/archives/private/

Easy enough? :)

-- 
Sylvain


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

Bug#718704: jam: No 'jam clean' under kfreebsd

[beuc]

Package: jam
Version: 2.5rel-1
Severity: important

Hi,

Compiling 'gargoyle-free' has always failed under kfreebsd. The latests logs 
are here:
https://buildd.debian.org/fetch.cgi?pkg=gargoyle-freearch=kfreebsd-i386ver=2011.1a-1stamp=1375236525file=log
https://buildd.debian.org/fetch.cgi?pkg=gargoyle-freearch=kfreebsd-amd64ver=2011.1a-1stamp=1375264124file=log

More precisely:
  make[1]: Entering directory `/«PKGBUILDDIR»'
  jam clean
  Unknown target. Please edit 'Jamrules'. 
  make[1]: *** [override_dh_auto_clean] Error 1

It's the only architecture where I get this, so I suspect something is
broken with the kfreebsd build.

Cheers!
Sylvain

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

Kernel: Linux 3.9-1-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

Versions of packages jam depends on:
ii  libc6  2.17-7

jam recommends no packages.

jam 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#671086: libgl1-mesa-glx: Cannot install both libgl1-mesa-swx11 and libgl1-mesa-glx

[beuc]

Package: libgl1-mesa-glx
Version: 7.11.2-1
Severity: important

Hi,

I used to install both the software and the DRI implementation of Mesa.

This allows to test an application with the DRI implementation by default,
and switch to software implementation, which is particularly useful when
debugging low-level OpenGL code, using:

  LIBGL_ALWAYS_SOFTWARE=1 ./myapp


Today, both libgl1-mesa-swx11 and libgl1-mesa-glx provide and conflict with
libgl1.  This means I have to remove -glx to install -swx11 and vice-versa.

Can these two libraries be installable in parallel?


Thanks!
Sylvain



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