Bug#769129: marked as done (unblock: busybox/1:1.22.0-10)
On 2014-11-23 16:59, Cyril Brulebois wrote: [...] Closing for now, feel free to reopen when you're ready. Niels still has an unblock for it. FTR, I'm personally scared by d's output. Mraw, KiBi. Not any more, sorry. I had forgotten about this thread, when I noticed the RC bug fix on the UDD tracker. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769269: rep-gtk: FTBFS in jessie/i386: /usr/lib/rep/i486-pc-linux-gnu/libtool: line 7834: i486-linux-gnu-gcc: command not found
block -1 by 769642 thanks /usr/lib/rep/i486-pc-linux-gnu/libtool ... This error is caused by the libtool shipped with librep-dev and already reported there as #769642. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770728: unblock: ruby-em-hiredis/0.2.1-2.1
Hi, On Sun, Nov 23, 2014 at 6:13 PM, Adam D. Barratt a...@adam-barratt.org.uk wrote: This package is a dependecy of ruby-em-synchrony, which is a build dependency of ruby-faraday, currently FTBFSing because of this removal. Unblocking this package won't make -synchrony eligible for migration, however. Was that an intended (but not stated) effect of this request? Yes, sorry, I'm new to the unblocking process, I thought I would file a separate unblock for -synchrony if this one got approved. If they should be unblocked together, then I guess the request should have been: unblock ruby-em-hiredis/0.2.1-2.1 unblock ruby-em-synchrony/1.0.3-1 -- Thanks, Marga -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770730: pre-approval for t-p-u upload/unblock: statsmodels/0.4.2-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please pre-approve an upload statsmodels to testing-proposed-updates in order to fix #768695. As unstable has a new upstream version, this needs to be fixed in jessie. The NMU debdiff I am going to sponsor is attached. unblock statsmodels/0.4.2-1.1 -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru statsmodels-0.4.2/debian/changelog statsmodels-0.4.2/debian/changelog --- statsmodels-0.4.2/debian/changelog 2012-06-29 23:26:49.0 +0200 +++ statsmodels-0.4.2/debian/changelog 2014-11-23 17:55:26.0 +0100 @@ -1,3 +1,10 @@ +statsmodels (0.4.2-1.1) testing; urgency=medium + + * Non-maintainer upload. + * Fixes various problems with build process + + -- Tomasz Buchert tomasz.buch...@inria.fr Sun, 23 Nov 2014 17:46:48 +0100 + statsmodels (0.4.2-1) unstable; urgency=low * Fresh upstream release addressing FTBFS across big-endian architectures. diff -Nru statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch --- statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch 1970-01-01 01:00:00.0 +0100 +++ statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch 2014-11-23 17:57:08.0 +0100 @@ -0,0 +1,128 @@ +Description: remove tests that use uncompatible scipy interface + The tests use an rvs method which has an incompatible + interface. We remove these failing tests altogother. + +--- statsmodels-0.4.2.orig/statsmodels/sandbox/tests/test_gam.py statsmodels-0.4.2/statsmodels/sandbox/tests/test_gam.py +@@ -187,121 +187,3 @@ class TestAdditiveModel(BaseAM, CheckAM) + const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers]) + #print const, slopes + res1.params = np.array([const] + slopes) +- +- +-class BaseGAM(BaseAM, CheckGAM): +- +-def init(self): +-nobs = self.nobs +-y_true, x, exog = self.y_true, self.x, self.exog +-if not hasattr(self, 'scale'): +-scale = 1 +-else: +-scale = self.scale +- +-f = self.family +- +-self.mu_true = mu_true = f.link.inverse(y_true) +- +-np.random.seed(8765993) +-#y_obs = np.asarray([stats.poisson.rvs(p) for p in mu], float) +-y_obs = self.rvs(mu_true, scale=scale, size=nobs) #this should work +-m = GAM(y_obs, x, family=f) #TODO: y_obs is twice __init__ and fit +-m.fit(y_obs, maxiter=100) +-res_gam = m.results +-self.res_gam = res_gam #attached for debugging +-self.mod_gam = m #attached for debugging +- +-res_glm = GLM(y_obs, exog, family=f).fit() +- +-#Note: there still are some naming inconsistencies +-self.res1 = res1 = Dummy() #for gam model +-#res2 = Dummy() #for benchmark +-self.res2 = res2 = res_glm #reuse existing glm results, will add additional +- +-#eta in GLM terminology +-res2.y_pred = res_glm.model.predict(res_glm.params, exog, linear=True) +-res1.y_pred = res_gam.predict(x) +-res1.y_predshort = res_gam.predict(x[:10]) #, linear=True) +- +-#mu +-res2.mu_pred = res_glm.model.predict(res_glm.params, exog, linear=False) +-res1.mu_pred = res_gam.mu +- +-#parameters +-slopes = [i for ss in m.smoothers for i in ss.params[1:]] +-const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers]) +-res1.params = np.array([const] + slopes) +- +- +-class TestGAMPoisson(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Poisson() +-self.rvs = stats.poisson.rvs +- +-self.init() +- +-class TestGAMBinomial(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Binomial() +-self.rvs = stats.bernoulli.rvs +- +-self.init() +- +-class _estGAMGaussianLogLink(BaseGAM): +-#test failure, but maybe precision issue, not far off +-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true)) +-#0.80409736263199649 +-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true))/tt.mu_true.mean() +-#0.023258245077813208 +-# np.mean((tt.res2.mu_pred - tt.mu_true)**2)/tt.mu_true.mean() +-#0.022989403735692578 +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Gaussian(links.log) +-self.rvs = stats.norm.rvs +-self.scale = 5 +- +-self.init() +- +- +-class TestGAMGamma(BaseGAM): +- +-def
Bug#759424: di-netboot-assistant: please update package for jessie / new syslinux
Hi Jonas,
On Sun, Nov 23, 2014 at 04:56:16PM +0100, Jonas Smedegaard wrote:
Sure thing: I will prepare git commits.
I now have a fork of your git locally, and attached patches were
produced using git format-patch --minimal origin/master - not sure if
that's what you prefer, else please guide me.
You migth consider adding this improved warning to the patch set:
--- di-netboot-assistant.andi 2014-11-23 18:15:05.100283686 +0100
+++ di-netboot-assistant.jonas 2014-11-23 16:53:10.232629361 +0100
@@ -392,7 +392,7 @@
if [ -f pxelinux.cfg/default ]; then
for x in $(sed -n -e
s,^\s*KERNEL\s[\s:/]*\(.*menu.c32\).*,\1,p pxelinux.cfg/default | sort -u );
do
+ [ ! -f ../$x ] echo W: The binary '${TFTP_ROOT}/$x'
mentioned in the PXE boot menu is missing.
- [ ! -f ../$x ] echo W: Some menu binaries are
missing. Install the package syslinux
done
else
find pxelinux.cfg/ -iregex '.*\(\.c32\|\.bak.*\|~\)$' \
It pops up when removing the debian-installer directory and not all installer
images have been installed again with di-netboot-assistant install XXX, and
the current content is rather confusing.
Best regards,
Andi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770731: ITP: symlookup -- Utility for object symbol search in installed libraries
Package: wnpp Severity: wishlist Owner: Dmitry Yu Okunev dyoku...@ut.mephi.ru * Package name: symlookup Version : 0.5.2 Upstream Author : Andrew A Savchenko birc...@users.sourceforge.net * URL : http://sourceforge.net/projects/symbol-lookup/ * License : GPL-3 Programming Lang: C (gnu99) Description : Utility for object symbol search in installed libraries This program searches for both dynamic and static libraries, looking those ones which provide given object symbols. It will assist you in undefined symbol errors eliminating. why is this package useful/relevant? It sometimes saves a lot of time while running closed source applications is it a dependency for another package? No. do you use it? Yes. if there are other packages providing similar functionality, how does it compare? I don't know such packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758973: [fontconfig-config] Stop breaking user configuration in /etc/fonts/conf.d/ after every upgrade
Hi, I reviewed the change with other people at the BSP and will now upload it to the 0-day delayed queue and request the unblock. I modified the changelog entry, so here's the attachment of the NMU I'll make. -- Regards, Marga fontconfig.debdiff Description: Binary data
Bug#766758: apt: does not process pending triggers
On Sat, Nov 15, 2014 at 12:28:07AM +0100, Guillem Jover wrote: I dislike bug-pingpong, but in this case I have to move it back to dpkg as we can't change apt to make upgrades work (at least it was never allowed in the past, so I doubt it is an option now) and its a behaviour change in dpkg, not a apt regression per-se, so dpkg/jessie has to behave as expected by libapt-pkg/wheezy here regardless of how dumb that might be. Sure, although the current apt behavior goes against the written triggers spec, where apt/aptitude even have their own section. :) I don't want to be seen as picky, but it doesn't. Especially the mentioned section isn't violated. We know these states and we call configure for them if we see them, but the next line says we usually will not see them. What you did now is changing the usual in this sentence to in the way you are using it, it will be close to always. Triggers are from our viewpoint an implementation detail of dpkg (which is also what the spec suggests), which leaks into our domain more and more for good reasons, but at the same time its bad as we can't really deal with them as there is no way to predict what will happen… If you agree just clone the bug back to us and I will take care of it from the apt side. You might want to clone it to other dpkg-callers as well as I presume that at least some have the same problem. Otherwise, I am all ears for alternative solutions. Only apt seems to be affected. dselect properly uses “dpkg transactions” and as such queues all configuration in a final «--configure --pending» call. And cupt seems to behave correctly by calling dpkg with «--triggers-only --pending», but Eugene might know for sure. If you know of other frontends, I'd be interested to know. Well, I don't know, but I would guess that at least the various (cross-)bootstrappers need to be checked. smartpm (although, it might be better to just remove it). d-i maybe, but I guess it doesn't use dpkg directly (and/or later states with apt will fix that up). codesearch might help if you can come up with a good search pattern (I couldn't). So apt needs to either pass man-db to the --configure call, or just do a final --triggers-only/--configure --pending call. A trivial fix would be to change the default value for DPkg::TriggersPending to true. I just realized that we also have a dpkg::ConfigurePending option causing apt to run a dpkg --configure --pending after all other dpkg calls, so I will opt for this one as it is more future proof and does what we need just as well. Reasoning: I just tried the following sequence: dpkg -i trigdepends-interest_1.0_all.deb triggerable-interest_1.0_all.deb # ^ dependency ^ interest /usr/share/doc dpkg --unpack trigdepends-interest_1.0_all.deb dpkg --unpack trigstuff_1.0_all.deb dpkg --configure trigstuff # ^ trigstuff is iW as dependencies of trigger aren't statisfied dpkg --triggers-only --pending My expectation I expressed in the previous mail was that the last command here would fail as a pending trigger can't be run. It doesn't, so my biggest concern with dpkg::TriggersPending isn't really existing, but I still think that running it all the time isn't needed if we can just do the more general ConfigurePending once. Best regards David Kalnischkies P.S.: I will respond to other parts of the mail/thread in other threads/bugs to keep all reasonably ordered… if that is possible. signature.asc Description: Digital signature
Bug#768308: chicken-bin: Fix C_MINOR_VERSION
Hi Johann, On Sat, 22 Nov 2014 14:54:08 +0100 Johann Felix Soden joh...@debian.org wrote: the changes from 4.9.0 to 4.9.0.1 are way to huge to update to the new upstream version for Debian Jessie (diff has O(70) lines). The attached patch only backports the C_MINOR_VERSION change as requested by this bug report. Is there another change which need to be included? Thanks for looking at this issue. Unfortunately, I'm afraid your patch is not the best approach to handle the problem. Touching chicken.h would cause the build system to rebuild practically the whole CHICKEN core software, and that would generate the gigantic diff you see. The 4.9.0.1 release does basically that, but provides the C code generated by the bootstrap process. Let me provide some more context. CHICKEN is a self-hosting Scheme-C compiler. It is mostly written in Scheme, but some parts are in C (runtime.c and chicken.h). To build CHICKEN out of sources from the git repository, you have to go through a bootstrap process, that is, you need CHICKEN to build CHICKEN. To make the life of users and packagers easier, we provide source tarballs with code that has already gone through the bootstrap process. Those source tarballs contain the source code from the git repository plus the C code generated by the bootstrap process (i.e., the output of the compilation of the compiler source, in Scheme, to C). Thus, to build CHICKEN out of source tarballs, you only need a working C toolchain and GNU make. However, if you touch any source file (the original source, from git -- not the C source code generated by the bootstrap process), the build system will probably try to compile that file and those that depend on it. That compilation step requires a working CHICKEN compiler. If you touch a basic file like chicken.h, a lot of files will have to go through the bootstrap process again. That's not desirable, since it would require a working CHICKEN installed. Here are the steps you can use to check the differences between 4.9.0 and 4.9.0.1: 1. $ wget http://code.call-cc.org/releases/4.9.0/chicken-4.9.0.tar.gz 2. $ wget http://code.call-cc.org/releases/4.9.0/chicken-4.9.0.1.tar.gz 3. $ tar xzf chicken-4.9.0.tar.gz 4. $ tar xzf chicken-4.9.0.1.tar.gz 5. $ (cd chicken-4.9.0 ; make PLATFORM=linux spotless) 6. $ (cd chicken-4.9.0.1 ; make PLATFORM=linux spotless) 7. $ diff -ur chicken-4.9.0 chicken-4.9.0.1 Steps 5 and 6 will remove the files generated by the bootstrap process. The ones left will show the differences between the two versions. Attached you can find the whole diff for versions 4.9.0 and 4.9.0.1 (generated by the steps [1 -- 7] above). As you can see, the major difference is the bump in C_MINOR_VERSION. The other changes are related to documentation and the addition of tests to catch that versioning mistake. As explained above, patching chicken.h is not the best option, since it will require the bootstrap process if users try to build the source tarball. So, I strongly advice using the tarball for the 4.9.0.1 release, which can be found at http://code.call-cc.org/releases/4.9.0/chicken-4.9.0.1.tar.gz (SHA256 sum: 04df7c439c36fc16446bdfa186e7a70258f911d2d826b5216a8e6b1cb2aa2815). That release fixes the versioning problem and the source code in the tarball has been gone through the bootstrap process. Best wishes. Mario -- http://parenteses.org/mario diff -ur chicken-4.9.0/NEWS chicken-4.9.0.1/NEWS --- chicken-4.9.0/NEWS 2014-06-02 11:30:25.0 -0300 +++ chicken-4.9.0.1/NEWS 2014-06-07 09:58:37.0 -0300 @@ -1,3 +1,8 @@ +4.9.0.1 + +- Runtime library + - C_MINOR_VERSION changed to 9; feature identifier chicken-4.8 = chicken-4.9 + 4.9.0 - Security fixes diff -ur chicken-4.9.0/README chicken-4.9.0.1/README --- chicken-4.9.0/README 2014-06-02 11:30:28.0 -0300 +++ chicken-4.9.0.1/README 2014-06-07 10:02:53.0 -0300 @@ -6,7 +6,7 @@ (c) 2008-2014, The Chicken Team (c) 2000-2007, Felix L. Winkelmann - version 4.9.0 + version 4.9.0.1 1. Introduction diff -ur chicken-4.9.0/buildversion chicken-4.9.0.1/buildversion --- chicken-4.9.0/buildversion 2014-06-02 11:30:25.0 -0300 +++ chicken-4.9.0.1/buildversion 2014-06-07 10:02:53.0 -0300 @@ -1 +1 @@ -4.9.0 +4.9.0.1 \ No newline at end of file diff -ur chicken-4.9.0/chicken.h chicken-4.9.0.1/chicken.h --- chicken-4.9.0/chicken.h 2014-06-02 11:30:25.0 -0300 +++ chicken-4.9.0.1/chicken.h 2014-06-07 09:26:48.0 -0300 @@ -38,7 +38,7 @@ #define ___CHICKEN #define C_MAJOR_VERSION 4 -#define C_MINOR_VERSION 8 +#define C_MINOR_VERSION 9 #ifndef _ISOC99_SOURCE # define _ISOC99_SOURCE diff -ur chicken-4.9.0/manual-html/The User's Manual.html chicken-4.9.0.1/manual-html/The User's Manual.html --- chicken-4.9.0/manual-html/The User's Manual.html 2014-06-02 11:40:31.0 -0300 +++ chicken-4.9.0.1/manual-html/The User's Manual.html 2014-06-07 10:23:33.0 -0300 @@ -7,7 +7,7 @@ meta
Bug#770730: pre-approval for t-p-u upload/unblock: statsmodels/0.4.2-1.1
Control: tags -1 + confirmed moreinfo On Sun, 2014-11-23 at 18:23 +0100, Michael Banck wrote: Please pre-approve an upload statsmodels to testing-proposed-updates in order to fix #768695. As unstable has a new upstream version, this needs to be fixed in jessie. The NMU debdiff I am going to sponsor is attached. Thanks for this. Please go ahead, and remove the moreinfo tag once the upload has been accepted. One comment: + interface. We remove these failing tests altogother. s/altogother/altogether/ Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770732: piuparts and jessie, pre-upload unblock request questions
package: release.debian.org x-debbugs-cc: piuparts-de...@lists.alioth.debian.org Dear release team, until a very few days ago, it didnt occur to me at all, that piuparts 0.60 ain't suitable for the release, but now Andreas Beckmann pointed out, that: - testing = jessie, that will be wrong soon - we have several custom-scripts dealing with init-systems... (the custom scripts are not used by piuparts by defaults but can be used easily and are in use on piuparts.d.o) - there are a few new patterns of ignored files to avoid false positives. Currently 0.60 is in sid+jessie, and piuparts.d.o runs the develop branch of piuparts.git (with the above changes and a few more as explained below). I'm happy to create a new jessie-branch and cherry-pick whatever you deem suitable for 0.61 in sid and then jessie (and keep running the develop branch on piuparts.d.o). To keep maintaining these two branches more, I'd like to discuss which changes are acceptable to keep the diff at a minimum or maybe not have one... currently we have: Comments inline the changelog, in the lines starting with # [ Holger Levsen ] * piuparts.py: Add /var/cache/apt/archives/partial/ to ignored files. (Closes: #767489) # one-liner to ignored patterns, it's important to not have false positives... * piuparts.py and piuparts-report: Detect four more (in)adequate issues: - broken-binfmt-detector - broken-binfmt-interpreter - missing-alternative - program-name-collision (Closes: #767499) # probably just a normal bug... but trivial changes at least ;) * distros.conf: Remove unneeded URI for squeeze-lts, it just uses the default repository. # trivial config change removing one line only relevant for those who test # squeeze-lts... * instances/pejacevic+slaves: Do not reschedule passed squeeze logs anymore. # trivial config change only relevant for hosts called pejacevic+piu- slave-(bm|1und1)-(a|1) [ Andreas Beckmann ] * piuparts.py: - Add to ignored_files: + /etc/modules-load.d/modules.conf (dangling symlink to ../modules) # one-liner to ignored patterns, it's important to not have false positives... - Create /etc/resolv.conf in the chroot using only the nameserver entries found on the host. # arguely a normal bug and unfilled :/ The patch is trivial and still looked good on a 3rd look ;) * lib/dwke.py: Fix parsing known_problems/*.conf using EXCLUDE_PATTERN. # an (unfiled) important bug in piuparts-report leading to wrongly detected problems... * Add AddDefaultCharset utf-8 to the apache2 configuration snipplet example, so that logfiles are displayed as UTF-8. # just an example configuration change * pre_install_foreign_architecture: New script to enable foreign architectures for testing cross toolchain packages. * pre_remove_40_find_unowned_lib_links, unowned_lib_symlink_*.conf: New script and reports for unowned symlinks in [/usr]/lib[/triplet]. # these custom scripts are not used by piuparts by defaults but can be used # easily and are in use on piuparts.d.o) * Rework the file-rc/sysvinit/upstart/systemd specific exceptions. # custom-scripts dealing with initsystems... [ Michael Prokop ] * Support new scripts directive 'post_chroot_unpack', useful for adding apt-keys for custom apt repositories. (Closes: #767485) * Add custom-scripts/scripts-unused-examples/post_chroot_unpack_key_setup.sh # this is really a wishlist bug and my only argument for including it is that # a.) the change to piuparts.py is rather trivial and b.) the feature is # really very nice to have... and c.) maintaining deltas is annoying. So... to summarize, I think these are all important bugfixes or documentation changes (counting the custom-scripts as documentation) except for: - the new scripts directive 'post_chroot_unpack' from Michael Prokop - creating resolv.conf for the minimal chroot - #767499 (detect more adequate tags) These are definitly normal/wishlist fixes but the changes are trivial and I would like to include them as pre-approved-changes ;-) Does that sound sound? (=to upload all these changes to sid, targeted at jessie) I'll happily follow your advice (whatever it will be) and maintain two branches as/if needed... obviously I'd rather not have to and I'm also really sorry I just fully realized yesterday, but life is as it is! :-) Oh and btw, regarding the freeze policy and getting stuff in until the 5th of December and January: do you mean in jessie or in sid by these dates? (And if you mean in jessie again (like for the 5th of November/26th of October deadline...), I think a loud clarification now would be nice and quite appreciated by some.) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#770153: Raising severity
Package: gedit Followup-For: Bug #770153 Control: severity 770153 grave I decided to upload gedit-latex-plugin (hence closing #768134) without the workaround for this which is applied upstream: whichever menu is used, as long as this bug is not solved there will be many combinations of plugins which make gedit segfault. So I'm raising the severity of this to grave - notice that data loss is well possible in the case in which gedit crashes at the moment of activating a plugin. Pietro -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768117: debian-policy: WSGI API must distinguish between Python 2 and 3
On 23/11/14 17:19, Bill Allombert wrote: On Wed, Nov 05, 2014 at 02:38:39PM +1100, Brian May wrote: We need two virtual package names, one for Python2 and one for Python3. What I am unclear is why a single virtual package httpd-wsgi3 will work for python 3.2, 3.3, 3.4 etc. All versions of Python 2.x are broadly source-compatible, and all versions of Python 3.x are broadly source-compatible, but correct Python 2.x code usually needs significant source changes to be interpreted correctly by Python 3.x. As a result of porting being required, and the way we package extensions in Debian, dependency declarations need to change across the 2 - 3 boundary, from python-foo to python3-foo. It would be appropriate for a webapp that requires module foo, and whose code is correct Python 2, to depend on httpd-wsgi and python-foo; it would be appropriate for a webapp that requires foo, and whose code is correct Python 3, to depend on httpd-wsgi3 and python3-foo. C extensions for versions of Python 2.x are not ABI-compatible with other versions of 2.x, but that doesn't really matter here, because the WSGI implementation will be linked to the libpython2.x from our default Python 2.x version (whatever that happens to be), and all python-* extensions that might be used by the webapp are available for at least that default version (and possibly other versions). The same logic presumably applies for 3.x and python3-* extensions. A concrete example of what is wrong: fookebox depends on (among others) python-sqlalchemy, and recommends httpd-wsgi. Even if we assume that fookebox's source code is simultaneously correct Python 2 and Python 3 code (which is possible to write, but sometimes difficult), if it was run under libapache2-mod-wsgi-py3 it would probably fail to start up, because python3-sqlalchemy is not pulled in by its dependencies. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770733: unblock: fontconfig/2.11.0-6.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package fontconfig The package in jessie includes a postinst that will override changes done by the sysadmin (by recreating links in /etc even if they had been removed). The package in unstable has the postinst modified so that the symlinks are only touched on installation or reconfigure stage. The package in testing is 2.11.0-6.1, the one in unstable is 2.11.0-6.2, and is already has an unblock request (#770370). I'm including the debdiff against that version, plus the wdiff (almost all the lines in my change were just indented), plus the debdiff against the package in testing unblock fontconfig/2.11.0-6.3 -- Thanks, Marga fontconfig-to-testing.debdiff Description: Binary data fontconfig.wdiff Description: Binary data fontconfig-to-unstable.debdiff Description: Binary data
Bug#769609: apt: does not process pending triggers
Hi,
as mentioned in the dpkg-part of this bugreport I am favoring enabling
the dpkg::configurePending option to fix this from our side.
It causes apt to shedule a dpkg --configure --pending after all other
dpkg calls are done. In the best case this is doing nothing, in the
worst it runs some triggers to get all packages out of the trigger
states.
I think it is better to this more general call than to do
--triggers-only as its more future proof and will be something we will
be using (more) in future versions anyway.
The attached git commit fixes also the progress reporting as otherwise
this sheduled call would be run at 100%. Included is a testcase for
this, but this obviously requires a broken dpkg version to see that it
actually works.
Best regards
David Kalnischkies
commit 1a46b9499017105f0d6a8c6319521088eadff6b2
Author: David Kalnischkies da...@kalnischkies.de
Date: Tue Nov 18 19:53:56 2014 +0100
always run 'dpkg --configure -a' at the end of our dpkg callings
dpkg checks now for dependencies before running triggers, so that
packages can now end up in trigger states (especially those we are not
touching at all with our calls) after apt is done running.
The solution to this is trivial: Just tell dpkg to configure everything
after we have (supposely) configured everything already. In the worst
case this means dpkg will have to run a bunch of triggers, usually it
will just do nothing though.
The code to make this happen was already available, so we just flip a
config option here to cause it to be run. This way we can keep
pretending that triggers are an implementation detail of dpkg.
--triggers-only would supposely work as well, but --configure is more
robust in regards to future changes to dpkg and something we will
hopefully make use of in future versions anyway (as it was planed at the
time this and related options were implemented).
Closes: 769609
diff --git a/apt-pkg/deb/dpkgpm.cc b/apt-pkg/deb/dpkgpm.cc
index 5938750..56e9d75 100644
--- a/apt-pkg/deb/dpkgpm.cc
+++ b/apt-pkg/deb/dpkgpm.cc
@@ -1047,6 +1047,12 @@ void pkgDPkgPM::BuildPackagesProgressMap()
PackagesTotal++;
}
}
+ /* one extra: We don't want the progress bar to reach 100%, especially not
+ if we call dpkg --configure --pending and process a bunch of triggers
+ while showing 100%. Also, spindown takes a while, so never reaching 100%
+ is way more correct than reaching 100% while still doing stuff even if
+ doing it this way is slightly bending the rules */
+ ++PackagesTotal;
}
/*}}}*/
bool pkgDPkgPM::Go(int StatusFd)
@@ -1274,9 +1280,8 @@ bool pkgDPkgPM::Go(APT::Progress::PackageManager *progress)
// support subpressing of triggers processing for special
// cases like d-i that runs the triggers handling manually
- bool const SmartConf = (_config-Find(PackageManager::Configure, all) != all);
bool const TriggersPending = _config-FindB(DPkg::TriggersPending, false);
- if (_config-FindB(DPkg::ConfigurePending, SmartConf) == true)
+ if (_config-FindB(DPkg::ConfigurePending, true) == true)
List.push_back(Item(Item::ConfigurePending, PkgIterator()));
// for the progress
diff --git a/test/integration/framework b/test/integration/framework
index ff059f5..36deccf 100644
--- a/test/integration/framework
+++ b/test/integration/framework
@@ -1241,10 +1241,13 @@ testnopackage() {
fi
}
-testdpkginstalled() {
- msgtest Test for correctly installed package(s) with dpkg -l $*
- local PKGS=$(dpkg -l $@ 2/dev/null | grep '^i' | wc -l)
- if [ $PKGS != $# ]; then
+testdpkgstatus() {
+ local STATE=$1
+ local NR=$2
+ shift 2
+ msgtest Test that $NR package(s) are in state $STATE with dpkg -l $*
+ local PKGS=$(dpkg -l $@ 2/dev/null | grep ^${STATE} | wc -l)
+ if [ $PKGS != $NR ]; then
echo 2 $PKGS
dpkg -l $@ | grep '^[a-z]' 2
msgfail
@@ -1253,16 +1256,12 @@ testdpkginstalled() {
fi
}
+testdpkginstalled() {
+ testdpkgstatus 'ii' $# $@
+}
+
testdpkgnotinstalled() {
- msgtest Test for correctly not-installed package(s) with dpkg -l $*
- local PKGS=$(dpkg -l $@ 2 /dev/null | grep '^i' | wc -l)
- if [ $PKGS != 0 ]; then
- echo
- dpkg -l $@ | grep '^[a-z]' 2
- msgfail
- else
- msgpass
- fi
+ testdpkgstatus 'ii' '0' $@
}
testmarkedauto() {
diff --git a/test/integration/test-apt-progress-fd b/test/integration/test-apt-progress-fd
index af022f5..90e6ef7 100755
--- a/test/integration/test-apt-progress-fd
+++ b/test/integration/test-apt-progress-fd
@@ -19,13 +19,14 @@ testequal dlstatus:1:0:Retrieving file 1 of 1
dlstatus:1:20:Retrieving file 1 of 1
pmstatus:dpkg-exec:0:Running dpkg
pmstatus:testing:0:Installing testing (amd64)
-pmstatus:testing:20:Preparing testing (amd64)
-pmstatus:testing:40:Unpacking testing (amd64)
-pmstatus:testing:60:Preparing to configure testing (amd64)
Bug#770016: Clarify network access for building packages in main
On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote: 2.2.1 says the packages in main must not require or recommend a package outside of main for compilation or execution (thus, the package must not declare a Pre-Depends, Depends, Recommends, Build-Depends, or Build-Depends-Indep relationship on a non- main package), In practice there is a consensus that this also means packages must not access external network servers which conforms to the spirit but not to the letter of this section. Note that there may be other requirements which are not codified, as mentioning only things that are packaged is not enough, it should say something like must not use any stuff except for packages in main. Hi Andrew, I guess that it is implicit from the defintion of contrib that follows in 2.2.2: The contrib archive area contains supplemental packages intended to work with the Debian distribution, but which require software outside of the distribution to either build or function. I've just understood both these statements mention requiring something non-free to *function*. Do we allow packages in main to require external services to function? -- WBR, wRAR signature.asc Description: Digital signature
Bug#770706: [PKG-Openstack-devel] Bug#770706: keystone.service does not start, /var/run/keystone not created
Hi I did not look into this praticular problem yet, but just a few comments from my experience with converting other packages to systemd. Stig Sandbeck Mathisen s...@debian.org writes: Looks like my proposed solution (RuntimeDirectory=) does not work very well with multiple services needing the same /run/something directories. When I defined multiple services with the same RuntimeDir=, the services delete each others runtime directories. This is documented in systemd.exec(5) for RuntimeDirectory=. This affects the ceilometer-* and glance-* services. Could this be handled with proper dependencies between these services? To ensure that the directory is already created? The processes are started, but since pidfiles are not created, and the systemd units are configured with PIDFile=, systemd times out waiting for the pidfiles to be created, and assumes the services didn't start correctly, which again the packages from being installed. Why do you set PIDFile at all? IMO pidfiles are unnecessary when the daemons managed by systemd run in the foreground and thus there is no need for a pidfile at all. I'll try using tmpfiles.d to solve this, as the systemd.exec(5) man page already mentions. Sounds good too, but like a lot of effort just to support legacy pid files (iff that's the only reasons for these directories). Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768678: ruby-faraday: FTBFS in jessie: build-dependency not installable: ruby-em-synchrony
On Sun, Nov 23, 2014 at 06:06:33PM +0100, Margarita Manterola wrote: Hi, I've uploaded a new version of ruby-em-hiredis, which fixes the FTBFS (#759917), and I have requested the unblock of this package (#770728). If ruby-em-hiredis gets unblocked, then ruby-em-synchrony could be also unblocked and this one would get solved. AFAIK the freeze migration policy is only packages already in testing get migrated, ruby-em-synchrony is not in testing. -- WBR, wRAR signature.asc Description: Digital signature
Bug#768695: Updated NMU patch
Here is a patch with 2 modifications: 1) d/changelog: added (Closes: ...) 2) altogother = altogether Cheers, Tomasz diff -Nru statsmodels-0.4.2/debian/changelog statsmodels-0.4.2/debian/changelog --- statsmodels-0.4.2/debian/changelog 2012-06-29 23:26:49.0 +0200 +++ statsmodels-0.4.2/debian/changelog 2014-11-23 17:55:26.0 +0100 @@ -1,3 +1,10 @@ +statsmodels (0.4.2-1.1) testing; urgency=medium + + * Non-maintainer upload. + * Fixes various problems with build process (Closes: #768695) + + -- Tomasz Buchert tomasz.buch...@inria.fr Sun, 23 Nov 2014 17:46:48 +0100 + statsmodels (0.4.2-1) unstable; urgency=low * Fresh upstream release addressing FTBFS across big-endian architectures. diff -Nru statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch --- statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch 1970-01-01 01:00:00.0 +0100 +++ statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch 2014-11-23 17:57:08.0 +0100 @@ -0,0 +1,128 @@ +Description: remove tests that use uncompatible scipy interface + The tests use an rvs method which has an incompatible + interface. We remove these failing tests altogether. + +--- statsmodels-0.4.2.orig/statsmodels/sandbox/tests/test_gam.py statsmodels-0.4.2/statsmodels/sandbox/tests/test_gam.py +@@ -187,121 +187,3 @@ class TestAdditiveModel(BaseAM, CheckAM) + const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers]) + #print const, slopes + res1.params = np.array([const] + slopes) +- +- +-class BaseGAM(BaseAM, CheckGAM): +- +-def init(self): +-nobs = self.nobs +-y_true, x, exog = self.y_true, self.x, self.exog +-if not hasattr(self, 'scale'): +-scale = 1 +-else: +-scale = self.scale +- +-f = self.family +- +-self.mu_true = mu_true = f.link.inverse(y_true) +- +-np.random.seed(8765993) +-#y_obs = np.asarray([stats.poisson.rvs(p) for p in mu], float) +-y_obs = self.rvs(mu_true, scale=scale, size=nobs) #this should work +-m = GAM(y_obs, x, family=f) #TODO: y_obs is twice __init__ and fit +-m.fit(y_obs, maxiter=100) +-res_gam = m.results +-self.res_gam = res_gam #attached for debugging +-self.mod_gam = m #attached for debugging +- +-res_glm = GLM(y_obs, exog, family=f).fit() +- +-#Note: there still are some naming inconsistencies +-self.res1 = res1 = Dummy() #for gam model +-#res2 = Dummy() #for benchmark +-self.res2 = res2 = res_glm #reuse existing glm results, will add additional +- +-#eta in GLM terminology +-res2.y_pred = res_glm.model.predict(res_glm.params, exog, linear=True) +-res1.y_pred = res_gam.predict(x) +-res1.y_predshort = res_gam.predict(x[:10]) #, linear=True) +- +-#mu +-res2.mu_pred = res_glm.model.predict(res_glm.params, exog, linear=False) +-res1.mu_pred = res_gam.mu +- +-#parameters +-slopes = [i for ss in m.smoothers for i in ss.params[1:]] +-const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers]) +-res1.params = np.array([const] + slopes) +- +- +-class TestGAMPoisson(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Poisson() +-self.rvs = stats.poisson.rvs +- +-self.init() +- +-class TestGAMBinomial(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Binomial() +-self.rvs = stats.bernoulli.rvs +- +-self.init() +- +-class _estGAMGaussianLogLink(BaseGAM): +-#test failure, but maybe precision issue, not far off +-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true)) +-#0.80409736263199649 +-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true))/tt.mu_true.mean() +-#0.023258245077813208 +-# np.mean((tt.res2.mu_pred - tt.mu_true)**2)/tt.mu_true.mean() +-#0.022989403735692578 +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Gaussian(links.log) +-self.rvs = stats.norm.rvs +-self.scale = 5 +- +-self.init() +- +- +-class TestGAMGamma(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Gamma(links.log) +-self.rvs = stats.gamma.rvs +- +-self.init() +- +-class _estGAMNegativeBinomial(BaseGAM): +-#rvs generation doesn't work, nbinom needs 2 parameters +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.NegativeBinomial() +-self.rvs = stats.nbinom.rvs +- +-self.init() +- +-if __name__ == '__main__': +-t1 =
Bug#770016: Clarify network access for building packages in main
On Sun, Nov 23, 2014 at 05:38:50PM +0100, Bill Allombert wrote: Package: debian-policy Severity: wishlist 2.2.1 says the packages in main must not require or recommend a package outside of main for compilation or execution (thus, the package must not declare a Pre-Depends, Depends, Recommends, Build-Depends, or Build-Depends-Indep relationship on a non- main package), In practice there is a consensus that this also means packages must not access external network servers which conforms to the spirit but not to the letter of this section. I offer the attached patch, which target section 4.9 Main building script: debian/rules This only address the issue in the bug title, namely 'Clarify network access for building packages in main'. Cheers, diff --git a/policy.sgml b/policy.sgml index 7bb703b..107ee44 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1928,12 +1928,16 @@ zope. impossible to auto-compile that package and also makes it hard for other people to reproduce the same binary package, all required targets must be non-interactive. It also follows that any target that these targets depend on must also be non-interactive. /p + p + For packages in the main archive, no required targets + may attempt network access. + /p p The targets are as follows: taglist tagttbuild/tt (required)/tag item It's fine, as it solves the initial problem. Seconded. -- WBR, wRAR signature.asc Description: Digital signature
Bug#761360: Bug#768896: nvidia-driver: resume from suspend breaks GNOME wallpaper
Andreas, Control: tag -1 moreinfo upstream Please try the new driver packages available at https://people.debian.org/~anbe/340.58/ Something like adding a new package source deb https://people.debian.org/~anbe/340.58/ ./ should work. (I cannot upload them to unstable currently since I'm waiting for another bugfix in the packaging to migrate to testing.) Just a question. I'm using 343.22 which is a version greater than 340.58 and have the issue. Do you confirm that this is normal and that 340.58 should fix this issue? Is that a specific Debian patch added into this version? Regards, -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767671: ekeyd: fails to remove: subprocess installed post-removal script fails when udev is not running
On Sun, Nov 16, 2014 at 11:46:06AM +0100, intrigeri wrote: Hi, Cameron Norman wrote (16 Nov 2014 03:01:32 GMT) : diff --git a/debian/ekeyd.postrm b/debian/ekeyd.postrm index 484db5c..4efc368 100644 --- a/debian/ekeyd.postrm +++ b/debian/ekeyd.postrm @@ -1,9 +1,5 @@ #!/bin/sh -e -if test -x /sbin/udevcontrol; then -udevcontrol --reload_rules 2/dev/null || udevcontrol reload_rules 2/dev/null -elif test -x /sbin/udevadm; then -udevadm control --reload-rules 2/dev/null || udevadm control --reload_rules 2/dev/null -fi +invoke-rc.d --quiet udev reload || true #DEBHELPER# IIRC, nowadays udev rules changes are picked up on new udev events anyway. So, it may be that simply removing ekeyd.postrm would do the job. But anyway, a smaller fix may be better suited for a freeze exception: simply adding || true at the end of each udevadm or udevcontrol pipeline should be enough. What do you think? I'd rather have Cameron's patch. The whole udevadm thing is a bug in itself. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Bug#768678: ruby-faraday: FTBFS in jessie: build-dependency not installable: ruby-em-synchrony
Hi, On Sun, Nov 23, 2014 at 6:54 PM, Andrey Rahmatullin w...@debian.org wrote: On Sun, Nov 23, 2014 at 06:06:33PM +0100, Margarita Manterola wrote: I've uploaded a new version of ruby-em-hiredis, which fixes the FTBFS (#759917), and I have requested the unblock of this package (#770728). If ruby-em-hiredis gets unblocked, then ruby-em-synchrony could be also unblocked and this one would get solved. AFAIK the freeze migration policy is only packages already in testing get migrated, ruby-em-synchrony is not in testing. I asked about this earlier on IRC and I was told that if a package had been in testing and got removed due to a RC bug, it would be accepted back again provided the fix followed the normal freeze policy, and the same for the other one that got transitively removed: @1416741742 marga So, if a package was removed already from testing due to FTBFS, and now dependencies are failing because of that, is it worth fixing it? Will it be accepted back? @1416741863 nthykier marga: Sounds reasonable at first glance, but it assumes that the changes between last-version-in-testing and upload complies with the freeze policy -- Regards, Marga -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770734: systemd: FTBFS in environment with all packages rebuilt locally
Source: systemd Version: 215-6 Severity: important From my pbuilder log, with pbuilder set up to use an archive of locally rebuilt packages: ... /bin/mkdir -p src/python-systemd/ /bin/sed -n -r 's/,//g; s/#define (SD_MESSAGE_[A-Z0-9_]+)\s.*/add_id(m, \1, \1) JOINER/p' ../src/systemd/sd-messages.h src/python-systemd/id128-constants.h make --no-print-directory all-recursive Making all in . LC_ALL=C /usr/bin/intltool-merge -x -u -c ./po/.intltool-merge-cache ../po ../src/hostname/org.freedesktop.hostname1.policy.in src/hostname/org.freedesktop.hostname1.policy Generating and caching the translation database Merging translations into src/hostname/org.freedesktop.hostname1.policy. Cannot open src/hostname/org.freedesktop.hostname1.policy: No such file or directory Makefile:17577: recipe for target 'src/hostname/org.freedesktop.hostname1.policy' failed make[4]: *** [src/hostname/org.freedesktop.hostname1.policy] Error 2 Makefile:16018: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 Makefile:8104: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/tmp/buildd/systemd-215/build-deb' dh_auto_build: make -j1 returned exit code 2 debian/rules:84: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/tmp/buildd/systemd-215' debian/rules:285: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 I can't reproduce this with a vanilla pbuilder setup, so I'm not sure what's causing the difference between the two builds. -- Daniel Schepler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769483: /usr/sbin/service restarts daemons in the current session cgroups when not running systemd
[Matteo Panella] If you need more details I'd be happy to provide them. You can perhaps provide details on how this work in Wheezy, to allow us to understand what changed? As far as I know, sysvinit do not have any relationship with cgroups at all, and thus do not quite sure understand why it now is a bug. Can you explain why you believe sysvinit should do anything about cgroups at all? I hope some of the more active sysvinit maintainers can look at this, as I really lack the time to figure out the cgroups details. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770735: freecad: SIGSEGV in Fillet
Package: freecad
Version: 0.14.3702+dfsg-3
Severity: normal
This reliably crashes Freecad:
File-New
Start-Part
Cube
Fillet
Select an edge
Ok
Fillet
All
Program exits, having printed
FreeCAD 0.14, Libs: 0.14R3702 (Git)
© Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2011
# ###
## # # # #
# ## # # # # #
# # # # # # # # # #
# # ## # # #
# # ## ## # # # ## ## ##
# # ### # # ## ## ##
Coin error in SoMField::deleteValues(): invalid indices [-1, -1] for array of
size 0
Coin error in SoMField::deleteValues(): invalid indices [-1, -1] for array of
size 0
Coin error in SoMField::deleteValues(): invalid indices [-1, -1] for array of
size 0
Coin error in SoMField::deleteValues(): invalid indices [-1, -1] for array of
size 0
*** Abort *** an exception was raised, but no catch was found.
... The exception is:SIGSEGV 'segmentation violation' detected. Address
40
Exit status is 1.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages freecad depends on:
ii libboost-filesystem1.55.0 1.55.0+dfsg-3
ii libboost-program-options1.55.0 1.55.0+dfsg-3
ii libboost-regex1.55.01.55.0+dfsg-3
ii libboost-signals1.55.0 1.55.0+dfsg-3
ii libboost-system1.55.0 1.55.0+dfsg-3
ii libboost-thread1.55.0 1.55.0+dfsg-3
ii libc6 2.19-12
ii libcoin80 3.1.4~abc9f50-7
ii libfreeimage3 3.15.4-4.1+b1
ii libfreetype62.5.2-2
ii libgcc1 1:4.9.2-1
ii libgfortran34.9.2-1
ii libgl1-mesa-glx [libgl1]10.3.2-1
ii libglu1-mesa [libglu1] 9.0.0-2
ii libice6 2:1.0.9-1
ii liboce-foundation8 0.15-4
ii liboce-modeling80.15-4
ii liboce-ocaf-lite8 0.15-4
ii liboce-ocaf80.15-4
ii liboce-visualization8 0.15-4
ii libpyside1.21.2.2-1+b1
ii libpython2.72.7.8-11
ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii libqt4-svg 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii libqt4-xmlpatterns 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii libqtwebkit42.3.4.dfsg-3
ii libquadmath04.9.2-1
ii libshiboken1.2 1.2.2-1+b1
ii libsm6 2:1.2.2-1
ii libsoqt4-20 1.6.0~e8310f-2
ii libspnav0 0.2.2-1
ii libstdc++6 4.9.2-1
ii libx11-62:1.6.2-3
ii libxerces-c3.1 3.1.1-5
ii libxext62:1.3.3-1
ii libzipios++0c2a 0.1.5.9+cvs.2007.04.28-5.1
ii python-collada 0.4-2
ii python-matplotlib 1.4.2-3
ii python-pivy 0.5.0~v609hg-3
ii python-ply 3.4-5
ii python-pyside 1.2.2-1
ii python2.7 2.7.8-11
pn python:any none
ii zlib1g 1:1.2.8.dfsg-2
freecad recommends no packages.
Versions of packages freecad suggests:
ii freecad-doc 0.14.3702+dfsg-3
-- no debconf information
-- debsums errors found:
debsums: can't open freecad file /usr/share/menu/freecad/menu (Not a directory)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768678: ruby-faraday: FTBFS in jessie: build-dependency not installable: ruby-em-synchrony
Control: tags -1 +pending Hi, The unblock has been added in #770728, so this bug will go away on its own when ruby-em-synchrony reaches testing. I'm tagging this therefore as pending, although I'm not 100% sure that's the right action. -- Cheers, Marga -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770736: unblock: ghc/7.6.3-20
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Please unblock package ghc
The fix can possible fix a problem with triggers during a wheezy →
testing upgrade (and even if it does not fix it in all cases, it is an
improvements, as it avoids unnecessary trigger runs).
unblock ghc/7.6.3-20
- -- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAlRyIp8ACgkQ9ijrk0dDIGyEyQCgi4rQ4qg4rBHpmUkvI4MPt1Y6
bZMAn13rICw0ncz411Icf9keUYIFMzNj
=qyJu
-END PGP SIGNATURE-
diff -Nru ghc-7.6.3/debian/changelog ghc-7.6.3/debian/changelog
--- ghc-7.6.3/debian/changelog 2014-09-29 17:28:56.0 +0200
+++ ghc-7.6.3/debian/changelog 2014-11-23 11:20:59.0 +0100
@@ -1,3 +1,9 @@
+ghc (7.6.3-20) unstable; urgency=medium
+
+ * Mark all triggers -noawait. Possibly Closes: #769554
+
+ -- Joachim Breitner nome...@debian.org Sun, 23 Nov 2014 11:20:59 +0100
+
ghc (7.6.3-19) unstable; urgency=medium
* Fix armel/armhf script munging; ghci and runghc are not available on
diff -Nru ghc-7.6.3/debian/control ghc-7.6.3/debian/control
--- ghc-7.6.3/debian/control 2014-09-29 17:26:40.0 +0200
+++ ghc-7.6.3/debian/control 2014-11-23 11:20:35.0 +0100
@@ -34,6 +34,7 @@
Package: ghc
Architecture: any
Depends: llvm-3.4 [armel armhf], gcc, libgmp-dev, libffi-dev, libbsd-dev, libc6-dev, ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: dpkg (= 1.16.1)
Provides: haskell-compiler, ${provided-devs}, ${haskell:Provides}, ${ghci}
Replaces: ghc6 ( 7)
Conflicts: ghc6 ( 7), ${conflicting-devs}
@@ -75,6 +76,7 @@
Replaces: ghc6-doc ( 7)
Conflicts: ghc6-doc ( 7), ghc (= 7.0.3-1)
Depends: ${haddock:Depends}, ${misc:Depends}, perl
+Pre-Depends: dpkg (= 1.16.1)
Description: Documentation for the Glasgow Haskell Compilation system
The Glorious Glasgow Haskell Compilation system (GHC) is a compiler for
Haskell.
diff -Nru ghc-7.6.3/debian/ghc-doc.triggers ghc-7.6.3/debian/ghc-doc.triggers
--- ghc-7.6.3/debian/ghc-doc.triggers 2014-09-29 17:26:40.0 +0200
+++ ghc-7.6.3/debian/ghc-doc.triggers 2014-11-23 11:19:14.0 +0100
@@ -1,6 +1,6 @@
-interest /usr/lib/ghc-doc/haddock
-interest /usr/lib/ghc-7.0.2/haddock
-interest /usr/lib/ghc-7.0.3/haddock
-interest /var/lib/ghc/package.conf.d
-interest /var/lib/ghc-7.0.3/package.conf.d
-interest /var/lib/ghc-7.0.4/package.conf.d
+interest-noawait /usr/lib/ghc-doc/haddock
+interest-noawait /usr/lib/ghc-7.0.2/haddock
+interest-noawait /usr/lib/ghc-7.0.3/haddock
+interest-noawait /var/lib/ghc/package.conf.d
+interest-noawait /var/lib/ghc-7.0.3/package.conf.d
+interest-noawait /var/lib/ghc-7.0.4/package.conf.d
diff -Nru ghc-7.6.3/debian/ghc.triggers ghc-7.6.3/debian/ghc.triggers
--- ghc-7.6.3/debian/ghc.triggers 2014-09-29 17:26:40.0 +0200
+++ ghc-7.6.3/debian/ghc.triggers 2014-11-23 11:19:22.0 +0100
@@ -1 +1 @@
-interest /var/lib/ghc/package.conf.d
+interest-noawait /var/lib/ghc/package.conf.d
Bug#765687: dpkg: no Setting up $p ($v) ... messages from apt-get -f install
Control: tags -1 - moreinfo + patch
Control: severity -1 serious
Hi,
The same problem with missing messages occurs in a clean jessie or sid
pbuilder chroot.
In addition to the Setting up messages, also the Processing triggers
messages seem to be missing sometimes (no testcase).
If I install something larger (e.g. libreoffice) I do get (some? all?)
Setting up messages.
I haven't exactly figured out why large installations work and small
do not, but I have at least an idea what goes on and how to fix it:
This is partly a regression of a fix for kfreebsd where something
similar happened (although it was reported more as an issue showing in
a stepped output).
What apt does is creating a pseudo terminal to run various dpkg
instances in it. I have searched for other tools doing this, but all of
them seem to be creating one only to execute a program once…
Anyway, the first call is no problem, dpkg runs perfectly fine in the
pseudo terminal and the output is moved from the slave to the master.
Now, if the first call completes we prepare the next call by opening the
slave side again (reusing the same FD works for linux, but fails on
kfreebsd), which works for both, but on linux it still looses the
connection between master and slave 'sometimes' if this was the only
reference to the pseudo terminal. So what we do now is keeping
a reference to the slave open at all times, but do not use it, which
seems to make freebsd as well as linux happy again.
(Some more techno-babble can be found in the commit message.)
The rest of the attached git commit is reshuffling code to make sure
that we actually create a pseudo terminal if possible as we otherwise do
not populate the log in some cases while we absolutely should.
I am raising severity for this as we not only fail to keep a log, but we
potentially eat conffile and debconf prompts which is rather bad.
Best regards
David Kalnischkies
commit 150bdc9ca5d656f9fba94d37c5f4f183b02bd746
Author: David Kalnischkies da...@kalnischkies.de
Date: Tue Nov 18 00:59:39 2014 +0100
fix PTY interaction on linux and kfreebsd
We run dpkg on its own pty, so we can log its output and have our own
output around it (like the progress bar), while also allowing debconf
and configfile prompts to happen.
In commit 223ae57d468fdcac451209a095047a07a5698212 we changed to
constantly reopening the slave for kfreebsd. This has the sideeffect
though that in some cases slave and master will lose their connection on
linux, so that no output is passed along anymore. We fix this by having
always an fd referencing the slave open (linux), but we don't use it
(kfreebsd).
Failing to get our PTY up and running has many (bad) consequences
including (not limited to, nor all at ones or in any case) garbled ouput,
no output, no logging, a (partial) mixture of the previous items, …
This commit is therefore also reshuffling quiet a bit of the creation
code to get especially the output part up and running on linux and the
logging for kfreebsd.
Note that the testcase tries to cover some cases, but this is an
interactivity issue so only interactive usage can really be a good test.
Closes: 765687
diff --git a/apt-pkg/deb/dpkgpm.cc b/apt-pkg/deb/dpkgpm.cc
index dd03eac..5938750 100644
--- a/apt-pkg/deb/dpkgpm.cc
+++ b/apt-pkg/deb/dpkgpm.cc
@@ -72,7 +72,8 @@ class pkgDPkgPMPrivate
public:
pkgDPkgPMPrivate() : stdin_is_dev_null(false), dpkgbuf_pos(0),
term_out(NULL), history_out(NULL),
-progress(NULL), master(-1), slave(NULL)
+ progress(NULL), tt_is_valid(false), master(-1),
+ slave(NULL), protect_slave_from_dying(-1)
{
dpkgbuf[0] = '\0';
}
@@ -90,8 +91,10 @@ public:
// pty stuff
struct termios tt;
+ bool tt_is_valid;
int master;
char * slave;
+ int protect_slave_from_dying;
// signals
sigset_t sigmask;
@@ -1069,47 +1072,40 @@ void pkgDPkgPM::StartPtyMagic()
}
_error-PushToStack();
- // if tcgetattr for both stdin/stdout returns 0 (no error)
- // we do the pty magic
- if (tcgetattr(STDOUT_FILENO, d-tt) == 0
- tcgetattr(STDIN_FILENO, d-tt) == 0)
+
+ d-master = posix_openpt(O_RDWR | O_NOCTTY);
+ if (d-master == -1)
+ _error-Errno(posix_openpt, _(Can not write log (%s)), _(Is /dev/pts mounted?));
+ else if (unlockpt(d-master) == -1)
+ _error-Errno(unlockpt, Unlocking the slave of master fd %d failed!, d-master);
+ else
{
- d-master = posix_openpt(O_RDWR | O_NOCTTY);
- if (d-master == -1)
- _error-Errno(posix_openpt, _(Can not write log (%s)), _(Is /dev/pts mounted?));
- else if (unlockpt(d-master) == -1)
- {
- _error-Errno(unlockpt, Unlocking the slave of master fd %d failed!, d-master);
- close(d-master);
- d-master = -1;
- }
+ char const * const slave_name = ptsname(d-master);
+ if (slave_name == NULL)
+ _error-Errno(ptsname, Getting
Bug#768117: debian-policy: WSGI API must distinguish between Python 2 and 3
On Sun, Nov 23, 2014 at 05:45:37PM +, Simon McVittie wrote:
On 23/11/14 17:19, Bill Allombert wrote:
On Wed, Nov 05, 2014 at 02:38:39PM +1100, Brian May wrote:
We need two virtual package names, one for Python2 and one for Python3.
What I am unclear is why a single virtual package httpd-wsgi3 will work
for python 3.2, 3.3, 3.4 etc.
All versions of Python 2.x are broadly source-compatible, and all
versions of Python 3.x are broadly source-compatible, but correct Python
2.x code usually needs significant source changes to be interpreted
correctly by Python 3.x. As a result of porting being required, and the
way we package extensions in Debian, dependency declarations need to
change across the 2 - 3 boundary, from python-foo to python3-foo.
Thanks for your clarification. Is the attached patch OK ?
Cheers,
--
Bill. ballo...@debian.org
Imagine a large red swirl here.
diff --git a/virtual-package-names-list.txt b/virtual-package-names-list.txt
index f52ddba..f68133f 100644
--- a/virtual-package-names-list.txt
+++ b/virtual-package-names-list.txt
@@ -106,7 +106,8 @@ Network
ftp-server a FTP server
httpd a HTTP server
httpd-cgi A CGI capable HTTP server
- httpd-wsgi A WSGI capable HTTP server
+ httpd-wsgi A WSGI capable HTTP server (python 2 API)
+ httpd-wsgi3 A WSGI capable HTTP server (python 3 API)
ident-serveran identd daemon
inet-superserveran inetd server
lambdamoo-core a lambdamoo-compatible database package
@@ -343,3 +344,4 @@ Bill Allombert:
16 Jul 2014 Added java{5,6,7,8,9}-runtime{,-headless}
Removed java1-runtime, java2-runtime
30 Jul 2014 Added httpd-wsgi
+ 23 Nov 2014 Added httpd-wsgi3
Bug#769259: golang-testify: FTBFS in jessie/i386: dh_auto_test: go test -v github.com/stretchr/testify github.com/stretchr/testify/assert github.com/stretchr/testify/http github.com/stretchr/testify/m
On Sat, Nov 15, 2014 at 09:57:17PM +0100, Lucas Nussbaum wrote:
On 15/11/14 at 21:18 +0100, Jelmer Vernooij wrote:
Hi Lucas,
On Wed, Nov 12, 2014 at 11:46:23AM +0100, Lucas Nussbaum wrote:
Source: golang-testify
Version: 0.0~git20140717-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20141112 qa-ftbfs
Justification: FTBFS in jessie on i386
Hi,
During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on i386.
Are you able to reproduce this locally? The buildds didn't have any problem
with this
version of the package earlier, and I'm also having trouble reproducing it
with
the current state of the archive.
Hi,
It builds fine on amd64, but fails on i386. The first failing test seem
to be:
if !Equal(mockT, int64(123), uint64(123)) {
t.Error(Equal should return true)
}
I could reproduce it again in a chroot on EC2. I don't have a local i386
chroot unfortunately.
FWIW, I reproduced it with cowbuilder using a jessie i386 chroot (host
system is amd64).
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770703: [Pkg-openldap-devel] Bug#770703: slapd segfault with memberof overlay on frontend db
Control: tags -1 + upstream moreinfo Control: forwarded -1 http://www.openldap.org/its/index.cgi/Incoming?id=7249 Hi Florian, Thank you for taking the time to report this bug. On Sun, Nov 23, 2014 at 01:37:27PM +0100, Florian Mutter wrote: The upstream bug seems to be http://www.openldap.org/its/index.cgi/Incoming?id=7249 but I'm not sure whether its fixed or not. I did a brief test (just creating a group and adding/removing a few members) using the config you supplied, and reproduced the crash in stable but not with 2.4.40 from testing. I haven't looked into this in detail and don't know how to trigger the other cases Jan mentioned, but it does appear to work, at least for basic cases with no other overlays involved. If you have a development or staging environment set up, is it possible for you to test the newer slapd there and see if it resolves your problem? thanks, Ryan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
On Mon, 24 Nov 2014, Charles Plessy wrote:
Le Sun, Nov 23, 2014 at 03:08:47PM -0200, Henrique de Moraes Holschuh a écrit
:
On Mon, 24 Nov 2014, Charles Plessy wrote:
do you have examples of packages having empty fields in source package
control
files ? I have not found any. (In the sense that a field that only
contains
a substitution variable is not considered empty).
They come from empty substitutions, yes.
Then they are not empty: there is a big difference between Depends: and
Depends: ${foo}. I think that it would be very confusing if we would refer
them as empty.
Well, both are valid. Can you suggest alternative wording?
For the record, some packages even autogenerate debian/control from a
template during package build. I can't recall the name of any right now,
though.
Also, the bug started with a problem where empty means nothing after the
colon.
In a binary package.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770737: unblock: kexec-tools/1:2.0.7-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package kexec-tools The latest uplaod to unstable fixes bugs 766338 and 767449. Both of these bugs have severity important but both of these bugs have severe impact on the system. Effectively with these bugs, a system can not be shut down. This is a severe limitation and would impact jeesie usability significantly. debdiff is at the end of this report. unblock kexec-tools/1:2.0.7-4 *** /tmp/kexec-tools_2.0.7-4.debdiff diff -Nru kexec-tools-2.0.7/debian/changelog kexec-tools-2.0.7/debian/changelog --- kexec-tools-2.0.7/debian/changelog 2014-10-10 10:31:21.0 -0600 +++ kexec-tools-2.0.7/debian/changelog 2014-11-03 16:38:48.0 -0700 @@ -1,3 +1,10 @@ +kexec-tools (1:2.0.7-4) unstable; urgency=medium + + * Changed the way systemd presence is detected to make shutdown more +reliable (closes: Bug#766338, closes: Bug#767449) + + -- Khalid Aziz kha...@debian.org Mon, 03 Nov 2014 16:37:53 -0700 + kexec-tools (1:2.0.7-3) unstable; urgency=medium * Fixed kexec-load init script so it will detect systemd diff -Nru kexec-tools-2.0.7/debian/kexec-load.init.d kexec-tools-2.0.7/debian/kexec-load.init.d --- kexec-tools-2.0.7/debian/kexec-load.init.d 2014-10-10 10:12:29.0 -0600 +++ kexec-tools-2.0.7/debian/kexec-load.init.d 2014-11-03 16:25:20.0 -0700 @@ -1,4 +1,4 @@ -#! /bin/sh +#! /bin/sh -x ### BEGIN INIT INFO # Provides:kexec-load # Required-Start: $local_fs $remote_fs kexec @@ -103,8 +103,7 @@ stop) # If running systemd, we want kexec reboot only if current # command is reboot - pidof systemd /dev/null 21 - if [ $? -eq 0 ]; then + if [ -d /run/systemd/system ]; then systemctl list-jobs systemd-reboot.service | grep -q systemd-reboot.service if [ $? -ne 0 ]; then exit 0 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768695: Bug #768695: statsmodels: FTBFS in jessie: ImportError: cannot import name DateRange
tags 768695 +pending Hi have uploaded the attached debdiff targetted at testing-proposed-updates to DELAYED/3-day. See also the pre-approval/unblock bug for relesae.debian.org, #770730. Michael diff -Nru statsmodels-0.4.2/debian/changelog statsmodels-0.4.2/debian/changelog --- statsmodels-0.4.2/debian/changelog 2012-06-29 23:26:49.0 +0200 +++ statsmodels-0.4.2/debian/changelog 2014-11-23 17:55:26.0 +0100 @@ -1,3 +1,10 @@ +statsmodels (0.4.2-1.1) testing; urgency=medium + + * Non-maintainer upload. + * Fixes various problems with build process (Closes: #768695) + + -- Tomasz Buchert tomasz.buch...@inria.fr Sun, 23 Nov 2014 17:46:48 +0100 + statsmodels (0.4.2-1) unstable; urgency=low * Fresh upstream release addressing FTBFS across big-endian architectures. diff -Nru statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch --- statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch 1970-01-01 01:00:00.0 +0100 +++ statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch 2014-11-23 17:57:08.0 +0100 @@ -0,0 +1,128 @@ +Description: remove tests that use uncompatible scipy interface + The tests use an rvs method which has an incompatible + interface. We remove these failing tests altogether. + +--- statsmodels-0.4.2.orig/statsmodels/sandbox/tests/test_gam.py statsmodels-0.4.2/statsmodels/sandbox/tests/test_gam.py +@@ -187,121 +187,3 @@ class TestAdditiveModel(BaseAM, CheckAM) + const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers]) + #print const, slopes + res1.params = np.array([const] + slopes) +- +- +-class BaseGAM(BaseAM, CheckGAM): +- +-def init(self): +-nobs = self.nobs +-y_true, x, exog = self.y_true, self.x, self.exog +-if not hasattr(self, 'scale'): +-scale = 1 +-else: +-scale = self.scale +- +-f = self.family +- +-self.mu_true = mu_true = f.link.inverse(y_true) +- +-np.random.seed(8765993) +-#y_obs = np.asarray([stats.poisson.rvs(p) for p in mu], float) +-y_obs = self.rvs(mu_true, scale=scale, size=nobs) #this should work +-m = GAM(y_obs, x, family=f) #TODO: y_obs is twice __init__ and fit +-m.fit(y_obs, maxiter=100) +-res_gam = m.results +-self.res_gam = res_gam #attached for debugging +-self.mod_gam = m #attached for debugging +- +-res_glm = GLM(y_obs, exog, family=f).fit() +- +-#Note: there still are some naming inconsistencies +-self.res1 = res1 = Dummy() #for gam model +-#res2 = Dummy() #for benchmark +-self.res2 = res2 = res_glm #reuse existing glm results, will add additional +- +-#eta in GLM terminology +-res2.y_pred = res_glm.model.predict(res_glm.params, exog, linear=True) +-res1.y_pred = res_gam.predict(x) +-res1.y_predshort = res_gam.predict(x[:10]) #, linear=True) +- +-#mu +-res2.mu_pred = res_glm.model.predict(res_glm.params, exog, linear=False) +-res1.mu_pred = res_gam.mu +- +-#parameters +-slopes = [i for ss in m.smoothers for i in ss.params[1:]] +-const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers]) +-res1.params = np.array([const] + slopes) +- +- +-class TestGAMPoisson(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Poisson() +-self.rvs = stats.poisson.rvs +- +-self.init() +- +-class TestGAMBinomial(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Binomial() +-self.rvs = stats.bernoulli.rvs +- +-self.init() +- +-class _estGAMGaussianLogLink(BaseGAM): +-#test failure, but maybe precision issue, not far off +-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true)) +-#0.80409736263199649 +-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true))/tt.mu_true.mean() +-#0.023258245077813208 +-# np.mean((tt.res2.mu_pred - tt.mu_true)**2)/tt.mu_true.mean() +-#0.022989403735692578 +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Gaussian(links.log) +-self.rvs = stats.norm.rvs +-self.scale = 5 +- +-self.init() +- +- +-class TestGAMGamma(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Gamma(links.log) +-self.rvs = stats.gamma.rvs +- +-self.init() +- +-class _estGAMNegativeBinomial(BaseGAM): +-#rvs generation doesn't work, nbinom needs 2 parameters +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.NegativeBinomial() +-self.rvs = stats.nbinom.rvs +- +-
Bug#750642: This is a duplicate to the (fixed) #750646
Hi, this bug describes in effect the same problem as #750646 and can be closed (verified that the fix for #750646 also fixes this problem). Regards, Steffen Ullrich -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770737: unblock: kexec-tools/1:2.0.7-4
Control: tags -1 moreinfo On 2014-11-23 19:08, Khalid Aziz wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package kexec-tools The latest uplaod to unstable fixes bugs 766338 and 767449. Both of these bugs have severity important but both of these bugs have severe impact on the system. Effectively with these bugs, a system can not be shut down. This is a severe limitation and would impact jeesie usability significantly. debdiff is at the end of this report. unblock kexec-tools/1:2.0.7-4 Hi, One question about the actual change (see below): [...] * Fixed kexec-load init script so it will detect systemd diff -Nru kexec-tools-2.0.7/debian/kexec-load.init.d kexec-tools-2.0.7/debian/kexec-load.init.d --- kexec-tools-2.0.7/debian/kexec-load.init.d2014-10-10 10:12:29.0 -0600 +++ kexec-tools-2.0.7/debian/kexec-load.init.d2014-11-03 16:25:20.0 -0700 @@ -1,4 +1,4 @@ -#! /bin/sh +#! /bin/sh -x ^ Is this change intentional? It does not look like it and it is not mentioned in the changelog. [...] ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770737: unblock: kexec-tools/1:2.0.7-4
Control: tags -1 + moreinfo On Sun, 2014-11-23 at 11:08 -0700, Khalid Aziz wrote: Please unblock package kexec-tools The latest uplaod to unstable fixes bugs 766338 and 767449. Both of these bugs have severity important but both of these bugs have severe impact on the system. Effectively with these bugs, a system can not be shut down. This is a severe limitation and would impact jeesie usability significantly. -#! /bin/sh +#! /bin/sh -x I assume you didn't mean to include that bit. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770738: unblock: nwchem/6.5+r26243-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package nwchem
This fixes a FTBFS bug on a previously uncompiled architecture (arm64),
a serious miscompile which leads to SIGILL on some amd64 CPUs, and it
reintroduces a Debian-specific patch which makes nwchem find essential
data files at runtime.
The last one can be worked-around by setting an environment variable or
setting up a configuration file, but it should really just-work, as it
did for jessie.
Michael
unblock nwchem/6.5+r26243-4
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru nwchem-6.5+r26243/debian/changelog nwchem-6.5+r26243/debian/changelog
--- nwchem-6.5+r26243/debian/changelog 2014-10-12 00:22:00.0 +0200
+++ nwchem-6.5+r26243/debian/changelog 2014-11-23 17:36:00.0 +0100
@@ -1,3 +1,20 @@
+nwchem (6.5+r26243-4) unstable; urgency=medium
+
+ * debian/patches/02_makefile_flags.patch: Patch updated, to remove -m64 from
+compiler flags on arm64 (Closes: #769525).
+
+ -- Michael Banck mba...@debian.org Sun, 23 Nov 2014 17:35:50 +0100
+
+nwchem (6.5+r26243-3) unstable; urgency=medium
+
+ * debian/patches/02_makefile_flags.patch: Patch updated to remove additions
+to $(FOPTIMIZE) which are not applicable to the baseline amd64
+architecture (Closes: #767481).
+ * debian/patches/01_hardcode_basis-sets_location.patch: Reintroduced patch,
+updated (Closes: #769297).
+
+ -- Michael Banck mba...@debian.org Thu, 13 Nov 2014 14:01:47 +0100
+
nwchem (6.5+r26243-2) unstable; urgency=medium
* debian/patches/14_fix_ga_download.patch: Updated to surpress unnecessary
diff -Nru
nwchem-6.5+r26243/debian/patches/01_hardcode_basis-sets_location.patch
nwchem-6.5+r26243/debian/patches/01_hardcode_basis-sets_location.patch
--- nwchem-6.5+r26243/debian/patches/01_hardcode_basis-sets_location.patch
1970-01-01 01:00:00.0 +0100
+++ nwchem-6.5+r26243/debian/patches/01_hardcode_basis-sets_location.patch
2014-11-12 23:53:21.0 +0100
@@ -0,0 +1,33 @@
+Index: nwchem-6.5+r26243/src/basis/bas_input.F
+===
+--- nwchem-6.5+r26243.orig/src/basis/bas_input.F
nwchem-6.5+r26243/src/basis/bas_input.F
+@@ -1180,12 +1180,11 @@ c
+ noslash=.false.
+ calls = calls + 1
+ if (debug) write(luout,*)' calls:calls: ',calls
+- call util_nwchem_srcdir(compiled_name)
++c call util_nwchem_srcdir(compiled_name)
+ c
+ c add here basis/libraries bit
+ c
+- compiled_name=compiled_name(1:inp_strlen(compiled_name))
+- $ ///basis/libraries/
++ compiled_name=/usr/share/nwchem/libraries/
+ *
+ * order of precedence for choosing name
+ * 1) value of NWCHEM_BASIS_LIBRARY environment variable
+Index: nwchem-6.5+r26243/src/nwpw/libraryps/nwpw_libfile.F
+===
+--- nwchem-6.5+r26243.orig/src/nwpw/libraryps/nwpw_libfile.F
nwchem-6.5+r26243/src/nwpw/libraryps/nwpw_libfile.F
+@@ -118,8 +118,7 @@ cNWPW_LIBRARY
+ c
+ c add here nwpw/libraryps bit
+ c
+- libname=libname(1:inp_strlen(libname))
+- ///nwpw/libraryps/
++ libname=/usr/share/nwchem/libraryps/
+ if (util_find_dir(libname)) then
+ goto 99
+ else
diff -Nru nwchem-6.5+r26243/debian/patches/02_makefile_flags.patch
nwchem-6.5+r26243/debian/patches/02_makefile_flags.patch
--- nwchem-6.5+r26243/debian/patches/02_makefile_flags.patch2014-09-28
12:35:42.0 +0200
+++ nwchem-6.5+r26243/debian/patches/02_makefile_flags.patch2014-11-23
17:35:47.0 +0100
@@ -1,7 +1,7 @@
-Index: nwchem-6.5/src/config/makefile.h
+Index: nwchem-6.5+r26243/src/config/makefile.h
===
nwchem-6.5.orig/src/config/makefile.h
-+++ nwchem-6.5/src/config/makefile.h
+--- nwchem-6.5+r26243.orig/src/config/makefile.h
nwchem-6.5+r26243/src/config/makefile.h
@@ -1384,7 +1384,7 @@ endif
endif
@@ -54,10 +54,50 @@
_G77V33= $(shell g77 -v 21|egrep spec|head -n 1|awk ' /3.3/ {print
Y}')
ifeq ($(FC),g77)
-Index: nwchem-6.5/src/peigs/DEFS
+@@ -1758,13 +1758,6 @@
+ endif
+ FOPTIMIZE = -O2
+ ifeq ($(_FC),gfortran)
+- ifeq ($(_CPU),aarch64)
+- DONTHAVEM64OPT=Y
+- endif
+- ifneq ($(DONTHAVEM64OPT),Y)
+- FOPTIONS = -m64
+- COPTIONS = -m64
+- endif
+ COPTIONS += -Wall
+ FOPTIONS += -ffast-math #-Wunused
+ FOPTIMIZE += -ffast-math -Wuninitialized
+@@ -2125,25 +2118,12 @@
+ endif
+ LINK.f = $(FC) $(LDFLAGS)
Bug#770739: tcos: should not be a native package
Package: tcos Version: 0.89.93 Severity: important tcos doesn't sound like it has no use outside Debian. It probably should not be a native package. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770352: Patch uploaded to DELAYED-3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --- gcc-3.3-3.3.6ds1/debian/changelog +++ gcc-3.3-3.3.6ds1/debian/changelog @@ -1,3 +1,11 @@ +gcc-3.3 (1:3.3.6ds1-27.2) unstable; urgency=medium + + * Non-maintainer upload. + * Use a nonempty default target architecture as dpkg-architecture no +longer supports -a without argument. (Closes: #770352) + + -- Simon Richter s...@debian.org Sun, 23 Nov 2014 18:58:06 +0100 + gcc-3.3 (1:3.3.6ds1-27.1) unstable; urgency=medium * Non-maintainer upload. diff -u gcc-3.3-3.3.6ds1/debian/rules.defs gcc-3.3-3.3.6ds1/debian/rules.defs - --- gcc-3.3-3.3.6ds1/debian/rules.defs +++ gcc-3.3-3.3.6ds1/debian/rules.defs @@ -31,6 +31,8 @@ DEBIAN_TARGET_FILE := $(strip $(shell cat debian/target 2/dev/null)) ifneq ($(DEBIAN_TARGET_FILE),) GCC_TARGET := $(DEBIAN_TARGET_FILE) +else +GCC_TARGET := $(DEB_HOST_ARCH) endif endif -BEGIN PGP SIGNATURE- Version: GnuPG v1 iJwEAQECAAYFAlRyJrAACgkQ0sfeulffv7sk/AQAugeQ/qcAk+fO7gg5DAF7cL8i a3soSH4FEeXXRU/lBbhyRjIsZuiIs835dzdf8XWT3p2MLcMO5vFYlSKd/qwTrJdC gaACE6/l7YlQlro2Jcmcd30cONutXyQAaJDIS3By18MeZCUBIJ7H/Nmubp+66NAd sD23orvDWshN/W6WJX0= =6s/R -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770556: libgtk-3-0: icon-shadow for SVG icons doesn't get scaled properly
Hi, I spent hours and hours yesterday trying to create a simple reproduction case for this, and I couldn't. Cinnamon uses st which is an internal library used by gnome-shell and forked in cinnamon. st uses both gtk and clutter, and its own styling system. I suspect the issue is that the handling of icons changed in gtk and it might be that this requires a change in cinnamon internal st or it might be that this is an actual bug in gtk, I haven't been able to figure this one out :-/ I'll keep investigating. -- Regards, Marga -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770740: qemu-system: qemu-system-i386 -fda /dev/fd0 ... fails.
Package: qemu-system Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Attempt to access host floppy /dev/fd0. * What exactly did you do (or not do) that was effective (or ineffective)? qemu-system-i386 -fda /dev/fd0 ... fails. * What was the outcome of this action? Host floppy /dev/fd0 can not be used by qemu-system-i386. * What outcome did you expect instead? /dev/fd0 should work as well as a floppy image file as in -fda /home/peter/MyDisketteImage. *** End of the template - remove these lines *** == A removable line. == == 2nd removable line. == -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qemu-system depends on: ii ipxe-qemu 1.0.0+git-20120202.f6840ba-3 ii libaio1 0.3.109-3 ii libasound21.0.25-4 ii libbluetooth3 4.99-2 ii libbrlapi0.5 4.4-10+deb7u1 ii libc6 2.13-38+deb7u6 ii libcurl3-gnutls 7.26.0-1+wheezy11 ii libfdt1 1.3.0-4 ii libgl1-mesa-glx [libgl1] 8.0.5-4+deb7u2 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgnutls26 2.12.20-8+deb7u2 ii libiscsi1 1.4.0-3 ii libjpeg8 8d-1+deb7u1 ii libncurses5 5.9-10 ii libpng12-01.2.49-1 ii libpulse0 2.0-6.1 ii libsasl2-22.1.25.dfsg1-6+deb7u1 ii libsdl1.2debian 1.2.15-5 ii libtinfo5 5.9-10 ii libusbredirparser00.4.3-2 ii libuuid1 2.20.1-5.3 ii libvdeplug2 2.3.2-4 ii libx11-6 2:1.5.0-1+deb7u1 ii libxen-4.14.1.4-3+deb7u3 ii libxenstore3.04.1.4-3+deb7u3 ii openbios-ppc 1.0+svn1060-1 ii openbios-sparc1.0+svn1060-1 ii openhackware 0.4.1-6 ii qemu-keymaps 1.1.2+dfsg-6a+deb7u5 ii seabios 1.7.0-1 ii vgabios 0.7a-3 ii zlib1g1:1.2.7.dfsg-13 Versions of packages qemu-system recommends: ii qemu-utils 1.1.2+dfsg-6a+deb7u5 ii vde22.3.2-4 Versions of packages qemu-system suggests: pn samba none -- no debconf information -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://carnot.yi.org/ Bcc: peter at easthope. ca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770740: qemu-system: qemu-system-i386 -fda /dev/fd0 ... fails.
Control: tag -1 + moreinfo unreproducible 23.11.2014 20:34, pe...@easthope.ca wrote: Package: qemu-system Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Attempt to access host floppy /dev/fd0. * What exactly did you do (or not do) that was effective (or ineffective)? qemu-system-i386 -fda /dev/fd0 ... fails. What does fails mean? It works here just fine. Please provide some useful information about how exactly it fails for you, and also specify which version of qemu you're using - your bug report does not specify this. Please also show complete qemu command line, not just the single argument. * What was the outcome of this action? Host floppy /dev/fd0 can not be used by qemu-system-i386. * What outcome did you expect instead? /dev/fd0 should work as well as a floppy image file as in -fda /home/peter/MyDisketteImage. This works for me as well, with a reasonable floppy image. Tagging as 'moreinfo unreproducible'. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765129: tcos: diff for NMU version 0.89.93+nmu1
Control: tags 765129 + pending Dear maintainer, I've prepared an NMU for tcos (versioned as 0.89.93+nmu1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 diff -Nru tcos-0.89.93/debian/changelog tcos-0.89.93+nmu1/debian/changelog --- tcos-0.89.93/debian/changelog 2013-12-31 13:28:27.0 + +++ tcos-0.89.93+nmu1/debian/changelog 2014-11-23 18:36:19.0 + @@ -1,3 +1,11 @@ +tcos (0.89.93+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * Switch alternative build-dep order for libxmlrpc-c3 (Closes: #765129) + * Add dh-python to build depends + + -- Jonathan Wiltshire j...@debian.org Sun, 23 Nov 2014 18:17:03 + + tcos (0.89.93) unstable; urgency=low * Bump standards version to 3.9.4, no changes needed diff -Nru tcos-0.89.93/debian/control tcos-0.89.93+nmu1/debian/control --- tcos-0.89.93/debian/control 2013-12-31 13:28:27.0 + +++ tcos-0.89.93+nmu1/debian/control 2014-11-23 18:36:13.0 + @@ -4,7 +4,8 @@ Maintainer: Mario Izquierdo (mariodebian) mariodeb...@gmail.com Build-Depends: debhelper (= 7.0.50~), python (= 2.6.6-3~), - libxmlrpc-c3-dev | libxmlrpc-core-c3-dev, + dh-python, + libxmlrpc-core-c3-dev | libxmlrpc-c3-dev, libxau-dev, libxaw7-dev, libimlib2-dev, signature.asc Description: Digital signature
Bug#770241: seahorse: fails to create new SSH key
I confirm this problem exists in seahorse 3.14.0 in Jessie. Here are the relevant Fedora and GNOME bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=1163660 https://bugzilla.gnome.org/show_bug.cgi?id=740138 And these 2 commits fix the problem for me: https://git.gnome.org/browse/seahorse/commit/?id=78c4a9600fa65df7e4628bd41a294ff4a3d1bef3 https://git.gnome.org/browse/seahorse/commit/?id=6650aadbcd7d175786c8a1b25b35f46467141cd8 FYI, this bug was a blocker for Fedora 21 and I strongly believe these fixes should find their way to Jessie. Regards, Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770741: vlc: FTBFS on hppa: borked plugin files
Package: vlc
Version: 2.2.0~rc2-1
Severity: normal
Build fails here:
# Install stuff
dh_install --fail-missing
# Check that we did not install a plugin linked with libX11 or
# libxcb in vlc-nox
BORKED=no; \
LD_LIBRARY_PATH=debian/libvlccore8/usr/lib:debian/libvlc5/usr/lib${LD_LIBRARY_PATH:+:}${LD_LIBRARY_PATH:-};
\
for file in $(find debian/vlc-nox/usr/lib/vlc -name '*.so'); do \
if ldd -r $file | egrep -q -e 'libX11\.so' -e 'libxcb\.so'; then \
BORKED=yes; \
echo $file depends on libX11 or libxcb; \
fi; \
done; \
if test $BORKED = yes; then exit 1; fi
debian/vlc-nox/usr/lib/vlc/plugins/demux/libavformat_plugin.so depends on
libX11 or libxcb
debian/vlc-nox/usr/lib/vlc/plugins/video_filter/libpostproc_plugin.so depends
on libX11 or libxcb
debian/vlc-nox/usr/lib/vlc/plugins/access/libavio_plugin.so depends on libX11
or libxcb
debian/vlc-nox/usr/lib/vlc/plugins/stream_out/libstream_out_chromaprint_plugin.so
depends on libX11 or libxcb
debian/vlc-nox/usr/lib/vlc/plugins/video_chroma/libswscale_plugin.so depends on
libX11 or libxcb
debian/vlc-nox/usr/lib/vlc/plugins/codec/libavcodec_plugin.so depends on libX11
or libxcb
debian/vlc-nox/usr/lib/vlc/plugins/codec/libhwdummy_plugin.so depends on libX11
or libxcb
make[1]: *** [override_dh_install] Error 1
Full log:
http://buildd.debian-ports.org/status/fetch.php?pkg=vlcarch=hppaver=2.2.0%7Erc2-1stamp=1416767042
-- System Information:
Debian Release: jessie/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)
Kernel: Linux 3.18.0-rc5+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676554: usbmount: no write permission on hotplugged usb devices: PLEASE CLOSE
Package: usbmount Followup-For: Bug #676554 Hi, Please close the bug report. There's nothing to do here. The problem seems specific to the original poster's configuration (and might, of course, be caused by what Edward described!). Don't keep idle bug reports around, please close. Thanks! -Hagen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770704: ITP: wcwidth -- determine printable width of a string on a terminal
* Adam Borowski kilob...@angband.pl, 2014-11-23, 16:12: Even better, it would be better to call libc's wcwidth() instead of reinventing the wheel -- as a bonus, the data would be current without need for manual intervention. Beware that wcwidth(2) is locale-dependent, which might or might not be desirable. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770016: Clarify network access for building packages in main
On Sun, 23 Nov 2014, Bill Allombert wrote: --- a/policy.sgml +++ b/policy.sgml @@ -1928,12 +1928,16 @@ zope. impossible to auto-compile that package and also makes it hard for other people to reproduce the same binary package, all required targets must be non-interactive. It also follows that any target that these targets depend on must also be non-interactive. /p + p + For packages in the main archive, no required targets + may attempt network access. + /p p The targets are as follows: taglist tagttbuild/tt (required)/tag item This is something we want for multiple reasons, but have we already fixed all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs or schemas during documentation build ? Or other network access attempts that don't fail a build (and helpfully don't modify it either)? I worry that we'd might need an intermediate step. And it is is not just for main, I don't think contrib is supposed to hit the network during *build*, either. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770064: Root cause for not updating found, network-manager issue remains
I digged into documentation of PK and found in
/usr/share/doc/packagekit/README.Debian
The following components of PackageKit aren't shipped in the packages:
- cron job: APT does this already, no need for doubling the functionality
The following components of PackageKit aren't shipped in the packages:
- cron job: APT does this already, no need for doubling the functionality
However purging update-notifier-common also removed these configuration
files:
/etc/apt/apt.conf.d/10periodic
/etc/apt/apt.conf.d/15update-stamp
So I took them from Wheezy and copied them to Jessi
GREAT!
And Updates are notified immediately as they are available and not after
next reboot!
Those 2 files should be included in pk-update-icon or PK itself:
/etc/apt/apt.conf.d/10periodic
APT::Periodic::Update-Package-Lists 1;
APT::Periodic::Download-Upgradeable-Packages 0;
APT::Periodic::AutocleanInterval 0;
/etc/apt/apt.conf.d/15update-stamp
APT::Update::Post-Invoke {touch
/var/lib/apt/periodic/update-success-stamp 2/dev/null || true;};
But as stated in the header: the network-manager issue remains as a bug!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770742: qemu-system: qemu-system-i386 -fda /dev/fd0 ... fails.
Package: qemu-system Version: 1.1.2+dfsg-6 Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Attempt to access host floppy /dev/fd0. * What exactly did you do (or not do) that was effective (or ineffective)? qemu-system-i386 -fda /dev/fd0 ... fails. * What was the outcome of this action? Host floppy /dev/fd0 can not be used by qemu-system-i386. * What outcome did you expect instead? /dev/fd0 should work as well as a floppy image file as in -fda /home/peter/MyDisketteImage. Additional information here. https://lists.debian.org/debian-user/2014/11/msg01432.html *** End of the template - remove these lines *** == A removable line. == == 2nd removable line. == -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qemu-system depends on: ii ipxe-qemu 1.0.0+git-20120202.f6840ba-3 ii libaio1 0.3.109-3 ii libasound21.0.25-4 ii libbluetooth3 4.99-2 ii libbrlapi0.5 4.4-10+deb7u1 ii libc6 2.13-38+deb7u6 ii libcurl3-gnutls 7.26.0-1+wheezy11 ii libfdt1 1.3.0-4 ii libgl1-mesa-glx [libgl1] 8.0.5-4+deb7u2 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgnutls26 2.12.20-8+deb7u2 ii libiscsi1 1.4.0-3 ii libjpeg8 8d-1+deb7u1 ii libncurses5 5.9-10 ii libpng12-01.2.49-1 ii libpulse0 2.0-6.1 ii libsasl2-22.1.25.dfsg1-6+deb7u1 ii libsdl1.2debian 1.2.15-5 ii libtinfo5 5.9-10 ii libusbredirparser00.4.3-2 ii libuuid1 2.20.1-5.3 ii libvdeplug2 2.3.2-4 ii libx11-6 2:1.5.0-1+deb7u1 ii libxen-4.14.1.4-3+deb7u3 ii libxenstore3.04.1.4-3+deb7u3 ii openbios-ppc 1.0+svn1060-1 ii openbios-sparc1.0+svn1060-1 ii openhackware 0.4.1-6 ii qemu-keymaps 1.1.2+dfsg-6a+deb7u5 ii seabios 1.7.0-1 ii vgabios 0.7a-3 ii zlib1g1:1.2.7.dfsg-13 Versions of packages qemu-system recommends: ii qemu-utils 1.1.2+dfsg-6a+deb7u5 ii vde22.3.2-4 Versions of packages qemu-system suggests: pn samba none -- no debconf information -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://carnot.yi.org/ Bcc: peter at easthope. ca -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768695: Updated NMU patch
On Sun, 2014-11-23 at 18:54 +0100, Tomasz Buchert wrote: Here is a patch with 2 modifications: 1) d/changelog: added (Closes: ...) 2) altogother = altogether No objections from me. :) Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770743: icinga2-classicui: dangling symlink causes postinst to break
Package: icinga2-classicui Version: 2.2.0-1 Severity: important Hi Alex, ln: failed to create symbolic link `/etc/apache2/conf.d/icinga2-classicui.conf': File exists dpkg: error processing icinga2-classicui (--configure): Looks like it's caused by a dangling symlink coming from the config file move. $ ll /etc/apache2/conf.d total 0 lrwxrwxrwx 1 root root 36 Nov 9 23:04 icinga2-classicui.conf - ../../icinga2/classicui/apache2.conf Haven't got much time at hand. Thanks Markus -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages icinga2 depends on: ii icinga2-bin 2.2.0-1~debmon70+3 ii icinga2-common 2.2.0-1~debmon70+3 Versions of packages icinga2 recommends: ii icinga2-doc 2.2.0-1~debmon70+3 ii monitoring-plugins-basic 2.0-1~debmon70+1 ii nagios-plugins-basic 2.0-1~debmon70+1 icinga2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770016: Clarify network access for building packages in main
On Sun, Nov 23, 2014 at 10:52:54PM +0500, Andrey Rahmatullin wrote: On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote: 2.2.1 says the packages in main must not require or recommend a package outside of main for compilation or execution (thus, the package must not declare a Pre-Depends, Depends, Recommends, Build-Depends, or Build-Depends-Indep relationship on a non- main package), In practice there is a consensus that this also means packages must not access external network servers which conforms to the spirit but not to the letter of this section. Note that there may be other requirements which are not codified, as mentioning only things that are packaged is not enough, it should say something like must not use any stuff except for packages in main. Hi Andrew, I guess that it is implicit from the defintion of contrib that follows in 2.2.2: The contrib archive area contains supplemental packages intended to work with the Debian distribution, but which require software outside of the distribution to either build or function. I've just understood both these statements mention requiring something non-free to *function*. Do we allow packages in main to require external services to function? There are far too many special case (think: whois, DNS, youtube-dl) to write something meaningful I am afraid. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770720: Known limitation
Hello, The behaviour you describe is a known limitation and is probably a duplicate of bug 686772. As the man page notes: If you have wdiff installed, colordiff will correctly colourise the added and removed text, provided that the '-n' option is given to wdiff: $ wdiff -n file1 file2 | colordiff That is considered the appropriate workaround for this situation. Dave. -- Dave Ewart da...@sungate.co.uk, http://twitter.com/DaveEwart All email from me is digitally signed, http://www.sungate.co.uk/ GPG key updated Jan 2013 see http://www.sungate.co.uk/gpg Fingerprint: CF3A 93EF 01E6 16C5 AE7A 1D27 45E1 E473 378B B197 signature.asc Description: Digital signature
Bug#770744: javamail: FTBFS under pbuilder with USENETWORK=no: Test failure
Source: javamail Version: 1.5.2-3 Severity: important From my pbuilder build log (on amd64): ... --- T E S T S --- Running MimeMultipartParseTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.207 sec Running javax.mail.internet.GetLocalAddressTest Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running javax.mail.internet.InternetAddressTest Tests run: 183, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.132 sec Running javax.mail.internet.MimeMessageTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running javax.mail.internet.MimeMultipartPropertyTest Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running javax.mail.internet.NewsAddressTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Running javax.mail.internet.MimeMultipartPreambleTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running javax.mail.internet.AddFromTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running javax.mail.internet.MimeMessageTestSuite AllowEncodedMessages Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec Running javax.mail.internet.AddAddressHeaderTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running javax.mail.internet.NonAsciiBoundaryTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running javax.mail.internet.FoldTest Tests run: 39, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec Running javax.mail.internet.search.SearchTermSerializationTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.05 sec Running javax.mail.internet.ParameterListTestSuite ParameterListTests WindowsFileNames AppleFileNames DecodeParameters ParametersNoStrict Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.065 sec Running javax.mail.internet.ContentTypeTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Running javax.mail.internet.ReferencesTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running javax.mail.internet.MimeUtilityTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec Running javax.mail.internet.ModifyMessageTest Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running javax.mail.internet.MimeBodyPartTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running javax.mail.internet.HeaderTokenizerTest Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.051 sec Running javax.mail.internet.RestrictEncodingTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running javax.mail.URLNameTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec Running com.sun.mail.imap.IMAPSaslLoginTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.085 sec Running com.sun.mail.imap.IMAPLoginFailureTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.005 sec Running com.sun.mail.imap.IMAPCloseFailureTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.261 sec Running com.sun.mail.imap.MessageCacheTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running com.sun.mail.imap.IMAPAlertTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.041 sec Running com.sun.mail.imap.IMAPConnectFailureTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running com.sun.mail.imap.protocol.IMAPProtocolTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running com.sun.mail.imap.protocol.StratoImapBugfixTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running com.sun.mail.imap.protocol.UIDSetTest Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running com.sun.mail.imap.protocol.EnvelopeTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running com.sun.mail.imap.IMAPAuthDebugTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.018 sec Running com.sun.mail.imap.IMAPIdleUntaggedResponseTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec Running com.sun.mail.imap.IMAPIdleStateTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.026 sec Running com.sun.mail.util.UUDecoderStreamTest Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running com.sun.mail.util.PropUtilTest Tests run: 19, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 sec Running com.sun.mail.util.MimeUtilTestSuite ContentTypeCleaner Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.052 sec Running com.sun.mail.util.LineInputStreamTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0,
Bug#770016: Clarify network access for building packages in main
On Sun, Nov 23, 2014 at 04:47:00PM -0200, Henrique de Moraes Holschuh wrote: On Sun, 23 Nov 2014, Bill Allombert wrote: --- a/policy.sgml +++ b/policy.sgml @@ -1928,12 +1928,16 @@ zope. impossible to auto-compile that package and also makes it hard for other people to reproduce the same binary package, all required targets must be non-interactive. It also follows that any target that these targets depend on must also be non-interactive. /p + p + For packages in the main archive, no required targets + may attempt network access. + /p p The targets are as follows: taglist tagttbuild/tt (required)/tag item This is something we want for multiple reasons, but have we already fixed all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs or schemas during documentation build ? Or other network access attempts that don't fail a build (and helpfully don't modify it either)? Lucas, can you confirm that the main archive ca be rebuild without external network access ? And it is is not just for main, I don't think contrib is supposed to hit the network during *build*, either. I have no idea abut contrib. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
On Mon, Nov 24, 2014 at 02:15:45AM +0900, Charles Plessy wrote:
Le Sun, Nov 23, 2014 at 03:08:47PM -0200, Henrique de Moraes Holschuh a écrit
:
On Mon, 24 Nov 2014, Charles Plessy wrote:
do you have examples of packages having empty fields in source package
control
files ? I have not found any. (In the sense that a field that only
contains
a substitution variable is not considered empty).
They come from empty substitutions, yes.
Then they are not empty: there is a big difference between Depends: and
Depends: ${foo}. I think that it would be very confusing if we would refer
them as empty.
Also, the bug started with a problem where empty means nothing after the
colon.
This bug is mostly to document a check in dak. Are you suggesting the check is
looking at the debian/control file and reject source packages with empty fields
?
Cheers,
--
Bill. ballo...@debian.org
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770122: Debian Bug#770122: patch as workaround/solution
Hi, I am forwarding this Debian bug [0] to alsa-devel due to a not maintained BugTracker at alsa project. Could one please have a look at it? [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770122 Thanks Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche signature.asc Description: Digital signature
Bug#770745: df_abs: Unintended breakage in rrd file names
Package: munin-plugins-core Version: 2.0.24-1 Severity: normal Hello, Upstream commit 2.0.6-1-ga4eb420 was created in the intention to append the mountpoint to non-device mounts like tmpfs in order to make them unique. However, the quoting in + /* ) disabled globbing so this clause will never be hit¹. As a result, the mountpoint is appended to *all* devices like in | _dev_vda1__boot.value 19868 | _dev_vda5__.value 165710 This field name change will also break the historic data as the rrd file name on the master changes accordingly. It might be an idea to stay that way (I consider that a bad one) but at the moment the plugin's behaviour matches neither the documention nor the one of the other df* plugins. In my opinion, this should still be fixed in jessie, else this will break users' graphs. Regards, Christoph ¹ Unless somebody naughty creates a device with literally that name. signature.asc Description: Digital signature
Bug#770016: Clarify network access for building packages in main
Bill Allombert ballo...@debian.org (2014-11-23): This is something we want for multiple reasons, but have we already fixed all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs or schemas during documentation build ? Or other network access attempts that don't fail a build (and helpfully don't modify it either)? Lucas, can you confirm that the main archive ca be rebuild without external network access ? Depends what you call “external network access”. At least the debian-installer source package pulls stuff from a mirror doing the build. (No need to tell me how wrong, ugly, blablabla that is; I'm aware.) Mraw, KiBi. signature.asc Description: Digital signature
Bug#770746: Improving the label generated by the irqstats plugin
Package: munin-plugins-core
Version: 2.0.24-1
Severity: wishlist
Tags: patch upstream
Hello,
three cosmetical issues with the labels generated by the irqstats
plugin:
1.
The concept of interrupt domains is somewhat unknown in the Intel
world. It seems to be quite common on other archs like ARM-based and
powerpc though.
Somewhat guessing from reading the Linux kernel sources, the basic
idea is the interrupt number as seen bei the interrupt controller
(hwirq) do not necessarily match the number the kernel uses
internally and is visible in the first column of /proc/interrupts.
In that case, an additional column contains that hwirq IRQ number¹.
The irqstats plugin is not aware of that and generates a label from
both that number and the actual name, like in
(...)
|CPU0
(...)
| 25: 492375413 main-interrupt-ctrl 11 eth0
| 33:949 main-interrupt-ctrl 33 serial
| 74: 15147181 main-interrupt-ctrl 46 f1072004.mdio-bus
(...)
[ /proc/interrupts ]
(...)
| i25.label 11 eth0
| i25.info Interrupt 25, for device(s): 11 eth0
| i25.type DERIVE
| i25.min 0
| i33.label 33 serial
| i33.info Interrupt 33, for device(s): 33 serial
| i33.type DERIVE
| i33.min 0
| i74.label 46 f1072004.mdio-bus
| i74.info Interrupt 74, for device(s): 46 f1072004.mdio-bus
| i74.type DERIVE
| i74.min 0
(...)
[ $(munin-run irqstats config) ]
2.
On kernels with CONFIG_GENERIC_IRQ_SHOW_LEVEL² enabled (powerpc), an
additional column containing Level or Edge is printed
|CPU0
(...)
| 19:745 MPIC 1 19 Level pata-macio
| 25: 0 MPIC 1 25 Level VIA-PMU
| 26: 0 MPIC 1 26 Level keywest i2c
(...)
[ /proc/interrupts ]
3.
In the expample above, the space in the PIC name MPIC 1³ causes
additional trouble, config suggests the labels as follows
| irqstats.i19.label 1 19 Level pata-macio
| irqstats.i25.label 1 25 Level VIA-PMU
| irqstats.i26.label 1 26 Level keywest i2c
These labels just eat space and are somewhat confusing.
The patch below catches these situations by
1. Dropping that number, unless it's different from the logical
one. In that case, it is appended to the label.
2. Stripping these strings if present.
3. Wild-guessing. The $type variable is not used by the way but the
patch creates a value in the intended idea.
It might be an idea to fix that extra space in the kernel.
Regards,
Christoph
¹ kernel-git:
commit v3.10-rc5-20-gc12d2f4
² kernel-git:
commit v2.6.38-7061-gab7798f
commit v2.6.39-rc5-148-g94b2c36
³ kernel-git:
commit v2.6.15-1517-g1beb6a7
--- a/plugins/node.d.linux/irqstats.in
+++ b/plugins/node.d.linux/irqstats.in
@@ -112,6 +112,16 @@
# For numbered interrupts the format is set
$label = pop @data;
$type = pop @data;
+ # work around MPIC \d on powerpc
+ if ($type =~ MPIC $label =~ s/^([12])\s+//) {
+ $type .= $1;;
+ }
+ # handle hwirq
+ if ($label =~ /^(\d+)\s+(.+)/) {
+ $label = $1 eq $irq ? $2 : $2 [$1];
+ }
+ # handle level/edge
+ $label =~ s/^(Level|Edge)\s+//;
} else {
# For named interrupts it's more confusing, slice and dice
# to divorce data from commentary
signature.asc
Description: Digital signature
Bug#770747: [digikam] Canon EOS70D - No thumbnail during import
Package: digikam Version: 4:4.4.0-1.1 Severity: normal --- Please enter the report below this line. --- Dear maintainer(s), Since buying a an EOS 70D I noticed that the thumbnail preview in the import window wasn't working. Gphoto2 does retrieve them with no issue when using : gphoto2 -T While investigating I noticed the following log message : digikam(21466)/digikam (core) Digikam::ImportStackedView::syncSelection: one or both of the models are null?! from: Digikam::ImportIconView(0x5ad29a0) to: Digikam::ImportThumbnailBar(0x42782d0) Which lead me to these bug reportS : https://bugs.kde.org/show_bug.cgi?id=340649 https://bugs.kde.org/show_bug.cgi?id=338407 The last one contains patches to solve the issue which are included in 4.5.0 I know Jessie is frozen, so I am wondering if it would be possible to just include the patches in the current package ? I wanted to try the patch myself, but I am not familiar with your packaging method. If you provide me with a simple procedure I can perform the test myself. Let me know Cheers --- System information. --- Architecture: amd64 Kernel: Linux 3.16.0-4-amd64 Debian Release: jessie/sid 500 unstable debian.mirrors.ovh.net 500 testing debian.mirrors.ovh.net 1 experimental debian.mirrors.ovh.net --- Package information. --- Depends (Version) | Installed ==-+-== digikam-private-libs (= 4:4.1.0-1) | 4:4.4.0-1.1 kde-runtime ( 4:4.10) | 4:4.14.2-1 libc6 (= 2.14) | libgcc1 (= 1:4.1.1) | libgphoto2-6 (= 2.5.2) | libgphoto2-port10 (= 2.5.2) | libkdcraw23 (= 4:4.12.3) | libkdecore5 (= 4:4.7.0) | libkdeui5 (= 4:4.10.0) | libkexiv2-11 (= 4:4.10.2) | libkhtml5 (= 4:4.3.4) | libkio5 (= 4:4.7.0) | libkipi11 (= 4:4.11.1) | libknotifyconfig4 (= 4:4.3.4) | libkparts4 (= 4:4.5.85) | libnepomukcore4 (= 4:4.10.0) | libopencv-core2.4 | libopencv-imgproc2.4 | libphonon4 (= 4:4.2.0) | libqt4-dbus (= 4:4.5.3) | libqt4-sql (= 4:4.5.3) | libqt4-xml (= 4:4.5.3) | libqtcore4 (= 4:4.8.0) | libqtgui4 (= 4:4.8.0) | libsolid4 (= 4:4.3.4) | libsoprano4 (= 2.1.1) | libstdc++6 (= 4.1.1) | libthreadweaver4 (= 4:4.3.4) | phonon | perl | libqt4-sql-sqlite | digikam-data (= 4:4.1.0-1) | Recommends (Version) | Installed -+-=== www-browser | kipi-plugins | 4:4.4.0-1.1 ffmpegthumbs | 4:4.14.1-1 OR mplayerthumbs | Suggests (Version) | Installed =-+-=== digikam-doc | systemsettings | 4:4.11.13-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770222: NMU uploaded to DELAYED-3
diff -Nru icecast2-2.4.0/debian/changelog icecast2-2.4.0/debian/changelog
--- icecast2-2.4.0/debian/changelog 2014-09-01 17:03:14.0 +0200
+++ icecast2-2.4.0/debian/changelog 2014-11-23 20:04:08.0 +0100
@@ -1,3 +1,11 @@
+icecast2 (2.4.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Include patchset 19313 (close file handles for external scripts).
+(Closes: #770222)
+
+ -- Simon Richter s...@debian.org Sun, 23 Nov 2014 20:02:58 +0100
+
icecast2 (2.4.0-1) unstable; urgency=medium
* Imported Upstream version 2.4.0
diff -Nru
icecast2-2.4.0/debian/patches/0001-disconnects_stdio_of_on_dis_connect_scripts_from_random_filehandles
icecast2-2.4.0/debian/patches/0001-disconnects_stdio_of_on_dis_connect_scripts_from_random_filehandles
---
icecast2-2.4.0/debian/patches/0001-disconnects_stdio_of_on_dis_connect_scripts_from_random_filehandles
1970-01-01 01:00:00.0 +0100
+++
icecast2-2.4.0/debian/patches/0001-disconnects_stdio_of_on_dis_connect_scripts_from_random_filehandles
2014-11-23 20:07:33.0 +0100
@@ -0,0 +1,80 @@
+Index: icecast2-2.4.0/src/source.c
+===
+--- icecast2-2.4.0.orig/src/source.c
icecast2-2.4.0/src/source.c
+@@ -34,6 +34,12 @@
+ #define snprintf _snprintf
+ #endif
+
++#ifndef _WIN32
++/* for __setup_empty_script_environment() */
++#include sys/stat.h
++#include fcntl.h
++#endif
++
+ #include thread/thread.h
+ #include avl/avl.h
+ #include httpp/httpp.h
+@@ -1311,6 +1317,34 @@ void source_client_callback (client_t *c
+
+
+ #ifndef _WIN32
++/* this sets up the new environment for script execution.
++ * We ignore most failtures as we can not handle them anyway.
++ */
++static inline void __setup_empty_script_environment(void) {
++int i;
++
++/* close at least the first 1024 handles */
++for (i = 0; i 1024; i++)
++close(i);
++
++/* open null device */
++i = open(/dev/null, O_RDWR);
++if (i != -1) {
++/* attach null device to stdin, stdout and stderr */
++if (i != 0)
++dup2(i, 0);
++if (i != 1)
++dup2(i, 1);
++if (i != 2)
++dup2(i, 2);
++
++/* close null device */
++if (i 2)
++close(i);
++}
++}
++#endif
++
+ static void source_run_script (char *command, char *mountpoint)
+ {
+ pid_t pid, external_pid;
+@@ -1326,10 +1360,15 @@ static void source_run_script (char *com
+ ERROR2 (Unable to fork %s (%s), command,
strerror (errno));
+ break;
+ case 0: /* child */
++if (access(command, R_OK|X_OK) != 0) {
++ERROR2 (Unable to run command %s (%s),
command, strerror(errno));
++exit(1);
++}
+ DEBUG1 (Starting command %s, command);
+-execl (command, command, mountpoint, (char *)NULL);
+-ERROR2 (Unable to run command %s (%s), command,
strerror (errno));
+-exit(0);
++__setup_empty_script_environment();
++/* consider to add action here as well */
++execl(command, command, mountpoint, (char *)NULL);
++exit(1);
+ default: /* parent */
+ break;
+ }
+@@ -1342,8 +1381,6 @@ static void source_run_script (char *com
+ break;
+ }
+ }
+-#endif
+-
+
+ static void *source_fallback_file (void *arg)
+ {
diff -Nru icecast2-2.4.0/debian/patches/series
icecast2-2.4.0/debian/patches/series
--- icecast2-2.4.0/debian/patches/series1970-01-01
01:00:00.0 +0100
+++ icecast2-2.4.0/debian/patches/series2014-11-23
19:52:21.0 +0100
@@ -0,0 +1 @@
+0001-disconnects_stdio_of_on_dis_connect_scripts_from_random_filehandles
signature.asc
Description: OpenPGP digital signature
Bug#750631: kbd still doesn't set settings (version 1.15.5-2)
main point is kbd (version 1.15.5-2) still doesn't set settings specified in
/etc/kbd/config.
settings what i refer to ...
# screen saver/DPMS settings: all VCs
# These settings are commented by default to avoid the chance of damage to
# very old monitors that don't support DPMS signalling.
# screen blanking timeout. monitor remains on, but the screen is cleared to
# range: 0-60 min (0==never) kernels I've looked at default to 10 minutes.
# (see linux/drivers/char/console.c)
BLANK_TIME=0
# blanking method (VESA DPMS mode to use after BLANK_TIME, before powerdown):
# on: the default, no DPMS signalling. near instant powerup, no power saving
# vsync: DPMS Standby mode. nearly instant recovery, uses 110/120W (17 screen)
# hsync: DPMS Suspend mode. typically 3s recovery, uses 15/120W (17 screen)
# powerdown,off: DPMS Off mode, typ. 10s recovery, uses 5/120W (17 screen)
# Those values are for my 17 Mag, but some monitors do suspend the same as
# standby. xset dpms force {off|standby|suspend|on} is useful for this, if X
# supports DPMS on your video card. Set X's DPMS screensaver with xset dpms
# or use option power_saver in XF86Config
#
# DPMS set by default to on, because hsync can cause problems on certain
# hardware, such as Armada E500 laptops
BLANK_DPMS=off
# Powerdown time. The console will go to DPMS Off mode POWERDOWN_TIME
# minutes _after_ blanking. (POWERDOWN_TIME + BLANK_TIME after the last input)
POWERDOWN_TIME=0
i made some tests and found out that setterm (when booting) gives following
error message
setterm: $TERM is not defined
i don't know should this bug be reopened or a new bug reported.
also i'm not fully sure did previous versions run /etc/init.d/kbd script fully
with setterm error message. but kbd settings was not set anyway.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770016: Clarify network access for building packages in main
On 23/11/14 at 20:03 +0100, Bill Allombert wrote: On Sun, Nov 23, 2014 at 04:47:00PM -0200, Henrique de Moraes Holschuh wrote: On Sun, 23 Nov 2014, Bill Allombert wrote: --- a/policy.sgml +++ b/policy.sgml @@ -1928,12 +1928,16 @@ zope. impossible to auto-compile that package and also makes it hard for other people to reproduce the same binary package, all required targets must be non-interactive. It also follows that any target that these targets depend on must also be non-interactive. /p + p + For packages in the main archive, no required targets + may attempt network access. + /p p The targets are as follows: taglist tagttbuild/tt (required)/tag item This is something we want for multiple reasons, but have we already fixed all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs or schemas during documentation build ? Or other network access attempts that don't fail a build (and helpfully don't modify it either)? Lucas, can you confirm that the main archive ca be rebuild without external network access ? No: that's something I used to check (by building on machines with specific firewall rules to forbid external network access), but that I haven't been testing recently. In the past, the rebuild setup was on a platform where external network access was unavailable; but now that it moved to Amazon, this is no longer a problem, and I haven't re-implemented the firewall rules. Lucas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770748: test if runtime dependencies in gemspec are present when building library
package: gem2deb version: 0.10 severity: wishlist sometimes we update gems without meeting their suggested runtime dependencies. we should check this automatically by running 'bundle install --local' during each build. if we don't want to update a dependency we should loosen the dependency by patching gemspec. when running a bundle install --local for diaspora (see https://wiki.debian.org/Diaspora for steps to install diaspora), I have noticed many libraries does not have their required dependencies. it would be good to catch this during build time automatically. signature.asc Description: OpenPGP digital signature
Bug#770032: installer: Guided Partitioning Provides Insufficient Space
I just re-tested, they are not chosen by default. This means I think the situation should be downgraded to an enhancement request either for: partman-auto to ask if a desktop environment was required (and then size the / partition appropriately rather than as a fixed % of total) and / or tasksel to show a size estimate so it would be apparent that the desired desktop environment won't work with the partitioning scheme prior to spending the time on download and install and out of space failure. On Sun, Nov 23, 2014 at 10:19 AM, Cyril Brulebois k...@debian.org wrote: Scot S isitas...@gmail.com (2014-11-18): Package: installer Severity: important Tags: d-i Dear Maintainer, * What led up to the situation? Installation of a new system on an 8.6GB virtual harddrive using either of the listed NETINST cds Jessie Official Snapshot i386 NETINST Binary-1 20141117-04:37 Jessie Official Snapshot amd64 NETINST Binary-1 20141117-06:40 Select any install method and then use Guided Partitioning with separate /home (with or without encryption). Default setting is ~2gb / and remainder for /home. This is insufficient space for install with any of the graphical environments so during the Install Software step, a red error box comes up that gives a generic Step Failed message. * What exactly did you do (or not do) that was effective (or ineffective)? First step was to try to resize the LVM w/Encryption which failed. Logs showed out of space errors, so reinstalled without separate /home. * What was the outcome of this action? Fully functional without separate /home partition, default install with Cinnamon (not Gnome) appears to be just over 4gb. * What outcome did you expect instead? Information about the size of the packages selected, so a possible install could be completed with the partitioning chosen. or A note in the Guided Partitioning regarding space requirements (since non-GUI should fit in the space allocated). Possibly with a separate Guided for GUI option? Best is one or both and a clear error message when the install fails at the install software step. Are you saying desktop environments were listed in tasksel with such a small / partition? My limited testing seems to suggest desktops aren't proposed in such a case. Mraw, KiBi.
Bug#769483: /usr/sbin/service restarts daemons in the current session cgroups when not running systemd
On 23/11/2014 19:03, Petter Reinholdtsen wrote: You can perhaps provide details on how this work in Wheezy, to allow us to understand what changed? Sure: in Wheezy this doesn't happen at all because there is no logind running without systemd (and by extension systemd-shim and cgmanager), so under normal circumstances cgroups are not involved. In Jessie this doesn't happen if either sysvinit or upstart are PID1 until libpam-systemd is pulled in through a dependency chain (almost every desktop task, plus some daemons which depend on policykit-1 like libvirtd). Whenever libpam-systemd is installed, logind becomes active (through systemd-shim and cgmanager) and every session which goes through pam_systemd.so gets its own set of cgroups. At this point, things start to go wrong when using either invoke-rc.d or service [1]: every time a daemon is started (or restarted) through a logind-enabled session either directly or as a consequence of a dpkg action (e.g. through invoke-rc.d in the configure stage), it will inherit the session cgroups instead of being placed into the root cgroups. The only exception is with upstart as PID1: daemons with an upstart job will be forked directly by PID1, so they'll end up in the root cgroup. Daemons without a job will fall back to the initscript and thus exhibit the same behavior (as a reference, even Ubuntu 14.04 and later got this interaction between initscripts and systemd-shim/logind wrong). As far as I know, sysvinit do not have any relationship with cgroups at all, and thus do not quite sure understand why it now is a bug. Truth be told, I never realized something was wrong until I tried to figure out why some logind session were still lingering in the closing state. At first, I thought it was a regression for #756076, then I realized that I restarted some daemons and they were running inside the session cgroups, thus keeping the session around in closing state even though I had logged out and logged back in. Can you explain why you believe sysvinit should do anything about cgroups at all? Because the current implementation of service and invoke-rc.d breaks logind session semantics: if a daemon ends up in a logind session, the session will linger as long as the daemon keeps running. For remote sessions, this *usually* isn't a big deal (at least, not that I know of, I still don't know exactly what logind is supposed to do). For local sessions (ttys and X11), though, this means that device ACLs set by logind will not be cleared until the session is properly closed - that is, until the misplaced daemons die (or are moved out of the way by root using cgm movepidabs). I hope some of the more active sysvinit maintainers can look at this, as I really lack the time to figure out the cgroups details. I'm afraid it will require a bit of cooperation from cgmanager maintainers as well. The not-so-simple (but almost correct) solution would be asking cgmanager to move service/invoke-rc.d into the root cgroups right before calling the init script, but unfortunately the dbus call to do that is asynchronous and would cause a race between cgmanager moving the caller into the right cgroups and the caller forking to run the initscript. Also, I honestly don't know how to handle things if/when cgmanager is being updated and thus it's not guaranteed to be restarted before other daemons in the same dpkg run. Again, the only reason I filed this issue is because logind uses the cgroup lifecycle to manage device ACLs, otherwise this would be a minor misbehavior not even worth of being reported, let alone fixed. [1]: I'm deliberately leaving the case of root running an initscript directly since the current draft of the init policy considers that action as deprecated, but most importantly because it cannot be fixed without rewriting the entire corpus of initscripts in Debian. Regards, -- Matteo Panella signature.asc Description: OpenPGP digital signature
Bug#770749: nethack: Revive the nethack-qt package with Qt 4
Source: nethack Severity: wishlist Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** I have a Qt 4 interface for NetHack at https://github.com/chasonr/nethack-3.4.3-interfaces and package data to build a nethack-qt package based on Qt 4. This Qt 4 interface is derived from my Internationalized NetHack project (http://sourceforge.net/projects/nethack-i18n/), which, in turn, derives its Qt 4 interface at some length from the original Qt 3 interface. The look and feel is mostly the same. Some improvements over the Qt 3 interface are: * Panes are resizable * Full support for IBMgraphics, and walls and corridors are drawn with graphical primitives for a continuous appearance no matter what the font says * Lots of irritating glitches fixed * Menus support proportional fonts correctly That @%# bug where the player name reverts to the Unix user name is still at large, and the workaround is the same: specify your name in ..nethackrc. The change consists only of new files in win/Qt4, build rules in sys/unix/Makefile.src and edits to the debian/ directory, mostly carrying forward the files that used to support the Qt 3 interface. -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766093:
this should be fixed in -3. (Currently uploading, should hit mirrors in a couple of hours.) Yes, it's fixed. Thank you!
Bug#766185: support of different Freeciv clients
On 23.11.2014 14:40, Jacob Nevins wrote: This sounds like a good plan to me. Markus Koschany writes: 1. The virtual package freeciv should be dropped and be replaced with a metapackage. [...] 2. The metapackage freeciv should always depend on the recommended and most sophisticated Freeciv client which is currently freeciv-client-gtk2 thus »apt install freeciv« will avoid any confusion among users and will always ensure the best gaming experience. If we ever do change our recommended client, presumably the experience for existing users upgrading with the 'freeciv' metapackage installed is that they keep their existing client, but the new one (which might be quite different from what they're used to) will be installed alongside (so they see two menu items, etc)? This seems like a reasonable compromise. Yeah, there would be two menu items then but of course I could change the freeciv wrapper script to point to the new default client and rename the desktop/menu entry to a generic Freeciv menu entry which would always launch the default client. I'm also going to assume that the GTK2 client will be superseded by GTK3 sometime, so there shouldn't be too many surprises for users. freeciv-client-xaw3d (big question mark, I'm not sure if it is worth to support xaw anymore since it lacks many features. It seems there are still some users who use this client. So one may argue that we should keep it as long as it is maintainable. I don't know about the Debian version, but whenever I run it upstream it is often completely unusable (e.g., http://gna.org/bugs/?22985, http://gna.org/bugs/?21609), and no effort is going into it currently. If I'm reading popcon graphs right, there's support for ~25-40 active popcon-using xaw3d users, as compared to ~150-200 active gtk users and ~50 active sdl users? https://qa.debian.org/popcon.php?package=freeciv It might be time to drop it from Debian. Yup, completely unusable doesn't sound very encouraging. Obviously Freeciv has to go through NEW for this change and it should be implemented for Freeciv 2.5. (Ah, that's another reason my last-minute plan for Jessie was doomed that I should have thought of.) Never forget the FTP team. :) Markus signature.asc Description: OpenPGP digital signature
Bug#767803: Bug #767803: gdm3: After update Gdm3 displays Oh No! Something has gone wrong
Did the problem start when nvidia-libopencl1 and nvidia-opencl-icd were upgraded (check /var/log/apt/history.log)? If so, this is probably the same bug as #769191 (see there for discussion of possible fixes): nvidia-opencl-icd just gained a dependency on libcuda1, which pulls in several other nvidia packages, including libgl1-nvidia-glx and glx-alternative-nvidia. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770750: e4defrag: Please clarify usage and concurrent access
Package: e2fsprogs Version: 1.42.12-1 Severity: wishlist Hello, the e4defrag manpages does not mention the outcome if other applications access a file (read and/or write) while e4defrag is processing it; including the case where that application opened the file beforehand. Probably one of these three: - Not defined. Expect data corruption, don't do this. - e4defrag/kernel assert data integrity, the application might be stalled during critical operations. - e4defrag/kernel assert data integrity, the e4defrag might be stalled during critical operations. From some tests by running e4defrag on the containers of a running PostgreSQL database¹ I guess it's option three. But I'd really like to hear an official word about this, and read it in the manpage. In the case it's really option one, please enforce some extra checks like exclusive locking and/or checking for open file handles. Thanks in advance, Christoph ¹ No worries, it was about to be purged anyway. signature.asc Description: Digital signature
Bug#770751: adt-run fail with ValueError: Invalid version string '10.1.1-1]'
package: autopkgtest
version: 3.8
severity: grave
pravi@savannah:~/forge/debian/git/pkg-ruby-extras/ruby-jwt $ adt-run -B
.// --- null
adt-run [01:17:28]: version 3.8
adt-run [01:17:28]: testbed dpkg architecture: amd64
adt-run [01:17:28]: unbuilt-tree .//
adt-run [01:17:28]: testing package ruby-jwt version 1.0.0-1
adt-run [01:17:28]: build not needed
adt-run [01:17:28]: test command1: preparing
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
adt-run [01:17:30]: ERROR: unexpected error:
Traceback (most recent call last):
File /usr/bin/adt-run, line 1742, in main
process_actions()
File /usr/bin/adt-run, line 1720, in process_actions
run_tests(tests, tests_tree)
File /usr/bin/adt-run, line 1205, in run_tests
testbed.run_test(tree, t)
File /usr/bin/adt-run, line 905, in run_test
self.prepare(test.depends, 'needs-recommends' in test.restrictions)
File /usr/bin/adt-run, line 468, in prepare
self.install_deps(deps_new, recommends)
File /usr/bin/adt-run, line 462, in install_deps
self.satisfy_dependencies_string(', '.join(deps_new),
'install-deps', recommends)
File /usr/bin/adt-run, line 888, in satisfy_dependencies_string
self.install_tmp(deps, recommends)
File /usr/bin/adt-run, line 725, in install_tmp
if not check_constraint(pkg, ver):
File /usr/bin/adt-run, line 698, in check_constraint
comp = debian_support.version_compare(ver, constraint[1])
File /usr/lib/python3/dist-packages/debian/debian_support.py, line
314, in version_compare
va = Version(a)
File /usr/lib/python3/dist-packages/debian/debian_support.py, line
213, in __init__
super(AptPkgVersion, self).__init__(version)
File /usr/lib/python3/dist-packages/debian/debian_support.py, line
111, in __init__
self.full_version = version
File /usr/lib/python3/dist-packages/debian/debian_support.py, line
137, in __setattr__
self._set_full_version(str(value))
File /usr/lib/python3/dist-packages/debian/debian_support.py, line
116, in _set_full_version
raise ValueError(Invalid version string %r % version)
ValueError: Invalid version string '10.1.1-1]'
signature.asc
Description: OpenPGP digital signature
Bug#769204: unblock: d3/3.4.13-2
Hi Julien, hi László, On 2014-11-14 12:03, Julien Cristau wrote: On Wed, Nov 12, 2014 at 07:15:57 +0100, Laszlo Boszormenyi (GCS) wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock D3, which fixes RC bug #768719 [1], missing build dependency in Jessie. I just removed it as it's needed for self-test only and was not working anyway. The debdiff is against the Sid version. It couldn't migrate since 23 days due to too tight dependency in python-xstatic-d3 . Thomas eased that since then even if it needs an unblock as well. Debdiffs attached. I don't think this is suitable, sorry. My preferred solution right now is to remove d3/3.4.11-1 flower/0.7.0+dfsg-1 python-mne/0.8.4+dfsg-1 python-mpld3/0.3git+20140910dfsg-1 python-xstatic-d3/3.4.11-1 rickshaw/1.5.0.dfsg-1 ruby-sidekiq/3.2.6~dfsg-1 ntopng/1.2.1+dfsg1-1.1 python-xstatic-rickshaw/1.5.0.2-2. As both co-maintainer of python-mpld3 and user of both rickshaw and D3, I'm not very happy about this solution. As I understand, the main problem is, that D3 is a newer upstream, which was not in testing in time, right? How about downgrading D3 to 1:3.4.11-2 with just the RC bug fixed? Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770752: upgrade-reports: wheezy-jessie upgrade: systemd emerg mode because of unpurged package
Package: upgrade-reports Severity: normal I upgraded wheezy-jessie with apt-get -s dist-upgrade. The apt-get failed and I needed several rounds of this to complete the upgrade: # dpkg --configure -a # apt-get install -f # apt-get autoremove But that's just background info. This upgrade also installed systemd. After checking with ... # apt-get update # apt-get dist-upgrade ... to make sure there were no unfinished things, I rebooted. The system came up, but systemd came up in emergency mode. This wasn't a welcome development. I had been avoiding getting embroiled in the public arguments about the merits of systemd and was basically neutral about it. I got the feeling though that my neutrality was about to change. I authenticated as root (with some difficulty; systemd appeared still to be checking local filesystems in parallel, and these processes were writing to the console) and tried out the diagnostic commands systemd suggested (for examining its journal). The result was quite unexpected. The journal contained a summary of systemd's attempts to start various subsystems. Most of the problems in the log related to hald. A minute's web research showed that since this is now obsolete, the fix is to uninstall it. I uninstalled it and rebooted. The second time, I was returned to emergency mode; two services had failed: console-kit-log-system-start.service ebtables.service The ebtables package was uninstalled (in state rc according to dpkg -l). I don't remember when I uninstalled it. Perhaps it was uninstalled by one of the invocations of apt-get autoremove above. Purging the ebtables package fixed one of the two problems. Unsettlingly though this made the other (apparently entirely unrelated) service flip from broken to working, so all was suddenly well. For a first experience with systemd, I think this went reasonably well, for me. But for a non-power-user to update from SYSV-style init to systemd seems a stretch, at least if my experience is typical. Anyway, once I'd booted again and logged in, everything seems to be working. According to etckeeper, the version of ebtables I purged was 2.0.9.2-2. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770745: [Packaging] Bug#770745: df_abs: Unintended breakage in rrd file names
control: tags -1 + upstream Hi Christoph, thanks for your bug reports, I've forwarded them upstream on IRC :) [21:05] h01ger | TheSnide: deb#770746 might be low-hanging [21:05] - zwiebelbot- | mumbles bug title and url... [21:05] h01ger | TheSnide: deb#770745 is [21:05] - zwiebelbot- | mumbles bug title and url... [21:06] h01ger | TheSnide: how is 2.0.25 coming along? I agree both fixes are desirable for jessie. signature.asc Description: This is a digitally signed message part.
Bug#770753: espeakup: spelling says capital
Package: espeakup Version: 1:0.71-17 Severity: important 1:0.71-17 made espeakup use say-as interpret-as=tts:char to spell characters. Unfortunately, that will say capital letters as capital-foo, instead of just raising the tone, making it tedious to hear when typing capital text. Using interpret-as=characters instead fixes exactly this. Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages espeakup depends on: ii espeak 1.48.04+dfsg-1 ii libc6 2.19-13 ii libespeak1 1.48.04+dfsg-1 espeakup recommends no packages. espeakup suggests no packages. -- Configuration Files: /etc/default/espeakup changed [not included] -- no debconf information -- Samuel I am the ILOVEGNU signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768422: release.debian.org: filterdiff support for debdiffs
On Fri, 2014-11-07 at 10:42 +, Adam D. Barratt wrote: It would be really helpful, particularly for d, if the debdiff library supported a configurable (set of?) filterdiff expression. From #d-r this evening, so we don't forget: 20:03 adsb so fwiw my original plan (which I think I failed to write down anywhere) was to add the ability to take options in the debdiff class and have exclusions pass -x to debdiff, rather than an explicit filterdiff. and for d to then pass a default set of excludes, which you could add to / override (including to an empty set) on the command line. but I've also been failing to do that 20:05 nthykier adsb: Seems reasonable, except I guess d should do it based on a personal config file rather than options 20:05 adsb nthykier: maybe, that's more to implement though :) 20:05 nthykier Based on the assumption that we will not agree on an universal default -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770016: Clarify network access for building packages in main
On Sun, Nov 23, 2014 at 08:15:33PM +0100, Lucas Nussbaum wrote: On 23/11/14 at 20:03 +0100, Bill Allombert wrote: On Sun, Nov 23, 2014 at 04:47:00PM -0200, Henrique de Moraes Holschuh wrote: On Sun, 23 Nov 2014, Bill Allombert wrote: --- a/policy.sgml +++ b/policy.sgml @@ -1928,12 +1928,16 @@ zope. impossible to auto-compile that package and also makes it hard for other people to reproduce the same binary package, all required targets must be non-interactive. It also follows that any target that these targets depend on must also be non-interactive. /p + p + For packages in the main archive, no required targets + may attempt network access. + /p p The targets are as follows: taglist tagttbuild/tt (required)/tag item This is something we want for multiple reasons, but have we already fixed all instances of, e.g., validating sgml/xml parsers trying to fetch DTDs or schemas during documentation build ? Or other network access attempts that don't fail a build (and helpfully don't modify it either)? Lucas, can you confirm that the main archive ca be rebuild without external network access ? No: that's something I used to check (by building on machines with specific firewall rules to forbid external network access), but that I haven't been testing recently. Was there a lot of failure ? What severity did you use for the bug report ? Are you in favor of the patch above ? I think it reflect the general view and practice. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770754: thunar: lack of accents in french thunar translations
Package: thunar Version: 1.6.3-2 Severity: minor Dear Maintainer, It seems to lack accents in few french translations. Please see my patch attached with some corrections. I also try to correct a miss of shortcut with the original item. Thanks, Fabien Harrang -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages thunar depends on: ii desktop-file-utils 0.22-1 ii exo-utils 0.10.2-4 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libdbus-1-3 1.8.10-1 ii libdbus-glib-1-20.102-1 ii libexo-1-0 0.10.2-4 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.42.0-2 ii libgtk2.0-0 2.24.25-1 ii libgudev-1.0-0 215-5+b1 ii libice6 2:1.0.9-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.8-2 ii libsm6 2:1.2.2-1 ii libthunarx-2-0 1.6.3-2 ii libxfce4ui-1-0 4.10.0-6 ii libxfce4util6 4.10.1-2 ii libxfconf-0-2 4.10.0-3 ii shared-mime-info1.3-1 ii thunar-data 1.6.3-2 Versions of packages thunar recommends: ii dbus-x11 1.8.10-1 ii gvfs 1.22.1-1 ii libfontconfig1 2.11.0-6.1 ii libfreetype6 2.5.2-2 ii libpangocairo-1.0-0 1.36.8-2 ii libpangoft2-1.0-01.36.8-2 ii thunar-volman0.8.0-4 ii tumbler 0.1.30-1+b1 pn xdg-user-dirsnone ii xfce4-panel 4.10.1-1 Versions of packages thunar suggests: ii thunar-archive-plugin 0.3.1-3 ii thunar-media-tags-plugin 0.2.1-1 -- no debconf information --- po/fr.po.orig 2013-05-05 18:37:23.0 +0200 +++ po/fr.po 2014-11-23 20:15:40.126558096 +0100 @@ -2180,11 +2180,11 @@ #: ../thunar/thunar-shortcuts-model.c:885 msgid DEVICES -msgstr PERIPHERIQUES +msgstr PÉRIPHÉRIQUES #: ../thunar/thunar-shortcuts-model.c:927 msgid NETWORK -msgstr RESEAU +msgstr RÉSEAU #: ../thunar/thunar-shortcuts-model.c:933 msgid Browse Network @@ -2224,7 +2224,7 @@ #. append the Eject menu action #: ../thunar/thunar-shortcuts-view.c:1136 ../thunar/thunar-tree-view.c:1159 msgid _Eject -msgstr _Ejecter +msgstr Éj_ecter #. append the Disconnect item #: ../thunar/thunar-shortcuts-view.c:1153 @@ -2235,7 +2235,7 @@ #. append the Mount Volume menu action #: ../thunar/thunar-shortcuts-view.c:1174 ../thunar/thunar-tree-view.c:1168 msgid Disconn_ect -msgstr Déconnecter +msgstr Déconn_ecter #: ../thunar/thunar-shortcuts-view.c:1253 msgid _Remove Shortcut
Bug#756721: too much vertical space
The new package tracker uses a font that is smaller than in the PTS, while at the same time taking more vertical space than the PTS. +1 from me. I also dislike that. The tracker shows less information than in the old PTS because of the bigger vertical space. -- regards Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769191: Bug#769072: #769191, #770588: nvidia-opencl-icd breaking non-nvidia systems
a better fix might be for whatever sets nvidia as default graphics provider to only do so if the hardware is present, but I don't know whether that's practical. The package already has a check in http://sources.debian.net/src/nvidia-graphics-drivers/340.46-5/debian/libgl1-nvidia-glx.preinst.in that offers to abort an install/upgrade on hardware that is too old for the new driver version, but it doesn't warn for hardware that isn't Nvidia at all (deliberately, according to the changelog; the warning currently suggests using nvidia-legacy-304xx-driver instead, which is the right solution for old Nvidia hardware but probably as bad as plain nvidia-driver on non-Nvidia hardware). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770755: systemd: debug shell unusable due to continuous systemd output
Package: systemd Version: 215-5+b1 Severity: normal Hi, I enabled systemd debug-shell service on several machines. However, each time I needed it (for example to fix a problem with mounted points, see #760848 for an specific example), the timeout output of systemd before going to emergency mode forbid me to use the shell. systemd output should not go continously on a used terminal (such as the one used by debug-shell in particular). Regards, Vincent -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armel mipsel Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-58 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1 ii libblkid1 2.25.2-2 ii libc6 2.19-13 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-3 ii libgcrypt20 1.6.2-4 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b1 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-5+b1 ii sysv-rc 2.88dsf-58 ii udev215-5+b1 ii util-linux 2.25.1-5 Versions of packages systemd recommends: ii dbus1.8.10-1 ii libpam-systemd 215-5+b1 Versions of packages systemd suggests: pn systemd-ui none -- Configuration Files: /etc/systemd/journald.conf changed: [Journal] TTYPath=/dev/tty10 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768905: FTBFS: fails test CHECK INVALID KEY TYPE
clone 768905 -1 retitle -1 keyutils: Work around FTBFS on non-release kernels severity -1 important thanks On 2014-11-23 15:44, Adam Borowski wrote: On Sun, Nov 23, 2014 at 12:55:22PM +0100, Christian Kastner wrote: The syscall is returning ENOKEY where until 3.16 it was returning EPERM. I am now quite certain that the issue is being caused by this kernel commit in 3.17: Commit: a4e3b8d79a5c6d40f4a9703abf7fe3abcc6c3b8d KEYS: special dot prefixed keyring name bug fix Except, it fails with earlier kernels too: I tested 3.8 on armhf and 3.11 on amd64 (the latter with config identical to Debian's in all uninteresting to me areas). I tested this with kernels 3.8 - 3.14 and can verify this issue existed up to 3.12. It's a separate (although similar) issue as above: a wrong errno is returned. It was fixed by the following commit (which entered kernel 3.13): Commit: 61ea0c0ba904a55f55317d850c1072ff7835ac92 KEYS: Skip key state checks when checking for possession Since this issue affects only non-release Debian kernels, I'll just be adding a patch that works around this issue in the affected kernels, and add a README documenting this issue. Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769204: unblock: d3/3.4.13-2
On Sun, Nov 23, 2014 at 8:54 PM, W. Martin Borgert deba...@debian.org wrote: On 2014-11-14 12:03, Julien Cristau wrote: On Wed, Nov 12, 2014 at 07:15:57 +0100, Laszlo Boszormenyi (GCS) wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I don't think this is suitable, sorry. My preferred solution right now is to remove d3/3.4.11-1 flower/0.7.0+dfsg-1 python-mne/0.8.4+dfsg-1 python-mpld3/0.3git+20140910dfsg-1 python-xstatic-d3/3.4.11-1 rickshaw/1.5.0.dfsg-1 ruby-sidekiq/3.2.6~dfsg-1 ntopng/1.2.1+dfsg1-1.1 python-xstatic-rickshaw/1.5.0.2-2. As both co-maintainer of python-mpld3 and user of both rickshaw and D3, I'm not very happy about this solution. As I understand, the main problem is, that D3 is a newer upstream, which was not in testing in time, right? How about downgrading D3 to 1:3.4.11-2 with just the RC bug fixed? Sure, it could be done via t-p-u if Julien allows it. Still, please consider that 3.4.13 is in the archives for over a month now without any bugs filed against it. Actually version 3.4.x is in bugfix mode only and fixes several upstream bugs[1]. -- cut -- 3.4.13 Fix invalid transform when switching between linear and log axes. Fix number formatting of groups with very small or very large numbers in exponent notation. Fix number formatting with explicit minus (-) sign. Fix loss of precision during linear interpolation. Fix crash in d3.layout.stack when passed an empty array. Fix for falsey rows when parsing DSV. Fix for leaked d3 global in Node. Fix conversion from HCL to Lab color. Fix for d3.mean, d3.median and d3.scale.quantile to coerce values to numbers. Improve performance of d3.map and d3.set by using Object.create(null). Improve performance of selection.data. 3.4.12 Fix uncaught InvalidStateError thrown when using d3.xhr with non-text response types. Fix parsing of positive time zone offsets with a non-zero number of minutes. Update to JSDOM version 1.0.0. Fix selection.size on enter selections. Workaround a Chrome touch bug affecting d3.behavior.zoom. -- cut -- Kind regards, Laszlo/GCS [1] https://github.com/mbostock/d3/releases -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770757: nethack: Revive the nethack-qt package with Qt 4
Source: nethack Severity: wishlist Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** request.txt -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770758: libwxgtk2.8-0: wxSound does not work
Package: libwxgtk2.8-0 Version: 2.8.12.1+dfsg2-2 Severity: normal Dear Maintainer, I have been having an issue with official builds of wxWidgets on Debian-based systems for a couple years now. The wxSound object does not work. It does not produce any audio output. I don't see any error output when building an app using the module nor when it is used at runtime. The bug only seems to affect Debian-based systems. Namely, I have tested it on Debian, Ubuntu, and Linux Mint, on none of which it works. I have also tested builds on non-Debian systems; Fedora, FreeBSD, Windows XP, and Windows 7. On all of these systems the wxSound module works fine. To further investigate the problem I custom built wxWidgets on my Debian system using source from http://www.wxwidgets.org/. Running binaries produced with the Debian build and custom build successfully executed the wxSound module when linked to the custom libs. For these reasons I believe that there is an error in the official Debian build of wxWidgets's shared libs: - Only Debian-based systems are affected. - A custom build of wxWidgets (wxGtk) produces a working wxSound module. For reference, the build command/options that I used follow: ../configure --enable-shared --enable-unicode --disable-gtktest \ --disable-sdltest --with-gtk --with-sdl --with-opengl \ --with-gnomeprint --with-gnomevfs I am unsure if current builds of the newer libwxgtk3.0-0 share this same bug. The project for which I am using wxWidgets and wxSound is located here for reference as well: https://sourceforge.net/projects/myabcs -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libwxgtk2.8-0 depends on: ii libatk1.0-0 2.14.0-1 ii libc6 2.19-13 ii libexpat1 2.1.0-6+b3 ii libfontconfig12.11.0-6.2 ii libfreetype6 2.5.2-2 ii libgcc1 1:4.9.2-2 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libgl1-mesa-glx [libgl1] 10.3.2-1 ii libglib2.0-0 2.42.1-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libgtk2.0-0 2.24.25-1 ii libjpeg8 8d1-2 ii libpango-1.0-01.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpng12-01.2.50-2+b1 ii libsm62:1.2.2-1 ii libstdc++64.9.2-2 ii libtiff5 4.0.3-10+b3 ii libwxbase2.8-02.8.12.1+dfsg2-2 ii libxinerama1 2:1.1.3-1+b1 ii libxxf86vm1 1:1.1.3-1+b1 ii multiarch-support 2.19-13 ii zlib1g1:1.2.8.dfsg-2 libwxgtk2.8-0 recommends no packages. libwxgtk2.8-0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770759: python3-mpld3: does not show graph because of missing link to D3.js
Package: python3-mpld3 Version: 0.3git+20140910dfsg-1 Severity: grave Justification: renders package unusable The link /usr/lib/python3/dist-packages/mpld3/js/d3.v3.min.js - /usr/share/javascript/d3/d3.min.js is missing, so graphs are not shown, which is the purpose of the package. The same applies to the Python 2 package. Note: This will be fixed in git in some minutes. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-mpld3 depends on: ii libjs-d33.4.11-1 ii python 2.7.8-2 ii python-mplexporter 0.0.1+20140921-1 python-mpld3 recommends no packages. python-mpld3 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770760: caja: filename font color does not always get picked up from theme
Package: caja Version: 1.8.2-1 Severity: minor Dear Maintainer, The font color of filenames in the directory listing of caja sometimes do not get applied as they should according to the theme. A few cases in which I have seen this happening: * When the BlackMATE theme has been applied. The filename font color is still black on the dark background, making the filenames harder to read (see the attached screenshot). * When switching from BlackMATE to a lighter theme. The filenames become light and thus barely readable on the white background. This is resolved with a restart of caja. Strangely, this only happens in the 'icons' and 'compact' display type, not in the 'list' display type. Switching from the 'icons' to the 'list' and back to the 'icons' type makes the filenames the right color (light gray or white). The 'High Contrast Inverse' theme doesn't have this problem. (I know this could be a mate-themes bug but as the right color does get applied under certain conditions, it seems like caja is messing up somewhere). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages caja depends on: ii caja-common 1.8.2-1 ii desktop-file-utils0.22-1 ii gvfs 1.22.1-1 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libcaja-extension11.8.2-1 ii libexempi32.2.1-2 ii libexif12 0.6.21-2 ii libfontconfig12.11.0-6.1 ii libfreetype6 2.5.2-2 ii libgail18 2.24.25-1 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libglib2.0-0 2.42.0-2 ii libglib2.0-data 2.42.0-2 ii libgtk2.0-0 2.24.25-1 ii libice6 2:1.0.9-1 ii libmate-desktop-2-17 1.8.1+dfsg1-2 ii libpango-1.0-01.36.8-2 ii libpangocairo-1.0-0 1.36.8-2 ii libpangoft2-1.0-0 1.36.8-2 ii libselinux1 2.3-2 ii libsm62:1.2.2-1 ii libstartup-notification0 0.12-4 ii libunique-1.0-0 1.1.6-5 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxml2 2.9.1+dfsg1-4 ii libxrender1 1:0.9.8-1+b1 ii mate-desktop 1.8.1+dfsg1-2 ii shared-mime-info 1.3-1 caja recommends no packages. Versions of packages caja suggests: ii engrampa 1.8.1+dfsg1-1 pn gstreamer0.10-tools none ii meld 3.12.1-1
Bug#768927: opensc: OpenCT missing. Was removed in 760258
Control: severity -1 important * Cornelius Kölbel (co...@cornelinux.de) wrote: Hi Eric, [snip] Yes, but to my up-to-now-knowledge using pcscd and opensc is not enough. As soon as we installed openct things worked fine. I will ask the opensc guys. Did you have any luck making it work with pcscd? -- Eric Dorland e...@kuroneko.ca 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
Bug#769582: works fine here - severity adjusted
Control: severity -1 important thanks Hi Patrick et al., I had a look into this issue at the BSP in Munich. However, amarok works fine here AFAICS - I run a long term test ATM. I fear that it is not justified to use severity 'grave', as amarok is definitely not 'unusable or mostly so' here. It's of course annoying if it fails on some systems and this should be fixed, but it should not delay the release or lead to removal of amarok from jessie. Best regards, Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762745: libvncserver -- will upload the NMU.
Hi Tobi, On Sun, Nov 23, 2014 at 04:57:28PM +0100, Tobias Frost wrote: After testing and looks that it is working, I will upload it to DELAYED/5. Please let me know if I should cancel it or delay it further. Please note that there is ongoing work by the maintainer asking for a pre-approval on the release team, see #770501. There is a probme as it seems tehere is an API/ABI break. So please double check with Luca (cc'ed him). Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770761: intel-microcode: should Depends: on the first working linux-image version (e.g. backports)
Package: intel-microcode Version: 3.20140913.1~bpo70+1 Severity: important User: cont...@itopie.ch Usertags: debian-packaging Hi there, while installing a new Debian wheezy following our internal instructions[1] that worked flawlessly in the past, I was quite surprised by the error message about not supported kernel appeared during the intel-microcode installation. [1] https://docs.itopie.ch/installation/debian Anyway, I rebooted and since there was still no intel-microcode loaded I checked the debian/changelog: --8---cut here---start-8--- intel-microcode (3.20140913.1~bpo70+1) wheezy-backports; urgency=medium * Rebuild for wheezy-backports (no changes) * THIS PACKAGE REQUIRES LINUX KERNEL 3.10 OR LATER, YOU MUST USE A BACKPORTED OR CUSTOM KERNEL. If you use the regular Debian stable (wheezy) kernel (Linux 3.2), please use the stable (wheezy) intel-microcode package. -- Henrique de Moraes Holschuh h...@debian.org Thu, 30 Oct 2014 16:19:08 -0200 --8---cut here---end---8--- I am sorry, but I see two important errors here: 1) the default apt-listchanges/which debconf value is news, which means that on upgrades the above message is not shown, instead it should have been added to debian/NEWS. 2) AFAIK, if a backport package needs a feature of another backport package to work on a stable installation, than the second package should be a Depends:. Thx, bye, Gismo / Luca -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages intel-microcode depends on: ii iucode-tool 1.1-1~bpo70+1 Versions of packages intel-microcode recommends: ii initramfs-tools 0.109.1 intel-microcode suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#666726: debian-policy: Clarify if empty control fields are ollowed or not
On Sun, 23 Nov 2014, Bill Allombert wrote:
On Mon, Nov 24, 2014 at 02:15:45AM +0900, Charles Plessy wrote:
Le Sun, Nov 23, 2014 at 03:08:47PM -0200, Henrique de Moraes Holschuh a
écrit :
On Mon, 24 Nov 2014, Charles Plessy wrote:
do you have examples of packages having empty fields in source package
control
files ? I have not found any. (In the sense that a field that only
contains
a substitution variable is not considered empty).
They come from empty substitutions, yes.
Then they are not empty: there is a big difference between Depends: and
Depends: ${foo}. I think that it would be very confusing if we would
refer
them as empty.
Also, the bug started with a problem where empty means nothing after the
colon.
This bug is mostly to document a check in dak. Are you suggesting the check is
looking at the debian/control file and reject source packages with empty
fields
?
That would be broken beyond belief! debian/control might not even *exist*
after source package unpack when it is autogenerated during the build.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769265: Patch for lib/Marpa/R2.pm
clone 769265 -1
retitle -1 cdbs: perl-build-vars.mk overrides $Config{ccflags}
reassign -1 cdbs 0.4.127
# maybe serious, not quite sure
severity -1 important
submitter -1 !
thanks
On Sat, Nov 22, 2014 at 04:39:19PM +0100, gregor herrmann wrote:
I've tested your patch (minus the version bump) now in an i386
chroot, and unfortunately the tests still fail:
I looked into this a bit, and the actual problem here seems to be that
the package build system compiles the XS code without $Config{ccflags},
causing a binary incompatibility (probably because -D_FILE_OFFSET_BITS=64
is missing) and leading into the segfault.
[Jeffrey: as a summary, I think this is a bug in the Debian packaging.
It looks to me like Marpa::R2::Build_Me is doing the right thing but
the packaging tells Module::Build to ignore that.]
The patch in 2.086000~dfsg-4 disabling
call_list(PL_scopestack_ix, PL_unitcheckav)
doesn't make much sense to me and is clearly (as advertized) a workaround
rather than a fix.
FWIW the test suite in 2.086000~dfsg-3 (i.e. without the PL_unitcheckav
workaround) passes for me on i386 if I first
export CFLAGS=$(dpkg-buildflags --get CFLAGS) $(perl -MConfig -e 'print
$Config{ccflags}')
which expands to
-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT
-D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
and then call 'debian/rules build' normally.
Marpa::R2::Build_Me seems to append its stuff to $Config{ccflags} like it
should. I think the bug is in the Debian cdbs logic, which ends up calling
perl Build.PL --installdirs vendor --config ccflags=-g -O2
-fstack-protector-strong -Wformat -Werror=format-security -Wall
which probably makes Module::Build override everything Marpa::R2::Build_Me
says about ccflags.
FWIW debhelper uses optimize instead of ccflags for this.
See /usr/share/perl5/Debian/Debhelper/Buildsystem/perl_build.pm.
As an example, debhelper configures the libcss-minifier-xs-perl package like
this:
perl Build.PL --installdirs vendor --config optimize=-g -O2
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
--config ld=cc -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wl,-z,relro
which makes Module::Build preserve $Config{ccflags}, so it
compiles like this:
cc -I/usr/lib/i386-linux-gnu/perl/5.20/CORE -DXS_VERSION=0.09
-DVERSION=0.09 -fPIC -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -o lib/CSS/Minifier/XS.o
lib/CSS/Minifier/XS.c
So, this looks like a bug in /usr/share/cdbs/1/class/perl-build-vars.mk.
Cloning. AFAICS libmarpa-r2-perl and liblucy-perl are the only
Architecture:any (XS) packages in sid that are built with cdbs and
Module::Build, so it makes sense this hasn't been noticed before.
#763039 in liblucy-perl is probably related.
I'm surprised that the workaround in libmarpa-r2-perl helps. If I try to
build libcss-minifier-xs-perl without $Config{ccflags}, I see much worse
breakage.
Not sure what's the right thing to do for jessie, changing cdbs at
this point isn't very inviting. As all the libmarpa-r2-perl reverse
dependencies seem to work with the workaround according to Michael,
I guess this isn't release critical any more...
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770747: [digikam] Canon EOS70D - No thumbnail during import
Forgot to add that I compiled Digikam 4.5.0 from source and the issue is indeed solved with it. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762194: Alternative proposal for init switch on upgrades.
Svante Signell svante.sign...@gmail.com writes: Do people use the usb stick/cd/dvd etc for upgrades to jessie, i.e. the debian installer. Or do they only use apt/aptitude/etc? I don't know that we can speak in absolutes, but I've never personally seen or heard of anyone using debian-installer to do an upgrade. Bdale signature.asc Description: PGP signature
