Bug#757112: [Debian-hebrew-package] Bug#757112: please build using dh-autoreconf
Thanks for the upload. Kaplan On Wed, Sep 10, 2014 at 5:23 PM, Andreas Barth a...@ayous.org wrote: * Matthias Klose (d...@debian.org) [140910 16:20]: please can you NMU all the M-A patches as well? Or just upload the Ubuntu package? ;) Lior, are the m-a-changes for you ok as well? If so, I could include them in the upload. Andi
Bug#758048: [dx] debian/rules:92: recipe for target 'install-stamp' failed
Control: severity -1 normal Hi Bastien On Wed, 13 Aug 2014 20:19:54 + bastien ROUCARIES roucaries.bast...@gmail.com wrote: Your package fail to build from source: So, one step further. We just had a successful rebuild of dx in unstable on ALL official architectures where it used to build (several ports were not rebuild and the ones that were scheduled and build, none failed so far). As such I downgrade the severity to normal. I still like to know what is different in your build environment in order to (maybe) prevent it. Please close this bug if you think it is not worth keeping open. Paul signature.asc Description: OpenPGP digital signature
Bug#761117: debsources: file-level deduplication
On Thu, Sep 11, 2014 at 4:31 AM, Stefano Zacchiroli wrote: We already have all the file checksums in the database. Removing (file-level) duplication in the file storage, using hard-links, can be safely implemented offline, i.e., as long as no debsources update is ongoing. I missed the talk, but some other ideas: A hash based filesystem layout like we use on snapshot.d.o. Use a filesystem with deduplication support like btrfs. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758619:
Hi Version 6.5.1 is installed on my system and the bug is still there. = apt show reportbug Package: reportbug Version: 6.5.1 Installed-Size: 226 kB Maintainer: Reportbug Maintainers reportbug-ma...@lists.alioth.debian.org Depends: python, python:any (= 2.6~), apt, python-reportbug (= 6.5.1) Suggests: postfix | exim4 | mail-transport-agent, gnupg | pgp, debconf-utils ( 1.1.0), debsums (= 2.0.47), file ( 1.30), dlocate, python-urwid, python-gtk2, python-vte, python-gtkspell, xdg-utils, emacs22-bin-common | emacs23-bin-common, claws-mail (= 3.8.0) Homepage: http://alioth.debian.org/projects/reportbug/ Tag: devel::bugtracker, implemented-in::python, interface::commandline, mail::smtp, network::client, protocol::http, protocol::smtp, role::program, scope::utility, suite::debian, use::TODO, works-with-format::plaintext, works-with::bugs Section: utils Priority: standard Download-Size: 122 kB APT-Manual-Installed: yes APT-Sources: http://http.us.debian.org/debian/ unstable/main amd64 Packages Description: reports bugs in the Debian distribution reportbug is a tool designed to make the reporting of bugs in Debian and derived distributions relatively painless. Its features include: . * Integration with mutt and mh/nmh mail readers. * Access to outstanding bug reports to make it easier to identify whether problems have already been reported. * Automatic checking for newer versions of packages. * Optional automatic verification of integrity of packages via debsums. * Support for following-up on outstanding reports. * Optional PGP/GnuPG integration. . reportbug is designed to be used on systems with an installed mail transport agent, like exim or sendmail; however, you can edit the configuration file and send reports using any available mail server. . This package also includes the querybts script for browsing the Debian bug tracking system. = On execution : l@leonardo ~ % reportbug Attempt to unlock mutex that was not locked zsh: abort reportbug l@leonardo ~ % echo $? 134 l@leonardo ~ % signature.asc Description: This is a digitally signed message part
Bug#761149: debsources: allow redirects to package versions based on suite/codename
Package: qa.debian.org Severity: wishlist User: debian...@lists.debian.org Usertags: debsources It would be great if debsources could allow codenames and suites in the version number field (in addition to 'latest') so these URLs worked: http://sources.debian.net/src/linux/experimental/ http://sources.debian.net/src/linux/unstable/ http://sources.debian.net/src/linux/sid/ http://sources.debian.net/src/linux/stable/ http://sources.debian.net/src/linux/wheezy/ http://sources.debian.net/src/linux/etch/ -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#761150: ITP: libpgobject-type-datetime-perl -- Datetime wrappers for PGObject
Package: wnpp Owner: Robert James Clay j...@rocasa.us Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libpgobject-type-datetime-perl Version : 1.0.2 Upstream Author : Chris Travers chris.trav...@gmail.com License : BSD-2-clause Description : PGObject::Type::DateTime - Datetime wrappers for PGObject classes This module provides a general wrapper for Perl DateTime objects for PostgreSQL date and time values. Once it is registered, it returns DateTime objects (via this wrapper class) which can be automatically serialized into PostgreSQL date and time values. Whether to print date and time is persisted and stored. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761151: lxmenu-data and lxlauncher: error when trying to install together
Package: lxlauncher,lxmenu-data Version: lxlauncher/0.2.3-1 Version: lxmenu-data/0.1.3-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2014-09-11 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: Extracting templates from packages: 41% Extracting templates from packages: 83% Extracting templates from packages: 100% Preconfiguring packages ... Selecting previously unselected package libgmp10:amd64. (Reading database ... 10869 files and directories currently installed.) Preparing to unpack .../libgmp10_2%3a6.0.0+dfsg-6_amd64.deb ... Unpacking libgmp10:amd64 (2:6.0.0+dfsg-6) ... Selecting previously unselected package libnettle4:amd64. Preparing to unpack .../libnettle4_2.7.1-3_amd64.deb ... Unpacking libnettle4:amd64 (2.7.1-3) ... Selecting previously unselected package libhogweed2:amd64. Preparing to unpack .../libhogweed2_2.7.1-3_amd64.deb ... Unpacking libhogweed2:amd64 (2.7.1-3) ... Selecting previously unselected package libffi6:amd64. Preparing to unpack .../libffi6_3.1-2_amd64.deb ... Unpacking libffi6:amd64 (3.1-2) ... Preparing to unpack .../libp11-kit0_0.20.3-2_amd64.deb ... Unpacking libp11-kit0:amd64 (0.20.3-2) over (0.18.5-3) ... Selecting previously unselected package libtasn1-6:amd64. Preparing to unpack .../libtasn1-6_4.1-2_amd64.deb ... Unpacking libtasn1-6:amd64 (4.1-2) ... Selecting previously unselected package libgnutls-deb0-28:amd64. Preparing to unpack .../libgnutls-deb0-28_3.3.7-2_amd64.deb ... Unpacking libgnutls-deb0-28:amd64 (3.3.7-2) ... Selecting previously unselected package libkeyutils1:amd64. Preparing to unpack .../libkeyutils1_1.5.9-5_amd64.deb ... Unpacking libkeyutils1:amd64 (1.5.9-5) ... Selecting previously unselected package libkrb5support0:amd64. Preparing to unpack .../libkrb5support0_1.12.1+dfsg-9_amd64.deb ... Unpacking libkrb5support0:amd64 (1.12.1+dfsg-9) ... Selecting previously unselected package libk5crypto3:amd64. Preparing to unpack .../libk5crypto3_1.12.1+dfsg-9_amd64.deb ... Unpacking libk5crypto3:amd64 (1.12.1+dfsg-9) ... Selecting previously unselected package libkrb5-3:amd64. Preparing to unpack .../libkrb5-3_1.12.1+dfsg-9_amd64.deb ... Unpacking libkrb5-3:amd64 (1.12.1+dfsg-9) ... Selecting previously unselected package libgssapi-krb5-2:amd64. Preparing to unpack .../libgssapi-krb5-2_1.12.1+dfsg-9_amd64.deb ... Unpacking libgssapi-krb5-2:amd64 (1.12.1+dfsg-9) ... Selecting previously unselected package libxml2:amd64. Preparing to unpack .../libxml2_2.9.1+dfsg1-4_amd64.deb ... Unpacking libxml2:amd64 (2.9.1+dfsg1-4) ... Selecting previously unselected package libglib2.0-0:amd64. Preparing to unpack .../libglib2.0-0_2.40.0-5_amd64.deb ... Unpacking libglib2.0-0:amd64 (2.40.0-5) ... Selecting previously unselected package libatk1.0-data. Preparing to unpack .../libatk1.0-data_2.12.0-1_all.deb ... Unpacking libatk1.0-data (2.12.0-1) ... Selecting previously unselected package libatk1.0-0:amd64. Preparing to unpack .../libatk1.0-0_2.12.0-1_amd64.deb ... Unpacking libatk1.0-0:amd64 (2.12.0-1) ... Selecting previously unselected package libavahi-common-data:amd64. Preparing to unpack .../libavahi-common-data_0.6.31-4_amd64.deb ... Unpacking libavahi-common-data:amd64 (0.6.31-4) ... Selecting previously unselected package libavahi-common3:amd64. Preparing to unpack .../libavahi-common3_0.6.31-4_amd64.deb ... Unpacking libavahi-common3:amd64 (0.6.31-4) ... Selecting previously unselected package libdbus-1-3:amd64. Preparing to unpack .../libdbus-1-3_1.8.6-2_amd64.deb ... Unpacking libdbus-1-3:amd64 (1.8.6-2) ... Selecting previously unselected package libavahi-client3:amd64. Preparing to unpack .../libavahi-client3_0.6.31-4_amd64.deb ... Unpacking libavahi-client3:amd64 (0.6.31-4) ... Selecting previously unselected package libexpat1:amd64. Preparing to unpack .../libexpat1_2.1.0-6_amd64.deb ... Unpacking libexpat1:amd64 (2.1.0-6) ... Selecting previously unselected package libpng12-0:amd64. Preparing to unpack .../libpng12-0_1.2.50-2_amd64.deb ... Unpacking libpng12-0:amd64 (1.2.50-2) ... Selecting previously unselected package libfreetype6:amd64. Preparing to unpack .../libfreetype6_2.5.2-1.1_amd64.deb ... Unpacking libfreetype6:amd64 (2.5.2-1.1) ... Selecting previously unselected package ucf. Preparing to unpack .../archives/ucf_3.0030_all.deb ... Moving old data out of the way Unpacking ucf (3.0030) ... Selecting previously unselected package fonts-dejavu-core. Preparing to unpack .../fonts-dejavu-core_2.34-1_all.deb ... Unpacking fonts-dejavu-core (2.34-1) ... Selecting previously unselected package fontconfig-config. Preparing to unpack .../fontconfig-config_2.11.0-6.1_all.deb ... Unpacking fontconfig-config (2.11.0-6.1) ... Selecting previously unselected package libfontconfig1:amd64. Preparing to unpack .../libfontconfig1_2.11.0-6.1_amd64.deb ...
Bug#739845: roger is in NEW
the package has just entered the NEW queue, let's hope it's still in time for jessie. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760261: [opam] opam broken by dose.3.2.2 update
On 09/11/2014 01:38 AM, Mehdi Dogguy wrote: Le 2014-09-02 09:29, Török Edwin a écrit : Package: opam Version: 1.1.1-1+b1 Severity: normal --- Please enter the report below this line. --- opam version is now 1.1.1-1+b1, which is broken due to using dose.3.2.2 instead of 3.1.x (as the initial version without +b1 apparently did). This would've been detected by opam's testsuite, except that Debian didn't build/run that test-suite due to using its own build-system. Can you please tell us how exactly opam is broken? Do you have a test that produces an error? What worked using 1.1.1-1 but didn't using version 1.1.1-1+b1? Testcase is: $ (export OPAMROOT=/tmp/opamroot; rm -rf $OPAMROOT; opam init opam install ocamlfind opam install lwt) This works with 1.1.1-1. Fails with 1.1.1-1+b1 trying to install ocamlfind again (it is already installed by first opam install command): [...] # Makefile:150: depend: No such file or directory # ocamlfind: Package bytes is already installed # - (file /tmp/opamroot/system/lib/bytes/META already exists) # make[1]: *** [install] Error 2 # make: *** [install] Error 2 Best regards, --Edwin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761074: RFS: cputool/0.0.7-1 [ITP]
On Wed, 2014-09-10 at 21:01 +, Nigel Kukard wrote: Hi Nigel, even if already uploaded, you've askes two question I'd like to answer: On 09/10/2014 08:22 PM, Tobias Frost wrote: - there are extra ,s after the years in line 8 and 12 Could you clarify this for me Tobias, I must be missing something, I copied an example that Eriberto gave me here... http://metadata.ftp-master.debian.org/changelogs/main/s/sentinella/unstable_copyright The format is specified in https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field The file format gives you many freedoms, so you format actually not really wrong, but for the symmetry the , was somehow disturbing my eyes as a comma indicates somehow there is something to follow. As said, its a nitpick. - d/control - I'd prefer only to override when necessary. In this case, please remove the file using d/clean. - please use dh_autoreconf Sorted. I now have this, I hope its what you were referring to... *** $ cat rules #!/usr/bin/make -f %: dh $@ --with autoreconf *** Yes, perfect. (you've also added a B-D on dh_autoreconf, haven't you?) Thanks again for your time! -N -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761152: ITP: python-strict-rfc3339 -- Strict, simple, lightweight RFC3339 functions
Package: wnpp Severity: wishlist Owner: Florian Preinstorfer f...@xell.at * Package name: python-strict-rfc3339 Version : 0.4 Upstream Author : Daniel Richman, Adam Greig * URL : https://pypi.python.org/pypi/strict-rfc3339/ * License : GPL-3 Programming Lang: Python Description : Strict, simple, lightweight RFC3339 functions This package tries to stick as closely as possible to RFC3339. Its goals are: * Convert unix timestamps to and from RFC3339. * Either produce RFC3339 strings with a UTC offset (Z) or with the offset that the C time module reports is the local timezone offset. * Simple with minimal dependencies/libraries. * Avoid timezones as much as possible. * Be very strict and follow RFC3339 as closely as possible. This program may be used to improve the validation of json-schema files. The package python-jsonschema optionally uses this program (if it is installed) to check the format 'date-time' as specified in the json schema specification. This package is used in-house and we'd like to contribute it back to Debian. A sponsor would be needed and a first draft of the package is available at [1]. regards, Florian [1] https://github.com/nblock/python-strict-rfc3339 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661110: orphaning isdnutils
retitle 661110 RFA: isdnutils -- ISDN utilities thanks The package was forced into a direction I do not approve of, in a part of the package that I don't really use myself and that has only a very limited user base nowadays. This has all but killed my motivation for isdnutils. I feel it's time for me to let it go. I will continue to maintain libcapi20 and it would be nice to share maintainship for isdnutils over a transitional period with whoever would like to step up as the main Debian maintainer. This is to make sure that for example configuration files are not creating any conflicts (this is something I still need to look more carefully into after the carve-out of libcapi) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729133: Forwarded desktop entry bug upstream
Control: tags + pending patch Control: forwarded 729133 https://gramps-project.org/bugs/view.php?id=8062 I have patched the desktop file with a Keywords entry, and forwarded the patch upstream. The keyword entries probably should be translated though! Ross signature.asc Description: OpenPGP digital signature
Bug#761107: Thanks for the repport
Hi Ralf, Thanks a lot for these bug reports. In fact, if I made the dependencies this way, it's because the python-xstatic-* packages really need to be tightly coupled, in terms of versionning, to the libjs package. So I wanted to make sure that the libjs packages don't get updates with updates of the python-xstatic packages as well. And that's exactly what's happening right now, with these 3 bug reports. So thanks again! I'm uploading fixes right now. Cheers, Thomas Goirand -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761074: RFS: cputool/0.0.7-1 [ITP]
Hi there Tobias, I'd just like to thank you again for the time you've taken below and pointing me in the right direction, its very much appreciated. Nothing but perfection is really not good enough ;), I've made a note on each item and will include it in my own checks in future. On 09/11/2014 06:31 AM, Tobias Frost wrote: - there are extra ,s after the years in line 8 and 12 Could you clarify this for me Tobias, I must be missing something, I copied an example that Eriberto gave me here... http://metadata.ftp-master.debian.org/changelogs/main/s/sentinella/unstable_copyright The format is specified in https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field The file format gives you many freedoms, so you format actually not really wrong, but for the symmetry the , was somehow disturbing my eyes as a comma indicates somehow there is something to follow. As said, its a nitpick. Excellent! I see what you mean, its the ,'s behind the dates. I've removed them, it does look a bit easier on the eyes. Thanks for pointing this out! - d/control - I'd prefer only to override when necessary. In this case, please remove the file using d/clean. - please use dh_autoreconf Sorted. I now have this, I hope its what you were referring to... *** $ cat rules #!/usr/bin/make -f %: dh $@ --with autoreconf *** Yes, perfect. (you've also added a B-D on dh_autoreconf, haven't you?) Excellent, thanks Tobias. I've made the relevant changes, I hope you find them satisfactory and feel free to note any other improvements I can make to improve quality :) http://mentors.debian.net/package/cputool dget -x http://mentors.debian.net/debian/pool/main/c/cputool/cputool_0.0.7-1.dsc -N -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761153: python-jsonschema: Improve format validation by optionally depending on python-strict-rfc3339
Source: python-jsonschema Version: 2.3.0-1 Severity: wishlist Hi, python-jsonschema allows the validation of formats as described in [1]. In order to validate the format 'date-time', upstream uses the package strict-rfc3339. I think it would be good to add an optional dependency to this packages. As it is not yet part of Debian, I created an initial version of the package and filed an ITP [2]. regards, Florian [1] http://python-jsonschema.readthedocs.org/en/latest/validate/#validating-formats [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761152 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761079: debsources: support multiple archives
On Thu, Sep 11, 2014 at 01:42:20PM +0800, Paul Wise wrote: On Wed, Sep 10, 2014 at 11:56 PM, Stefano Zacchiroli wrote: (e.g., derivatives). For derivatives, the best thing will be replacing debmirror with rsyncing sources.list files (and or apt directories) from the derivs census plus apt-get update and apt-get source. Do you maybe already have code that does this (at list the first part, up to some sort of containerized apt-get update) as part of the census script? If so, mind posting to this bug report pointers to it? Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#761152: ITP: python-strict-rfc3339 -- Strict, simple, lightweight RFC3339 functions
Florian Preinstorfer f...@xell.at (2014-09-11): Package: wnpp Severity: wishlist Owner: Florian Preinstorfer f...@xell.at * Package name: python-strict-rfc3339 Version : 0.4 Upstream Author : Daniel Richman, Adam Greig * URL : https://pypi.python.org/pypi/strict-rfc3339/ * License : GPL-3 Programming Lang: Python Description : Strict, simple, lightweight RFC3339 functions This package tries to stick as closely as possible to RFC3339. Its goals are: * Convert unix timestamps to and from RFC3339. * Either produce RFC3339 strings with a UTC offset (Z) or with the offset that the C time module reports is the local timezone offset. * Simple with minimal dependencies/libraries. * Avoid timezones as much as possible. * Be very strict and follow RFC3339 as closely as possible. This program may be used to improve the validation of json-schema files. The package python-jsonschema optionally uses this program (if it is installed) to check the format 'date-time' as specified in the json schema specification. This package is used in-house and we'd like to contribute it back to Debian. A sponsor would be needed and a first draft of the package is available at [1]. FWIW this was uploaded but didn't pass the GPG check: | Sep 11 06:43:38 processing /python-strict-rfc3339_0.4-1_source.changes | Sep 11 06:43:39 GnuPG signature check failed on python-strict-rfc3339_0.4-1_source.changes | Sep 11 06:43:39 (Exit status 2) | Sep 11 06:43:39 /python-strict-rfc3339_0.4-1_source.changes has bad PGP/GnuPG signature! | Sep 11 06:43:39 Removing /python-strict-rfc3339_0.4-1_source.changes, but keeping its associated files for now. (I was looking at queued's log for other reasons when I noticed this, so I thought I'd drop you a quick note.) Mraw, KiBi. signature.asc Description: Digital signature
Bug#760712: WEP vs WPA2
With this installation I was using WPA2-Personal at the access point. I see the log messages look similar as in bug #741622, deauthenticating immediately after connect. For a later install on the same computer, also to USB target, I used WEP in the installer to connect to the access point (installation report #761148). So possibly the problem has to do with WPA2 as opposed to WEP. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759517: Info received (Bug#759517: Info received (digikam: When starting digikam it searches for new pictures and then nothing more happens.))
Hi I've just solved this bug or at least identified the culprit. It's Gstreamer. So what I did: apt-get install phonon-backend-vlc dpkg -r phonon-backend-gstreamer:amd64 in systemsettings, the phonon engine was automatically switched to the only one available, VLC. And now digikam starts normally. I believe it's linked to this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760663 and they say that next phonon package update should fix it. In the meanwhile, using another backend is a good workaround. regards Massis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
[Cyril Brulebois] Of course a failing d-i build means src:debian-installer FTBFS. What else would that be? Thanks for asking. To me, it could also mean a failing to build a ISO with d-i udebs on it. But I had already tested ISO builds, and thus was a bit unsure what was failing for you. Please explain how you managed to build installation images with a failing d-i build. The ISO build system understand and handle the provides header, and the ISO build is working as before the deb was introduced, as can be seen on for example URL: http://lists.alioth.debian.org/pipermail/debian-edu-commits/2014-September/008537.html . I'm not sure why you're insisting on the renaming. Please explain why you did that (see my first follow-up). Somehow I get the impression that you do not really want to understand why I did this change but just want a set of arguments to brush off before reverting it, but I hope it is just a language barrier issue. Anyway, here are the explanation why I introduced a archdetect deb and how the change have been tested so far. * A archdetect deb allow users on installed systems to figure out which kernel the installer want to install on a given machine. * The need for a normal deb for archdetect have been on the TODO list for years, see for example debian-installer/doc/TODO listing this entry in the Post-etch goals list: - real deb from archdetect udeb (luther) * The deb was already present in Ubuntu, under the name archdetect-deb. Adding the deb in Debian can reduce the diff with Ubuntu. * We normally in Debian name udebs with a -udeb postfix, and name packages after the binary they contain. Diverting from this common naming scheme should be avoided. This I decided to use the sensible name for the deb in Debian, and switch the udeb to have the name we commonly use for udebs in debian, package-udeb. * I knew d-i (anna-install and the rest of the d-i installation system) would handle the provides header, and tested this on a fresh install in a virtual machine before commiting the change. * I checked how many udebs were depending on archdetect (6, if I recall correctly), and new they would cope just fine with the change. * Knew the Debian archive would handle the rename, as udebs and debs have different name spaces, and we use the provides method with several library udebs already. So the change was tested and the installer was working as it should also after the rename. The only thing I didn't test was building the debian-installer source package itself, which broke as you correctly observed. The simple fix is to replace archdetect with archdetect-udeb, but a more proper fix is probably to teach the build of d-i initrds to understand the provides header, to ensure similar issues do not arise in the future. The simple fix is in look like this (commits 50506fe7643ecf44ccc388dab04e3c7fba085dcd and 9925e98994c4406b616e21d9db2703eca5b6ce32) in the debian-installer git repo: diff --git a/debian/changelog b/debian/changelog index a6d89a2..f732bcc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -29,6 +29,10 @@ debian-installer (2014) UNRELEASED; urgency=low - raise the xorriso build dependency to = 1.3.2-1~ on these architectures, for compatibility with grub-mkrescue in GRUB 2.02 + [ Petter Reinholdtsen ] + * Adjust package lists to cope with the archdetect-archdetect-udeb +rename, and remove the rename item from the TODO (Closes: #761135). + -- Cyril Brulebois k...@debian.org Sat, 02 Aug 2014 02:59:35 +0200 debian-installer (20140802) unstable; urgency=low diff --git a/build/pkg-lists/base b/build/pkg-lists/base index 4650288..12c66e2 100644 --- a/build/pkg-lists/base +++ b/build/pkg-lists/base @@ -2,7 +2,7 @@ # get them. busybox-udeb anna -archdetect +archdetect-udeb cdebconf-udeb cdebconf-priority di-utils diff --git a/build/pkg-lists/cdrom/m68k.cfg b/build/pkg-lists/cdrom/m68k.cfg index 61d6947..5ef5b33 100644 --- a/build/pkg-lists/cdrom/m68k.cfg +++ b/build/pkg-lists/cdrom/m68k.cfg @@ -7,4 +7,4 @@ console-setup-amiga-ekmap console-setup-ataritt-ekmap console-setup-udeb kbd-udeb -archdetect +archdetect-udeb diff --git a/build/pkg-lists/hd-media/m68k.cfg b/build/pkg-lists/hd-media/m68k.cfg index d9c75bb..0b61609 100644 --- a/build/pkg-lists/hd-media/m68k.cfg +++ b/build/pkg-lists/hd-media/m68k.cfg @@ -5,4 +5,4 @@ console-setup-amiga-ekmap console-setup-ataritt-ekmap console-setup-udeb kbd-udeb -archdetect +archdetect-udeb diff --git a/doc/TODO b/doc/TODO index ed6167b..f73f37e 100644 --- a/doc/TODO +++ b/doc/TODO @@ -147,7 +147,6 @@ Post-etch goals - low(er) mem (zboob) - uml for testing d-i (anton) - post reboot network configuration (cjwatson) - - real deb from archdetect udeb (luther) - integrate selinux installation into the installer, for a painless install (joeyh/manoj?) - add a xen server task (joeyh)
Bug#761105: debsources: on the fly package diff / debdiff
On Thu, Sep 11, 2014 at 01:47:33PM +0800, Paul Wise wrote: On Thu, Sep 11, 2014 at 3:01 AM, Stefano Zacchiroli wrote: Add the ability to diff arbitrary version of packages available in Debsources, producing a debdiff as a result. FYI, we were thinking about adding debdiff capabilities to snapshot.debian.org, that might make more sense since it has more package versions? We're gonna need it on debsources anyhow, in particular to implement the edit feature suggested by Raphael Geissert. What we could do is to factorize as much as possible the common parts in a common place, e.g., python-debian. But I'm not sure there is actually that *much* code to write, considering that 1) we will probably invoke the real debdiff as an external program anyhow and 2) I plan to delegate diff highlighting to the javascript toolkit we already use. What else is there to be done? -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#761154: OpenJPEG 2.1 is out !
Package: openjpeg2 openjpeg 2.0.0 is old, please provide 2.1 for jessie. Package such as Leptonica do need it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761117: debsources: file-level deduplication
On Thu, Sep 11, 2014 at 02:09:35PM +0800, Paul Wise wrote: A hash based filesystem layout like we use on snapshot.d.o. Use a filesystem with deduplication support like btrfs. I thought about btrfs back in the days, and ruled out the idea because it imposes a fairly important deployment requirement. Regarding a hash-based filesystem layout, that will get in the way of dpkg-source -x, meaning you will need to massage the files into the has layout after package extraction. Plus, you lose the ability to use the natural file organization as the url structure that you present to the user. All in all, offline deduplication seems much more appealing and, up to now, it seems to have no drawbacks whatsoever (except a negligible lag between the extraction time and the deduplication run). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#761034: debconf-set-selections is ignored
On 09/10/14 21:49, Joey Hess wrote: It's up to individual packages how they deal with debconf settings. In general, the current configuration of the system is preferred over what is in the debconf cache when reconfiguring a package. It's often considered a bug if a package uses some, possibly old value from the debconf cache and blows away local admin changes to the system. I understand. Maybe I am too blind to see, but this is completely left out in debconf(1) and others, i.e. the confusing and unex- pected still stands. Maybe it would help to extend the Debian policy to make sure that packages do not ignore their own(!) options stored in the debconf database? Just for using debconf, of course. Debconf preseeding is not really intended to be used with dpkg-reconfigure, but instead to be done before a package is installed for the first time. debconf-set-selections(1): debconf-set-selections can be used to pre-seed the debconf data- base with answers, or to change answers in the database. Each question will be marked as seen to prevent debconf from asking the question interactively. WARNING Only use this command to seed debconf values for packages that will be or are installed. Otherwise you can end up with values in the database for uninstalled packages that will not go away ... No word about first time install only. Some real-life packages simply behave differently to what is des- cribed in the man page, even though they are using debconf. This doesn't seem right. Regards Harri signature.asc Description: OpenPGP digital signature
Bug#761155: incompatible-java-bytecode-format
Package: openjpeg2 The java binding is build with java version 1.7, please use 1.5 for now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761156: extlinux: Recommends grub-pc on UEFI systems
Package: extlinux Version: 3:6.03~pre18+dfsg-1 Severity: normal I just upgraded extlinux on my jessie system and got a message about extlinux no longer shipping bootloader integration. It also recommended installing grub-pc, something which would be actively harmful on this system as it's using UEFI. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages extlinux depends on: ii libc6 2.19-10 Versions of packages extlinux recommends: ii os-prober1.64 ii syslinux-common 3:6.03~pre18+dfsg-1 extlinux suggests no packages. -- debconf information: extlinux/install: false -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761134: libsbml5-perl: Depends on libperl5.18 but should be libperl5.20 now
Hi, I think a package rebuild should be sufficient to close this bug. Thus I commited * rebuild with latest libperl Closes: #761134 to the changelog. Ivo, it is *really* high time to upload libsbml if we want to deliver it in Jessie. Do you have any idea why the current state of SVN does not build on other machines. Please communicate your problems or lets consult debian-mentors. We are really short in time before the freeze (2014-11-05). Kind regards Andreas. On Wed, Sep 10, 2014 at 03:27:28PM -0700, Steve Lane wrote: Package: libsbml5-perl Version: 5.8.0-2+b1 Severity: important Dear Maintainer, libperl5.18 is no longer available: root apt-show-versions -a libperl5.18 libperl5.18:amd64 5.18.2-7 install ok installed No stable version No testing version No unstable version libperl5.18:amd64 5.18.2-7 installed: No available version in archive but upgrading to 5.20 will uninstall libsbml5-perl because of the dependency. Thanks/best, -- Steve Lane System Administrator, Scientific Computing Joint BioEnergy Institute Lawrence Berkeley National Laboratory -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (990, 'stable'), (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libsbml5-perl depends on: ii libbz2-1.0 1.0.6-4 ii libc6 2.19-9 ii libgcc1 1:4.9.1-4 ii libperl5.18 5.18.2-7 ii libstdc++6 4.9.1-4 ii libxml2 2.8.0+dfsg1-7+wheezy1 ii perl5.18.2-7 ii perl-base [perlapi-5.18.2] 5.18.2-7 ii zlib1g 1:1.2.7.dfsg-13 libsbml5-perl recommends no packages. libsbml5-perl suggests no packages. -- no debconf information ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761079: debsources: support multiple archives
On Thu, Sep 11, 2014 at 2:55 PM, Stefano Zacchiroli wrote: Do you maybe already have code that does this (at list the first part, up to some sort of containerized apt-get update) as part of the census script? If so, mind posting to this bug report pointers to it? Once I move the derivs census off alioth and get deriv.debian.org setup properly, rsync will be: rsync --timeout=60 --contimeout=60 --prune-empty-dirs --filter 'merge, include-sources-lists' -a --no-perms --no-owner --no-group --chmod=a+rX,ug+w,o-w,Dg+s,Da+x deriv.debian.org::deriv/census/ ./ With include-sources-lists being a file like this: + */ + /var/*/sources.list - * Containerizing apt-get update simply needs pointing the APT_CONFIG environment variable at an appropriate apt configuration file. chdist from devscripts can do it and in addition I have such a setup in the derivs census scripts: https://anonscm.debian.org/cgit/dex/census.git/tree/Makefile#n6 https://anonscm.debian.org/cgit/dex/census.git/tree/etc/apt.conf https://anonscm.debian.org/cgit/dex/census.git/tree/bin/get-package-lists -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742487: Update of python-ldap to upstream version 2.4.15
retitle 742487 Update of python-ldap to upstream version 2.4.16 tag 742487 patch thanks Hello, On 10.09.2014 14:19, Michael Ströder wrote: Philipp Hahn wrote: The attached version contains my fix for that problem, which I sent upstream and which is already committed to the maintainers CVS repository: http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/ldapobject.py?r1=1.139r2=1.141 I prefer not having to bear in mind backport fixes in distri packages. Therefore I've release 2.4.16. I would appreciate if you would package that (after locally testing the release). Attached is 2.4.16. It survived our internal nightly test run for UCS. python-ldap_2.4.16-0.1.debian.tar.gz Description: application/gzip Format: 3.0 (quilt) Source: python-ldap Binary: python-ldap, python-ldap-dbg Architecture: any Version: 2.4.16-0.1 Maintainer: Matej Vela v...@debian.org Homepage: http://www.python-ldap.org/ Standards-Version: 3.9.3 Build-Depends: debhelper (= 8), python-all-dev (= 2.6.6-3~), python-all-dbg, libldap2-dev, libsasl2-dev Package-List: python-ldap deb python optional python-ldap-dbg deb debug extra Checksums-Sha1: e25e1edda67ced26a31e8b7a68eb003c039ba21a 137873 python-ldap_2.4.16.orig.tar.gz 3b0aef3825d7642aa62440f76b5738faecb03c79 6411 python-ldap_2.4.16-0.1.debian.tar.gz Checksums-Sha256: 524de8a99a2cf001e8d69b8e86b2bd4af18f6b9b3057bbd2ead2758ae5ac1443 137873 python-ldap_2.4.16.orig.tar.gz 253f6019e3c52a4bc0218d0fc920e2a37ff089ecca5fc33f16144625b0510fa0 6411 python-ldap_2.4.16-0.1.debian.tar.gz Files: 75549bad7eaaf4949f6adf80334f0acc 137873 python-ldap_2.4.16.orig.tar.gz 9f0b95975ce2c8ceb5058b4d84a42ab1 6411 python-ldap_2.4.16-0.1.debian.tar.gz
Bug#760712: WEP vs WPA2
Hi Chris! Chris Tillman toff.till...@gmail.com (2014-09-11): With this installation I was using WPA2-Personal at the access point. I see the log messages look similar as in bug #741622, deauthenticating immediately after connect. For a later install on the same computer, also to USB target, I used WEP in the installer to connect to the access point (installation report #761148). So possibly the problem has to do with WPA2 as opposed to WEP. That's an interesting data point, thank you! (That reminds me I haven't yet submitted an installation report… the wireless part wasn't OK either.) Mraw, KiBi. signature.asc Description: Digital signature
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
Petter Reinholdtsen p...@hungry.com (2014-09-11): [Cyril Brulebois] Of course a failing d-i build means src:debian-installer FTBFS. What else would that be? Thanks for asking. To me, it could also mean a failing to build a ISO with d-i udebs on it. But I had already tested ISO builds, and thus was a bit unsure what was failing for you. That might be some kind of language barrier issue as you mentioned, but when I write “d-i build”, it's really about building d-i. If I want to talk about a cd/dvd/iso build, I write “cd/dvd/iso build”. Please explain how you managed to build installation images with a failing d-i build. The ISO build system understand and handle the provides header, and the ISO build is working as before the deb was introduced, as can be seen on for example URL: http://lists.alioth.debian.org/pipermail/debian-edu-commits/2014-September/008537.html . ACK. I'm not sure why you're insisting on the renaming. Please explain why you did that (see my first follow-up). Somehow I get the impression that you do not really want to understand why I did this change but just want a set of arguments to brush off before reverting it, but I hope it is just a language barrier issue. Certainly a communication problem somwhere since I'm asking about the *renaming* part, and you're talking about the whole changeset. Anyway, here are the explanation why I introduced a archdetect deb and how the change have been tested so far. * A archdetect deb allow users on installed systems to figure out which kernel the installer want to install on a given machine. * The need for a normal deb for archdetect have been on the TODO list for years, see for example debian-installer/doc/TODO listing this entry in the Post-etch goals list: - real deb from archdetect udeb (luther) This is the part I'm talking about: ,--- | * The deb was already present in Ubuntu, under the name | archdetect-deb. Adding the deb in Debian can reduce the diff with | Ubuntu. | * We normally in Debian name udebs with a -udeb postfix, and name | packages after the binary they contain. Diverting from this common | naming scheme should be avoided. This I decided to use the | sensible name for the deb in Debian, and switch the udeb to have | the name we commonly use for udebs in debian, package-udeb. `--- * I knew d-i (anna-install and the rest of the d-i installation system) would handle the provides header, and tested this on a fresh install in a virtual machine before commiting the change. * I checked how many udebs were depending on archdetect (6, if I recall correctly), and new they would cope just fine with the change. * Knew the Debian archive would handle the rename, as udebs and debs have different name spaces, and we use the provides method with several library udebs already. So the change was tested and the installer was working as it should also after the rename. The only thing I didn't test was building the debian-installer source package itself, which broke as you correctly observed. The simple fix is to replace archdetect with archdetect-udeb, but a more proper fix is probably to teach the build of d-i initrds to understand the provides header, to ensure similar issues do not arise in the future. I disagree that reusing package names across package types is a nice thing to do. I very strongly disagree that it's OK to try that when we're close to the freeze (and not at the very beginning of the release cycle, where it hurts less to upload disruptive changes). As I already mentioned, you had been told in advance more stuff would have to be adjusted! Sticking to naming schemes is nice, but that certainly shouldn't be a reason for renaming packages and generating more work! You could look at the file you modified: | # These udebs will be needed on nearly every image. Include this file | # to get them. | busybox-udeb | anna | archdetect | cdebconf-udeb | cdebconf-priority | di-utils | di-utils-reboot | di-utils-shell | libdebconfclient0-udeb | libdebian-installer4-udeb | libnss-dns-udeb | lowmemcheck | main-menu | rootskel | udpkg | rescue-check | env-preseed | pciutils-udeb | | #include udev | | libkmod2-udeb [linux] | kldutils-udeb [kfreebsd] *-udeb really isn't mandatory in any way! So yes, I reverted these changes since renaming is unwarranted, already broke things, and might break others; I'm not interested in dealing with possible fallouts due to cosmetics. KiBi. signature.asc Description: Digital signature
Bug#755651: Fwd: [Horizon] Last remaining Django 1.7 issue in Horizon (and other OpenStack packages)
Hi,
Here's a message from the maintainer of python-django in Debian. We've
been trying to switch to Django 1.7, because we would like to benefits
from its security support for the life of Debian Jessie.
I have already fixed numerous Debian packages regarding Django 1.7
compatibility (for example: python-appconf,
python-django-openstack-auth, python-django-compressor,
python-django-pycss, tuskar-ui, many issues in Horizon, and more...).
This is (hopefully...) the very last remaining issue, so it'd be really
cool to get at least comments on it, so I can consider everything
solved. Input from the Horizon team would be great.
BTW, I'd like to publicly thanks Raphael for all the help he provided
investigating many of the Django 1.7 issues in OpenStack related
packages. He's been really great and supportive, plus warned soon enough
so we had time to fix everything together.
Cheers,
Thomas Goirand (zigo)
Original Message
Subject: [PKG-Openstack-devel] Bug#755651: [openstack-dev] [horizon]
Support for Django 1.7: there's a bit of work, though it looks fixable
to me...
Resent-Date: Wed, 10 Sep 2014 20:45:23 +
Resent-From: Raphael Hertzog hert...@debian.org
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: PKG OpenStack openstack-de...@lists.alioth.debian.org
Date: Wed, 10 Sep 2014 22:42:09 +0200
From: Raphael Hertzog hert...@debian.org
Reply-To: Tracking bugs and development for OpenStack
openstack-de...@lists.alioth.debian.org
To: Thomas Goirand z...@debian.org
CC: OpenStack Development Mailing List (not for usage questions)
openstack-...@lists.openstack.org, 755...@bugs.debian.org
[ I'm not subscribed to openstack-devel, please cc me ]
On Tue, 05 Aug 2014, Thomas Goirand wrote:
I'm now down to only a single error not solved:
==
FAIL: test_update_project_when_default_role_does_not_exist
(openstack_dashboard.dashboards.admin.projects.tests.UpdateProjectWorkflowTests)
--
Traceback (most recent call last):
File
/home/zigo/sources/openstack/icehouse/horizon/build-area/horizon-2014.1.1/openstack_dashboard/test/helpers.py,
line 83, in instance_stub_out
return fn(self, *args, **kwargs)
File
/home/zigo/sources/openstack/icehouse/horizon/build-area/horizon-2014.1.1/openstack_dashboard/dashboards/admin/projects/tests.py,
line 1458, in test_update_project_when_default_role_does_not_exist
self.client.get(url)
AssertionError: NotFound not raised
Any idea?
I looked further into this and in fact the exceptions is caught by the
template rendering code (IncludeNode.render() in
django/template/loader_tags.py while processing the include of
'horizon/common/_workflow.html' and to be more precise the processing of
'{% if step.has_required_fields %}' is the exact place where the exception
is fired). I can get the test to pass by changing the Django setting
TEMPLATE_DEBUG to True.
Django 1.6 has a slightly different code here and doesn't intercept
it (I'm not sure why, but I did two parallel step by step execution
with pdb to verify this).
But such a setting is not appropriate for production usage and somehow I
expect horizon to rely on the fact that the exception can be caught in
some upper level. So I'm not quite sure what to suggest here.
The expected behaviour is not clear to me and relying on exception
propagation from code executed indirectly in template rendering seems
bad design from the start.
That said the consequences of this failing test is just that we get a
page without any useful content instead of an internal server error.
Not sure that it matters much either...
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
___
Openstack-devel mailing list
openstack-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/openstack-devel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760874: openjpeg2
Control: reassign -1 src:openjpeg2 Control: affects -1 src:openjpeg openjpeg2 should superseed openjpeg at some point, but breaks the old 1.x API. I need to check what is the best course of actions to: 1. Provide the full tools from openjpeg2 2. Do not conflict with openjpeg 1.x (the main API in use still) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697682: libapache2-mod-perl2: Intermittent FTBFS: t/apache/read3.t failure
On 5 September 2014 20:06, Niko Tyni nt...@debian.org wrote: On Wed, Aug 13, 2014 at 11:47:58AM +0300, Niko Tyni wrote: On Wed, Aug 13, 2014 at 09:12:11AM +0100, Steve Hay wrote: Thanks for the patch. I haven't seen this failure myself on Windows, but the patch certainly doesn't seem to break anything. I'm a little uneasy about it, though. It seems odd to structure read3.pm differently to read2.pm and read4.pm, which still have a plan emitted before the first read(). Why does read3.pm deadlock but read2.pm and read4.pm don't? If it's just luck then perhaps read2.pm and read4.pm should be changed similarly? It only happens with read3 because the POSTed string in that test is very much larger than the other ones. LWP::Protocol::http sends the whole POST request in one write() unless it's over eight kilobytes long (see lib/LWP/Protocol/http.pm in libwww-perl_6.08 line 276.) I've updated the attached patch to change read2 too. read4 is quite different though, as it reads just a few bytes at a time, so I think it's OK to leave it as is. Maybe a comment in the code would be good too, since the structure of most test files is to get the plan out early. Otherwise there is scope for re-introducing the bug in the future since it isn't obvious that the placement of the plan is important. Done as well. Thanks, applied in revision 1624218. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761105: debsources: on the fly package diff / debdiff
On Thu, Sep 11, 2014 at 2:58 PM, Stefano Zacchiroli wrote: We're gonna need it on debsources anyhow, in particular to implement the edit feature suggested by Raphael Geissert. What we could do is to factorize as much as possible the common parts in a common place, e.g., python-debian. But I'm not sure there is actually that *much* code to write, considering that 1) we will probably invoke the real debdiff as an external program anyhow and 2) I plan to delegate diff highlighting to the javascript toolkit we already use. I see, some factors I can think of: Some derivatives support tarball compression schemes that Debian does not (rejected by the dpkg maintainer). The derivatives census converts to gzip with low compression and does debdiff on the result. Ancient Debian source packages had no dsc files, debdiffing would require constructing fake ones I guess. debdiff of libreoffice versions needs adequate space in $TMP which usually isn't available when /tmp is a tmpfs. Would be great to move that into python-debian. What else is there to be done? Mainly having a full set of packages to debdiff between, from our discussions at DebConf14 it seems like you plan to get a copy of the snapshot archive anyway so maybe sources.d.n is indeed the right place to do this? -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
[Cyril Brulebois] I disagree that reusing package names across package types is a nice thing to do. I very strongly disagree that it's OK to try that when we're close to the freeze (and not at the very beginning of the release cycle, where it hurts less to upload disruptive changes). Given that udebs and debs have different name spaces, I do not see any problem myself with dropping a name from one namespace and introducing it in another, which is what I did when I renamed archdetect to archdetect-udeb in the udeb namespace and introduced the archdetect name into the deb namespace. The freeze is two months away. I understand you see the freeze as very close, while I see it as a bit further away. I fully respect your view about the urgenzy, even if I do not quite share it. I believe fixing the d-i build could have been done this week (for example by uploading a new debian-installer package without the kernel change), and was prepared to get any required fixes in place as soon as possible. As I already mentioned, you had been told in advance more stuff would have to be adjusted! I noticed you mentioned IRC messages I hadn't seen before you mentioned them here in the mail, so I guess they were said while I was away from IRC. I had tested the change, but simply forgot to check the debian-installer initrd build. I am still sorry about this. Sticking to naming schemes is nice, but that certainly shouldn't be a reason for renaming packages and generating more work! You could look at the file you modified: [...] *-udeb really isn't mandatory in any way! Sure, but it is used when there is a deb and an udeb. The common naming then is package for the deb name space and package-udeb for the udeb namespace. I did not check them all, but as far as I can tell, the examples without the '-udeb' ending do not have a package in the deb namespace. So yes, I reverted these changes since renaming is unwarranted, already broke things, and might break others; I'm not interested in dealing with possible fallouts due to cosmetics. My approach would have been to fix the remaining issues and keep the archdetect and archdetect-udeb names, but I'm not starting competing for commits uploads over this and will try to find time for the fix after Jessie instead. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760604: Dovecot ssl config
How did you configure dovecot in debconf (debconf-show dovecot-core)? * dovecot-core/create-ssl-cert: false dovecot-core/ssl-cert-exists: * dovecot-core/ssl-cert-name: localhost Seeems to be that #760653 is the actual reason for this issue. With dovecot-core 2.2.13-5 the problem is gone. Wolfgang signature.asc Description: Digital signature
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
Petter Reinholdtsen p...@hungry.com (2014-09-11): Given that udebs and debs have different name spaces, I do not see any problem myself with dropping a name from one namespace and introducing it in another, which is what I did when I renamed archdetect to archdetect-udeb in the udeb namespace and introduced the archdetect name into the deb namespace. Re-using package names has always been a pain, for users, for packages depending on them, for bug tracking purposes, for bisecting purposes (downloading older snapshots in an automated way, testing them), etc. This should be avoided. Always. Consistency with a naming scheme is not a reason good enough to outweigh the costs mentioned above. The freeze is two months away. I understand you see the freeze as very close, while I see it as a bit further away. I fully respect your view about the urgenzy, even if I do not quite share it. I believe fixing the d-i build could have been done this week (for example by uploading a new debian-installer package without the kernel change), and was prepared to get any required fixes in place as soon as possible. First thing first: I upload debian-installer only when it is needed, meaning we're targetting a release. Secondly, since the udeb change didn't reach testing, no, it wouldn't have worked. I know two months is a lot, somewhat. But there are many more important things to track already! So losing time, focus, and energy over such disruptive and avoidable changes is really not appreciated. As I already mentioned, you had been told in advance more stuff would have to be adjusted! I noticed you mentioned IRC messages I hadn't seen before you mentioned them here in the mail, so I guess they were said while I was away from IRC. No, you were in the middle of a conversation with Colin. I'm not going to copy/paste it because that'd be impolite, but you'll find it in your logs, 2014-09-09, around 10 UTC. Sticking to naming schemes is nice, but that certainly shouldn't be a reason for renaming packages and generating more work! You could look at the file you modified: [...] *-udeb really isn't mandatory in any way! Sure, but it is used when there is a deb and an udeb. The common naming then is package for the deb name space and package-udeb for the udeb namespace. I did not check them all, but as far as I can tell, the examples without the '-udeb' ending do not have a package in the deb namespace. That doesn't mean we have to enforce it. I'm pretty sure that someone 1. wanting to use archdetect 2. doing apt-get install archdetect can either press tab to try autocompletion, or use apt-cache search archdetect to discover the archdetect-deb package (if we ended up stealing this name from Ubuntu). So yes, I reverted these changes since renaming is unwarranted, already broke things, and might break others; I'm not interested in dealing with possible fallouts due to cosmetics. My approach would have been to fix the remaining issues and keep the archdetect and archdetect-udeb names, but I'm not starting competing for commits uploads over this and will try to find time for the fix after Jessie instead. Thanks. Mraw, KiBi. signature.asc Description: Digital signature
Bug#761157: grep -P is very slow on binary files
Package: grep Version: 2.20-3 Severity: important Between grep 2.18-2 and grep 2.20-3 (fixing bug 758105), there is a huge slowdown when binary files (with invalid UTF-8 sequences) are involved. The timings on my personal svn working copy (with all my files), when searching for a word that doesn't exist (no matches): grep 2.18-2: 0.9 s grep 2.20-3: 11.6 s Note: the -P is useless in this case, but it is useful in other cases. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-1-amd64 (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grep depends on: ii dpkg 1.17.13 ii install-info 5.2.0.dfsg.1-4 ii libc6 2.19-10 ii libpcre3 1:8.35-3 grep recommends no packages. grep 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#758105: bug#18266: grep -P and invalid exits with error
On 2014-09-10 13:22:36 +0200, Santiago wrote: Thanks! I'm including this fix in the current debian package. Unfortunately, it is very slow, with a large slowdown factor. I've just reported a new Debian concerning the performance problem. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://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#761158: ITP: kvmcs -- kvm in client/server environment
Package: wnpp Severity: wishlist Owner: willem kuyn willemk...@gmail.com * Package name: kvmcs Version : 0.4.5 Upstream Author : Willem Kuyn willemk...@gmail.com * URL : http://gitorious.org/kvmcs/kvmcs * License : GPL3+ Programming Lang: Perl Description : kvm in client/server environment KVMCS (Kernel Virtual Machine in Client Server environment) The KVMCS environment is ment for an education environment and is developed for an internet cafe for senior citizens. In this internet cafe they give courses and instructions on different operating systems. A lot of different operating systems had to be available at the same time and the power of the (old) computer systems were not sufficient for that purpose. A client server environment is developed where the processing is done on a server and the displays are situated on (thin) clients. A user can select an operating system by logging in with the operatingsystemname (pe xp) and gets the desktop of this os on his screen. After closing down all changes are deleted. The environment is designed for an arbitrary number of clients and os'es. Limitations are server processing power and network bandwidth. I am the upstream developer and the package is used on 3 locations (3 servers and 14 clients). A package in debian will improve the quality and installation from the standard repositories is much easier. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761159: squid3: pam_auth does not work - needs setuid/setgid
Source: squid3 Version: 3.1.20-2.2+deb7u2 Severity: normal Dear Maintainer, I have noticed that after recent security update of squid3, pam_auth stopped working. Users are authenticated with basic auth, but even if they supply the right credentials, they sill get: Cache Access Denied. I have tracked the problem to /usr/lib/squid3/pam_auth, which used to have setuid bit, but does not have it any more. Setting the file to proxy:shadow 2750, or root:proxy 4750 solved the problem. I'm not sure which of the two is preferred. Simple test is to run /usr/lib/squid3/pam_auth from command line and enter name password. If run as root, OK is returned, if run as normal user you get ERR, unless you have the proper setgid or setuid bits. This applies to wheezy as well as squeeze-lts. Should I file a separate bug for squeeze-lts? -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'squeeze-lts'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/8 CPU cores) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753001: openmpi: New upstream version 1.8 available
Version 1.8.2 is out, which brings a good list of bug fixes. http://www.open-mpi.org/community/lists/announce/2014/08/0063.php In the changelog, this line : - Close many memory leaks to achieve valgrind-clean operation suggests bug #732160 may be addressed. How large an effort would it be to update openmpi from the 1.6 to the 1.8 series ? Ghis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761131: [Pkg-libvirt-maintainers] Bug#761131: even simplest install and purge leaves junk behind
# find /var/lib/libvirt/qemu /var/cache/libvirt/qemu /var/lib/libvirt/qemu /var/lib/libvirt/qemu/capabilities.monitor.sock /var/lib/libvirt/qemu/save /var/lib/libvirt/qemu/snapshot /var/lib/libvirt/qemu/dump /var/cache/libvirt/qemu /var/cache/libvirt/qemu/capabilities /var/cache/libvirt/qemu/capabilities/2d1567fa77de202a8d45125ec58eadc9538916e0d21b9ecbc092de24d27ecf9c.xml /var/cache/libvirt/qemu/capabilities/f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml /var/cache/libvirt/qemu/capabilities/926803a9278e445ec919c2b6cbd8c1c449c75b26dcb1686b774314180376c725.xml -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761128: transition: oce
Hi, On 2014-09-10 22:45, D. Barbier wrote: I would like to upload oce 0.16 into unstable, it is currently in experimental. This source package provides several development libraries, their soname version have been bumped. The window for new transitions closed on 5th September, so this will have to be deferred until after Jessie's release. Please remind us then. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 directhex i have six years of solaris sysadmin experience, from 8-10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755303: Debian bug #755303
Hello Luca, hello Michael, I ask before more then 2 weeks about the status of the adoption from remmia. So I want to adopt this package too. CU Jörg -- pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8 EBCB 422B 44B0 BE58 1B6E pgp Key: BE581B6E CAcert Key S/N: 0E:D4:56 Jörg Frings-Fürst D-54526 Niederkail Threema: SYR8SJXB IRC: j_...@freenode.net j_...@oftc.net signature.asc Description: This is a digitally signed message part
Bug#761160: git-buildpackage: gbp pq: multiple user interface issues
Package: git-buildpackage Version: 0.6.19 Severity: wishlist I would like to see the following changes in the behaviour of gbp pq: 1/ gbp pq export should automatically drop the temporary patch-queue branch Rationale: if other people do changes do the quilt series, my patch queue branch will be stale and this will force me to drop it manually and re-import it. Worst case: I don't notice it and I drop the work of others. 2/ gbp pq switch should automatically call gbp pq import if there is a pre-existing debian/patches/series. If I want to start a new empty patch queue branch, it should be a dedicated command (and it could be used here for the case where debian/patches/series doesn't exist). Thank you for considering! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages git-buildpackage depends on: ii devscripts2.14.6 ii git 1:2.1.0-1 ii man-db2.6.7.1-1 ii python2.7.8-1 ii python-dateutil 1.5+dfsg-1 ii python-pkg-resources 5.5.1-1 Versions of packages git-buildpackage recommends: ii cowbuilder0.73 ii pristine-tar 1.32 Versions of packages git-buildpackage suggests: ii python-notify 0.1.1-3 ii unzip 6.0-12 -- 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#761115: [Pkg-salt-team] Bug#761115: salt: new upstream version 2014.7
Hi, On Thu, 2014-09-11 at 09:28 +1000, Joe Healy wrote: 2014.7 is still only in release candidate stage. A new release candidate is expected shortly. Oh, I see. Do you know why there's already a tag for v2014.7? That's what led me to believe it was already stable. Additionally, I'm not rushing to upload 2014.7 yet - it took 2014.1 about 9 or 10 point releases to stabilize. What do you mean with stabilize? Did the point releases introduce such big changes or fix real show-stopper bugs? Otherwise it would IMHO still be interesting to have 2014.7 in debian (but that's of course not my call). Separately, a new release for 2014.1 (2014.1.11) is almost ready for release. I'll be uploading it as soon as I can. Cool! Thanks for the work and the heads-up! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761138: closed by Paul Wise p...@debian.org (Re: Bug#761138: pagetrail misleading)
B Added the suggested prefix, thanks for the usability tip. Where did you add it? I still see Debian Wiki FrontPage debconfandroid-sdkKVMPaulWiseFrontPage -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761161: git-buildpackage: gbp pq import+export should preserve patch filenames
Package: git-buildpackage Version: 0.6.19 Severity: wishlist When importing patches from debian/patches/series, gbp pq import should inject a Gbp-Patch-Name field in the commit log and use that during gbp pq export to preserve the filename. This could nicely obsolete the topic feature since that field could contain subdirectories like topic1/fix-foobar.patch. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages git-buildpackage depends on: ii devscripts2.14.6 ii git 1:2.1.0-1 ii man-db2.6.7.1-1 ii python2.7.8-1 ii python-dateutil 1.5+dfsg-1 ii python-pkg-resources 5.5.1-1 Versions of packages git-buildpackage recommends: ii cowbuilder0.73 ii pristine-tar 1.32 Versions of packages git-buildpackage suggests: ii python-notify 0.1.1-3 ii unzip 6.0-12 -- 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#760769: subsurface: can't be installed due to missing libmarblewidget18
On 07/09/2014 19:39, Christoph Anton Mitterer wrote: Package: subsurface Version: 4.2-1.1 Severity: grave Justification: renders package unusable libmarblewidget18 is no longer in sid, and therefore the package can't be installed. yes, it seems that the libmarblewidget18 transition could have been managed better ... Please rebuild,... and also please move to unstable. I see no reason to have it in experimental only. Well, we had a reason. Subsurface 4.2 requires libgit2 and it was only available in experimental until last week. Cheers, Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753001: openmpi: New upstream version 1.8 available
On 11/09/2014 10:45, Ghislain Vaillant wrote: Version 1.8.2 is out, which brings a good list of bug fixes. http://www.open-mpi.org/community/lists/announce/2014/08/0063.php Yeh, professionally, I left the scientific world for Mozilla. So, my interest for scientific packages decreased. Sorry about that. In the changelog, this line : - Close many memory leaks to achieve valgrind-clean operation suggests bug #732160 may be addressed. How large an effort would it be to update openmpi from the 1.6 to the 1.8 series ? Usually, upstream is great to keep our work easy. However, it is likely that this version of OpenMPI requires an SO bump (and therefor requires a transition). Such transition is going to be important to be done before Jessie. However, we could prepare everything in experimental. If you are interested, I would be happy to sponsor such work. Cheers, Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761105: debsources: on the fly package diff / debdiff
On Thu, Sep 11, 2014 at 03:48:38PM +0800, Paul Wise wrote: On Thu, Sep 11, 2014 at 2:58 PM, Stefano Zacchiroli wrote: We're gonna need it on debsources anyhow, in particular to implement the edit feature suggested by Raphael Geissert. What we could do is to factorize as much as possible the common parts in a common place, e.g., python-debian. But I'm not sure there is actually that *much* code to write, considering that 1) we will probably invoke the real debdiff as an external program anyhow and 2) I plan to delegate diff highlighting to the javascript toolkit we already use. I see, some factors I can think of: So, from your examples I've realized that I've mentioned debdiff, but I actually don't need it. Debsources currently have unpacked packages on the filesystem, organized in per-version directories. So Debsources can simply recursively diff the two directories, instead of using debdiff (which AFAICT, doesn't even work on directories). We'll just need to look into whether debdiff uses specific diff options that we want to use as well, just to ensure that the output format is more or less the same. (FWIW, this seems to be yet another good argument against some hash-based file-layout, that we have been discussing in #761117.) Most of the legitimate problems you've mentioned seems to be related to source package format and, arguably, we won't have those problems with Debsources, or at least not in the diffing part. (We will have them at source package unpack time, of course.) What else is there to be done? Mainly having a full set of packages to debdiff between, from our discussions at DebConf14 it seems like you plan to get a copy of the snapshot archive anyway so maybe sources.d.n is indeed the right place to do this? That's the plan yes, even though importing snapshot.d.o is a very different feature/goal. However, it is important to observe that sources.d.n still aims at being source-package-only, whereas 1) debdiff is capable of diffing .deb and 2) .debs are indeed available on snapshot.d.o. So if you are interested in diffing .debs, as of now the only place where to implement that specific feature is snapshot.d.o. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#761146: ITP: casacore-data -- Data for Common Astronomy Software Applications core library
Hi Benda, I assume you will maintain this package in the Debian Astro team. Since I have not seen this ITP on their list I'm hereby forwarding it to let your team members know. It is generally a good idea to add the list in the initial bug report. Thanks for your work on this package Andreas. On Thu, Sep 11, 2014 at 02:13:13PM +0900, Benda Xu wrote: Package: wnpp Severity: wishlist Owner: Benda Xu hero...@gentoo.org * Package name: casacore-data Version : 0 Upstream Author : Australia Telescope National Facility * URL : https://code.google.com/p/casacore * License : LGPL Programming Lang: none Description : Data for Common Astronomy Software Applications core library This package contains data from Australia Telescope National Facility to be used by Common Astronomy Software Applications core library at runtime and test. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140911051313.5112.11885.reportbug@localhost -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758839: contains non-free data
On 10-09-14 19:02, Stas wrote: I guess so, once you have your new release ready I'll try to upload an updated package that closes this bug as soon as work and real childs permit... :) Ok, I will make a new package tomorrow morning and post the link when ready. Here's the new 2.6.5 release with a sound file which now belongs to me :-) http://download.savannah.gnu.org/releases/childsplay/ Thanks for your fast replies and happy to see that e-mail missunderstandings have been solved. Greetings, Sergio -- Sergio Talens-Oliag s...@debian.org http://people.debian.org/~sto/ Key fingerprint = FA90 8E47 1AD3 7D7F 2363 D78F 821A EE0F D167 FBDF -- To unsubscribe, send mail to 758839-unsubscr...@bugs.debian.org. Regards, Stas Zytkiewicz -- Regards, Stas Zytkiewicz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752900: ITP: appstream-glib -- Library for AppStream metadata access
Hello! Any progress on this so far? Do you have any outlook for the future? It feels like it's getting tight now for getting it into Jessie. What are your plans? Having this packaged is a blocker for updating other packages in Debian. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750557: pgadmin3: segmentation fault
Hi guys, I've just uploaded 1.20.0~beta1 to unstable. Could you check if you still see the pgadmin3 crashes there? It seems to work for me now. Packages on apt.postgresql.org should be available shortly in the *-pgdg-testing suites. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#761138: closed by Paul Wise p...@debian.org (Re: Bug#761138: pagetrail misleading)
On Thu, Sep 11, 2014 at 4:52 PM, 積丹尼 Dan Jacobson wrote: B Added the suggested prefix, thanks for the usability tip. Where did you add it? I still see Sounds like you need to reload, I see this: Wiki/ Recently viewed pages: Derivatives/Integration/how-can-i-help/how-can-i-help/Ideas/Reproducible Builds/Paul Wise -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761105: debsources: on the fly package diff / debdiff
On Thu, 2014-09-11 at 11:13 +0200, Stefano Zacchiroli wrote: We'll just need to look into whether debdiff uses specific diff options that we want to use as well, just to ensure that the output format is more or less the same. One thing debdiff helps with is not having quilt cruft in the diff. Most of the legitimate problems you've mentioned seems to be related to source package format and, arguably, we won't have those problems with Debsources, or at least not in the diffing part. (We will have them at source package unpack time, of course.) Right. However, it is important to observe that sources.d.n still aims at being source-package-only, whereas 1) debdiff is capable of diffing .deb and 2) .debs are indeed available on snapshot.d.o. So if you are interested in diffing .debs, as of now the only place where to implement that specific feature is snapshot.d.o. The debdiff idea was only for sources and mainly in conjunction with derivs census patch stuff. On the binaries stuff, various folks have been asking about a binaries.d.o, similar to sources.d.n but for binaries. The debdiff output for binaries is useful for some use-cases but we might also want more comprehensive diffs for binaries, diffp from the reproducible builds stuff comes to mind as a potential script to add. https://wiki.debian.org/ReproducibleBuilds#bash_script_to_compare_two_package_builds -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#761061: tracker doesnt show closed issues as done
Hi, On Mittwoch, 10. September 2014, Moritz Muehlenhoff wrote: It's only that noone has come around to change this. But since you now have experience with the code base... :-) grummel, this seems to be true ;) from what I've said on irc just now: * | h01ger is happy to report that he has patched the security tracker so it eg shows whats fixed through lts uploads in the file package whats funny though is, that it still doesnt know about wheezy-security just lts :) havent digged into the cause anymore last night, but the source_packages table doesn't seem hold the wheezy-security packages, yet the tracker knows which DSA was fixed in which version. I'll now do some other stuff and later continue with this... (oh, and it now just shows squeeze and squeeze-lts, as it would show wheezy and wheezy-security if that were in source_packages... I'm tempted to debug this now, but really need to do other stuff first :) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#755459: RFS: lucene/4.9.0-1 [put in ITP, ITA, RC, NMU if applicable]
added the classpath. thanks On Wed, Sep 3, 2014 at 10:57 PM, Игорь Пашев pashev.i...@gmail.com wrote: You may need to build it with export CLASSPATH=/usr/share/java/ivy.jar in debian/rules And I saw ivy tends to fetch some files from the net 2014-07-23 0:51 GMT+04:00 Hilko Bengen ben...@debian.org: * Raaj S: I am looking for a sponsor for my package lucene * Package name: lucene Version : 4.9.0-1 lucene4_4.6-1 (one of the many build-dependencies for elasticsearch) has been packaged and waiting for ftp-master approval in NEW for about a month now. Cheers, -Hilko -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbqpf777@msgid.hilluzination.de
Bug#746505: [Pkg-lirc-maint] Bug#746505: fix FTBFS on new architectures
* Stefan Lippers-Hollmann (s@gmx.de) [140911 00:47]: Ideally I can get the new version into shape until the end of the weekend, but feel free to push a porter-NMU as needed. The patch attached to this bug should work and there's no need to bother about the pending new version (it's fixed there already in an equivalent way) or a formal NMU-diff. I'll take care to acknowledge the NMU and not to conflict with the testing migration then. Thanks, Uploaded. Regards, Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760350: Bug#750557: pgadmin3: segmentation fault
On Thursday 11 September 2014 11:31:44 Christoph Berg wrote: Hi guys, I've just uploaded 1.20.0~beta1 to unstable. Could you check if you still see the pgadmin3 crashes there? It seems to work for me now. Packages on apt.postgresql.org should be available shortly in the *-pgdg-testing suites. Christoph Hi, updated and tested, but no joy ;-(. Check http://paste.kde.org/pnrcj16nt BogDan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761162: clamav-unofficial-sigs: Cron job results spread onto mail and logs
Package: clamav-unofficial-sigs Version: 3.7.1-3 Severity: normal Dear Maintainer, this bug is different from bug #704656, albeit similar: The issue here is the output of curl not redirected, rather than the output of clamscan not being redirected. I frequently receive mail to clamav@`hostname` from the Cron Daemon, saying curl: (28) connect() timed out!, one or more times. Perhaps, that recipient address should be configurable. Looking at the log file, I find corresponding lines: Sep 11 02:52:07 WARNING - Failed curl connection to clamav.securiteinfo.com - SKIPPED SecuriteInfo securiteinfodos.hdb update Sep 11 02:52:22 WARNING - Failed curl connection to clamav.securiteinfo.com - SKIPPED SecuriteInfo securiteinfoelf.hdb update Sep 11 02:52:37 WARNING - Failed curl connection to clamav.securiteinfo.com - SKIPPED SecuriteInfo securiteinfo.hdb update The above results from standard package installation. The missing info is how severe those warnings are. When have those files been last updated? Note that there are other files downloaded from the same host. So connect() fails intermittently. The page at http://sanesecurity.com/donate/ says one can get a better url by paying for the service. However, shell variable si_url is hardcoded in clamav-unofficial- sigs.sh. Perhaps, making it configurable may encourage donations. In fact, it is not clear whether that host is managed by Sanesecurity or SecuriteInfo. Thank you Ale -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.51ale22 (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/bash Versions of packages clamav-unofficial-sigs depends on: ii bind9-host [host] 1:9.8.4.dfsg.P1-6+nmu2+deb7u1 ii clamav 0.98.4+dfsg-0+deb7u2 ii curl 7.26.0-1+wheezy9 ii dnsutils 1:9.8.4.dfsg.P1-6+nmu2+deb7u1 ii gnupg 1.4.12-7+deb7u4 ii rsync 3.0.9-4 clamav-unofficial-sigs recommends no packages. Versions of packages clamav-unofficial-sigs suggests: pn clamav-daemon 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#760904: installation-reports: no network on linkstation pro with jessie d-i
On Wed, 2014-09-10 at 14:14 -0700, Ryan Tandy wrote: On 10/09/14 10:28 AM, Ian Campbell wrote: In the meantime if you could collect the lsmod with a Wheezy kernel for comparison we can check if there is anything else there which ought to be exposed to the installer. Attaching dmesg and report-hw from wheezy and jessie for completeness. Thanks. The new networking related bits seem to be marvell.ko and mvmdio.ko. marvell.ko was already packaged in the right place and I added mvmdio.ko yesterday. I remain hopeful that will have solved your issue. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761138: closed by Paul Wise p...@debian.org (Re: Bug#761138: pagetrail misleading)
Nope. Not showing up. Even logged in with a different browser. Debian Wiki HelpContents PaulWiseRecentChangesHelpContents Anyway yours says Wiki/ mine says Debian Wiki. PW == Paul Wise p...@debian.org writes: PW On Thu, Sep 11, 2014 at 4:52 PM, 積丹尼 Dan Jacobson wrote: B Added the suggested prefix, thanks for the usability tip. Where did you add it? I still see PW Sounds like you need to reload, I see this: PW Wiki/ PW Recently viewed pages: PW Derivatives/Integration/how-can-i-help/how-can-i-help/Ideas/Reproducible PW Builds/Paul Wise
Bug#761164: libpoppler-qt4-4: leaks private symbols into the public ABI
Source: libpoppler-qt4-4 Version: 0.26.4-1 Severity: wishlist Usertags: symbols I am rebuilding poppler for wheezy-backports. My normal build process includes DPKG_GENSYMBOLS_CHECK_LEVEL=4 and as a result I got a build failure (see below) due to new symbols being introduced. Based on the name these are clearly private symbols that should not be exported in the public ABI, please set the default symbol visibility to hidden. debian/rules override_dh_makeshlibs make[1]: Entering directory `/tmp/buildd/poppler-0.26.4' cat debian/libpoppler-glib8.symbols.in | sed -e 's/#CURVER#/0.26.4/g' debian/libpoppler-glib8.symbols cat debian/libpoppler-qt4-4.symbols.in | sed -e 's/#CURVER#/0.26.4/g' debian/libpoppler-qt4-4.symbols cat debian/libpoppler-qt5-1.symbols.in | sed -e 's/#CURVER#/0.26.4/g' debian/libpoppler-qt5-1.symbols dh_makeshlibs -plibpoppler46 -V dh_makeshlibs -plibpoppler-cpp0 -Vlibpoppler-cpp0 (= 0.16) dh_makeshlibs --remaining-packages dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libpoppler-qt4-4/DEBIAN/symbols doesn't match completely debian/libpoppler-qt4-4.symbols --- debian/libpoppler-qt4-4.symbols (libpoppler-qt4-4_0.26.4-1~bpo70+1_amd64) +++ dpkg-gensymbolsGOHqyF 2014-09-08 02:11:57.304205915 + @@ -7,6 +7,10 @@ _ZN7Poppler10Annotation19setModificationDateERK9QDateTime@Base 0.20.1 _ZN7Poppler10Annotation5Popup10setSummaryERK7QString@Base 0.20.1 _ZN7Poppler10Annotation5Popup11setGeometryERK6QRectF@Base 0.20.1 + _ZN7Poppler10Annotation5Popup7PrivateC1ERKS2_@Base 0.26.4-1~bpo70+1 + _ZN7Poppler10Annotation5Popup7PrivateC2ERKS2_@Base 0.26.4-1~bpo70+1 + _ZN7Poppler10Annotation5Popup7PrivateD1Ev@Base 0.26.4-1~bpo70+1 + _ZN7Poppler10Annotation5Popup7PrivateD2Ev@Base 0.26.4-1~bpo70+1 _ZN7Poppler10Annotation5Popup7setTextERK7QString@Base 0.20.1 _ZN7Poppler10Annotation5Popup8setFlagsEi@Base 0.20.1 _ZN7Poppler10Annotation5Popup8setTitleERK7QString@Base 0.20.1 dh_makeshlibs: dpkg-gensymbols -plibpoppler-qt4-4 -Idebian/libpoppler-qt4-4.symbols -Pdebian/libpoppler-qt4-4 -edebian/libpoppler-qt4-4/usr/lib/x86_64-linux-gnu/libpoppler-qt4.so.4.4.0 returned exit code 2 $ c++filt + _ZN7Poppler10Annotation5Popup7PrivateC1ERKS2_@Base 0.26.4-1~bpo70+1 + _ZN7Poppler10Annotation5Popup7PrivateC2ERKS2_@Base 0.26.4-1~bpo70+1 + _ZN7Poppler10Annotation5Popup7PrivateD1Ev@Base 0.26.4-1~bpo70+1 + _ZN7Poppler10Annotation5Popup7PrivateD2Ev@Base 0.26.4-1~bpo70+1 + Poppler::Annotation::Popup::Private::Private(Poppler::Annotation::Popup::Private const)@Base 0.26.4-1~bpo70+1 + Poppler::Annotation::Popup::Private::Private(Poppler::Annotation::Popup::Private const)@Base 0.26.4-1~bpo70+1 + Poppler::Annotation::Popup::Private::~Private()@Base 0.26.4-1~bpo70+1 + Poppler::Annotation::Popup::Private::~Private()@Base 0.26.4-1~bpo70+1 -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#761163: libgl1-mesa-dri: DRI3 causes error messages on i915 driver
Package: libgl1-mesa-dri Version: 10.3.0~rc3-1 Severity: minor Any application using libGL will report the following errors to stderr: libGL error: Version 4 or later of flush extension not found libGL error: failed to load driver: i915 The reason is that the i915 driver does not support DRI3 (yet?) as per upstream bug report: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=81601 See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754297 (Ealier version of this bug, which caused crashes) The best fix would of course be to add version 4 flush extension to the i915 driver. But if this isn't easily possible, there should be some flag indicating that this driver is not DRI3 compatible, and DRI3 should then be disabled without an error (that sounds as if OpenGL does not work at all). Maybe DRI3 is only supported for 2D on this graphics board? After all the log reports: intel(0): direct rendering: DRI2 DRI3 enabled But the mesa libGL will fail at DRI3. Setting LIBGL_DRI3_DISABLE=1 makes the error message disappear. -- Package-specific info: glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync GLX version: 1.4 GLX extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) IGD x86/MMX/SSE2 OpenGL version string: 2.1 Mesa 10.3.0-rc3 OpenGL shading language version string: 1.20 OpenGL extensions: GL_3DFX_texture_compression_FXT1, GL_AMD_shader_trinary_minmax, GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, GL_APPLE_object_purgeable, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_ES2_compatibility, GL_ARB_clear_buffer_object, GL_ARB_compressed_texture_pixel_storage, GL_ARB_copy_buffer, GL_ARB_debug_output, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, GL_ARB_explicit_uniform_location, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_framebuffer_object, GL_ARB_get_program_binary, GL_ARB_half_float_pixel, GL_ARB_internalformat_query, GL_ARB_invalidate_subdata, GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, GL_ARB_robustness, GL_ARB_sampler_objects, GL_ARB_separate_shader_objects, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_sync, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
Bug#761165: vlc: segmentation fault with VDPAU
Package: vlc Version: 2.2.0~pre2-4+b1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Playing a DVD in a local optical drive. * What exactly did you do (or not do) that was effective (or ineffective)? Removing the vdpau libraries worked. * What was the outcome of this action? With the vdpau r600 library installed, had this result: libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_03_0.VOB at 0x00015c65 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_03_1.VOB at 0x00015cb2 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_04_0.VOB at 0x0009204d libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_04_1.VOB at 0x0009209a libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_05_0.VOB at 0x000b7b82 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_05_1.VOB at 0x000b7bcf libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_06_0.VOB at 0x000c9a6a libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_06_1.VOB at 0x000c9ab7 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_07_0.VOB at 0x000d8d28 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_07_1.VOB at 0x000d8d75 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_08_0.VOB at 0x000dc3df libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_08_1.VOB at 0x000dc42c libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_09_0.VOB at 0x000df9af libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_09_1.VOB at 0x000df9fc libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_10_0.VOB at 0x000e8487 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_10_1.VOB at 0x000e84d4 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_11_0.VOB at 0x000ed95d libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_11_1.VOB at 0x000ed9aa libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_12_0.VOB at 0x000f6577 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_12_1.VOB at 0x000f65c4 libdvdread: Elapsed time 0 libdvdread: Found 12 VTS's libdvdread: Elapsed time 0 [New Thread 0x7fffe8e24700 (LWP 4196)] [7fffd40009b8] core input error: ES_OUT_RESET_PCR called [New Thread 0x7fffe9026700 (LWP 4197)] [New Thread 0x7fffe9127700 (LWP 4199)] [New Thread 0x7fffc832d700 (LWP 4202)] [New Thread 0x7fffc6c79700 (LWP 4209)] [7fffd81699f8] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding. [mpeg2video @ 0x7fffd8172ea0] warning: first frame is no keyframe [New Thread 0x7fffc2200700 (LWP 4213)] [New Thread 0x7fffc1a54700 (LWP 4214)] [7fffbc001268] vdpau_display vout display error: bitmap surface creation failure: The size of a supplied object does not match the object it is being used with. For example, a VdpVideoMixer is configured to process VdpVideoSurface objects of a specific size. If presented with a VdpVideoSurface of a different size, this error will be raised. [7fffbc001268] vdpau_display vout display error: bitmap surface creation failure: The size of a supplied object does not match the object it is being used with. For example, a VdpVideoMixer is configured to process VdpVideoSurface objects of a specific size. If presented with a VdpVideoSurface of a different size, this error will be raised. [7fffbc001268] vdpau_display vout display error: bitmap surface creation failure: The size of a supplied object does not match the object it is being used with. For example, a VdpVideoMixer is configured to process VdpVideoSurface objects of a specific size. If presented with a VdpVideoSurface of a different size, this error will be raised. [7fffbc001268] vdpau_display vout display error: bitmap surface creation failure: The size of a supplied object does not match the object it is being used with. For example, a VdpVideoMixer is configured to process VdpVideoSurface objects of a specific size. If presented with a VdpVideoSurface of a different size, this error will be raised. [7fffbc001268] vdpau_display vout display error: bitmap surface creation failure: The size of a supplied object does not match the object it is being used with. For example, a VdpVideoMixer is configured to process VdpVideoSurface objects of a specific size. If presented with a VdpVideoSurface of a different size, this error will be raised. [7fffbc001268] vdpau_display vout display error: bitmap surface creation failure: The size of a supplied object does not match the object it is being used with. For example, a VdpVideoMixer is configured to process VdpVideoSurface objects of a specific size. If presented with a VdpVideoSurface of a different size, this error will be raised. [7fffbc001268]
Bug#759056: dicompyler: Please update to use wxpython3.0
Hi Olly,
I have updated
Vcs-Svn: svn://anonscm.debian.org/debian-med/trunk/packages/dicompyler/trunk/
a lot (also with help of Debian Python) but I think I'm stalled again
with an WX3.0 issue. If I build the package as in SVN and run
dicompyler I get a window telling me:
XRC error: 229: invalid column index 7: must be less than 4
The detailed log says:
12:12:27: XRC error: 90: too many children in grid sizer: 12 3 x 1 (consider
omitting the number of rows or columns)
12:12:27: XRC error: 90: unexpected item in sizer
12:12:27: XRC error: 229: invalid column index 5: must be less than 4
12:12:27: XRC error: 229: invalid column index 7: must be less than 4
Here is the full output of the xterm from where I called dicompyler:
$ dicompyler
ERROR: Unhandled exception: Traceback (most recent call last):
File /usr/bin/dicompyler, line 9, in module
load_entry_point('dicompyler==0.4.2', 'console_scripts', 'dicompyler')()
File /usr/share/dicompyler/dicompyler/main.py, line 946, in start
app = dicompyler(0)
File /usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_core.py, line 8631,
in __init__
self._BootstrapApp()
File /usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_core.py, line 8196,
in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File /usr/share/dicompyler/dicompyler/main.py, line 938, in OnInit
dicompylerFrame = MainFrame(None, -1, dicompyler, self.res)
File /usr/share/dicompyler/dicompyler/main.py, line 235, in __init__
parent = None, appname = 'dicompyler', name = 'Options')
File /usr/share/dicompyler/dicompyler/preferences.py, line 35, in __init__
pub.subscribe(self.SetPreferenceTemplate, 'preferences.updated.template')
TypeError: unbound method subscribe() must be called with Publisher instance as
first argument (got instancemethod instance instead)
Error in sys.excepthook:
Traceback (most recent call last):
File /usr/share/dicompyler/dicompyler/main.py, line 45, in LogExcepthook
pub.sendMessage('logging.exception', text)
TypeError: unbound method sendMessage() must be called with Publisher instance
as first argument (got str instance instead)
Original exception was:
Traceback (most recent call last):
File /usr/bin/dicompyler, line 9, in module
load_entry_point('dicompyler==0.4.2', 'console_scripts', 'dicompyler')()
File /usr/share/dicompyler/dicompyler/main.py, line 946, in start
app = dicompyler(0)
File /usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_core.py, line 8631,
in __init__
self._BootstrapApp()
File /usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_core.py, line 8196,
in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File /usr/share/dicompyler/dicompyler/main.py, line 938, in OnInit
dicompylerFrame = MainFrame(None, -1, dicompyler, self.res)
File /usr/share/dicompyler/dicompyler/main.py, line 235, in __init__
parent = None, appname = 'dicompyler', name = 'Options')
File /usr/share/dicompyler/dicompyler/preferences.py, line 35, in __init__
pub.subscribe(self.SetPreferenceTemplate, 'preferences.updated.template')
TypeError: unbound method subscribe() must be called with Publisher instance as
first argument (got instancemethod instance instead)
ERROR: Unhandled exception: Traceback (most recent call last):
File /usr/share/dicompyler/dicompyler/preferences.py, line 340, in OnClose
pub.sendMessage('preferences.updated.values', self.values)
TypeError: unbound method sendMessage() must be called with Publisher instance
as first argument (got str instance instead)
Error in sys.excepthook:
Traceback (most recent call last):
File /usr/share/dicompyler/dicompyler/main.py, line 45, in LogExcepthook
pub.sendMessage('logging.exception', text)
TypeError: unbound method sendMessage() must be called with Publisher instance
as first argument (got str instance instead)
Original exception was:
Traceback (most recent call last):
File /usr/share/dicompyler/dicompyler/preferences.py, line 340, in OnClose
pub.sendMessage('preferences.updated.values', self.values)
TypeError: unbound method sendMessage() must be called with Publisher instance
as first argument (got str instance instead)
Segmentation fault
Any idea how to fix this?
I have no idea whether this is connected to the patch[1] that was
inspired by your suggestion[2]. If not you might like to adapt your
script to include the changes I did in [1]. Could you possibly give
some advise what might be wrong?
Thanks a lot for your help
Andreas.
[1]
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/dicompyler/trunk/debian/patches/wxpy30-more.patch?revision=17981view=markup
[2] http://sources.debian.net/src/bitpim/1.0.7%2Bdfsg1-4/debian/
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759060: [o...@survex.com: Bug#759060: invesalius: Partial patch for wxPython 3.0]
Hi again Andreas,
I don't know if it's my setup here. But I think there is a problem in
the interaction between VTK5.8 and wxPython3, it was already reported
here [1], and is the same problem that Olly Betts reported some emails
ago. I installed Debian Testing inside a VirtualBox VM. The wxPyhon
version in 3.0, and VTK is 5.8. The error happens even with this
simple python script:
script
from vtk.wx.wxVTKRenderWindowInteractor import
wxVTKRenderWindowInteractorConeExample
wxVTKRenderWindowInteractorConeExample()
/script
Please, could you, please run this script in your setup?
Ah, I've created a branch to port invesalius to wxPython3.
Best regards!
[1] - https://groups.google.com/forum/#!topic/wxpython-users/MxJPxlOS05A
On Wed, Sep 10, 2014 at 9:52 AM, Thiago Franco Moraes
tfmor...@cti.gov.br wrote:
Hi Andreas,
Thanks for notify me about this patch. I was a little off, so I
haven't seen it. I have a branch of invesalius which works with
wxpython3, at least in MacOSX. I'm going to test it in Debian and see
if it works, and if works I'll generate a patch and create new debian
package with this patch applied.
Best regards!
On Wed, Sep 10, 2014 at 3:02 AM, Andreas Tille andr...@an3as.eu wrote:
Hi Thiago,
in case you missed this partial patch. Please note that even if there
are about six weeks the Freeze for Jessie is approaching and we should
get this straight in the next couple of weeks.
Kind regards
Andreas.
- Forwarded message from Olly Betts o...@survex.com -
Date: Tue, 9 Sep 2014 21:19:21 -0300
From: Olly Betts o...@survex.com
To: 759...@bugs.debian.org
Subject: Bug#759060: invesalius: Partial patch for wxPython 3.0
X-Debian-PR-Message: followup 759060
X-Debian-PR-Package: src:invesalius
X-Debian-PR-Keywords: jessie sid
X-Debian-PR-Source: invesalius
I've had a look at updating invesalius for wxpython3.0, and made some
progress.
However, the startup still isn't clean - the splash screen throws up
several errors - see invesalius.wxpy3.0.log - and once the app fires up,
there are clearly issues with the sizing of widgets, to the extent that
it isn't usable. I'm not sure if these are as a result of the splash
screen errors or not.
The logic in the splashscreen code seems hard to follow, relying on
several different delayed callbacks. I wonder if it's just inherently
racy, and a timing difference causes the failures with wxpython 3.0.
Anyway, I'm giving up on this one for the moment, but thought I should
at least send the patch I have so far to avoid duplicated effort if you
were also looking at it.
Cheers,
Olly
diff -Nru invesalius-3.0~b5/debian/changelog
invesalius-3.0~b5/debian/changelog
--- invesalius-3.0~b5/debian/changelog 2014-06-16 09:01:59.0 -0300
+++ invesalius-3.0~b5/debian/changelog 2014-09-09 21:00:48.0 -0300
@@ -1,3 +1,11 @@
+invesalius (3.0~b5-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update for wxPython 3.0 (Closes: #759060):
++ New patch: wxpython3.0.patch
+
+ -- Olly Betts o...@survex.com Wed, 10 Sep 2014 00:00:33 +
+
invesalius (3.0~b5-3) unstable; urgency=low
[ Thiago Franco de Moraes ]
diff -Nru invesalius-3.0~b5/debian/control invesalius-3.0~b5/debian/control
--- invesalius-3.0~b5/debian/control2014-06-16 09:00:44.0 -0300
+++ invesalius-3.0~b5/debian/control2014-09-09 20:03:09.0 -0300
@@ -22,7 +22,7 @@
${misc:Depends},
python-numpy,
python-scipy,
- python-wxgtk2.8 (= 2.8.12),
+ python-wxgtk3.0,
python-imaging,
python-vtk,
python-gdcm,
diff -Nru invesalius-3.0~b5/debian/patches/series
invesalius-3.0~b5/debian/patches/series
--- invesalius-3.0~b5/debian/patches/series 2014-04-28
13:21:20.0 -0300
+++ invesalius-3.0~b5/debian/patches/series 2014-09-09
20:03:43.0 -0300
@@ -1,2 +1,3 @@
10_sample_path.patch
10_import_mips.patch
+wxpython3.0.patch
diff -Nru invesalius-3.0~b5/debian/patches/wxpython3.0.patch
invesalius-3.0~b5/debian/patches/wxpython3.0.patch
--- invesalius-3.0~b5/debian/patches/wxpython3.0.patch 1969-12-31
21:00:00.0 -0300
+++ invesalius-3.0~b5/debian/patches/wxpython3.0.patch 2014-09-09
21:00:03.0 -0300
@@ -0,0 +1,114 @@
+Description: Update for wxPython 3.0
+ These changes should remain compatible with wxPython 2.8, aside from the
+ wxversion change in the last hunk.
+ .
+ We can't simply drop the wxversion.select() call and use
+ .
+ wxversion.ensureMinimal('2.8-unicode', optionsRequired=True)
+ .
+ because 3.0 is always Unicode, and the -unicode option has been dropped,
+ but wxversion isn't smart enough to know to allow for this when matching
+ options.
+Bug-Debian: https://bugs.debian.org/759060
+Forwarded: no
+Last-Update: 2014-09-09
+
+--- invesalius-3.0~b5.orig/invesalius/gui/dialogs.py
Bug#749060: [PATCH] [klibc] ppc64: ELFv2: Load TOC value in system call stub
On Tue, Sep 09, 2014 at 07:17:19PM -0300, Mauricio Faria de Oliveira wrote:
This fixes a segmentation fault in the system call's error handling path with
dynamically-linked binaries on PowerPC64 little endian. The system call stub
wasn't loading up r2 with the appropriate TOC value in its global entry point.
The r2 setup code comes from the FUNC_START macro in gcc [1] and an equivalent
one can also be found in the LOCALENTRY macro in glibc [2].
On the ELFv2 ABI (see [1]):
- The global entry point is expected to load up r2 with the appropriate TOC
value for this function.
- The local entry point expects r2 to be set up to the current TOC.
The problem happened with dynamically-linked binaries because:
- the system call is an indirect call (via global entry point) from the
binary
to the shared library, landing in the syscall stub (which didn't load up
r2
with the TOC of the shared library)
- its branch to __syscall_error is a direct call (via local entry point)
within
the shared library, landing in the function (which expects r2 to be set up
to
that TOC)
- when the function attempts to store errno (in an address relative to the
TOC),
that address incorrectly pointed to a read-only segment -- segmentation
fault.
The problem didn't happen with statically-linked binaries because the TOC
value
wasn't different on that case.
Thanks and credits to Alan Modra and Ulrich Weigand, for helping with this and
pointing out the solution.
[1] https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01141.html
[2] https://www.sourceware.org/ml/libc-alpha/2013-11/msg00315.html
Signed-off-by: Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com
---
usr/klibc/arch/ppc64/sysstub.ph |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/usr/klibc/arch/ppc64/sysstub.ph b/usr/klibc/arch/ppc64/sysstub.ph
index b3f6e38..a0c6d41 100644
--- a/usr/klibc/arch/ppc64/sysstub.ph
+++ b/usr/klibc/arch/ppc64/sysstub.ph
@@ -18,6 +18,9 @@ sub make_sysstub($@) {
#if _CALL_ELF == 2
.type ${fname},\@function
${fname}:
+0: addis 2,12,(.TOC.-0b)\@ha
+ addi2,2,(.TOC.-0b)\@l
+ .localentry ${fname},.-${fname}
#else
.section .opd,aw
.balign 8
Thanks for the patch, I confirm it fixes the problem.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761061: tracker doesnt show closed issues as done
Hi, On Donnerstag, 11. September 2014, Holger Levsen wrote: (oh, and it now just shows squeeze and squeeze-lts, as it would show wheezy and wheezy-security if that were in source_packages... I'm tempted to debug this now, but really need to do other stuff first :) grummel. and so this is fixed now too. will propose patches later for real. (the cause for this was that I did make update-$MANY_THINGS (and even added a update-all target) but forgot to run make all, which is now fixed/included in my update-all target too. Guess those targets need some cleanup too...) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#761161: git-buildpackage: gbp pq import+export should preserve patch filenames
On Thu, Sep 11, 2014 at 11:00:21AM +0200, Raphaël Hertzog wrote: Package: git-buildpackage Version: 0.6.19 Severity: wishlist When importing patches from debian/patches/series, gbp pq import should inject a Gbp-Patch-Name field in the commit log and use that during gbp pq export to preserve the filename. This could nicely obsolete the topic feature since that field could contain subdirectories like topic1/fix-foobar.patch. It's actually a feature that you don't need to mess with the patch names anymore (but can handle different topics). Having an explicit filename option like Gbp-pq: Filename path/relative/to/debian/patches.diff would be o.k. for corner cases though. The import part would need to learn about this too. Cheers, -- Guido -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages git-buildpackage depends on: ii devscripts2.14.6 ii git 1:2.1.0-1 ii man-db2.6.7.1-1 ii python2.7.8-1 ii python-dateutil 1.5+dfsg-1 ii python-pkg-resources 5.5.1-1 Versions of packages git-buildpackage recommends: ii cowbuilder0.73 ii pristine-tar 1.32 Versions of packages git-buildpackage suggests: ii python-notify 0.1.1-3 ii unzip 6.0-12 -- 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#761160: git-buildpackage: gbp pq: multiple user interface issues
clone 761160 -1 retitle 761160 pq: make export drop the patch queue branch retitle -1 pq: make switch import the patch queue branch thanks On Thu, Sep 11, 2014 at 10:55:03AM +0200, Raphaël Hertzog wrote: Package: git-buildpackage Version: 0.6.19 Severity: wishlist I would like to see the following changes in the behaviour of gbp pq: 1/ gbp pq export should automatically drop the temporary patch-queue branch Rationale: if other people do changes do the quilt series, my patch queue branch will be stale and this will force me to drop it manually and re-import it. Worst case: I don't notice it and I drop the work of others. If at all this should become an options since e.g. I prefer to keep the branch around. Patch would be welcome. 2/ gbp pq switch should automatically call gbp pq import if there is a pre-existing debian/patches/series. If I want to start a new empty patch queue branch, it should be a dedicated command (and it could be used here for the case where debian/patches/series doesn't exist). I mostly agree here but the case were the series doesn't import needs some consideration. (e.g. if it's better to create branch by going back in history like --time-machine does or fail upfront) and we need to decide whether to rebase the pq branch automatically on switch too. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
On Thu, Sep 11, 2014 at 09:33:13AM +0200, Cyril Brulebois wrote: I disagree that reusing package names across package types is a nice thing to do. I very strongly disagree that it's OK to try that when we're close to the freeze (and not at the very beginning of the release cycle, where it hurts less to upload disruptive changes). So, I think the best way to handle this longer-term would be: * upload hw-detect with a transitional package archdetect (Package-Type: udeb) Depends: archdetect-udeb * make sure everything copes well with that * at some later point (e.g. in jessie+1) introduce archdetect as a .deb I would like to have archdetect as a .deb; the archdetect-deb name I made up a while back in Ubuntu sucks and I wouldn't like to perpetuate it; I don't think there's a fundamental problem with reusing package names across package types, but in cases like this where it has coordination issues we should make some effort to smooth the transition rather than just going straight for it. -- 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#761162: clamav-unofficial-sigs: Cron job results spread onto mail and logs
On Thu, Sep 11, 2014 at 11:42:53AM +0200, Alessandro Vesely wrote: I frequently receive mail to clamav@`hostname` from the Cron Daemon, saying curl: (28) connect() timed out!, one or more times. ... The missing info is how severe those warnings are. When have those files been last updated? That is indeed the most annoying thing about clamav-unofficial-sigs, CCing upstream on this mail, Bill, full discussion here: https://bugs.debian.org/761162 Bill, would it be possible for you to update clamav-unofficial-sigs so that only signature downtime of more than one day is reported by the cron job? The current setup means that many admins are getting a lot of non-actionable cron spam, myself included. Perhaps, that recipient address should be configurable. To set the recipient address you can put MAILTO=some...@example.org in the cron job configuration file. shell variable si_url is hardcoded in clamav-unofficial- sigs.sh. Perhaps, making it configurable may encourage donations. In fact, it is not clear whether that host is managed by Sanesecurity or SecuriteInfo. You can change the default URL by putting si_url=... here: /etc/clamav-unofficial-sigs.conf.d/sanesecurl.conf I doubt the premium mirrors would resolve this issue though. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#750557: pgadmin3: segmentation fault
Le 11.09.2014 11:43, Bogdan Vatra a écrit : On Thursday 11 September 2014 11:31:44 Christoph Berg wrote: Hi guys, I've just uploaded 1.20.0~beta1 to unstable. Could you check if you still see the pgadmin3 crashes there? It seems to work for me now. Packages on apt.postgresql.org should be available shortly in the *-pgdg-testing suites. Christoph Hi, updated and tested, but no joy ;-(. Check http://paste.kde.org/pnrcj16nt BogDan. Same here, still segfaulting after right clicks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761138: closed by Paul Wise p...@debian.org (Re: Bug#761138: pagetrail misleading)
On Thu, 2014-09-11 at 17:57 +0800, 積丹尼 Dan Jacobson wrote: Nope. Not showing up. Even logged in with a different browser. I guess you aren't using the default theme, please change your preferences to switch to it. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#742855: order by release? you mean release_date?
Hi Salvatore, so you want more recent CVEs up and older CVEs down? (So far I achieved that for Security announcements but neither for Open issues nor Resolved issues...) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#761167: ITP: isort -- utility / library for sorting Python imports
X-Debbugs-CC: debian-pyt...@lists.debian.org Package: wnpp Severity: wishlist Owner: Tristan Seligmann mithra...@mithrandi.net * Package name: isort Version : 3.9.0 Upstream Author : Timothy Crosley * URL : https://github.com/timothycrosley/isort * License : MIT (Expat-style) Programming Lang: Python Description : utility / library for sorting Python imports isort is a Python utility / library to sort imports alphabetically, and automatically separated into sections. It provides a command line utility, Python library and plugins for various editors to quickly sort all your imports. I intend to maintain this package within the Python Applications Packaging Team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742855: order by release? you mean release_date?
Hi Holger, On Thu, Sep 11, 2014 at 12:36:26PM +0200, Holger Levsen wrote: so you want more recent CVEs up and older CVEs down? (So far I achieved that for Security announcements but neither for Open issues nor Resolved issues...) No, not about the CVE ordering, but the collumns in the tabular view. They are not generated consistently. For example if you look at [1], it says jessie | sid | wheezy [1] https://security-tracker.debian.org/tracker/source-package/libspring-java Others are correct, for example [2], which says squeeze | wheezy | jessie | sid [2] https://security-tracker.debian.org/tracker/source-package/bind9 Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#482577: still applicable today? (pending notation)
Hi, is this bug still of concern today? No activity since 5 years so I assume this problem has been solved or disappeared by now ;) cheerrs, Holger signature.asc Description: This is a digitally signed message part.
Bug#752384: HEAnet sourceforge mirror is outdated
Hi Paul,
On 11/09/14 04:20, Paul Wise wrote:
On Tue, Jul 22, 2014 at 5:29 PM, Daniel Lintott wrote:
I shall drop another version of the patch to the bug report that reverts
the custom caching mechanism.
A yak shaving exercise reminded me that this hasn't been done yet,
could you please send the updated patch?
Apologies for not getting this done sooner, got tied up with some other
projects.
Attached is a new patch against the old sf.wml from SVN, that doesn't
include any caching mechanism.
Regards
Daniel
--- ../sf-redirect-old/sf.wml 2014-07-21 19:24:00.835216162 +0100
+++ sf.wml 2014-09-11 11:46:00.277558546 +0100
@@ -1,21 +1,10 @@
?php
-
-$data_dir = '/srv/qa.debian.org/data/watch';
-
// need to strip leading slash, sf.net doesn't like double slashes
$project=ltrim($_SERVER['PATH_INFO'], '/');
if (!$project) {
-header('Location: http://manpages.debian.net/cgi-bin/man.cgi?query=uscan');
-exit;
-}
-
-$fdb = $data_dir . '/sf-list.db';
-
-if (!file_exists($fdb)) {
-header('HTTP/1.0 500 Internal Server Error');
-die('The files database is not available. Please report this message to'.
- ' debian...@lists.debian.org');
+ header('Location: http://manpages.debian.net/cgi-bin/man.cgi?query=uscan');
+ exit;
}
// $project is not a file and doesn't have trailing slash
@@ -29,40 +18,31 @@
exit;
}
-$db = dba_open($fdb, 'r', 'db4');
-
-if (!dba_exists($project, $db)) {
-header('HTTP/1.0 404 File Not Found');
-die('There is no information about the '.$project.' project.');
-}
+$xml_url = https://sourceforge.net/projects/$project/rss;;
-?html
+$xml = simplexml_load_file($xml_url, 'SimpleXMLElement', LIBXML_NOCDATA);
+$title = $xml-channel[0]-title;
+$files = $xml-channel[0]-item;
+?
+html
head
-titleFile listing for project ?php echo htmlspecialchars($project); ?/title
+titleFile listing for project ?php echo $title; ?/title
/head
body
p
-h1File listing for project ?php echo htmlspecialchars($project); ?/h1
-Visit a href=http://sf.net/projects/?php echo htmlspecialchars($project); ??php echo
-htmlspecialchars($project); ?'s project page/a.br/br/
+h1File listing for project ?php echo $title; ?/h1
+Visit a href=http://sf.net/projects/?php echo $project; ??php echo $project; ?'s project page/a.brbr
?php
-echo dba_fetch($project, $db);
+foreach ($files as $item) {
+ $file = basename($item-title);
+ $link = $_SERVER['SCRIPT_NAME'] . /$project/$file;
+ echo a href='$file'$file/abr\n;
+}
?
/p
p
-Thanks to a href=http://ftp.heanet.ie/;HEAnet's mirror service/a
-for being the source of data for this service.
-/p
-p
Get the source code: a href=svn://anonscm.debian.org/svn/qa/trunk/wml/watchcheckout SVN repository/a #124;
a href=http://anonscm.debian.org/viewvc/qa/trunk/wml/watch/;browse SVN repository/a
/p
-p Last database update:
-?php echo date(DATE_RFC822, filemtime($fdb)); ?
-/p
/body
-/html?php
-
-dba_close($db);
-
-?
+/html
signature.asc
Description: OpenPGP digital signature
Bug#761164: libpoppler-qt4-4: leaks private symbols into the public ABI
Hi, On 2014-09-11 12:22, Paul Wise wrote: I am rebuilding poppler for wheezy-backports. My normal build process includes DPKG_GENSYMBOLS_CHECK_LEVEL=4 That isn't a wise thing to do, with a different toolchain. and as a result I got a build failure (see below) due to new symbols being introduced. Based on the name these are clearly private symbols that should not be exported in the public ABI, please set the default symbol visibility to hidden. libpoppler-qt4-N (and now libpoppler-qt5-N) already *do* have symbols visibility by default, and this is a Debian-specific change (just because I haven't found the time to do the proper buildsystem bits upstream). What you see are internal symbols which older GCCs somehow still export. I cannot do anything about them, and if you see the symbols file for libpoppler-qt4-3 (in stable), these symbols are there, just marked as optional (as gccinternal stuff). In the end: a) there is nothing I can do about them b) don't use DPKG_GENSYMBOLS_CHECK_LEVEL=4 with a different toolchain -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
Hi, due to bug #736066, encfs was removed from jessie. I'd think it would be better to allow encfs into jessie for the following reasons: The bug report is about security issues, but these are not security issues of the software (as in: you can somehow hack into the computer wich is running the software), but of the encryption algorithms used. So it can be compared to a package implementing md5: Yes, it's known that md5 is not secure any more, but that's not a reason to remove all packages implementing md5 from debian. One could argue that encfs shouldn't be used any longer to encrypt files, and therefore encfs is just not useful and can be removed. But many users will have legacy installations using encfs encrypted file systems, and will be surprised that they can't access them any more from jessie. So removing encfs will cause major inconveniences to some of our users. Therefore, I propose that encfs should be allowed into jessie. (What would be the right way to do that? Lower the severtiy of the bug? Add a jessie-ignore tag?) To notify users about the potential security issue, a NEWS file could be added, or one could add a warning to the output of the encfs command. Regards, Jan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761168: systemtap-common: procfs probes fail
Package: systemtap-common
Version: 1.7-1+deb7u1
Severity: normal
Tags: patch
Dear Maintainer,
Trying a simple procfs probe like this:
---profs-read.stp-
probe procfs(readme).read {
$value = 100\n
}
---
reports an error while compiling:
-
# stap profs-read.stp
In file included from
/tmp/staphcNerS/stap_4162120524274ba06e575bd8424aaf44_1037_src.c:173:0:
/usr/share/systemtap/runtime/procfs.c: In function
‘_stp_mkdir_proc_module’:
/usr/share/systemtap/runtime/procfs.c:148:27: error: dereferencing pointer to
incomplete type
make[3]: *** [/tmp/staphcNerS/stap_4162120524274ba06e575bd8424aaf44_1037_src.o]
Error 1
make[2]: *** [_module_/tmp/staphcNerS] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
WARNING: make exited with status: 2
Pass 4: compilation failed. Try again with another '--vp 0001' option.
-
It seems struct vfsmount is not defined. It can be fixed adding:
#include linux/mount.h
in top of file /usr/share/systemtap/runtime/procfs.c
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
systemtap-common depends on no packages.
Versions of packages systemtap-common recommends:
ii systemtap 1.7-1+deb7u1
systemtap-common suggests no packages.
-- no debconf information
--- /usr/share/systemtap/runtime/procfs.c.orig 2014-09-11 12:39:39.0 +0200
+++ /usr/share/systemtap/runtime/procfs.c 2014-09-11 12:39:19.0 +0200
@@ -21,6 +21,8 @@
#include linux/pid_namespace.h
#endif
+#include linux/mount.h
+
/* The maximum number of files AND directories that can be opened.
* It would be great if the translator would emit this based on the actual
* number of needed files.
Bug#761169: ruby-gsl: please update to latest version, 1.16.0.2
Package: ruby-gsl Version: 1.15.3+dfsg-2 Severity: wishlist Hi, The upstream the package lists seem to be dead, even the server is gone: http://rb-gsl.rubyforge.org/ The new upstream seems to be this one: https://github.com/blackwinter/rb-gsl RubyGems seems to be track this upstream, too: https://rubygems.org/gems/rb-gsl Please consider switching to new upstream and packaging the new version. Cheers, Balint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761170: libgit2: FTBFS on multiple architectures
Source: libgit2 Version: 0.21.1-1 Severity: important Hi, libgit2 is unfortunately FTBFS on multiple architectures in unstable due to test failures. Would be nice if the pkg was building on all the architectures. Cheers, Laurent Bigonville -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667592: libaspell15: multiarch problem
On Thu, May 01, 2014 at 09:44:19PM -0400, David Sanders wrote:
AMD wrote:
I am writing as dictionaries-common maintainer (not aspell maintainer)
since some things here are related to the common dictionaries support
for aspell dictionary hashes autobuild.
The problem behind is that dictionary hashes are arch dependent, and
IIRC, this is not only about endianness. Currently, hashes are
auto-generated at postinst stage for most dictionaries, which are
arch:all. This way we keep our archive smaller and any possible change
in hash format automatically triggers a hash rebuild for all
dictionaries using this model making transitions painless.
Unfortunately, this is not very multiarch-friendly.
The dictionary hashes depend on two things endianness and the size_t
for the architechture. The upstream authors recognized this as a
problem on systems with 32-bit and 64-bit code and have a workaround.
See here:
http://aspell.net/0.61/man-html/Using-32_002dBit-Dictionaries-on-a-64_002dBit-System.html
All that is required is to use a configure time flag to cause aspell to always
use a 32-bit number in the hash. Then for example the i386 and amd64
architectures (and other combinations where the endianness is the same)
can be configured for multiarch support.
This could be done relatively simpley for jessie.
Hi, thanks for the very interesting info.
Unfortunately, this is not all the problem. There are some things in aspell
buildchain that make this harder,
On Fri, Sep 05, 2014 at 06:57:27PM +0200, Matthias Urlichs wrote:
this bug prevents installation of several nontrivial 3rd-party packages on
Jessie;
basically, anything that indirectly depends on some library which supports
spell checking, even if the package in question doesn't do any spell
checking whatsoever. Webkit, for instance.
...
Please fix.
I have been looking at this in case I can prepare an aspell NMU, and as
wrote above, there are more things involved than just the 32/64-bit stuff
before we can have a multiarch implementation.
I have already done some work on this. I am trying to implement something
like (for i386/amd64)
/usr/lib/aspell: dicts, valid for both architectures.
/usr/lib/{i386,x86_64}-linux-gnu:General purpose libs (libaspell...)
/usr/lib/aspell/{i386,x86_64}-linux-gnu: Aspell filters (binaries) and friends
/usr/share/aspell: Data files
For this some things need to be done:
a) Really fix https://bugs.debian.org/612051 instead of working around it.
I think I found the reason for the problem and a working fix. Submitted
upstream for his opinion.
b) Allow explicit selection of dictionaries path in a way independent of
the place filters will go. Initial implementation done, needs more
testing. Also let upstream know about this.
c) The usual multiarch stuff.
The good news are that things seem to be working, so unless something weird
happens, I'd expect this to be fixed in time for jessie by means of an NMU,
Regards,
--
Agustin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761171: wagon2 fails to build in a non networked environment
Package: src:wagon2 Version: 2.6-1 Severity: serious Tags: sid jessie the tests fail without network access: [...] T E S T S --- Running org.apache.maven.wagon.providers.http.HugeFileDownloadTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 51.61 sec Running org.apache.maven.wagon.providers.http.HttpClientWagonTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.maven.wagon.providers.http.AbstractHttpClientWagonTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.052 sec FAILURE! Results : Tests in error: test(org.apache.maven.wagon.providers.http.AbstractHttpClientWagonTest): repo.maven.apache.org: Name or service not known Tests run: 6, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747032: RFS: libjs-zxcvbn/1.0+dfsg.1-1
I completely agree that downloading anything at build-time is a no-no, but... * Eriberto Mota eribe...@debian.org, 2014-09-10, 15:45: 3. The buildd system, that builds packages in Debian, don't have access to the Internet. This is a common misconception. Buildds do not block Internet access. (Although hopefully they will do this in the future!) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761172: libitext5-java tests fail in a non networked environment
Package: src:libitext5-java Version: 5.5.0-1 Severity: serious Tags: sid jessie causing a build failure. [...] Results : Tests in error: remoteGifTest(com.itextpdf.text.RemoteGifImageTest): itextpdf.com Tests run: 210, Failures: 0, Errors: 1, Skipped: 4 [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758105: handling bytes not part of the charset, and other garbage (was: grep -P and invalid exits with error)
On 2014-09-01 01:31:53 -0700, Paul Eggert wrote: Vincent Lefevre wrote: If there are many invalid UTF8 bytes, this would be slow, IMHO That's OK. We don't need grep -P to be fast on invalid input. I can see a too important slowdown in practical cases. But is the copy of the buffer really needed? Couldn't the invalid UTF8 sequences just be replaced by null bytes? I'd rather not, because that changes the semantics of matching. The null byte is valid input data that might get matched. It appears that the current behavior in UTF-8 is incorrect, even without -P. For instance: $ printf 'tr\xe8s\n' text $ grep 'tr.s' text $ LC_ALL=C grep 'tr.s' text trE8s There's no reason that '.' matches something that doesn't belong to the charset in C locale, but doesn't match in a UTF-8 locale. The pattern tr.s is used here to match the French word très in files that could be encoded in ISO-8859-1 or UTF-8 locales. In the past, before using UTF-8 locales, I was doing something like: grep -E 'tr..?s' text to match both encodings, and this worked (I could get false positives, but anyway, one is often not interested in all the real grep matches in practice, so that even when knowing the encoding, one was already getting false positives). It's annoying that now in UTF-8, one can no longer match ISO-8859-1 text, and doing a pre-conversion would take too much time. Concerning binary files, I've never wanted to differentiate explicitly null bytes and invalid UTF-8 sequences: IMHO, this is just garbage. There are obviously no differences with patterns like 'some_word' or 'foo[0-9]*bar', but when I use a pattern like 'foo.bar' or 'foo.*bar', I can see two valid reasons to handle these sequences in a similar way with '.': 1. One may want to match valid (often in the sense printable, in the specified encoding) but unknown characters. 2. One may also want to match garbage (including null bytes, and also bytes that do not have any meaning in the charset), with the drawback that if the garbage contains a newline character, this won't work. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://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#686518: network_interfaces() does not work with systemd
It seems that most of the problem is fixed in the recent version
as ifup --allow=ovs [bridges…]” is called in the network_interfaces()
function.
Sadly, when using systems, this function just return and does not
execute ifup as ${RUNLEVEL} is not set.
I have no idea what purpose the line [ -z ${RUNLEVEL} ] return”
in network_interfaces has, but it prevents this bug from being fixed
when systemd is used as init :(
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761165: vlc: segmentation fault with VDPAU
tags 761165 + moreinfo thanks Hello, Le 2014-09-11 13:11, Arthur Marsh a écrit : [7fffbc001268] vdpau_display vout display error: bitmap surface creation failure: The size of a supplied object does not match the object it is being used with. For example, a VdpVideoMixer is configured to process VdpVideoSurface objects of a specific size. If presented with a VdpVideoSurface of a different size, this error will be raised. That's VdpBitmapSurfaceCreate() failing with error VDP_STATUS_INVALID_SIZE. Consequently, OSD and subtitles will fail. That error does not make much sense in this context; this is probably a bug in the VDPAU driver. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffc2200700 (LWP 4213)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x7fffc7191df7 in pipe_sampler_view_reference (view=0x0, ptr=optimized out) at ../../../../../src/gallium/auxiliary/util/u_inlines.h:151 #2 destroy_video_buffer_private (private=0x7fffcc01acc0) at ../../../../../src/gallium/auxiliary/vl/vl_mpeg12_decoder.c:103 #3 0x7fffc71ada58 in vl_video_buffer_set_associated_data ( destroy_associated_data=0x0, associated_data=0x0, vcodec=0x0, vbuf=0x7fffcc01d560) at ../../../../../src/gallium/auxiliary/vl/vl_video_buffer.c:200 #4 vl_video_buffer_destroy (buffer=0x7fffcc01d560) at ../../../../../src/gallium/auxiliary/vl/vl_video_buffer.c:265 #5 0x7fffc71f76ba in vlVdpVideoSurfaceDestroy (surface=5) at ../../../../../../src/gallium/state_trackers/vdpau/surface.c:139 That too looks a lot like (another but possibly related) bug in the VDPAU driver. If you can, try to play the same DVD with another graphic card and a different VDPAU driver (e.g. the NVIDIA proprietary blob). Otherwise I will need a legal sample file. If that is also not possible, I will have to assume this is a Mesa driver bug and advise Debian Multimedia to reassign. -- Rémi Denis-Courmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644373: libproxy0 0.3.1-3 doesn't work with automatic proxy configuration
Any clues what can be wrong? Is WPAD with proxy working for you? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752900: ITP: appstream-glib -- Library for AppStream metadata access
2014-09-11 11:20 GMT+02:00 Andreas Henriksson andr...@fatal.se: Hello! Any progress on this so far? Do you have any outlook for the future? It feels like it's getting tight now for getting it into Jessie. What are your plans? It's in progress. Only recently, upstream added support for DEP-11, which was important for Debian. Now, appstream-glib is on my todo list right after landing AppStream support in dak (without that, both the appstream package and the future appstream-glib package aren't really useful) Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761165: vlc: segmentation fault with VDPAU
Rémi Denis-Courmont wrote, on 11/09/14 20:46: tags 761165 + moreinfo thanks Hello, Le 2014-09-11 13:11, Arthur Marsh a écrit : [7fffbc001268] vdpau_display vout display error: bitmap surface creation failure: The size of a supplied object does not match the object it is being used with. For example, a VdpVideoMixer is configured to process VdpVideoSurface objects of a specific size. If presented with a VdpVideoSurface of a different size, this error will be raised. That's VdpBitmapSurfaceCreate() failing with error VDP_STATUS_INVALID_SIZE. Consequently, OSD and subtitles will fail. That error does not make much sense in this context; this is probably a bug in the VDPAU driver. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffc2200700 (LWP 4213)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x7fffc7191df7 in pipe_sampler_view_reference (view=0x0, ptr=optimized out) at ../../../../../src/gallium/auxiliary/util/u_inlines.h:151 #2 destroy_video_buffer_private (private=0x7fffcc01acc0) at ../../../../../src/gallium/auxiliary/vl/vl_mpeg12_decoder.c:103 #3 0x7fffc71ada58 in vl_video_buffer_set_associated_data ( destroy_associated_data=0x0, associated_data=0x0, vcodec=0x0, vbuf=0x7fffcc01d560) at ../../../../../src/gallium/auxiliary/vl/vl_video_buffer.c:200 #4 vl_video_buffer_destroy (buffer=0x7fffcc01d560) at ../../../../../src/gallium/auxiliary/vl/vl_video_buffer.c:265 #5 0x7fffc71f76ba in vlVdpVideoSurfaceDestroy (surface=5) at ../../../../../../src/gallium/state_trackers/vdpau/surface.c:139 That too looks a lot like (another but possibly related) bug in the VDPAU driver. If you can, try to play the same DVD with another graphic card and a different VDPAU driver (e.g. the NVIDIA proprietary blob). Otherwise I will need a legal sample file. If that is also not possible, I will have to assume this is a Mesa driver bug and advise Debian Multimedia to reassign. I noticed that the bug report didn't include any vdpau related package versions nor video card details. dpkg -l|grep vdpau returned: ii libvdpau-dev:amd64 0.7-2 amd64Video Decode and Presentation API for Unix (development files) ii libvdpau-doc 0.7-2 all Video Decode and Presentation API for Unix (documentation) ii libvdpau-va-gl1:amd64 0.3.4-1+b1 amd64VDPAU driver with OpenGL/VAAPI backend ii libvdpau1:amd640.7-2 amd64Video Decode and Presentation API for Unix (libraries) ii mesa-vdpau-drivers:amd64 10.2.6-1 amd64Mesa VDPAU video acceleration drivers ii mesa-vdpau-drivers-dbg:amd64 10.2.6-1 amd64Debugging symbols for the Mesa VDPAU video acceleration drivers ii vdpau-va-driver:amd64 0.7.4-3 amd64VDPAU-based backend for VA API ii vdpauinfo 0.1-1 amd64Video Decode and Presentation API for Unix (vdpauinfo utility) and the video card is reported as: Chipset: ATI Radeon HD3850 (ChipID = 0x9505) I will investigate getting an NVIDIA card to see if the problem can be reproduced with it. Regards, Arthur. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
