Bug#733026: kde-workspace-bin: kscreenlocker_greet -- unable to unlock session, unable to type password.
Package: kde-workspace-bin Version: 4:4.11.3-2 Severity: important On Debian "testing" I can't unlock my KDE session any more. When I lock session manually (or if "kdm" configured for auto-login) "kscreenlocker_greet" do not allow me to enter password -- it simply do not respond to keyboard at all. Strangely enough password prompt is unable to receive focus when I click on it. Button "unlock" is perfectly clickable but of course it just says "unlock failed" (due to empty password). When I SSH to locked machine I kill "kscreenlocker_greet" which is immediately started again but this time it respond to keyboard so I can unlock my session as expected. This regression appeared just recently as I've never have anything like this on Wheezy. For what's it worth I spotted the problem on my notebook (Intel drivers) and on workstation with "fglrx" driver. --- System information. --- Architecture: amd64 Kernel: Linux 3.11-2-amd64 -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- It is impossible to imagine Goethe or Beethoven being good at billiards or golf. -- H. L. Mencken signature.asc Description: This is a digitally signed message part.
Bug#662759: RFP: csslint -- automated tool for the linting of Cascading Stylesheets [DFSG concerns]
I had a quick look at version 0.10.0 and found that (at least) "jshint.js" is contaminated by sick-minded evil license by Douglas Crockford (i.e. "The Software shall be used for Good, not Evil."). :( I'm not sure how useful this software would be without "jshint.js" (if we consider preparing DFSG-compliant version). Besides what source-less "js.jar" is for? -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#657712: ITP: p2pool -- peer-to-peer pool for Bitcoin mining
Control: block -1 by 676396 This ITP was dormant for over the year so perhaps it could benefit from little help. Lately I packaged "p2pool-13.4" and committed my effort here: http://anonscm.debian.org/gitweb/?p=pkg-bitcoin/p2pool.git There are still some things to finish (see TODO.Debian), notably we need to package dependency "libjs-d3" (#676396) and clarify copyright statement with upstream. Matthias, if you still interested to take care of "p2pool" you're welcome to our friendly "pkg-bitcoin" team -- maintaining package(s) together is easier. :) -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#733180: litecoin: not suitable for stable
Source: litecoin Severity: serious Similar to bitcoin bug #718272 this is to prevent "litecoin" migration to "testing" as long as "litecoin" is considered unsuitable for "stable". -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733276: Acknowledging from Triggers view looses status of "Triggers status", reverts to "Problem"
Dear David, Thank you for your report. Since this problem apparently have nothing to do with Debian I'd love to see that kind of bugs reported directly to upstream bug tracker: https://support.zabbix.com/secure/Dashboard.jspa We need upstream to review your patch and reporting directly to them will save some time for forwarding this information. Could you please confirm if bug affects latest Zabbix from "unstable"? Thank you. Cheers and all the best for the new year. Dmitry Smirnov GPG key : 4096R/53968D1B --- It is a fine thing to be honest, but it is also very important to be right. -- Winston Churchill -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733621: mc: tilde expandion in rename/move is broken
On Tue, 31 Dec 2013 00:03:11 Thorsten Glaser wrote: > Severity: serious Thanks for your report but please do *not* panic and use correct severity in the future: http://www.debian.org/Bugs/Developer#severities -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733676: node-jsdom: tests license / can we re-distribute tests?
Source: node-jsdom Version: 0.2.13+dfsg1-1 Severity: minor I've noticed that during DFSG-repackaging W3C test suite is dropped. README.source explains: remove the testsuite, which has portions © W3C, under a non-free license <http://www.w3.org/Consortium/Legal/2008/04-testsuite-license.html> But LICENSE.txt under "/test" in the original tar says: all level1,level2,level3 test cases were written by the w3c see: http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html for licensing I checked the above link and found that actually tests are dual-licensed under "BSD-3-clause" or "W3C Test Suite License". I also checked archives.org to see whether W3C tests licensing has changed since the package was introduced but found no changes: https://web.archive.org/web/20100610095930/http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html It looks like tests are available under BSD-3-clause terms so perhaps we could ship them. However header of "DOMTestCase.js" says: Copyright (c) 2001-2004 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved. This program is distributed under the W3C's Software Intellectual Property License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See W3C License http://www.w3.org/Consortium/Legal/ for more details. From the above page I have impression that "Software Intellectual Property License" refers to "Test Suite Licenses" in which case perhaps we could re-distribute tests under BSD-3-clause license. So I wonder if we can ship tests after all? Am I missing something? -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#729593: #729593 possibly incorrect lintian check hyphen-used-as-minus-sign
This is really pedantic. :) There is nothing wrong with this check. Lintian uses man output to check for hyphens. I had reproducible case where I could see hyphens outside of lintian and escaping exactly one minus after space was enough to see the problem gone even if second minus was left un-escaped. There were never dash following minus in man pages even if only first minus after space was escaped. Although documentation can always be improved I doubt if there will be any reason to mention that "this check is correct". We assume all checks to be correct -- otherwise we report bugs. :) I recommend to close this "bug" right away. I didn't do it myself merely to leave room for second opinion. Thanks. -- Best wishes, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#738937: zabbix: Drop virtual libgcrypt-dev from Build-Depends
On Fri, 14 Feb 2014 00:07:10 Artur Rona wrote: > In Ubuntu, we've applied the attached patch to achieve the following: > >* debian/control: Replace virtual libgcrypt-dev in Build-Depends with > libgcrypt11-dev | libgcrypt20-dev > > We thought you might be interested in doing the same. Why? I do not recognise the benefits (if any)... -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739078: xpra: recommends contrib package python-pyopencl
Control: block -1 by 723132 On Sat, 15 Feb 2014 18:41:59 Jonas Smedegaard wrote: > As subject says, xpra recommends contrib package python-pyopencl. > > xpra should either only suggest python-pyopencl, or itself be moved to > contrib. Thanks for reporting this. Admittedly I've made a mistake by not checking section of python-pyopencl before adding it to Recommends. But python-pyopencl shouldn't be in contrib in first place. OpenCL is no longer in the exclusive area of proprietary drivers. Right now "opencl-icd" also provided by free "beignet" (along with proprietary providers). Mesa OpenCL support is almost ready to be added to Debian, see #717500. Given the above I think "python-pyopencl" should be moved from "contrib" to "main" and there is an existing ticket for that -- #723132. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723132: please prioritise...
Could this be prioritised please? The reason is #739078 where another package from "main" got "serious" bug for Recommending "python-pyopencl" because the latter is in "contrib"... Thanks. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- Good luck happens when preparedness meets opportunity. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736668: closed by Dmitry Smirnov (Bug#736668: fixed in ifenslave 2.4)
Hi Andreas, Thank you very much for your always useful feedback. On Sun, 16 Feb 2014 03:00:38 Andreas Beckmann wrote: > On 2014-02-10 16:27, Debian Bug Tracking System wrote: > > ifenslave (2.4) unstable; urgency=medium > > . > >* Added "ifenslave-2.6.prerm" to remove dangling alternatives > > prerm does not look right ... I'm not sure why as I couldn't reproduce dangling alternatives with prerm... Do you have any particular scenario where prerm would not be sufficient? -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B --- Faith is the antithesis of proof. -- NY State Supreme Court Justice Edward J. Greenfield, 1995 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723132: please prioritise...
On Mon, 17 Feb 2014 21:18:47 Tomasz Rybak wrote: > Would it be OK to upload to main without running tests from package > (from test/*) on Beignet? IMHO yes, it should be OK since Beignet declared OpenCL support. If it doesn't work it would qualify for bug report wouldn't it? ;) When Mesa/OpenCL will become available it will provide additional justification for "main" disregarding of whether it is production ready or not. -- Best wishes, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739487: python-mysql.connector: Trying to overwrite a file that belong to mysql-utilities
Sorry for delay... I'm a bit confused as even after dropping "namespace.patch" build system of mysql-utilities still install empty file "/usr/share/pyshared/mysql/__init__.py". Is it safe just to dismiss (drop) it? Thanks. -- All the best, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723132: please prioritise...
On Wed, 19 Feb 2014 21:35:49 Tomasz Rybak wrote: > I'll update package during the weekend, and fix #739173 and #739176. > As package will need to go through NEW queue, will you sponsor it? Of course, just let me know when you're ready and allow me several days to reply if I'm busy... -- Best wishes, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738811: handbrake: crashes after source DVD is selected
Are you using "dvdnav" or "libdvdread" (check in File/Preferences/Advanced)? "libdvdread" used to be problematic in the past and once it was causing similar crash, see #688574. Unfortunately it looks like it hasn't been properly fixed which makes me wonder if it hit us again... -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735918: bfgminer version is out of date
On Sun, 19 Jan 2014 02:36:18 Ian Bruce wrote: > As of January 15, 2014, BFGMiner v3.10.0 is available. Dear Ian, Sending that kind of reminders less than a week after release is *not* helpful and perhaps even annoying... What changes in this particular version made you so impatient about new release? -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734597: litecoin: Litecoin still builds with system LevelDB
Hi Scott, Thanks for the relevant links to the discussion that I wasn't aware of. On Thu, 9 Jan 2014 10:02:37 Scott Howard wrote: > If you disagree, I'd be interested in hearing why. Mostly my decision is based on our policy. I'm convinced that discouraging linking to private libraries is one of the best practices that we have in Debian. No only it benefit security but also it helps to maintain coherent up-to-date distribution, encourage communication and cooperation between maintainers as well as compartmentalise development without unnecessary duplication. There are some cases when we have to use bundled library due to local modifications: for instance we can't use system "libjson-spirit" because bundled version is different. (I don't know if Bitcoin developers tried to submit their changes to "libjson-spirit" for acceptance upstream). Generally speaking I often find rationale provided by upstreams in order to justify bundling components to be weak. With the rare exceptions following our policy is the best practice. One of the most convincing arguments that I've seen is the following: http://luke.dashjr.org/tmp/code/20130723-linux-distribution-packaging-and-bitcoin.md.asc But there are problems: * We can't ask our users to use upstream-provided binaries. * Mentioned "unique testing procedures" are not documented in sources so how can _we_ test? * It does not make sense to use bundled LevelDB merely because of "backdor audit". Can't they audit upstream LevelDB release rather their own copy? * If using system-wide library makes software fragile it better be fixed (as well as automatic testing improved to catch possible causes). Otherwise even using bundled libs won't actually guarantee integrity or anything. Basically they are saying somewhat "trust us and beware of any local modifications". The above can be taken as the evidence for insufficient post-build testing which is a weak argument for using bundled software components. To support their argument they mention the following incident: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki But I fail to see how it applies to our situation. From reading incident report I realise that network safety do not depend that much on bundled LevelDB or the whole network would be too fragile for anybody's confidence. Indeed if problem happened due to disagreement between BerkeleyDB-based and LevelDB-based Bitcoin software I don't see how this can support this idea that not using bundled LevelDB can cause implications for the whole network. Upstream developers emphasise testing. This is one of my reasons to use system LevelDB which at least runs post-build tests to ensure that LevelDB is functioning properly. Bitcoin/Litecoin build system doesn't do that. System LevelDB is also better tested with all its patches and build flags simply because it is used by more than one package so there are more eyes on it and potential problem(s) are more likely to be reported. As maintainer I may not know whether bundled library is affected by the same issue or if it would be safe to apply patch to bundled LevelDB without Bitcoin developer's blessing. Finally the only authority on LevelDB is LevelDB developers, not Bitcoin devs. After building new Litecoin version I always let it run for some time before upload. I reckon if there are any disagreement(s) with network it would probably at least fail to catch-up with blockchain updates. I'd be interested to know if there are any additional steps to ensure its proper functioning. -- All the best, Dmitry Smirnov. --- Odious ideas are not entitled to hide from criticism behind the human shield of their believers' feelings. -- Richard Stallman signature.asc Description: This is a digitally signed message part.
Bug#694730: ITP: libsass -- A C implementation of a Sass compiler
I think "libsass" should be built with "--enable-tests" but it will require "sassc" and "sass-spec" test set. "sassc" needs "libsass" so to avoid circular dependency I think "libsass" and "sassc" shall be produced from single source package. Also "sass-spec" will be required on build-time so perhaps it would make sense to package "sass-spec" as standalone package and Build-Depend on it. Here is the link to upstream repository for "sass-spec": https://github.com/hcatlin/sass-spec Besides it would be nice if sass packages will be maintained in collab-maint repositories... -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736144: python-webm: needs update for libwebp5
On Fri, 24 Jan 2014 11:47:41 Jonathan Nieder wrote: > I've rebuilt python-webm and uploaded to DELAYED/5 to fix this. If I > should cancel the upload or push to collab-maint and move it to > DELAYED/0, please don't hesitate to let me know. Many thanks for your help Jonathan. Please push updated changelog to collab-maint repository if/when convenient. Any DELAYED/* (at your preference) uploads are welcome. Thanks for providing diff and for re-building my package. (I lost this bug in the pile of other emails)... -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B --- Good luck happens when preparedness meets opportunity. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733391: abiword: FTBFS: itex2MML.y:298:25: error: 'ret_str' undeclared (first use in this function)
On Wed, 29 Jan 2014 15:21:46 Markus Koschany wrote: > It appears the FTBFS is caused by bison3 and Ubuntu applied this patch for > it. Thanks very much for this information, Markus. Too bad on this instance ubuntu developer did not trouble himself sharing the improvement with us or even with upstream. I'd like to think that it was a mere negligence rather than agenda to stay ahead of us with their "added value"... :( -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- The gods offer no rewards for intellect. There was never one yet that showed any interest in it. -- Mark Twain, 1900 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727084: #727084: pyabiword: libabiword-3.0 mini-transition
In order to fix RC bug I just uploaded abiword-3.0.0 to "unstable" hence I'm raising severity of this bug to "serious"... -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737384: Should use GTK+2 useful for LXDE and Xfce users
On Sun, 2 Feb 2014 11:42:22 Mateusz Łukasik wrote: > since 2.0 version galculator uses GTK+3 libralies, but it isn't good for > LXDE and Xfce How/why it isn't good? Last time I checked galculator were looking just fine in XFCE... Did you check with upstream if he wants to continue supporting GTK-2? IMHO there is no harm in moving to GTK-3 and the dependency burden from GTK-3 is little... -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- It is impossible to imagine Goethe or Beethoven being good at billiards or golf. -- H. L. Mencken -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#717500: #717500 mesa: Please add support for OpenCL/GalliumCompute
Thank for your work on OpenCL support in Mesa. Regarding patch, please remember to add "Provides: opencl-icd" to package "libopencl1-mesa". This is necessary for packages depending on ICD loader(s) (e.g. "python-pyopencl" and others). -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- Democracy is a pathetic belief in the collective wisdom of individual ignorance. -- H. L. Mencken -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system decision-making concerns
Dear all, I'm sincerely grateful to technical committee members for their dedication and relentless effort to thoroughly research and understand the issue in order to make the best decision possible. Although most arguments for and against various init systems were already presented I think I still have something to add. I apologise in advance to some who might consider my feedback to be obvious or redundant. This is the first time ever I'm sharing my concerns regarding init system for Debian. I think well-balanced decision on this subject would benefit from not being too technical. For instance due to controversial contributor's agreement Upstart is pretty much defunct project. Many contributors prefer to spend their time on something else rather than Upstart. If adopted Upstart will likely turn into a big liability for Debian. The very survival of Upstart may depend on whether we going to be involved or not. Canonical/Ubuntu would be very happy to use Debian resources for Upstart as if they succeed in "selling" Upstart to Debian they would be able to offload (i.e. outsource) a significant chunk of effort that they have to dedicate to Upstart development and maintenance otherwise. It is quite possible that Ubuntu might reduce their involvement to Upstart (and "allow" Debian to deal with problems) while they are likely to spend more of their resources formerly allocated to Upstart to contribute to other areas of "added value". (IMHO the only major Ubuntu sell point is a concept of "added value" on top of Debian.) In my opinion Canonical/Ubuntu will benefit the most from Upstart adoption in Debian. Considering the possibility that in the future Ubuntu might abandon Upstart, Debian may end up with unwanted/obsolete init system. Since Upstart future is uncertain I fear that we might waste a lot of precious resources for Upstart and/or potentially became de-facto upstream for Upstart. IMHO from this prospective Upstart shall not be considered as alternative init system at all. Indeed I'm concerned about conflict of interests from DDs affiliated with Canonical and Ubuntu. When they advocate for Upstart I doubt they have Debian's best interests in mind. There is a danger for Debian to be overrun by outsiders or to fall under their influence even if some of them are working on both sides. Besides we can learn from OpenSUSE where Upstart was replaced with Systemd. Even without much investigation it should be fairly clear that there are good reasons not to use Upstart and to prefer something else. As for Systemd I do not fear its adoption. On the bright side it would be nice to reduce our differences with other distros in that area. Systemd may open some exciting opportunities to cooperate and join the efforts with other influential distros. Our users may benefit from feature rich init system and its adoption might make it easier for new users to switch to Debian. It doesn't look like Systemd survival will be influenced much from Debian involvement so from non-technical prospective Systemd is better for us due to strong upstream and wide(r) adoption. Of course there are concerns regarding integration between Systemd and GNOME but that's a different issue and perhaps not a major one as long as we use GNOME as default desktop environment. Besides GNOME already became notorious for being intrusive (e.g. it depends on "pulseaudio" etc.). Also I'd like to notice that shopping for most feature-rich init system might be not our goal after all. OpenRC may be the safest choice that might satisfy majority of developers as it appears to have the least number of objections. I have impression that OpenRC have far less passionate opponents than Systemd. Finally I'm sure everybody is already getting exhausted by long debates about this topic. At this point it might be tempting to approach on decision, any decision, to put this to end. This is a way to make mistakes of judgement. Unless there is a rush we all need to slow down and perhaps even take a break for several weeks to clear our heads and make a balanced, well thought decision. Taking break may be beneficial for the quality of decision making. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- Odious ideas are not entitled to hide from criticism behind the human shield of their believers' feelings. -- Richard Stallman signature.asc Description: This is a digitally signed message part.
Bug#738550: RM: ifenslave-2.6 -- ROM; obsolete, replaced by "ifenslave"
Package: ftp.debian.org Severity: normal Please remove source package "ifenslave-2.6" from "unstable". It was completely replaced by "ifenslave" (which now builds transitional binary package "ifenslave-2.6"). What's left of source package "ifenslave-2.6" in "unstable" is my incorrect attempt to convert it to transitional package which is now completely redundant. Thank you. Regards, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#731640: pyrit: please provide OpenCL addon
Package: pyrit Version: 0.4.0-2 Severity: normal Please provide OpenCL addon. At the moment "pyrit" recognise only CPU cores. It is quite confusing that package description mention OpenCL functionality which is, in fact, not available. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732066: [Pkg-bitcoin-devel] Bug#732066: Bug#732066: can you please also package cgminer 3.7.2 (along with the latest version)?
On Sat, 14 Dec 2013 08:19:57 Ariel wrote: > On Fri, 13 Dec 2013, Scott Howard wrote: > > bfgminer is in the NEW queue, it's pending acceptance into Debian: > > http://ftp-master.debian.org/new/bfgminer_3.6.0-1.html > > > > Once bfgminer is in Debian, could you try it and see if that fits your > > needs? > > Sure. Is there any way for me to download it and build it myself? (Since > it's still not accepted yet.) You can checkout the following repository: http://anonscm.debian.org/gitweb/?p=pkg-bitcoin/bfgminer.git Let us know if need build instructions. > None of those are 3.7.2 - but it doesn't matter, I'm suggesting having > that version as a first class package. We disagree. :) By definition cgminer 3.7.2 became a "second grade" software since upstream maintainer dropped the very functionality that you need. We have neither interest nor resources to maintain old version of cgminer that upstream himself declared as "unmaintained". > Unless you are saying the bfgminer is better in every way and there > is no point in the old cgminer version? Perhaps not in every way but regarding GPU mining bfgminer it certainly better. > But if so why have cgminer at all (at any version)? Although there are lot of similarities between cgminer and bfgminer (they have common ancestor) at this time the reason to have both packages might be to support broader range of mining devices. Initially I introduced cgminer because I was not aware of bfgminer. Now I tend to think that it was a mistake but last time I checked cgminer had support for some devices that bfgminer don't recognise yet. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732084: RFS: slowhttptest/1.6-1 [ITP] -- Application layer Denial of Service attacks simulation tool
Hi Neutron, On Sat, 14 Dec 2013 05:30:51 Neutron Soutmun wrote: > I am looking for a sponsor for my package "slowhttptest" Nice, thank you for your work. :) I hope you'll forgive me for pedantic nitpicking but let's fix the following minor issues before we upload: * Standards 3.9.4 (expected current version 3.9.5). * Needless versioned Build-Depends on debhelper (this exact version is in "stable"). Besides is there are any features of this particular version is in use? * Short package description starts with capital letter (lowercase would be better). Thanks. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#732141: RFP: zint -- Zint barcode studio - utilities and library for barcoding
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Package name: zint Version: 2.4.3 Upstream Author: Robin Stuart URL: http://sourceforge.net/projects/zint/ License: GPL-2+, BSD-2-clause Description: Zint barcode studio - utilities and library for barcoding Zint is a barcode encoding and image generating library. It currently features support for over 50 symbologies including Australian Post 4-state codes (redirect, reply-paid, routing, standard customer), Aztec Code (ISO 24778), Aztec Runes, Channel code, Codabar, Code 11, Code 128 (ISO 15417), Code 16k, Code 2 of 5 (Data Logic, IATA, Industrial, Interleaved, Matrix), Code 32 (Italian Pharmacode), Code 39 (ISO 16388), Code 39 Extended, Code 49, Code 93, Code One, Databar (Expanded, Expanded Stacked, Limited, Stacked Omnidirectional), Data Matrix (ISO 16022), Deutsche Post (Identicode, Leitcode), Dutch Post KIX, EAN-14, European Article Number (EAN), Facing Identification Mark (FIM), Flattermarken, Grid Matrix, ITF-14, Internation Standard Book Number (ISBN), Japanese Postal Barcode, Korean Postal Barcode, LOGMARS, Maxicode (ISO 16023), MicroPDF417 (ISO 24728), Micro QR Code, MSI Plessey, NVE-18, PDF417 (ISO 15438), Pharmacode (2-track, Zentralnummer (PZN)), PLANET, Postnet, QR Code (ISO 18004), Royal Mail 4-state Barcode, Telepen, Telepen Numeric, UK Plessey, Universal Product Code (UPC-A, UPC-E), USPS Intelligent Mail as well as HIBC. . Also included are Unicode translation for symbologies which support Latin-1 and Kanji character sets, full GS1 data support including verification and automated insertion of FNC1 characters and support for encoding binary data including NULL (ASCII 0) characters. Zint encode input data in a barcode and save as a PNG, EPS or SVG file. Packaging is practically completed and available from http://anonscm.debian.org/gitweb/?p=collab-maint/zint.git Source package produces the following binary packages: * zint"command line utility to encode data in barcode symbols" * zint-qt "Zint Barcode Studio, a QT frontend to zint" * libzint2.4 "library for encoding data in barcode symbols" * libzint-dev "Zint development files" * zint-dbg"Zint -- debugging symbols" -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#732084: RFS: slowhttptest/1.6-1 [ITP] -- Application layer Denial of Service attacks simulation tool
On Sun, 15 Dec 2013 14:38:48 Prach Pongpanich wrote: > It's missing '/gitweb' in Vcs-Browser field. Yeah, well spotted, it is a broken URL indeed. It should be Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/slowhttptest.git -- All the best, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718272: [Pkg-bitcoin-devel] Bug#718272: Bug#718272: Bitcoin still not ready for stable release in Debian
Hi Scott, For your information I have a case that you might find interesting: Zabbix did not meet release criteria and was removed from "testing" just before release of Wheezy. Ever since yours truly was maintaining it in wheezy-backports. Why wouldn't we seek backports manager(s)' permission to provide "bitcoin" in wheezy-backports? -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726501: mysql-workbench: Crash on adding new table to empty EER diagram
Dear Peter, On Wed, 16 Oct 2013 20:40:46 Peter Spiess-Knafl wrote: > mysql-workbench is crashing when I try to add a new table into an (yet) empty > EER diagram. It tried it several times, evertime the crash happened. > > Can you confirm this behaviour? Actually I can't... Could you please advise step-by-step how to reproduce? Can you reproduce using sample "sakila_full.mwb" model? Thank you. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- It is impossible to imagine Goethe or Beethoven being good at billiards or golf. -- H. L. Mencken -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698451: Bug:#698451: qemubuilder mounts rootfs as read-only
On Sat, 19 Oct 2013 07:45:26 Thorsten Alteholz wrote: > are you sure that your super safe version of the patch really works? > > I applied it here and still got the "Read-only file system"-error. Yes, it work for me on 'mipsel'. Remember that patch will only fix new images (i.g. '--create'). You will get read-only root if image (i.e. 'pbuilder-run') was created by unpatched qemubuilder. In this case try to '--login' and fix problem manually as described in message#10: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698451#10 I hope this helps. -- All the best, Dmitry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727069: pvpgn: co-maintainership
Package: src:pvpgn Version: 1.8.1-2.1 Severity: wishlist Dear Radu, I'd like to give you a hand with "pvpgn" package which needs a little care. I took some time to update it and I've managed to fix all bugs, update package for new upstream version (with SQL injection fixes) and for new release of support files. I introduced sqlite support, logrotate, unbundled libcdb and did many other changes (please find full list of changes below). You're welcome to review my work in the following repository: http://anonscm.debian.org/gitweb/?p=users/onlyjob/pvpgn.git I'm happy to take responsibility for those changes so I took liberty to add myself to Uploaders. With your permission I'd like to upload updated package or you're welcome to take any of my improvements for your future upload. What do you think? Thanks. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B pvpgn (1.8.5-1) unstable; urgency=low * New upstream release [February 2009]. * Install upstream changelog. * Added new watch file, based on watch written by Bart Martens. + lintian-override for "debian-watch-file-should-use-sf-redirector". * Updated Homepage URL. * Standards to 3.9.4 * Source to "3.0 (quilt)" format. * Debhelper & compat to version 9. * dh-style rules, no longer use cdbs. * autotools-dev --> dh-autoreconf. * Dropped "libmysqlclient15-dev" alternative from Build-Depends. * Dropped worthless upstream docs (i.g. how to build instructions etc.). * Build with "--with-sqlite3"; Build-Depends: +libsqlite3-dev. * Build with all hardening. * Added new patch to enable verbose build. * Added new patch with spelling corrections. * Moved man pages to "debian/man"; corrected "hyphen-used-as-minus-sign". * pvpgn-support-installer: + updated support files' archive name + downloader fixes. + replaced hard-coded archive name with variable. + added new file "ver-ix86-1.mpq" to clean-up. + alphabetised list of files to clean. + increased verbosity of file copy/remove operations. * init.d: + init.d-script-does-not-source-init-functions. + init.d-script-missing-lsb-description. + status support. + updated list of files from "pvpgn-support-1.2.tar.gz"; fixed daemon start. + improved message about getting support files. * Updated URL to support files archive in README.Debian. * Suggests: mysql-server (Closes: #667659). * "bnetd.log" moved to "/var/log/pvpgn" (Closes: #578010). * Install logrotate config. * Fixed ladders directory (Closes: #578012). * Corrected paths (dirs should be in "/var/lib/pvpgn", not in "/var/lib/pvpgn/files"). * Unbundle tinycdb: + added new patch to link with libcdb. + Build-Depends: +libcdb-dev. + Recommends: +tinycdb (provides `cdb`). - no longer install `bncdb` and its man page (use `cdb` instead). * "debian/copyright" to copyright-format-1.0 + audit. * Added myself to Uploaders. -- Dmitry Smirnov Tue, 22 Oct 2013 05:42:40 +1100 signature.asc Description: This is a digitally signed message part.
Bug#727069: pvpgn: co-maintainership
On Tue, 22 Oct 2013 12:45:06 Radu Spineanu wrote: > Go for it. Thank you. :) Would you mind if I also push repository to collab-maint (and update the package Vcs fields accordingly)? -- Cheers, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726437: Screen resolution not restored
Dear Bernhard, On Wed, 16 Oct 2013 05:42:24 Bernhard wrote: > There is a problem with the screen resolution after ending the game. > I use Debian testing "jessie" with gnome desktop. > > If i start the game in full screen mode and end the game, the resolution > of the desktop is not restored. > The gnome desktop remains in the low resolution from the game. This is not happening on my side. Could you help me to reproduce please? If you start the game from console what does it print just before exit? Also it is much better to report bugs using `reportbug` because it provides vital information about installed libraries etc. Here you can read more about reporting bugs: http://www.debian.org/Bugs/Reporting http://raphaelhertzog.com/2011/07/11/7-tips-to-file-useful-debian-bug-reports-and-get-your-problem-solved/ -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727069: pvpgn: co-maintainership
Package: src:pvpgn Thanks, Radu. Package uploaded, repository moved to http://anonscm.debian.org/gitweb/?p=collab-maint/pvpgn.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727084: src:python-abiword: libabiword-3.0 mini-transition
Package: src:python-abiword Version: 0.8.0-11 Severity: normal Dear Jonas, "libabiword-3.0" is in experimental and "python-abiword" is the only reverse dependency that is still bound to "libabiword-2.9". Please consider updating your package for this mini-transition. With minimum changes to Build-Depends and to "configure.in" (see below) I was able to build "python-abiword" successfully with "libabiword-3.0", however I can't test the run-time functionality of the re-built package. --- a/configure.in +++ b/configure.in @@ -16,9 +16,9 @@ AC_STDC_HEADERS AM_PROG_LIBTOOL AC_C_CONST -abi_pkg='abiword-2.9 >= 2.9.0' +abi_pkg='abiword-3.0 >= 3.0.0' PKG_CHECK_MODULES(ABIWORD, "$abi_pkg") AC_SUBST(ABIWORD_CFLAGS) AC_SUBST(ABIWORD_LIBS) Thanks. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698008: fglrx-driver: Xorg crash on window resize.
The attached script from [1] may be helpful to reproduce the problem.
Just start the application and resize (enlarge) its window.
I also made a list of possibly related bugs:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698008
https://bugs.freedesktop.org/show_bug.cgi?id=57534
http://ati.cchtml.com/show_bug.cgi?id=687
http://ati.cchtml.com/show_bug.cgi?id=633
http://ati.cchtml.com/show_bug.cgi?id=567
http://ati.cchtml.com/show_bug.cgi?id=657
https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1151242
I'm not sure where would be the best place to forward this test
case...
[1]: http://xpra.org/trac/ticket/327#comment:10
Thanks.
--
Regards,
Dmitry Smirnov
GPG key : 4096R/53968D1B
---
Odious ideas are not entitled to hide from criticism behind the human
shield of their believers' feelings.
-- Richard Stallman
#!/usr/bin/env python
import gtk
from gtk import gdk
import cairo
import gobject
CRASH = True
class ClientWindow(gtk.Window):
def __init__(self, w, h):
gtk.Window.__init__(self, gtk.WINDOW_TOPLEVEL)
self.set_size_request(w, h)
self.set_app_paintable(True)
self.add_events(gdk.STRUCTURE_MASK)
self._backing = None
self.new_backing(w, h)
def new_backing(self, w, h):
print("new_backing(%s, %s)" % (w, h))
if self._backing is None:
self._backing = Backing()
self._backing.init(w, h)
def do_configure_event(self, event):
print("do_configure_event(%s)" % event)
gtk.Window.do_configure_event(self, event)
_, _, w, h, _ = self.get_window().get_geometry()
self.new_backing(w, h)
class Backing(object):
def __init__(self):
self._backing = None
def init(self, w, h):
old_backing = self._backing
self._backing = gdk.Pixmap(gdk.get_default_root_window(), w, h)
cr = self._backing.cairo_create()
cr.set_source_rgb(1, 1, 1)
if CRASH and old_backing is not None:
cr.set_operator(cairo.OPERATOR_SOURCE)
cr.set_source_pixmap(old_backing, 0, 0)
cr.paint()
old_w, old_h = old_backing.get_size()
if w>old_w:
cr.new_path()
cr.move_to(old_w, 0)
cr.line_to(w, 0)
cr.line_to(w, h)
cr.line_to(old_w, h)
cr.close_path()
cr.fill()
if h>old_h:
cr.new_path()
cr.move_to(0, old_h)
cr.line_to(0, h)
cr.line_to(w, h)
cr.line_to(w, old_h)
cr.close_path()
cr.fill()
else:
cr.rectangle(0, 0, w, h)
cr.fill()
gobject.type_register(ClientWindow)
def main():
window = ClientWindow(400, 200)
window.show()
gtk.main()
if __name__ == "__main__":
main()
Bug#719559: Fwd: Bug#719559: cuetools: filenames are split on spaces
Hi Martin, When convenient could you please have a look at the bug #719559 (below)? Reporter claims that your patch causing regression so perhaps you're the best person to ask for advise. Thank you. Package: cuetools Version: 1.3.1-13 Dear Maintainer, it appears that the recent commit to fix bug 655078 caused unexpected name splitting the following line in the function main appears to serve no purpose and removing it solves the problem set -- $FILES -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- Good luck happens when preparedness meets opportunity. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727604: zabbix-agent: Bad default hostname
On Fri, 25 Oct 2013 00:48:36 Petr Shestov wrote: > By default zabbix_agentd.conf include string: > "Hostname=Zabbix server" > It appears to be more appropriate to leave Hostname undefined so default > value (which equals > system.hostname) will be used. Arguably it could be reasonable default but here we merely inherit upstream defaults. On this instance I do not wish to derive from upstream so you need to convince upstream to change their defaults first. Besides "Hostname" in agent configuration is not a host name but an identifier that is used by zabbix server to check agent through proxy or push active checks. Sometimes using host name as such identifier is a natural thing but in many cases it is desirable to have unique Hostname that is used only by zabbix. For that reason I doubt if Hostname=host_name is a good default in case when we want to use non-host-name IDs in zabbix. Current default helps to distinguish those two and encourages admins to set their own defaults. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650196: timebrowse: changing back from ITP to RFP
retitle 650196 RFP: timebrowse -- NILFS Snapshot Manager/Windows VSS like Nautilus extension noowner 650196 -- I've decided to return this package to RFP state because nobody expressed any interest to this package since my ITP. I reckon NILFS2 is not very popular even though it is great and very stable file system. I committed complete packaging to the following repository: http://anonscm.debian.org/gitweb/?p=collab-maint/timebrowse.git Source package produces the following binary packages: * nilfs-ss-manager - NILFS Snapshot Manager * nautilus-timebrowse - nautilus extension to access NILFS2 snapshots "nilfs-ss-manager" works well. "nautilus-timebrowse" do not work at all (it used to work but now it needs to be updated for python gtk mess and new nautilus). Anyway it is not very useful because with "nilfs-ss-manager" NILFS2 snaphots can be accessed using any file manager. Perhaps "nilfs-ss-manager" can be shipped alone. Upstream status: dormant with no commits since April 2011. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- Science embraces facts and debates opinion; religion embraces opinion and debates the facts. -- Tom Heehler, The Well-Spoken Thesaurus. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727703: mc: down arrow cursor movement broken in mcedit
On Sat, 26 Oct 2013 08:48:49 Roy Fullmer wrote: > I found the culprit! It is a file named mc.macros which somehow got > into my /root/.local/share/mc directory. I see, perhaps it would be safe to close this bug as there is nothing for maintainer to do about it? > I don't know if I should laugh or cry. No worries, it happens with all of us eventually. :) -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728198: devscripts: debuild (& others) must reject debian/rules actions on unpatched source trees
Dear Ximin, While I agree with you that it would be nice to have a big fat warning when `debuild` attempts to build package with no patches applied, I must mention that sometimes current behaviour is quite useful. When you're hacking the source tree and finalising your patches it is convenient that `debuild -b` is not trying to re-apply them. This is only happening when you're building with "-b" option. Without "-b" patches will be applied and `debuild` will fail on any error. Regarding #728097 that you mentioned you should have build your package in clean environment (e.g. using pbuilder) in first place. Many other problems will happen if you're not building in clean chroot before upload. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728198: devscripts: debuild (& others) must reject debian/rules actions on unpatched source trees
On Wed, 30 Oct 2013 04:14:00 Ximin Luo wrote: > I'm not sure if I follow. It is really simple. When you build using `debuild -b` you may have only some patches applied in source tree or you may have pending changes that are not yet written to patch files using `quilt refresh`. So you can build package, try it, and then refresh your patches if they are ready. `debuild -b` just builds the package and leaves patch management to you which is convenient when you need to apply just some patches (but not all of them) or experiment with source tree changes. I hope that makes sense. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- Platitude: an idea (a) that is admitted to be true by everyone, and (b) that is not true. -- H. L. Mencken -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728270: quiterss: Crashes on key press randomly when connected through torify.
> QuiteRSS crshes randomly at a key press randomly when run w/ torrify Sorry but I have no idea what "torrify" is and how can it affect QuiteRSS. Please provide detailed instructions how to reproduce, including backtrace (you will need to install "quiterss-dbg" package). See https://wiki.debian.org/HowToGetABacktrace Also could it be the same crash as #728219? -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- It is impossible to imagine Goethe or Beethoven being good at billiards or golf. -- H. L. Mencken -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734597: litecoin: Litecoin still builds with system LevelDB
On Wed, 8 Jan 2014 23:22:37 Micha wrote: > It would be better to change Litecoin to use the bundled LevelDB, > for the same reason as that is already being done with Bitcoin. Actually I disagree that it would be better to use bundled LevelDB. Would you be able to provide short summary of reasons why do you think it would be better? I'm not convinced by reason(s) highlighted in README.source in bitcoin packaging. Marking as "wontfix" for now. -- Regards, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734571: mc: [copy&] paste adds extra characters
Dear Drew, I don't see how it could be bug in MC. Certainly this is not happening in `konsole` in KDE. Feel free to reassign to Gnome Terminal, otherwise I'll close this bug few weeks later. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734807: xpra: Python errors displayed when starting xpra (problems with Python modules)
Dear Peter, On Fri, 10 Jan 2014 10:16:55 Peter Paluch wrote: > After xpra attach is called, a number of Python error messages is displayed, > suggesting that some modules xpra tries to import do not exist: Those are just harmless warnings that are safe to ignore. There is nothing we can do about them but you might find interesting to read the following corresponding bugs: * http://xpra.org/trac/ticket/481 * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703585 -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734475: please provide an init script for xpra
Dear Christian, On Wed, 8 Jan 2014 01:00:11 Christian Lecherbauer wrote: > I use xpra to forward windows from a virtual machine. The only purpose > of this VM is to run some untrusted Desktop apps (e.g. eclipse). In > this case it would be nice, if xpra would be started like a daemon on > system boot. At the moment I'm convinced that we don't need init script for Xpra. If you want to initialise Xpra session automatically I'd suggest to invoke Xpra from "/etc/rc.local" as workaround. Marking as "wontfix" for now. > Is it necessary that xpra runs as a regular user or could it run as a > new "xpra" user? This is up to you, for Xpra there is no difference. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735515: please do not allow post-build tests to fail on all architectures
Source: leveldb Version: 1.14.0-3 Severity: wishlist Tags: patch I understand that currently post-build tests are allowed to fail on all architectures due to problems on "mips". This is overkill and with the following (sample) code we can isolate override_dh_auto_test and ignore failure(s) only on affected architecture: override_dh_auto_test: ifeq ($(DEB_BUILD_ARCH),mips) @echo " will not abort on test(s) failure " -dh_auto_test else dh_auto_test endif Please consider making tests fatal on supported architectures. LevelDB is critical for some applications so I hope that running tests suite might help to build more confidence in LevelDB's correct functioning. Thanks. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622164: RFA: cuetools -- tools for manipulating CUE/TOC files
On Sun, 10 Nov 2013 15:48:07 GUO Yixuan wrote: > I wish to adopt this package. Thank you for your intention to take care of this package. > To Dmitry Smirnov: I noticed your recent uploads and conversion to git > repo, I think I can try to make that repo more suitable for use with > git-buildpackage (by adding upstream and pristine-tar), as a first step. Repository is already quite suitable for git-buildpackage provided that you have orig.tar in tarball-dir and the following in your .gbp.conf: [git-buildpackage] tarball-dir = ../ Personally I have concerns for repository size and for risk of having non-DFSG files in upstream branch. Although in this particular case the above concerns are admittedly weak I prefer to keep my upstream branch local and do not push it to public repository. I'm yet to learn why git-buildpackage fans merge upstream files to "master" branch so often -- I think it is quite inconvenient and I don't know what it is good for... Anyway you're the boss, so fell free to do as you like with care. ;) > Thank you for your QA works! Thanks for your kind words. :) -- Cheers, Dmitry Smirnov. --- Platitude: an idea (a) that is admitted to be true by everyone, and (b) that is not true. -- H. L. Mencken -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729204: RFP: iowatcher -- utility to visualize block I/O patterns
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Package name: iowatcher Version: 1.0 Upstream Author: Chris Mason URL: https://www.kernel.org/pub/linux/kernel/people/mason/iowatcher License: GPL-2 Description: utility to visualize block I/O patterns iowatcher generates graphs from blktrace runs to help visualize IO patterns and performance. It can plot multiple blktrace runs together, making it easy to compare the differences between different benchmark runs. If/when matured "iowatcher" can become successor to "seekwatcher". Initial packaging is committed to http://anonscm.debian.org/gitweb/?p=collab-maint/iowatcher.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622164: RFA: cuetools -- tools for manipulating CUE/TOC files
On Sun, 10 Nov 2013 16:45:04 GUO Yixuan wrote: > Then I'm going to ask for access to collab-maint. (I think it's ok to > use collab-maint even if I'm the only maintainer, is that right?) Of course. Not only it is OK but also it's a best practice as all Debian Developers and most maintainers would be able to easily become you co-maintainers. :) -- Cheers, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729280: dput-ng: uploads to wrong server
Package: dput-ng Version: 1.6 Severity: important After replacing "dput" with "dput-ng" I was quite surprised when the latter uploaded source package to wrong server. Here is what I have in the beginning of my "~/.dput.cf": [DEFAULT] default_host_main = debmain [debmain] fqdn = debmain.local method = scp incoming = /var/www/debian/incoming allow_unsigned_uploads = 0 progress_indicator = 2 [mentors] fqdn = mentors.debian.net incoming = /upload method = http allow_unsigned_uploads = 0 progress_indicator = 2 [mentors-ftp] fqdn = mentors.debian.net login = anonymous progress_indicator = 2 passive_ftp = 1 incoming = / method = ftp allow_unsigned_uploads = 0 Contrary to my expectations (and "dput" behaviour) "dput-ng" uploaded source package to mentors instead of default server without any warnings or errors: Uploading [package] using ftp to mentors-ftp (host: mentors.debian.net; directory: /) --- Package information. --- Depends (Version) | Installed ==-+-=== python | 2.7.5-5 python-dput (= 1.6) | 1.6 -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729280: dput-ng: uploads to wrong server
Hi Paul, Thanks for perfect bug handling. :) On Tue, 12 Nov 2013 04:24:42 Paul Tagliamonte wrote: > I've commited a fix[1] to my GitHub while git.d.o is down. It'd be nice > if you could confirm this branch fixes the issue. I've been able to > duplicate the issue, and fix it locally, so I think it's fine. I'll > upload soon. > > [1]: > https://github.com/paultag/dput-ng/commit/068febcac691283f75479ebabcf8c6e6343dcc27 It works for me now. Thank you. -- Regards, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729943: jarwrapper: pass only 48 chars of Debian-Java-Parameters
Package: javatools
Version: 0.45
Severity: important
Tags: patch
"jarwrapper" parses MANIFEST.MF line-by-line using `sed`. However
java tools wrap manifest on 72nd character (and add space) so after
parsing only 48 characters (72 - length("Debian-Java-Parameters: "))
of Debian-Java-Parameters are passed to application.
In the attached MANIFEST.MF I'm trying to pass
Debian-Java-Parameters: -Dlogback.configurationFile=/etc/zabbix/logback.xml
-server
but jarwrapper strip it to
-Dlogback.configurationFile=/etc/zabbix/logback.
To fix this issue we need to merge multi-line values in MANIFEST.MF
using the following filter:
perl -0pE 's{\r?\n\s}{}gsm'
or replace incorrect use of `sed` with the following patch:
--- jarwrapper 2013-11-19 15:12:16.833880666 +1100
+++ /usr/bin/jarwrapper 2013-11-19 15:47:39.597893120 +1100
@@ -14,10 +14,10 @@
TEMP="`mktemp -d`"
(cd "$TEMP"; fastjar xf "$JAR" META-INF/MANIFEST.MF)
-NEW_JAVA_HOMES="`sed -n '/^Debian-Java-Home:/s/^[^:]*: *//p'
"$TEMP/META-INF/MANIFEST.MF"`"
-JAVAOPTS="`sed -n '/^Debian-Java-Parameters:/s/^[^:]*: *//p'
"$TEMP/META-INF/MANIFEST.MF"`"
+NEW_JAVA_HOMES="$(perl -0nE 's{\r?\n\s}{}gsm; print $1 if
m{^Debian-Java-Home:\s*([^\r\n]+)}m;' "$TEMP/META-INF/MANIFEST.MF")"
+JAVAOPTS="$(perl -0nE 's{\r?\n\s}{}gsm; print $1 if
m{^Debian-Java-Parameters:\s*([^\r\n]+)}m;' "$TEMP/META-INF/MANIFEST.MF")"
rm -rf "$TEMP"
for i in $NEW_JAVA_HOMES; do
if [ -x "$i/bin/java" ]; then
I tested the above patch with dos and unix line endings in
"MANIFEST.MF".
--
Best wishes,
Dmitry Smirnov
GPG key : 4096R/53968D1B
---
However beautiful the strategy, you should occasionally look at the
results.
-- Winston Churchill
Manifest-Version: 1.0
Created-By: 1.6.0_27 (Sun Microsystems Inc.)
Debian-Java-Parameters: -Dlogback.configurationFile=/etc/zabbix/logback.
xml -server
Class-Path: /usr/share/java/json.jar /usr/share/java/logback-core.jar /u
sr/share/java/logback-classic.jar /usr/share/java/slf4j-api.jar
Main-Class: com.zabbix.gateway.JavaGateway
Bug#729973: javahelper: please support debhelper-style option "-p mypkg"
Package: javahelper Version: 0.45 Severity: minor dh_* tools can be invoked with "-p" option in the following ways: dh_installinit -v -pmypkg dh_installinit -v -p mypkg Javahelper support only first variant: jh_depends -v -pmypkg But it just do not do anything if there is a space between "-p" and "mypkg": jh_depends -v -p mypkg This behaviour is slightly confusing so it would be nice to recognise DH-compatible syntax. Thanks. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728219: Bug#728270: quiterss: Crashes on key press randomly when connected through torify.
On Sat, 23 Nov 2013 20:25:05 Ста Деюс wrote: > I run it as follows: > > /bin/torify /usr/bin/quiterss > > that way i get it using TOR and unless that i can not make it working > through its networking settings as i have already mentioned. > > > https://wiki.debian.org/HowToGetABacktrace > > I have installed the debug package but since then it does not crash for > weeks now. :o) > > > Also could it be the same crash as #728219? > > I believe. no. > > Thank you. > Thanks for your feedback. Please remember to always reply to bug as keeping public records is more important than to email to me personally. :) Upstream fixed one problem with crash after long run but I hardly experienced it since I had QuiteRSS working for several weeks without restart. Whatever the problem is it will be probably fixed with next upstream release. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B --- Democracy is a pathetic belief in the collective wisdom of individual ignorance. -- H. L. Mencken -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730432: nginx: please build "nginx-full" with Spdy support
Package: src:nginx Version: 1.4.3-2 Severity: wishlist At the moment Spdy support is enabled only in package "nginx-extra" but not in "nginx-full". Perhaps I do not understand well enough justification behind decision to include Spdy support only to "nginx-extras" but it appears to me that "nginx-full" shall have Spdy support too since Spdy is merely an (optional) improvement to HTTPS performance. Spdy needs no additional dependencies. When I built nginx-full with Spdy the only dependency that changed as result is the following: "zlib1g (>= 1:1.1.4)" --> "zlib1g (>= 1:1.2.0)" Spdy is not enabled by default in run time. It must be activated in configuration so I believe it should be safe to build "nginx-full" with Spdy support. Thanks. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676396: node-jsdom
Hi David, Can I give you a hand with "node-jsdom"? We need its newer version for d3 [1], see ITP #676396: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676396 Thank you. [1]: http://d3js.org/ -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#751655: [Pkg-bitcoin-devel] Bug#751655: bfgminer: Please upload new version: 4.2.0
On Sun, 15 Jun 2014 19:43:27 Luke Dashjr wrote: > That's under the ccan-upstream/ path I mentioned. I'm not sure why it's > failing there, though, since the file is included in all the txz files. :/ > > -rw-rw-r-- luke-jr/luke-jr 11804 2014-02-06 03:50 bfgminer-4.0.0/ccan- > upstream/ccan/opt/helpers.c Unfortunately, ccan-upstream/* files are missing from tarball that I downloaded from github: https://github.com/luke-jr/bfgminer/archive/bfgminer-4.2.0.tar.gz I realise that complete tarballs are no longer to be found on Github hence I'm switching package watch file to monitor the following location: http://luke.dashjr.org/programs/bitcoin/files/bfgminer/ -- All the best, Dmitry Smirnov. --- Every decent man is ashamed of the government he lives under. -- H. L. Mencken signature.asc Description: This is a digitally signed message part.
Bug#751655: [Pkg-bitcoin-devel] Bug#751655: Bug#751655: bfgminer: Please upload new version: 4.2.0 [WONTFIX]
Bad news: I had a look at tarball which includes ccan-upstream/* files and I must say that I dramatically underestimated the mess which is there. There are so many files and licenses but also tarballs with who-knows-what. IMHO packaging this mess do not worth the effort -- it is simply too time consuming not to mention that I'm uncomfortable to upload it as is without DFSG-cleanup. I committed updated debian/copyright with all changes except for ccan- upstream/*. For now I leave package as is in hope that upstream tarball will undertake cleanup to leave only what's necessary under "ccan-upstream" till next release. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- Truth — Something somehow discreditable to someone. -- H. L. Mencken, 1949 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699141:
On Wed, 18 Jun 2014 09:07:51 you wrote: > Hi, the new get-orig-script should address this issue, sorry I wrote it > prior to see your bug report > > I'm closing it now, feel free to reopen if you have an even better approach `get-orig-script` is a non-standard way to fetch source archive. It would be better if you implement it as "get-orig-source" target in "debian/rules" as mandated by policy §4.9. See more details in http://wiki.debian.org/onlyjob/get-orig-source I think policy compliance matters for such case as it will be better to be able to get source archive in a unified manner. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- No person, no idea, and no religion deserves to be illegal to insult, not even the Church of Emacs. -- Richard Stallman signature.asc Description: This is a digitally signed message part.
Bug#751655: [Pkg-bitcoin-devel] Bug#751655: Bug#751655: bfgminer: Please upload new version: 4.2.0
On Mon, 16 Jun 2014 15:56:30 Luke Dashjr wrote:
> Actually, I had intended to minimise the tarball size since before 4.0, but
> only noticed it failed when confirming the files were there for you.
>
> Future releases will include only:
> ccan/{build_assert,cast,compiler,opt,typesafe_cb}
> licenses/{CC0,GPL-3,LGPL-2.1}
>
> It is also safe to delete anything other than these in the current releases.
Thanks Luke, I cleaned-up tarball as advised and uploaded.
Besides "no_blkmaker.patch" was necessary to avoid error
Makefile.am:79: error: required directory ./libblkmaker does not exist
with removed "libblkmaker" folder.
--
Cheers,
Dmitry Smirnov.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752484: redmine: ActionView::Template::Error (incompatible character encodings: UTF-8 and ASCII-8BIT)
Package: redmine Version: 2.5.1-2 Severity: normal User created new ticket (she probably pasted something from web page to description) but it is impossible to open/view due to "Internal error": Completed 500 Internal Server Error in 130.7ms ActionView::Template::Error (incompatible character encodings: UTF-8 and ASCII-8BIT): 55: <%= yield :sidebar %> 56: <%= view_layouts_base_sidebar_hook_response %> 57: 58: 59: 60: <%= render_flash_messages %> 61: <%= yield %> app/views/layouts/base.html.erb:58:in `_app_views_layouts_base_html_erb__1969665907268258752_25510160' app/controllers/issues_controller.rb:128:in `block (2 levels) in show' app/controllers/issues_controller.rb:125:in `show' This bug looks similar to upstream http://www.redmine.org/issues/10593 but fix r9330 (already in v2.5.1) appears to be insufficient. Please advise. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#744179: quiterss: Not all filters work on news headers.
Please try new version from "unstable". Besides to save maintainer's time you may also consider to report non-Debian-related bugs to upstream bug tracker: https://code.google.com/p/quite-rss/issues/list Thank you. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#744181: quiterss: Impossible to set hot keys for moving news body up or down.
Please try new version from "unstable". Besides to save maintainer's time you may also consider to report non-Debian-related bugs to upstream bug tracker: https://code.google.com/p/quite-rss/issues/list Thank you. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#744732: kmail: loss of plain text draft when HTML document attached
Package: kmail Version: 4:4.11.5-1 Severity: important Yesterday I lost plain text of en email draft. I typed new message, attached HTML file and saved email as draft. In Drafts folder I could see my email properly but when I re-opened it for editing/sending plain text email message was irreversibly replaced with content of the attached HTML document (converted to text). This is regression from kmail v1. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- --- System information. --- Architecture: amd64 Kernel: Linux 3.13-1-amd64 --- Package information. --- Depends (Version) | Installed ===-+-=== perl| 5.18.2-2+b1 kde-runtime (>> 4:4.10) | 4:4.11.3-1 kdepim-runtime(>= 4:4.10.2) | 4:4.11.5-1 kdepimlibs-kio-plugins | 4:4.11.5-4+b1 libakonadi-calendar4 (>= 4:4.11.1) | 4:4.11.5-4+b1 libakonadi-contact4 (>= 4:4.11.3) | 4:4.11.5-4+b1 libakonadi-kde4 (>= 4:4.11.3) | 4:4.11.5-4+b1 libakonadi-kmime4 (>= 4:4.11.3) | 4:4.11.5-4+b1 libakonadiprotocolinternals1 (>= 1.5.1) | 1.11.0-1 libc6 (>= 2.14) | 2.18-4 libcalendarsupport4 (= 4:4.11.5-1) | 4:4.11.5-1 libgcc1(>= 1:4.1.1) | 1:4.8.1-2 libgpgme++2 (>= 4:4.11.3) | 4:4.11.5-4+b1 libgrantlee-core0(>= 0.3.0) | 0.3.0-5 libincidenceeditorsng4 (= 4:4.11.5-1) | 4:4.11.5-1 libkabc4 (>= 4:4.11.3) | 4:4.11.5-4+b1 libkalarmcal2 (>= 4:4.8.1) | 4:4.11.5-4+b1 libkcalcore4 (>= 4:4.5.86) | 4:4.11.5-4+b1 libkcalutils4 (>= 4:4.5.86) | 4:4.11.5-4+b1 libkcmutils4 (>= 4:4.5.86) | 4:4.11.3-2 libkdecore5 (>= 4:4.4.95) | 4:4.11.3-2 libkdepim4 (= 4:4.11.5-1) | 4:4.11.5-1 libkdeui5 (>= 4:4.10.0) | 4:4.11.3-2 libkio5 (>= 4:4.5.85) | 4:4.11.3-2 libkleo4 (= 4:4.11.5-1) | 4:4.11.5-1 libkmime4 (>= 4:4.11.3) | 4:4.11.5-4+b1 libknewstuff3-4 (>= 4:4.5.85) | 4:4.11.3-2 libknotifyconfig4 (>= 4:4.3.4) | 4:4.11.3-2 libkontactinterface4 (>= 4:4.11.3) | 4:4.11.5-4+b1 libkparts4(>= 4:4.5.85) | 4:4.11.3-2 libkpgp4 (= 4:4.11.5-1) | 4:4.11.5-1 libkpimidentities4(>= 4:4.11.3) | 4:4.11.5-4+b1 libkpimtextedit4 (>= 4:4.11.3) | 4:4.11.5-4+b1 libkpimutils4 (>= 4:4.11.3) | 4:4.11.5-4+b1 libkprintutils4 (>= 4:4.4.95) | 4:4.11.3-2 libksieveui4 (= 4:4.11.5-1) | 4:4.11.5-1 libktnef4 (>= 4:4.11.3) | 4:4.11.5-4+b1 libmailcommon4 (= 4:4.11.5-1) | 4:4.11.5-1 libmailimporter4 (= 4:4.11.5-1) | 4:4.11.5-1 libmailtransport4 (>= 4:4.11.3) | 4:4.11.5-4+b1 libmessagecomposer4 (= 4:4.11.5-1) | 4:4.11.5-1 libmessagecore4 (= 4:4.11.5-1) | 4:4.11.5-1 libmessagelist4 (= 4:4.11.5-1) | 4:4.11.5-1 libmessageviewer4(= 4:4.11.5-1) | 4:4.11.5-1 libnepomukcore4(>= 4:4.9.3) | 4:4.11.5-2+b1 libpimcommon4(= 4:4.11.5-1) | 4:4.11.5-1 libqt4-dbus(>= 4:4.5.3) | 4:4.8.5+git242- g0315971+dfsg-2 libqt4-network (>= 4:4.5.3) | 4:4.8.5+git242- g0315971+dfsg-2 libqt4-xml (>= 4:4.5.3) | 4:4.8.5+git242- g0315971+dfsg-2 libqtcore4 (>= 4:4.7.0~beta1) | 4:4.8.5+git242- g0315971+dfsg-2 libqtgui4 (>= 4:4.8.0) | 4:4.8.5+git242- g0315971+dfsg-2 libqtwebkit4 (>= 2.2.0) | 2.2.1-5 libsendlater4(= 4:4.11.5-1) | 4:4.11.5-1 libsolid4 (>= 4:4.3.4) | 4:4.11.3-2 libsoprano4 (>= 2.9.0) | 2.9.4+dfsg-1 libstdc++6 (>= 4.1.1) | 4.7.2-5 libtemplateparser4 (= 4:4.11.5-1) | 4:4.11.5-1 Recommends(Version) | Installed ===-+-=== gnupg-agent | 2.0.19-2+deb7u1 gnupg2 | 2.0.19-2+deb7u1 pinentry-qt4| 0.8.1-1 OR pinentry-x11| Suggests (Version)
Bug#744735: rekonq: memory leak
Package: rekonq Version: 0.9.2-1 Severity: normal `rekonq` ate all available RAM. I think I closed it so application window dissapeared (but process remained active in memory). My system became unresponsive due to extensive swapping so I invoked task manager (htop) and found that `/usr/bin/rekonq` allocated over 32 GiB of RAM. --- System information. --- Architecture: amd64 Kernel: Linux 3.13-1-amd64 Debian Release: 7.4 -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#744382: [Ceph-maintainers] Bug#744382: librbd-dev and librados-dev does not provide correct shlibs/symbols file
Hi Michael, On Sun, 13 Apr 2014 18:32:05 Michael Tokarev wrote: > Package: librbd-dev, librados-dev > Version: 0.72.2-2 > Severity: grave > > Currently, testing+unstable has librbd version 0.72.2-2. When linking, > for example, qemu against this version of librbd, the resulting depends > on unversioned librbd1. But for example, librbd1 version 0.47.2-1 does > not provide some library symbols which are provided by 0.72.2 - eg, > rbd_aio_flush. As a result, programs linked with 0.72.2-2 version > does not work with older version of the library, and no indication of > the version needed is given. > > That to say, linking programs with librbd or librados breaks those > programs in random way. Thank you for detailed report. > This has already been reported before wheezy, this is exactly the reason > why ceph has been removed from wheezy. I haven't looked at the updated > librbd/librados before enabling ceph support in qemu. Looks like this > enabling has been done too early, since the libraries aren't yet ready > to be used. I'd like to thank you for enabling rbd support in qemu. I found it very useful and it saved me a lot of time already. Upstream released Ceph-0.79 as pre-release to 0.80 which we will be uploading to "unstable" (when released). We will include fix for this issue in 0.80-1 or perhaps even earlier if one of us find enough time to upload 0.72.2-3. By the way do you think that just using "dh_makeshlibs -V" would be sufficient? Although I committed .symbols files I've never had good experience with symbols in C++ libraries and I have concerns for potential build problems on multiple architectures... -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual. -- Galileo Galilei signature.asc Description: This is a digitally signed message part.
Bug#744382: [Ceph-maintainers] Bug#744382: librbd-dev and librados-dev does not provide correct shlibs/symbols file
On Mon, 14 Apr 2014 11:23:29 Michael Tokarev wrote: > 14.04.2014 10:47, Dmitry Smirnov wrote: > > By the way do you think that just using "dh_makeshlibs -V" would be > > sufficient? Although I committed .symbols files I've never had good > > experience with symbols in C++ libraries and I have concerns for > > potential build problems on multiple architectures... > > Yes, this has happened in the past - a naive attempt to use dh_makeshlibs -V > resulted in package FTBFS on all arches except of the one where makeshlibs > were run, due to differences in complier and architectures wrt C++ symbols. Actually I thought that "dh_makeshlibs -V" would be safe to use, safer than adding .symbols file(s) but perhas not that flexible... I'm considering to make upload of 0.72.2-3 with "dh_makeshlibs -V" -- would you recommend not to do that? How "dh_makeshlibs -V" can cause FTBFS? > I don't know ceph internals. If those C++ symbols are internal, and only > regular symbols should be exposed, maybe just hiding them all should be a > good idea. If, on the other hand, those are parts of public ABI, I'm afraid > there's no good solution except of the way you did it -- making all C++ > symbols to be part of the latest release. I wish I knew the answer to those questions. :) By the way thank you for useful comments in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679686#53 > Note that makeshlibs supports symbols.arch file in addition to symbols file, > maybe that one can be used to export (limited) set of C++ ABI. Thank you, I'll remember that. > I too have no expirience with C++ exporting and .symbols files. I found it so difficult to maintain symbols in C++ libraries so I just used "dh_makeshlibs -V" and it never failed me. > Besides, you added the two .symbols files into 0.79 package, -- maybe you > may run makeshlibs on 0.72 instead (or even on 0.44/0.48), to generate > initial .symbols files, and run mkshlibs again on new version(s) to make > additions. This way, even older lib may be used for symbols which were > present long time ago. Dunno how important it is. Will do, that's exactly what I was thinking about. Just need a bit more time to build... :) Thank you. -- All the best, Dmitry Smirnov. --- However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#744382: [Ceph-maintainers] Bug#744382: librbd-dev and librados-dev does not provide correct shlibs/symbols file
On Mon, 14 Apr 2014 12:09:59 Michael Tokarev wrote: > 14.04.2014 11:42, Dmitry Smirnov wrote: > > I found it so difficult to maintain symbols in C++ libraries so I just > > used > > "dh_makeshlibs -V" and it never failed me. > > Yeah, it never fails, but it has its own downside which I mentioned > above. Thank you for all your comments. I'm with you, I understand how useful .symbols could be for linking (if done properly). Specifically in regards to Ceph for a moment I feel much more comfortable with "dh_makeshlibs -V" not only due to lack of confidence in C++ symbols approach but mostly because of rapid upstream development. The amount of changes between 0.72.2 and 0.79 is huge. I would feel quite uncomfortable if "qemu" would be built successfully with 0.79 but wouldn't pull newer libraries when used with 0.72.2... For example Ceph cluster has to be completely upgraded to 0.79 as it just doesn't work with mix of 0.72.2 and 0.79 components (i.e. OSD,MON,MDS)... > And thank you too for tryin to clear the mess! The pleasure is mine and thanks for your kind words. :) Ceph is quite exciting technology to work with. I'm looking forward the time when we have up-to-date well packaged Ceph in testing/unstable together with rbd-enabled Qemu. ;) -- Regards, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#744781: please remove ubuntu from dashboard or at least provide an option to hide it
I couldn't agree more with this. Please remove Ubuntu or hide it by default. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#744382: [Ceph-maintainers] Bug#744382: librbd-dev and librados-dev does not provide correct shlibs/symbols file
On Tue, 15 Apr 2014 09:18:27 Michael Tokarev wrote:
> This approach works, but, as you've shown below, not for ceph, because
> ceph does not tolerate mixed-cluster, so once you update any 3rd party,
> not cluster-related but cluster-used, software, you'll have to upgrade
> whole cluster too, because according to the package manager, you'll
> have to update - in this case - librbd to the latest, which will most
> likely require updating whole ceph stack on one node, which ofcourse
> requires upgrading ceph stack on other nodes as well.
I only meant that different versions of cluster components (in my short
experience with 0.72.2 and 0.78) do not work well with each other.
Having said that `qemu-img` linked with "librbd-0.72.2" worked well with
cluster 0.72.2 and with 0.78 (unless there are some subtle bugs that I didn't
notice).
> Dmitry: this is a good example of why naive `makeshlibs -V' approach
> sometimes should NOT be used...
I see your point. Indeed .symbols approach to linking is more flexible.
However I believe that `makeshlibs -V' is the safest and most conservative way
to ensure that application will always require at least the very version of
the library it was build with (and not earlier). Basically I have two
arguments for this: easier maintenance (here my only concerns are C++ symbols
as maintaining C symbols is easy) and run-time safety. To my taste there were
way too many bugs in 0.72.2 to use it with confidence. Even if combination of
client librbd/librados-0.72.2 libraries *may* work with newer cluster just
fine, I'd rather not take any chances and force upgrading all client libraries
just to be safe even if it may be unnecessary.
I'm sure some time later symbols will work just fine to allow linking with
older client libraries.
I'm already gaining more confidence with 0.79 than I ever had with 0.72.2 so I
hope we will start using symbols soon if it won't cause any build problems in
"experimental".
> For now, I think, the current approach taken by Dmitry is the best:
> he gave all C symbols a version, so that any non-C++ program will
> use the versioned .symbols file correctly. And marked all C++ symbols
> as belonging to "current" version (I think it should be possible to
> use a variable in .symbols file, like ${VERSION}, somehow) -- so that
> all C++ users of the library will always require "latest" version.
> We don't have many C++ users in Debian archive (if at all), so this
> should not be that bad as a start. Later on, when the above changes
> will land in ceph, it will be possible to expand the C++ regex in
> the symbols file to include actual list of exported symbols.
Thank you very much for reassuring me with the chosen strategy.
By the way today I've made another commit to "experimental" branch to update
symbols files with data from 0.72.2. I doubt if including older symbols would
be necessary...
--
All the best,
Dmitry Smirnov
GPG key : 4096R/53968D1B
signature.asc
Description: This is a digitally signed message part.
Bug#744382: [Ceph-maintainers] Bug#744382: librbd-dev and librados-dev does not provide correct shlibs/symbols file
On Mon, 14 Apr 2014 16:06:30 Josh Durgin wrote: > As a ceph developer, the mixed-cluster issue is a bug (possibly fixed > already since 0.79 is undergoing heavy testing and fixes before the > next long term stable release, 0.80, is out). If you have more details > we'd be happy to hear about them. Sorry it was really version 0.78 that couldn't work in mixed environment with 0.72.2. By the time when 0.79 was released I already upgraded my cluster from 0.72.2 to 0.78 therefore I'm not sure if 0.79 exhibit the same problem. > Regarding library symbols, the ceph libraries each have C++ as well as > C interfaces, and there's been some suggestions to move to > visibility=hidden by default, to avoid some of the hairier problems > with C++ libraries [1]. It seems like this would make .symbols files > approach more tenable, since passing through all C++ symbols would > not be as bad if only the desired ones are exported in the first place. > This isn't done yet, but in the mean time the "dh_makeshlibs -V" > approach seems fine to me. I see Thanks for your comments. For now I uploaded Ceph_0.72.2-3 with "dh_makeshlibs -V" fix for #679686. As for .symbols we will try some in "experimental" first to see how it goes. I lowered severity of #744382 which I'm going to keep open to track progress of adding symbols. > If there's anything we could do upstream to make this easier, let us know. Thank you, thank you. :) -- Best wishes, Dmitry Smirnov. --- A wise man proportions his belief to the evidence. -- David Hume, "An Inquiry Concerning Human Understanding" signature.asc Description: This is a digitally signed message part.
Bug#744943: ruby-sass: Cannot load sass/script/node
This problem was introduced in package "ruby-sass/3.3.4-1" which rendered `compass` unusable... I re-assigned this bug accordingly. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#744943: ruby-sass: Cannot load sass/script/node
On Sun, 20 Apr 2014 12:56:30 Jonas Smedegaard wrote: > Bug arguably is at both packages (but I maintain both, so no need for > further BTS ping-pong): Sorry, I didn't check who maintain those packages. My intention was merely to assign bug to the right package. My impression is that the problem is in "ruby-sass" package because updating it broke "ruby-compass" which (unlike "ruby-sass") was not updated recently. > I suspect this problem to be caused not by changes to ruby-sass code (it > was upgraded), but instead to change of default Ruby version. > > I guess this could be solved by a simple binNMU of ruby-compass. I re-built "ruby-compass" in "unstable" but it did not fix the problem. > Also there is a new major release of Compass that I want to > upgrade to - i.e. my plan is to do a source-full release instead and > expect that to magically solve this issue. I also hope that new upstream release of "ruby-compass" will fix the problem. Until then we're stuck with broken `compass` unfortunately... -- Regards, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#705111: Please enable the --enable-rdb option when building
Dear Michael, I just want to let you know that Ceph_0.72.2-3 introduced library versioning mechanism and it already migrated to "testing". Ceph_0.79 in "experimental" now provides symbols (starting from 0.72.2) for all its libraries. I built qemu/1.7.0+dfsg-8 with ceph_0.79/experimental and (as expected) generated dependencies were conservative: "librados2 (>= 0.72.2), librbd1 (>= 0.72.2)". Now I hope you can safely enable RBD support in Qemu. Please let me know if you need anything else to re-introduce RBD support. I'm eagerly looking forward to have it back. ;) Thank you. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#705111: Please enable the --enable-rdb option when building
On Tue, 22 Apr 2014 14:32:30 Michael Tokarev wrote: > I looked at what's currently in 0.72.2-3 and 0.79 in experimental, and I > think this is a very good start. Good start? I thought it's pretty much done. Is there anything else left to do?? > Just one thing - maybe you can remove -V > option of dh_makeshlibs in 0.79, since you have good .symbols files > already. I might do it eventually but it is not really necessary as symbols take priority over '-V' which may still be useful if someone remove symbols or introduce new symbol-less library... > I think that's all what needed, I will re-enable rbd/ceph on the next qemu > upload. Fantastic, thank you. > BTW, I found another link which might be useful for this: > http://pkg-kde.alioth.debian.org/symbolfiles.html Thanks, I've seen this before but I need to learn the utilities that they mentioned and for now I don't want to complicate symbols maintenance any further... > Thank you for taking care of this! Thank you for making me fix it. ;) -- Cheers, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#745707: xpra: raising a window with H.264 encoding causes xpra to crash and remain stale
On Thu, 24 Apr 2014 10:46:23 Arno Töll wrote: > Versions of packages xpra depends on: > ii libavutil52 10:2.1.3-dmo1 > ii libswscale2 10:2.1.3-dmo1 I'm pretty sure the above libraries are responsible for troubles. Packages from DMO are entirely unsupported and known to cause problems. See §2.6, §2.7: https://wiki.debian.org/DebianMultimedia/FAQ#Does_the_team_coordinate_package_maintenance_with_dmo.3F -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#739429: tupi -- FTBFS with libav10
On Mon, 24 Feb 2014 15:30:13 Sebastian Ramacher wrote: > The attached patch fixes this issue. Since there is already special > casing for libav 9 and newer present in the package, there should be no > special casing needed for older versions (in case the patch is going to > be sent to upstream). Many thanks for your help, Sebastian. Much appreciated. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#740423: gitg: New upstream version 0.3.2 available
Dear Geoff, On Sat, 1 Mar 2014 14:06:55 Geoff wrote: > A new gitg version is available, please consider packaging it. There is no need for such notices. I'm well aware of new version availability as this information is presented in DDPO and Maintainer's dashboard. New version of "gitg" needs new package "libgit2-glib" (#706119) and newer package "libgit2". Please consider to help packaging libgit2* dependency packages. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B --- You have to start with the truth. The truth is the only way that we can get anywhere. Because any decision-making that is based upon lies or ignorance can't lead to a good conclusion. -- Julian Assange, 2010 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739459: [Xpra] FTBFS with libav10
Dear Anton, On Sun, 23 Feb 2014 14:45:48 an...@khirnov.net wrote: > the attached patch should fix this bug Many thanks to you for this patch. Much appreciated. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- Good luck happens when preparedness meets opportunity. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740678: RFA: abiword -- efficient, featureful word processor with collaboration
Package: wnpp Severity: normal X-Debbugs-CC: debian-de...@lists.debian.org Abiword needs new maintainer. signature.asc Description: This is a digitally signed message part.
Bug#706119: ITP: libgit2-glib -- GLib wrapper for libgit2
I'm taking over this ITP since previous owner is not active for a while and apparently might even not be active any more: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718031#51 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720540#31 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721163#19 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730827#25 I committed draft packaging to http://anonscm.debian.org/gitweb/?p=collab-maint/libgit2-glib.git Current blocker is the "libgit2" package: we need "libgit2-dev (>= 0.20)" but at the moment only 0.19 is available from "experimental" -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B --- You have enemies? Good. That means you've stood up for something, sometime in your life. -- Victor Hugo, "Villemain", 1845 (often misattributed to Winston Churchill) signature.asc Description: This is a digitally signed message part.
Bug#740703: ginkgocadx: new upstream available [FTBFS] [non-free files?]
On Tue, 4 Mar 2014 09:31:21 Karsten Hilbert wrote:
> Upstream has released v3.6.1 which fixes a few bugs
> related to not being able to show X ray studies
> under certain circumstances.
Thanks but is is really necessary to notify about new version through bug
report just hours(?) after release? Usually we can learn about new releases
from maintainers dashboard, DDPO and package PTS page...
> A major change to be aware of regarding compilation
> is that it now compiles against wxWidgets 3.
Unfortunately this version also introduces seemingly non-free files, notably
src/cadxcore/main/controllers/smartretrievecontroller.cpp
src/cadxcore/main/controllers/smartretrievecontroller.h
Carlos, could you comment on this please? The above files (from
v3.6.1.1367.34) are "Copyright 2008 MetaEmotion S.L. All rights reserved."
but (unlike othes) there is no indication that they are licensed as LGPL.
Apparently there are more files like this (looks like I missed those ones
previously):
src/cadxcore/main/gui/startup/startupform.cpp
src/cadxcore/main/gui/startup/startupform.h
src/cadxcore/main/gui/startup/startupview.cpp
There could be more. Please advise.
By the way I just tried to build new version and got FTBFS:
{{{
/tmp/buildd/ginkgocadx-3.6.1.1367.34+dfsg/src/cadxcore/VTKInria3D/wxVTK/wxVTKRenderWindowInteractor.cpp:153:36:
fatal error: wx/gtk/private/win_gtk.h: No such file or directory
#include
^
compilation terminated.
}}}
I'm not sure how to fix that...
--
Regards,
Dmitry Smirnov
GPG key : 4096R/53968D1B
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740703: ginkgocadx: new upstream available [FTBFS] [non-free files?]
On Tue, 4 Mar 2014 11:59:31 Carlos Barrales wrote: > Sorry, it was a mistake merging files. > We'll upload updated sources (We'll wait for the following compile error) Thanks. > What version of wxWidgets are you compiling against? 3.0.0, see http://packages.qa.debian.org/w/wxwidgets3.0.html I tried to build in Debian "testing" and in clean "unstable" chroot, both FTBFS... Thank you. -- Regards, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740734: README.Debian is out of date
On Tue, 4 Mar 2014 15:41:21 Harald Dunkel wrote: > Following /usr/share/doc/zabbix-frontend-php/README.Debian for > apache2 (2.4) or nginx (1.4.5) gives me just a 404 on > http://myserver/zabbix/. I can't spot a problem with nginx instructions. This is pretty much how it configured on my system and it works for me. Your suggestions are welcome if you have ideas how documentation can be improved (or if you know what is missing). -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740815: zabbix-server-mysql: snmp monitoring not works if snmp MIBs are missing
On Wed, 5 Mar 2014 20:48:38 Alex 'AdUser' Z wrote: > Please add 'snmp-mibs-downloader' as soft dependency. We can't Depend or Recommend non-free package although I think it is possible to Suggest it. Frankly I'm reluctant even to suggest it... Is there are any alternatives from "main"? -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- All that is necessary for the triumph of evil is that good men do nothing. signature.asc Description: This is a digitally signed message part.
Bug#740815: zabbix-server-mysql: snmp monitoring not works if snmp MIBs are missing
On Wed, 5 Mar 2014 23:58:20 Alex 'AdUser' Z wrote: > Another possible way - make a note in README.Debian. Makes sense, perhaps we can do both -- suggest and add a note to README.Debian. Thank you. -- Regards, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738937: zabbix: Drop virtual libgcrypt-dev from Build-Depends
On Sat, 15 Feb 2014 16:32:25 Artur Rona wrote: > In Ubuntu, we've got FTBFS due to missing Build-Depends libgcrypt-dev. > Suggested change fixed that bug. This is not a bug in Debian. I'm convinced that one sided Ubuntu-only fixes do not belong to Debian hence I'm tagging this as "wontfix". Mutually beneficial patches are always welcome. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#741023: xpra attach :100 leads to 'segmentation fault'
I'm unable to reproduce this. On Fri, 7 Mar 2014 16:16:15 Wenceslao González-Viñas wrote: > I tried also with versions 0.11.2 and 0.12.0 0.12.0 is not in Debian and not even released yet so my guess is that you might have broken/incompatible Xpra configuration files in "/etc/xpra" or in "~/.xpra"... Also it may help if you try to disable pulseaudio. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741023: xpra attach :100 leads to 'segmentation fault'
On Sat, 8 Mar 2014 07:56:26 Antoine Martin wrote: > From the log files that are provided, the poster's error is that there > is an X11 server already running on the display he is trying to start. > That's what the error message says, almost word for word: > "Make sure an X server isn't already running" If we trust reporter I think he claims that computer was rebooted just prior he reproduced the problem... > There might be other problems too, but they are occluded by this one. Indeed. -- Regards, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509335: Bug:#509335: rsync: please build with support for '--copy-devices'
Dear Paul, I wish to have "--copy-devices" option as well. It will be best to implement it using upstream patch "copy-devices.diff" provided in "rsync-patches-$(VER).tar.gz" from https://rsync.samba.org/ftp/rsync/src/ This functionality is quite useful. As a matter of fact lack of "--copy-devices" in rsync is the only reason for #724344 but I'd rather teach rsync to do it than introduce yet another utility. Thank you. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#740703: ginkgocadx: new upstream available [FTBFS] [non-free files?]
Hi Carlos, On Mon, 10 Mar 2014 10:46:28 Carlos Barrales wrote: > I see... The official wxWidgets compilation is (reasonably) against GTK3, > and we used GTK2. > Shouldn't be hard to fix, but we will take time... > Those ugly macros are for window reparenting issues and we finally removed > the main point of failure (window undocking). > > We will keep you informed. Thank you for update. -- Best wishes, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741023: xpra attach :100 leads to 'segmentation fault'
Hi Wenceslao, Please avoid using HTML formatting (it doesn't look good in bug report) and use only plain-text emails. On Mon, 10 Mar 2014 14:05:23 Wenceslao González-Viñas wrote: > It works!!! How can the problem be fixed (not temporarily)? Please try with "--opengl=no" (it will probably work). What's your video drivers? Which OpenCL/ICD packages are installed? What's the oputput of `clinfo`? Which GLX module in use (check using "sudo update-alternatives --config glx")? -- Regards, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741347: gitg: can't stage files
On Tue, 11 Mar 2014 14:51:41 Gerald wrote: > Version: 0.2.4-1.1+deb7u1 I recommend to install never version from backports especially if 0.2.4 do not work for you. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#723599: RFA: nilfs-tools -- Continuous Snapshotting Log-structured Filesystem
I'll take care about "nilfs-tools" for now but in the future I'd like someone who use NILFS2 to help with maintaining this package. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
