Bug#689569: Unchecked implicit conversion from float to enum
Package: openarena Version: While building the package using our research compiler infrastructure we noticed the following unchecked implicit conversion with possibly undefined behaviour: Lines 401-403 of code/q3_ui/ui_playermodel.c: qboolean precache; precache = trap_Cvar_VariableValue(com_buildscript); The conversion of an arbitrary float value to an enum (qboolean) isn't well-defined. Likely the best fix is to change the right-hand side to a comparison to non-zero: precache = trap_Cvar_VariableValue(com_buildscript) != 0; Best, Michael pgp4HzxXuc0l0.pgp Description: PGP signature
Bug#689570: Conflicting declarations of variable prottable
Package: pavuk
Version: 0.9.35-2.3
While building the package using our research compiler infrastructure we noticed
the following conflicting declarations:
src/url.h: extern const protinfo prottable[9];
src/url.c: const protinfo prottable[] = { ... 8 entries only ... };
The wrong extern declaration/missing entry in the initialisation and thus
allocation of prottable may explain some of the segfaults.
Best,
Michael
pgp4tZV11PslL.pgp
Description: PGP signature
Bug#689571: CVE-2012-4463: Improper sanitization of MC_EXT_SELECTED variable when viewing multiple files
Package: mc Version: 3:4.8.5-1~exp4 Severity: important Tags: security Hi, the following vulnerability was published for mc. CVE-2012-4463[0]: Improper sanitization of MC_EXT_SELECTED variable when viewing multiple files If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. For further information see: [0] http://security-tracker.debian.org/tracker/CVE-2012-4463 Please adjust the affected versions in the BTS as needed. Note: I have not checked the code if actually also the versions in stable, testing and unstable are affected. At first glance it seems that at least the experimental version is affected. Regards, Salvatore signature.asc Description: Digital signature
Bug#689572: nmu: packages linked against libhdf5-7 1.8.8-7.1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org There're several packages currently in Debian testing having a versioned dependency on the semi-virtual libhdf5-7 package (apparently as the result of being built prior to Source: hdf5 1.8.8-7.1 propagating to testing on 2012-02-23.) Consequently, these packages cannot be installed along with any of the other libraries providing libhdf5-7 (check, e. g., [1].) I'm therefore suggesting re-building these packages against the now-current libhdf5-7, with binNMU's as specified below. TIA. nmu libcgns_3.1.3.4-1 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' nmu nexus_4.2.1-svn1614-1 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' nmu r-cran-hdf5_1.6.10-1 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' nmu tessa_0.3.1-6 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' nmu udav_0.7.1.2-3 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' The hdf-eos5_5.1.14+dfsg.1-1 currently in Debian unstable fixes the issue (as well as a few others), but unless it's unblocked (and enters Debian testing), it has to be re-built just as well: nmu hdf-eos5_5.1.13.dfsg.1-3 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' [1] http://packages.debian.org/wheezy/libhdf5-7 JFTR, the respective Source: hdf5 Debian changelog [2] entry is: --cut: http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog -- hdf5 (1.8.8-7.1) unstable; urgency=low * Non-maintainer upload. * Stop building the c++ libraries, nothing uses them. And don't version the libhdf5-7 symbols file, so the dependency can also be satisfied by the mpi packages' Provides. * Use DEB_HOST_ARCH instead of DEB_BUILD_ARCH in debian/rules. * Don't require root for debian/rules clean. -- Julien Cristau jcris...@debian.org Sat, 18 Feb 2012 12:25:35 + --cut: http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog -- The PTS entries for the packages affected are as follows. http://packages.qa.debian.org/h/hdf-eos5.html • [2012-02-24] hdf-eos5 5.1.13.dfsg.1-3 MIGRATED to testing (Britney) http://packages.qa.debian.org/libc/libcgns.html • [2012-01-24] Accepted 3.1.3.4-1 in unstable (low) (Sylvestre Ledru) http://packages.qa.debian.org/n/nexus.html • [2011-07-31] Accepted 4.2.1-svn1614-1 in unstable (low) (Tobias Stefan Richter) (Although nexus was re-built once as 4.2.1-svn1614-1+b1, it was on 2012-01-26, thus before hdf5_1.8.8-7.1, and still bearing a possibly unwarranted versioned dependency on libhdf5-7.) http://packages.qa.debian.org/r/r-cran-hdf5.html • [2012-01-18] Accepted 1.6.10-1 in unstable (low) (Dirk Eddelbuettel) http://packages.qa.debian.org/t/tessa.html • [2012-02-20] Accepted 0.3.1-6 in unstable (low) (Josselin Mouette) http://packages.qa.debian.org/u/udav.html • [2012-01-25] Accepted 0.7.1.2-3 in unstable (low) (Salvatore Bonaccorso) -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689500: RFS: python-eventlib/0.1.0-1
On 03/10/12 22:06, Jakub Wilk wrote: (I don't intend to sponsor this package.) Thanks for the feedback, I'll respond to some of the points, some I'm deferring to upstream (Saúl and AG Projects) as they are interested in becoming more involved with the Debian packaging This package and the related packages are based on artifacts created by upstream for their unofficial Debian packages. I have done some basic adaption (e.g. to DEP-5 copyright), but otherwise I have used the material from upstream. * Daniel Pocock dan...@pocock.com.au, 2012-10-03, 12:23: http://mentors.debian.net/debian/pool/main/p/python-eventlib/python-eventlib_0.1.0-1.dsc lintian reports: I: python-eventlib source: debian-watch-file-is-missing Fixed that one yesterday P: python-eventlib: no-upstream-changelog I: python-eventlib: description-synopsis-might-not-be-phrased-properly Furthermore, lintian4python reports: i: python-eventlib source: debian-pycompat-is-obsolete e: python-eventlib: except-shadows-builtin usr/share/pyshared/eventlib/db_pool.py:175: ValueError e: python-eventlib: except-shadows-builtin usr/share/pyshared/eventlib/httpd.py:497: ValueError e: python-eventlib: string-exception usr/share/pyshared/eventlib/saranwrap.py:654 (+ a bunch of pyflakes-* tags, most of which are likely either false positives or not worth caring.) The copyright file is not policy-compliant. Please see: https://lists.debian.org/debian-devel-announce/2006/03/msg00023.html Worse, it doesn't seem to be factually correct either. It says LGPL-2, whereas e.g. setup.py says MIT License. I've previously made mistakes with DEP-5 and lintian has identified them As for the LGPL-2 or MIT - the upstream tarball contains a debian/copyright referring to LGPL-2. So I leave it to them to have the final say on which they prefer. I'd use debhelper (= 8) instead of debhelper (= 8.0.0). The versioned build-dependency on python-all is insufficent; as per dh_python2 manpage it should be at least = 2.6.6-3~. Current standards version is 3.9.4. What is the purpose of Conflicts: python-eventlet? python-eventlib is a fork of python-eventlet upstream can clarify the need for the Conflicts header. Out of curiosity, why do you remove dist and MANIFEST in the clean target? Upstream seems to provide a test suite. Please run it at build time. I leave these for upstream comments Upstream provides some examples. It might be worth including the in the binary package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689293: dia menu entry should use /usr/bin/dia not /usr/bin/dia-normal
On 03.10.2012 12:38, schrieb Roland Stigge: Hi! Thanks you for your report! On 01/10/12 10:30, Andre Naujoks wrote: The installation of dia should add a menu entry to start dia with the link in /usr/bin/dia, so the choice of the alternatives system is taken into account. Currently /usr/bin/dia-normal is used, which bypasses the alternatives system. Interesting question. Currently, dia just installs menu files for dia(-normal) and dia-gnome each, which will both appear in the menu, if available. Now I wonder if menu entries should follow alternative system choices or not. Is there a policy about that or some common practice in other packages? Now that you mention it, I think I don't know any other package that uses the alternatives system the way dia does. The choice is basically a command line parameter. But I think dia should start in the same configuration regardless of where it is started from, be it a menu or the command line. Andre Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689500: RFS: python-eventlib/0.1.0-1
Hi, python-eventlib upstream here. Daniel Pocock wrote: On 03/10/12 22:06, Jakub Wilk wrote: (I don't intend to sponsor this package.) Thanks for the feedback, I'll respond to some of the points, some I'm deferring to upstream (Saúl and AG Projects) as they are interested in becoming more involved with the Debian packaging This package and the related packages are based on artifacts created by upstream for their unofficial Debian packages. I have done some basic adaption (e.g. to DEP-5 copyright), but otherwise I have used the material from upstream. * Daniel Pocockdan...@pocock.com.au, 2012-10-03, 12:23: http://mentors.debian.net/debian/pool/main/p/python-eventlib/python-eventlib_0.1.0-1.dsc lintian reports: I: python-eventlib source: debian-watch-file-is-missing Fixed that one yesterday P: python-eventlib: no-upstream-changelog I: python-eventlib: description-synopsis-might-not-be-phrased-properly Furthermore, lintian4python reports: i: python-eventlib source: debian-pycompat-is-obsolete e: python-eventlib: except-shadows-builtin usr/share/pyshared/eventlib/db_pool.py:175: ValueError e: python-eventlib: except-shadows-builtin usr/share/pyshared/eventlib/httpd.py:497: ValueError e: python-eventlib: string-exception usr/share/pyshared/eventlib/saranwrap.py:654 (+ a bunch of pyflakes-* tags, most of which are likely either false positives or not worth caring.) The copyright file is not policy-compliant. Please see: https://lists.debian.org/debian-devel-announce/2006/03/msg00023.html Worse, it doesn't seem to be factually correct either. It says LGPL-2, whereas e.g. setup.py says MIT License. Eventlet was MIT licensed so I don't see a reason to change that. If LGPL is mentioned somewhere we should probably change that. I've previously made mistakes with DEP-5 and lintian has identified them As for the LGPL-2 or MIT - the upstream tarball contains a debian/copyright referring to LGPL-2. So I leave it to them to have the final say on which they prefer. I'd use debhelper (= 8) instead of debhelper (= 8.0.0). The versioned build-dependency on python-all is insufficent; as per dh_python2 manpage it should be at least= 2.6.6-3~. Current standards version is 3.9.4. What is the purpose of Conflicts: python-eventlet? python-eventlib is a fork of python-eventlet upstream can clarify the need for the Conflicts header. This is a leftover from when the package wasn't actually called eventlib. I can be safely removed now. Out of curiosity, why do you remove dist and MANIFEST in the clean target? They are generated by python setup.py sdist and can cause trouble if you add a new file but forget to remove MANIFEST and run sdist sgain. Upstream seems to provide a test suite. Please run it at build time. I'm not sure if the test suite was adapted to the project rename. I leave these for upstream comments Upstream provides some examples. It might be worth including the in the binary package. Regards, -- Saúl Ibarra Corretgé http://saghul.net/blog | http://about.me/saghul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689573: RFP: rhodecode -- an open source source control management system for Mercurial and Git
Package: wnpp Severity: wishlist * Package name: rhodecode Version : 1.4.3 Upstream Author : Marcin Kuźminski * URL : http://www.rhodecode.org * License : GPL-3 Programming Lang: Python Description : an open source source control management system for Mercurial and Git An open source source control management system for Mercurial and GIT with code-reviews, built in push/pull server, LDAP/AD, permissions system and full text search. .. RhodeCode is similar in some respects to Github or Bitbucket, however RhodeCode can be run as standalone hosted application on your own server. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633297: funguloids: FTBFS everywhere: error: reference to 'map' is ambiguous
Hi Paul, thanks for your elaboration. Am 02.10.2012 17:11, schrieb Paul Wise: was lost. At this point I got a bit de-motivated and slack, moved on to other things. So we have to treat the pre-rendered files as source, replace them where possible over time and live with them until then. I don't consider the mpak file format such a critical issue, as long as the file contents are declared free and we have a free tool to handle it. Currently, the mpak.py script does not include a license, but we could ask upstream for one. IIRC you said you were in contact with him? Then we could repair the data files in the Debian package on the fly and finally upload a new package. Please remember that the game is licensed under the zlib license, which does not require a prefered form for modification. If you would like to join upstream, then I will try to fix the remaining issues in the tar2git script (which are because upstream developed Windows and Linux versions separately) and push to git. After that the Arch, Debian, Maemo and Mandriva patches can be merged, the code adapted to not using the mpak format and a new release made. I am not that much interested in joining upstream, but more in fixing what we already have in Debian. However, I'd by happy to help if there's anything I can do. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689215: funguloids: Please check package depencies
Am 02.10.2012 23:04, schrieb Stephen Kitt: That's fine by me, thanks! I am currently discussing the further development with Paul Wise in #633297. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689574: Wrong argument type in pidgin_create_prpl_icon causing undefined behaviour
Package: purple-plugin-pack Version: 2.6.3-2 While building the package using our research compiler infrastructure we noticed the following code with undefined behaviour (the effective result will at best depend on ROUNDING_MODE): autoprofile/preferences.c, line 345: pixbuf = pidgin_create_prpl_icon(account, 0.5); The 0.5 is invalid here, as an argument of type PidginPrplIconSize is expected, which is an enum. Best, Michael pgpHDyAAXecXM.pgp Description: PGP signature
Bug#688433: biomaj: still modifies /usr/share/biomaj/bin/env.sh
Package: biomaj Followup-For: Bug #688433 Control: found -1 1.2.0-8 Hi, I don't know what /usr/share/biomaj/bin/env.sh is being used for, but modifying a shipped file is not a good idea - it will be overwritten on every upgrade. Andreas biomaj_1.2.0-8.log.gz Description: GNU Zip compressed data
Bug#689554: paragraph-separating blank line in debian/control before contents
Hi, On Wed, 03 Oct 2012, Michael Tautschnig wrote: By policy, blank lines separate paragraphs, comments are discarded, so we end up with an empty first paragraph. Policy, however, requires that the *first* paragraph contains essential package information (Policy 5.2). The blank line should be removed or a comment marker should be inserted. The current setup breaks at least pbuilder's build-dependency parsing, which relies on this fact. We can certainly change quilt, but IMO it's more of a bug in pbuilder than anything else. Considering something empty to be a paragraph on its own is weird. The first non-empty non-comment line ought to start the first paragraph. Just because you have an empty line doesn't mean that there should be something before it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689575: fonts-liberation: breaks applications relying on the ttf-liberation name
Package: fonts-liberation Version: 1.07.2-5 Severity: important Control: affects -1 + calibre The fonts-liberation package provides the ttf-liberation package, but does not ship a compatibility symlink for /usr/share/fonts/truetype/ttf-liberation. This affects applications such as calibre, which now contain a dangling symbolic link. The issue cannot be fixed entirely in calibre, because upgrading ttf-liberation to the transitional package breaks calibre. I see the following options: 1) Add ln -s liberation /usr/share/fonts/truetype/ttf-liberation in the fonts-liberation package and remove the link for jessie. 2) Add Breaks to for all affected packages. Of course the calibre maintainer should fix their part (#674838) as well, but they have not yet done so despite the presence of a patch. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689576: entangle: modifies a shipped file: /usr/share/glib-2.0/schemas/gschemas.compiled
Package: entangle Version: 0.4.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package modifies a file it ships: /usr/share/glib-2.0/schemas/gschemas.compiled. Or maybe ships a file that is created/updated by triggers from another package, I cant say for sure. But there is the following cleanup code: libglib2.0-0:amd64.postrm:rm -f /usr/share/glib-2.0/schemas/gschemas.compiled so I think entangle should *not ship* this file and let glib do it's bookkeeping job. cheers, Andreas entangle_0.4.1-1.log.gz Description: GNU Zip compressed data
Bug#689293: dia menu entry should use /usr/bin/dia not /usr/bin/dia-normal
Hi! On 10/04/2012 09:07 AM, Andre Naujoks wrote: On 01/10/12 10:30, Andre Naujoks wrote: The installation of dia should add a menu entry to start dia with the link in /usr/bin/dia, so the choice of the alternatives system is taken into account. Currently /usr/bin/dia-normal is used, which bypasses the alternatives system. Interesting question. Currently, dia just installs menu files for dia(-normal) and dia-gnome each, which will both appear in the menu, if available. Now I wonder if menu entries should follow alternative system choices or not. Is there a policy about that or some common practice in other packages? Now that you mention it, I think I don't know any other package that uses the alternatives system the way dia does. The choice is basically a command line parameter. But I think dia should start in the same configuration regardless of where it is started from, be it a menu or the command line. Now I understand what you mean :-) : Dia actually has 4 alternatives entries: dia-normal and dia-gnome, with an -integrated variant each, to provide the integrated window view as default. The upstream default (without command line option) is non-integrated, and on the Debian desktop, --integrated would be best. For consolidation, we can consider doing only the integrated variant, at least for the menus. Still, we have dia-normal and dia-gnome. Does your report apply to this as well? My question about other packages referred to possible examples of menu entries interacting with alternatives config. Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689577: smbind: modifies shipped files: /usr/share/dbconfig-common/data/smbind/install/{my, pg}sql
Package: smbind Version: 0.4.7-5.2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package modifies some shipped files. This looks like a bad interaction with dbconfig-common, as these files will be overwritten on every upgrade ... debsums reports modification of the following files, from the attached log (scroll to the bottom...): /usr/share/dbconfig-common/data/smbind/install/mysql /usr/share/dbconfig-common/data/smbind/install/pgsql cheers, smbind_0.4.7-5.2.log.gz Description: GNU Zip compressed data
Bug#689419: freeradius: segfaults in rlm_perl
On Tue, Oct 02, 2012 at 02:47:26PM +0200, Miquel van Smoorenburg wrote: Package: freeradius Version: 2.1.12+dfsg-1.1 Severity: important Freeradius can dynamically grow and shrink its thread pool. When growing the thread pool, multiple threads will call perl_clone at the same time, which can result in segfaults. The call to perl_clone should be protected with a mutex. This was reported in http://lists.freeradius.org/pipermail/freeradius-devel/2011-November/006568.html and the patch was integrated for the 2.2.0 release. There hasn't been a 2.1.x release with this patch yet. The patch for 2.1.x is here: https://github.com/alandekok/freeradius-server/commit/ecb3cd1dbedb764ab98532dae5e0b5bfc9571b00 Did you intend to file this as important and not serious or? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689578: sympa: modifies conffiles (policy 10.7.3): /etc/syslog.conf
Package: sympa Version: 6.1.11~dfsg-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package modifies conffiles. And even worse, it's a conffile owned by a different package. This is forbidden by the policy, see http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files 10.7.3: [...] The easy way to achieve this behavior is to make the configuration file a conffile. [...] This implies that the default version will be part of the package distribution, and must not be modified by the maintainer scripts during installation (or at any other time). Note that once a package ships a modified version of that conffile, dpkg will prompt the user for an action how to handle the upgrade of this modified conffile (that was not modified by the user). Further in 10.7.3: [...] must not ask unnecessary questions (particularly during upgrades) [...] If a configuration file is customized by a maintainer script after having asked some debconf questions, it may not be marked as a conffile. Instead a template could be installed in /usr/share and used by the postinst script to fill in the custom values and create (or update) the configuration file (preserving any user modifications!). This file must be removed during postrm purge. ucf(1) may help with these tasks. See also http://wiki.debian.org/DpkgConffileHandling In https://lists.debian.org/debian-devel/2012/09/msg00412.html and followups it has been agreed that these bugs are to be filed with severity serious. debsums reports modification of the following files, from the attached log (scroll to the bottom...): /etc/syslog.conf cheers, Andreas sympa_6.1.11~dfsg-4.log.gz Description: GNU Zip compressed data
Bug#689579: unblock: dvi2ps-fontdesc-morisawa5/0.5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package dvi2ps-fontdesc-morisawa5
This version fixes the grave bug#688253 i.e. unistallable
in sid.
Basically, it is a dependency problem and we need to change
dependency from obsolete vfdata-morisawa5 to texlive-lang-cjk.
Also because of this change, the package should be modified to
use TFM and/or VF files of texlive-lang-cjk so I did it too.
So debdiff output:
diff -Nru dvi2ps-fontdesc-morisawa5-0.4/debian/changelog
dvi2ps-fontdesc-morisawa5-0.5/debian/changelog
--- dvi2ps-fontdesc-morisawa5-0.4/debian/changelog 2008-07-23
11:20:11.0 +0900
+++ dvi2ps-fontdesc-morisawa5-0.5/debian/changelog 2012-10-04
09:34:58.0 +0900
@@ -1,3 +1,15 @@
+dvi2ps-fontdesc-morisawa5 (0.5) unstable; urgency=low
+
+ * Modify to be compatible with new TeXLive2012 environment.
+So we can't use the package with vfdata-morisawa5 anymore and we removed
+vfdata-morisawa5 from Depends field.
+ * Fix a control file so that this is installable. Thanks to Andreas Beckmann
+debian AT abeckmann.de and Colin Watson cjwatson AT ubuntu.com.
+(Closes: #688253)
+ * To erase lintian warnings, we refine debian/rules a bit.
+
+ -- Atsuhito KOHDA ko...@debian.org Wed, 03 Oct 2012 14:29:25 +0900
+
dvi2ps-fontdesc-morisawa5 (0.4) unstable; urgency=low
* Renamed fontdesc file bikan-morisawa (to bikan-morisawa5) to avoid
diff -Nru dvi2ps-fontdesc-morisawa5-0.4/debian/compat
dvi2ps-fontdesc-morisawa5-0.5/debian/compat
--- dvi2ps-fontdesc-morisawa5-0.4/debian/compat 2008-05-29 17:24:21.0
+0900
+++ dvi2ps-fontdesc-morisawa5-0.5/debian/compat 2012-10-03 14:47:06.0
+0900
@@ -1 +1 @@
-4
+6
diff -Nru dvi2ps-fontdesc-morisawa5-0.4/debian/control
dvi2ps-fontdesc-morisawa5-0.5/debian/control
--- dvi2ps-fontdesc-morisawa5-0.4/debian/control2008-05-29
17:31:02.0 +0900
+++ dvi2ps-fontdesc-morisawa5-0.5/debian/control2012-10-03
16:44:14.0 +0900
@@ -7,7 +7,7 @@
Package: dvi2ps-fontdesc-morisawa5
Architecture: all
-Depends: dvi2ps (= 4.1j), vfdata-morisawa5 ( 0.0.20020122-12)
+Depends: ${misc:Depends}, dvi2ps (= 5.1j), texlive-lang-cjk
Recommends: ptex-bin, okumura-clsfiles
Description: fontdesc files of dvi2ps for Morisawa Basic-5 type faces
You can convert DVI file with Morisawa Basic-5 type faces of vfdata-morisawa5
diff -Nru dvi2ps-fontdesc-morisawa5-0.4/debian/copyright
dvi2ps-fontdesc-morisawa5-0.5/debian/copyright
--- dvi2ps-fontdesc-morisawa5-0.4/debian/copyright 2008-05-29
17:31:02.0 +0900
+++ dvi2ps-fontdesc-morisawa5-0.5/debian/copyright 2012-10-03
16:44:14.0 +0900
@@ -7,6 +7,3 @@
ftp://ftp.math.s.chiba-u.ac.jp/tex
and dvi2ps is in main (i.e. DFSG-compliant) so this package goes in main.
-
-Note vfdata-morisawa5, on which this package depends, changed license to
-the modified BSD.
diff -Nru dvi2ps-fontdesc-morisawa5-0.4/debian/dirs
dvi2ps-fontdesc-morisawa5-0.5/debian/dirs
--- dvi2ps-fontdesc-morisawa5-0.4/debian/dirs 2003-02-14 12:00:17.0
+0900
+++ dvi2ps-fontdesc-morisawa5-0.5/debian/dirs 2012-10-03 14:55:48.0
+0900
@@ -1,2 +1,2 @@
-usr/share/texmf/dvi2ps
+usr/lib/dvi2ps
etc/texmf/dvi2ps
diff -Nru dvi2ps-fontdesc-morisawa5-0.4/debian/rules
dvi2ps-fontdesc-morisawa5-0.5/debian/rules
--- dvi2ps-fontdesc-morisawa5-0.4/debian/rules 2008-07-23 11:23:50.0
+0900
+++ dvi2ps-fontdesc-morisawa5-0.5/debian/rules 2012-10-03 16:40:08.0
+0900
@@ -8,7 +8,7 @@
# This is the debhelper compatability version to use.
PACK=dvi2ps-fontdesc-morisawa5
-TXMF=/usr/share/texmf
+TXMF=/usr/lib
INSTDIR=$(CURDIR)/debian/$(PACK)$(TXMF)/dvi2ps
ETCDIR=$(CURDIR)/debian/$(PACK)/etc/texmf/dvi2ps
@@ -19,7 +19,9 @@
touch configure-stamp
-build: configure-stamp build-stamp
+build: build-arch build-indep
+build-arch: configure-stamp build-stamp
+build-indep: configure-stamp build-stamp
build-stamp:
dh_testdir
diff -Nru dvi2ps-fontdesc-morisawa5-0.4/fontsk/asc-morisawa5
dvi2ps-fontdesc-morisawa5-0.5/fontsk/asc-morisawa5
--- dvi2ps-fontdesc-morisawa5-0.4/fontsk/asc-morisawa5 2008-07-23
11:31:59.0 +0900
+++ dvi2ps-fontdesc-morisawa5-0.5/fontsk/asc-morisawa5 2012-10-03
16:09:32.0 +0900
@@ -1,6 +1,6 @@
# built-in morisawa fonts for pTeX / ASCII Nihongo TeX
# First, convert pTeX dvi - built-in kanji dvi by virtual font
-font jvf * 0 $tmf/vf/ascii-mor5/%f.vf
-#font jvf * 0 a2$bk-%f
+font jvf * 0 $texl/vf/ptex/morisawa/%f.vf
+#font jvf * 0 $texl/vf/morisawa/%f.vf
# then, use built-in kanji
fontdesc bikan-$extra
diff -Nru dvi2ps-fontdesc-morisawa5-0.4/fontsk/bikan-morisawa5
dvi2ps-fontdesc-morisawa5-0.5/fontsk/bikan-morisawa5
--- dvi2ps-fontdesc-morisawa5-0.4/fontsk/bikan-morisawa52008-05-29
14:25:37.0 +0900
+++ dvi2ps-fontdesc-morisawa5-0.5/fontsk/bikan-morisawa5
Bug#688433: biomaj: still modifies /usr/share/biomaj/bin/env.sh
Le 4 oct. 2012 09:48, Andreas Beckmann deb...@abeckmann.de a écrit : Package: biomaj Followup-For: Bug #688433 Control: found -1 1.2.0-8 Hi, I don't know what /usr/share/biomaj/bin/env.sh is being used for, but modifying a shipped file is not a good idea - it will be overwritten on every upgrade. It is an environment setup, automatically set by the application, not the user. It is done by upstream install code. This file can safely be overwritten at each upgrade. Olivier Andreas
Bug#689554: paragraph-separating blank line in debian/control before contents
Hi, On Wed, 03 Oct 2012, Michael Tautschnig wrote: By policy, blank lines separate paragraphs, comments are discarded, so we end up with an empty first paragraph. Policy, however, requires that the *first* paragraph contains essential package information (Policy 5.2). The blank line should be removed or a comment marker should be inserted. The current setup breaks at least pbuilder's build-dependency parsing, which relies on this fact. We can certainly change quilt, but IMO it's more of a bug in pbuilder than anything else. Considering something empty to be a paragraph on its own is weird. The first non-empty non-comment line ought to start the first paragraph. Just because you have an empty line doesn't mean that there should be something before it. Sorry, I think I should have included a pointer to the discussion on debian-devel [1] as well. If we stick close to RFC822 than a blank line AFAIK does have a meaning and must not be ignored. But we might as well just agree that we want a more human and natural interpretation of paragraphs and amend policy accordingly. For now, however, I'm seeing only a small number of packages make use of such a blank line (see also one of the messages in [1] for data), hence it seems to be worth fixing. Best, Michael [1] http://lists.debian.org/debian-devel/2012/10/msg00026.html pgphCRPDNYRtE.pgp Description: PGP signature
Bug#689419: freeradius: segfaults in rlm_perl
On 4-10-12 10:05 AM, Josip Rodin wrote: On Tue, Oct 02, 2012 at 02:47:26PM +0200, Miquel van Smoorenburg wrote: Package: freeradius Version: 2.1.12+dfsg-1.1 Severity: important Freeradius can dynamically grow and shrink its thread pool. When growing the thread pool, multiple threads will call perl_clone at the same time, which can result in segfaults. The call to perl_clone should be protected with a mutex. This was reported in http://lists.freeradius.org/pipermail/freeradius-devel/2011-November/006568.html and the patch was integrated for the 2.2.0 release. There hasn't been a 2.1.x release with this patch yet. The patch for 2.1.x is here: https://github.com/alandekok/freeradius-server/commit/ecb3cd1dbedb764ab98532dae5e0b5bfc9571b00 Did you intend to file this as important and not serious or? I wasn't sure. We are hitting this problem in production, but if you don't use rlm_perl freeradius works fine otherwise. So for freeradius in total I'd say a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone., while for the rlm_perl module it would be more like it makes the package unsuitable for release. Perhaps I should have tagged it serious, it can always be downgraded if the maintainer doesn't agree, right? Mike. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689580: Please split the Opentype fonts into a separate package
Package: tex-gyre,lmodern
Severity: wishlist
Hi,
as the subject line suggests, please package the Opentype flavours of
the tex-gyre and lmodern fonts in separate packages. While the
opentype flavours may be useful for any fontconfig-using application,
the rest of the packages is merely only useful in the TeX ecosystem.
Furthermore, please compare:
$ du /usr/share/texmf/fonts/opentype/public/tex-gyre
4424/usr/share/texmf/fonts/opentype/public/tex-gyre
$ dpkg-query -f='${Installed-Size}\n' -W tex-gyre
30774
Of course, the fontconfig files discussed in #687940 and #686098 must
get included in these packages as well.
Regarding the names for the split-off packages, this should get
discussed in another bug report, soon to come. ;)
- Fabian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689575: fonts-liberation: breaks applications relying on the ttf-liberation name
Am 04.10.2012 09:51, schrieb Helmut Grohne: The fonts-liberation package provides the ttf-liberation package, but does not ship a compatibility symlink for /usr/share/fonts/truetype/ttf-liberation. Indeed, it is wrong for fonts-liberation to Provides: ttf-liberation without actually providing the expected files. Whose idea was that? ;) Of course the calibre maintainer should fix their part (#674838) as well, but they have not yet done so despite the presence of a patch. Yes, this needs to be fixed ASAP, but we have to fix our package as well. Thanks, - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689293: dia menu entry should use /usr/bin/dia not /usr/bin/dia-normal
On 04.10.2012 09:57, schrieb Roland Stigge: Hi! On 10/04/2012 09:07 AM, Andre Naujoks wrote: On 01/10/12 10:30, Andre Naujoks wrote: The installation of dia should add a menu entry to start dia with the link in /usr/bin/dia, so the choice of the alternatives system is taken into account. Currently /usr/bin/dia-normal is used, which bypasses the alternatives system. Interesting question. Currently, dia just installs menu files for dia(-normal) and dia-gnome each, which will both appear in the menu, if available. Now I wonder if menu entries should follow alternative system choices or not. Is there a policy about that or some common practice in other packages? Now that you mention it, I think I don't know any other package that uses the alternatives system the way dia does. The choice is basically a command line parameter. But I think dia should start in the same configuration regardless of where it is started from, be it a menu or the command line. Now I understand what you mean :-) : Dia actually has 4 alternatives entries: dia-normal and dia-gnome, with an -integrated variant each, to provide the integrated window view as default. The upstream default (without command line option) is non-integrated, and on the Debian desktop, --integrated would be best. For consolidation, we can consider doing only the integrated variant, at least for the menus. That would mean the problem is just switched around. If I choose to change what my dia points to (via update-alternatives) I'd expect this change to be used when I start dia via a menu. I think it would be best to remove the alternatives to the non integrated forms and use the alternative chosen to launch dia from a menu. This way dia is consistently used in its integrated form and only if you really want to, you can start dia-normal. Still, we have dia-normal and dia-gnome. Does your report apply to this as well? My question about other packages referred to possible examples of menu entries interacting with alternatives config. I don't know of any, but I don't really know that many packages in depth. dia-gnome should be one alternative in the alternatives group. Andre Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689581: Please adopt the pkg-fonts team's package naming convention
Package: tex-gyre,lmodern
Severity: wishlist
Hi,
again, the subject line already tells it all. The pkg-fonts team's
package naming convention currently looks like
fonts-[$(foundry)-]$(family)
where the $(foundry) part is optional (but would be gust in both
cases, I guess).
There are two things to keep in mind that are particular for the two
packages in question:
1) The tex-gyre package name already contains a minus '-'.
I don't think we have a strict rule for this, but for the
fonts-linuxlibertine package we simply removed the minus from the
font family name in order to avoid confusion about linux being a
foundry.
2) Should you follow my requests from #689575 and #689580, there would
be two packages from the same source shipping the same fonts in
different formats. While this should be avoided whenever possible, I
don't think we have a strict rule about dealing with the font packages
names when this is necessary (and it definitely *is* in this case).
For the GNU Freefont we thus introduced a fonts-freefont-otf and a
fonts-freefont-ttf package.
Finally, if you decide against splitting the Opentype flavours off
into separate packages we would end up with
fonts-texgyre
and
fonts-lmodern
But if you decide to introduce separate packages for the Opentype
flavours, we would have to distinguish the packages from each other.
I'd suggest
fonts-{lmodern,texgyre}-otf
or simply
fonts-{lmodern,texgyre}
and either
fonts-{lmodern,texgyre}-extra
(or -type1 or -tex or -latex or whatever)
or
texlive-fonts-{lmodern,texgyre}
I'll add the pkg-fonts team in CC for further discussion.
- Fabian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689582: ExtractTar: 100 char long path names get truncated to 99 chars
Package: apt
Version: 0.9.7.5
Severity: important
Dear Maintainer,
When a data.tar.{gz,xz} contains a path name that is exactly
100 characters long, it will get truncated to 99 chars upon
extraction in ExtractTar::Go().
It seems in older gnu tar versions (pre-wheezy) the behavior
was more conservative and to use the 100 byte path field only
for path names less than 100 chars long, and to switch to
using long names already at 100 chars. In wheezy the
behavior seems to be different and path names of exactly
100 chars long can fill the whole reserved space in the tar
and then get truncated in ExtractTar::Go():
// Grab the filename
if (LastLongName.empty() == false)
Itm.Name = (char *)LastLongName.c_str();
else
{
Tar-Name[sizeof(Tar-Name)-1] = 0;
Itm.Name = Tar-Name;
}
Quick way to reproducing the problem using a generated dummy
deb package and python-apt is included as an attachment.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/11 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 apt depends on:
ii debian-archive-keyring 2012.4
ii gnupg 1.4.12-4+b1
ii libapt-pkg4.12 0.9.7.5
ii libc6 2.13-35
ii libgcc1 1:4.7.1-7
ii libstdc++6 4.7.1-7
apt recommends no packages.
#! /usr/bin/python
import os
import apt_inst
paths = []
for i in range(98,103):
path = (%03d % i).ljust(i,x)
file(path, w)
paths.append(path)
assert not os.system(tar zcf data.tar.gz %s % .join(paths))
file(control.tar.gz, w)
file(debian-binary, w)
assert not os.system(ar cr test.deb data.tar.gz control.tar.gz debian-binary)
def cb(a, b):
print %3d %s % (len(a.name), a.name)
apt_inst.DebFile(file(test.deb, rb)).data.go(cb)
Bug#686098: Fonts from package misbehave in exported PDF
Am 25.09.2012 09:28, schrieb Fabian Greffrath: Well, fair enough. The 35 Postscript core fonts are generally expected in Type 1 format and the alias.conf file will map them to the Tex-Gyre fonts in Opentype format. However, I think for fontconfig-using applications this shouldn't be a big deal and things definitely look better in some situations (e.g. web pages requesting to get rendered in Helvetica look awefull when the browser falls back to the Type 1 Nimbus Sans L). So, I think it's a conservative but reasonable choice - whereas enabling the alias.conf would be reasonable as well. ;) Erm, please install the fontconfig file. We need a better looking alternative for the 35 Postscript core fonts than the Type 1 files provided by gsfonts. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689583: swi-prolog-nox depends on libncursesw5 on amd64, but not on proper -dev package
Package: swi-prolog-nox Version: 5.10.4-3 Severity: serious Justification: breaks build of other packages swi-prolog-nox lists as dependencies: libncursesw5 (= 5.6+20070908) [amd64] libncurses5 (= 5.5-5~) [not amd64] libncurses5-dev This breaks any build using swipl-ld on *amd64* as libncursesw5.so will not be available. Best, Michael pgpFtvLlT7NBs.pgp Description: PGP signature
Bug#689584: Please remove sleep patch which does not work and does not resolve any problem
Package: aiccu Severity: normal Creating a new bug as 531003 is archived and thus can't comment there any more unfortunately. Related links: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531003 https://bugs.launchpad.net/bugs/1058883 Original Message Subject: Please remove sleep patch which does not work and does not resolve any problem Date: Thu, 04 Oct 2012 00:52:26 +0200 From: Jeroen Massar jer...@unfix.org To: 531...@bugs.debian.org, 1058...@bugs.launchpad.net [Caleb: thanks for finding the origin of this fix] So it seems this sleep fix, by just restarting (I thought Debian was not an ancient Microsoft product where one just reboots all the time), which was not tested is now causing issues for people: https://bugs.launchpad.net/bugs/1058883 Would it not be prudent to revert such a patch, or better, never have applied it if the patch was not tested or proven working at all?!? It seems there are no logs or other details included about this issue, just a it does not work and I restart it now it works and then a patch for just restarting it. Would be great if there actually where logs for this issue or other details that would demonstrate the problem. Maybe time to remove this patch? As I have stated in various places: AICCU does not need to be restarted, the protocols used should handle it, that is why those protocols, exist. If the tunnel 'breaks', please provide details of what is broken so that the real problem can be addressed just restarting it does not resolve such a problem. Bigger note: If anybody has logs which demonstrate breakage please provide them, then I can take those situations along in the testing of the new AICCU. I've added to the to-check list to check with Virtualbox how a acpisleepbutton event affects the state of AICCU, thus lets see what the result of such a test is (best I can do, no Linux on a laptop anywhere near me at the moment... but this should be similar) Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593134: (unreleased) libprophet-perl: GPL in debian/copyright
On Wed, 2012-10-03 at 21:19 -0700, Ioan Rogers wrote: I'll strip and set up symlinks for those that are packaged, Erg, it seems I can't yet. Prophet checks the resolved path is under its static root before serving it up. So we'll have to keep the embedded copy of tablesorter for now. Ioan signature.asc Description: This is a digitally signed message part
Bug#593134: (unreleased) libprophet-perl: GPL in debian/copyright
-=| Ioan Rogers, 04.10.2012 01:45:17 -0700 |=- On Wed, 2012-10-03 at 21:19 -0700, Ioan Rogers wrote: I'll strip and set up symlinks for those that are packaged, Erg, it seems I can't yet. Prophet checks the resolved path is under its static root before serving it up. So we'll have to keep the embedded copy of tablesorter for now. Maybe that check can be fixed? Or at least replace embedded copy with the packaged content at build time? This way if there is a problem in that code a rebuild against fixed libjs-jquery-tablesorter would fix it. signature.asc Description: Digital signature
Bug#689585: ssh: please don't complete hosts found after Hostname in .ssh/config
Package: bash-completion
Version: 1:2.0-1
Severity: minor
Hello,
my ssh-config contains something like:
Host login.sd
Hostname login.some.domain
ProxyCommand none
Host somehost.sd
Hostname somehost.some.domain
Host *.sd
ProxyCommand ssh login.sd nc -w 1 %h %p
So now if I type
$ ssh somehotab
I'd like to only getting somehost.sd suggested, because I cannot connect
to somehost.some.domain directly anyhow.
So I suggest to do
-local hosts=$( sed -ne 's/^[
\t]*[Hh][Oo][Ss][Tt]\([Nn][Aa][Mm][Ee]\)\{0,1\}['$'\t
'']\{1,\}\([^#*?]*\)\(#.*\)\{0,1\}$/\2/p' ${config[@]} )
+local hosts=$( sed -ne 's/^[ \t]*[Hh][Oo][Ss][Tt]['$'\t
'']\{1,\}\([^#*?]*\)\(#.*\)\{0,1\}$/\1/p' ${config[@]} )
in /usr/share/bash-completion/bash_completion.
Obviously this changes the result for people that want the names after
Hostname completed. For those you can just add an otherwise empty Host
section.
Best regards
Uwe
-- System Information:
Debian Release: 6.0.5
APT prefers stable-updates
APT policy: (900, 'stable-updates'), (900, 'proposed-updates'), (900,
'stable'), (800, 'testing-proposed-updates'), (800, 'testing'), (700,
'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-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 bash-completion depends on:
ii bash 4.1-3 The GNU Bourne Again SHell
ii dpkg 1.16.8 Debian package management system
bash-completion recommends no packages.
bash-completion 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#633297: funguloids: FTBFS everywhere: error: reference to 'map' is ambiguous
On Thu, 2012-10-04 at 09:26 +0200, Fabian Greffrath wrote: Currently, the mpak.py script does not include a license, but we could ask upstream for one. IIRC you said you were in contact with him? I've sent him a mail just now, I don't expect a response. The alternative to using mpak.py btw is to use the C++ code in mpak.cpp to do the packing/unpacking. Please remember that the game is licensed under the zlib license, which does not require a prefered form for modification. The license is not what I was concerned about. I was concerned about the practicalities of developing the game, without data source it is harder to improve the artwork, just like it is harder to improve the executable/engine if you don't have non-obfuscated C++ code. In addition, Debian has promised to ship source to our users. I am not that much interested in joining upstream, but more in fixing what we already have in Debian. However, I'd by happy to help if there's anything I can do. Ok, thanks for your interest anyway. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#689586: Newer version that fixes blue skin in Flash
Package: libvdpau1 Version: 0.4.1-7 Nearly 500 Ubuntu users reported that they are affected by blue skin in e.g. youtube videos using recent flash player when libvdpau1 is in use. It's entirely Adobe's fault for this deffect: https://bugs.launchpad.net/ubuntu/+source/adobe-flashplugin/+bug/967091 Please upload libvdpau 0.5 that makes special non-default setting for making special case for flashplayer: http://lists.x.org/archives/xorg-announce/2012-September/002066.html Regards, Ognyan Kulev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689586: Newer version that fixes blue skin in Flash
On 2012-10-04 11:10, Ognyan Kulev wrote: Package: libvdpau1 Version: 0.4.1-7 Nearly 500 Ubuntu users reported that they are affected by blue skin in e.g. youtube videos using recent flash player when libvdpau1 is in use. It's entirely Adobe's fault for this deffect: https://bugs.launchpad.net/ubuntu/+source/adobe-flashplugin/+bug/967091 Please upload libvdpau 0.5 that makes special non-default setting for making special case for flashplayer: http://lists.x.org/archives/xorg-announce/2012-September/002066.html That patch has been applied since 0.4.1-6. There are no changes in 0.5 that haven't been backported to 0.4.1. Expect a 0.5 upload after wheezy's release. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522163: apt-cacher: change AUTOSTART to ENABLED in /etc/default/apt-cacher
package apt-cacher reassign 522163 debian-policy retitle 522163 Consistent variable names in /etc/default/* for grep thanks On Tue, Mar 02, 2010 at 08:19:18PM +, Mark Hindley wrote: On Wed, Apr 01, 2009 at 01:36:59PM +0300, Jari Aalto wrote: Package: apt-cacher Version: 1.6.8 Severity: wishlist $ cd /etc/default $ grep -i enable.*= * bootlogd:2:BOOTLOGD_ENABLE=No icecast2:18:ENABLE=false rsync:8:RSYNC_ENABLE=false smartmontools:6:#enable_smart=/dev/hda /dev/hdb spamassassin:8:ENABLED=1 It would be good if apt-cacher would use similar variable: ENABLED=0 instead of current: AUTOSTART=0 This would help grepping which services are 'enabled'. Thanks for this. I have looked into it and whilst the change would be easy to do, there is no accepted standard for this. A number of services use RUN_DAEMON or something similar. I suggest that you start a discussion on debian-devel and reach a consensus which gets included in Debian Policy and then we all know what is expected. Mark I am going to reassign this to debian-policy as I think that is the right place to develop a consensus. Mark -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633297: funguloids: FTBFS everywhere: error: reference to 'map' is ambiguous
On Thu, 2012-10-04 at 17:04 +0800, Paul Wise wrote:
I've sent him a mail just now, I don't expect a response.
Wow, he replied immediately, see the attached files.
--
bye,
pabs
http://bonedaddy.net/pabs3/
---BeginMessage---
Hi Paul,
What is the license for mpak.py? Can you release it under a free license
such as the GNU GPL or the BSD/MIT/Expat licenses?
Here you go, brand new mpak.py version licensed under the MIT license.. :)
Cheers,
--
Mika
mpak.py
Description: Binary data
---End Message---
#!/usr/bin/env python
MPAK package handling utility
Version 1.5 (Python-implementation)
Copyright (c) 2008, 2012, Mika Halttunen. http://www.mhgames.org
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the Software),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Description follows:
This command line tool allows creation and extraction of MPAK (.mpk) packages used
in several of my games. MPAK is a simple WAD-like file format of mine, that allows storing
the game data in one single .mpk file. I originally had a very crude command line program
bit like this one (written in C++), and decided to write this Python-implementation as
an Python-programming excercise. So, it's my first Python program. :)
Version history:
v1.5: Licensed under MIT license (no functional changes)
v1.4: The first Python version
v1.0 -- v1.31: The original C++ implementation
import getopt, sys
import os
import traceback
import struct
import binascii
import fnmatch
import shutil
from ctypes import c_uint32
def usage():
Prints the program usage.
print MPAK package handling utility
print Version 1.5 (Python-implementation)
print Copyright (c) 2008, 2012, Mika Halttunen.
print
print Usage:, sys.argv[0],[switch],-f pakfile.mpk,[file1],[file2], [...], [fileN]
print where [switch] is one of the following:
print -f, --file=FILE Use package FILE
print -c, --create Create a new package with files 'file1' to 'fileN'
print -l, --listList the files from given package
print -e, --extract Extract all files (by default) from given package. If you
print want to only extract some specific files, you can name
print them individually, and/or use wildcards (i.e. *.png).
print You can supply path where to extract with -p.
print -p, --path=PATH Extract to PATH (created if doesn't exist)
print -h, --helpPrint this usage text
print
def errorMsg(msg):
Prints an error message and exits.
try:
pos = traceback.extract_stack(limit=2)
if pos:
print ERROR: In %s:%s, line %d: % (pos[0][0], pos[0][2], pos[0][1])
else: print ERROR:
print \t,msg
except:
if __debug__:
traceback.print_exc()
pass
sys.exit(2)
def separator():
Prints the separator line.
print -*75
def computeCRC(file, offset):
Computes the CRC32 for the file, starting at given offset.
f = open(file, rb)
f.seek(offset)
crc = 0
# Compute a running CRC32 for the file in 16kb chunks
while True:
buffer = f.read(16384)
if buffer == : break # End of file
crc = binascii.crc32(buffer, crc)
f.close()
return crc
def createPackage(pakFile, files):
Creates a new MPAK package.
This copies the given files into the new package file, writes the file table
and closes the package. MPAK doesn't support adding new files to an existing
package.
print Creating '%s'.. % pakFile
if len(files) 1: errorMsg(No input files specified!)
separator()
# Open the package file for writing
out = open(pakFile, wb)
# Write the header and reserve 4+4 bytes for CRC32 and file table offset
out.write(MPK1)
out.write(.*8)
# Write each file
package = { fileNames: [], fileOffsets: [] }
count = 0
for file in files:
# Get the basename
filename = os.path.basename(file)
print ,filename,...,
package[fileNames].append(filename)
# Get the file size in bytes
stats = os.stat(file)
# Store the current offset
Bug#633297: funguloids: FTBFS everywhere: error: reference to 'map' is ambiguous
Am 04.10.2012 11:23, schrieb Paul Wise: Wow, he replied immediately, see the attached files. o_O Awesome! I guess we can go and take this to fix the Debian package now, right? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685996: mythes-de-ch contains german ß instead of ss
On Tue, Oct 02, 2012 at 01:38:09PM +0200, Daniel Baumann wrote: any news on this? Just forgot this bug. Will fix soon. Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633297: funguloids: FTBFS everywhere: error: reference to 'map' is ambiguous
On Thu, 2012-10-04 at 11:38 +0200, Fabian Greffrath wrote: I guess we can go and take this to fix the Debian package now, right? I guess so, I'm going to focus on upstream first though. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part
Bug#689567: mkinitramfs: Module unix no longer automatically loaded causing udevadm to fail with socket error
Now that I think about it, the reason I made unix a module why back was because initramfs gave errors that it wasn't a module during boot. I have since tracked down the change to the udev package as I was unaware that the udev package was responsible for the force loading of the unix module in the first place. What worries me is that anybody upgrading an old Debian install with a custom kernel and modular unix will end up with an unbootable system after upgrading to wheezy. I will raise this issue with the udev maintainer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689586: Newer version that fixes blue skin in Flash
На 4.10.2012 12:22, Andreas Beckmann написа: Please upload libvdpau 0.5 that makes special non-default setting for making special case for flashplayer: http://lists.x.org/archives/xorg-announce/2012-September/002066.html That patch has been applied since 0.4.1-6. There are no changes in 0.5 that haven't been backported to 0.4.1. Expect a 0.5 upload after wheezy's release. I had non-default config setting dom.ipc.plugins.enabled=false in my Firefox. As a result I didn't have separate process for flashplayer and libvdpau didn't recognize it's flashplayer. This was the reason I was experiencing the issue. I reset the setting and now everything is fine :-) Keep up the good work :-) Regards, Ognyan Kulev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689487: New upstream release, 0.97.6, and backport/stable-update upload request
refcard attachment: 1-it-2-48.vcf
Bug#689587: unblock: jackd2/1.9.8~dfsg.4+20120529git007cdc37-4.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: pkg-multimedia-maintain...@lists.alioth.debian.org Please unblock package jackd2. The version in unstable fixes RC bug #688204. The debdiff against testing is in the bug report. Thanks, unblock jackd2/1.9.8~dfsg.4+20120529git007cdc37-4.1 -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 pgp9M9TKTUbyQ.pgp Description: PGP signature
Bug#689588: pre-approve unblock: cracklib2/2.8.19-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear release managers,
I have a cracklib2 upload ready that would fix #682735 [1] by applying the
patch by Markus Wanner. The patch introduces a new Debian specific function
__DEBIAN_SPECIFIC__SafeFascistCheck that does not call exit() when there is
a problem reading the dictionary file.
The modified Python binding that uses the new function passes the test suite
for all supported Python versions.
Another option is to patch the existing FascistCheck function, but as
libcrack2 has some reverse dependencies I don't think this should be done
before the Wheezy release. I will discuss changing FascistCheck with the
other upstream developers for a later version though.
Would you allow the changed cracklib2 package (debdiff attached) for Wheezy?
[1] http://bugs.debian.org/682735
Best regards
Jan
debdiff attached
unblock cracklib2/2.8.19-2
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=de, LC_CTYPE=de (charmap=UTF-8) (ignored: LC_ALL set to
de_DE.UTF-8)
Shell: /bin/sh linked to /bin/bash
--
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD
http://ddportfolio.debian.net/ - http://people.debian.org/~jandd/
diff -Nru cracklib2-2.8.19/debian/changelog cracklib2-2.8.19/debian/changelog
--- cracklib2-2.8.19/debian/changelog 2012-05-20 01:24:15.0 +0200
+++ cracklib2-2.8.19/debian/changelog 2012-10-02 09:15:24.0 +0200
@@ -1,3 +1,12 @@
+cracklib2 (2.8.19-2) unstable; urgency=low
+
+ * add debian/patches/libcrack2-error-safer-check-variant.patch to provide
+__DEBIAN_SPECIFIC__SafeFascistCheck that does not call exit (Closes:
+#682735)
+ * add __DEBIAN_SPECIFIC__SafeFascistCheck to debian/libcrack2.symbols
+
+ -- Jan Dittberner ja...@debian.org Tue, 02 Oct 2012 09:15:16 +0200
+
cracklib2 (2.8.19-1) unstable; urgency=low
* New upstream version
diff -Nru cracklib2-2.8.19/debian/libcrack2.symbols
cracklib2-2.8.19/debian/libcrack2.symbols
--- cracklib2-2.8.19/debian/libcrack2.symbols 2012-05-20 01:24:15.0
+0200
+++ cracklib2-2.8.19/debian/libcrack2.symbols 2012-10-02 09:15:24.0
+0200
@@ -27,3 +27,4 @@
Trim@Base 2.8.12
Uppercase@Base 2.8.12
GetDefaultCracklibDict@Base 2.8.14
+ __DEBIAN_SPECIFIC__SafeFascistCheck@Base 2.8.19-2~
diff -Nru
cracklib2-2.8.19/debian/patches/libcrack2-error-safer-check-variant.patch
cracklib2-2.8.19/debian/patches/libcrack2-error-safer-check-variant.patch
--- cracklib2-2.8.19/debian/patches/libcrack2-error-safer-check-variant.patch
1970-01-01 01:00:00.0 +0100
+++ cracklib2-2.8.19/debian/patches/libcrack2-error-safer-check-variant.patch
2012-10-02 09:15:24.0 +0200
@@ -0,0 +1,189 @@
+Subject: add a safer check variant
+Author: Markus Wanner mar...@bluegap.ch
+Bug-Debian: http://bugs.debian.org/682735
+--- a/lib/fascist.c
b/lib/fascist.c
+@@ -879,6 +879,48 @@
+ return res;
+ }
+
++/* This Debian specific method is a work-around for Debian #682735. Please
++ do not rely on it being available in future verisons of cracklib2. */
++int
++__DEBIAN_SPECIFIC__SafeFascistCheck(password, path, errstr)
++const char *password;
++const char *path;
++char *errstr;
++{
++PWDICT *pwp;
++char pwtrunced[STRINGSIZE];
++
++/* If passed null for the path, use a compiled-in default */
++if ( ! path )
++{
++ path = DEFAULT_CRACKLIB_DICT;
++}
++
++/* security problem: assume we may have been given a really long
++ password (buffer attack) and so truncate it to a workable size;
++ try to define workable size as something from which we cannot
++ extend a buffer beyond its limits in the rest of the code */
++
++strncpy(pwtrunced, password, TRUNCSTRINGSIZE);
++pwtrunced[TRUNCSTRINGSIZE - 1] = '\0'; /* enforce */
++
++/* perhaps someone should put something here to check if password
++ is really long and syslog() a message denoting buffer attacks? */
++
++if (!(pwp = PWOpen(path, r)))
++{
++ return 0;
++}
++
++/* sure seems like we should close the database, since we're only likely
to check one password */
++errstr = FascistLook(pwp, pwtrunced);
++
++PWClose(pwp);
++pwp = (PWDICT *)0;
++
++return 1;
++}
++
+ const char *
+ GetDefaultCracklibDict()
+ {
+--- a/python/_cracklibmodule.c
b/python/_cracklibmodule.c
+@@ -42,6 +42,7 @@
+ #ifdef HAVE_LIBINTL_H
+ #include libintl.h
+ #endif
++#include errno.h
+
+ #ifdef HAVE_PTHREAD_H
+ static pthread_mutex_t cracklib_mutex = PTHREAD_MUTEX_INITIALIZER;
+@@ -74,7 +75,8 @@
+ {
+ char *candidate, *dict;
+ char *defaultdict = NULL;
+-const char *result;
++int result;
++char *errmsg;
+
Bug#685265: syncmaildir: fails on '' in Maildir names in EXCLUDE* ([smd-bug] internal error)
On Mon, Oct 01, 2012 at 06:00:20PM +0200, gregor herrmann wrote: The attached patch brings me over this failure; no idea if it has any side effects, I haven't dared to run smd* without --dry-run :) Good news: smd is running flawlessly for me since a week. I clearly understand your patch, it seems OK to me. And I'm indeed glad it works ;-) I does, and I'm happily using smd since then :) I've been able to reproduce the bug. The bad news is that your fix does not work. The folder you marked for exclusion is probably not excluded at all, since the ' is interpreted as part of the glob expression (at least by smd-pull). The bug is clearly a consequence of the escaping madness of the shell. The bits of smd written in shell script have grown too much, and it is time to rewrite them in a less error prone language. I think that the easiest workaround for you, if you want exclude the folder in question, is to revet your patch and replace with %26 in the EXCLUDE_* glob expression (as you have to do with %20 for spaces). Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633297: funguloids: FTBFS everywhere: error: reference to 'map' is ambiguous
Am 04.10.2012 11:48, schrieb Paul Wise: I guess so, I'm going to focus on upstream first though. Alright, would you mind me hacking on it in SVN, though? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689590: udev: System fails to boot when unix is compiled as a module.
Package: udev Version: 175-7 Severity: normal System fails to boot when unix is compiled as a module. The force loading of unix has been removed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654282 I originally changed unix to a module because of the error messages on boot. The upgrade I did today left me with an unbootable system until I figured out what happened. It looks like busybox has fixed the extraneous error message however: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652672 While my issue was partially self inflicted, I'm wondering what will happen to people upgrading old versions of Debian that have a custom kernel with unix as a module. They'll might end up with an unbootable system as well. I am not familiar with how bulletproof the upgrade system must be so if this is not an issue, feel free to close this bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689589: RFP: openfire -- cross-platform real-time collaboration server based on the XMPP (Jabber) protocol.
Package: wnpp Severity: wishlist * Package name: openfire Version : 3.7.1 Upstream Author : Ignite Realtime Community ad...@igniterealtime.org * URL : http://www.igniterealtime.org * License : Apache License Programming Lang: Java Description : cross-platform collaboration server based on the XMPP (Jabber) protocol. Description from official site: Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache License. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522163: apt-cacher: change AUTOSTART to ENABLED in /etc/default/apt-cacher
On 04/10/12 09:52, Mark Hindley wrote: It would be good if apt-cacher would use similar variable: ENABLED=0 instead of current: AUTOSTART=0 This would help grepping which services are 'enabled'. I don't think packages should do this, except as a way to respect sysadmin configuration done in previous versions. openarena-server used to do this (and be off-by-default), but for wheezy I changed the documented way to disable it: (from its README.Debian) Disabling the init script - To disable the init script, use the facilities provided by your init system. For instance, under sysvinit, use update-rc.d openarena-server disable or under systemd, use ln -s /dev/null /etc/systemd/system/openarena-server.service Changing the value of the START_DAEMON variable in /etc/default/openarena-server is deprecated. Please leave it set to unless-disabled-by-upgrade. The relevant commits (it took me a few attempts to get the upgrade logic right!) are: http://anonscm.debian.org/gitweb/?p=pkg-games/openarena.git;a=commitdiff;h=ba31d93d6738e27de04d8db10664afdf23143404 http://anonscm.debian.org/gitweb/?p=pkg-games/openarena.git;a=commitdiff;h=c92f557bdd0b7e45806e50b46111582651f19af0 http://anonscm.debian.org/gitweb/?p=pkg-games/openarena.git;a=commitdiff;h=65a9e096397a4a5b9171b660d6e04cc987faf1f5 S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633297: funguloids: FTBFS everywhere: error: reference to 'map' is ambiguous
On Thu, 2012-10-04 at 12:13 +0200, Fabian Greffrath wrote: Alright, would you mind me hacking on it in SVN, though? I never mind people doing useful work :) -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part
Bug#689567: mkinitramfs: Module unix no longer automatically loaded causing udevadm to fail with socket error
On Thu, Oct 04, 2012 at 05:54:26AM -0400, Avernar wrote: What worries me is that anybody upgrading an old Debian install with a custom kernel and modular unix will end up with an unbootable system after upgrading to wheezy. I will raise this issue with the udev maintainer. This issue has lng been decided, if you are concerned, please propose a patch for the wheezy release notes. Modular unix is bad for cache-hits performance reasons! Best, -- maks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689298: upowerd goes crazy w/o /proc/timer_stats
OK, I'm able to confirm the CPU waste on a kernel built without CONFIG_TIMER_STATS=y run under qemu-kvm. I still haven't made upowerd leak memory like I saw in the wild yet though. To reproduce: build and run a kernel without CONFIG_TIMER_STATS=y run gnome-power-statistics after some seconds you'll observe both gnome-power-statistics and upowerd using gobs of CPU without actually getting anything done. In my qemu-kvm testbed, gnome-power-statistics becomes completely unresponsive and I have to send it SIGTERM to kill it. The upowerd CPU consumption continues even after gnome-power-statistics is dead and gone though. Eventually dbus-daemon is seen to grow in both CPU utilization (though not to the grand scope of upowerd) and noticably in resident memory as well. In short, a kernel built without the debugging interface for timer statistics will cause a chain reaction of instability and farcical resource consumption. strace of upowerd shows runaway attempts to open the non-existant /proc/timer_stats and subsequent logging of the failure, while it streams a continual raft of ultimately useless messages to the dbus machinery. -- Jamie Heilman http://audible.transient.net/~jamie/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685694: libmatio: diff for NMU version 1.3.4-3.1
Salvatore Bonaccorso car...@debian.org writes:
On Sun, Sep 02, 2012 at 10:16:09AM +0200, Sylvestre Ledru wrote:
Le 01/09/2012 13:33, Salvatore Bonaccorso a écrit :
A rebuild of the libmatio-doc would suffice here, as Sebastien noted.
Is it fine for you to upload a 'no changes' upload or would you like
to do it yourself?
This would fix RC bug #685694.
OK. Sounds great. :) (even if I don't like no-changes upload when I
don't know why it failed before ...
Don't hesitate to NMU with a 0 delay (or I can do the upload, no worries)
Before I did an NMU upload I tested now the 4 build-rdeps of
libmatio-dev: scilab, dynare, vips and openmeeg.
I get a FTBFS for openmeeg (failing tests) with a rebuilded libmatio.
The cause of the FTBFS is a bug in libmatio 1.3.4-3, more precisely an
illegal read. The bug is already present in the current sid binary, but
only triggers a crash after a recompilation (probably because of
compiler changes).
I attach a testcase: a C program and a MAT file (taken from openmeeg
testsuite).
When this test is run against the current libmatio, valgrind detects an
illegal read, but the program does not crash. When run against a
recompiled libmatio, the program crashes, and so does openmeeg
testsuite.
The good news is that this bug has been fixed upstream on the 1.3
branch, but has never been released since the stable branch is now 1.5:
http://matio.git.sourceforge.net/git/gitweb.cgi?p=matio/matio;a=commit;h=4b096356fda6973b404218bb7536b7267641fc55
Note that libmatio 1.5 currently in experimental is not affected.
Sylvestre: how do you want to proceed? I can do a team upload with this
patch incorporated. That would fix the libmatio-doc RC bug without
introducing an FTBFS on other packages.
Best,
#include assert.h
#include matio.h
int
main()
{
mat_t *mt = Mat_Open(Head1.mat, MAT_ACC_RDONLY);
assert(mt);
matvar_t *matvar;
while (matvar = Mat_VarReadNext(mt))
{
}
Mat_Close(mt);
}
Head1.mat
Description: Binary data
--
.''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
`- GPG Key: 4096R/381A7594
pgpTIjpjwdUsO.pgp
Description: PGP signature
Bug#689591: freeipmi-tools: Does not work with libgcrypt/gnutls from squeeze
Package: freeipmi-tools Version: 1.1.5-3 Severity: normal I had freeipmi from wheezy installed on a system running mostly squeeze. All dependencies were satisfied, but ipmipower gave this error when trying to power on some devices: ipmi_rmcpplus_init: incompatible crypto library I did an apt-get intall -t testing libgcrypt11, which did these upgrades: Selecting previously deselected package libp11-kit0. (Reading database ... 120159 files and directories currently installed.) Unpacking libp11-kit0 (from .../libp11-kit0_0.12-3_amd64.deb) ... Preparing to replace libgnutls26 2.8.6-1+squeeze2 (using .../libgnutls26_2.12.20-1_amd64.deb) ... Unpacking replacement libgnutls26 ... Preparing to replace libgcrypt11 1.4.6-9 (using .../libgcrypt11_1.5.0-3_amd64.deb) ... Unpacking replacement libgcrypt11 ... Setting up libp11-kit0 (0.12-3) ... Setting up libgcrypt11 (1.5.0-3) ... Setting up libgnutls26 (2.12.20-1) ... Then ipmipower worked fine again. -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (300, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-bpo.2-amd64 (SMP w/16 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 freeipmi-tools depends on: ii libc6 2.13-35Embedded GNU C Library: Shared lib ii libfreeipmi12 1.1.5-3GNU IPMI - libraries ii libgcrypt11 1.5.0-3LGPL Crypto library - runtime libr ii libipmiconsole2 1.1.5-3GNU IPMI - Serial-over-Lan library ii libipmidetect01.1.5-3GNU IPMI - IPMI node detection lib freeipmi-tools recommends no packages. Versions of packages freeipmi-tools suggests: pn freeipmi-bmc-watchdog none (no description available) pn freeipmi-ipmidetect none (no description available) -- 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#689592: gnome-power-statistics: memory leak insanity w/broken upowerd
Package: gnome-power-manager Version: 3.4.0-2 This is related to, but ultimately a separate problem from the one detailed in bug 689298. When gnome-power-statistics is run on a Linux system without CONFIG_TIMER_STATS=y set in the kernel, upowerd won't work correctly, and indeed behaves horribly, which impacts gnome-power-statistics in a negative manner. In that circumstance, gnome-power-statistics will leak memory rapidly and without bounds while it consumes substantial CPU resources. The memory leak is arguably the bigger problem, but suffice it to say that even if upowerd is broken and not responding correctly there's no good reason for gnome-power-statistics to consume memory endlessly. -- Jamie Heilman http://audible.transient.net/~jamie/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685265: syncmaildir: fails on '' in Maildir names in EXCLUDE* ([smd-bug] internal error)
On Thu, 04 Oct 2012 12:04:56 +0200, Enrico Tassi wrote: I clearly understand your patch, it seems OK to me. And I'm indeed glad it works ;-) I does, and I'm happily using smd since then :) I've been able to reproduce the bug. Excellent. The bad news is that your fix does not work. Oh, please don't tell this to my smd instance :) The folder you marked for exclusion is probably not excluded at all, since the ' is interpreted as part of the glob expression (at least by smd-pull). Ah, that might explain why it works (as in: I have the folders locally on the laptop but not on the server -- just checked again, they really are not there). Is there something different for -pull and -push with regard to EXCLUDE(_LOCAL)? The bug is clearly a consequence of the escaping madness of the shell. The bits of smd written in shell script have grown too much, and it is time to rewrite them in a less error prone language. Right, shell escaping is a beast ... I think that the easiest workaround for you, if you want exclude the folder in question, is to revet your patch and replace with %26 in the EXCLUDE_* glob expression (as you have to do with %20 for spaces). Good hint, thanks. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #148: Insert coin for new game -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686197: closed by Adam D. Barratt a...@adam-barratt.org.uk (Re: Bug#686197: unblock: rhnsd/4.9.15-1)
reopen 686197 retitle 686197 unblock: rhn-client-tools/1.8.9-3 thanks Hi, unfortunately I missed yet another dependency, which was not available on !linux. Apart from a new changelog entry, the diff is tiny: - python-dmidecode, lsb-release, gnupg, python-gudev, debconf, python-openssl + python-dmidecode, lsb-release, gnupg, python-gudev [linux-any], hal [!linux-any], debconf, python-openssl Support for hal is already in the rhn-client-tools, just the dependency was missing. So please unblock: rhn-client-tools/1.8.9-3 thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689593: move libjs-sphinxdoc from depends to recommends
Package: python-eventlet python-eventlet pulls in libjs-jquery, libjs-underscore through depending on libjs-sphinxdoc. i only want the python stuff, and not a bunch of js libraries. please do move the depends on libjs-sphinxdoc to a recommends, which is the appropriate thing to do. Thanks, Daniel -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685694: libmatio: diff for NMU version 1.3.4-3.1
On 04/10/2012 12:19, Sébastien Villemot wrote: Salvatore Bonaccorso car...@debian.org writes: On Sun, Sep 02, 2012 at 10:16:09AM +0200, Sylvestre Ledru wrote: Le 01/09/2012 13:33, Salvatore Bonaccorso a écrit : A rebuild of the libmatio-doc would suffice here, as Sebastien noted. Is it fine for you to upload a 'no changes' upload or would you like to do it yourself? This would fix RC bug #685694. [...] The good news is that this bug has been fixed upstream on the 1.3 branch, but has never been released since the stable branch is now 1.5: http://matio.git.sourceforge.net/git/gitweb.cgi?p=matio/matio;a=commit;h=4b096356fda6973b404218bb7536b7267641fc55 Note that libmatio 1.5 currently in experimental is not affected. Sylvestre: how do you want to proceed? I can do a team upload with this patch incorporated. That would fix the libmatio-doc RC bug without introducing an FTBFS on other packages. I am doing the build and upload right now. Many thanks for digging into this issue. Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688319: devscripts: Please consider including the 'yodack' tool
usertags 688319 + debian-packaging
thanks
Hi there!
On Fri, 28 Sep 2012 15:07:47 +0200, Gergely Nagy wrote:
FWIW, since the example given in the bug report is fairly verbose, and
that tends to put off some people, I'd like to mention that yodack does
not need the verboseness, that is merely an option.
The following command does exactly the same thing that the example I
originally posted:
$ yodack ftp-master dm alger...@madhouse-project.org \
allow dh-exec ivykis deny eglibc bash
IMHO this relies too much on the debian-keyring package, which is not
always in sync with the real situation:
=
$ who-uploads bacula
Uploads for bacula:
5.2.6+dfsg-5 to unstable: unrecognised public key (31455D17)
5.2.6+dfsg-4 to unstable: unrecognised public key (31455D17)
5.2.6+dfsg-3 to unstable: Luca Capello gi...@debian.org
$ gpg --no-default-keyring \
--keyring /usr/share/keyrings/debian-maintainers.gpg \
--list-key 31455D17
gpg: error reading key: public key not found
$ wget -O - http://ftp-master.debian.org/dm-uploaders.html | grep -A 3 31455D17
--2012-10-04 11:24:31-- http://ftp-master.debian.org/dm-uploaders.html
Resolving ftp-master.debian.org (ftp-master.debian.org)... 128.148.34.3
Connecting to ftp-master.debian.org (ftp-master.debian.org)|128.148.34.3|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 68299458 (65M) [text/html]
Saving to: ‘STDOUT’
0% [ ] 0
--.-K/s td
align=left5E2A59462C7B2CD307FB8A5A949C322631455D17/td
/tr
tr valign=top
td align=leftalexan...@ankalagon.ru/td
7% [=== ] 5,179,371
814KB/s eta 97s^C
$ git clone git://anonscm.debian.org/users/algernon/yodack.git
Cloning into 'yodack'...
remote: Counting objects: 92, done.
remote: Compressing objects: 100% (78/78), done.
remote: Total 92 (delta 39), reused 0 (delta 0)
Receiving objects: 100% (92/92), 42.93 KiB, done.
Resolving deltas: 100% (39/39), done.
$ cd yodack/
$ USER=gismo ./yodack ftp-master dm 31455D17 allow bacula
A known DM permissions to set, you must.
$ git diff
[attached below]
$ USER=gismo ./yodack ftp-master dm 31455D17 keyring ~/.gnupg/pubring.gpg allow
bacula
[verification and GnuPG stuff]
Upload to 'ftp-master', how to I know not.
[no exit error code]
$ ln -s ~/src/Debian/yodack/yodack.conf ~/.yodack.conf
$ USER=gismo ./yodack ftp-master dm 31455D17 keyring ~/.gnupg/pubring.gpg allow
bacula
[verification and GnuPG stuff]
Uploading gismo-1349344867.dak-commands to ftp-master.d.o...
$
=
BTW, is there any reason not to use dput/dcut for upload, but instead a
custom curl command?
Thx, bye,
Gismo / Luca
From d6a686729a1ed59ee57ed6f625c74f46c7f02fae Mon Sep 17 00:00:00 2001
From: Luca Capello l...@pca.it
Date: Thu, 4 Oct 2012 12:04:23 +0200
Subject: [PATCH] yodack: add keyring option
The Debian Maintainer keyring shipped in the debian-keyring package is
not always in sync with the real situation, i.e. the list available at
http://ftp-master.debian.org/dm-uploaders.html.
---
man1/yodack.1 |7 ---
yodack|9 +++--
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/man1/yodack.1 b/man1/yodack.1
index 08a4ffa..dfe3cf3 100644
--- a/man1/yodack.1
+++ b/man1/yodack.1
@@ -4,9 +4,9 @@
.SH NAME
yodack \- Ye Olde Debian Archive Control Kit
.SH SYNOPSIS
-.BI yodack ftp\-master dm example@org allow this that deny something\-else
+.BI yodack ftp\-master dm example@org keyring keyring.gpg allow this that deny something\-else
-.BI yodack at ftp\-master for dm example@org allow upload of package this, that , but deny uploading something\-else.
+.BI yodack at ftp\-master for dm example@org in keyring keyring.gpg allow upload of package this, that , but deny uploading something\-else.
.SH DESCRIPTION
Ye Olde Debian Archive Control Kit (or \fByodack\fR for short) is a
@@ -36,7 +36,8 @@ end up being sent, however.
Grant or revoke access to a particular Debian Maintainer (identified
by the \fIkey\-id\fR) on the listed packages.
-The maintainer will be looked up in the Debian Maintainer keyring, and
+The maintainer will be looked up in the Debian Maintainer keyring by default
+if an alternative keyring is specified via the \fBkeyring\fR option, and
Yodack will ask for verification - or complain, if there is more than
one match. Yodack does not like to choose, it wants the young
apprentices to make their own choices.
diff --git a/yodack b/yodack
index 836c41f..8a6d91a 100755
--- a/yodack
+++ b/yodack
@@ -107,7 +107,7 @@ EOF
yodack_add_dm_fingerprint () {
if fprs=$(gpg --no-options --no-default-keyring \
- --keyring /usr/share/keyrings/debian-maintainers.gpg \
+ --keyring $2 \
--list-options no-show-photo --fingerprint $1 2/dev/null); then
:
Bug#685230: unblock hylafax 3:6.0.6-4
Il giorno lun, 01/10/2012 alle 10.23 +0200, Julien Cristau ha scritto: [...] The BTS thinks #661482 and #682824 are RC bugs affecting the version in testing. You are right, I am going to prepare and updated package during this weekend. Thanks, Giuseppe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688319: devscripts: Please consider including the 'yodack' tool
Luca Capello l...@pca.it writes: On Fri, 28 Sep 2012 15:07:47 +0200, Gergely Nagy wrote: FWIW, since the example given in the bug report is fairly verbose, and that tends to put off some people, I'd like to mention that yodack does not need the verboseness, that is merely an option. The following command does exactly the same thing that the example I originally posted: $ yodack ftp-master dm alger...@madhouse-project.org \ allow dh-exec ivykis deny eglibc bash IMHO this relies too much on the debian-keyring package, which is not always in sync with the real situation: Oh, right. I haven't thought of that. Thanks for the patch, I'll review apply in a bit! [...] $ git diff [attached below] $ USER=gismo ./yodack ftp-master dm 31455D17 keyring ~/.gnupg/pubring.gpg allow bacula [verification and GnuPG stuff] Upload to 'ftp-master', how to I know not. [no exit error code] Hrm, it should exit with a non-zero code there. I'll fix that too, thanks for noticing it! BTW, is there any reason not to use dput/dcut for upload, but instead a custom curl command? Because when the tool was originally written, neither dput nor dcut were happy about .dak-command files for one, and because for uploading a single file, they both seemed like overkill to begin with. (In all honesty, a longer-term plan is to improve yodack to the point where it can replace dcut alltogether.) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689594: Dependency on ldb needs to be = 1.1.12
Package: samba4 Version: 4.0.0~rc2+dfsg1 Severity: normal samba4-4.0.0~rc2+dfsg1$ debuild [...] Checking for python headers : using cache Checking for system ldb = 1.1.12 : not found ERROR: System library ldb of version 1.1.12 not found, and bundling disabled samba4-4.0.0~rc2+dfsg1$ grep ldb debian/control libldb-dev (= 1:1.1.6~), python-ldb (= 1:1.1.6~), python-ldb-dev (= 1:1.1.6~), [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689516: linux-image-3.2.0-3-amd64: suspending a Lenovo Thinkpad X131e AMD crashes on resume
On 03/10/12 16:02, Ben Hutchings wrote: Please remove the broadcom-sta driver (rmmod wl) and re-test. Well, it worked, for a while, when I tried this, but is now failing again in exactly the same way, even though I've added config to deal with the wl module. I can hibernate OK (apart from the fact it needs to be triggered from a root command prompt), but suspend is still troublesome. -- Phil Reynolds mail: phil-deb...@tinsleyviaduct.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685265: syncmaildir: fails on '' in Maildir names in EXCLUDE* ([smd-bug] internal error)
On Thu, Oct 04, 2012 at 12:39:32PM +0200, gregor herrmann wrote: Ah, that might explain why it works (as in: I have the folders locally on the laptop but not on the server -- just checked again, they really are not there). Is there something different for -pull and -push with regard to EXCLUDE(_LOCAL)? Nothing but for the number of time the value is parsed by the shell. When you pull you do something like: ssh host smd-server --exclude $EXCLUDE_REMOTE ... and the remote smd-server passes the flag to mddiff. If you push, you directly call mddiff with the $EXCLUDE_LOCAL flag. For some reasons I did not dig into, one of the two commands asks the shell to parse the argument lists passed around twice. I tried a bit to use `eval` to unifor the things, but I decided it is better to fix the problem in another way ;-) Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689595: xine-ui: 0.99.7-1 pulls in libvdpau1, which crashes upon startup on non nvidia hardware
Package: xine-ui
Version: 0.99.7-1
Severity: important
I don't have any nvidia hardware (plain old Intel, TYVM), but xine-ui
insists on pulling in some nvidia specific vdpau crap and crashing
anyway:
231985,31 sudo aptitude install xine-ui/stable
The following packages will be DOWNGRADED:
xine-ui
The following packages will be REMOVED:
libvdpau1{u} libxine2-x{u}
0 packages upgraded, 0 newly installed, 1 downgraded, 2 to remove and 85 not
upgraded.
Need to get 0 B/1,560 kB of archives. After unpacking 455 kB will be freed.
Do you want to continue? [Y/n/?]
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
dpkg: warning: downgrading xine-ui from 0.99.7-1 to 0.99.6-1.
(Reading database ... 401212 files and directories currently installed.)
Preparing to replace xine-ui 0.99.7-1 (using .../xine-ui_0.99.6-1_amd64.deb) ...
Unpacking replacement xine-ui ...
Processing triggers for man-db ...
Processing triggers for gnome-menus ...
Processing triggers for desktop-file-utils ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for menu ...
(Reading database ... 401208 files and directories currently installed.)
Removing libxine2-x ...
Removing libvdpau1 ...
Setting up xine-ui (0.99.6-1) ...
Updated the MIME types in xine's menu file.
Processing triggers for menu ...
0-1-21:15:14, Thu Oct 04 tconnors@dirac:~/movies/kaffeine (bash)
231986,32 xine -f Cycling\ Central-22.m2t
This is xine (X11 gui) - a free video player v0.99.6.
(c) 2000-2007 The xine Team.
231988,34 sudo aptitude -t unstable install xine-ui
The following NEW packages will be installed:
libvdpau1{a} libxine2-x{a}
The following packages will be upgraded:
xine-ui
1 packages upgraded, 2 newly installed, 0 to remove and 2440 not upgraded.
Need to get 0 B/1,865 kB of archives. After unpacking 455 kB will be used.
Do you want to continue? [Y/n/?]
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
Selecting previously deselected package libvdpau1.
(Reading database ... 401184 files and directories currently installed.)
Unpacking libvdpau1 (from .../libvdpau1_0.4.1-7_amd64.deb) ...
Selecting previously deselected package libxine2-x.
Unpacking libxine2-x (from .../libxine2-x_1%3a1.2.2-dmo3_amd64.deb) ...
Preparing to replace xine-ui 0.99.6-1 (using .../xine-ui_0.99.7-1_amd64.deb) ...
Unpacking replacement xine-ui ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for menu ...
Processing triggers for man-db ...
Processing triggers for gnome-menus ...
Processing triggers for desktop-file-utils ...
Setting up libvdpau1 (0.4.1-7) ...
Setting up libxine2-x (1:1.2.2-dmo3) ...
Setting up xine-ui (0.99.7-1) ...
Updated the MIME types in xine's menu file.
Processing triggers for menu ...
Current status: 2440 updates [-1].
0-1-21:16:15, Thu Oct 04 tconnors@dirac:~/movies/kaffeine (bash)
231989,35 xine -f Cycling\ Central-22.m2t
This is xine (X11 gui) - a free video player v0.99.7.
(c) 2000-2010 The xine Team.
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object
file: No such file or directory
vo_vdpau: Can't create vdp device : No vdpau implementation.
Segmentation fault
Wh!
-- System Information:
Debian Release: 6.0.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1,
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.5-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages xine-ui depends on:
ii libc6 2.13-10 Embedded GNU C Library: Shared lib
ii libcurl3-gnutls7.25.0-1 easy-to-use client-side URL transf
ii libjpeg8 8c-2 Independent JPEG Group's JPEG runt
ii liblircclient0 0.8.3-5 infra-red remote control support -
ii libpng12-0 1.2.44-1+squeeze4 PNG library - runtime
ii libreadline6 6.1-3 GNU readline and history libraries
ii libx11-6 2:1.4.99.901-2X11 client-side library
ii libxext6 2:1.3.0-3 X11 miscellaneous extension librar
ii libxft22.1.14-2 FreeType-based font drawing librar
ii libxine2 1:1.2.2-dmo3 Xine media player library, meta-pa
ii libxine2-ffmpeg1:1.2.2-dmo3 MPEG-related plugins for libxine2.
ii libxine2-x 1:1.2.2-dmo3 X desktop video output plugins for
ii libxinerama1 2:1.1.1-3 X11 Xinerama extension library
ii libxtst6 2:1.1.0-3 X11 Testing -- Record extension li
ii libxv1 2:1.0.5-1 X11
Bug#689596: obmenu: Obmenu doesn't start after upgrade to wheezy due to a bad python version
Package: obmenu Version: 1.0-1+b1 Severity: important If I launch obmenu in a terminal, this error mesage is displayed and obmenu doesn't start Traceback (most recent call last): File /usr/bin/obmenu, line 21, in module import obxml, gtk, gtk.glade, gobject, random, time, os, sys ImportError: No module named obxml the first of /usr/bin/obmenu is #!/usr/bin/python2.5 I replaced it with #!/usr/bin/python and now it works. I found this solution in a forum, I'm no the only one who faced this problem. Regards, Mickaël -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/2 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 obmenu depends on: ii python-glade2 2.24.0-3 GTK+ bindings: Glade support ii python-support1.0.15 automated rebuilding support for P ii python2.5 2.5.5-11 An interactive high-level object-o Versions of packages obmenu recommends: ii openbox 3.5.0-4standards compliant, fast, light-w obmenu suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /usr/bin/obmenu (from obmenu package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689597: makes my X server disfunctional
Package: icedove Version: 10.0.7-1 Severity: important Hi, I'm not sure whether this is a bug in icedove, my X server, or in awesome (my window manager), but since I only experience it when I'm using icedove, I think this is the best guess. I'm also aware that this is a pretty vague description, and that it's probably not going to help much, but I can't help it. Whenever I use icedove for more than a few seconds or minutes, chances that my X server refuses all inputs apart from the movement of my mouse will approach one. That is, when this happens, the mouse pointer will still move around, but everything else will fail: no keyboard inputs or mouse button inputs will be accepted. The only solution thus far that I've found is a hard reset: push the power button until the screen goes blank, and reboot. Needless to say, this is very painful. I have been considering switching from mutt to icedove as my primary mail client, but obviously this is a major blocker to make this a possibility. If there's any way in which I can help debug this more, do let me know. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages icedove depends on: ii debianutils 4.3.4 ii fontconfig2.9.0-7 ii libasound21.0.25-4 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-35 ii libcairo2 1.12.2-2 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100-1 ii libevent-2.0-52.0.19-stable-3 ii libffi5 3.0.10-3 ii libfontconfig12.9.0-7 ii libfreetype6 2.4.9-1 ii libgcc1 1:4.7.2-2 ii libgdk-pixbuf2.0-02.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-1 ii libgtk2.0-0 2.24.10-2 ii libhunspell-1.3-0 1.3.2-4 ii libjpeg8 8d-1 ii libnspr4 2:4.9.2-1 ii libnspr4-0d 2:4.9.2-1 ii libnss3 2:3.13.6-1 ii libnss3-1d2:3.13.6-1 ii libpango1.0-0 1.30.0-1 ii libpixman-1-0 0.26.0-3 ii libsqlite3-0 3.7.14-1 ii libstartup-notification0 0.12-1 ii libstdc++64.7.2-2 ii libvpx1 1.1.0-1 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxrender1 1:0.9.7-1 ii libxt61:1.1.3-1 ii psmisc22.20-1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages icedove recommends: ii myspell-nl [myspell-dictionary] 1:2.10-1 Versions of packages icedove suggests: ii fonts-lyx 2.0.3-3 ii gconf-service 3.2.5-1+build1 ii libgconf-2-4 3.2.5-1+build1 ii libgssapi-krb5-2 1.10.1+dfsg-2 ii libnotify40.7.5-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#689598: dak: lintian check for packages referring to source in NEW fails
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: dak The lintian check fails for packages that refer to upstream tarballs in NEW: W: lintian failed for /srv/ftp-master.debian.org/tmp/dakup3IIw/readosm_1.0.0a-2_i386.changes [return code: 2]. W: [possible output:] gpgv: keyblock resource `/home/dak-unpriv/.gnupg/trustedkeys.gpg': file open error [possible output:] gpgv: Signature made Wed Oct 3 22:08:22 2012 UTC using DSA key ID 1392B174 [possible output:] gpgv: Can't check signature: public key not found [possible output:] dpkg-source: error: cannot fstat file /tmp/temp-lintian-lab-avvP4ypHUd/pool/r/readosm/readosm_1.0.0a-2_source/readosm_1.0.0a.orig.tar.gz: Permission denied [possible output:] internal error: dpkg-source -x failed with status 13 at /usr/share/lintian/lib/Lintian/Util.pm line 831. [possible output:] warning: collect info unpacked about package readosm failed [possible output:] warning: skipping check of source package readosm The problem is that *.orig.tar.gz is a symlink to the file in NEW which is not readable by dak-unpriv. Maybe we should just always copy files around instead of trying to do less I/O? Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688319: devscripts: Please consider including the 'yodack' tool
Hi there! On Thu, 04 Oct 2012 13:07:11 +0200, Gergely Nagy wrote: Luca Capello l...@pca.it writes: BTW, is there any reason not to use dput/dcut for upload, but instead a custom curl command? Because when the tool was originally written, neither dput nor dcut were happy about .dak-command files for one, and because for uploading a single file, they both seemed like overkill to begin with. (In all honesty, a longer-term plan is to improve yodack to the point where it can replace dcut alltogether.) Well, dcut accepts .commands and works using the same configuration file than dput, while yodack wants yet another configuration file. Your call, but this seems to me duplication for no real advantage. Thx, bye, Gismo / Luca pgpn99JqOVtr9.pgp Description: PGP signature
Bug#684082: gcc-doc: update to gcc 4.7
On 2012-08-06 21:32:53 +0200, Andrew Shadura wrote: Please package gcc-4.7-doc and update gcc-doc to point to it. Now that gcc-4.7-doc is available, the only thing to do is to update gcc-doc to point to it. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689599: eucalyptus: CVE-2012-4063 CVE-2012-4064 CVE-2012-4065
Package: eucalyptus Severity: grave Tags: security Justification: user security hole Please see http://www.eucalyptus.com/eucalyptus-cloud/security/esa-06 http://www.eucalyptus.com/eucalyptus-cloud/security/esa-05 http://www.eucalyptus.com/eucalyptus-cloud/security/esa-07 Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689420: (no subject)
I did a reinstallation, which did not help. During the reinstallation I have chosen a generic kernel version, with a partially installed Intel Wireless driver (see bug 689416): only the iwlwifi-6000-4.ucode file was used. After that, I went into the rescue mode from a boot medium (USB stick). From there, I installed linux-image-3.2.0-4-amd64 onto the laptop and rebooted. The laptop failed to boot with the new kernel either. The recovery modes are not working any more either. Now it is pretty reproducible that both current testing and unstable kernels completely fail to work on (my variant of) Dell Precision M6700. Link: http://configure.euro.dell.com/dellstore/config.aspx?oc=w08m6711model_id=precision-m6700c=del=des=bsdcs=debsdt1 Please repair the kernel. Jaakov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
I can confirm this bug here too and found a temporarly workaround. Ivy-Bridge i5-3570K on Intel DH77EB MoBo (H77 chipset), latest BIOS EB0089.BIO. These freezes happend most of the time when hitting a link in Iceweasel. They are so severe that even the MoBo reset button does not respond immediately, I had to hit it several times. Additionally when PC stalls, monitor continues to display the frozen desktop (via displayport) and power consumption rises from idle 38 watts to constant 86 watts - verry dangerous if also fan regulation fails. Upon next boot I get orphaned inodes - very much the same as Per Foreby describes. System here is Wheezy-amd64 with - kernel 3.2.23-1 - xserver-xorg-video-intel 2:2.19.0-5 Now I'll give the history what I did try with which result. Sorry if it's not scientific, but probably helps to pin down the root cause. It started when I was examining my logs and discovered the messages: [drm] MTRR allocation failed. Graphics performance may suffer. Checking mtrr's showed: cat /proc/mtrr reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back reg01: base=0x2 ( 8192MB), size= 512MB, count=1: write-back reg02: base=0x0e000 ( 3584MB), size= 512MB, count=1: uncachable reg03: base=0x0dc00 ( 3520MB), size= 64MB, count=1: uncachable reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable So I decided to boot with kernel parameter enable_mtrr_cleanup which seemed to solve the problem: reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x0c000 ( 3072MB), size= 512MB, count=1: write-back reg03: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable reg04: base=0x0dc00 ( 3520MB), size= 64MB, count=1: uncachable reg05: base=0x1 ( 4096MB), size= 4096MB, count=1: write-back reg06: base=0x2 ( 8192MB), size= 512MB, count=1: write-back reg07: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable reg08: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable reg09: base=0x0e000 ( 3584MB), size= 256MB, count=1: write-combining At least since then (don't know whether before as well) the freezes/crashes were observed, sometimes more than once a day. Did try a lot to find the root cause and finally found following workaround: Default setting in the BIOS of the DH77EB for video agp-aperture is max (values of 64, 128, 256 and 512MB are offered as options). I played around with different BIOS settings and observed that these settings are not respected by the i915 module. Dmesg always reports 256MB for the aperture: dmesg | grep agp Linux agpgart interface v0.103 agpgart-intel :00:00.0: Intel Ivybridge Chipset agpgart-intel :00:00.0: detected gtt size: 2097152K total, 262144K mappable agpgart-intel :00:00.0: detected 65536K stolen memory agpgart-intel :00:00.0: AGP aperture is 256M @ 0xe000 So I decided to set the BIOS AGP-aperture to 256MB as well and removed the kernel parameter 'enable_mtrr_cleanup'. I now get for the mtrr's: reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back reg01: base=0x2 ( 8192MB), size= 512MB, count=1: write-back reg02: base=0x0e000 ( 3584MB), size= 512MB, count=1: uncachable reg03: base=0x0dc00 ( 3520MB), size= 64MB, count=1: uncachable reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable still suffering graphics performance and mtrr missmatch according to dmesg: mtrr: type mismatch for e000,1000 old: write-back new: write-combining [drm] MTRR allocation failed. Graphics performance may suffer. But since then I have never obseved any cras/freeze for days now. If more information is required, please let me know (logs did never contain any information related to the crashes). My suspicion for the cause is some memory or communication missmatch between BIOS-setting, mtrr's and agp-aperture. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688319: devscripts: Please consider including the 'yodack' tool
Luca Capello l...@pca.it writes: Hi there! On Thu, 04 Oct 2012 13:07:11 +0200, Gergely Nagy wrote: Luca Capello l...@pca.it writes: BTW, is there any reason not to use dput/dcut for upload, but instead a custom curl command? Because when the tool was originally written, neither dput nor dcut were happy about .dak-command files for one, and because for uploading a single file, they both seemed like overkill to begin with. (In all honesty, a longer-term plan is to improve yodack to the point where it can replace dcut alltogether.) Well, dcut accepts .commands and works using the same configuration file than dput, while yodack wants yet another configuration file. Your call, but this seems to me duplication for no real advantage. It doesn't take much effort to support .commands files, and the same config file. I just didn't get around to do it yet, and .dak-commands was the priority. (Hence the longer-term plan being replacing dcut, not an immediate one :) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689510: lintian errors/warnings
The OpenSSL license status needs to be confirmed and possibly override the error. The debian/rules file or the python setup script may need to be adapted to use CFLAGS from dpkg-buildpackage when compiling things: W: python-sipsimple: hardening-no-relro usr/lib/python2.6/dist-packages/sipsimple/core/_core.so W: python-sipsimple: hardening-no-fortify-functions usr/lib/python2.6/dist-packages/sipsimple/core/_core.so W: python-sipsimple: hardening-no-fortify-functions usr/lib/python2.7/dist-packages/sipsimple/core/_core.so E: python-sipsimple: possible-gpl-code-linked-with-openssl W: python-sipsimple-dbg: hardening-no-relro usr/lib/python2.6/dist-packages/sipsimple/core/_core_d.so W: python-sipsimple-dbg: hardening-no-fortify-functions usr/lib/python2.6/dist-packages/sipsimple/core/_core_d.so W: python-sipsimple-dbg: hardening-no-fortify-functions usr/lib/python2.7/dist-packages/sipsimple/core/_core_d.so E: python-sipsimple-dbg: possible-gpl-code-linked-with-openssl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687969: ftp.debian.org: ftp.kr.debian.org began to develop Hash Sum errors.
Simon, you were right. Our mirror was not getting past stage1 for a while, but now it's fixed. After our ssh port got blocked, we were invoking ftpsync from crontab, but too excessively. Invoking ftpsync while another one was running touched the update-required file, and this made ftpsync loop in stage1 so it never proceeded to the rest of the sync. We learned we should be careful not to invoke ftpsync too frequently when doing it manually, and our mirror is now (really) in sync. I also made some internal changes, so we can use ftpsync without any modification. Previously, we added a hook to the cleanup part of ftpsync. I'll contact you privately (and perhaps mirrors@) to get our push triggers back via a non-standard ssh port. Thanks, and sorry for the mess we made, ~Jaeho On Wed, Oct 3, 2012 at 1:54 AM, Simon Paillard spaill...@debian.org wrote: Hi, On Tue, Oct 02, 2012 at 05:50:33PM -0700, Jaeho Shin wrote: On Tue, Oct 2, 2012 at 3:24 PM, Simon Paillard spaill...@debian.org wrote: On Mon, Oct 01, 2012 at 01:54:10AM -0700, Jaeho Shin wrote: No successful update occurred since 20th Sept ? http://ftp.kr.debian.org/debian/project/trace/ Sorry about the confusion. However, you can confirm the upstream ones are fresh. ftp-master having Tue Oct 2 20:28:04 UTC 2012 It's misleading, it can happen you have synchronized trace files and part of the mirror, but the sync is not properly finished so local trace file not generated. Seems like the upgrade wasn't smooth and our timestamps aren't being generated since then. We are hooking some of our pre/post scripts into ftpsync, but that must have gone wrong. We'll fix it soon. Yes we do receive the mails, and despite seeing some connection timeouts for a few days, it seems to be keeping in sync. (except our trace timestamp) You may disable the hook for the moment so that 1 full sync is performed including trace file. We're also working on opening a ssh port for receiving push triggers from you. Our campus network policy became very strict a while ago and most of the known service ports have been closed. Is it possible to receive ssh triggers on a non-standard port BTW? Yes. -- Simon Paillard
Bug#637207: Patch to update to 1.3~beta2
Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu quantal ubuntu-patch Maybe in experimental xwax could be updated to 1.3~beta2 - I have been using it since it was released and it has been working great. The patch attached fixes: - Update to 1.3~beta2. - Use [linux-any] for libasound2-dev (Closes: #634480). - Use debhelper7. - Update debian/copyright to DEP5. - Drop all patches, everything's fixed upstream or is easily overridden in debian/rules. Have a great day, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673468: Successful installation on Qemu, but german keymap is missing umlauts
I performed a test installation with Beta2, using debian-wheezy-DI-beta2-kfreebsd-i386-netinst.iso on qemu. (I wrote this bugreport initially for a installation on virtualbox. Now, beta2 does no longer boot on virtualbox. alpha1 and beta1 boot correctly. This is why I switched to qemu for this test. The kfreebsd beta2 netinst burned to a CD boots fine on my Thinkpad T60.) Summary: installation went fine! The only glitch I noticed was, that the umlauts (ä,ö,ü,ß) are missing from the german keymap: german keymap was selected in the console (in the installer AND in the installed system), but when typing the umlauts, no character is shown. Thanks Holger -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Powered by Sylpheed 3.0.2 under Debian GNU/ / _ _ _ _ _ __ __ / /__ / / / \// //_// \ \/ / // /_/ /_/\/ /___/ /_/\_\6.0 / Squeeze. Registered LinuxUser #311290 - http://counter.li.org/ = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637207: Patch to update to 1.3~beta2
Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu quantal ubuntu-patch Maybe in experimental xwax could be updated to 1.3~beta2 - I have been using it since it was released and it has been working great. The patch attached fixes: - Update to 1.3~beta2. - Use [linux-any] for libasound2-dev (Closes: #634480). - Use debhelper7. - Update debian/copyright to DEP5. - Drop all patches, everything's fixed upstream or is easily overridden in debian/rules. Have a great day, Daniel diff -ruN xwax-0.9/debian/clean xwax-1.3~beta2/debian/clean --- xwax-0.9/debian/clean 1970-01-01 01:00:00.0 +0100 +++ xwax-1.3~beta2/debian/clean 2012-04-20 09:21:37.0 +0200 @@ -0,0 +1,3 @@ +.config +test-*.d +test-*.o diff -ruN xwax-0.9/debian/control xwax-1.3~beta2/debian/control --- xwax-0.9/debian/control 2011-04-22 20:22:38.0 +0200 +++ xwax-1.3~beta2/debian/control 2012-10-04 13:38:03.848081207 +0200 @@ -1,9 +1,10 @@ Source: xwax Section: sound Priority: extra -Maintainer: Mitchell Smith m...@mjsprojects.net -Build-Depends: debhelper (= 7), libasound2-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], libsdl-ttf2.0-dev -Standards-Version: 3.9.1 +Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com +XSBC-Original-Maintainer: Mitchell Smith m...@mjsprojects.net +Build-Depends: debhelper (= 7.0.50~), libasound2-dev [linux-any], libsdl-ttf2.0-dev +Standards-Version: 3.9.3 Homepage: http://www.xwax.co.uk/ Package: xwax diff -ruN xwax-0.9/debian/copyright xwax-1.3~beta2/debian/copyright --- xwax-0.9/debian/copyright 2011-04-22 20:05:09.0 +0200 +++ xwax-1.3~beta2/debian/copyright 2012-04-20 09:00:33.0 +0200 @@ -1,41 +1,16 @@ -This work was packaged for Debian by: - -Mitchell Smith m...@mjsprojects.net on Sun, 05 Jul 2009 21:57:19 + - -It was downloaded from: - -http://www.xwax.co.uk/ - -Upstream Author(s): - -Mark Hills m...@pogo.org.uk - -Copyright: - -Copyright (C) 2011 Mark Hills - -License: - - This package is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License version 2 as - published by the Free Software Foundation. - -This package is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program. If not, see http://www.gnu.org/licenses/ - -On Debian systems, the complete text of the GNU General -Public License version 2 can be found in /usr/share/common-licenses/GPL-2. - -The Debian packaging is: - -Copyright (C) 2011 Mitchell Smith m...@mjsprojects.net - -you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or -(at your option) any later version. +Format-Specification: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ +Upstream-Name: xwax +Upstream-Contact: m...@pogo.org.uk +Source: https://xwax.co.uk/download.html + +Files: * +Copyright: 2011 Mark Hills +License: GPL-2 + The full text of the GPL is distributed as in + /usr/share/common-licenses/GPL-2 on Debian systems. + +Files: debian/* +Copyright: 2010 2011 Mitchell Smith +License: GPL-2+ + The full text of the GPL is distributed as in + /usr/share/common-licenses/GPL-2 on Debian systems. diff -ruN xwax-0.9/debian/patches/01-fix-libexec-dir-in-makefile.patch xwax-1.3~beta2/debian/patches/01-fix-libexec-dir-in-makefile.patch --- xwax-0.9/debian/patches/01-fix-libexec-dir-in-makefile.patch 2011-04-21 00:33:53.0 +0200 +++ xwax-1.3~beta2/debian/patches/01-fix-libexec-dir-in-makefile.patch 1970-01-01 01:00:00.0 +0100 @@ -1,15 +0,0 @@ -## Description: Install external scripts in FHS friendly location. -## Origin/Author: Mitchell Smith m...@mjsprojects.net -Index: xwax-0.9/Makefile -=== xwax-0.9.orig/Makefile 2011-04-16 19:19:28.0 +1000 -+++ xwax-0.9/Makefile 2011-04-21 08:32:59.315641837 +1000 -@@ -35,7 +35,7 @@ - # Installation paths - - BINDIR = $(PREFIX)/bin --EXECDIR = $(PREFIX)/libexec -+EXECDIR = $(PREFIX)/share/xwax - MANDIR = $(PREFIX)/share/man - DOCDIR = $(PREFIX)/share/doc - diff -ruN xwax-0.9/debian/patches/02-remove-redundant-copyright-notice.patch xwax-1.3~beta2/debian/patches/02-remove-redundant-copyright-notice.patch --- xwax-0.9/debian/patches/02-remove-redundant-copyright-notice.patch 2011-04-21 00:30:45.0 +0200 +++ xwax-1.3~beta2/debian/patches/02-remove-redundant-copyright-notice.patch 1970-01-01 01:00:00.0 +0100 @@ -1,14 +0,0 @@ -## Description: Stop redundant copyright file from being installed. -## Origin/Author: Mitchell
Bug#687651: dose3 source does not clean properly so cannot be built twice
Hi, in fact this bug was due to two things: (1) a bug in the upstream makefile, with the result that make clean did not remove all generated doc files (2) the fact that the debian package for this version has to run aclocal and autoconf due to an ommission in the upstream tarball, and as a consequence modifie the ./configure file. (1) is fixed now in the master branch of the upstream git reprository. (2) should be resolved when the next upstream version does no longer require to run aclocal and autoconf. Cheers -Ralf. -- Ralf Treinen Laboratoire Preuves, Programmes et Systèmes Université Paris Diderot, Paris, France. http://www.pps.univ-paris-diderot.fr/~treinen/ = New email address: trei...@pps.univ-paris-diderot.fr = -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689562: utempter: Allows fake host setting
Searching for previous references for this issue, I found: https://github.com/keithw/mosh/pull/219 To top it all off: I actually believe libutempter to be a security /bug/ by its very design, as it allows untrusted code to spoof hostnames into utmp ... so may have been a known issue. (Only reference I found, so far.) Should this broken behaviour be documented, maybe? Are there any utilities that depend on a correct utmp? If not, why do we bother updating it? Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566754: Closing HwB bug # 566754
close 566754 thanks The Hardware Book package 1:040412-6 has been uploaded to unstable [1] and that resolves this bug. Closing. Robert James Clay j...@rocasa.us [1] http://packages.qa.debian.org/h/hwb/news/20121003T181752Z.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689037: inputlirc: Crashes immediately after starting
On Tue, 2 Oct 2012 11:23:44 +0200 Guus Sliepen g...@debian.org wrote: Hm, I cannot reproduce the crash, Neither can I now, so I suppose there's not much that can be done except to close this bug. Perhaps it was caused by my mistake in using $EVENTS as well as -n. but you should remove /dev/input/event* from the command, otherwise inputlirc will grab ALL devices, which is not what you want. The -n 'Media*' option itself will scan all possible input event devices for matches. So please try starting it as follows: inputlircd -g -n 'Media*' OK. I had a little trouble with that because I had nested quotes in /etc/default/inputlirc but it's working now. Can you also install input-utils and email me the output of the lsinput command regardless of whether the above works or not? Probably not needed now, but I'll add it below anyway. NB lirc wasn't installed at the time, I installed that afterwards. The lirc package isn't needed for inputlirc to work, it should work fine without it. I know, but I installed it after inputlirc didn't work, and for irw etc. But inputlirc seems better to me, because it's much simpler to set up and it seems to have a more sensible default repeat/delay, although no doubt that can be configured in lirc. [htpc] ~ $ sudo lsinput /dev/input/event0 bustype : BUS_USB vendor : 0x46d product : 0xc52b version : 273 name: Logitech Unifying Device. Wirele phys: usb-:00:12.0-3:1 uniq: bits ev : EV_SYN EV_KEY EV_REL EV_MSC /dev/input/event1 bustype : BUS_USB vendor : 0x46d product : 0xc52b version : 273 name: Logitech Unifying Device. Wirele phys: usb-:00:12.0-3:2 uniq: bits ev : EV_SYN EV_KEY EV_REL EV_ABS EV_MSC EV_LED EV_REP /dev/input/event3 bustype : BUS_HOST vendor : 0x0 product : 0x1 version : 0 name: Power Button phys: PNP0C0C/button/input0 bits ev : EV_SYN EV_KEY /dev/input/event4 bustype : BUS_HOST vendor : 0x0 product : 0x1 version : 0 name: Power Button phys: LNXPWRBN/button/input0 bits ev : EV_SYN EV_KEY /dev/input/event5 bustype : BUS_USB vendor : 0x1934 product : 0x5168 version : 1 name: Media Center Ed. eHome Infrared phys: usb-:00:12.0-5 bits ev : EV_SYN EV_KEY EV_MSC EV_REP /dev/input/event6 bustype : (null) vendor : 0x0 product : 0x0 version : 0 name: MCE IR Keyboard/Mouse (mceusb) phys: /input0 bits ev : EV_SYN EV_KEY EV_REL EV_MSC EV_REP /dev/input/event7 bustype : BUS_USB vendor : 0x2013 product : 0x24f version : 1 name: em28xx IR (em28xx #0) phys: usb-:00:13.2-1/input0 bits ev : EV_SYN EV_KEY EV_MSC EV_REP /dev/input/event8 bustype : (null) vendor : 0x0 product : 0x0 version : 0 name: HDA NVidia HDMI/DP,pcm=9 phys: ALSA bits ev : EV_SYN EV_SW /dev/input/event9 bustype : (null) vendor : 0x0 product : 0x0 version : 0 name: HDA NVidia HDMI/DP,pcm=8 phys: ALSA bits ev : EV_SYN EV_SW /dev/input/event10 bustype : (null) vendor : 0x0 product : 0x0 version : 0 name: HDA NVidia HDMI/DP,pcm=7 phys: ALSA bits ev : EV_SYN EV_SW /dev/input/event11 bustype : (null) vendor : 0x0 product : 0x0 version : 0 name: HDA NVidia HDMI/DP,pcm=3 phys: ALSA bits ev : EV_SYN EV_SW -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688549: Now a new problem...
Looks like the install disks are wrong and grub-install wasn't run correctly On Oct 1, 2012 4:15 AM, Dean Loros debianmainu...@gmail.com wrote: I found that I did not have ia32-libs installed..installed the libs grub was still complaining about this: [sudo] password for dean: GRUB = 2.00 has been unpacked but not yet configured. grub-mkconfig will not work until the upgrade is complete. It should run later as part of configuring the new GRUB packages. I found that I did not have all parts of grub in /boot/grub--only in /boot/grub/i386-pc ...My system is 64bit. I copied all the missing parts into my /boot/grub left the duplicates in /boot/grub/i386--the system boots, but stills gives the above error with the sudo update-grub or sudo grub-mkconfig commands. I am reverting back to 1.99-23 again await more information--here is the log: Log started: 2012-09-30 18:39:25 (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 338513 files and directories currently installed.) Preparing to replace grub-common 2.00-7 (using .../grub-common_2.00-7_amd64.deb) ... Unpacking replacement grub-common ... Preparing to replace grub-pc 2.00-7 (using .../grub-pc_2.00-7_amd64.deb) ... Unpacking replacement grub-pc ... Preparing to replace grub-pc-bin 2.00-7 (using .../grub-pc-bin_2.00-7_amd64.deb) ... Unpacking replacement grub-pc-bin ... Preparing to replace grub2-common 2.00-7 (using .../grub2-common_2.00-7_amd64.deb) ... Unpacking replacement grub2-common ... Processing triggers for man-db ... Processing triggers for install-info ... Setting up grub-common (2.00-7) ... Setting up grub2-common (2.00-7) ... Setting up grub-pc-bin (2.00-7) ... Setting up grub-pc (2.00-7) ... Installation finished. No error reported. GRUB = 2.00 has been unpacked but not yet configured. grub-mkconfig will not work until the upgrade is complete. It should run later as part of configuring the new GRUB packages. Log ended: 2012-09-30 18:39:30 -- Cheers!!! Dean Loros Performance by Design Ltd. autocrosser at http://forums.linuxmint.com ___ Pkg-grub-devel mailing list pkg-grub-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grub-devel
Bug#689600: libboost1.49-dev: read_json does not compile with std=c++11.
Package: libboost1.49-dev Version: 1.49.0-3.1 Severity: normal Dear Maintainer, Function read_json from property_tree library doesn't compile with -std=c++11 compiler flag. This makes JSON parser from this library totally unusable in case of using that language standard. This bug has been already fixed in boost trunk (in revision r78679). Ticket in boost bug tracker: https://svn.boost.org/trac/boost/ticket/6785 -- System Information: Debian Release: wheezy/sid Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libboost1.49-dev depends on: ii libc6 2.13-35 ii libgcc1 1:4.7.1-7 ii libicu484.8.1.1-9 ii libstdc++6 4.7.1-7 ii libstdc++6-4.7-dev [libstdc++-dev] 4.7.1-7 libboost1.49-dev recommends no packages. Versions of packages libboost1.49-dev suggests: pn default-jdk none ii docbook-xml 4.5-7.1 ii docbook-xsl 1.76.1+dfsg-1 ii doxygen 1.8.1.2-1 pn fop none ii libboost-chrono1.49-dev 1.49.0-3.1 ii libboost-date-time1.49-dev1.49.0-3.1 ii libboost-filesystem1.49-dev 1.49.0-3.1 ii libboost-graph-parallel1.49-dev 1.49.0-3.1 ii libboost-graph1.49-dev1.49.0-3.1 ii libboost-iostreams1.49-dev1.49.0-3.1 ii libboost-locale1.49-dev 1.49.0-3.1 ii libboost-math1.49-dev 1.49.0-3.1 ii libboost-mpi1.49-dev 1.49.0-3.1 ii libboost-program-options1.49-dev 1.49.0-3.1 ii libboost-python1.49-dev 1.49.0-3.1 ii libboost-random1.49-dev 1.49.0-3.1 ii libboost-regex1.49-dev1.49.0-3.1 ii libboost-serialization1.49-dev1.49.0-3.1 ii libboost-signals1.49-dev 1.49.0-3.1 ii libboost-system1.49-dev 1.49.0-3.1 ii libboost-test1.49-dev 1.49.0-3.1 ii libboost-thread1.49-dev 1.49.0-3.1 ii libboost-timer1.49-dev1.49.0-3.1 ii libboost-wave1.49-dev 1.49.0-3.1 ii libboost1.49-doc 1.49.0-3.1 pn xsltproc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633297: funguloids: FTBFS everywhere: error: reference to 'map' is ambiguous
Am 04.10.2012 12:18, schrieb Paul Wise: I never mind people doing useful work :) I never mind a review. ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689601: icinga-common doesnt set check_external_commands to 1
Package: icinga-common Version: 1.7.1-3~bpo60+1 Severity: important When I ran apt-get install icinga-common and chose to set allow external commands to 1, it didnt take, check_external_commands was still set to 0 when the installation was done. dpkg-reconfigure icinga-common and chosing yes there took though and its working as it should. Just need to have it do this at the installation aswell. -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-042stab056.11 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages icinga-common depends on: ii adduser 3.112+nmu2 add and remove users and groups ii coreutils 8.5-1GNU core utilities ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii heirloom-mailx [mailx] 12.4-2 feature-rich BSD mail(1) ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii nagios-plugins-basic1.4.16-1~bpo60+1 Plugins for nagios compatible moni ii ucf 3.0025+nmu1 Update Configuration File: preserv Versions of packages icinga-common recommends: ii nagios-plugins 1.4.16-1~bpo60+1 Plugins for nagios compatible moni icinga-common suggests no packages. -- Configuration Files: /etc/icinga/icinga.cfg changed [not included] -- debconf information: * icinga/check_external_commands: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689602: pu: package dbus/1.2.24-4+squeeze2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu CVE-2012-3524 (#689070) is a local root privilege escalation vulnerability when setuid-root applications use libdbus without first sanitizing their caller-supplied environment via a whitelist. Applications thought to be exploitable include Xorg via the setuid /usr/bin/X if using libhal (so for us, kFreeBSD but not Linux), and perhaps su/sudo if libpam-systemd or libpam-ck-connector is used. I wasn't able to exploit libpam-ck-connector under a squeeze VM, but perhaps I'm doing it wrong. D-Bus upstream consensus is that it is an application bug to use any non-trivial library in a setuid application without first clearing the caller-supplied environment; but having said that, hardening libdbus against applications with this bug seems wise. When I asked for security team feedback on #689070, they requested that I send this to stable via s-p-u. This is basically the same as the t-p-u option in #689148, but with the patches adjusted for the older libdbus in stable. May I upload? I have source+i386 ready to go; proposed debdiff attached. Regards, S -- System Information: Debian Release: wheezy/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diffstat for dbus-1.2.24 dbus-1.2.24 changelog | 12 patches/0001-CVE-2012-3524-Don-t-access-environment-variables-or-.patch | 213 ++ patches/0002-hardening-Ensure-_dbus_check_setuid-is-initialized-t.patch | 36 + patches/0003-hardening-Remove-activation-helper-handling-for-DBUS.patch | 57 ++ patches/0004-activation-helper-Ensure-DBUS_STARTER_ADDRESS-is-set.patch | 66 +++ patches/series |4 6 files changed, 388 insertions(+) diff -Nru dbus-1.2.24/debian/changelog dbus-1.2.24/debian/changelog --- dbus-1.2.24/debian/changelog 2011-06-14 20:09:38.0 +0100 +++ dbus-1.2.24/debian/changelog 2012-10-04 08:47:17.0 +0100 @@ -1,3 +1,15 @@ +dbus (1.2.24-4+squeeze2) stable; urgency=low + + * CVE-2012-3524: apply patches from upstream 1.6.6 to avoid arbitrary +code execution in setuid/setgid binaries that incorrectly use libdbus +without first sanitizing the environment variables inherited from +their less-privileged caller (Closes: #689070). +- As per upstream 1.6.8, do not check filesystem capabilities for now, + only setuid/setgid, fixing regressions in certain configurations of + gnome-keyring + + -- Simon McVittie s...@debian.org Thu, 04 Oct 2012 08:47:10 +0100 + dbus (1.2.24-4+squeeze1) stable; urgency=low * Update Vcs-* control fields to reflect the move to git diff -Nru dbus-1.2.24/debian/patches/0001-CVE-2012-3524-Don-t-access-environment-variables-or-.patch dbus-1.2.24/debian/patches/0001-CVE-2012-3524-Don-t-access-environment-variables-or-.patch --- dbus-1.2.24/debian/patches/0001-CVE-2012-3524-Don-t-access-environment-variables-or-.patch 1970-01-01 01:00:00.0 +0100 +++ dbus-1.2.24/debian/patches/0001-CVE-2012-3524-Don-t-access-environment-variables-or-.patch 2012-10-04 08:47:17.0 +0100 @@ -0,0 +1,213 @@ +From: Colin Walters walt...@verbum.org +Date: Wed, 22 Aug 2012 10:03:34 -0400 +Subject: [PATCH 1/5] CVE-2012-3524: Don't access environment variables or run + dbus-launch when setuid + +This matches a corresponding change in GLib. See +glib/gutils.c:g_check_setuid(). + +Some programs attempt to use libdbus when setuid; notably the X.org +server is shipped in such a configuration. libdbus never had an +explicit policy about its use in setuid programs. + +I'm not sure whether we should advertise such support. However, given +that there are real-world programs that do this currently, we can make +them safer with not too much effort. + +Better to fix a problem caused by an interaction between two +components in *both* places if possible. + +How to determine whether or not we're running in a privilege-escalated +path is operating system specific. Note that GTK+'s code to check +euid versus uid worked historically on Unix, more modern systems have +filesystem capabilities and SELinux domain transitions, neither of +which are captured by the uid comparison. + +On Linux/glibc, the way this works is that the kernel sets an +AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on +startup. If found, then glibc sets a public-but-undocumented +__libc_enable_secure variable which we can use. Unfortunately, while +it *previously* worked to check this variable, a combination of newer +binutils and RPM break it:
Bug#689603: dpkg-shlibdeps: don't say could avoid a useless dependency if there is no extra (dpkg) dependency
Package: dpkg-dev Version: 1.16.8 Severity: wishlist File: /usr/bin/dpkg-shlibdeps dpkg-shlibdeps warns that package could avoid a useless dependency if an executable or library is linked against any library whose symbols it does not actually use. However, when libraries share a package, unnecessary linking does not necessarily cause a useless dependency. For instance, if you link against any of GLib, GObject, GIO and GModule, uselessly linking against any of the others is not a problem, because you're going to depend on libglib2.0-0 in any case; and if you link against libc, uselessly linking against libm, libpthread etc. does not introduce a dependency, because you're going to depend on libc6 (or libc0.1 or whatever) in any case. In the particular case of libpthread, evading the library dependency can apparently even be harmful, if you're going to dlopen modules that really do depend on libpthread later (which is why GModule explicitly depends on it, and triggers useless dependency warnings in everything that links GModule, which is basically everything GNOME-related). See: http://article.gmane.org/gmane.comp.gnome.gtk+.devel.general/18117 If you're not willing to do this in general, just silencing the warning for libpthread in the same way that's already been done for libm would also be a reasonable solution. Thanks, S -- System Information: Debian Release: wheezy/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg-dev depends on: ii base-files6.11 ii binutils 2.22-7.1 ii bzip2 1.0.6-4 ii libdpkg-perl 1.16.8 ii make 3.81-8.2 ii patch 2.6.1-3 ii xz-utils 5.1.1alpha+20120614-1 Versions of packages dpkg-dev recommends: ii build-essential 11.5 ii clang [c-compiler] 3.1-8 ii fakeroot 1.18.4-2 ii gcc [c-compiler] 4:4.7.1-1 ii gcc-4.6 [c-compiler] 4.6.3-10 ii gcc-4.7 [c-compiler] 4.7.1-9 ii gnupg1.4.12-4+b1 ii gpgv 1.4.12-4+b1 ii libalgorithm-merge-perl 0.08-2 Versions of packages dpkg-dev suggests: ii debian-keyring 2012.06.01 -- 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#631275: [patch] pkg-config-crosswrapper and multiarch
About a year on, here are updated patches for #631275 and #642292,
and a version of Wookey's patch for #650298 that applies on top of those
(also available from the multiarch2 branch in my Alioth repository, gitweb at
http://anonscm.debian.org/gitweb/?p=users/smcv/multiarch/pkg-config.git;a=shortlog;h=refs/heads/multiarch2).
Tollef, Steve, Wookey, anyone else interested: any thoughts on these?
In particular, Tollef, if these changes look OK to you, an upload to
experimental would be great. Any project depending on libraries that rely
on pkg-config to set search paths (such as dbus and glib2.0) can't usefully
be cross-built without something like this.
On Wed, 21 Sep 2011 at 22:36:18 -0700, Steve Langasek wrote:
So my suggestion would be to make the script special-case i386, instead of
adding a runtime dependency on dpkg-dev for dpkg-architecture.
I can do this if you feel strongly about it, but as Wookey pointed out,
dpkg-dev is build-essential. The version in my repository ignores
errors from dpkg-architecture; on non-Debian systems it'll skip the
Debian-style multiarch paths (because $multiarch is empty),
and only use the traditional /usr/TRIPLET-style paths.
Ah; my patch had gone by the manpage and as a result, I overlooked the fact
that the multiarch paths were part of this variable. Yes, we certainly
don't want to search in multiarch directories for the native architecture as
part of the cross tools!
I've checked (via pkg-config --debug) that my version does not do this.
One subtle departure from Steve's patch here is that if you run
armv5tel-linux-gnueabi-pkg-config on an i386 system, it will never search
/usr/lib/pkgconfig - which I think is desirable.
Keeping /usr/lib/pkgconfig on the path was quite deliberate on my part.
Certainly any library shipping in /usr/lib/pkgconfig is not a multiarch
library, but that doesn't actually mean it has to be a *native* library: it
will be possible to cross-install many -dev packages for a while before it's
possible to co-install them together with the native versions.
Fair enough. My second patch attached to this mail does what you asked.
I attach a patch to give the semantics I suggest, plus a patch to put
pkg-config-crosswrapper into a directory that complies with the FHS (with
a compatibility symlink).
By my reading of the FHS, there is no requirement to move it.
I've dropped that patch from the multiarch2 branch.
On Mon, 28 Nov 2011 at 22:06:42 +, Wookey wrote:
Protoecting its use with a test -x would probably be wise.
I'm running it with 2/dev/null; if it isn't executable, ${multiarch}
will be and the multiarch directories will be ignored altogether.
That seems somewhat simpler than playing with command -v to find out
whether there is an executable dpkg-architecture on $PATH.
When the multiarch transition is 'complete' (however we define that)
we can remove /usr/lib/pkgconfig from the search path and
cross-building within your main rootfs will work nicely.
When the time comes, reverting the second patch here will have that effect.
Regards,
S
From c0ae63630dcbb8789f6fe2e546f29f827918d504 Mon Sep 17 00:00:00 2001
From: Simon McVittie s...@debian.org
Date: Wed, 21 Sep 2011 14:29:59 +0100
Subject: [PATCH 1/3] Search multiarch directories in pkg-config-crosswrapper
We use PKG_CONFIG_LIBDIR, not PKG_CONFIG_PATH, so that we don't search
/usr/lib/pkgconfig (legacy path likely to contain wrong-arch libraries),
and so that the user can prepend paths in /opt or whatever by using
PKG_CONFIG_PATH in the usual way.
If the user has set PKG_CONFIG_LIBDIR, the cross-wrapper does nothing -
the user is assumed to know best, just as they are with native pkg-config.
This leaves the search path as something like this (if you invoke
armv5tel-linux-gnueabi-pkg-config):
if PKG_CONFIG_PATH is set:
the elements of PKG_CONFIG_PATH
if PKG_CONFIG_LIBDIR is set:
the elements of PKG_CONFIG_LIBDIR
else:
/usr/local/lib/arm-linux-gnueabi/pkgconfig (site multiarch)
/usr/local/share/pkg-config (site arch-indep)
/usr/local/armv5tel-linux-gnueabi/lib/pkgconfig (site pre-MA cross)
/usr/lib/arm-linux-gnueabi/pkgconfig(distro multiarch)
/usr/share/pkg-config (distro arch-indep)
/usr/armv5tel-linux-gnueabi/lib/pkgconfig (distro pre-MA cross)
Signed-off-by: Simon McVittie s...@debian.org
---
debian/changelog | 18 ++
debian/control |1 +
debian/pkg-config-crosswrapper | 30 --
3 files changed, 47 insertions(+), 2 deletions(-)
mode change 100644 = 100755 debian/pkg-config-crosswrapper
diff --git a/debian/changelog b/debian/changelog
index b6adc3c..07814f7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+pkg-config (0.26-1+multiarch) UNRELEASED; urgency=low
+
+ [ Steve Langasek ]
+ *
Bug#689604: libgpg-error: dpatch leftovers cause deeply confusing source package layout
Package: libgpg-error Version: 1.10-3.1 Severity: normal $ cat debian/source/format 3.0 (quilt) $ ls debian/patches/ 00list 06_Makefile.in.dpatch l10n_update.patch series 05_Makefile.am.dpatch 10_relibtoolize.dpatch m4_macros.dpatch The series file was added in an NMU; but even before that, having both 3.0 (quilt) and dpatch leftovers in the same package is too confusing for words. As far as I can tell, what happened is that these old dpatch files were correctly removed in an NMU (1.10-0.1), and then when the maintainer integrated that NMU in 1.10-1 he reintroduced debian/patches/ along with debian/docs. The history in the automatic import at https://bazaar.launchpad.net/+branch/debian/libgpg-error makes it quite clear: revno: 7 tags: 1.10-1 author: Jose Carlos Garcia Sogo js...@debian.org committer: Package Import Robot package-imp...@ubuntu.com branch nick: sid timestamp: Sat 2011-09-10 12:39:11 +0200 message: Ack all previous NMU. All thanks go to Jonas Meurer. added: debian/docs debian/patches/ debian/patches/00list debian/patches/05_Makefile.am.dpatch debian/patches/06_Makefile.in.dpatch debian/patches/10_relibtoolize.dpatch debian/patches/m4_macros.dpatch modified: debian/changelog Simple use of debdiff would have caught this problem. Please remove these files again. Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689605: multipath-tools: no default multipath.conf
Package: multipath-tools
Version: 0.4.8+git0.761c66f-10
Severity: normal
Since the multipath-tools package includes no standard multipath.conf,
multipathd will grab any new block device. This can lead to surprising and hard
debug effects.
e.g. attaching a device in a XEN dom0 domain will render the device
inaccessible. This corrupts xen-utils-4.1 since xend will attach the boot
device locally for pygrub, but can't release it properly because multipathd has
it.
I suggest supplying at least a minimal multipath.conf that blacklists the most
dangerous devices by default.
-- Package-specific info:
Contents of /etc/multipath.conf:
blacklist
{
devnode ^xvd[0-9a-z]*
}
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (990, 'stable'), (100, 'stable-updates'), (100, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages multipath-tools depends on:
ii initscripts2.88dsf-32scripts for initializing and shutt
ii kpartx 0.4.8+git0.761c66f-10 create device mappings for partiti
ii libaio10.3.107-7 Linux kernel AIO access library -
ii libc6 2.13-33 Embedded GNU C Library: Shared lib
ii libdevmapper1.02.1 2:1.02.74-4 Linux Kernel Device Mapper userspa
ii libncurses55.7+20100313-5shared libraries for terminal hand
ii libreadline6 6.1-3 GNU readline and history libraries
ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii udev 164-3 /dev/ and hotplug management daemo
multipath-tools recommends no packages.
Versions of packages multipath-tools suggests:
pn multipath-tools-boot none (no description available)
-- 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#688041: Please confirm
[sorry for accidentally dropping the bug address; OTOH this gives me the opportunity to include only the bug-relevant parts in the bug] On 04.10.2012 05:54, Norbert Preining wrote: [...] Please go ahead and propose a splitting instead pf whining, Well, I did exactly that in this bug report. And if you mean by propose that I was to give a complete splitting strategy on what should go where, I naively thought the maintainer would know better than me anyway, but if asked I would propose one font family per package. If there are actions involved (mktexlsr etc.), I propose using an apt trigger. a splitting that will be accepted upstream. Now here is a point I don't understand: What does upstream have to do with debian packages? I didn't suggest splitting the source package (which would probably be sensible, yes), but splitting the binary package texlive-fonts-extra. There are undoubtedly many other packages that split the compiled output of their sources into smaller binary packages (e.g. when splitting into -data, -doc, -dev etc.) without needing written consent by upstream. [...] Yours Thomas Kremer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688953: freeze-exception: nvidia-graphics-drivers/304.48-3 - libgl1-nvidia-glx package split
On 2012-09-27 12:16, Andreas Beckmann wrote: Please approve the following changes for package nvidia-graphics-drivers: As discussed in #688861 (freeze exception for libxvmc) yesterday, there is another possibility to address the missing multiarchification of libxvmc1: if we split the libgl1-nvidia-glx package and move one library to a new libxvmcnvidia1 library we can move the dependency on libxvmc1 to that new package and libgl1-nvidia-glx will have its dependencies satisfied for installing libgl1-nvidia-glx:i386 along with libgl1-nvidia-glx:amd64. I'd really like to know whether this is an acceptable solution for wheezy, so that I could proceed ... Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689520: No libcuda1-dev package provided by backports
On 2012-10-03 16:01, Jan Stolarek wrote: Backports repository for Squeeze provides libcuda1 package updated to 295.59 but it does not provide corresponding development package. This makes CUDA development impossible for people who want to rely only on packages provided in repositories. Please package the corresponding development package and place it in backports. So you actually want nvidia-cuda-toolkit backported? That would be possible ... Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689606: unblock: mdp/3.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package mdp Dear Release Team, mdp/3.3-1 fixes two FTBFS bugs -- #687408 and #689027 -- and enables full use of python-sklearn 0.11.0 version now in wheezy -- only versions up to 0.10 were supported until now -- see #689028. All changes in the attached debdiff are related to the above mentioned problems. The relatively long diff for the file CHANGES can be safely ignored, most of those changes are already present in mdp/3.2+git78-g7db3c50 currently in wheezy. A number of hunks are whitespace-only changes introduced by the new python-mode in emacs: upstream didn't feel like rebasing a public github repo just to expunge them. The package features a quite extensive unittests battery which is run at build time. It passes successfully even across different Debian and Ubuntu releases (tested on the NeuroDebian buildbots). This gives me enough confidence to ask for the package to be released with wheezy. Please allow mdp/3.3-1 in testing. Thanks, Tiziano Zito unblock mdp/3.3-1 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-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 diff -Nru mdp-3.2+git78-g7db3c50/CHANGES mdp-3.3/CHANGES --- mdp-3.2+git78-g7db3c50/CHANGES 2012-04-05 16:01:52.0 +0200 +++ mdp-3.3/CHANGES 2012-09-28 14:48:39.0 +0200 @@ -1,3 +1,148 @@ +MDP-3.3: +2012-09-19: FIX: fix error in automatic testing for MultinomialNB. +2012-09-19: ERF: make sklearn nodes automatic testing more robust The previous +solution was actually ignoring the special definitions in NODES. + +2012-09-19: FIX: disable pp support if server can not start Being able to +import pp is not enough to be sure that pp works. For example in a +low memory situation, the following can happen: + + import pp + server = pp.Server() +[...] OSError: [Errno 12] Cannot allocate memory + +This fix just disables pp support if the server can not be +started. + +2012-06-18: FIX: Fix wrapping of sklearn 0.11 classifiers +2012-04-17: FIX: make test_SFA2Node even more robust +2012-04-16: FIX: make FastICANode test more robust +2012-04-16: FIX: make test_SFA2Node more robust +2012-04-05: FIX: fix pp_tests when run multiple times. pp tests were failing +when run twice in a row. hugly work-around, but it seems to +work... + +2012-04-05: FIX: fixed broken test_reload. test_reload was failing when called +twice in a row. + +2012-04-05: FIX: fix random seed tests. The tests were failing when called +twice in a row: + import mdp + mdp.test() + mdp.test() the first call was working, the second one was +giving failures. + +2012-04-01: ERF: added tests for learning of bias parameters +2012-03-26: FIX: replace third remaing test for pp_monkeypatch_dirname +Hopefully this will fix test suite failures. + +2012-03-22: FIX: Decrease the noise level in the DiscreteHopfieldClassifier. +2012-03-22: FIX: honor MDP_DISABLE_SHOGUN env variable +2012-03-19: FIX: fix left-over directories from testing pp. I do not know why, +but this simple change fixes the leftover directories problem when +testig with python-pp and pp monkey-patching. It should have +worked even as it was before, but apparently some race condition +happens. + +2012-03-06: FIX: fix determinant of random rotation matrix determinant sign +was wrong if dimensions of rotation matrix were odd. Thanks to +Philip DeBoer. Actual Fix. + +2012-03-06: FIX: fix determinant of random rotation matrix determinant sign +was wrong if dimensions of rotation matrix were odd. Thanks to +Philip DeBoer. Failing Test. + +2012-02-13: ENH: remove duplicated and overly verbose code +2012-02-13: FIX: remove FastICA stabilization from tests +2012-02-13: FIX: remove unused parameter stabilization in FastICA. +2012-01-19: NEW: added new sklearn algorithms wrapping We now wrap 93 sklearn +algorithms! + +2012-01-19: FIX: fix another imcompatibility with sklearn 0.10 Although +EllipticEnvelop is derived from sklearn.base.ClassifierMixin, it +is not a classifier. It is actually a predictor. Added a check +in the sklearn wrappers. + +2012-01-19: FIX: fix sklearn wrappers for version 0.10 New sklearn version +introduces classifiers and predictors mixin classes that do not +have a 'fit' method. Typical error: + +AttributeError: type object 'OutlierDetectionMixin' has no +
