Bug#737095: qdbus segfaults
[snip] But those symbols are Qt5 related. Do you happen to have qt5-default installed? If you have qt5-default installed, please allow me to sugegst some stuff to see what could be going wrong: 1) Try calling qdbus with: gdb -ex r --args qdbus -qt4 org.kde.kmail2 /kmail2/kmail_composer_1 2) If you are using unstable you might want to try Qt 5.2.0 from experimental. 3) Remove qt5-default. That will make qt4 the default Qt stack. If you want to develop stuff under Qt5 you can always use CMake or export QT_SELECT=qt5, see [0] [0] http://perezmeyer.blogspot.com.ar/2013/08/qt-in-debian-using-qt4-andor-qt5-in.html Kinds regards, Lisandro. -- If for every rule there is an exception, then we have established that there is an exception to every rule. If we accept For every rule there is an exception as a rule, then we must concede that there may not be an exception after all, since the rule states that there is always the possibility of exception, and if we follow it to its logical end we must agree that there can be an exception to the rule that for every rule there is an exception. Bill Boquist Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Putting it another way, then, I expect there are some people who will not want systemd on their GNU/Linux systems. I don't think it matters if their reasons are technical, political, irrational fear or personal dislike of the creator; I'd like them to have that choice and for it to work as well as possible. Whatever init system we use on the non-Linux ports (which will certainly not be systemd), I expect it will be fully available to Debian GNU/Linux installs, with init scripts that we'd have to maintain already for the sake of our ports. Hopefully that is some reassurance. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#737072: ITP: KeySigningPartyTools -- create a better formatted list in PDF format by reading a FOSDEM key list
On Thu, Jan 30, 2014 at 1:11 PM, Alexander Wirt formo...@debian.org wrote: On Wed, 29 Jan 2014, Alberto Fuentes wrote: Package: wnpp Severity: wishlist Owner: Alberto Fuentes paj...@gmail.com * Package name: KeySigningPartyTools Version : n/a Upstream Author : Vadim Trochinsky m...@vadim.ws * URL : https://github.com/vatral/KeySigningPartyTools * License : AGPL v3 Programming Lang: Perl Description : create a better formatted list in PDF format by reading a FOSDEM key list Key signing is really in need of a program that eases interchange of keys. KeySigningPartyTools generates a pdf with qr codes and visual hints for the fingerprints that allows faster processing and avoid manual errors. It process the qr codes afterwards with the help of a webcam as well. It also automatically checks that the keys scanned match the keys downloaded before you sign them. There already is a signing-party package, would you mind to integrate KeySigningPartyTools into it? Thanks Alex I can sure look into it if its ok to Thijs... Any suggestion on how to proceed since the package will have two sources? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737090: [Pkg-ime-devel] Bug#737090: ibus-pinyin: Perhaps need pinyin database
control: severity 737090 grave Hi, Thanks for noticing this. On Wed, Jan 29, 2014 at 11:02:56PM -0800, Hongzheng Wang wrote: Package: ibus-pinyin Version: 1.5.0-1 Severity: important Dear Maintainer, The package ibus-pinyin in sid just updated to 1.5.0. I noticed that it no longer depends on ibus-pinyin-db-open-phrase/android. My question is where the new ibus-pinyin gets pinyin database. I checked Fedora package and found there is a pyzy that contains a file 'main.db'. By contrast, Debian's libpyzy contains only pyzy algorithms. OK we need to upload it as such. As I see: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=145709 pyzy-0.1.0.tar.gz 1571946 pyzy-database-1.0.0.tar.bz2 9977983 pyzy.spec So they include pyzy-database-1.0.0.tar.bz2 . Considering this database may be arch-indep. We may be better off packaging separately. (Although this is not pkg-ime package but considering people inviolved and archive used, i hope it is OK to include it into pkg-ime. * Tue May 28 2013 Peng Wu p...@redhat.com - 0.1.0-6 - Obsoletes ibus-pinyin-db Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737095: qdbus segfaults
1) Try calling qdbus with: gdb -ex r --args qdbus -qt4 org.kde.kmail2 /kmail2/kmail_composer_1 That works. 2) If you are using unstable you might want to try Qt 5.2.0 from experimental. Hmmm, I got qt5-default=5.2.0something - but that's not enough. libqt5core5 has no 5.2.0 - what else should get upgraded? 3) Remove qt5-default. That will make qt4 the default Qt stack. If you want to develop stuff under Qt5 you can always use CMake or export QT_SELECT=qt5, see [0] Well, I wanted to get to QT5 at some time ... So I don't really have an opinion about which way to choose. Thanks for the quick answer! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651308: libsasl2-modules-gssapi-mit: buggy autoconf m4 script makes SASL's keytab option not work
On Wed, Jan 29, 2014 at 08:30:16PM -0500, Benjamin Kaduk wrote: That routine is prototyped in gssapi/gssapi_krb5.h; the file(s) in question should include that header if it is present. I did not get a chance to look at the full build log or other warnings it may contain. Ben, Thanks very much for the pointer. I went ahead and added this to the plugins/gssapi.c source file (which uses that routine now): #ifdef HAVE_KRB5_GSS_REGISTER_ACCEPTOR_IDENTITY #include gssapi/gssapi_krb5.h #endif That seemed to do the trick, as there are no longer any build warnings related to krb5_gss_register_acceptor_identity. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature ___ Pkg-cyrus-sasl2-debian-devel mailing list pkg-cyrus-sasl2-debian-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-sasl2-debian-devel
Bug#651308: libsasl2-modules-gssapi-mit: buggy autoconf m4 script makes SASL's keytab option not work
On Wed, 29 Jan 2014, Roberto C. Sánchez wrote: On Tue, Jan 28, 2014 at 12:39:08PM -0800, Russ Allbery wrote: I think this needs to be fixed within the cyrus-sasl2 package. Exposing this as a function would mean adding a new function just to make the Autoconf probe work, which doesn't seem like a good idea. (The solution that the bug reporter proposes definitely doesn't work, since as mentioned that would change the GSS-API library API.) I suspect that SASL is currently doing something like: AC_CHECK_FUNCS([gsskrb5_register_acceptor_identity]) The right solution is probably to also do: AC_CHECK_FUNCS([krb5_gss_regster_acceptor_identity]) and then use whichever one is found. Russ, I have made an attempt at what you suggested. I have attached the patch I created to implement the solution. The question that I have is whether the below warning is something to worry about: ../../plugins/gssapi.c: In function 'gssapiv2_server_plug_init': ../../plugins/gssapi.c:1321:2: warning: implicit declaration of function 'krb5_gss_register_acceptor_identity' [-Wimplicit-function-declaration] krb5_gss_register_acceptor_identity(keytab_path); cyrus-sasl2 builds with tons of warnings about all sorts of GSSAPI things, so I am not sure if this is just par for the course or if I actually did something wrong. That routine is prototyped in gssapi/gssapi_krb5.h; the file(s) in question should include that header if it is present. I did not get a chance to look at the full build log or other warnings it may contain. -Ben
Bug#735162: xml-security-c: FTBFS on hurd-i386
Svante Signell svante.sign...@gmail.com writes: The attached patch fixes this problem by adding a check in configure.ac for a working path = getcwd(NULL, 0) allocating the string length required dynamically, and freed later on. Similarly the string baseURI is malloced and freed. I can see the freeing of baseURI, but not that of path. I'd say it's leaked. Or do I miss something here? -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737118: kdepimlibs: FTBFS on powerpcspe due to symbol changes
tag 737118 pending thanks Hi! I've just fixed the symbols in the repo, but I will not upload because the package needs one more day to get into testing and is now part of the libboost transition. Feel free to ping me if I forget to push the fix once the package gets to testing. Kinds regards, Lisandro. -- In college, I cooked some hot dogs by putting metal forks in each end of the hot dog and running 120 volts through it. Hot dogs have just enough conductivity so that this works well greenroom(576281) - on a truly geeky way to cook hot dogs. Posted in Slashdot, also found in The Open Source Cookbook for Geeks. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
Quoting Antoine Beaupré (2014-01-30 05:24:51)
On 2014-01-29 23:12:50, Jerome Charaoui wrote:
Le 2014-01-29 22:16, Antoine Beaupré a écrit :
Jérome: what's wrong with sass? you seem to be looking through
heaven and earth for an alternative... :)
I don't have any bias against it, it's only that pulling in ruby does
seem a bit overkill. Plus, if we want PhotoFloat to use sass and
handle css syntax errors I think that may require some adjustments
upstream to the Makefile and/or patches, or at least a ship custom
script with the package like Jonas suggests.
That's a good point. Ruby is huge, maybe we don't want to add that
extra dependency.
I am not sure we should worry about CSS syntax errors, that seems like
a nice feature anyways.
Using make, ruby-sass and node-uglify - no patching:
make -C web css/styles.min.css JS_COMPILER=uglifyjs CSS_COMPILER='perl -e
'\''system sass --style compressed --no-cache $$ARGV[2] $$ARGV[1]'\'' -- '
runtime filesize: 3650 + 18024 = 21674
runtime pkgsize bloat: ~1M + ~13M + ~7M = ~21M
***
Using ruby-sass and node-uglify - no make or patching:
find web/css -name '*.css' -not -name '*.min.css' -exec cat {} + \
| scss --style compressed --no-cache --stdin web/css/styles.min.css
find web/js -name '*.js' -not -name '*.min.js' -exec cat {} + \
web/js/scripts.min.js~ \
uglifyjs -o web/js/scripts.min.js web/js/scripts.min.js~ \
rm web/js/scripts.min.js~
runtime filesize: 3648 + 13267 = 16915
runtime pkgsize bloat: ~13M + ~7M = ~20M
***
My favorite - uglify at build time and preserve CSS readable shipped
below /etc to allow editing (why hardcode Palatino?):
find web/css -name '*.css' -not -name '*.min.css' -exec cat {} + \
| scss --style compact --no-cache --stdin web/css/styles.min.css
find web/js -name '*.js' -not -name '*.min.js' -exec cat {} + \
web/js/scripts.min.js~ \
uglifyjs -o web/js/scripts.min.js web/js/scripts.min.js~ \
rm web/js/scripts.min.js~
runtime filesize: 4178 + 13267 = 17445
runtime pkgsize bloat: 0
If you insist on uglifying at runtime, then I still recommend compacting
CSS at build time (300 bytes win is silly when using jQuery bloat!).
If you insist on uglifying _CSS_ at runtime, then I still recommend
using ruby-sass, and switch to sassc later (see bug#694733,694730).
- Jonas
--
* Jonas Smedegaard - idealist Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#737133: rm: krb5-appl -- ROM obsolete by kerberos ssh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 package: ftp.debian.org Hi. After discussion on debian-devel, I've decided to remove krb5-appl. One of the comaintainers dropped out, and after discussion we realized that we weren't using the package, there are better alternatives in the community, and discussion on debian-devel suggests few if any other people are using it either. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLqYPgACgkQ/I12czyGJg8OCACgr0bq6+wIlRMHSnjHEbgTMN7s odAAoJ+vkX6i0Xcci961zXM7tb+E5rwp =WHhB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737072: ITP: KeySigningPartyTools -- create a better formatted list in PDF format by reading a FOSDEM key list
On Thu, January 30, 2014 15:17, alberto fuentes wrote: On Thu, Jan 30, 2014 at 1:11 PM, Alexander Wirt formo...@debian.org wrote: On Wed, 29 Jan 2014, Alberto Fuentes wrote: Package: wnpp Severity: wishlist Owner: Alberto Fuentes paj...@gmail.com * Package name: KeySigningPartyTools Version : n/a Upstream Author : Vadim Trochinsky m...@vadim.ws * URL : https://github.com/vatral/KeySigningPartyTools * License : AGPL v3 Programming Lang: Perl Description : create a better formatted list in PDF format by reading a FOSDEM key list Key signing is really in need of a program that eases interchange of keys. KeySigningPartyTools generates a pdf with qr codes and visual hints for the fingerprints that allows faster processing and avoid manual errors. It process the qr codes afterwards with the help of a webcam as well. It also automatically checks that the keys scanned match the keys downloaded before you sign them. There already is a signing-party package, would you mind to integrate KeySigningPartyTools into it? Thanks Alex I can sure look into it if its ok to Thijs... I don't see any objection, but in fact. I prefer to actually relinquish my maintainership of signing-party. Any suggestion on how to proceed since the package will have two sources? It's possible to work with multiple source tarballs... Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#360202: aptitude: misaligned output of aptitude show in ru_RU.UTF-8 locale
Control: tags -1 + confirmed The problem seems to be here: src/cmdline/cmdline_show.cc: return cw::fragf(%s: %F, title.c_str(), indentbox(0, title.size()+2, flowbox(cw::join_fragments(fragments, L, ; For indenting name and contents of a field (e.g. Depends) on several lines, it uses zero as the first parameter meaning spaces of indentation of the first line, and the second parameter for the spaces of indentation of the remaining lines. Since it takes title.size() + 2, presumably because in ru_RU.UTF-8 locale each character takes two positions in a std::string (the type of title variable), the lines following the first one are indented with roughly double of the space needed. This should be easy to fix if one knows how many characters will occupy when printed. But probably there should be a comprehensive review of all this and use a solution everywhere in the code, not just here. Using std::wstring for all translatable strings might help, but I don't know if it will work fine all the charsets. Probably C++11 has better support for this, so maybe this is the way to go. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664729: cyrus-sasl2-heimdal-dbg: fails to purge after lenny-squeeze-wheezy upgrade: diversions not removed
On Wed, Jan 29, 2014 at 09:18:59PM +0100, Andreas Beckmann wrote: Please fix this for jessie, the fix should be rather trivial. In postinst configure, you most probably want to do this: dpkg-divert --remove --package cyrus-sasl2-heimdal-dbg --divert /usr/lib/debug/usr/lib/sasl2/libgssapiv2.so.2.0.22.mit --rename /usr/lib/debug/usr/lib/sasl2/libgssapiv2.so.2.0.22 (based on the preinst script in lenny, the postrm script seems wrong as it is missing the --divert option). I did not realize that the fix would be so trivial. I will go ahead and add a cyrus-sasl2-heimdal-dbg.postinst script with this command. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#736958: CVE request: temporary file issue in Passenger rubygem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If a local attacker can predict this filename, and precreates a symlink with the same filename that points to an arbitrary directory with mode 755, owner root and group root, then the attacker will succeed in making Phusion Passenger write files and create subdirectories inside that target directory. It is fixed in upstream version 4.0.33. https://github.com/phusion/passenger/commit/34b1087870c2bf85ebfd72c30b78577e10ab9744 One thing to notice, however, is that there's a race condition between the stat check introduced in 34b1087870c2. The following sequence still triggers the bogus behaviour: user mkdir $dir phusion lstat() (getFileTypeNoFollowSymlinks) user rmdir $dir user ln -s /target $dir phusion stat() (from verifyDirectoryPermissions) Upstream has now fixed this with the following commit (basically using the structure from lstat() for the two checks): https://github.com/phusion/passenger/commit/94428057c602da3d6d34ef75c78091066ecac5c0 Use CVE-2014-1831 for the vulnerability with the before 4.0.33 affected versions. Use CVE-2014-1832 for the vulnerability with the 4.0.33 and earlier affected versions. This is an unusual situation because it depends on a decision about whether the fix in version 4.0.33 solves part of the problem or addresses one of the threat models. It also depends on whether two CVEs should be used to cover a set of reports that are only relevant to symlink attacks, but arguably have different flaw types. CVE-2014-1831 requires the ability to create a symlink but apparently does not require the ability to conduct the described race-condition attack. The attacker could lack direct shell access, but have some type of slow or limited access to the system. This could potentially involve the ability to upload and run scripts that can create symlinks but can't execute arbitrary commands or code. Alternatively, the attacker could have access to a file manager with the same constraints. Also, in some cases, multiple CVEs are used in the case of a single original report of a symlink-handling problem, e.g., CVE-2008-1569 and CVE-2008-1570. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJS6l9uAAoJEKllVAevmvmsj9oH/RlmH2kO7M1WIIvuD3FlH1SD Fe0bqmWlVQRR77Q61IS7trfCd88sSTiyWZAm7g8EJn6Prct6AGAIH1tE0EaPbzm1 VrCcxPXJh22LPDNv0p+4ug9CjjWLVhj8cHP/T50M5bgRbbj/EKF4CbkHsDxdLtf8 crpDsvQVTZLS2d2460tCe3gjVk0Ew2bP99PgW0p7NHz4IbbwL2mX/1L0shUqMnkB UAJW1YSU1n5sAX37iz49Neyw5ptqrXsFcZNvqyuW5ch+LBnMKg8fcgg6t78ATqBE 1bw1HMSPyXhmmajk1ED/+8qc4+wMe0/iqItiVQQTO/JqL3qMGr+1rmGbLkPH43U= =5HHG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737085: apt: Apt downloads arch all packages from wrong repo/checks wrong checksum
On Thu, Jan 30, 2014 at 12:27:21PM +, Wookey wrote: +++ Julian Andres Klode [2014-01-30 08:12 +0100]: On Thu, Jan 30, 2014 at 03:13:16AM +, Wookey wrote: Package: apt Version: 0.9.15 Severity: important In the sources I have my own bootstrap repository containing a lot of (unstable) packages built for arm64, and plain debian unstable and saucy repos apt-get install arch-all-package (that is available in all 3 repos) results in a size mismatch error. It seems that apt is using the checksum from one repo but downloading the package from another. The packages used is just an example it seems to be the same for any arch all package (debian-arm64)# apt-cache policy x11proto-scrnsaver-dev x11proto-scrnsaver-dev: Installed: (none) Candidate: 1.2.2-1 Version table: 1.2.2-1 0 500 http://people.debian.org/~wookey/bootstrap/debianrepo2/ debianstrap/main arm64 Packages 500 http://ftp.uk.debian.org/debian/ unstable/main amd64 Packages 500 http://ports.ubuntu.com/ubuntu-ports/ saucy/main arm64 Packages Right, and that's a problem, as having two different packages with the same version is not really supported. APT differentiates packages with the same version by CRC-16 hashing the fields Installed-Size Depends Pre-Depends Conflicts Breaks Replaces in order to handle packages where those are the same APT would need to hash size or SHA hash as well, but this fails for installed packages, as this information is not provided in /var/lib/dpkg/status. OK. That makes sense. I see what's going on now. Which of course if why we do -B builds for other architectures and carefully ensure there is only one copy of the arch all packages. The problem is that in order to debootstrap you need all the packages in one repo so leaving the arch all packages in ftp.uk.debian.org means you can't debootstrap if you only uploaded the new-arch 'any' packages to the 'bootstrap' repo. It's also important to test that the arch-all build actually works, and not just the arch-any part so doing those builds and testing the results can be good. A work around might be to reorder sources.list entries. The order of those entries determines from which source a package is retrieved, I believe the first match takes precedence. It's fine for apt to consider these packages to be functionally equivalent, but it does need to check the correct checksum on download. It seems to me that this can be fixed by either adding size/hash to the hash as you suggest(making them 'different packages', or just separately ensuring that the checksum for the repo/file that was downloaded is used. Apt knows that there is more than one repo source for this package, but doesn't record that there might be more than one checksum? The fact that it can end up choosing one checksum and another source does seem wrong. Perhaps the code/object structure makes it hard to fix this this way and your fix is the only one that makes sense? It seems right to me in this case, because otherwise functional aspects like dependencies could differ as well. And if APT uses the dependencies from one source and then fetches the package from another source, but that one has different dependencies, installing it would produce an error. An alternative would be to change the cache-building algorithms to look at SHA hashes and/or size and create different version entries in the cache if they are present in both versions, but different. SHA Hashes would require all repositories to use the same best checksum algorithm. I think just adding size to the hash would be cheap and easy and would largely solve this problem. Adding the hash would cover a few extra cases where the size came out the same too, but if it's difficult I'd be happy to have this mostly-solved, as it's a situation we normally try to avoid anyway. Adding the size to the hash is not possible, as dpkg does not store the size for installed packages. This would mean that an installed package always has a different hash than an available package, causing APT to go crazy (it would try to upgrade all installed packages...). David or Michael probably have some more ideas. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Please do not top-post if possible. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
I have taken Bdale's text, reformatted it a bit, and added the GR rider and the multiple init systems rider texts. For the GR rider I used the version from my previous standalone proposal. I see Bdale has a different text in git. I'll discuss that in a moment. For the multiple init systems rider I used my original text for the first sentence and Don's formulation for the second sentence. I have also added an explicit option for declining to decide and asking the project to do it via GR. I think such an option would be much better than FD. Below is the result. This in principle results in 9 real options plus FD. I'm going to call the options by the subsets of the text they use: D DM U UM O OM V VM GR and of course FD I think we can probably leave out one of each of O OM V VM. If anyone has a preference for O and V over OM and VM please say so. I think O and V are probably sufficient for those options, as the desire to support multiple systems there is probably obvious so doesn't need saying. That would leave us with 7 real options which isn't too unmanageable. The text below is in the tc git repo. I'm going to follow up in a moment with a formal action to propose a resolution, starting the constitutional discussion period. Ian. == version D (systemD) == The default init system for Linux architectures in jessie should be systemd. == version U (Upstart) == The default init system for Linux architectures in jessie should be upstart. == version O (Openrc) == The default init system for Linux architectures in jessie should be openrc == version V (sysVinit) == The default init system for Linux architectures in jessie should be sysvinit (no change). == version GR (General Resolution) == The Technical Committee requests that the project decide the default init system for jessie by means of General Resolution. == optional rider M (Multiple init systems) == Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Where feasible, software should interoperate with non-default init systems; maintainers are encouraged to accept technically sound patches to enable interoperation, even if it results in degraded operation while running under the init system the patch enables interoperation with. == rider for all versions except GR == This decision is automatically vacated by any contrary General Resolution which passes by a simple majority. In that case the General Resolution takes effect and the whole of this TC resolution is to be taken as withdrawn by the TC, just as if the TC had explicitly withdrawn it by a subsequent TC resolution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
Ian Jackson writes (TC resolution revised draft): For the GR rider I used the version from my previous standalone proposal. I see Bdale has a different text in git. I'll discuss that in a moment. I see that Bdale has his own draft in git. The differences are: * My GR rider is different to Bdale's. Mine is more comprehensive; it specifically allows the GR to override any other part of the resolution, and that any contrary GR completely replaces the TC resolution. I think this is better. This is particularly true given that the TC resolution might include the multiple init systems wording, which ought to be overrideable too. So for that reason I have kept my version rather than Bdale's. * My options have mnemonic letters. This is going to be relevant because some of them want to have the multiple init systems version. * Formatting is a bit different. 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#737134: Keyboard in Debian 7
package: im-config I have two portable computers with Swedish keyboard layout. One is a Samsung netbook. The other one is an Acer laptop. Although installed from the same DVD-image and in the same way, the netbook always prints dead keys immediately. The other one behaves as it should. They are both installed within the same week. Before reinstallation of the netbook, the keyboard also misbehaved. This worked correctly in Debian 6. Both computers have the same configuration when it comes to the keyboard, but it seems as the netbook computer doesn't apply them correctly. -- PGP-key fingerprint: 1B30 7F61 AF9E 538A FCD6 2BE7 CED7 B0E4 3BF9 8D6C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735345: wheezy-ignore
tag 735345 + wheezy-ignore thanks I think this bug can be ignored for wheezy -- Mathieu Parent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
On 30/01/14 14:40, Ian Jackson wrote: D DM U UM O OM V VM GR and of course FD I think we can probably leave out one of each of O OM V VM. If anyone has a preference for O and V over OM and VM please say so. Couldn't it bias the outcome if votes might otherwise have been split between O and OM for example? And so better to leave them in? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737135: munin: Missing Recommends/Suggests libcgi-fast-perl
Package: munin Version: 2.0.19-3 Severity: normal CGI mode is recommended these days (although not the default), but doesn't work without libcgi-fast-perl installed. I got this: [Thu Jan 30 14:41:38 2014] [error] [client 41.85.12.90] Can't locate CGI/Fast.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl) at /usr/lib/munin/cgi/munin-cgi-html line 30. [Thu Jan 30 14:41:38 2014] [error] [client 41.85.12.90] BEGIN failed--compilation aborted at /usr/lib/munin/cgi/munin-cgi-html line 30. [Thu Jan 30 14:41:38 2014] [error] [client 41.85.12.90] Premature end of script headers: munin-cgi-html I think a Recommends or even Suggests would be useful. SR -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.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#678464: xplanet should be upgraded to 1.3.0 to read JPL files
This is a +1 on this bug. Please see http://xplanet.sourceforge.net/FUDforum2/index.php?t=msgth=614. Currently xplanet 1.2.1 on Debian (and Ubuntu) is unable to read even the older JPL DE405 files. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Bug#727708: TC resolution revised draft
Ian Jackson writes (TC resolution revised draft): I'm going to follow up in a moment with a formal action to propose a resolution, starting the constitutional discussion period. I hereby formally propose what I have called UM (text below). I also hereby formally propose DM as an amendment, but do not accept it. After I hear from other TC members on the merits of O vs OM and V vs VM, I will propose but not accept one of each, unless someone else gets there first. I suggest that those TC members who prefer to leave out the comments about supporting multiple init systems propose D and/or U. That will leave us voting on (most likely): Dsystemd default in jessie, say nothing about multiple inits DM systemd default in jessie, support multiple inits Usystemd default in jessie, say nothing about multiple inits UM systemd default in jessie, support multiple inits Oopenrc default in jessie Vsysvinit default in jessie GR project should decide via GR FD further discussion We should see what people say by email and at the meeting, but unless people disagree I think it would be sensible to have a formal discussion period of about a week. That would have us starting the vote on the 6th of February. Is everyone available to vote then ? Thanks, Ian. == version D (systemD) == The default init system for Linux architectures in jessie should be systemd. == version U (Upstart) == The default init system for Linux architectures in jessie should be upstart. == version O (Openrc) == The default init system for Linux architectures in jessie should be openrc == version V (sysVinit) == The default init system for Linux architectures in jessie should be sysvinit (no change). == version GR (General Resolution) == The Technical Committee requests that the project decide the default init system for jessie by means of General Resolution. == optional rider M (Multiple init systems) == Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Where feasible, software should interoperate with non-default init systems; maintainers are encouraged to accept technically sound patches to enable interoperation, even if it results in degraded operation while running under the init system the patch enables interoperation with. == rider for all versions except GR == This decision is automatically vacated by any contrary General Resolution which passes by a simple majority. In that case the General Resolution takes effect and the whole of this TC resolution is to be taken as withdrawn by the TC, just as if the TC had explicitly withdrawn it by a subsequent TC resolution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737090: [Pkg-ime-devel] Bug#737090: Bug#737090: ibus-pinyin: Perhaps need pinyin database
control: clone 737090 -1 control: severity -1 important control: reassign -1 libpyzy control: retitle -1 Please include pyzy-database-1.0.0 Let's keep grave for 737090 to prevent testing migration. Considering urgent situation of fixing this 737090 bug; So they include pyzy-database-1.0.0.tar.bz2 . Considering this database may be arch-indep. We may be better off packaging separately. Official upstream: https://code.google.com/p/pyzy/downloads/detail?name=pyzy-database-1.0.0.tar.bz2 https://pyzy.googlecode.com/files/pyzy-database-1.0.0.tar.bz2 https://code.google.com/p/pyzy/downloads/detail?name=pyzy-0.1.0.tar.gz https://pyzy.googlecode.com/files/pyzy-0.1.0.tar.gz (Although this is not pkg-ime package but considering people inviolved and archive used, i hope it is OK to include it into pkg-ime. * Tue May 28 2013 Peng Wu p...@redhat.com - 0.1.0-6 - Obsoletes ibus-pinyin-db I propose 2 step approach: Step 1, upload libpyzy with pyzy-database-1.0.0 Step 2, split libpyzy into libpyzy and pyzy-database let libpyzy depend on pyzy-database (For size, this is better) Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735162: xml-security-c: FTBFS on hurd-i386
On Thu, 2014-01-30 at 14:58 +0100, Ferenc Wagner wrote:
Svante Signell svante.sign...@gmail.com writes:
The attached patch fixes this problem by adding a check in
configure.ac for a working path = getcwd(NULL, 0) allocating the
string length required dynamically, and freed later on. Similarly the
string baseURI is malloced and freed.
I can see the freeing of baseURI, but not that of path.
I'd say it's leaked. Or do I miss something here?
Damn, I updated the patch, viewed it in gedit and still the old patch
was there. Attached is the correct one.
Thanks!
---
configure.ac | 11 +++
xsec/tools/checksig/checksig.cpp | 17 -
xsec/tools/cipher/cipher.cpp | 17 -
xsec/tools/templatesign/templatesign.cpp | 17 -
xsec/tools/txfmout/txfmout.cpp | 18 --
5 files changed, 59 insertions(+), 21 deletions(-)
--- a/configure.ac
+++ b/configure.ac
@@ -73,6 +73,17 @@ AC_CHECK_HEADERS(unistd.h direct.h)
AC_CHECK_DECL(strcasecmp,[AC_DEFINE([XSEC_HAVE_STRCASECMP],[1],[Define to 1 if strcasecmp present.])],,[#include string.h])
+# Check for required functionality
+AC_MSG_CHECKING([whether getcwd(NULL, 0) works])
+AC_RUN_IFELSE([AC_LANG_PROGRAM([#include stdlib.h
+ #include unistd.h],
+ [char *cwd = getcwd(NULL, 0);
+ return (cwd != NULL) ? EXIT_SUCCESS : EXIT_FAILURE;])],
+ [AC_MSG_RESULT(yes)
+ AC_DEFINE([HAVE_GETCWD_DYN], [1],
+ [Define to 1 if getcwd(NULL, 0) works])],
+ [AC_MSG_RESULT(no)])
+
AC_LANG(C++)
# Xerces is required
--- a/xsec/tools/checksig/checksig.cpp
+++ b/xsec/tools/checksig/checksig.cpp
@@ -57,7 +57,6 @@
#if defined(HAVE_UNISTD_H)
# include unistd.h
-# define _MAX_PATH PATH_MAX
#else
# if defined(HAVE_DIRECT_H)
# include direct.h
@@ -438,10 +437,14 @@ int evaluate(int argc, char ** argv) {
AnonymousResolver theAnonymousResolver;
// Map out base path of the file
- char path[_MAX_PATH];
- char baseURI[(_MAX_PATH * 2) + 10];
- getcwd(path, _MAX_PATH);
-
+#if HAVE_GETCWD_DYN
+ char *path = getcwd(NULL, 0);
+ char *baseURI = (char*)malloc(strlen(path) + 8 + 1 + strlen(filename) + 1);
+#else
+ char path[PATH_MAX];
+ char baseURI[(PATH_MAX * 2) + 10];
+ getcwd(path, PATH_MAX);
+#endif
strcpy(baseURI, file:///);
// Ugly and nasty but quick
@@ -471,6 +474,10 @@ int evaluate(int argc, char ** argv) {
XMLCh * baseURIXMLCh = XMLString::transcode(baseURI);
XMLUri uri(MAKE_UNICODE_STRING(baseURI));
+#if HAVE_GETCWD_DYN
+ free(path);
+ free(baseURI);
+#endif
if (useAnonymousResolver == true) {
// AnonymousResolver takes precedence
--- a/xsec/tools/cipher/cipher.cpp
+++ b/xsec/tools/cipher/cipher.cpp
@@ -60,7 +60,6 @@
#if defined(HAVE_UNISTD_H)
# include unistd.h
-# define _MAX_PATH PATH_MAX
#else
# if defined(HAVE_DIRECT_H)
# include direct.h
@@ -639,10 +638,14 @@ int evaluate(int argc, char ** argv) {
if (useInteropResolver == true) {
// Map out base path of the file
-char path[_MAX_PATH];
-char baseURI[(_MAX_PATH * 2) + 10];
-getcwd(path, _MAX_PATH);
-
+#if HAVE_GETCWD_DYN
+char *path = getcwd(NULL, 0);
+char *baseURI = (char*)malloc(strlen(path) + 8 + 1 + strlen(filename) + 1);
+#else
+char path[PATH_MAX];
+char baseURI[(PATH_MAX * 2) + 10];
+getcwd(path, PATH_MAX);
+#endif
strcpy(baseURI, file:///);
// Ugly and nasty but quick
@@ -671,6 +674,10 @@ int evaluate(int argc, char ** argv) {
baseURI[lastSlash + 1] = '\0';
XMLCh * uriT = XMLString::transcode(baseURI);
+#if HAVE_GETCWD_DYN
+free(path);
+free(baseURI);
+#endif
XencInteropResolver ires(doc, (uriT[8]));
XSEC_RELEASE_XMLCH(uriT);
--- a/xsec/tools/templatesign/templatesign.cpp
+++ b/xsec/tools/templatesign/templatesign.cpp
@@ -74,7 +74,6 @@
#if defined(HAVE_UNISTD_H)
# include unistd.h
-# define _MAX_PATH PATH_MAX
#else
# if defined(HAVE_DIRECT_H)
# include direct.h
@@ -1169,10 +1168,14 @@ int main(int argc, char **argv) {
// Map out base path of the file
char * filename=argv[argc-1];
- char path[_MAX_PATH];
- char baseURI[(_MAX_PATH * 2) + 10];
- getcwd(path, _MAX_PATH);
-
+#if HAVE_GETCWD_DYN
+ char *path = getcwd(NULL, 0);
+ char *baseURI = (char*)malloc(strlen(path) + 8 + 1 + strlen(filename) + 1);
+#else
+ char path[PATH_MAX];
+ char baseURI[(PATH_MAX * 2) + 10];
+ getcwd(path, PATH_MAX);
+#endif
strcpy(baseURI, file:///);
// Ugly and nasty but quick
@@ -1202,6 +1205,10 @@ int main(int argc, char **argv) {
theResolver-setBaseURI(MAKE_UNICODE_STRING(baseURI));
sig-setURIResolver(theResolver);
+#if HAVE_GETCWD_DYN
+ free(path);
+ free(baseURI);
+#endif
try {
sig-load();
--- a/xsec/tools/txfmout/txfmout.cpp
+++ b/xsec/tools/txfmout/txfmout.cpp
@@ -57,7 +57,6 @@
#if defined(HAVE_UNISTD_H)
# include unistd.h
-# define _MAX_PATH PATH_MAX
#else
# if defined(HAVE_DIRECT_H)
# include direct.h
@@
Bug#727708: TC resolution revised draft
Steven Chamberlain writes (Bug#727708: TC resolution revised draft): On 30/01/14 14:40, Ian Jackson wrote: D DM U UM O OM V VM GR and of course FD I think we can probably leave out one of each of O OM V VM. If anyone has a preference for O and V over OM and VM please say so. Couldn't it bias the outcome if votes might otherwise have been split between O and OM for example? And so better to leave them in? Thanks for asking, but I think not. [1] Our voting system (Condorcet with Schwartz Cloneproof Sequential Dropping) is designed to cope with that. In actual practice I'm expecting to have a single Condorcet winner in which case splitting/joining options is totally irrelevant. Ian. [1] I'm starting to feel the need to thank anyone who makes a short and non-useless contribution, even if they happen to be wrong, since there are so many unhelpful emails now and such a bad atmosphere. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737137: game-data-packager: patch to support hexdd
Package: game-data-packager
Version: 37
Severity: wishlist
Dear Maintainer,
included is a patch to support the hexen addon 'hexdd.wad'.
This patch also changes the installation folder of heretic and hexen wads
back to /usr/share/games/hexen|heretic as it was before version 30. I originally
suggested the change to put all doom engine files into /usr/share/games/doom
but I now think that was not such a good idea.
Would you consider adding the patch?
One more question: is it allowed to add support for pwads to g-d-p?
Or is there any other recommended way to get pwads packaged?
Best,
Johey
diff -uNr game-data-packager-37/doom-common/usr/share/applications/hexdd.desktop.in game-data-packager-37.patched/doom-common/usr/share/applications/hexdd.desktop.in
--- game-data-packager-37/doom-common/usr/share/applications/hexdd.desktop.in 1970-01-01 01:00:00.0 +0100
+++ game-data-packager-37.patched/doom-common/usr/share/applications/hexdd.desktop.in 2014-01-30 15:26:09.887953139 +0100
@@ -0,0 +1,9 @@
+[Desktop Entry]
+Name=LONG
+GenericName=First Person Shooter Game
+TryExec=ENGINE
+Exec=ENGINE -iwad /usr/share/games/ENGINE/hexen.wad -file /usr/share/games/ENGINE/hexdd.wad
+Icon=GAME.xpm
+Terminal=false
+Type=Application
+Categories=Game
diff -uNr game-data-packager-37/doom-common.mk game-data-packager-37.patched/doom-common.mk
--- game-data-packager-37/doom-common.mk 2013-10-13 22:58:10.0 +0200
+++ game-data-packager-37.patched/doom-common.mk 2014-01-30 15:00:46.383630600 +0100
@@ -42,9 +42,15 @@
$@
build/$(IWAD)-wad/usr/share/applications/$(IWAD)-wad.desktop:
- m4 -DGAME=$(IWAD) -DLONG=$(LONG) -DENGINE=$(GAME) \
- doom-common/usr/share/applications/doom-common.desktop.in \
- $@
+ if [ $(IWAD) = hexdd ] ; then \
+ m4 -DGAME=hexen -DLONG=$(LONG) -DENGINE=$(GAME) \
+ doom-common/usr/share/applications/hexdd.desktop.in \
+ $@ ; \
+ else \
+ m4 -DGAME=$(IWAD) -DLONG=$(LONG) -DENGINE=$(GAME) \
+ doom-common/usr/share/applications/doom-common.desktop.in \
+ $@ ; \
+ fi
build/$(IWAD)-wad/DEBIAN/preinst:
m4 -DIWAD=$(IWAD).wad \
diff -uNr game-data-packager-37/hexdd/DEBIAN/control.in game-data-packager-37.patched/hexdd/DEBIAN/control.in
--- game-data-packager-37/hexdd/DEBIAN/control.in 1970-01-01 01:00:00.0 +0100
+++ game-data-packager-37.patched/hexdd/DEBIAN/control.in 2014-01-30 14:33:20.787522733 +0100
@@ -0,0 +1,13 @@
+Package: PACKAGE
+Section: non-free/games
+Priority: optional
+Architecture: all
+Depends: hexen-wad
+Provides: GAME-wad
+Installed-Size: 56
+Version: VERSION
+Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org
+Description: Hexen: Deathkings of the Dark Citadel
+ This expansion pack requires both a hexen-engine and a hexen-wad to play.
+ This package contains add-on levels to Raven Software's game hexen
+ and was generated using the game-data-packager program.
diff -uNr game-data-packager-37/lib/doom-common game-data-packager-37.patched/lib/doom-common
--- game-data-packager-37/lib/doom-common 2013-10-13 22:58:10.0 +0200
+++ game-data-packager-37.patched/lib/doom-common 2014-01-30 15:42:19.040182483 +0100
@@ -18,7 +18,9 @@
debug checksum = $CHECKSUM
}
-WADDIR=/usr/share/games/doom
+set +u
+[ -n $WADDIR ] || WADDIR=/usr/share/games/doom
+set -u
DEB=$DATADIR/$DEBBASE
go() {
diff -uNr game-data-packager-37/Makefile game-data-packager-37.patched/Makefile
--- game-data-packager-37/Makefile 2013-11-18 20:32:13.0 +0100
+++ game-data-packager-37.patched/Makefile 2014-01-30 15:00:02.099629764 +0100
@@ -13,11 +13,14 @@
make -f doom-common.mk IWAD=plutonia \
LONG=Final Doom: The Plutonia Experiment VERSION=$(VERSION)
make -f doom-common.mk IWAD=heretic VERSION=$(VERSION) \
- CONTROLIN=heretic/DEBIAN/control.in \
+ CONTROLIN=heretic/DEBIAN/control.in GAME=heretic \
LONG=Heretic: Shadow of the Serpent Riders
make -f doom-common.mk IWAD=hexen VERSION=$(VERSION) \
- CONTROLIN=hexen/DEBIAN/control.in \
+ CONTROLIN=hexen/DEBIAN/control.in GAME=hexen \
LONG=Hexen: Beyond Heretic
+ make -f doom-common.mk IWAD=hexdd VERSION=$(VERSION) \
+ CONTROLIN=hexdd/DEBIAN/control.in GAME=hexen \
+ LONG=Hexen: Deathkings of the Dark Citadel
make -f quake.mk LONG=Quake VERSION=$(VERSION) PACKAGE=quake-registered \
FOLDER=id1
make -f quake.mk LONG=Quake music VERSION=$(VERSION) \
@@ -59,11 +62,14 @@
make -f doom-common.mk IWAD=plutonia \
LONG=Final Doom: The Plutonia Experiment VERSION=$(VERSION) clean
make -f doom-common.mk IWAD=heretic VERSION=$(VERSION) \
- CONTROLIN=heretic/DEBIAN/control.in \
+ CONTROLIN=heretic/DEBIAN/control.in GAME=heretic \
LONG=Heretic: Shadow of the Serpent Riders clean
make -f doom-common.mk IWAD=hexen VERSION=$(VERSION) \
- CONTROLIN=hexen/DEBIAN/control.in \
+ CONTROLIN=hexen/DEBIAN/control.in GAME=hexen \
LONG=Hexen: Beyond Heretic clean
+ make -f doom-common.mk IWAD=hexdd VERSION=$(VERSION) \
+ CONTROLIN=hexdd/DEBIAN/control.in GAME=hexen \
+ LONG=Hexen:
Bug#716723: sasl2-bin: subprocess installed post-installation script returned error exit status 1
package sasl2-bin tags 716723 + moreinfo thanks On Thu, Jul 11, 2013 at 10:36:40PM +0200, Johannes Schlumberger wrote: Configuring sasl2-bin Failed to upgrade /etc/sasldb2 The /etc/sasldb2 file could not be upgraded to the new database format. This is a fatal error and will cause the package installation to fail. Johannes, I am going through the bugs against cyrus-sasl2 and trying to resolve as many as possible. Is there any chance you can provide the offending /etc/sasldb2 file? If that is not possible, can you fabricate a minimal /etc/sasldb2 that can be used to reproduce the problem? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#737138: RFP: routeconverter -- RouteConverter is a free, user friendly GPS tool to display, edit, enrich and convert routes, tracks and waypoints.
Package: wnpp Severity: wishlist * Package name: routeconverter Version : 2.11 * URL : http://www.routeconverter.de/home/en * License : GPL Programming Lang: Java Description : RouteConverter is a free, user friendly GPS tool to display, edit, enrich and convert routes, tracks and waypoints. It helps me to plan routes and consolidate tracks and I hope it could help you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737085: apt: Apt downloads arch all packages from wrong repo/checks wrong checksum
+++ Julian Andres Klode [2014-01-30 15:42 +0100]: On Thu, Jan 30, 2014 at 12:27:21PM +, Wookey wrote: +++ Julian Andres Klode [2014-01-30 08:12 +0100]: On Thu, Jan 30, 2014 at 03:13:16AM +, Wookey wrote: Package: apt Version: 0.9.15 Severity: important In the sources I have my own bootstrap repository containing a lot of (unstable) packages built for arm64, and plain debian unstable and saucy repos apt-get install arch-all-package (that is available in all 3 repos) results in a size mismatch error. It seems that apt is using the checksum from one repo but downloading the package from another. The packages used is just an example it seems to be the same for any arch all package (debian-arm64)# apt-cache policy x11proto-scrnsaver-dev x11proto-scrnsaver-dev: Installed: (none) Candidate: 1.2.2-1 Version table: 1.2.2-1 0 500 http://people.debian.org/~wookey/bootstrap/debianrepo2/ debianstrap/main arm64 Packages 500 http://ftp.uk.debian.org/debian/ unstable/main amd64 Packages 500 http://ports.ubuntu.com/ubuntu-ports/ saucy/main arm64 Packages Right, and that's a problem, as having two different packages with the same version is not really supported. OK. That makes sense. I see what's going on now. The problem is that in order to debootstrap you need all the packages in one repo so leaving the arch all packages in ftp.uk.debian.org means you can't debootstrap if you only uploaded the new-arch 'any' packages to the 'bootstrap' repo. It's also important to test that the arch-all build actually works, and not just the arch-any part so doing those builds and testing the results can be good. A work around might be to reorder sources.list entries. The order of those entries determines from which source a package is retrieved, I believe the first match takes precedence. Ha. That does indeed provide a working workaround :-) Moving the repo that the 'all' packages are being download from, to the top of the list makes it work. so moving ftp.uk.debian.org above p.d.o/~wookey/bootstrap # apt-cache policy x11proto-scrnsaver-dev x11proto-scrnsaver-dev: Installed: 1.2.2-1 Candidate: 1.2.2-1 Version table: *** 1.2.2-1 0 550 http://ftp.uk.debian.org/debian/ unstable/main amd64 Packages 1001 http://people.debian.org/~wookey/bootstrap/debianrepo2/ debianstrap/main arm64 Packages 500 http://ports.ubuntu.com/ubuntu-ports/ saucy/main arm64 Packages 100 /var/lib/dpkg/status means that both downloads and checksums come from ftp.uk.debian.org I'll use it like this for a bit and see if it always works, or just sometimes :-) This isn't really any sort of actual 'solution', but it's a very handy suggestion. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737132: Regression: wheezy initrd loads md raids only if defined on mdadm.conf even with INITRDSTART='all'
30.01.2014 17:45, Fabio Fantoni wrote: Package: mdadm Version: 3.2.5-5 Severity: normal I'm attempting to restore a backup of a root partition on a set of brand new disks (md raid1). On Wheezy, initramfs doesn't show md devices if they are not defined in /etc/mdadm/mdadm.conf even if on /etc/default/mdadm there is INITRDSTART='all'. Such problem may be caused by a regression (squeezy or wheezy) because on lenny I've been always did such task without problem. [] Personalities : [raid1] md1 : active raid1 sda3[0] sdb3[1] 72610624 blocks super 1.2 [2/2] [UU] With 1.x superblock, the term all actually refers to all arrays belonging to this host, which has current hostname recorded in the superblock (1.x format superblock has a place for homehost field, while 0.90 format didn't have this field). Previously, mdadm really tried to assemble any arrays found, but this turned out to be wrong. For example, when you insert hard drives from another system for recovery of broken raid/filesystem, mdadm should NOT assemble arrays from there by default, because this way we've a high risk of breaking stuff further. Please ensure that you have the right homehost in your raid arrays (mdadm -D will tell you), and -- the second part of the picture -- that this hostname is set correctly inside initrd when mdadm is run. Please note also that modern mdadm will try to check homehost even for 0.90 superblocks, by doing some magic with the array UUID. If your arrays were created by sufficiently recent mdadm, the UUID has some bits of homehost mixed in. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737139: gnome-keyring: Adobe AIR 2.6 runtime can't find gnome-keyring
Package: gnome-keyring Version: 3.4.1-5 Severity: normal Dear Maintainer, Adobe AIR 2.6 runtime can't install untill # ln -s /usr/lib/i386-linux-gnu/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so.0 # ln -s /usr/lib/i386-linux-gnu/libgnome-keyring.so.0.2.0 /usr/lib/libgnome-keyring.so.0.2.0 solution found at: http://www.clarifylinux.org/2012/04/ubuntu-1204-tweak-and-hack-round-up.html Thank you for great work!:) Greg. -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-keyring depends on: ii dbus-x11 1.6.8-1+deb7u1 ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii gcr 3.4.1-3 ii libc62.13-38 ii libcap-ng0 0.6.6-2 ii libcap2-bin 1:2.22-1.2 ii libdbus-1-3 1.6.8-1+deb7u1 ii libgck-1-0 3.4.1-3 ii libgcr-3-1 3.4.1-3 ii libgcrypt11 1.5.0-5+deb7u1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgtk-3-0 3.4.2-7 Versions of packages gnome-keyring recommends: ii libpam-gnome-keyring 3.4.1-5 gnome-keyring 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#717613: systemd-udevd failes to execute /lib/udev/socket:@/org/freedesktop/hal/udev_event
This is crazy and scary. Affects me too. The system is hardly a year old, first Wheezy then dist-upgraded to Testing. Hal was NOT manually installed. I know what prehistoric artifact HAL is, but the thing is - it was pulled as dependency at some regular update. Indeed, the hal somehow was in the system...! Thanks a lot for reporting and pointing it out. Why doesn't Debian have clear distinction between must-keep/relevant packages and the rest/non-relevant? It sure has manually installed group, but user could manually install because it was dependency of one must-keep package and can be safely purged if must-keep is gone. Apt-pinning isn't the case, because we don't want to pin version, we want to pin the package in system, as explicitly to stay in the system as of relevance to the user. Manually installed is also very vague definition, as displayed earlier. I am not debian developer, nor can code. I wish someone proposed something like that. Thanks!
Bug#722494: Bug #722494
On Thu, Jan 30, 2014 at 11:02:42AM +, Colin Tuckley wrote: Patrick, Did you see my comment on this bug? The upstream dev is concerned about people not being able to get cqrlog working. Colin Colin, While I appreciate upstream's concern, having MySQL *installed on the same machine* is not a requirement for it to run. This seems to me to be a case for Recommends rather than Depends From the policy manual: Recommends This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. The upstream includes this on the cqrlog website's download page: The binaries should work in any distribution. Please don't forget to install MySQL server, MySQL client, Hamlib libraries and if LoTW support is desired, trustedqsl package and libssl-devel must be installed. If the upstream was truly concerned about the software just working he would embed the database server in the cqrlog tarball (reference MythTV's treatment of FFMPEG) and it would all just install at once. An example from a similar case in Ubuntu - MythTV. The MythTV application is non-functional without a MySQL database server running on the local network. None of the MythTV functional packages depend on the MySQL server package, just mysql-client. (The meta-package MythTV does depend on the MySQL server) With the current Debian package, I can not install cqrlog on my shack machine without either accepting a lot of wasted space/time (installing MySQL on the box and then configuring it not to run or allowing it to run on the shack box sucking up resources) or using force-depends vodoo to make cqrlog install this one time without pulling in MySQL - and then having to remember to do this in the future so and update/upgrade doesn't pull MySQL back in. Pat -- ,-. Patrick Ouellette | While you are proclaiming peace with your lips, pat(at)flying-gecko.net | be careful to have it even more fully in your Amateur Radio: NE4PO| heart. -- Francis of Assisi `-' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Cut-and paste typo
Svante Signell writes (Bug#727708: Cut-and paste typo): I think you made a c-p typo, see below: That will leave us voting on (most likely): Dsystemd default in jessie, say nothing about multiple inits DM systemd default in jessie, support multiple inits Usystemd default in jessie, say nothing about multiple inits ^upstart UM systemd default in jessie, support multiple inits ^upstart Oopenrc default in jessie Vsysvinit default in jessie GR project should decide via GR FD further discussion Otherwise the voting would (almost) not be needed! *rotfl* You are of course entirely right. Here's the revised table Dsystemd default in jessie, say nothing about multiple inits DM systemd default in jessie, support multiple inits Uupstart default in jessie, say nothing about multiple inits UM upstart default in jessie, support multiple inits Oopenrc default in jessie Vsysvinit default in jessie GR project should decide via GR FD further discussion 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#633582: initramfs-tools: All files in initrd owned by root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/30/2014 11:31 AM, Michael Prokop wrote: [Adding Harald Hoyer from dracut to CC, maybe he can enlighten us about the reasoning in dracut. Harald, this is about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633582 which I'm also quoting in the following mail ] * Teddy Hogeborn [Thu Jan 30, 2014 at 10:35:56AM +0100]: intrigeri intrig...@boum.org writes: Michael Prokop wrote (23 Nov 2011 11:45:14 GMT) : maximilian: i've scheduled the patch for inclusion via mika/user_permissions. Was this included eventually? No. We have, for two years now, a very ugly workaround in mandos-client to deal with this. Maks, please report back what's your opinion how to handle that. FTR, that's what dracut uses (latest git as of today): , [ dracut.sh ] | if [[ $create_early_cpio = yes ]]; then | echo 1 $early_cpio_dir/d/early_cpio | # The microcode blob is _before_ the initramfs blob, not after | (cd $early_cpio_dir/d; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet ../early.cpio) | mv $early_cpio_dir/early.cpio $outfile.$$ | fi | if ! ( umask 077; cd $initdir; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet | \ ` And see: , [ dracut.git % git show 8e5db363 ] | commit 8e5db363e8c14f2964fe71100f3dcd7f912ca283 | Author: Harald Hoyer har...@redhat.com | Date: Fri Jan 24 15:27:15 2014 +0100 | | dracut.sh: set file owners of early cpio files to 0:0 | | diff --git a/dracut.sh b/dracut.sh | index 2142e2d..0970710 100755 | --- a/dracut.sh | +++ b/dracut.sh | @@ -1464,10 +1464,10 @@ rm -f -- $outfile | dinfo *** Creating image file *** | if [[ $create_early_cpio = yes ]]; then | # The microcode blob is _before_ the initramfs blob, not after | -(cd $early_cpio_dir/d; find . -print0 | cpio --null -o -H newc --quiet ../early.cpio) | +(cd $early_cpio_dir/d; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet ../early.cpio) | mv $early_cpio_dir/early.cpio $outfile.$$ | fi | -if ! ( umask 077; cd $initdir; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet| \ | +if ! ( umask 077; cd $initdir; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet | \ | $compress $outfile.$$; ); then | dfatal dracut: creation of $outfile.$$ failed | exit 1 ` So there might be a good reason why also dracut goes for all files in initrd owned by root. Harald, do you have any bug reports or details about why dracut decided to handle it this way that you might share with us? regards, -mika- Initially it was done to prevent user (uid!=0) generated initramfs images to accidentally produce static device nodes owned by that user. But you are right, we should preserve the owners, if root builds the image. So, here is the upstream commit for dracut: http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=c8a9a6b4a7dff76c66e84f65b2717632e1bb4505 Thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS6nGjAAoJEANOs3ABTfJwTsEP/1Xsq6A0v8oMrQOW1zMrcVq/ YOsp+qQxzEIE1xIMjm7aNYmuA5NMtlDLZL1wFrjqZ44P1oDyiDjmV6TdNcntZQAL NLXjOk144A8FdLt+FMOdgu0cKo67JMo7uc7dRFSq57FKuvNOR1pKncybtN40q8w2 Gg+139bQGxbh5K1E4W5a01LxinyLK7EZMIdQR/+JCFoQsJoCwjXTJTzC8LTRmvc1 ZXT3CD5expvX9oSqpzvUCKqLp/5rC4Uxb7rzc0qq7jP4qMdAjObwUlBqdxrOLnn5 7FTCC19yVP9Xx6moLBpzjXti6Q3M9DPXdhnuLHf9VFOqlZF+dOZCDrQomjnzUG7L 1cICRD9k5mzZSHulviuAXElouVpaI4UgJJwkYz8Xj1uqxm8jHiT6dEly19DYSdrt L84NzTnc/HJwVZ43+xFBti2iJy6auTXrMn+YrkF7x96Q0UST5qUe8lZdfi5fboHv 5KVbqhXJNRzes2tDMSbotN94obD0tHwhcXKe+14CXmheuoPrM2DfmDCOrpl2ntSh epfCGJcUbb82Iock/WDvQuaGifG3oBGb1o7Erz+AQ72Hcy4y5yWywlNSD62NB/S3 OoFs1MDUmfN4iPcm1SSp2VvmKK9dZ2dEMQjGQ2x8qfzAy/4KpqbTu//CvmH6K2Nv KBkUmYtC8jBabs1TZurT =gZvp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737140: Assumes zpool member devices reside directly in /dev
Package: grub-pc
Version: 2.02~beta2-6
Severity: normal
Tags: upstream
Hi,
grub-probe --target=device / calls zpool status to determine what
devices a zpool consists of.
Unfortunately zpool status only prints nicknames for devices, for example:
# zpool status
pool: sealynx
state: ONLINE
see: http://zfsonlinux.org/msg/ZFS-8000-EY
scan: none requested
config:
NAMESTATE READ
WRITE CKSUM
sealynx ONLINE 0
0 0
mirror-0 ONLINE 0
0 0
scsi-SATA_Hitachi_HUA7220_JPW9P0N007TZ5D-part3 ONLINE 0
0 0
scsi-SATA_Hitachi_HUA7220_JPW9P0N00AZ49D-part3 ONLINE 0
0 0
logs
mirror-1 ONLINE 0
0 0
scsi-SATA_SAMSUNG_MZ7WD12S16KNEAD700746-part3 ONLINE 0
0 0
scsi-SATA_SAMSUNG_MZ7WD12S16KNEAD700747-part3 ONLINE 0
0 0
cache
scsi-SATA_SAMSUNG_MZ7WD12S16KNEAD700746-part4 ONLINE 0
0 0
scsi-SATA_SAMSUNG_MZ7WD12S16KNEAD700747-part4 ONLINE 0
0 0
In this case, the pool was assembled using device names from
/dev/disks/by-id, but grub-probe assumes they are under /dev and fails:
grub-probe: error: failed to get canonical path of
`/dev/scsi-SATA_Hitachi_HUA7220_JPW9P0N007TZ5D-part3'.
Additionally, for non-online devices, the output of zpool status is likely
completely useless to grub-probe. I'm not sure if you're already filtering
those out, but if not, you should.
I suppose something like the following could be used to obtain the
canonical device names:
zpool status $poolname \
| sed -n '/^[[:space:]]*NAME[[:space:]]*STATE[[:space:]]/,${
/ ONLINE /s/^[[:space:]]*//;
s/[[:space:]]*ONLINE[[:space:]]*[0-9]*[[:space:]]*[0-9]*[[:space:]]*[0-9]*[[:space:]]*$//p
}' \
| while read candidate; do
devlink=$(find /dev -name $candidate | head -n 1)
if [[ -e $devlink ]]; then
[[ -b $(readlink -f $devlink) ]] readlink -f
$devlink
fi
done
This still has problems (for example, it assumes that the first match in
/dev for any of the names printed by zpool status will be either the
relevant block device or a symlink to it), but I'm not sure it's possible or
necessary to do much better.
Ideally, zpool should be patched so that it can print device paths, not just
device names.
Andras
--
Both of his feet are firmly planted in the air.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721181: Some information on this subject.
I found this information related to this subject: https://bugs.eclipse.org/bugs/show_bug.cgi?id=386955 http://permalink.gmane.org/gmane.comp.lib.cairo/23403 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737142: seabios: PC-BSD 10.0-RELEASE installer does not boot (kernel trap 12 with interrupts disabled)
Package: seabios Version: 1.7.4-1 Severity: normal Dear Maintainer, PC-BSD 10.0 Release installer does not boot on qemu. Please see attached screenshot. downgrade seabios to 1.7.3-3 fix problem. Best Regards, Kouichi ONO -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13.0-dirty (SMP w/12 CPU cores; PREEMPT) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- debconf-show failed inline: Screenshot_pcbsd-1_2014-01-30_22:52:03.png
Bug#737143: Please add patch for module loading
Package: fuse Version: 2.9.2-4 Severity: normal Tags: patch Hi, loading modules in fuse filesystems is broken when fuse is compiled with -O2. Please add the patch for this from the fuse mailinglist: http://sourceforge.net/mailarchive/forum.php?thread_name=CAB6Q1a8ER1O%2B8NaQEQg7vzaVdNC0EShGO4sbKj%2BbYJVPyeASmw%40mail.gmail.comforum_name=fuse-devel MfG Goswin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages fuse depends on: ii adduser 3.113+nmu3 ii libc6 2.17-92+b1 ii libfuse2 2.9.0-2+deb7u1 ii makedev 2.3.1-91 ii mount 2.20.1-5.1 ii sed 4.2.1-10 ii udev 175-7.2 fuse recommends no packages. fuse suggests no packages. -- Configuration Files: /etc/fuse.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
On 2014-01-30 09:29:08, Jonas Smedegaard wrote: runtime pkgsize bloat: 0 Thanks for those measurements Jonas!! If you insist on uglifying at runtime, then I still recommend compacting CSS at build time (300 bytes win is silly when using jQuery bloat!). If you insist on uglifying _CSS_ at runtime, then I still recommend using ruby-sass, and switch to sassc later (see bug#694733,694730). I don't insist at all, in fact I don't understand why we would compress CSS at runtime at all. For JS it makes sense because of section 4.13 (convenience copies), but the CSS is native... We could *suggest* an uglifier of some sort (and the jury's still out on that I guess) but I strongly feel we should compress at build time. Moving below /etc is a nice extra, but not entirely necessary at this stage, IMHO. A. -- Software gets slower faster than hardware gets faster. - Wirth's law pgpynziaen6cl.pgp Description: PGP signature
Bug#727708: TC resolution revised draft
Philipp Kern writes (Re: Bug#727708: TC resolution revised draft): On 2014-01-30 15:59, Ian Jackson wrote: Our voting system (Condorcet with Schwartz Cloneproof Sequential Dropping) is designed to cope with that. In actual practice I'm expecting to have a single Condorcet winner in which case splitting/joining options is totally irrelevant. I really hope you are right that it cannot be rigged. That said: How does Bdale's casting vote work with Condorcet? If there's a tie, both are in the set of winners and he'll break the tie using the order within his vote? Yes. See Constitution A.6. Thanks, Ian. (PS: I have replied to the bug. Please send messages on this subject to the bug, not just to the ctte list.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Cut-and paste typo
I think you made a c-p typo, see below: That will leave us voting on (most likely): Dsystemd default in jessie, say nothing about multiple inits DM systemd default in jessie, support multiple inits Usystemd default in jessie, say nothing about multiple inits ^upstart UM systemd default in jessie, support multiple inits ^upstart Oopenrc default in jessie Vsysvinit default in jessie GR project should decide via GR FD further discussion Otherwise the voting would (almost) not be needed! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737144: cvs2svn: FTBFS with rcs 5.9
Package: cvs2svn
Version: 2.4.0
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
I hope I'm doing this correctly.
The cvs2svn package fails to build from source with recent versions of rcs
due to a failed internal test. This is caused by the rcs v5.9 'co' command
deprecating '-V' in favor of '--version'. When cvs2svn executes 'co -V' to
test for its existence, co outputs a warning on stderr, which cvs2svn
mistakes for a failure.
Attached is a patch that corrects this problem, so that the package builds.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Subject: Use --version instead of obsolete -V to check for co's existence
The --use-rcs option uses 'co -V' to verify that co exists. However, recent
versions of rcs produce a warning on stderr to use --version instead; this
causes a false negative, causing --use-rcs to fail.
Author: Stephen Oberholtzer ste...@qrpff.net
--- a/cvs2svn_lib/rcs_revision_manager.py
+++ b/cvs2svn_lib/rcs_revision_manager.py
@@ -29,7 +29,7 @@
def __init__(self, co_executable):
self.co_executable = co_executable
try:
- check_command_runs([self.co_executable, '-V'], self.co_executable)
+ check_command_runs([self.co_executable, '--version'], self.co_executable)
except CommandFailedException, e:
raise FatalError('%s\n'
'Please check that co is installed and in your PATH\n'
Bug#737139: gnome-keyring: Adobe AIR 2.6 runtime can't find gnome-keyring
Le jeudi 30 janvier 2014 à 16:18 +0100, Grzegorz Stalmierski a écrit : Adobe AIR 2.6 runtime can't install untill # ln -s /usr/lib/i386-linux-gnu/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so.0 # ln -s /usr/lib/i386-linux-gnu/libgnome-keyring.so.0.2.0 /usr/lib/libgnome-keyring.so.0.2.0 This is a bug in Adobe AIR, not in libgnome-keyring. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
Philipp Kern writes (Re: Bug#727708: TC resolution revised draft): So if we assume that upstart wins, would it be acceptable to depend on systemd (or vice versa)? We might then get a set called, say, Unity, depending on upstart and one called, say, GNOME, depending on systemd, which would not be co-installable. Maybe there should be a paragraph addressing this? I have tried to persaude my colleagues that it is necessary to exclude this possibility, but I don't seem to have succeeded. I do like the current phrasing wrt support of the non-default init system. But I don't see the question above addressed in it… You're right, it's not. Some of my proposed stronger wordings for the Multiple section do address it. However, with Russ, Bdale and Keith all saying they're opposed to having this paragraph at all, I would need the support of all the rest of the TC to include it. Hence my proposal for a compromise which Don has said he prefers to FD. (And even that may not be enough.) If you think it's important to explicitly vote on this question then I am open to putting it on the ballot. (Although the number of options starts to become rather unwieldy, in practice I expect the TC members not to have trouble ranking them.) I also don't know whether Bdale intends to use his casting vote to force a decision (and if so how far that decision will go), or whether he'll use it to acknowledge that the TC is split and punt the question to a GR. But I would guess the former. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736760: debian/upstream vs. debian/upstream/signing-key.pgp
On Thu, Jan 30, 2014 at 10:52:03AM +0900, Charles Plessy wrote: Le Wed, Jan 29, 2014 at 10:05:28PM +0100, Jan Beyer a écrit : thanks for your reply. But I'm not quite convinced that you are right, because both the recent changelog entry of devscripts and the man page of uscan talk explicitly about debian/upstream/signing-key.[asc,gpg]... Hello everybody, this is discussed in #736760, and we need to decide whether devscripts cancel their changes, or somebody organises a transition, or the DEP 12 project is cancelled. While I perfectly agree that it would have been the correct way to discuss claiming parts of the namespace first (heck, even if you do discuss changes for uscan at length like I did for Files-Excluded people raise their hands afterwards that should be implemented differently) I would volunteer to *help* (not lead) in a transition which means * reuploading files of Debian Med (and if needed of Debian Science and DebiChem) * working on the needed changes for UDD machine readable files gatherer However, my prefered solution for this problem would to start an open discussion on debian-devel for opinions about a potential new name for the signature file. This would have two advantages: 1. We might find some better consensus which could make a stressfull transition superfluous 2. Readers of the list would hopefully *learn* about both things (the signature file as well as the metadata file) From my point of view the later is perhaps even more important. BTW, I would be quite happy if the work on upstream metadata which had been done in a quite big effort would be respected to some extend and not simply spoiled due to some naming choice. Kind regards Andreas. -- 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#737145: libprotobuf8: segfault in mozc-server with versions later than 2.5.0-5
Package: libprotobuf8 Version: 2.5.0-6 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? upgrade libprotobuf8 from 2.5.0-5 to 2.5.0-8 * What exactly did you do (or not do) that was effective (or ineffective)? when I attempted to downgrade again 2.5.0-5 was no longer available, so I tried using 2.5.0-6 but had the same problem: $ gdb /usr/lib/mozc/mozc_server GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/lib/mozc/mozc_server...(no debugging symbols found)...done. (gdb) run Starting program: /usr/lib/mozc/mozc_server warning: Could not load shared library symbols for linux-gate.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1. [New Thread 0xb7f6ab40 (LWP 5502)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7f6ab40 (LWP 5502)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x080fd380 in ?? () #2 0x08070a98 in google::protobuf::Message::GetReflection() const () #3 0x411a06a2 in google::protobuf::internal::ReflectionOps::DiscardUnknownFields(google::protobuf::Message*) () from /usr/lib/i386-linux-gnu/libprotobuf.so.8 #4 0x4119dc8b in google::protobuf::Message::DiscardUnknownFields() () from /usr/lib/i386-linux-gnu/libprotobuf.so.8 #5 0x0811320e in ?? () #6 0x08117598 in ?? () #7 0x08117651 in ?? () #8 0x08117685 in ?? () #9 0x08152f11 in ?? () #10 0x08089b0b in ?? () #11 0x4206acf1 in start_thread (arg=0xb7f6ab40) at pthread_create.c:311 #12 0x41f55c3e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131 (gdb) * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13.0+ (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libprotobuf8 depends on: ii libc6 2.17-97 ii libgcc1 1:4.8.2-14 ii libstdc++6 4.8.2-14 ii zlib1g 1:1.2.8.dfsg-1 libprotobuf8 recommends no packages. libprotobuf8 suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679390: debian-el: M-x debian-bug does not run bug script if it is a symlink
Sincere apologies... :-( Peter Sven Joachim svenj...@gmx.de wrote: Ping? I have been applying this patch locally for the last releases, would like not having to do this anymore. Ping again… :-( Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737095: qdbus segfaults
reassign 737095 qdbus-qt5 5.1.1-2 thanks On Thursday 30 January 2014 15:22:45 Philipp Marek wrote: 1) Try calling qdbus with: gdb -ex r --args qdbus -qt4 org.kde.kmail2 /kmail2/kmail_composer_1 That works. OK, now we know it's Qt5's qdbus which is crashing. I'm so reassigning it. 2) If you are using unstable you might want to try Qt 5.2.0 from experimental. Hmmm, I got qt5-default=5.2.0something - but that's not enough. libqt5core5 has no 5.2.0 - what else should get upgraded? Almost everything :) qt5-default will not pull the rest of the new stuff. But please, before upgrading anything, please send the output of dpkg -l qt5-dbus So we can be sure of what exact version we are talking about. After that I'll tell you how to upgrade the rest. 3) Remove qt5-default. That will make qt4 the default Qt stack. If you want to develop stuff under Qt5 you can always use CMake or export QT_SELECT=qt5, see [0] Well, I wanted to get to QT5 at some time ... So I don't really have an opinion about which way to choose. qt5-default should only be used if you are developing things. Else apps will just use the Qt version they where compiled for. You don't need to do anything. OTOH, if you are developing things, you can avoid qt5-default too. Thanks and I'll wait for your reply to this mail :) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#737132: Regression: wheezy initrd loads md raids only if defined on mdadm.conf even with INITRDSTART='all'
Il 30/01/2014 16:15, Michael Tokarev ha scritto: 30.01.2014 17:45, Fabio Fantoni wrote: Package: mdadm Version: 3.2.5-5 Severity: normal I'm attempting to restore a backup of a root partition on a set of brand new disks (md raid1). On Wheezy, initramfs doesn't show md devices if they are not defined in /etc/mdadm/mdadm.conf even if on /etc/default/mdadm there is INITRDSTART='all'. Such problem may be caused by a regression (squeezy or wheezy) because on lenny I've been always did such task without problem. [] Personalities : [raid1] md1 : active raid1 sda3[0] sdb3[1] 72610624 blocks super 1.2 [2/2] [UU] With 1.x superblock, the term all actually refers to all arrays belonging to this host, which has current hostname recorded in the superblock (1.x format superblock has a place for homehost field, while 0.90 format didn't have this field). Previously, mdadm really tried to assemble any arrays found, but this turned out to be wrong. For example, when you insert hard drives from another system for recovery of broken raid/filesystem, mdadm should NOT assemble arrays from there by default, because this way we've a high risk of breaking stuff further. Please ensure that you have the right homehost in your raid arrays (mdadm -D will tell you), and -- the second part of the picture -- that this hostname is set correctly inside initrd when mdadm is run. Please note also that modern mdadm will try to check homehost even for 0.90 superblocks, by doing some magic with the array UUID. If your arrays were created by sufficiently recent mdadm, the UUID has some bits of homehost mixed in. Thanks, /mjt Thanks for reply. The new md arrays were created by Wheezy persistent install on usb pendrive used as recovery system/tools. The root of system to recover is also Wheezy. Than the arrays are created with 1.2 superblock and different hostname. Is it possible to force the hostname on mdadm create? If so, is the UUID going to work too? Otherwise if it is possible to change it only with --update, will the UUID contain the old hostname and will it be a problem on initrd start? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733723: ruby-rmagick: FTBFS on i386: stroke_linecap.rb:42:in `draw': pixels are not authentic
Package: ruby-rmagick Version: 2.13.2-2 Followup-For: Bug #733723 Hi Christian, It seems that these errors occur when building the documentation. The two examples from doc/ex/ causing such errors are stroke_linecap.rb and shadow.rb. Running these examples outside of post-setup.rb (which generates the documentation) does not give any error. The original source code allows for 4 errors or less during documentation build, but the debian patch fail-on-doc-failure.dpatch makesthe build fail after 2 errors. I am tempted to remove that patch from debian/patches/series for the moment, and leave a normal bug open related to the failing examples. What do you think? With kind regards, Cédric -- 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.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ruby-rmagick depends on: ii libc6 2.17-97 ii libmagickcore58:6.7.7.10-7 ii libruby1.9.1 1.9.3.484-1 ii libruby2.02.0.0.353-1 ii ruby 1:1.9.3 ii ruby1.9.1 [ruby-interpreter] 1.9.3.484-1 ii ruby2.0 [ruby-interpreter]2.0.0.353-1 ruby-rmagick recommends no packages. ruby-rmagick suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#737132: Regression: wheezy initrd loads md raids only if defined on mdadm.conf even with INITRDSTART='all'
30.01.2014 20:18, Fabio Fantoni wrote: [] Thanks for reply. The new md arrays were created by Wheezy persistent install on usb pendrive used as recovery system/tools. The root of system to recover is also Wheezy. Than the arrays are created with 1.2 superblock and different hostname. Is it possible to force the hostname on mdadm create? use --homehost=whatever for that. If so, is the UUID going to work too? I don't understand this question. Otherwise if it is possible to change it only with --update, will the UUID contain the old hostname and will it be a problem on initrd start? use --update=homehost when assembling. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737145: libprotobuf8: segfault in mozc-server with versions later than 2.5.0-5
Package: libprotobuf8 Followup-For: Bug #737145 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** 2.5.0-5 was still in my package cache. When I manually installed it and restarted the desktop, mozc functioned normally. For your reference, these are the mozc-related packages installed: ii ibus-mozc 1.13.1651.102-1+b1 i386 Mozc engine for IBus - Client of the Mozc input method ii mozc-data 1.13.1651.102-1 all Mozc input method - data files ii mozc-server 1.13.1651.102-1+b1 i386 Server of the Mozc input method ii mozc-utils-gui1.13.1651.102-1+b1 i386 GUI utilities of the Mozc input method *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13.0+ (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libprotobuf8 depends on: ii libc6 2.17-97 ii libgcc1 1:4.8.2-14 ii libstdc++6 4.8.2-14 ii zlib1g 1:1.2.8.dfsg-1 libprotobuf8 recommends no packages. libprotobuf8 suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737096: /usr/bin/qdbusviewer: does not start
block 737096 by 731261 thanks This actually happens because qdbusviewer is shipped in 5.2.0. The bug will be present in unstable/testing until we can push 5.2.0 in it. I'm blocking this bug with the transition's one. Kinds regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#722494: Bug #722494
Colin, The question of using an external MySQL server is even asked and answered on the cqrlog forum: Hi Is there any way to use an external MySQL database? I have a dedicated MySQL server and I will prefer to store my log there. Best 73 de OX3IO, Brian Hi Brian, yes, it is. After program runs, you'll see list of logs. On the top of the window is checkbox Save log data to local machine. If you uncheck it, you'll be able to enter connection options to dedicated server. 73 Petr, OK2CQR http://www.cqrlog.com/node/1094 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737145: Fwd: libprotobuf8: segfault in mozc-server with versions later than 2.5.0-5
Original Message Subject: libprotobuf8: segfault in mozc-server with versions later than 2.5.0-5 Date: Fri, 31 Jan 2014 02:33:48 +1030 From: Arthur Marsh arthur.ma...@internode.on.net To: Debian Bug Tracking System sub...@bugs.debian.org Package: libprotobuf8 Version: 2.5.0-6 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? upgrade libprotobuf8 from 2.5.0-5 to 2.5.0-8 Correction, I meant 2.5.0-7: [UPGRADE] libprotobuf8:i386 2.5.0-5 - 2.5.0-7 Regards, Arthur. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735834: surefire: FTBFS: compile errors
In order to fix this issue maven-ant-helper has to add maven-toolchain.jar to the classpath when invoking Maven. This is a side effect of the maven-compiler-plugin upgrade from 2.0.2 to 2.5.1 last November. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737146: nginx-extras: naxsi not compiled in
Package: nginx-extras Version: 1.4.4-1~bpo70+1 Severity: wishlist Hi I noticed there is a package nginx-naxsi (which does not contain webdav) and a apackage nginx-extras (which contains everything but the kitchen sink but not naxsi). Is there a reason why the otherwise fully-fledged nginx-extras does not contain naxsi? If no, I'd be obliged if it could be compiled in. (Actually, I would like nginx-naxsi with webdav even better; but I understand some people would no like to burden it even more). -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.13.0-grsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (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#737147: Please stop using HAL
Package: halevt Version: 0.1.6.2-2 Severity: serious User: pkg-utopia-maintain...@lists.alioth.debian.org Usertags: halectomy Hi, HAL has been deprecated and declared dead upstream so we want to get rid of it in Debian [1]. Due to the changes in udev-183, hal is no longer really functional on Linux since it doesn't receive any uevents any longer [2]. Since halevt directly relies on hal, the best option I see is to remove this package from the archive. Regards, Michael [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=halectomy;users=pkg-utopia-maintain...@lists.alioth.debian.org [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=udev-183 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (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#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
2014-01-30 Thorsten Glaser t...@mirbsd.de: Matthias Klumpp dixit: 2014-01-30 ChaosEsque Team chaosesquet...@yahoo.com: [bullshit] This was actually *not* bullshit. The delivery of most of the content could use some polishing, but the content is a(n inconvenient) truth. Wasn't there some kind of a ban applied here? Apparently not, but it’s better that way, as the reasoning was something along the lines of the messages being off-topic, which they are clearly not, so I believe the ban to be in error, anyway. First of all, I am sorry for leaking information and this rather rude reply - won't happen again. I was just very annoyed yesterday, but a more polite reply would still have been better (although I still think the arguments weren't valid) On thing about the whole dropping GNOME and punishing Lennart/the systemd team for pushing innovations without caring for how it was done prevously: What would be the effecr if we decided to drop GNOME, because it depends on systemd? Of course, Debian would have played with it's muscles, but in the end we would have lost GNOME users, all GNOME developers and many motivated people involved in taking care of GNOME. GNOME upstream won't really change, because they test the with-systemd codepath, which means they are running it. So we would have a great loss without any gain. What would happen if we adopted systemd? We could keep every software running as-it-is on Debian. People would not notice any issues, because (except for some bugs pending to be fixed, and the migration phase) a systemd-system does not break anything for Linux users (ask Arch, Fedora, OpenSUSE, ...). Of course, there is the kFreeBSD case. But instead of porting away each and every software from systemd to $other_init, in case of kFreeBSD we would just have to maintain portability patches for applications which want to run on this architecture. So, less work. For users of alternative kernels, they could also use sysvinit or anything else, because existing scripts won't stop working and new ones can be written which match the underlying alternative kernel (sysvinit is running on kFreeBSD due to some hacks to make /proc Linux-ish, so this kind of adaption is already happening). If we would drop systemd or anything which Lennart created, we would reject functionality without any technical reason to do so. The software written by Lennart fixes issues. That's why Wayland uses it and an X patch is pending, to make some new scenarios with X possible. People working on these projects are no idiots who add a dependency because they can, but because it seems to be the best solution in order to fix a problem for them. Of course, that could - in theory - be done differently, but nobody stepped up to write an alternative to systemd services, so systemd is used. Not using systemd fixes *none* of the problems, but results in much more work in future to make stuff work on Debian - so I don't really consider this to be a viable solution to anything. All of the above applies to upstart as well, but with the limitation that in case of using upstart we would still have to make upstart support systemd features and to carry additional patches to make all systemd services work well on that system. In the end: Dropping GNOME or systemd does not fix issues but is only hiding problems. Ignoring things written by the systemd people which are adopted by many upstream projects already will harm Debian more then simply adding them and making them work great (because that's what distributions should do: make upstream software work well together), no matter if systemd is running as init or not. Phew, waaay to much text... 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#717613: [Pkg-utopia-maintainers] Bug#717613: systemd-udevd failes to execute /lib/udev/socket:@/org/freedesktop/hal/udev_event
Am 30.01.2014 16:26, schrieb lct: This is crazy and scary. Affects me too. The system is hardly a year old, first Wheezy then dist-upgraded to Testing. Hal was NOT manually installed. I know what prehistoric artifact HAL is, but the thing is - it was pulled as dependency at some regular update. Can you run aptitude why hal to see which other package pulled in hal? Indeed, the hal somehow was in the system...! Thanks a lot for reporting and pointing it out. Why doesn't Debian have clear distinction between must-keep/relevant packages and the rest/non-relevant? It sure has manually installed group, but user could manually install because it was dependency of one must-keep package and can be safely purged if must-keep is gone. Apt-pinning isn't the case, because we don't want to pin version, we want to pin the package in system, as explicitly to stay in the system as of relevance to the user. Manually installed is also very vague definition, as displayed earlier. I am not debian developer, nor can code. I wish someone proposed something like that. Unfortunately we can't just yet get rid of hal, because Xorg on kfreebsd still requires it. There are also a few stragglers on Linux, but the list is very short [1]. What we can possibly do is a/ Remove hal on linux. Tools like aptitude should then list the hal package under Obsolete and Locally Created Packages. Building for non-Linux only is a bit tricky though, since myself I only use Linux. b/ Move hal to Section oldlibs c/ Add Breaks: hal to udev so it is automatically uninstalled on Linux. Since hal on Linux is no longer really functional and actually broken by that udev change, this might be the right thing to do. I'm usuallly a bit wary with adding Breaks since they have the tendency to confuse apt on dist-upgrades. I've CCed the pkg-systemd maintainers list since I'd like some input from the other systemd/udev maintainers on this. Cheers, Michael [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=halectomy;users=pkg-utopia-maintain...@lists.alioth.debian.org -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#360202: Wrong calculations about string sizes with russial locales
I think that #610955 is related to #350202. Not merging or doing other triaging actions because I don't have time for deeper investigation at the moment. But I think that this is a general problem when languages require more than 1 byte to represent the charsets. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737116: rawdog: Please don't ship useless copy of timeoutsocket.py
Hi. Adam Sampson a...@offog.org writes: Hi Olivier, On Thu, Jan 30, 2014 at 01:07:02PM +0100, Olivier Berger wrote: It seems to me that rawdog embedds a copy of timeoutsocket.py, This has been fixed for a couple of releases in upstream rawdog. I've been trying to adopt the orphaned Debian rawdog package for a few months, but I'm still looking for a mentor (since I'm not a DD/DM) -- would you be willing to do this, or do you know anyone who might be? After sending the mail, I've noticed your ITA and subsequent RFS... however I'm not really sure this is a commitment I can offer as I'm not a user of rawdog myself. Btw, I'm concerned about such issues, and that's by thinking about such unfortunate situations that I've asked myself if there's something we can do, hence my posting to the debian-devel list : https://lists.debian.org/debian-devel/2014/01/msg00579.html As you can see from first reactions, I can't yet claim I've found a miracle solution for lack of interest in sponsoring from DDs :-/ Good luck. Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683523: rubber: multibib support broken
tags 683523 + patch stop On 30.01.14 Martin Lambers (mar...@marlam.de) wrote: Hi, I encountered the same error and fixed it by fixing the typo in /usr/lib/pymodules/python2.7/rubber/latex_modules/multibib.py line 65: replace 'bibligraphystyle' with 'bibliographystyle'. Thanks. Tagging as having a patch for now. H. -- sigmentation fault signature.asc Description: Digital signature
Bug#737124: libbinio: FTBFS: symbols don't match
Control: tags -1 pending On 30.01.2014 14:35, Roland Stigge wrote: libbinio FTBFS on powerpc, sparc, s390x, alpha, powerpcspe and ppc64 like this: (Example from powerpc): Thanks, I've pushed a fix to git and asked my sponsor to upload it. Cheers, Andreas -- Andreas Moog, Berliner Str. 29, 36205 Sontra/Germany PGP-encrypted mails preferred (Key-ID: 74DE6624) PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624 signature.asc Description: OpenPGP digital signature
Bug#718432: Debian bug 718432
On Tue, Jan 28, 2014 at 08:33:23PM -0500, Keith Lawson wrote: Hi Fernando, How are you defining $r in the code you're referencing in Debian bug 718432? Can you send your my $r = line from your code? Did you switched from mod_perl 1 to mod_perl 2 when upgrading Apache or was this code working under earlier versions of Apache 2.x? Sorry for my lack of interaction: after some time everything started to work fine again. I saw that the bug was in state closed and I didn't think to write back to you. Thank you. -- Fernando Santagata -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716723: sasl2-bin: subprocess installed post-installation script returned error exit status 1
Hi Roberto, thank you for looking into this. I will send you a link to the sasldb2 file in a personal separate email for you investigation (would you please provide me with an address?). Please keep the contents of this file private. You may share the contents and the file with other package maintainers or who else you see fit to work on this bug, provided they also keep it private. thank you, Johannes package sasl2-bin tags 716723 + moreinfo thanks On Thu, Jul 11, 2013 at 10:36:40PM +0200, Johannes Schlumberger wrote: Configuring sasl2-bin Failed to upgrade /etc/sasldb2 The /etc/sasldb2 file could not be upgraded to the new database format. This is a fatal error and will cause the package installation to fail. Johannes, I am going through the bugs against cyrus-sasl2 and trying to resolve as many as possible. Is there any chance you can provide the offending /etc/sasldb2 file? If that is not possible, can you fabricate a minimal /etc/sasldb2 that can be used to reproduce the problem? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#722494: Bug #722494
Pat, While I appreciate upstream's concern, having MySQL *installed on the same machine* is not a requirement for it to run. This seems to me to be a case for Recommends rather than Depends Right, I'm not an expert on mysql but I understand that much. What actually happens if you try to run cqrlog on a machine which has the mysql client installed but not the server? When cqrlog starts it opens a dialog asking which callsign/database you want to use with the tickbox checked for save log data to local machine. So by default it's going to try to use a local server. If a sensible error message is produced then that would be okay, but if it's something obscure or the program just exits or crashes then that would be a problem. Maybe the program should ask the client somehow about a local server and if one is not available then it should present the dialog with the check-box unticked, which makes the dialog open with the boxes for server name and port visible. Colin PS did you see my query about acfax? -- Colin Tuckley | +44(0)1223 830814 | PGP/GnuPG Key Id Debian Developer | +44(0)7799 143369 | 0x38C9D903 Oxymoron: Real Magic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716723: sasl2-bin: subprocess installed post-installation script returned error exit status 1
On Thu, Jan 30, 2014 at 05:36:05PM +0100, Johannes Schlumberger wrote: Hi Roberto, thank you for looking into this. I will send you a link to the sasldb2 file in a personal separate email for you investigation (would you please provide me with an address?). Please keep the contents of this file private. You may share the contents and the file with other package maintainers or who else you see fit to work on this bug, provided they also keep it private. thank you, Johannes Johannes, You can send it to robe...@connexer.com If you like, you can send the file itself in an encrypted email (my key is in the Debian keyring). A link would also work. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#737148: gnucash: Can't open SQL file
Package: gnucash Version: 1:2.6.1-1 Severity: normal gnucash suggested to libdbd-mysql For Gnucash =2.6 compiled with libdbi1 = 0.9 you also need libdbd-mysql = 0.9 as this time it failed in testing. After installing it from sid all things works. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnucash depends on: ii gnucash-common 1:2.6.1-1 ii guile-2.0 2.0.9+1-1 ii guile-2.0-libs 2.0.9+1-1 ii libaqbanking34 5.3.1beta-2 ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libcrypt-ssleay-perl 0.58-1+b1 ii libdate-manip-perl 6.42-1 ii libdbi10.9.0-1 ii libfinance-quote-perl 1.18-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-0 2.36.4-1 ii libgnome-keyring0 3.4.1-1 ii libgnomecanvas2-0 2.30.3-2 ii libgoffice-0.8-8 0.8.17-3 ii libgtk2.0-02.24.22-1 ii libgwengui-gtk2-0 4.9.0beta-1 ii libgwenhywfar604.9.0beta-1 ii libhtml-tableextract-perl 2.11-1 ii libhtml-tree-perl 5.03-1 ii libktoblzcheck1c2a 1.44-1 ii libofx41:0.9.4-2.1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-01.36.0-1+b1 ii libpython2.7 2.7.6-5 ii libwebkitgtk-1.0-0 2.2.3-1 ii libwww-perl6.05-2 ii libx11-6 2:1.6.2-1 ii libxml22.9.1+dfsg1-3 ii libxslt1.1 1.1.28-2 ii perl 5.18.2-2 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages gnucash recommends: ii gnucash-docs 2.6.0-1 ii yelp 3.10.1-1 Versions of packages gnucash suggests: ii libdbd-mysql0.9.0-2 pn libdbd-pgsqlnone pn libdbd-sqlite3 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#726165: Acknowledgement (transition: protobuf)
Julien Cristau wrote: On Sun, Jan 26, 2014 at 12:19:49 +0100, Julien Cristau wrote: On Sat, Jan 25, 2014 at 16:57:30 -0500, Robert Edmonds wrote: I will upload protobuf 2.5.0-5 to unstable shortly. Is there anything I need to do to schedule binNMUs of the reverse deps or is that handled by the release team? Scheduled now. And they started failing. At least ia64 and sparc look like protobuf itself being broken. Cheers, Julien Hi, I'd like to request binNMUs against protobuf 2.5.0-7. -- Robert Edmonds edmo...@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#538307: aptitude: package view doesn't show description for some packages
Control: tags -1 + moreinfo Hi, Can you please try to see if this happens in current versions of aptitude? Maybe the fact that asylum doesn't have any candidate (nor installed) version is what it's causing the problem. If you (or anybody) could verify whether this is an issue with the rest of games/packages (trying to correlate lack of description and lack of candidate or installed versions), it would be great. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737149: CVE-2014-1691: Remote code execution in horde 5.1.1
Package: horde3 Version: 3.3.8+debian0-2 Severity: serious Tags: security Justification: security issue Hello, As detailed on the debian security tracker[0] and reported on oss-sec[1] and assigned CVE 2014-1691, there is a remote code execution bug in horde affecting all versions from at least horde 3.1.x to 5.1.1. That includes squeeze... I've got a patch that applies to the horde3 package in squeeze that resolves this issue, please find it attached[2]... I've built and tested these packages on Squeeze in an active environment. I am not certain where this particular code is used, so I wasn't sure if I was able to test exactly that code path. If you would like, I can provide a package for squeeze for a DSA. Micah 0. https://security-tracker.debian.org/tracker/CVE-2014-1691 1. http://seclists.org/oss-sec/2014/q1/153 2. https://gist.github.com/pietro/8712454/raw/b03bc5ecb7ec1f1f778b867ecd6d9d142d0ddaf7/gistfile1.diff -- 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.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages horde3 depends on: ii apache2 2.4.7-1 ii apache2-bin [httpd] 2.4.7-1 ii libapache2-mod-php5 5.5.8+dfsg-3 ii libjs-scriptaculous 1.9.0-2 ii php-log 1.12.7-1 ii php-mail 1.2.0-5 ii php-mail-mime1.8.8-1 ii php5-gd 5.5.8+dfsg-3 ii php5-mcrypt 5.5.8+dfsg-3 Versions of packages horde3 recommends: pn fckeditor none ii locales2.17-97 ii logrotate 3.8.7-1 pn php-date none ii php-db 1.7.14-2 pn php-file none ii php-mdb2 2.5.0b5-1 pn php-mdb2-driver-mysql | php-mdb2-driver-pgsql | php-mdb2-driv none pn php-services-weather none ii php5-cli 5.5.8+dfsg-3 pn php5-mysql | php5-pgsql | php5-ldapnone pn tinymce2 | tinymce none Versions of packages horde3 suggests: pn chora2none pn enscript none ii gettext 0.18.3.2-1 pn gollemnone pn imp4 none pn kronolith2none ii libgeoip1 1.6.0-1 pn libwpd-tools none pn mnemo2none pn php-net-imap none pn php5-auth-pam none ii php5-common [php5-mhash] 5.5.8+dfsg-3 pn ppthtml none pn rpm none pn source-highlight none pn turba2none pn unrtf none pn webcppnone pn wvnone pn xlhtmlnone -- Configuration Files: /etc/horde/horde3/.htaccess [Errno 13] Permission denied: u'/etc/horde/horde3/.htaccess' /etc/horde/horde3/conf.php [Errno 13] Permission denied: u'/etc/horde/horde3/conf.php' /etc/horde/horde3/conf.xml [Errno 13] Permission denied: u'/etc/horde/horde3/conf.xml' /etc/horde/horde3/hooks.php [Errno 13] Permission denied: u'/etc/horde/horde3/hooks.php' /etc/horde/horde3/mime_drivers.php [Errno 13] Permission denied: u'/etc/horde/horde3/mime_drivers.php' /etc/horde/horde3/motd.php [Errno 13] Permission denied: u'/etc/horde/horde3/motd.php' /etc/horde/horde3/nls.php [Errno 13] Permission denied: u'/etc/horde/horde3/nls.php' /etc/horde/horde3/prefs.php [Errno 13] Permission denied: u'/etc/horde/horde3/prefs.php' /etc/horde/horde3/registry.d/README [Errno 13] Permission denied: u'/etc/horde/horde3/registry.d/README' /etc/horde/horde3/registry.php [Errno 13] Permission denied: u'/etc/horde/horde3/registry.php' -- 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#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Matthias Klumpp dixit: What would happen if we adopted systemd? The project would lose (a different set of) contributors and users. The OSS ecosystem would lose, vendor-lock-in would ensue in a way even worse than the FSF does, and the remnants of Unix/GNU in Debian would die, to be replaced by FLOS. The last “big” outpost of inde‐ pendence would go away. I don’t know which OS I’d use in place of Debian then (probably rather OpenBSD than Gentoo), in the places where I’m currently using, supporting or pushing Debian. Debian would follow the path of Red Hat, Inc. The LSB would die. The LPI people would probably rejoice, as they could drop everything other than systemd configs… Every single Unix or GNU sysadmin would have to relearn basically everything about system/service management. Oh, and don’t let me get started on “journal”… And, finally – last but definitely not least – nobody knows what Lennart and Co. would drop onto our heads *next* time. Or the GNOME people. And, by then, switching away would be even *more* reluctant work. software written by Lennart fixes issues. That's why Wayland uses it and an X patch is pending, to make some new scenarios with X possible. It also creates lots of issues (a common way to fix audio problems on contemporary Debian is “purge pulseaudio”, I kid you not!), and not everyone needs all those scenarios. I don’t mind Debian permitting people to use systemd as long as sysvinit support stays mandatory, and it is possible to install a Debian system without systemd/GNOME without needing to go through unreasonable things. Otherwise… well. In the end: Dropping GNOME or systemd does not fix issues but is only Well, it _would_ fix the current clash *and* give clear signals into the direction of KDE and hopefully XFCE people. Also, it would signal to people that they cannot just take over the entire OS like that. Distributions are *not* meant to be there to just look and do the same. Rather, the contrary. While their initial and foremost purpose is to make the bunch of packages in the GNU ecosystem installable and harmonise with each other, their job is also to offer a diverse choice. And the GNOME/systemd people are invited to make their dream of the FLOS GNOME OS into a Debian derivate or Pure Blend. bye, //mirabilos -- 08:05⎜XTaran:#grml mika: Does grml have an tool to read Apple ⎜System Log (asl) files? :) 08:08⎜ft:#grml yeah. /bin/rm. ;) 08:09⎜mrud:#grml hexdump -C 08:31⎜XTaran:#grml ft, mrud: *g* -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737150: util-linux: blkid does not support f2fs
Package: util-linux Version: 2.20.1-5.5 Severity: normal blkid -kdoes not include f2fs so that udev does not populate /dev/disk/by-label/ with an entry when a f2fs system is mounted. This blog: http://bkhome.org/blog2/?viewDetailed=00133 suggests that it is available upstream. *** End of the template - remove these lines *** -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Matthias Klumpp writes (Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.): What would be the effecr if we decided to drop GNOME, because it depends on systemd? In this hypothetical scenario: It would be fairly easy for a downstream of Debian to mandate systemd for their users, and provide Gnome. It would not be anywhere near as easy for a downstream of Debian to undo the assumption by Debian (de facto or de jure) of systemd as the one true init system. If it comes down to it I would prefer to drop Gnome than to make systemd mandatory for all of Debian's users and downstreams just because Gnome had introduced a hard dependency on systemd. Luckily this is all hypothetical. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726165: Acknowledgement (transition: protobuf)
On Thu, Jan 30, 2014 at 12:00:35 -0500, Robert Edmonds wrote: Julien Cristau wrote: On Sun, Jan 26, 2014 at 12:19:49 +0100, Julien Cristau wrote: On Sat, Jan 25, 2014 at 16:57:30 -0500, Robert Edmonds wrote: I will upload protobuf 2.5.0-5 to unstable shortly. Is there anything I need to do to schedule binNMUs of the reverse deps or is that handled by the release team? Scheduled now. And they started failing. At least ia64 and sparc look like protobuf itself being broken. Cheers, Julien Hi, I'd like to request binNMUs against protobuf 2.5.0-7. Failed ia64 and sparc builds given back. Cheers, Julien signature.asc Description: Digital signature
Bug#737136: uploaded fixed libpyzy
Hi, I just uploaded fixed version of libpyzy. Let's get this moving to testing first. Then fix this package by splitting into data and lib. I think upstream URL needs to change. so does upstream source file name. For that we need new upstream version. I think patch needs to be tagged too. As for the git repo. we need to think a bit. Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737149: CVE-2014-1691: Remote code execution in horde 5.1.1
On Thu, Jan 30, 2014 at 12:00:10PM -0500, Micah Anderson wrote: Package: horde3 Version: 3.3.8+debian0-2 Severity: serious Tags: security Justification: security issue Hello, As detailed on the debian security tracker[0] and reported on oss-sec[1] and assigned CVE 2014-1691, there is a remote code execution bug in horde affecting all versions from at least horde 3.1.x to 5.1.1. That includes squeeze... I've got a patch that applies to the horde3 package in squeeze that resolves this issue, please find it attached[2]... I've built and tested these packages on Squeeze in an active environment. I am not certain where this particular code is used, so I wasn't sure if I was able to test exactly that code path. If you would like, I can provide a package for squeeze for a DSA. 2. https://gist.github.com/pietro/8712454/raw/b03bc5ecb7ec1f1f778b867ecd6d9d142d0ddaf7/gistfile1.diff Yes, please upload a fixed oldstable package with the patch Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
Quoting Antoine Beaupré (2014-01-30 16:34:47) On 2014-01-30 09:29:08, Jonas Smedegaard wrote: runtime pkgsize bloat: 0 Thanks for those measurements Jonas!! If you insist on uglifying at runtime, then I still recommend compacting CSS at build time (300 bytes win is silly when using jQuery bloat!). If you insist on uglifying _CSS_ at runtime, then I still recommend using ruby-sass, and switch to sassc later (see bug#694733,694730). I don't insist at all, in fact I don't understand why we would compress CSS at runtime at all. Ok. For JS it makes sense because of section 4.13 (convenience copies), but the CSS is native... Not sure I understand you here. Debian do not allow redistribution of upstream-compressed JavaScript, but that does not force you to compress at runtime: distributing buildtime-complressed JavaScript is fine to distribute in Debian. Same is in principle true for CSS (and HMTL etc.) but less strongly enforced (because such declarative code is more likely to be still readable). We could *suggest* an uglifier of some sort (and the jury's still out on that I guess) but I strongly feel we should compress at build time. I don't understand what you are saying here. Are you distinguishing between uglify and compress, about JavaScript and CSS, or only about buildtime and runtime?!? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#737126: Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
On Thu, Jan 30, 2014 at 9:16 PM, Markus Hoenicka markus.hoeni...@mhoenicka.de wrote: [..] It's got the same result as without -fsigned-char. :( Ok, maybe this change alone was not sufficient. I went through the changes between the latest 0.8.x release (where things apparently still worked) and 0.9, and I suspect that we need some of the configure magic that was cleaned out before 0.9. Could you please test the appended patches against configure.ac of both libdbi and libdbi-drivers? To fix the problem, we may have to fiddle with both packages at a time. (Cc:-ing #737126) That reduced failures, but still remain the issue with the_float and the_double. Running libdbi framework test... test_dbi.c:3732: unit test failure: sqlite3 - libdbi connection - Retrieving fields as - test_dbi_result_get_as_longlong - [-1] should match [0] at [test_dbi.c] line [3732] test_dbi.c:3733: unit test failure: sqlite3 - libdbi connection - Retrieving fields as - test_dbi_result_get_as_longlong - [-1] should match [0] at [test_dbi.c] line [3733] Running libdbi framework test... Running libdbi framework test... Running libdbi framework test... Completed libdbi framework test: 397 passes, 2 failures, 0 exceptions. make: *** [test-stamp] Error 1 -- Prach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737109: [pkg-wpa-devel] Bug#737109: hostapd: Bridged interface dropped from bridge
On Thu, Jan 30, 2014 at 12:42:07PM +, Stefan Lippers-Hollmann wrote: [...] Thanks a lot for investigating this so well and providing a patch, which seems to have gotten decent testing and looks to be pretty straight forward. However I'm concerned that this particular patch appears to be around three years old, without having been merged into hostapd upstream, despite the patch author usually being quite active in upstream development[1] of these wireless needs... Given that the old bugtracker at w1.fi no longer exists, I can't confirm at the moment if this patch had been submitted upstream and/ or if it has been rejected for any reasons, which makes me a bit reluctant to apply it to Debian. So far I haven't come to a conclusion yet and while this patch might not be part of the very next wpa upload, I'll keep it in mind. Thanks. I understand your reluctance. I am not that familiar with hostapd, but wanted to share a fix for my issue ;-) Having a quick look through the current hostapd GIT (http://hostap.epitest.fi/cgit/hostap/tree/src/drivers/driver_nl80211.c), I think the patch *functionality* is incorporated: HUNK 1 appears around line 9376. The changes to wpa_driver_nl80211_if_remove() are no longer directly necessary because the order of the logic has been changed and most of the function is skipped for non WPA_IF_AP_BSS by the test if (type != WPA_IF_AP_BSS) return 0; at line 9780. The GIT implementation of wpa_driver_nl80211_if_remove() may well be cleaner and more preferable. Perhaps that would be a better fix? I hope that helps. Mark -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737137: game-data-packager: patch to support hexdd
Am Donnerstag, den 30.01.2014, 15:04 + schrieb Johey Shmit: This patch also changes the installation folder of heretic and hexen wads back to /usr/share/games/hexen|heretic as it was before version 30. I originally suggested the change to put all doom engine files into /usr/share/games/doom but I now think that was not such a good idea. Please keep it that way! Currently all Doom engines in Debian that also support playing Heretic or Hexen have /u/s/games/doom set as their IWAD directory. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: TC resolution revised draft
Philipp Kern writes (Re: Bug#727708: TC resolution revised draft): On 2014-01-30 15:47, Ian Jackson wrote: == optional rider M (Multiple init systems) == Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Where feasible, software should interoperate with non-default init systems; maintainers are encouraged to accept technically sound patches to enable interoperation, even if it results in degraded operation while running under the init system the patch enables interoperation with. So if we assume that upstart wins, would it be acceptable to depend on systemd (or vice versa)? We might then get a set called, say, Unity, depending on upstart and one called, say, GNOME, depending on systemd, which would not be co-installable. Maybe there should be a paragraph addressing this? So, my previous version of this rider was this: Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. (Same as above.) Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. Different to above. Perhaps adding this: Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems. would soften this text. I will ensure that something like this gets onto the ballot iff I hear from the project that they think it's important to vote on it in the TC (even if the TC seems likely to reject it). I'm obviously open to suggested wording improvements for the version M you see above (which is in the git repo) and this stronger compatibility requirement version. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
On 2014-01-30 12:15:00, Jonas Smedegaard wrote: Quoting Antoine Beaupré (2014-01-30 16:34:47) On 2014-01-30 09:29:08, Jonas Smedegaard wrote: runtime pkgsize bloat: 0 Thanks for those measurements Jonas!! If you insist on uglifying at runtime, then I still recommend compacting CSS at build time (300 bytes win is silly when using jQuery bloat!). If you insist on uglifying _CSS_ at runtime, then I still recommend using ruby-sass, and switch to sassc later (see bug#694733,694730). I don't insist at all, in fact I don't understand why we would compress CSS at runtime at all. Ok. For JS it makes sense because of section 4.13 (convenience copies), but the CSS is native... Not sure I understand you here. Debian do not allow redistribution of upstream-compressed JavaScript, but that does not force you to compress at runtime: distributing buildtime-complressed JavaScript is fine to distribute in Debian. Right. Same is in principle true for CSS (and HMTL etc.) but less strongly enforced (because such declarative code is more likely to be still readable). The difference being that the CSS is not upstream so we do not need to fiddle around with symlinks. We can just shipped the compressed code in the binary package and the original in the source without breaking policy. Of course, we probably want to ship the source CSS anyways as a convenience to allow our users to modify it, but that's a separate feature... We could *suggest* an uglifier of some sort (and the jury's still out on that I guess) but I strongly feel we should compress at build time. I don't understand what you are saying here. Are you distinguishing between uglify and compress, about JavaScript and CSS, or only about buildtime and runtime?!? I was specifically saying that we could allow users to modify the CSS and recompress it, in which case we should Suggest: some kind of CSS compressor so that this can be done easily. But in my opinion, this shouldn't be a hard Depends: we should compress at build time and not force people to install nodejs or ruby to use the photofloat binary package. If they want to edit the CSS and recompress it, then yes, they will need to install one of those bundles, but we shouldn't enforce that if we can avoid it. A. -- Be who you are and say what you feel Because those who mind don't matter And those who matter don't mind. - Dr. Seuss pgpgUeNSJm96s.pgp Description: PGP signature
Bug#490702: pencile got forked
pencil upstream is dead, and in the current shape (last tarball is dated 2009) is unfit for release. Nevermid, somebody made a fork, called pencil2d http://www.pencil2d.org https://github.com/pencil2d/pencil I'm going to open an ITP bug for it, since I'm interested in this software. I think we should close this bug and continue the work in the new one. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo signature.asc Description: Digital signature
Bug#737151: nut-server: upsd not killed on removing nut-server
Package: nut-server Version: 2.6.4-2.3 Severity: normal I got replaced my UPS and put it on a central server and tried to setup up NUT-Monitor, which failed. It turns out NUT-Monitor failed because upsd was still running on the workstation after removing nut-server (due to the old ups being connected to the workstation, but not the new one). -- System Information: Debian Release: 7.3 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_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nut-server depends on: ii adduser3.113+nmu3 ii libc6 2.13-38 ii libupsclient1 2.6.4-2.3 ii libusb-0.1-4 2:0.1.12-20+nmu1 ii libwrap0 7.6.q-24 ii lsb-base 4.1+Debian8+deb7u1 ii nut-client 2.6.4-2.3 ii udev 175-7.2 nut-server recommends no packages. Versions of packages nut-server suggests: pn nut-cgi none pn nut-dev none pn nut-snmp none pn nut-xml none -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
On 30/01/14 17:01, Thorsten Glaser wrote: And the GNOME/systemd people are invited to make their dream of the FLOS GNOME OS into a Debian derivate or Pure Blend. If the chosen default is something other than systemd, and if the TC resolution does not prevent GNOME having a hard dependency on systemd interfaces, then systemd would effectively belong to task-gnome-desktop That situation is basically how the pure blends work already? And it still means the Debian GNOME DVD could give the ideal setup for GNOME. And the 'default' can be decided irrespective of what GNOME needs? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
On Thu, Jan 30, 2014 at 05:30:04PM +0100, Matthias Klumpp wrote: What would be the effecr if we decided to drop GNOME, because it depends on systemd? Of course, Debian would have played with it's muscles, but in the end we would have lost GNOME users, all GNOME developers and many motivated people involved in taking care of GNOME. May be. On another hand, it this decision can attract more conservative (and, probably, experienced) people from other distributions. GNOME upstream won't really change Why? There are non-Linux GNOME users, for example. If the GNOME developers don't care even about such popular distribution as Debian - something is going wrong. And not with the Debian, for sure. We could keep every software running as-it-is on Debian. People would not notice any issues, because (except for some bugs pending to be fixed, and the migration phase) a systemd-system does not break anything for Linux users Please don't repeat here these myths. It does break things, it has bugs. Go to bugtrackers of mentioned distributions, go to the systemd's bugtracker. Last, but not least: http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yessrc=systemd If we would drop systemd or anything which Lennart created, we would reject functionality without any technical reason to do so. There are lots of reasons why we sometimes want to keep things simple and clean. A good example was mentioned in this thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3155 That's why Wayland uses it and an X patch is pending, to make some new scenarios with X possible. People working on these projects are no idiots who add a dependency because they can, but because it seems to be the best solution in order to fix a problem for them. Are X-people indeed sacrifice portability, or there is something different (e.g. these dependencies are optional)? Not using systemd fixes *none* of the problems Where is the list of problems for sysvinit we intend to solve? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737149: CVE-2014-1691: Remote code execution in horde 5.1.1
Moritz Mühlenhoff j...@inutil.org writes: On Thu, Jan 30, 2014 at 12:00:10PM -0500, Micah Anderson wrote: Package: horde3 Version: 3.3.8+debian0-2 Severity: serious Tags: security Justification: security issue Hello, As detailed on the debian security tracker[0] and reported on oss-sec[1] and assigned CVE 2014-1691, there is a remote code execution bug in horde affecting all versions from at least horde 3.1.x to 5.1.1. That includes squeeze... I've got a patch that applies to the horde3 package in squeeze that resolves this issue, please find it attached[2]... I've built and tested these packages on Squeeze in an active environment. I am not certain where this particular code is used, so I wasn't sure if I was able to test exactly that code path. If you would like, I can provide a package for squeeze for a DSA. 2. https://gist.github.com/pietro/8712454/raw/b03bc5ecb7ec1f1f778b867ecd6d9d142d0ddaf7/gistfile1.diff Yes, please upload a fixed oldstable package with the patch Done. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Le jeudi 30 janvier 2014 à 21:38 +0400, Sergey B Kirpichev a écrit : [Lots of crap] Where is the list of problems for sysvinit we intend to solve? https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737152: wheezy: ia64 Netinst iso image broken/doesn't work
Package: wheezy Severity: important When attempting to boot the ia64 netinst iso image in VirtualBox the following error message occurs: FATAL: No bootable medium found! System halted. I was able to install a fedora image x86_64 using VB so I think that the problem is with the ia64 iso image. I was running VB on Lenovo and Acer Windows 8 (64 bit machines). The system information associated with this bug is most likely incorrect. -- System Information: Debian Release: 6.0.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (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#737153: OpenCVModules.cmake not installed, causing visp FTBFS
Package: libopencv-dev Version: 2.4.8+dfsg-1 Control: affects -1 visp openimageio sikuli sitplus digikam mrpt (= everything build-depending on libopencv-dev and cmake) The file OpenCVModules.cmake is created during the build process, but not put in any of the packages: dh_install -O--buildsystem=cmake --list-missing dh_install: usr/share/OpenCV/OpenCVModules-release.cmake exists in debian/tmp but is not installed to anywhere dh_install: usr/share/OpenCV/OpenCVModules.cmake exists in debian/tmp but is not installed to anywhere As this file is referenced from OpenCVConfig.cmake, attempting to use this library from CMake hence fails with (from https://buildd.debian.org/status/fetch.php?pkg=visparch=armelver=2.8.0-4stamp=1390889862) CMake Error at /usr/share/OpenCV/OpenCVConfig.cmake:45 (include): include could not find load file: /usr/share/OpenCV/OpenCVModules.cmake I expect that putting this file in libopencv-dev would fix the problem, but have not tested this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737114: plucker: Should not ship embedded compy of timeoutsocket
Le 30/01/2014 12:57, Olivier Berger a écrit : Package: plucker Severity: wishlist Dear Maintainer, Hello, It seems to me that plucker embedds a copy of timeoutsocket.py, which seems to be potentially duplicated in other packages. This isn't optimal to Debian standards. One solution would be to instead depend on a system package providing timeoutsocket (an RFP exists at #736935). But as timeoutsocket seems to be no longer needed in recent versions of Python (see the discussion at [0]), it may as well be removed from the installed files, making sure that the necessary patch is applied to upstream code. Thanks in advance if you can address this. plucker is no more maintained upstream. Its popularity is declining: http://qa.debian.org/popcon.php?package=plucker I do not use it anymore and do not plan to invest time and energy in wishlist bugs. Thanks for the bug. -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736755: Pending fixes for bugs in the libfile-counterfile-perl package
tag 736755 + pending thanks Some bugs in the libfile-counterfile-perl package are closed in revision a2bb8b74a4eee000321b83d3ed29002a9090a258 in branch 'master' by Niko Tyni The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libfile-counterfile-perl.git;a=commitdiff;h=a2bb8b7 Commit message: Change the fallback directory for counter files to /var/tmp. (Closes: #736755) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737081: seems to miss displaying some comments to posts
On Wed, Jan 29, 2014 at 07:44:15PM -0400, Joey Hess wrote: https://microca.st/howcanuhavemyusername/note/U3BdE1SYRpmcDl-_5Ae6WQ In the web interface, this post has 4 comments. In pumpa, only the first comment is shown. (After expanding the post in the UI since it started collapsed.) I noticed several other posts where pumpa was not showing some or all of the comments. Tried reloading the timeline in pumpa, this did not make the missing comments show up. Restarting pumpa entirely did. Yes, I'm pretty sure I know why this problem occurs, but I haven't yet decided on the best solution. My guess is you are not following the other people in who replied to the thread (whose replies did not show up in Pumpa)? The problem is that Pumpa currently fills in any new replies (that appear after the main post has first appeared) when they arrive in the meanwhile feed. The meanwhile feed shows only replies from people you follow. To get all replies it would have to reload the original post, but the problem is I cannot know which posts have received new replies, so I would have to poll *all* posts in the inbox, which would cause something like 20-100 extra http requests. Another partial solution would be to reload the inbox feed itself, which usually contains the 20-or-so newest posts. This would automatically get the 4-5 newest comments for each of those posts. Right now Pumpa only polls for new items. Anyway, I will need to figure out some kind of solution before the next release, this is an annoying issue. Regards, Mats signature.asc Description: Digital signature
Bug#737154: ITP: pencil2d -- Animation/drawing software to create hand-drawn animation using both bitmap and vector graphics
Package: wnpp Severity: wishlist Owner: Mattia Rizzolo mat...@mapreri.org * Package name: pencil2d Version : 0.5.4 beta Upstream Author : Matt Chang chc...@gmail.com * URL : http://www.pencil2d.org/ * License : GPL Programming Lang: C++ Description : Animation/drawing software to create hand-drawn animation using both bitmap and vector graphics Pencil2D is an animation/drawing software for Mac OS X, Windows, and Linux. It lets you create traditional hand-drawn animation (cartoon) using both bitmap and vector graphics. Pencil is free and open source. This program is a fork of pencil (RFP bug #490702 and bug #562848), both of them already widely used. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo signature.asc Description: Digital signature
Bug#737108: python-gamin: mixed use of tabs and spaces in the gamin.py file causing syntax erros
[I'm not the maintainer of this package.] * Matt Baker m...@wheres.co.uk, 2014-01-30, 10:19: $ bcfg2-profile-templates.py Traceback (most recent call last): File /usr/local/projects/cfgman/var/work/cmxmb/tags/PROD_STABLE/scripts/bcfg2-profile-templates.py, line 13, in module import Bcfg2.Server.Core File /usr/lib/python2.7/dist-packages/Bcfg2/Server/Core.py, line 17, in module import Bcfg2.Server.FileMonitor File /usr/lib/python2.7/dist-packages/Bcfg2/Server/FileMonitor/__init__.py, line 346, in module from Bcfg2.Server.FileMonitor.Gamin import Gamin File /usr/lib/python2.7/dist-packages/Bcfg2/Server/FileMonitor/Gamin.py, line 6, in module from gamin import WatchMonitor, GAMCreated, GAMExists, GAMEndExist, \ File /usr/lib/pymodules/python2.7/gamin.py, line 39 err = _gamin.Errno() ^ TabError: inconsistent use of tabs and spaces in indentation While it is true that gamin uses unholy mixture of spaces and tabs for indentation, this does _not_ render the package unusable. The reason the script fails is because it uses the -tt option, which enables stricter-than-default indentation checks. If you remove this option from the script's shebang, it should start working. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
