Bug#982809: ITP: dodge-the-creeps -- Dodge the Creeps! tutorial game for the Godot engine
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
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
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)
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
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
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
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
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
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 &Event) + 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, &lInstallProgress); + 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 direc
Bug#893157: planet-venus: django.template.exceptions.TemplateDoesNotExist
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
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
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
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
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
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
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
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
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 cytadela/1.1.0-3 -- System Information: Debian Release: 9.0 APT prefers testing APT policy
Bug#767839: debian-policy: Linking documentation of arch:any package to arch:all
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
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
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
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
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
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)
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
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
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) (Re: hydrogen-drumkits: DFSG-ness of the drumkits)
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#798706: unowned files after purge (policy 6.8, 10.8)
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#793683: unowned files after purge (policy 6.8, 10.8)
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)
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#793683: unowned files after purge (policy 6.8, 10.8)
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
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#798973: anonscm: AH01630: client denied by server configuration
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
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/*
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
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 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)
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#726209: closed by b...@debian.org (Re: ballz: missing icon entry in menu file Jessie Release Goal)
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#793598: lxc-debian: only enable free section by default
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
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
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
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
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
tch a bug in > > 9.4beta2. > >* supported-versions: Set 9.4 as pgdg default on Ubuntu 14.10. > >* Debconf translation updates, thanks! > > + nl by Frans Spiesschaert. (Closes: #762632) > > . > >[ Peter Michael Green ] > >* Use ID_LIKE to identify deriviatives of Debian and Ubuntu. > > (Closes: #761020) > > . > >[ Richard Hughes ] > >* Use Type=forking in postgresql@.service and start before postgresql. > > (Closes: #759725) > > Checksums-Sha1: > > d16d77dcd70a0e5d3c39795089894f6b336605ee 2240 postgresql-common_162.dsc > > 72700311d17f9f5b0ab33dac3c2ee4b1f691a83e 186148 > > postgresql-common_162.tar.xz > > f1d9c51af5a8d18e3ff2f93911a2b66702e3eef8 58446 > > postgresql-server-dev-all_162_all.deb > > c5aa9355d15073352377250fc34fe71f8676f846 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 > > To: Debian Bug Tracking System > > 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
Bug#771944: closed by Michael Gilbert (Re: Bug#771944: Following FusionForge 5.3 stable branch)
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 (Re: Bug#771944: Following FusionForge 5.3 stable branch)
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 (Re: Bug#771944: Following FusionForge 5.3 stable branch)
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 (Re: Bug#771944: Following FusionForge 5.3 stable branch)
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 . > > 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 > 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 > 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#776328: cytadela won't start
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 ) at malloc.c:4157 #1 0x766734d1 in _int_free (av=0x7699d620 , p=, 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=) at videoplayer.cpp:191 #7 0x00422324 in CSDLClass::playVideo (this=, fileName=fileName@entry=0x431496 "video/intro_en.webm", offOnFinish=, audio=) 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=, 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#775588: [Pkg-haskell-maintainers] Bug#775588: darcs: Missing copyright information
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#774799: sysv-rc: Unit my-service.service failed to load: No such file or directory, using install from source + update-rc.d
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#773246: hydrogen-drumkits: DFSG-ness of the drumkits
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
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#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing
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#773210: unblock: fusionforge/5.3.2+20141104-3
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 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 , Olivier Berger , Sylvain Beucler 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
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#772870: fusionforge-plugin-mediawiki: Trigger cycle causes dpkg to fail processing
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
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 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 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 , Olivier Berger , Sylvain Beucler 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 fusionforge-plugin-authldap: lines which differ (wdiff format) ---
Bug#771619: fusionforge: plugin postinst script uses 'service' instead of invoke-rc.d
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 build&install 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
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#771944: Following FusionForge 5.3 stable branch
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#750716: coffeescript: FTBFS against uglify 2.x series - Cannot call method 'parse' of undefined
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#767541: jenkins: CVE-2014-3665
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#767892: subtitleeditor: Cannot type or edit subtitles
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
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 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
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 -- 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 (Bug#759725: fixed in postgresql-common 162)
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 > To: Debian Bug Tracking System > 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 postgresq
Bug#762162: gdb output (2)
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=, text=, 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=, text=, str=0xa34ba0) at /build/glib2.0-tWPgvS/glib2.0-2.40.0/./glib/gmarkup.c:2162 #1 g_markup_escape_text (text=, length=, 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=, value=0x7fffd120, pspec=) at /build/gtk+2.0-zztKf7/gtk+2.0-2.24.24/gtk/gtkwidget.c:2739 #3 0x761690a1 in object_set_property (nqueue=, value=, pspec=, object=) 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=, signal_id=, detail=, 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=, signal_id=, detail=) 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=) 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=) at image.c:91 #19 image_post_process_color (start_row=, run_in_bg=, imd=) 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=, x=0, y=0, w=, h=, data=) 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, detail=detail@entry=0, instance=instance@entry=0xa44240, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffdd80) at /build/glib2.0-tWPgvS/glib2.0-2.40.0/./gobject/gsignal.c:3551 #24 0x7617c208 in g_signal_emit_valist (instance=, signal_id=, detail=, var_args=var_args@entry=0x7fffdf60) at /buil
Bug#762079: apt: Hash Sum mismatch while sum checks since security update
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/wheezy&id=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#762079: apt: Hash Sum mismatch while sum checks since security update
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 41bf248d8c2ce060e61529f6f130a588a10
Bug#759725: postgresql-common: non-synchronous service postgresql start/stop/reload
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)
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
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
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
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
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
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
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
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
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: SDL2_gfx: patch for pkg-config support
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 Author: Sylvain Beucler 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
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 +Author: Sylvain Beucler +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: libsdl2-gfx-dev: pkg-config support
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 +Author: Sylvain Beucler +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
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 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 > Uploaders: Sylvain Beucler > -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 > +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; > + } > +
Bug#585205: gforge-web-apache2: Python string exceptions no more allowed in Python 2.6
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
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, wrote: > > > SDL_FORCE_SOUNDFONTS=1 > > > > There is no leak with that in the environment. > > Thanks for checking. > > Would you mind retitling&reassigning 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
Hi, On Thu, May 15, 2014 at 09:56:59PM -0700, Ben Longbons wrote: > On Wed, May 14, 2014 at 2:44 AM, wrote: > > SDL_FORCE_SOUNDFONTS=1 > > There is no leak with that in the environment. Thanks for checking. Would you mind retitling&reassigning 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
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
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
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
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#603904: Fresh installation of mailman has wrong permissions, causes archiving to fail
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#741082: apache2: Includes+MultiViews+mod_deflate = Content Encoding Error
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#718704: jam: No 'jam clean' under kfreebsd
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-free&arch=kfreebsd-i386&ver=2011.1a-1&stamp=1375236525&file=log https://buildd.debian.org/fetch.cgi?pkg=gargoyle-free&arch=kfreebsd-amd64&ver=2011.1a-1&stamp=1375264124&file=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
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