Bug#733850: RM: automake1.12/experimental -- ROM; Abandoned version of automake
Package: ftp.debian.org Severity: normal automake1.12 never made it to unstable and isn't interesting compared to automake-1.14 so it should just be dropped from unstable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733850: RM: automake1.12/experimental -- ROM; Abandoned version of automake
* Eric Dorland (e...@debian.org) wrote: Package: ftp.debian.org Severity: normal automake1.12 never made it to unstable and isn't interesting compared to automake-1.14 so it should just be dropped from unstable. And by unstable I mean experimental. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Bug#733452: init system daemon readiness protocol
]] Ian Jackson (Sorry, 2nd copy here because I missed up the change of To field in the previous one.) cameron writes (Re: Bug#733452: init system daemon readiness protocol): I was curious: why should SOCK_STREAM be used instead of SOCK_DGRAM in your proposed protocol? SOCK_DGRAM sockets do not offer reliable delivery (at least, not on all unices). Have you seen Lennart Poettering's pastebin of a short daemon side implementation of that protocol: http://fpaste.org/64821/32737713/? It meets all your desired criteria, it is used in one init system already, and it is very extensible. Now that you know that systemd does not actually use SOCK_SEQPACKET, but SOCK_DGRAM, do you have any changes in opinion of the systemd approach? I still think it would be simpler to pass the ready-connected socket (or whatever) to the daemon by inheritance, rather than having the daemon call socket() etc. Do you know why in systemd it was done the way it was ? Passing a file descriptor around reliably so it only ends up in the right place is harder than doing the same with an environment variable. Many daemons close all fds as part of the startup (this is documented as best practice in quite a few places). You also need to ensure that the fd given in the environment variable is actually a valid file descriptior. As per Lennart when asked on IRC: 17:16 poettering Mithrandir: anyway, the one line summary is that i wanted this to be as simple as possible: it should suffice to place a single sd_notify() at the appropriate place to make this work. With fd passing that would not work, as you first have to make sure the passed fd is not closed as part of setting up the execution environment during daemon initialization. 17:17 poettering Mithrandir: sd_notify() as it stands now is really really isolated. As long as the env var is there it doesn't need anything else 17:17 poettering Mithrandir: what ian wants otoh is not so isolated, you need to have a look at the entire daemon initialization and make sure the fd is never closed or handled in its process, and then you *also* need to look at the env var for it 17:17 poettering hope that makes sense -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733851: RFP: txr -- Data munging language
Package: wnpp Severity: wishlist * Package name: txr Version : 72 Upstream Author : Kaz Kylheku k...@kylheku.com * URL : http://www.nongnu.org/txr/ * License : BSD Programming Lang: C Description : Data munging language TXR started as a pattern matching language with the simple design goal of doing text analysis by reversing the manner in which here-documents do synthesis. It soon became a more sophisticated version of the concept, and sprouted a Lisp dialect to fill in functionality gaps, resulting in a tool that can benefit anyone working in a Unix-like environment. -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733087: [ITR] templates://apt-cacher-ng/{apt-cacher-ng.templates}
Dear Debian maintainer, The Debian internationalisation team and the Debian English localisation team will soon begin the review of the debconf templates used in apt-cacher-ng. This review takes place for all packages that use debconf to interact with users and its aims are: - to improve the use of English in all debconf templates; - to make the wording of debconf templates more consistent; - to encourage more translations of templates. Even if your first language is English, this process is likely to help track down typos or errors, and improve consistency between the debconf templates of your package and that of other packages in the distribution. The process involves both debian-l10n-english contributors and Debian translators. The details of the process are given in http://wiki.debian.org/I18n/SmithDebconfReviewProcess. I will act as the coordinator of this activity for apt-cacher-ng. The first step of the process is to review the debconf source template file(s) of apt-cacher-ng. This review will start on Saturday, January 04, 2014, or as soon as you acknowledge this mail with an agreement for us to carry out this process. All parts of the process will be carried out in close collaboration with you, and, unless you explicitly ask for it, no upload nor NMU will happen for apt-cacher-ng. If you approve this process, please let us know by replying to this mail. If some work in progress on your side would conflict with such a rewrite (such as adding or removing debconf templates), please say so, and we will defer the review to later in the development cycle. Thank you for your attention. -- signature.asc Description: Digital signature
Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
On Tue, Dec 31, 2013 at 11:06:15PM +0100, Michael Vogt wrote: On Tue, Dec 31, 2013 at 01:09:39PM +0100, Michael Schaller wrote: [..] It also adds a .travis.yml file that runs the tests. Next step is to actually make the pep8/pylakes test to pass :) [..] That is now done, my branch is pyflakes and pep8 clean. The patch is a bit big (mostly whitespace of course), I pushed it to https://github.com/mvo5/python-apt/tree/feature/travis (but I guess the name should be changed :) I had to update the minimal python3 version to 3.3 because test_paths.py would not work otherwise. We might consider rewriting this test to work on 3.2 (but honestly, I'm not very motivated to do that). Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733300: [ITR] templates://kinect-audio-setup/{templates}
Dear Debian maintainer, The Debian internationalisation team and the Debian English localisation team will soon begin the review of the debconf templates used in kinect-audio-setup. This review takes place for all packages that use debconf to interact with users and its aims are: - to improve the use of English in all debconf templates; - to make the wording of debconf templates more consistent; - to encourage more translations of templates. Even if your first language is English, this process is likely to help track down typos or errors, and improve consistency between the debconf templates of your package and that of other packages in the distribution. The process involves both debian-l10n-english contributors and Debian translators. The details of the process are given in http://wiki.debian.org/I18n/SmithDebconfReviewProcess. I will act as the coordinator of this activity for kinect-audio-setup. The first step of the process is to review the debconf source template file(s) of kinect-audio-setup. This review will start on Saturday, January 04, 2014, or as soon as you acknowledge this mail with an agreement for us to carry out this process. All parts of the process will be carried out in close collaboration with you, and, unless you explicitly ask for it, no upload nor NMU will happen for kinect-audio-setup. If you approve this process, please let us know by replying to this mail. If some work in progress on your side would conflict with such a rewrite (such as adding or removing debconf templates), please say so, and we will defer the review to later in the development cycle. Thank you for your attention. -- signature.asc Description: Digital signature
Bug#733815: Modules completion takes a very long time
a...@usp.br wrote: Thanks for your message. I find it useful to have modprobe default to listing only modules that are NOT loaded yet. For the default use, when loading a module, this is the case. Another issue is that some filenames have '-' in them, but the module names have '_' in them. Does the current solution filter out duplicates due to the modulename and filename not being the same (i.e. '-' vs. '_')? The command modprobe has also an -r option to unload the module, and in this case it would complete to the already loaded modules. Yeah... I never use that case, so didn't code it up, but that's fairly easy just using the output of lsmod. To get the ones not loaded, you have subtract the ones loaded (that you'd find w/lsmod) from the full list -- AND filter out the ones where the names don't exactly correspond (due to _/-). In my system I have 2542 modules: $ _clean_n_sort_mods | wc -l 2543 --- Wow... ?! (Note -- I boot directly from my HD w/no ram disk, so anything I *know* I need, is linked in w/my base kernel). The extra ones are only ones that I might need that would be pertinent to my setup (i.e. only for hardware I have). If I needed to have that many, I might have optimized my functions more... ;-) Good catches on that, BTW. So sounds like using a modified function based on the function I used and your optimizations would ignore the problem of the extra links? Thanks for the timingsdon't have nearly so many modules as it's tuned for my hw setup... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733288: Acknowledgement (bitcoin-qt: Failed to write block at 6 days behind)
Update: I have been sharing my blockchain between two machines, using Bittorent Sync to copy changes from one to the other. I have stopped doing that and now bitcoin-qt works again on both machines, after an rsync to repair the blockchain on the broken machine (reported by this bug report). Apparently bitcoin-qt cannot handle nor recover from something Bittorent Sync is doing, which is probably not a good thing, but IMO not a fatal flaw. IMO this bug report could be downgraded or closed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs
On Tue, Dec 31, 2013 at 07:08:34PM -0800, Steve Langasek wrote: On Tue, Dec 31, 2013 at 11:15:33AM -0800, Russ Allbery wrote: Similarly, I'm not sure why the focus on only adding necessary tools to the initramfs image. Surely this doesn't matter much if the tools are harmless when unneeded? In this context I'm not sure how applicable it is; but there are many x86 ^^^ non-x86 platforms where the bootloader doesn't have particularly impressive I/O performance, and having to load a large initramfs before booting the kernel has a major impact on boot speed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#733706: installation-report: installation on a Lenovo Thinkpad E431
Hi, On 31.12.2013 16:23, Luca Capello wrote: On Tue, 31 Dec 2013 15:50:39 +0100, Antoine Beaupré wrote: On 2013-12-31 05:45:01, Andreas Cadhalpun wrote: Installing on UEFI firmware is supported, but is a little bit tricky, see for example [1]. Particularly you need a GPT partitioned hard disk with two additional partitions, one EFI partition marked with the 'boot' flag in gparted and a partition for grub marked as 'bios_grub' in gparted. Wrong, with UEFI you do not need any 'bios_grub' partition at all: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691046#36 That's correct. The additional 'bios_grub' partition is only needed, if one wants to be able to boot with both EFI and legacy BIOS. This is probably not intended in most cases. On 31.12.2013 16:37, Antoine Beaupré wrote: On 2013-12-31 10:23:18, Luca Capello wrote: On Tue, 31 Dec 2013 15:50:39 +0100, Antoine Beaupré wrote: On 2013-12-31 05:45:01, Andreas Cadhalpun wrote: Yeah... I struggled with that before, and I *was* able to make it work, but since it wasn't obvious this was necessary *during* theinstaller, I did a normal MBR-based partitionning. When the boot loader failed to install, I didn't want to go back and redo everything, especially since this is a dual-boot system and I was happy to have been able to resize the NTFS partition at all... ;) Sorry, but there is something strange here. In the first email you reported that when I rebooted, grub was not installed in the MBR and I was brought back into windows, which means that partman used the partition table already present. This can be checked with a simple `fdisk -l /dev/sda`: if there is no GPT mention, then the partition table is plain old MBR. BTW, Windows 7 does not mandate GPT nor UEFI, but can use both. Oh right - I used the original partitionning I guess. I assumed it was MBR. If it is MBR, UEFI installation is not possible without deleting the existing files on the disk and creating a new GPT partition table. But with MBR one still can use the legacy BIOS mode, as you did. Shouldn't we create GPT partitions all the time now anyways? Why? IMHO if there is no need for it (because BIOS is used) plain old MBR is easier. The reason is that it will fail on newer BIOS, from what I can tell. But GPT is not supported by most old hardware still out there. Personally, I haven't yet come across a BIOS that doesn't support MBR. On 31.12.2013 15:50, Antoine Beaupré wrote: (That resize, btw, was quite scary - I am not sure I did it right. First off it was very fast, so I suspect only the boundaries of the filesystem were changed, without telling NTFS. Then when we rebooted into Windows 7, it did a disk check which thankfully worked fine and it seems the Windows install is okay. But I can't think of doing this on an older system - it would have probably destroyed data, which is not clearly stated in partman. The resize usually is relatively fast, if the part you are removing from the filesystem does not contain any data, because then no data has to be moved and only the file system has to be updated to the new size. I think chkdsk is always scheduled after a resize of NTFS, just to be on the safe side. This should also work perfectly fine on an older system, but there it might take considerably longer, since the data is more likely to be distributed over the whole partition. Of course, one should always have backups of important data. Last but not least, you have to select the UEFI:USB in the firmware and not BIOS:USB, which every firmware has a different marking scheme for, but disabling legacy-bios (or equivalent option) in the UEFI BIOS, should always disable the BIOS:USB option. (It can be enabled again after installation.) Right, I guess this is the tricky bit. It seems that in any case, the user needs to go fiddle in the BIOS, which is annoying. In my case, I was able to install by *disabling* UEFI in the BIOS, but the reverse might be the case for others. Normally, it should not be necessary to change BIOS settings, one just has to select the correct boot device, which is not always easy. Either the BIOS should be in legacy mode, or the hard drive should be partitioned as GPT, when it is an UEFI system. Both cases are supported out of the box by the Debian installer. But if the disk is partitioned as MBR and the BIOS in UEFI mode, this inconsistency has to be solved manually. The next missing thing was wifi. I tried installing firmware-linux- nonfree, but that wasn't enough - firmware-iwlwifi was the one that was required. The installer should install the correct firmware, if you have (on some partition accessible during installation) a /firmware folder that contains the unpacked firmware bundle, which can be downloaded from [2]. But this is currently broken, see [3]. Understood. The weird thing is that the live image did find the wifi card without a problem, but it wasn't found after the install was done.
Bug#733300: [ITR] templates://kinect-audio-setup/{templates}
On Wed, 1 Jan 2014 09:33:58 +0100 Christian PERRIER bubu...@debian.org wrote: Dear Debian maintainer, The Debian internationalisation team and the Debian English localisation team will soon begin the review of the debconf templates used in kinect-audio-setup. [...] If you approve this process, please let us know by replying to this mail. If some work in progress on your side would conflict with such a rewrite (such as adding or removing debconf templates), please say so, and we will defer the review to later in the development cycle. Thank you for your attention. You can proceed with the review. Thanks, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733852: dash: spurious output after Ctrl-V Ctrl-J
Package: dash Version: 0.5.7-3 Severity: minor When one types Ctrl-V Ctrl-J (to make a ^J control character appear on the command line), dash outputs a spurious string (one by ^J occurrence) once the command is validated. For instance: $ echo ab^Jcd^Jef ab cd ef $ true ab^Jcd^Jef $ where the ^J has been entered with Ctrl-V Ctrl-J. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dash depends on: ii debianutils 4.4 ii dpkg 1.17.5 ii libc62.17-97 dash recommends no packages. dash suggests no packages. -- debconf information: * dash/sh: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733853: notmuch: package should warn in a NEWS.Debian file about possible pre-upgrade action
Package: notmuch Version: 0.17-1 Severity: normal Upstream News file mentions actions recommended to do on bigendian machines _before_ upgrading. Debian users have already upgraded when they are provided that file, however. Please add a NEWS.Debian file that echoes that same warning. - Jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
On 12/31/2013 11:52 PM, Julian Andres Klode wrote: It's still a git patch, so it should still have a summary line. git tools are becoming a bit useless otherwise. I did not write “remove the summary line”. * apt/cache.py: - Fixed PEP8 issues - Fixed pyflakes issue: Removed unused local variable 'transient' * apt/package.py: - Fixed PEP8 issues - Fixed pyflakes issue: Removed unused import 'warnings' And git patches usually have prose text. I know that the latest commit does not follow the usual git conventions, but I'm trying to get us completely adopt them, because it just looks unnatural otherwise. Done. Please see the attached patch in revision 3. From 2da21a6e4161799474d996f2530aad03ec9ee674 Mon Sep 17 00:00:00 2001 From: Michael Schaller mich...@5challer.de Date: Wed, 1 Jan 2014 12:08:21 +0100 Subject: [PATCH] apt/cache.py, apt/package.py: Fixed PEP8 and pyflakes issues This commit removed the unused local variable 'transient' in 'apt/cache.py' and the unused import 'warnings' in 'apt/package.py'. --- apt/cache.py | 53 + apt/package.py | 40 +++- debian/changelog | 9 + 3 files changed, 53 insertions(+), 49 deletions(-) diff --git a/apt/cache.py b/apt/cache.py index 43fb55d..6b1e2bd 100644 --- a/apt/cache.py +++ b/apt/cache.py @@ -40,6 +40,7 @@ class FetchFailedException(IOError): class LockFailedException(IOError): Exception that is thrown when locking fails. + class CacheClosedException(Exception): Exception that is thrown when the cache is used after close(). @@ -53,7 +54,7 @@ class Cache(object): list of available packages. The cache can be used like a mapping from package names to Package -objects (although only getting items is supported). +objects (although only getting items is supported). Keyword arguments: progress -- a OpProgress object @@ -74,7 +75,7 @@ class Cache(object): self._fullnameset = set() self._changes_count = -1 self._sorted_set = None - + self.connect(cache_post_open, self._inc_changes_count) self.connect(cache_post_change, self._inc_changes_count) if memonly: @@ -86,17 +87,17 @@ class Cache(object): apt_pkg.config.clear(APT) apt_pkg.config.set(Dir, rootdir) apt_pkg.init_config() -if os.path.exists(rootdir+/etc/apt/apt.conf): +if os.path.exists(rootdir + /etc/apt/apt.conf): apt_pkg.read_config_file(apt_pkg.config, - rootdir + /etc/apt/apt.conf) -if os.path.isdir(rootdir+/etc/apt/apt.conf.d): + rootdir + /etc/apt/apt.conf) +if os.path.isdir(rootdir + /etc/apt/apt.conf.d): apt_pkg.read_config_dir(apt_pkg.config, - rootdir + /etc/apt/apt.conf.d) +rootdir + /etc/apt/apt.conf.d) apt_pkg.config.set(Dir::State::status, rootdir + /var/lib/dpkg/status) # also set dpkg to the rootdir path so that its called for the # --print-foreign-architectures call -apt_pkg.config.set(Dir::bin::dpkg, +apt_pkg.config.set(Dir::bin::dpkg, os.path.join(rootdir, usr, bin, dpkg)) # create required dirs/files when run with special rootdir # automatically @@ -105,7 +106,6 @@ class Cache(object): # recognized (LP: #320665) apt_pkg.init_system() self.open(progress) - def _inc_changes_count(self): Increase the number of changes @@ -118,12 +118,12 @@ class Cache(object): files = [/var/lib/dpkg/status, /etc/apt/sources.list, -] + ] dirs = [/var/lib/dpkg, /etc/apt/, /var/cache/apt/archives/partial, /var/lib/apt/lists/partial, - ] +] for d in dirs: if not os.path.exists(rootdir + d): #print creating: , rootdir + d @@ -165,8 +165,8 @@ class Cache(object): i = last = 0 size = len(self._cache.packages) for pkg in self._cache.packages: -if progress is not None and last+100 i: -progress.update(i/float(size)*100) +if progress is not None and last + 100 i: +progress.update(i / float(size) * 100) last = i # drop stuff with no versions (cruft) if pkg.has_versions: @@ -259,7 +259,8 @@ class Cache(object): def required_download(self): Get the size of the packages that are required to download. if self._records is None: -raise CacheClosedException(Cache
Bug#733852: dash: spurious output after Ctrl-V Ctrl-J
On 2014-01-01 11:33:18 +0100, Vincent Lefevre wrote: When one types Ctrl-V Ctrl-J (to make a ^J control character appear on the command line), dash outputs a spurious string (one by ^J occurrence) once the command is validated. For instance: $ echo ab^Jcd^Jef ab cd ef $ true ab^Jcd^Jef $ where the ^J has been entered with Ctrl-V Ctrl-J. I'm wondering whether this problem comes from an old behavior that no longer works or something that has actually never worked, where the should have been some prompt like with busybox sh. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733854: posh: spurious output after Ctrl-V Ctrl-J
Package: posh Version: 0.12.2 Severity: minor When one types Ctrl-V Ctrl-J (to make a ^J control character appear on the command line), posh outputs a spurious string (one by ^J occurrence) once the command is validated. For instance: $ echo ab^Jcd^Jef ab cd ef $ true ab^Jcd^Jef $ where the ^J has been entered with Ctrl-V Ctrl-J. Same problem as dash: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733852 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages posh depends on: ii debconf [debconf-2.0] 1.5.52 ii libc6 2.17-97 posh recommends no packages. posh suggests no packages. -- debconf information: posh/sh: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
A few comments on the patches: 1) tests/test_pep8.py Can you document in a comment or docstring why you ignore certain issues and what these issues are? This should help readers to better understand what the test does and more importantly what it ignores. Furthermore do you plan to reduce the number of ignores in the future? If so you should add a TODO for yourself. 2) tests/test_pep8.py Can you use instead of 'self.assertEqual(res, 0)' a better fail message like you did in 'tests/test_pyflakes.py'? 3) tests/test_pyflakes.py You don't need the 'from __future__ import print_function' import with Python 3. 4) debian/control (nitpick) I prefer to sort dependencies alphabetically. 5) .travis.yml I would really like to see a rather lengthy comment in the beginning of the YAML file to explain what purpose it serves and what it does. I also think you should give a link here and that you should explain what should happen after Trusty. Maybe it would be even better to use SID instead of Trusty. 6) .travis.yml Why do you run './debian/rules binary' and not 'dpkg-buildpackage'? 7) .travis.yml Why not also ensure here that Lintian and if possible piuparts have no issues with the newly built package? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733853: notmuch: package should warn in a NEWS.Debian file about possible pre-upgrade action
Jonas Smedegaard d...@jones.dk writes: Upstream News file mentions actions recommended to do on bigendian machines _before_ upgrading. Debian users have already upgraded when they are provided that file, however. Please add a NEWS.Debian file that echoes that same warning. - Jonas Hi Jonas; Indeed NEWS.Debian was already in the source package. But it turns out that's the wrong name :(. Thanks for the heads-up, rebuilding... David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733727: wine32: /usr/lib/i386-linux-gnu/wine/bin/wine32: could not open
Package: wine32 Version: 1.6.1-10 Followup-For: Bug #733727 A workaround is to symlink /usr/lib/i386-linux-gnu/wine/bin/wine to /usr/lib/i386-linux-gnu/wine/bin/wine32. -- 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.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wine32 depends on: ii libc6 2.17-97 ii libwine1.6.1-10 ii libwine-gecko-1.4 1.4+dfsg1-3 ii x11-utils 7.7+1 wine32 recommends no packages. wine32 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#705859: blueman: diff for NMU version 1.23+update1-2.1
I uploaded new versions to mentors yesterday. Waiting for Nobuhiro Iwamatsu to sponsor them. So you can cancel the NMU. No more pressure necessary. ;) Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733855: oo
package: wnpp Severity: wishlist Owner: 'oliver weber' sinn...@londor.eu *Package Name : buftok Version : 0.2.0 Upstream Author : Tony Arcieri, Martin Emde, Erik Michaels-Ober *URL : https://github.com/sferik/buftok *License : MIT *Description : BufferedTokenizer extracts token delimited entities from a sequence of arbitrary inputs I am packaging devise as it is a dependency of devise_invitable (#691181) which is a dependency of diaspora (#597093) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733856: graphite-carbon: Logrotate is not working correctly
Package: graphite-carbon Version: 0.9.12-1 Severity: normal Tags: patch Current logrotate script use copytruncate mode, but carbon-cache do not behave well with such mode : after rotation logfile will start with huge hole full of NULL character. To reproduce, you can: * install package (tested with 0.9.12-1 on Ubuntu saucy 13.10) * Start graphite-carbon (edit /etc/default/graphite-carbon to enable startup, start it with /etc/init.d/graphite-carbon) * Create some message on logfile, example for listener.log, just open/close a connection on port 2003 * Simulate logrotate action (cp listener.log listener.log.1 echo -n listener.log) * Re-create some message on logfile. * See that log file start with NULL character It seems that code support external log rotation if the file is only moved. From file lib/carbon/log.py, we can see that if log file no longer exist it will be re-opened: def write(self, data): if not self.enableRotation: if not exists(self.path): self.reopen() Where self.enableRotation is the carbon's internal log rotation disabled by Debian packaging. So a solution could be to disable copytruncate in logrotate. The default mode of logrotate, if I'm not wrong, is to move the file and no recreating a new file. Thus carbon-cache will detect that logfile no longer exist and re-open it. I attached a debdiff with this fix. -- System Information: Debian Release: sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru graphite-carbon-0.9.12/debian/changelog graphite-carbon-0.9.12/debian/changelog --- graphite-carbon-0.9.12/debian/changelog 2013-09-01 12:29:29.0 +0200 +++ graphite-carbon-0.9.12/debian/changelog 2014-01-01 12:58:28.0 +0100 @@ -1,3 +1,9 @@ +graphite-carbon (0.9.12-1.1) unstable; urgency=medium + + * Remove copytruncate mode of logrotate. + + -- Pierre Fersing pier...@pierref.org Wed, 01 Jan 2014 12:57:16 +0100 + graphite-carbon (0.9.12-1) unstable; urgency=low * New Upstream Version diff -Nru graphite-carbon-0.9.12/debian/graphite-carbon.logrotate graphite-carbon-0.9.12/debian/graphite-carbon.logrotate --- graphite-carbon-0.9.12/debian/graphite-carbon.logrotate 2013-09-01 12:29:29.0 +0200 +++ graphite-carbon-0.9.12/debian/graphite-carbon.logrotate 2014-01-01 13:14:44.0 +0100 @@ -6,5 +6,4 @@ delaycompress notifempty sharedscripts - copytruncate }
Bug#729203: ffmpeg for debian/ubuntu
Hi, please please provide ffmpeg in ubuntu because I had a lot of trouble with libav. I compile myself ffmpeg. eddrog
Bug#733857: Please switch from autotools-dev to autoreconf to cover more ports
Package: libisocodes
Version: 1.0-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch
In Ubuntu, the attached patch was applied to achieve the following:
* Switch from autotools-dev to dh-autoreconf to get libtool updates.
* Explicitly set $LANGUAGE; the testsuite fails when it hasn't been.
The first change is the topic of this bug report. autoreconf happens
to pull in config.{sub,guess} updates for automake-using projects (like
this one), so dh-autoreconf ends up being a superset of autotools-dev,
and allows you to support zero-effort porting to even more arches, like
the ppc64el port that requires libtool updates.
While you're at it, the second half of this patch is a simple bugfix
that doesn't seem to have an impact on the Debian buildds, but was
biting me on the Ubuntu buildds. Setting LANGUAGE explicitly when
running the testsuite seems to be necessary if it's previously been
unset, and certainly doesn't do any harm in cases where things were
already working.
... Adam
-- System Information:
Debian Release: wheezy/sid
APT prefers trusty-updates
APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500,
'trusty'), (500, 'saucy-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13.0-0-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libisocodes-1.0/debian/changelog libisocodes-1.0/debian/changelog
diff -Nru libisocodes-1.0/debian/control libisocodes-1.0/debian/control
--- libisocodes-1.0/debian/control 2013-12-29 07:10:38.0 -0700
+++ libisocodes-1.0/debian/control 2014-01-01 05:37:35.0 -0700
@@ -1,7 +1,7 @@
Source: libisocodes
Priority: optional
Maintainer: Tobias Quathamer to...@debian.org
-Build-Depends: debhelper (= 9), autotools-dev, valac, libglib2.0-dev,
+Build-Depends: debhelper (= 9), dh-autoreconf, valac, libglib2.0-dev,
libxml2-dev, libgee-dev, libgirepository1.0-dev, gobject-introspection,
# The following packages are only needed for testing during the build
iso-codes, locales
diff -Nru libisocodes-1.0/debian/rules libisocodes-1.0/debian/rules
--- libisocodes-1.0/debian/rules 2013-12-13 13:32:22.0 -0700
+++ libisocodes-1.0/debian/rules 2014-01-01 05:30:04.0 -0700
@@ -14,7 +14,7 @@
override_dh_auto_test:
mkdir -p debian/tmpdir/usr/lib/locale
localedef -i de_DE -f UTF-8 debian/tmpdir/usr/lib/locale/de_DE.UTF-8
- LOCPATH=debian/tmpdir/usr/lib/locale LC_ALL=de_DE.UTF-8 dh_auto_test
+ LOCPATH=debian/tmpdir/usr/lib/locale LANGUAGE=de LC_ALL=de_DE.UTF-8 dh_auto_test
# Remove the tmpdir for the locale, see above.
override_dh_auto_clean:
@@ -22,4 +22,4 @@
rm -rf debian/tmpdir
%:
- dh $@ --with autotools-dev
+ dh $@ --with autoreconf
Bug#720816: openscenegraph uninstallable
Control: block 724686 by -1 Control: block 719402 by -1 Upstream may be releasing 3.2.1 soon, but there is still no definite date (http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2013-December/065775.html). As far as I can tell, the only packaging change needed (beyond what has already been done in Alioth) is to declare the conflicts with 3.2.0rc (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722674#10). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: loose ends for init system decision
On Tue, Dec 31, 2013 at 10:18:08PM -0800, Russ Allbery wrote: For upstart readiness, obviously one needs some sort of explicit flag or trigger to enable the raise(SIGSTOP) behavior, since that will otherwise cause rather obvious problems in getting the daemon to work outside of upstart. I prefer to use a command-line flag for this (-Z, per your recommendation) since it has to be explicitly enabled and there isn't the same sort of safe fallback if it's missing the way that there is for the systemd protocol. I don't see any real problem with using an environment variable, though, as long as it's unset afterwards so that it's not inherited by children. Bear in mind that this may often be being done by the Debian maintainer in advance of upstream, and adding a one-character command-line option is problematic since that stands a decent chance of clashing. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system other points, and conclusion
On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote: On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson cjwat...@debian.org inotify is used to notice changes to configuration files. This is certainly helpful for users, but it isn't critical as initctl reload-configuration works without it. We could probably do without this with the aid of a dpkg trigger. inotify use can easily be ported to kqueue within Upstart, or libinotify-kqueue can be used. Note that I'm talking about the Hurd here. kqueue is a kFreeBSD thing, as far as I know. (Compare e.g. https://lists.debian.org/debian-hurd/2013/10/msg00021.html) prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work properly when Upstart is supervising a user session. This isn't a required feature and could easily be compiled out until suitable kernel support is available (this actually seems like the sort of thing that could be done in the Hurd without too much difficulty, but I haven't looked into it). If absent, it might well impede the ability to do an advanced desktop port, but it wouldn't get in the way of porting the bulk of services. Unity, likely the only desktop environment using Upstart as a session init, is not in Debian. The sacrifice of this functionality on non-linux systems is perfectly acceptable. While this is true today, we need to look to the future. Using Upstart as a session init is not conceptually tied to Unity in any way, and I expect that other desktop environments will want to use more advanced session supervision soon enough. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733858: aptitude crashes when installing systemd-sysvinit and upgrading sysvinit at the same time
Package: aptitude Version: 0.6.8.2-1 Severity: normal Hello, I wanted to try systemd so 1) installed systemd 2) marked non-conflicting version of sysvinit and systemd-sysv for install 3) proceeded with installetion aptitude crashed endlessly printing information about systemd-sysv conflicting with the sysvinit currently installed There is no debug info. #0 0x77b223db in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, bool, int) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 No symbol table info available. #1 0x77b235b1 in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, bool, int) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 No symbol table info available. #2 0x77b22c7e in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, bool, int) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 No symbol table info available. #3 0x77b235b1 in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, bool, int) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 No symbol table info available. #4 0x77b22c7e in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, bool, int) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 No symbol table info available. #5 0x77b235b1 in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, bool, int) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 No symbol table info available. #6 0x77b22c7e in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, bool, int) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 No symbol table info available. #7 0x77b235b1 in pkgPackageManager::SmartUnPack(pkgCache::PkgIterator, bool, int) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 -- Package-specific info: Terminal: rxvt-unicode $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.8.2 compiled at Nov 7 2012 07:08:03 Compiler: g++ 4.7.2 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.2.10 Ept support enabled. Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20110404 cwidget version: 0.5.16 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 (0x7fffc0e9b000) libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x7f179488d000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f179465d000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f1794433000) libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f179422e000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7f1793f2e000) libept.so.1.aptpkg4.12 = /usr/lib/libept.so.1.aptpkg4.12 (0x7f1793c8d000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f17938a8000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f1793691000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f17933e5000) libboost_iostreams.so.1.49.0 = /usr/lib/libboost_iostreams.so.1.49.0 (0x7f17933ca000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f17931ae000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f1792ea6000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f1792ba8000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f1792992000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f17925e5000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f17923e2000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f17921de000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f1791fcd000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f1791dc8000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f1791bbf000) /lib64/ld-linux-x86-64.so.2 (0x7f1795228000) -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (990, 'stable'), (171, 'unstable'), (151, 'experimental'), (121, 'precise-updates'), (121, 'precise-security'), (121, 'precise'), (101, 'stable'), (101, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-trunk-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 aptitude depends on: ii aptitude-common 0.6.8.2-1 ii libapt-pkg4.120.9.7.9+deb7u1 ii libboost-iostreams1.49.0 1.49.0-3.2 ii libc6 2.17-97 ii libcwidget3 0.5.16-3.4 ii libept1.4.12 1.0.9 ii libgcc1 1:4.8.2-10 ii libncursesw5 5.9-10 ii libsigc++-2.0-0c2a2.2.10-0.2 ii libsqlite3-0 3.7.13-1+deb7u1 ii libstdc++64.7.2-5 ii libtinfo5 5.9-10 ii
Bug#733859: /usr/lib/i386-linux-gnu/wine/bin/wine: /usr/lib/i386-linux-gnu/wine/bin/wine32 is missing
Package: wine32 Version: 1.6.1-10 Severity: important File: /usr/lib/i386-linux-gnu/wine/bin/wine Dear Maintainer, Actually, wine is a bash-script, which toggle between /usr/bin/wine32 and /usr/bin/wine64. /usr/bin/32 is a symlinks to /usr/lib/i386-linux-gnu/wine/bin/wine. It seems that /usr/lib/i386-linux-gnu/wine/bin/wine, when executed from /usr/bin/wine32, try to find and do things with a file called /usr/lib/i386-linux-gnu/wine/bin/wine32. You will find below some strace of the call, created using 'strace -ft /usr/bin/wine32'. Thanks for reading! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wine32 depends on: ii libc6 2.17-97 ii libwine1.6.1-10 ii libwine-gecko-1.4 1.4+dfsg1-3 ii x11-utils 7.7+1 wine32 recommends no packages. wine32 suggests no packages. -- no debconf information 14:17:29 execve(/usr/bin/wine32, [/usr/bin/wine32, junk], [/* 23 vars */]) = 0 14:17:29 brk(0) = 0x7d253000 14:17:29 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory) 14:17:29 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf771 14:17:29 readlink(/proc/self/exe, /usr/lib/i386-linux-gnu/wine/bin/wine, 4096) = 37 14:17:29 access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/tls/i686/sse2/cmov/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/tls/i686/sse2/cmov, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/tls/i686/sse2/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/tls/i686/sse2, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/tls/i686/cmov/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/tls/i686/cmov, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/tls/i686/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/tls/i686, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/tls/sse2/cmov/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/tls/sse2/cmov, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/tls/sse2/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/tls/sse2, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/tls/cmov/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/tls/cmov, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/tls/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/tls, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/i686/sse2/cmov/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/i686/sse2/cmov, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/i686/sse2/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/i686/sse2, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/i686/cmov/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/i686/cmov, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/i686/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/i686, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/sse2/cmov/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/sse2/cmov, 0xff8fb110) = -1 ENOENT (No such file or directory) 14:17:29 open(/usr/lib/i386-linux-gnu/wine/sse2/libwine.so.1, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 14:17:29 stat64(/usr/lib/i386-linux-gnu/wine/sse2, 0xff8fb110) = -1 ENOENT (No such file
Bug#732910: [request-tracker-maintainers] Bug#732910: Add MariaDB as an alternative dependency
On Sun, Dec 22, 2013 at 07:57:16PM +0200, Otto Kekäläinen wrote: MariaDB is an drop in replacement for MySQL. As MariaDB has just landed in Debian unstable it would be a good time to include it in the dependencies as an alternative to MySQL. Please change in the debian/control any occurences of mysql-server and mysql-client to mariadb-server | mysql-server and mariadb-client | mysql-client. This way systems that have MariaDB installed instead of MySQL can use this package without problems. While MariaDB is at the moment only in Debian unstable, some users might have installed it from mariadb.org or other sources to jessie or wheezy, so it does not hurt if this package has these dependencies updated for older Debian releases too. This is a very quick and safe change to do, and there is no urgency to upload the package just for this small thing. Just update the dependency (or suggest or recommends) lines in the debian/control file and let the change propagate when there is something else to push too. I will wait until the revised suggestion being discussed on debian-devel is made official (please could you consider sending a note to the bugs in question in that case?) Cheers, Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730641: [request-tracker-maintainers] Bug#730641: Bug#730641: request-tracker4: FTBFS: Can't locate Plack/Handler/Starlet.pm in @INC
On Thu, Dec 05, 2013 at 11:14:44AM +0200, Niko Tyni wrote: On Wed, Dec 04, 2013 at 06:26:44PM +0100, Andreas Moog wrote: That's weird, I can't reproduce it either now. It used to fail on i386 sbuild for me, but builds succeed now. Ah well, maybe it was a problem in my sbuild instance. Sorry for the noise. I hope I sent the correct request to the BTS to deal with this incorrect report. No worries, thanks for trying. I guess it could be a now-fixed problem in one of the numerous dependencies. Just as another data point, I saw these two tests fail back in October when initially packaging 4.0.18 (but ran out of time to do anything more with it) and it's gone away for me too. Cheers, Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732743: Pending fixes for bugs in the fontforge package
tag 732743 + pending thanks Some bugs in the fontforge package are closed in revision 45113dd2e21ae1abbfedf624b5c5006c923572ab in branch 'master' by Christian Perrier The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-fonts/fontforge.git;a=commitdiff;h=45113dd Commit message: Make packages Multi-Arch: foreign. Thanks to Dimitri John Ledkov. Closes: #732743 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
Package: wnpp Severity: wishlist Owner: Ximin Luo infini...@gmx.com * Package name: pond Version : 0:git~2014-01-01 Upstream Author : Adam Langley a...@imperialviolet.org * URL : https://pond.imperialviolet.org/ * License : BSD Programming Lang: Go Description : Forward secure, asynchronous messaging for the discerning. For secure, synchronous communication we have OTR and, when run over Tor, this is pretty good. But while we have secure asynchronous messaging in the form of PGP email, it's not forward secure and it gratuitously leaks traffic information. While a desire for forward secure PGP is hardly new, it still hasn't materialised in a widely usable manner. Additionally, email is used predominately for insecure communications (mailing lists, etc) and is useful because it allows previously unconnected people to communicate as long as a (public) email address is known to one party. But the flip side to this is that volume and spam are driving people to use centralised email services. These provide such huge benefits to the majority of email communication, so it's unlikely that this trend is going to reverse. But, even with PGP, these services are trusted with hugely valuable traffic information if any party uses them. So Pond is not email. Pond is forward secure, asynchronous messaging for the discerning. Pond messages are asynchronous, but are not a record; they expire automatically a week after they are received. Pond seeks to prevent leaking traffic information against everyone except a global passive attacker. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733861: Upstream provider changed - FMCS now part of RDKit
Source: fmcs Version: 1.0-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I discovered, that RDKit ships a copy of FMCS that is newer (1.1) than what upstream of FMCS released yet (1.0). So I was talking to Greg Landrum and he told me, that in accordance with Andrew Dalke RDKit now provides the official FMCS python module. Shall python-rdkit provide python-fmcs or shall it be split? Regards, Daniel - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (850, 'unstable'), (700, 'testing'), (560, 'stable'), (500, 'oldstable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlLEIYAACgkQm0bx+wiPa4yxBQCdGUpAsKVmMp9dubJOez8LLj9/ zWQAn1iVyW5RkC8MXfjrB8Q5e1O9nOlA =qD1r -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#733862: APC_UPS?
Package: linux-image, linux-headers Version: 3...~bpo70+1 (any backports kernel) No APC UPS appearing, no conservative CPU mode possible, in any backports kernel. fn-keys were acceptable working in 3.11.8-1~bpo70+1 (same like stable kernel) and only volume/brigthness in 3.11.10-1~bpo70+1 (asus_nb_wmi). When fully functional backports kernel will be available? PCs: ASUS Q400A, ASUS P4P800E-DELUX, ASRock Z77EXTREME6, ASRock P4i45E Debian Wheezy MATE Desktop 32 or 64 bit. Best regards and Happy New Year, Alexey
Bug#730896: kexec-tools: FTBFS: stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory
Hi, Sorry for the answer time :) El Lunes, 16 de diciembre de 2013 12:23:52 Khalid Aziz escribió I have tried to reproduce this problem multiple times so I could debug it and have failed to reproduce it. Error message looks like issue with glibc. buildd shows amd64 package for kexec-tools built and installed successfully - https://buildd.debian.org/status/package.php?p=kexec-toolssuite=sid. Could it have been a glitch in glibc that has been resolved Still failing. Build log extract from 2013/12/26 [1]: In file included from command-line:0:0: /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory #include bits/predefs.h [1] http://aws-logs.debian.net/ftbfs-logs/2013/12/26/kexec-tools_2.0.4-1_unstable.log.gz David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733859: /usr/lib/i386-linux-gnu/wine/bin/wine: Re: /usr/lib/i386-linux-gnu/wine/bin/wine: /usr/lib/i386-linux-gnu/wine/bin/wine32 is missing
Package: wine32
Version: 1.6.1-10
Followup-For: Bug #733859
Dear Maintainer,
I guess I have found out the problem
I have written a small patch that will look out for symlink, before preloading
the binary (see below).
PS: this bug refers to #733727, mea culpa
*** /tmp/main.patch
--- wine-1.6.1/loader/main.c2013-11-15 20:30:24.0 +0100
+++ wine-good/loader/main.c 2014-01-01 15:22:41.618312694 +0100
@@ -209,6 +209,7 @@
int main( int argc, char *argv[] )
{
char error[1024];
+char realfile[1024];
int i;
if (!getenv( WINELOADERNOEXEC )) /* first time around */
@@ -219,7 +220,15 @@
check_command_line( argc, argv );
if (pre_exec())
{
-wine_init_argv0_path( argv[0] );
+// Try to find the real binary
+// If readlink fails, it may be because loader is NOT a symlink
+ssize_t len = readlink(argv[0], realfile, sizeof(realfile) - 1);
+if(len != -1){
+realfile[len] = '\0';
+wine_init_argv0_path( realfile );
+} else {
+wine_init_argv0_path( argv[0] );
+}
wine_exec_wine_binary( NULL, argv, getenv( WINELOADER ));
fprintf( stderr, wine: could not exec the wine loader\n );
exit(1);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706426: memcached: diff for NMU version 1.4.13-0.3
Control: tags 706426 + patch pending
Control: tags 733643 + patch pending
Dear maintainer,
I've prepared an NMU for memcached (versioned as 1.4.13-0.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards,
Salvatore
diff -Nru memcached-1.4.13/debian/changelog memcached-1.4.13/debian/changelog
--- memcached-1.4.13/debian/changelog 2013-01-23 21:22:12.0 +0100
+++ memcached-1.4.13/debian/changelog 2014-01-01 15:37:36.0 +0100
@@ -1,3 +1,15 @@
+memcached (1.4.13-0.3) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Add 06_CVE-2011-4971.patch patch.
+CVE-2011-4971: Fix remote denial of service. Sending a specially
+crafted packet cause memcached to segfault. (Closes: #706426)
+ * Add 07_CVE-2013-7239.patch patch.
+CVE-2013-7239: SASL authentication allows wrong credentials to access
+memcache. (Closes: #733643)
+
+ -- Salvatore Bonaccorso car...@debian.org Mon, 30 Dec 2013 17:47:44 +0100
+
memcached (1.4.13-0.2) unstable; urgency=low
* Non-maintainer upload.
diff -Nru memcached-1.4.13/debian/patches/06_CVE-2011-4971.patch memcached-1.4.13/debian/patches/06_CVE-2011-4971.patch
--- memcached-1.4.13/debian/patches/06_CVE-2011-4971.patch 1970-01-01 01:00:00.0 +0100
+++ memcached-1.4.13/debian/patches/06_CVE-2011-4971.patch 2014-01-01 15:37:36.0 +0100
@@ -0,0 +1,54 @@
+Description: Fix segfault on specially crafted packet
+ CVE-2011-4971: remote denial of service
+Origin: upstream, http://github.com/memcached/memcached/commit/6695ccbc525c36d693aaa3e8337b36aa0c784424
+Bug: https://code.google.com/p/memcached/issues/detail?id=192
+Bug-Debian: http://bugs.debian.org/706426
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=957964
+Forwarded: not-needed
+Author: Huzaifa Sidhpurwala huzai...@redhat.com
+Reviewed-by: Salvatore Bonaccorso car...@debian.org
+Last-Update: 2013-12-29
+Applied-Upstream: 1.4.16
+
+--- a/memcached.c
b/memcached.c
+@@ -3874,6 +3874,16 @@
+ complete_nread(c);
+ break;
+ }
++
++/* Check if rbytes 0, to prevent crash */
++if (c-rlbytes 0) {
++if (settings.verbose) {
++fprintf(stderr, Invalid rlbytes to read: len %d\n, c-rlbytes);
++}
++conn_set_state(c, conn_closing);
++break;
++}
++
+ /* first check if we have leftovers in the conn_read buffer */
+ if (c-rbytes 0) {
+ int tocopy = c-rbytes c-rlbytes ? c-rlbytes : c-rbytes;
+--- /dev/null
b/t/issue_192.t
+@@ -0,0 +1,20 @@
++#!/usr/bin/perl
++
++use strict;
++use Test::More tests = 2;
++use FindBin qw($Bin);
++use lib $Bin/lib;
++use MemcachedTest;
++
++my $server = new_memcached();
++my $sock = $server-sock;
++
++ok($server-new_sock, opened new socket);
++
++print $sock \x80\x12\x00\x01\x08\x00\x00\x00\xff\xff\xff\xe8\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00;
++
++sleep 0.5;
++ok($server-new_sock, failed to open new socket);
++
++
++
diff -Nru memcached-1.4.13/debian/patches/07_CVE-2013-7239.patch memcached-1.4.13/debian/patches/07_CVE-2013-7239.patch
--- memcached-1.4.13/debian/patches/07_CVE-2013-7239.patch 1970-01-01 01:00:00.0 +0100
+++ memcached-1.4.13/debian/patches/07_CVE-2013-7239.patch 2014-01-01 15:37:36.0 +0100
@@ -0,0 +1,122 @@
+Description: CVE-2013-7239: SASL authentication allows wrong credentials to access memcache
+ It was previously possible to bypass authentication due to implicit
+ state management. Now we explicitly consider ourselves
+ unauthenticated on any new connections and authentication attempts.
+Origin: upstream, https://github.com/memcached/memcached/commit/87c1cf0f20be20608d3becf854e9cf0910f4ad32
+Bug: https://code.google.com/p/memcached/issues/detail?id=316
+Bug-Debian: http://bugs.debian.org/733643
+Forwarded: not-needed
+Last-Update: 2013-12-30
+Applied-Upstream: 1.4.17
+
+--- a/memcached.c
b/memcached.c
+@@ -442,6 +442,7 @@
+ c-iovused = 0;
+ c-msgcurr = 0;
+ c-msgused = 0;
++c-authenticated = false;
+
+ c-write_and_go = init_state;
+ c-write_and_free = 0;
+@@ -1602,6 +1603,8 @@
+ if (!settings.sasl)
+ return;
+
++c-authenticated = false;
++
+ if (!c-sasl_conn) {
+ int result=sasl_server_new(memcached,
+NULL,
+@@ -1736,6 +1739,7 @@
+
+ switch(result) {
+ case SASL_OK:
++c-authenticated = true;
+ write_bin_response(c, Authenticated, 0, 0, strlen(Authenticated));
+ pthread_mutex_lock(c-thread-stats.mutex);
+ c-thread-stats.auth_cmds++;
+@@ -1772,11 +1776,7 @@
+ rv = true;
+ break;
+ default:
+-if (c-sasl_conn) {
+-const void *uname = NULL;
+-
Bug#727708: init system other points, and conclusion
Hi, Ian Jackson wrote (31 Dec 2013 16:58:17 GMT) : I think you have misunderstood. Or perhaps I hae misunderstood you. The work that I'm saying needs to be done anyway is the work to disentange the parts of systemd which are required by (say) GNOME from the parts which are only relevant for systemd as init. I was talking about the very same work, so I think we're understanding each other just fine on this point :) Your reply helped me focus and clarify my analysis (that is not the project as whole / porters and upstart lovers anymore), though. Thank you. It also helped me understand what, I think, a few things we disagree on: first, who would have the moral responsibility of doing this work; second, whether it matters at all; third, who would have to do this work in practice. In what follows, I'll try to keep my personal preferences (that don't matter at all as far as the TC decision is concerned) aside, but I don't expect to be entirely successful. Sorry about that in advance. My conscious intent here is to help make this discussion more fruitful and focused on what matters in practice; but it's obvious that my analysis is somehow affected by the investments I've personally made in the last 14 months (since then, I have been very happily running systemd on almost every Wheezy or newer system that I am responsible for). For the sake of full-disclosure, I have to add that I am a core developer of a Debian derivative that relies on GNOME and does not intend to switch any time soon. intrigeri writes (Bug#727708: init system other points, and conclusion): The difference lies in who are the people who need to do this work anyway, and who else may instead dedicate their time to other tasks, lead by their own desires and needs. I think that it is right that the costs of undoing systemd's bundling, be borne by the systemd community (including systemd's advocates and maintainers in Debian) rather than by Debian (or the rest of the Free Software world) at large. First, I beg to disagree about who, in full rightness, would have the moral responsibility to do this work. But as shown below, we don't care much about what you or I think. Second, regardless of what my or Ian's or the TC's or $DEITY's opinion on this moral matter is, that's very much unimportant: in my belief, the time and energy people put into Debian is rarely lead by a sense of moral responsibility, especially when the work that needs to be done is something they do *not* feel to be part of what they have committed to in the first place. I happen to very much doubt that the systemd community feels that they are committed to support the use-case we are discussing (systemd minus its init component). Hence, my third point is that in practice: * If upstart is chosen as the default init: it might be that the systemd community shows little interest in doing this work (and, to be fair, I would find this totally understandable, and not surprising at all). Then, it is not unlikely that the people who end up doing this work are those who maintain reverse dependencies of the systemd stack, such as desktop environments (at least GNOME and Unity, in Debian and/or Ubuntu). They might have to do this because of the combination of 1. they want to keep their packages in working state in Debian and/or Ubuntu; 2. the decision to use upstart creates the need for someone to do this work; 3. for whatever reason, nobody else is doing it. If this were to happen, regardless of anyone's take on what full rightness would have called for, then the cost of the initial and ongoing work would be held by an important subset of our community, that is anyone who wants Debian to deliver a given modern DE. I realize that it's not the same as the Debian project as a whole, contrary to what I initially wrote. But it's a lot more people than just the systemd maintainers in Debian (I'm not comparing to the broader systemd community here, for reasons I've given above). * If systemd is chosen as the default init: I am very doubtful that a decision of the TC regarding who has the moral responsibility of it would be enough to motivate the systemd community to tackle this work if they don't feel it's part of the mission they are committed to. It might be, but I don't think it's a reasonable assumption to make. So, with the information I have in hand, I'm sticking to my original point here: in practice, this would be a job for porters, for anyone who wants to allow users of Debian to give this amount of flexibility, and for any derivative who wants to use another init system; while others treat this effort with deference and reasonable accommodation, and can get themselves busy, as they wish, with other means to scratch their own itch and/or make the world a better place. My conclusion is that 1. in practice, the situation is far from being as simple as: the systemd community will have to do it anyway; and 2.
Bug#733612: [gdm3] wm-independent
I have tried the login with different window managers also (gnome, gnome classic, gnome flashback, lxde, xfce, icewm) but the error was similar (and happened in 100% cases). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733112: [Pkg-systemd-maintainers] Bug#733112: libsystemd-login0: logind not found by gdm3
Hi Kjö, Kjö Hansi Glaz k...@a4nancy.net.eu.org writes: I use systemd as init. It seems that gdm3 fails to communicate with logind as it fallsback to consolekit as a login manager. Can you also strace gdm3 please? I’m not yet convinced the bug is in systemd-logind (or libsystemd-login0). Please find attached a strace of systemd-logind before restarting gdm3 and logging in. Can you repeat that with -s 2048 so that we can actually see a bit of the message’s content? Also, a trace of what’s happening on dbus would be useful. I think you can use dbus-monitor for that. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731753: gnome crashes on login but gnome-classic doesn't
Control: severity -1 important Control: tags -1 + moreinfo Le lundi 09 décembre 2013 à 07:34 -0500, Thomas Hehl a écrit : Subject: gnome-shell: gnome crashes on login but gnome-classic does not Package: gnome-shell Version: 3.4.2-7+deb7u1 Justification: can't use the GUI Severity: serious When I came in on Monday morning, I found that my system was off. I started it up and could not log into the gnome shell. I kept getting the Oh, no! screen. * What exactly did you do (or not do) that was effective (or ineffective)? I switched to gnome-classic, which seems to be working Has gnome-shell ever worked on your machine? If not, this is likely a problem with 3D support of your card. Could you also please attach the /tmp/xorg-debug.log created by the following command to this bug report? sudo bash -c /usr/share/bug/xserver-xorg-core/script 31 /tmp/xorg-debug.log Also, I'm downgrading the severity of this bug report, since gnome-shell works fine for most users. Best, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#733232: [Pkg-systemd-maintainers] Bug#733232: systemd: Systemd fails to boot after fscking filesystem if plymouth not installed
Hi Philip, Philip Armstrong p...@kantaka.co.uk writes: If systemd decides to fsck one or more of my filesystems, then the boot consistently fails, dropping me to a root password prompt. If I login run journalctl -xb than I find the following error in the journal: Dec 27 12:39:53 xanthus systemd[1]: Started LSB: option to manually manipulate the IPsec SA/SP database. Dec 27 12:39:53 xanthus systemd[1]: Startup finished in 4.659s (kernel) + 1min 30.662s (userspace) = 1min 35.321s. Dec 27 12:39:53 xanthus systemd[685]: Failed at step EXEC spawning /bin/plymouth: No such file or directory (I don't have plymouth installed there is no /bin/plymouth) The system always boots successfully if no fsck is required. I think you are misinterpreting the situation. In the systemd source, there are only two occurrences of /bin/plymouth: $ grep -r '/bin/plymouth' . ./units/rescue.service.m4.in:ExecStartPre=-/bin/plymouth quit ./units/emergency.service.in:ExecStartPre=-/bin/plymouth quit Both are prefixed with a minus, meaning it’s not a problem if they cannot be started. Furthermore, both occur in rescue.service and emergency.service, respectively, so I think something else is failing before that. Can you reproduce this with the kernel parameter systemd.log_level=debug and then attach the entire journalctl -xb output please? -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733863: dlocate totally not prepared for :i386 etc. suffixes
Package: dlocate Version: 1.02+nmu3 Severity: important # update-dlocatedb # dpkg -L libkml-dev|wc 372 372 17445 # dlocate -L libkml-dev|wc Package libkml-dev not installed or libkml-dev.list is empty. 0 0 0 Well at least it could say try adding :i386. # dpkg -L libkml-dev:i386|wc 372 372 17445 # dpkg -L libkml-dev|wc 372 372 17445 works fine either way. When I installed the package, aptitude didn't make me type :i386. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733864: perhaps say which ../*.list is empty
Package: dlocate Version: 1.02+nmu3 Severity: minor # dlocate -L xxx Package xxx not installed or xxx.list is empty. Even though the man page mentions it, I would still say Package xxx not installed or /var/lib/dpkg/info/xxx.list is empty. so users know exactly what you are talking about. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692108: python-pip: --ignore-installed option is ignored
Control: tag + fixed-upstream
On Sun, Jun 02, 2013 at 01:21:53AM +0200, Stefano Rivera wrote:
Control: tag -1 upstream
Hi Joerg (2012.11.02_11:58:16_+0200)
pip install --install-option=--prefix=${HOME}/.mypython27
--ignore-installed module name
Since 1.3, this should be possible, using --user instead of setting a
prefix. While this doesn't solve your specific problem, it should allow
you to install a newer version of a system package, locally.
See https://github.com/pypa/pip/pull/705
Sorry for the late answer, yep, --user works (and has been working since 1.3).
Following up on this bug, I even noticed, that if one first does a --user
install even my above commandline works again, since it then tries to uninstall
the installation in .local but not in /usr
I'm not going to close this bug in the 1.3.1 upload, as this specific
issue isn't dealt with. I recommend filing it upstream.
Even with me forgetting about the bug it has been filed upstream (
https://github.com/pypa/pip/issues/991 )
an recently fixed (see this pull request https://github.com/pypa/pip/pull/1352 )
I just built pip 1.5rc4 and found that the bug is indeed fixed, so when pip 1.5
is released I would hope for it to quickly move to the Debian repos.
best regards,
Joerg
pgpFwsk0YJh5W.pgp
Description: PGP signature
Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
On Wed, 2014-01-01 at 14:00 +, Ximin Luo wrote: Package: wnpp Severity: wishlist Owner: Ximin Luo infini...@gmx.com * Package name: pond Version : 0:git~2014-01-01 Upstream Author : Adam Langley a...@imperialviolet.org * URL : https://pond.imperialviolet.org/ * License : BSD Programming Lang: Go Description : Forward secure, asynchronous messaging for the discerning. [...] Is it really a good idea to package this yet, considering the home page says Dear God, please don't use Pond for anything real yet. Maybe upload to experimental only? Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Bug#733865: xen-utils-4.3: qemu-dm is not executable: No such file or directory
Package: xen-utils-4.3 Version: 4.3.0-3+b1 Severity: normal When I try to create an HVW withDevian/xen, I run into trouble. It used to work, maybe with xen 4.1, but it has never worked since. Bug 688311 was filed, with the same exact problem. That bug was somehow closed and no resolution or explanation was provided. I have seen posts mentioning traditional and upstream qemu-dm. But it is not clear to me what the difference is between traditional and upstream, or how to select either one. My config file (snaptest.cfg) is nearly identical to the one provided by the distribution in /etc/xen/xlexample.hvm. I don't know if there are missing files in the distibution. Or if I am missing an important package. Or maybe I'm doing something wrong- and the documentation is inaccurate. Is it possible to do HVM with Debian? Thanks, Marc # xl create snaptest.cfg Parsing config from snaptest.cfg xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader:0010-001a0164 Modules: - TOTAL: -ff80 ENTRY ADDRESS: 00100608 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0200 2MB PAGES: 0x05fb 1GB PAGES: 0x0001 libxl: error: libxl_dm.c:1142:libxl__spawn_local_dm: device model /usr/lib/xen-4.3/bin/qemu-dm is not executable: No such file or directory libxl: error: libxl_dm.c:1275:device_model_spawn_outcome: (null): spawn failed (rc=-3) libxl: error: libxl_create.c:1075:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1300:libxl__destroy_device_model: could not find device-model's pid for dom 2 libxl: error: libxl.c:1408:libxl__destroy_domid: libxl__destroy_device_model failed for 2 Exit 3 # cat snaptest.cfg builder='hvm' name = example.hvm memory = 4096 vcpus = 2 disk = [ 'phy:/dev/vg0/snap,hda,w' ] -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-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 xen-utils-4.3 depends on: ii e2fslibs 1.42.8-1 ii libc6 2.17-97 ii libncurses5 5.9+20130608-1 ii libtinfo5 5.9+20130608-1 ii libxen-4.34.3.0-3+b1 ii libxenstore3.04.3.0-3+b1 ii libyajl2 2.0.4-4 ii python2.7 2.7.6-3 pn python:anynone ii xen-utils-common 4.3.0-3 Versions of packages xen-utils-4.3 recommends: ii bridge-utils 1.5-7 ii qemu-system-x861.7.0+dfsg-2 ii xen-hypervisor-4.3-amd64 [xen-hypervisor-4.3] 4.3.0-3+b1 xen-utils-4.3 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#733866: nyancat-server: drop reconf-inetd dependency
Package: nyancat-server Version: 1.2.2-1 Severity: normal Hi, I plan to remove reconf-inetd from the Debian archive, since jessie will most likely be released with a modern init system which makes inetd even more irrelevant (and thus reconf-inetd not a worthwhile project). Please drop nyncat-server's dependency on reconf-inetd (eg. by switching back to update-inetd). Thanks for giving a try to reconf-inetd and apologies for the wasted time in doing so. Thanks, Serafeim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733867: [INTL:es] Spanish debconf template translation for bilibop
Package: bilibop Version: 0.4.20 Severity: wishlist Tags: l10n patch Greetings, -- Camaleón # bilibop po-debconf translation to Spanish # Copyright (C) 2013 Software in the Public Interest # This file is distributed under the same license as the bilibop package. # Changes: # - Initial translation # Camaleón noela...@gmail.com, 2010, 2013. # - Updates # Traductores, si no conocen el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/ # especialmente las notas y normas de traducción en # http://www.debian.org/intl/spanish/notas # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans msgid msgstr Project-Id-Version: bilibop 0.4.20\n Report-Msgid-Bugs-To: quid...@poivron.org\n POT-Creation-Date: 2013-11-23 10:14+\n PO-Revision-Date: 2013-12-21 13:50+0200\n Last-Translator: Camaleón noela...@gmail.com\n Language-Team: Debian Spanish debian-l10n-span...@lists.debian.org\n Language: es\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=2; plural=(n != 1);\n X-Generator: Virtaal 0.7.1\n #. Type: boolean #. Description #: ../bilibop-rules.templates:1001 msgid Do you intend to install bilibop-rules on a Live System ? msgstr ¿Va a instalar bilibop-rules en un sistema «Live»? #. Type: boolean #. Description #: ../bilibop-rules.templates:1001 msgid Some bilibop-rules settings can be useful on non-volatile Operating Systems, when running from a removable and writable media (USB sticks, external HDD or SD cards); but they are currently useless or even harmful for LiveCD or LiveUSB systems. msgstr Algunos de los ajustes de bilibop-rules pueden resultar útiles en sistemas operativos persistentes cuando se ejecutan desde un dispositivo removible y grabable (llaves USB, discos duros externos o tarjetas SD) pero resultan completamente inútiles o incluso perjudiciales en sistemas LiveCD o LiveUSB. #. Type: boolean #. Description #: ../bilibop-rules.templates:1001 msgid If you choose this option, no other question will be asked; bilibop udev rules will be applied but nothing else will be modified on your system. Note that in that case, this package is overkill and you should probably replace it by the lighter but as much as efficient bilibop-udev package. msgstr Si elige esta opción no se le harán más preguntas, se aplicarán las reglas udev de bilibop pero no se modificará nada más en su sistema. Tenga en cuenta que en este caso este paquete resulta excesivo y probablemente debería reemplazarlo por otro más ligero pero igual de eficiente como el paquete bilibop-udev. #. Type: boolean #. Description #: ../bilibop-rules.templates:2001 msgid Do you want to use custom bilibop rules and build them now ? msgstr ¿Desea utilizar reglas bilibop personalizadas y construirlas ahora? #. Type: boolean #. Description #: ../bilibop-rules.templates:2001 msgid If tens of removable media are plugged on the computer your system boots from, bilibop udev rules can significantly increase boot time. This can be avoided by using custom udev rules, which are specific to the device your system is installed on. msgstr Si tiene conectados varios dispositivos removibles en el equipo desde donde inicia el sistema, las reglas udev de bilibop pueden incrementar significativamente el tiempo de inicio. Para evitar esto puede utilizar reglas udev personalizadas que son específicas para el dispositivo donde se encuentra instalado el sistema. #. Type: boolean #. Description #: ../bilibop-rules.templates:2001 msgid That said, if this device can boot from different hardware port types (as USB/Firewire, USB/eSATA, USB/MMC/SD, etc.), you should check the resulting rules by booting your system on the alternative port type, and if necessary by running 'dpkg-reconfigure bilibop-rules' again with proper options, or even by editing '/etc/udev/rules.d/66-bilibop.rules'. msgstr Dicho eso, si el dispositivo puede iniciarse desde distintos tipos de puerto (como USB/Firewire, USB/eSATA, USB/MMC/SD, etc.) debería comprobar las reglas generadas e iniciar el sistema desde uno de los tipos de puerto alternativos y si fuera necesario, ejecutar «dpkg-reconfigure bilibop-rules» de nuevo con las opciones adecuadas o incluso editar el archivo «/etc/udev/rules.d/66-bilibop.rules». #. Type: select #. Choices #: ../bilibop-rules.templates:3001 msgid keep existing custom rules msgstr mantener las reglas personalizadas existentes #. Type: select #. Choices #: ../bilibop-rules.templates:3001 msgid rebuild custom rules msgstr reconstruir las
Bug#714364: 8.0.5 almost done
Quick update: After a long time the 8.x packaging is almost done. The only thing left to do is to figure out the reason for a schedd segfault. Once this is fixed I will upload. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733868: nmu: Rebuild with newer gem2deb for Ruby2.0 support
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, please schedule binNMUs for these packages: nmu ruby-http-parser.rb_0.6.0~beta.2-1 . amd64 . -m Rebuild with newer gem2deb for Ruby2.0 support nmu ruby-kyotocabinet_1.32-1 . ALL . -m Rebuild with newer gem2deb for Ruby2.0 support nmu ruby-levenshtein_0.2.2-1 . ALL . -m Rebuild with newer gem2deb for Ruby2.0 support nmu ruby-rinku_1.7.3-1 . ALL . -m Rebuild with newer gem2deb for Ruby2.0 support nmu ruby-sequel-pg_1.6.8-1 . ALL . -m Rebuild with newer gem2deb for Ruby2.0 support nmu ruby-dataobjects-mysql_0.10.13-1 . ALL . -m Rebuild with newer gem2deb for Ruby2.0 support nmu ruby-dataobjects-postgres_0.10.13-1 . ALL . -m Rebuild with newer gem2deb for Ruby2.0 support nmu ruby-dataobjects-sqlite3_0.10.13-1 . ALL . -m Rebuild with newer gem2deb for Ruby2.0 support nmu ruby-blockenspiel_0.4.5-1 . amd64 i386 kfreebsd-amd64 kfreebsd-i386 powerpc s390x sparc . -m Rebuild with newer gem2deb for Ruby2.0 support Thank you, Christian -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- signature.asc Description: Digital signature
Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
On 01/01/14 15:26, Ben Hutchings wrote: On Wed, 2014-01-01 at 14:00 +, Ximin Luo wrote: Package: wnpp Severity: wishlist Owner: Ximin Luo infini...@gmx.com * Package name: pond Version : 0:git~2014-01-01 Upstream Author : Adam Langley a...@imperialviolet.org * URL : https://pond.imperialviolet.org/ * License : BSD Programming Lang: Go Description : Forward secure, asynchronous messaging for the discerning. [...] Is it really a good idea to package this yet, considering the home page says Dear God, please don't use Pond for anything real yet. Maybe upload to experimental only? Ben. That blog post is from quite a while ago, but I see your point. I'll contact upstream to see what his advice is, and only upload to experimental in the meantime. -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature
Bug#733869: python-stdnum: FTBFS: tries to access internet
Source: python-stdnum
Version: 0.9-1
Severity: serious
Justification: fails to build from source
Dear Maintainer,
Your package fails to build from source on machines which
do not have internet connection.
--8--
running build_ext
Searching for distribute
Reading https://pypi.python.org/simple/distribute/
Download error on https://pypi.python.org/simple/distribute/: [Errno -2] Name
or service not known -- Some packages may not be found!
Couldn't find index page for 'distribute' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
Download error on https://pypi.python.org/simple/: [Errno -2] Name or service
not known -- Some packages may not be found!
No local packages or download links found for distribute
error: Could not find suitable distribution for Requirement.parse('distribute')
make[1]: *** [override_dh_auto_test] Error 1
--8--
--
Dmitry Shachnev
signature.asc
Description: OpenPGP digital signature
Bug#733870: pymia: FTBFS with multiple supported python3 versions
Source: pymia Version: 0.1.5-1 Severity: important Tags: patch Dear Maintainer, In current Debian experimental (where python3.4 is a supported version), pymia FTBFS: i686-linux-gnu-gcc -pthread -g -O0 -Wall -Wstrict-prototypes -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/sigc++-2.0 -I/usr/lib/i386-linux-gnu/mia-2.0/include -I/usr/lib/libxml++-2.6/include -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/lib/i386-linux-gnu/glibmm-2.4/include -I/usr//usr/lib/i386-linux-gnu/mia-2.0/include -I/usr/include/mia-2.0 -I/usr/include/glibmm-2.4 -I/usr/lib/i386-linux-gnu/sigc++-2.0/include -I/usr/include/libxml++-2.6 -I/usr/include/glib-2.0 -I/usr/include/libxml2 -I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.4dm -c src/mia_python.cc -o build/temp.linux-i686-3.4-pydebug/src/mia_python.o -std=c++0x cc1plus: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++ [enabled by default] src/mia_python.cc:21:20: fatal error: Python.h: No such file or directory #include Python.h ^ compilation terminated. error: command 'i686-linux-gnu-gcc' failed with exit status 1 Build-depending on python3-all-dev fixes that: --- a/debian/control +++ b/debian/control @@ -4,9 +4,9 @@ Section: science Priority: optional Build-Depends: debhelper (= 9), - python-dev, + python-all-dev, python-all-dbg, - python3-dev, + python3-all-dev, python3-all-dbg, python-numpy-dbg, python3-numpy-dbg , -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Bug#733871: openchange: add debug package to ship debugging symbols
Source: openchange
Version: 2.0-2
Severity: wishlist
Tags: patch
Hey there,
please add a -dbg package to allow better debugging of errors.
See the attached patch with changes I've done for local testing.
Cheers
Markus
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-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
--- openchange-2.0/debian/rules 2013-10-22 16:27:30.0 +0200
+++ openchange/debian/rules 2014-01-01 17:36:33.693426651 +0100
@@ -60,5 +60,9 @@
override_dh_install:
dh_install --sourcedir=debian/tmp --list-missing --fail-missing
+.PHONY: override_dh_strip
+override_dh_strip:
+ dh_strip --dbg-package=openchange-dbg
+
get-orig-source:
./debian/build-orig.sh
--- openchange-2.0/debian/control 2013-10-22 16:27:30.0 +0200
+++ openchange/debian/control 2014-01-01 17:39:50.512386460 +0100
@@ -204,3 +204,12 @@
Library that can store arbitrary MAPI objects.
.
This package contains the development files.
+
+Package: openchange-dbg
+Section: debug
+Architecture: any
+Depends: libmapi0 (= ${binary:Version}), ${misc:Depends}
+Description: Experimental MAPI (Exchange/Outlook) library - debug symbols
+ Library and server tools for the MAPI protocol.
+ .
+ This package contains debugging symbols.
Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
On Wed, Jan 01, 2014 at 12:30:16PM +0100, Michael Schaller wrote: A few comments on the patches: Thanks for your review and the points you raised. 1) tests/test_pep8.py Can you document in a comment or docstring why you ignore certain issues and what these issues are? This should help readers to better understand what the test does and more importantly what it ignores. Furthermore do you plan to reduce the number of ignores in the future? If so you should add a TODO for yourself. 2) tests/test_pep8.py Can you use instead of 'self.assertEqual(res, 0)' a better fail message like you did in 'tests/test_pyflakes.py'? 3) tests/test_pyflakes.py You don't need the 'from __future__ import print_function' import with Python 3. Those are fixed in my git branch now, thanks! 4) debian/control (nitpick) I prefer to sort dependencies alphabetically. I have no opinion about this :) I don't really mind either way. 5) .travis.yml I would really like to see a rather lengthy comment in the beginning of the YAML file to explain what purpose it serves and what it does. I also think you should give a link here and that you should explain what should happen after Trusty. Maybe it would be even better to use SID instead of Trusty. 6) .travis.yml Why do you run './debian/rules binary' and not 'dpkg-buildpackage'? 7) .travis.yml Why not also ensure here that Lintian and if possible piuparts have no issues with the newly built package? Good points, I added a explaination to the top now that hopefully addresses the points. I renamed the added sources.list entry as its misleading. In my branch its using distro-info --stable to get test latest python3.3 and apt/libapt. Using sid here is probably a bit too fragile, the chroots of the travis-ci.org are ubuntu based. But I would certainly love to see a travis-ci instance that is debian based. I changed the debian/rules binary in my branch now to be ./debian/rules build-arch. This will build and run the tests. We can't use dpkg-buildpackage currently as its using fakeroot and the tests (iirc in the test_auth.py code) also use fakeroot and nesting is not possible AFAIK. But I do like the idea of building the deb and doing additional checks like lintian/piuparts. Cheers and happy new year! Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733872: libmapi0: SIGSEV when Exchange server is not reachable or network connections change
Package: libmapi0 Version: 1:2.0-2 Severity: important Tags: upstream Hey there, I noticed a SIGSEV problem while using evolution-mapi with my companies Exchange server. When the server is not reachable or the network connections change, it might happen that libmapi SIGSEVs. Here is a stacktrace from gdb (please not that I've recompiled the package to provide debug symbols. --snip-- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff967fc700 (LWP 30249)] load_interfaces (mem_ctx=0x64, interfaces=0x2, local_interfaces=0x0) at libmapi/socket/interface.c:197 197 *local_interfaces = NULL; (gdb) bt #0 load_interfaces (mem_ctx=0x64, interfaces=0x2, local_interfaces=0x0) at libmapi/socket/interface.c:197 #1 0x7fff28162379 in _nss_wins_gethostbyname_r () from /lib/x86_64-linux-gnu/libnss_wins.so.2 #2 0x73ae5255 in gaih_inet (name=name@entry=0x565f09d0 srv-mail.int.netways.de, service=optimized out, req=req@entry=0x74674500, pai=pai@entry=0x7fff967fb990, naddrs=naddrs@entry=0x7fff967fb988) at ../sysdeps/posix/getaddrinfo.c:959 #3 0x73ae7a14 in __GI_getaddrinfo (name=0x565f09d0 exchange.company.de, service=optimized out, hints=0x74674500, pai=0x7fff967fbb08) at ../sysdeps/posix/getaddrinfo.c:2473 #4 0x74395813 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #5 0x74393045 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #6 0x73e38b96 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0x73e381d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x77349e0e in start_thread (arg=0x7fff967fc700) at pthread_create.c:311 #9 0x73b090fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 --snip-- The segfault also occurs on other mail servers, e.g. my private IMAP server, when that name is resolved. Please tell me if I can supply any other information. I'm not sure how that nss resolving stuff works. Cheers Markus -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-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 Versions of packages libmapi0 depends on: ii libc6 2.17-97 ii libldb11:1.1.16-1 ii libtalloc2 2.1.0-1 ii libtevent0 0.9.19-1 ii multiarch-support 2.17-97 ii samba-libs 2:4.0.13+dfsg-1 libmapi0 recommends no packages. libmapi0 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#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
On Tue, Dec 31, 2013 at 11:04:47PM +0100, Julian Andres Klode wrote: (Addressed to Michael Vogt, so don't wonder, other Michael...) [..] I thought we wanted to use git-dch now (meaning after I released 0.9.1) for changelog manipulation. I did commit 56ed099558a9f6e7137a8c113ca9efb2b2c1a1d2 without a changelog entry for that reason, but I see that you did the commit afterwards with a changelog entry. Indeed, sorry for this, I'm not used to this yet, but I agree that its a good idea and we should stick with git-dch. It would also be cooler to have some more useful summary lines in your commits. The last one just had * apt/cache.py:. If you use debcommit, you can use debcommit -e to adjust the summary. Again agreed, I was using debcommit and will be more carefull about this in the future. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: loose ends for init system decision
On 30 Dec 2013, at 18:47, Russ Allbery r...@debian.org wrote: However, I think it's the best available approach that balances our ideals as a project against the opportunities offered by a new init system. This approach does permit full use of new init system features for jessie except for eliminating /etc/default files (which I doubt we'd successfully do quickly anyway), and opens up the full spectrum of use cases after jessie. The cost is that packagers should merge contributed patches to the init systems that they don't use. I don't think this is too much to ask, nor do I think it will have serious effects on package complexity based on my own experience configuring a package to work under all three init systems I considered. I’m no longer a RM, but I would echo Russ’ comments here - an ordered transition is very important for Debian releases - and the size of this transition would be something that (in my opinion) would be very hard to achieve in one release cycle. Neil -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system thoughts
Hi, Colin Watson cjwat...@debian.org writes: Reservations with systemd - [...] Basically, systemd would be more compelling to me if it tried to do less. I don't expect to persuade systemd advocates of this, as I think it amounts to different basic views of the world, but the basic approach here is probably the single biggest factor influencing my position. On the other hand even when using upstart as an init replacement, we'll continue to use large chunks of systemd (logind, other dbus services). I personally think less is more would only be a convincing argument if we actually would not need the aditional features. I also have one question: your mail doesn't mention the integration problems with logind into a system that uses upstart and not systemd as init. Do you think this will not be an issue? Given it means ongoing work instead of a one-time investment, this is one of my main gripes with upstart. I feel that minor technical differences between the init replacements are not work committing to long-time maintaince of a systemd-logind branch that works outside of systemd. There are more interesting areas we can invest our resources into. Note that this might also include session management functions in the future. As you mentioned yourself in [1], DEs are looking into using advanced session supervision. So far both kwin and GNOME seem to target systemd for this. So this would be another area that we would need to invest resources into to maintain an upstart replacement. [1] https://lists.debian.org/debian-ctte/2014/01/msg00017.html Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730760: perl-base: IO::Socket::INET cannot cope with option inet6 in /etc/resolv.conf
Control: severity -1 normal On Fri, Nov 29, 2013 at 10:13:07AM +, Bob Ham wrote: When setting option inet6 in /etc/resolv.conf, IO::Socket::INET cannot connect properly, particularly to popcon.debian.org: $ perl -MIO::Socket::INET -e 'IO::Socket::INET-new(popcon.debian.org:80) or die $@;' IO::Socket::INET: Bad hostname 'popcon.debian.org:80' at -e line 1. When commenting out option inet6, it works fine: $ perl -MIO::Socket::INET -e 'IO::Socket::INET-new(popcon.debian.org:80) or die $@;' $ I agree that this is a problem, but I'm not sure whether it's a reasonable expectation for ipv4-only software to work with this option being set; the manpage for resolv.conf does mention that breakage is to be expected. A more pragmatic solution might be to use IO::Socket::IP instead. Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698884: ircd-hybrid version 8 should be a separate package
On Fri, Nov 15, 2013 at 04:15:41PM +0100, Guus Sliepen wrote: On Sun, 27 Jan 2013 11:47:09 +, Dominic Hargreaves wrote: Can i recommend/request making ircd-hybrid 8 a separate package (such as ircd-hybrid8)? Given that apparently version 7 and version 8 servers are incompatible when peering. Only where cryptlinks are in use. Not so, I just upgraded one IRC daemon to version 8, and when connecting to another server I get this message: 16:03 Meuk-sliepen.org- *** Notice -- Connection to irc.uvt.nl[fec0::32:202:a5ff:feaa:f4b7] activated. 16:03 Meuk-sliepen.org- *** Notice -- Link with irc.uvt.nl[unknown@255.255.255.255] established: (Capabilities: TS KNOCK UNKLN KLN ENCAP TBURST GLN CHW IE EX HOPS CLUSTER EOB QS) 16:03 Meuk-sliepen.org- *** Notice -- Dropping server irc.uvt.nl due to (invalid) command 'TBURST' with only 5 arguments (expecting 6). If it isn't backwards compatible, I agree with Mark that the should've been renamed. I am pretty sure that when I tested this, I was able to link a Hybrid-7 server to a Hybrid-8 server. However I don't have that test infrastructure about any more: my production Hybrid-7 servers use cryptlinks, which *is* known to be incompatible (see #714573). What software version is/was irc.uvt.nl running? I'm not sure that this issue, if confirmed, is sufficient to give the new server package a new name, since Hybrid-7 is no longer maintained upstream; but I'm willing to be persuaded otherwise. Cheers, Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711929: openarena: Became slower w/ the version.
What graphics hardware is this on? Does this go away if you downgrade ioquake3 to an earlier version? yes, framerate is at least twice faster using the 1.36+svn2287-2 version Does this go away if you downgrade Mesa to an earlier version? What about other related packages (e.g. libdrm*)? with the successive upgrades of mesa or drm of the last six months, it didn't change the previous answer. Are you running OpenArena full-screen or windowed? What resolution? Full screen, 2560x1440 If you run it from a terminal, do you get any warnings or other interesting output? Please see the attached diff. oa is launched, menu is shown, then i quit. The fact it's going to be slow is visible immediately even before the openarena menu is shown (during the splash screen animation, it's already slow). What graphics settings do you have? In particular, are flares enabled (#711519)? Changing the flares/bloom settings has no obvious impact on performance now. Changing other settings (bilinear/trilinear, texture details) has some impact on both versions, as expected (but the 2x difference in framerate doesn't change). Using a rebuilt ioquake3 package doesn't change anything (just saying). Jérémy. 1c1 ioq3 1.36+svn2287-2/Debian linux-x86_64 Oct 13 2013 --- ioq3 1.36+u20130504+g42eeb75-2/Debian linux-x86_64 May 19 2013 69a70 Initializing Shaders 74c75,76 GL_EXTENSIONS: GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_polygon_offset GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_depth_clamp GL_NV_fog_distance GL_APPLE_packed_pixels GL_APPLE_vertex_array_object GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_MESA_pack_invert GL_NV_primitive_restart GL_ARB_depth_clamp GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_shading_language_100 GL_ARB_sync GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate GL_OES_read_format GL_ARB_color_buffer_float GL_ARB_pixel_buffer_object GL_ARB_texture_compression_rgtc GL_ARB_texture_float GL_ARB_texture_rectangle GL_ATI_texture_compression_3dc GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_mirror_clamp GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_ARB_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_packed_depth_stencil GL_ARB_vertex_array_object GL_ATI_separate_stencil GL_ATI_texture_mirror_once GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_gpu_program_parameters GL_EXT_texture_array GL_EXT_texture_compression_latc GL_EXT_texture_integer GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_OES_EGL_image GL_MESA_texture_array GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_draw_instanced GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_map_buffer_range GL_ARB_texture_rg GL_ARB_texture_swizzle GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle GL_EXT_vertex_array_bgra GL_NV_conditional_render GL_AMD_conservative_depth GL_AMD_draw_buffers_blend GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_stencil_export GL_ARB_ES2_compatibility GL_ARB_blend_func_extended GL_ARB_debug_output GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_explicit_attrib_location
Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
Hi, I think it's important to add also the paragraph about actual usability for the homepage: Dear God, please don't use Pond for anything real yet. I've hammered out nearly 20K lines of code that have never been reviewed. Unless you're looking to experiment you should go use something that actually works (e.g. GnuPG).[0] I general I'd ask if it's not better to wait for code reviews before packaging it. Best, Philip [0] https://pond.imperialviolet.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732578: Issue after conversion of AppArmor package to dh(1) and Multi-Arch
Hi, intrigeri wrote (27 Dec 2013 00:49:09 GMT) : https://buildd.debian.org/status/fetch.php?pkg=apparmorarch=i386ver=2.8.0-4stamp=1388104085 says libapparmor-perl still lacks /usr/lib/perl5/LibAppArmor.pm. I can reproduce this by building -4 with pbuilder + a sid/i386 chroot and a sid/amd64 one. But I cannot reproduce this by building -4 manually with dpkg-buildpackage in a sid/amd64 chroot. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system thoughts
On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote: Colin Watson cjwat...@debian.org writes: Reservations with systemd - [...] Basically, systemd would be more compelling to me if it tried to do less. I don't expect to persuade systemd advocates of this, as I think it amounts to different basic views of the world, but the basic approach here is probably the single biggest factor influencing my position. On the other hand even when using upstart as an init replacement, we'll continue to use large chunks of systemd (logind, other dbus services). I personally think less is more would only be a convincing argument if we actually would not need the aditional features. I'm referring to features that I don't think we'll need, not to logind et al. So far I feel that the debates about those seem to be a bit circular and go something like this: A: This feature of systemd conflicts with something else; I'd rather we didn't use it. B: You can disable that, you know. A: OK, let's disable it. B: But you shouldn't disable it because that would make Debian systemd less compatible with systemd on other distributions. A: ... I also have one question: your mail doesn't mention the integration problems with logind into a system that uses upstart and not systemd as init. Do you think this will not be an issue? I think the amount of time spent arguing about it has already exceeded the total amount of effort it would ever take. That said, I rather suspect that it was a tactical error for Upstart people to choose to use the logind code from systemd, even though that involved less reimplementation of wheels. In the long term it would probably be better to write an independent implementation of the same interfaces or fork the existing code to a different source package, partly because that would help to dispose of the idea that Upstart is really dependent on systemd anyway, and partly because it would be friendlier to the Debian systemd maintainers. No doubt that could still be done. It's unfortunate that it's not one of the components listed as Reimplementable Independently, but I guess that just means more manual effort to keep track of the interface; and this would move the grunt work from the shoulders of the Debian systemd maintainers to those of the Upstart maintainers, which is probably the right place for it to lie. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733761: plymouth errors out during start-up
On Wed, Jan 01, 2014 at 01:51:36PM +0100, Daniel Baumann wrote: 'versioned closed' aka version tracking in the bts means, that the bug is marked as open for wheezy (or any distribution not shipping the version for which the bug has been marked as closed with), but is marked as closed for jessie/sid (or any distribution that is shipping the version or any newer version for which the bug has been marked as closed with). this is standard procedure in the debian bug tracking system. Do you intend to fix it in Wheezy, or will this be like LXC, where someone else has to take on your work? -- Mason Loring Bliss (( In the drowsy dark cave of the mind dreams ma...@blisses.org )) build their nest with fragments dropped http://blisses.org/ (( from day's caravan. - Rabindranath Tagore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733873: [pyneighborhood] should depend on gnome-keyring
Package: pyneighborhood Version: 0.5.1-2 Severity: normal If gnome-keyring is not installed pyneighborhood displays the error message Gkr-Message: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files when trying to add a mount point. Thanks! C. --- System information. --- Architecture: amd64 Kernel: Linux 3.11-2-amd64 Debian Release: jessie/sid 990 stable security.debian.org 990 stable ftp.egr.msu.edu 99 testing security.debian.org 99 testing debian.cites.illinois.edu 98 stable debian.dc-uoit.net 49 experimentaldebian.cites.illinois.edu 30 oneiric us.archive.ubuntu.com --- Package information. --- Depends (Version) | Installed ===-+-== python2.7 | 2.7.5-5 OR python2.6 | 2.6.8-2 python(= 2.6.6-7~) | 2.7.5-2 python ( 2.8) | 2.7.5-2 cifs-utils | 2:6.0-1 smbclient | 2:3.6.17-1 python-gtk2 | 2.24.0-3+b1 python-glade2 | 2.24.0-3+b1 Package's Recommends field is empty. Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732227: Bug#732235: brutalchess bugs #732235 and #732227
Hi Markus, Markus Koschany a...@gambaru.de writes: I'm attaching a debdiff with the latest changes of brutalchess that fixes the FTBFS and the broken -p option. Unfortunately the only way to fix the latter is to disable the quake option because those models were never shipped by upstream. The changes are also available in the team's svn repository. Thanks for fixing these two bugs. Would it be fine for you if I upload the current version in svn with just the changelog timestamp updated ? Thanks, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732227: Bug#732235: brutalchess bugs #732235 and #732227
Hi Vincent, On 01.01.2014 18:22, Vincent Legout wrote: Hi Markus, Markus Koschany a...@gambaru.de writes: I'm attaching a debdiff with the latest changes of brutalchess that fixes the FTBFS and the broken -p option. Unfortunately the only way to fix the latter is to disable the quake option because those models were never shipped by upstream. The changes are also available in the team's svn repository. Thanks for fixing these two bugs. Would it be fine for you if I upload the current version in svn with just the changelog timestamp updated ? Sure. Please go ahead! Thank you, Markus signature.asc Description: OpenPGP digital signature
Bug#733490: RM: unicon -- RoQA; orphaned, unused, dead upstream
Control: tag -1 moreinfo Moritz Muehlenhoff j...@debian.org writes: please remove unicon. It's orphaned for more than a year, dead upstream and popcon is very low. It's also affected by several of the bugs found by the Mayhem project. The package still has a reverse dependency: # Broken Depends: zhcon: zhcon [...] # Broken Build-Depends: zhcon: unicon-imc2 Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733874: python-owncloud doesn't works with resent versions of libocsync = 0.91.0
Package: python-owncloud Version: 0.3.1-1 Severity: grave Tags: upstream Justification: renders package unusable Forwarded: https://github.com/csawyerYumaed/pyOwnCloud/issues/61 Control: tag 733435 -pending python-owncloud is not able to use ocsync version 0.91.0. But ocsync = 0.91.0 is needed for the owncloud-client. So this package is broken till it is fixed upstream. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-6.towo-siduction-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-owncloud depends on: ii libocsync0 [libocsync-plugin-owncloud] 0.91.4-1 ii python 2.7.5-5 ii python-pkg-resources2.0.1-2 python-owncloud recommends no packages. Versions of packages python-owncloud suggests: ii python-keyring 3.3-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system other points, and conclusion
On Wed, Jan 1, 2014 at 4:56 AM, Colin Watson cjwat...@debian.org wrote: On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote: On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson cjwat...@debian.org inotify is used to notice changes to configuration files. This is certainly helpful for users, but it isn't critical as initctl reload-configuration works without it. We could probably do without this with the aid of a dpkg trigger. inotify use can easily be ported to kqueue within Upstart, or libinotify-kqueue can be used. Note that I'm talking about the Hurd here. kqueue is a kFreeBSD thing, as far as I know. (Compare e.g. https://lists.debian.org/debian-hurd/2013/10/msg00021.html) prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work properly when Upstart is supervising a user session. This isn't a required feature and could easily be compiled out until suitable kernel support is available (this actually seems like the sort of thing that could be done in the Hurd without too much difficulty, but I haven't looked into it). If absent, it might well impede the ability to do an advanced desktop port, but it wouldn't get in the way of porting the bulk of services. Unity, likely the only desktop environment using Upstart as a session init, is not in Debian. The sacrifice of this functionality on non-linux systems is perfectly acceptable. While this is true today, we need to look to the future. Using Upstart as a session init is not conceptually tied to Unity in any way, and I expect that other desktop environments will want to use more advanced session supervision soon enough. I place less importance on the session init capabilities of Upstart, as alternative home grown solutions ww.ritten by the environments are in place and are portable. Furthermore, portability of these environments hinges on a session and seat manager, ConsoleKit support in GNOME is quickly disappearing, and ConsoleKit itself is completely abandoned. What this means, to me, is there is a lot more effort required to accomplish this than to port Upstart's session init capabilities or use the current portable session inits. Sincerely, Cameron Norman -- Colin Watson [cjwat...@debian.org]
Bug#733705: RM: automake1.4 -- ROM; old, obsolete automake package
Control: tag -1 moreinfo Eric Dorland e...@debian.org writes: There are only two remaining packages build depending on automake1.4 and they both have patches (see http://bugs.debian.org/724002 and http://bugs.debian.org/724010). Once it's removed I'll upgrade the severity of these bugs and upload delayed NMU uploads. There is a third package build-depending on automake1.4: gcc-3.3. I also think it's better to fix the packages before removing the automake1.4 package. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711929: openarena: Became slower w/ the version.
Hi again,
i've pulled and rebuilt from upstream version bc2efc4, and there is no
performance problem with it.
Please find attached the refreshed quilt patches, and a small fix
to debian/*docs, so you can update easily to that upstream version.
I hope this helps,
Jérémy.
From 179f09e52587e2ec1417c656c0716aca180529e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Lal?= kapo...@melix.org
Date: Wed, 1 Jan 2014 18:45:02 +0100
Subject: [PATCH 2/2] Install README.md
---
debian/ioquake3-server.docs | 2 +-
debian/ioquake3.docs| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/debian/ioquake3-server.docs b/debian/ioquake3-server.docs
index ad1c255..d4485f1 100644
--- a/debian/ioquake3-server.docs
+++ b/debian/ioquake3-server.docs
@@ -1,2 +1,2 @@
-README
+README.md
id-readme.txt
diff --git a/debian/ioquake3.docs b/debian/ioquake3.docs
index 2cae632..69000d8 100644
--- a/debian/ioquake3.docs
+++ b/debian/ioquake3.docs
@@ -1,3 +1,3 @@
-README
+README.md
voip-readme.txt
id-readme.txt
--
1.8.5.2
From 5d7159c6dd680e235f514e51e678d979b4a97dca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Lal?= kapo...@melix.org
Date: Wed, 1 Jan 2014 18:41:24 +0100
Subject: [PATCH 1/2] Refresh patches
---
...al-vmMagic-that-causes-equivalent-native-.patch | 34 +-
...start-which-can-be-set-by-game-code-to-re.patch | 18
.../patches/0007-Let-servers-set-sv_fps-too.patch | 4 +--
...-a-window-by-default-on-new-installations.patch | 12 +++-
4 files changed, 23 insertions(+), 45 deletions(-)
diff --git a/debian/patches/0001-Add-a-special-vmMagic-that-causes-equivalent-native-.patch b/debian/patches/0001-Add-a-special-vmMagic-that-causes-equivalent-native-.patch
index a442a7f..db9f75d 100644
--- a/debian/patches/0001-Add-a-special-vmMagic-that-causes-equivalent-native-.patch
+++ b/debian/patches/0001-Add-a-special-vmMagic-that-causes-equivalent-native-.patch
@@ -25,20 +25,18 @@ Forwarded: no
code/qcommon/vm.c | 57 +++-
4 files changed, 64 insertions(+), 5 deletions(-)
-diff --git a/code/qcommon/files.c b/code/qcommon/files.c
-index 5955fb1..eb53221 100644
--- a/code/qcommon/files.c
+++ b/code/qcommon/files.c
-@@ -1398,7 +1398,7 @@ Return the searchpath in startSearch.
+@@ -1399,7 +1399,7 @@
=
*/
--vmInterpret_t FS_FindVM(void **startSearch, char *found, int foundlen, const char *name, int enableDll)
-+vmInterpret_t FS_FindVM(void **startSearch, char *found, int foundlen, const char *name, int enableDll, int forceDll)
+-int FS_FindVM(void **startSearch, char *found, int foundlen, const char *name, int enableDll)
++int FS_FindVM(void **startSearch, char *found, int foundlen, const char *name, int enableDll, int forceDll)
{
searchpath_t *search, *lastSearch;
directory_t *dir;
-@@ -1422,7 +1422,7 @@ vmInterpret_t FS_FindVM(void **startSearch, char *found, int foundlen, const cha
+@@ -1423,7 +1423,7 @@
while(search)
{
@@ -47,7 +45,7 @@ index 5955fb1..eb53221 100644
{
dir = search-dir;
-@@ -1445,7 +1445,7 @@ vmInterpret_t FS_FindVM(void **startSearch, char *found, int foundlen, const cha
+@@ -1446,7 +1446,7 @@
return VMI_COMPILED;
}
}
@@ -56,24 +54,20 @@ index 5955fb1..eb53221 100644
{
pack = search-pack;
-diff --git a/code/qcommon/qcommon.h b/code/qcommon/qcommon.h
-index 349953d..047691e 100644
--- a/code/qcommon/qcommon.h
+++ b/code/qcommon/qcommon.h
-@@ -624,7 +624,7 @@ qboolean FS_FileExists( const char *file );
+@@ -624,7 +624,7 @@
qboolean FS_CreatePath (char *OSPath);
--vmInterpret_t FS_FindVM(void **startSearch, char *found, int foundlen, const char *name, int enableDll);
-+vmInterpret_t FS_FindVM(void **startSearch, char *found, int foundlen, const char *name, int enableDll, int forceDll);
+-int FS_FindVM(void **startSearch, char *found, int foundlen, const char *name, int enableDll);
++int FS_FindVM(void **startSearch, char *found, int foundlen, const char *name, int enableDll, int forceDll);
char *FS_BuildOSPath( const char *base, const char *game, const char *qpath );
qboolean FS_CompareZipChecksum(const char *zipfile);
-diff --git a/code/qcommon/qfiles.h b/code/qcommon/qfiles.h
-index 78b06da..cdfb6ae 100644
--- a/code/qcommon/qfiles.h
+++ b/code/qcommon/qfiles.h
-@@ -52,6 +52,10 @@ QVM files
+@@ -52,6 +52,10 @@
#define VM_MAGIC 0x12721444
#define VM_MAGIC_VER2 0x12721445
@@ -84,11 +78,9 @@ index 78b06da..cdfb6ae 100644
typedef struct {
int vmMagic;
-diff --git a/code/qcommon/vm.c b/code/qcommon/vm.c
-index e8818a6..f1fc425 100644
--- a/code/qcommon/vm.c
+++ b/code/qcommon/vm.c
-@@ -371,6 +371,7 @@ vmHeader_t *VM_LoadQVM( vm_t *vm, qboolean alloc, qboolean unpure)
+@@ -371,6 +371,7 @@
union {
vmHeader_t *h;
void*v;
@@ -96,7 +88,7 @@ index e8818a6..f1fc425 100644
} header;
// load the image
-@@ -391,6 +392,54 @@ vmHeader_t
Bug#733706: installation-report: installation on a Lenovo Thinkpad E431
On 2014-01-01 05:05:18, Andreas Cadhalpun wrote: On 31.12.2013 15:50, Antoine Beaupré wrote: (That resize, btw, was quite scary - I am not sure I did it right. First off it was very fast, so I suspect only the boundaries of the filesystem were changed, without telling NTFS. Then when we rebooted into Windows 7, it did a disk check which thankfully worked fine and it seems the Windows install is okay. But I can't think of doing this on an older system - it would have probably destroyed data, which is not clearly stated in partman. The resize usually is relatively fast, if the part you are removing from the filesystem does not contain any data, because then no data has to be moved and only the file system has to be updated to the new size. I think chkdsk is always scheduled after a resize of NTFS, just to be on the safe side. This should also work perfectly fine on an older system, but there it might take considerably longer, since the data is more likely to be distributed over the whole partition. Of course, one should always have backups of important data. Well, that's reassuring - I somehow thought only the partitions were resized, without telling the filesystem. Good job there! :) voice style=crooked, old manIn my days, you had to to move bits around with a magnet to resize FAT12 partitions and NTFS was satan! You kids have it t easy./voice ;) The next missing thing was wifi. I tried installing firmware-linux- nonfree, but that wasn't enough - firmware-iwlwifi was the one that was required. The installer should install the correct firmware, if you have (on some partition accessible during installation) a /firmware folder that contains the unpacked firmware bundle, which can be downloaded from [2]. But this is currently broken, see [3]. Understood. The weird thing is that the live image did find the wifi card without a problem, but it wasn't found after the install was done. Did you have a /firmware folder around? As you installed wheezy, this should have worked, because it is only broken in jessie/sid. Yes, there was a firmware folder, it only contained a .deb of linux-firmware. Oh, and I forgot to mention that I had to remove this block for Network-Manager to properly pickup the wired interface: auto eth0 iface eth0 inet dhcp Otherwise it would say wired: not managed, which is strange to me... This is bug #724928 [1], which was fixed in the Wheezy 7.2 installer. That sounds familiar! I guess I need to update my image. ;) My user was expecting the touch to click to work out of the box, and we were worried this wasn't supported, and in fact it wasn't until gnome was installed (XFCE failed to configure it properly). This is especially annoying on this laptop because the buttons are completely part of the touchpad construction, so it's actually difficult to click without moving the mouse slightly. These seem to be bugs in xfce4 and gnome respectively. You should report them there. It seems more users prefer this (see [2]) and I also do. Well, #2 is about a serious bug that makes unrelated things just not work when you enable disable touchpad while typing. It seems to me this bug should be fixed, but it is not related to enabling the touch functionality on the... touch pad. ;) Probably not related to gnome only either... But I understand this is another serious bikeshed material and fold. :) That being said, I think it really might be a good idea to install plymouth by default, as 'novices' generally prefer it, and anyone who wants to see the boot messages should have sufficient knowledge to remove it. I totally agree with that. One thing I noticed with plymouth is that even when you install it, it doesn't properly configure grub, you still have to go around the grub config and (*gasp*) edit a weird configuration file! ;) I would have expected the plymouth postinst to configure grub automagically. :) But then that's more an issue with plymouth itself than the installer. You could report this as a bug in plymouth, but it is probably not trivial to fix, because which configuration file has to be changed, depends on which boot loader is used. Actually I'm not even sure it is possible, because the boot loader may be installed after plymouth (as the installer does), or it might be changed after plymouth is installed. Yeah, this seems to be a problem larger than plymouth actually. On the top of my head, fixing this would probably involve: * triggers * a way to hook into /etc/grub.d/10_linux to add boot parameters from outside * lots more bikeshedding Unless we make plymouth a hard dependency, which would probably involve around 1500 emails on -devel, so let's pretend I didn't say anything. ;) And anyways, those are probably things to keep in mind for Jessie more than Wheezy... Except for the already fixed issue, I agree. Happy new year! A. -- Antoine Beaupré +++ Réseau Koumbit Networks
Bug#733875: broken on s390x
Package: samhain Version: 2.8.3a-1 Severity: grave Hi, samhain is broken in stable on s390x: } root@zani:~# /usr/sbin/samhain } assertion failed (x_dnmalloc.c): hashval AMOUNTHASH } Aborted It'd be great if that could be fixed in wheezy also. Cheers, weasel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system thoughts
On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote: On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote: Colin Watson cjwat...@debian.org writes: Basically, systemd would be more compelling to me if it tried to do less. I don't expect to persuade systemd advocates of this, as I think it amounts to different basic views of the world, but the basic approach here is probably the single biggest factor influencing my position. On the other hand even when using upstart as an init replacement, we'll continue to use large chunks of systemd (logind, other dbus services). I personally think less is more would only be a convincing argument if we actually would not need the aditional features. I think this counterargument, while valid, misses the major flaw in the would be more compelling if it tried to do less claim: You can simply not install any of these additional services if you don't want them. This is completely trivial to do. Using systemd as init in no way requires using them. Thus their existence cannot cause any technical problems for the use of systemd in Debian (beyond possibly needing to do the trivial disabling). If some other components that Debian does want to use start to depend on those services, such that disabling them is not easy, then this problem would exist regardless of the chosen init, and is again not a reason for favor upstart. I'm referring to features that I don't think we'll need, not to logind et al. So far I feel that the debates about those seem to be a bit circular and go something like this: A: This feature of systemd conflicts with something else; I'd rather we didn't use it. B: You can disable that, you know. A: OK, let's disable it. B: But you shouldn't disable it because that would make Debian systemd less compatible with systemd on other distributions. A: ... Here B first correctly points out that the feature can be disabled if desired, and thus the situation cannot be worse than with upstart - you can do at least as well with systemd as you could with upstart. Then you (A) have a disagreement with B about whether disabling the feature is the _best_ way to handle the situation: B thinks that gaining compatibility with other distributions is a bigger plus, and that changing to the systemd way is an actual win over current situation, rather than just neutral like the the upstart and disabling with systemd cases. There is no technical reason to prefer upstart here. Given your preferences, systemd can do at least as well (after disabling the service). Given B's preferences, systemd can do better (after enabling the service). The only benefit that choosing upstart would give you here is that it'd let you automatically win your argument with B: we already chose upstart, so enabling the systemd service is not an available choice any more. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733876: RM: ruby-prof [armel armhf ia64 mips mipsel s390x sparc] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal Dear ftpmasters, with my Ruby Extras Team hat on, I request removal of ruby-prof from these architectures, as it contains arch-specific code: armel armhf ia64 mips mipsel s390x sparc ruby-prof does not build on additional archs, but these ought to work (vs. those above which just won't work). Thank you, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733815: Modules completion takes a very long time
Another issue is that some filenames have '-' in them, but the module
names have '_' in them.
This is a problem because the modules filenames are a mess. Some
filenames have an underscore '_' too.
Does the current solution filter out
duplicates due to the modulename and filename not being the same
(i.e. '-' vs. '_')?
If you want to get
(all available mods) minus (already loaded mods)
a solution is to change hyphen '-' to underscore '_' in the filenames,
but not the opposite. This is because the output of lsmod or
/proc/modules is always with underscore.
I try this modification (and renaming) of you functions
---
function _sort_all_mods {
find /lib/modules/$(uname -r) -type f -name \*.ko|sed
's|.*/||g;s|[.]ko$||'|sort -u|tr - _
}
function _loaded_mods_regexp {
local a
a=$(awk '{print $1}' /proc/modules|sort -u|sed 's/^/^/;s/$/$/'|tr \n '|')
echo ${a%|}
}
function _newmods {
declare cur prev words cword
_get_comp_words_by_ref cur
COMPREPLY=( $(compgen -W $(_sort_all_mods|grep -E -v
$(_loaded_mods_regexp)) -- $cur ) )
}
complete -F _newmods modprobe
---
Using the functions above I get the right filtering
$ _sort_all_mods | wc -l
2542
$ _loaded_mods_regexp | tr '|' \n | wc -l
79
$ _sort_all_mods | grep -E -v $(_loaded_mods_regexp) | wc -l
2463
$ echo 2542 - 79 | bc
2463
So sounds like using a modified function based on the function
I used and your optimizations would ignore the problem of the
extra links?
Your solution works because uses command find, which ignore links
by default. I mean, find is equivalent to find -P.
Regards,
FA
Bug#733877: xfce4.10 apperance settings style is not remembered for multimonitor
Package: xfce4 Version: 4.10.1 Severity: important Dear Maintainer, I am running xfce without a login manager. e.g. I start up the system, log in and start xfce with startxfce4 my xfce is cherry picked and running on a custom xorg.conf who is set up with two nvidia graphcis cards. The center and left display are run by one graphics card while the third display is run by the other graphics card. xfce runs with three separate x screens (can't move windows between them). No xinerama enabled. When I start xfce I basically have three desktops running. On the center display everything is remembered. I can set desktop background, dpi settings and everything is remembered on the other displays as well. However the xfcemenu-settings-apperance-style settings is not remembered on the other displays. The workaround is to on the left or right display open xfcemenu-settings-apperances-style and switch between another one and the one I prefer. It now remains for the duration of the session. The following information should probably be in a separate bugreport but in case it is relevant: On the left and right display the menu is not opened close to the menubutton on first try. The menu is opened in a y position apparently relative to the resolution differnece of the mid and left/right monitor (mid: 1280x1024 - l/r:1600x1200) e.g. 176 pixels. Workaround is to just click the menubutton twice and the problem resolves itself. (I put the menu in the lower left corner). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-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 xfce4 depends on: ii gtk2-engines-xfce 3.0.1-2 ii libxfce4ui-utils 4.10.0-5 ii orage 4.10.0-1 ii thunar 1.6.3-1 ii xfce4-appfinder4.10.1-1 ii xfce4-mixer4.10.0-2 ii xfce4-panel4.10.1-1 ii xfce4-session 4.10.1-3 ii xfce4-settings 4.10.1-2 ii xfconf 4.10.0-2 ii xfdesktop4 4.10.2-3 ii xfwm4 4.10.1-2 Versions of packages xfce4 recommends: ii desktop-base 7.0.3 ii tango-icon-theme 0.8.90-5 ii thunar-volman 0.8.0-2 ii xfce4-notifyd 0.2.4-2 ii xorg 1:7.7+4 Versions of packages xfce4 suggests: pn gtk3-engines-xfcenone pn xfce4-goodiesnone pn xfce4-power-manager none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729765: fglrx-modules-dkms: fglrx module does not compile on recent x86 kernels
|reopen 729765| thanks Unfortunately, the issue is still there with fglrx 13.12. I just tested it with kernel 3.11 on an i386 system and got the following error output: DKMS make.log for fglrx-13.12 for kernel 3.11-0.bpo.2-486 (i686) Mit Jan 1 16:30:23 CET 2014 make: Entering directory `/usr/src/linux-headers-3.11-0.bpo.2-486' LD /var/lib/dkms/fglrx/13.12/build/built-in.o CC [M] /var/lib/dkms/fglrx/13.12/build/firegl_public.o /var/lib/dkms/fglrx/13.12/build/firegl_public.c:2827:13: warning: ‘kcl_flush_tlb_one’ defined but not used [-Wunused-function] CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_acpi.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_agp.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_debug.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_ioctl.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_io.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_pci.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_str.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_iommu.o /var/lib/dkms/fglrx/13.12/build/kcl_iommu.c: In function ‘KCL_IOMMU_CheckInfo’: /var/lib/dkms/fglrx/13.12/build/kcl_iommu.c:191:28: error: ‘struct dev_archdata’ has no member named ‘iommu’ make[3]: *** [/var/lib/dkms/fglrx/13.12/build/kcl_iommu.o] Fehler 1 make[2]: *** [_module_/var/lib/dkms/fglrx/13.12/build] Fehler 2 make[1]: *** [sub-make] Fehler 2 make: *** [all] Fehler 2 make: Leaving directory `/usr/src/linux-headers-3.11-0.bpo.2-486' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733878: RM: ruby-kgio [sparc] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal Dear ftpmasters, with my Ruby Extras team hat on, I request removal of ruby-kgio from sparc. ruby-kgio FTBFS (in tests) on sparc, and apparently nobody has the power to fix it. Thank you, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697019: Bug is fixed: at least for stable debian 7 kernel SMP Debian 3.2.51-1 x86_64
Bug is fixed: at least for stable debian 7, kernel SMP Debian 3.2.51-1 x86_64 Ext usb-3.0 HDD is mounted properly and it works as expected. Transfer rate shows usb-3 speed. PS uname -a output: Linux lenovo 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux lsusb output: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 003: ID 5986:0299 Acer, Inc Bus 003 Device 002: ID 0bc2:2332 Seagate RSS LLC dmesg output: [ 74.355092] hub 2-0:1.0: unable to enumerate USB device on port 2 [ 74.595165] usb 3-2: new SuperSpeed USB device number 2 using xhci_hcd [ 74.613295] usb 3-2: New USB device found, idVendor=0bc2, idProduct=2332 [ 74.613306] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 74.613312] usb 3-2: Product: Portable [ 74.613316] usb 3-2: Manufacturer: Seagate [ 74.613320] usb 3-2: SerialNumber: 2GH76WY5 [ 74.750174] Initializing USB Mass Storage driver... [ 74.750443] scsi7 : usb-storage 3-2:1.0 [ 74.750584] usbcore: registered new interface driver usb-storage [ 74.750587] USB Mass Storage support registered. [ 75.747222] scsi 7:0:0:0: Direct-Access Seagate Portable SF04 PQ: 0 ANSI: 4 [ 75.749760] sd 7:0:0:0: [sdc] 976773164 512-byte logical blocks: (500 GB/465 GiB) [ 75.750135] sd 7:0:0:0: [sdc] Write Protect is off [ 75.750143] sd 7:0:0:0: [sdc] Mode Sense: 1c 00 00 00 [ 75.750870] sd 7:0:0:0: Attached scsi generic sg2 type 0 [ 75.752304] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 75.806605] sdc: sdc1 [ 75.808055] sd 7:0:0:0: [sdc] Attached SCSI disk [ 76.429555] fuse init (API version 7.17) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733878: RM: ruby-kgio [sparc] -- ROM; FTBFS
Dear ftpmasters, I forgot to mention that unicorn depends on ruby-kgio. Please remove unicorn [sparc] as well. Thank you, Christian -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- signature.asc Description: Digital signature
Bug#733879: please remove useless build-dep on mail-transport-agent
package: libemail-send-perl version: 2.198-4 Hi, libemail-send-perl has a build-depends on nullmailer | mail-transport-agent, but it seems to build fine without this, so this build-dep should be removed. If it is actually used during the build, this seems wrong, as a package build shouldn't be sending mail. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618862: systemd: ignores keyscript in crypttab
Oh and I forget (but it seems this is already clear as well): keyscripts may make use of arbitrary other programs... OpenSSL, pcscd, gpg, etc. pp. I've just attached my own keyscript to give an example (just the script, not the initramfs-tools hook or documentation). The biggest problem is likely stuff that requires terminal input (AFAIU systemd takes this over or at least should do so). In Debians cryptsetup, there's /lib/cryptsetup/askpass which I for example use to gather the passphrase (which is used to decrypt the OpenPGP encrypted actual key). So I guess that needs to be adapted somehow as well... either this, or properly documented how to do things in the systemd-way. And of course, any keyscripts would then need to support both,... a systemd-way of interactive input (if there is any)... and the traditional via e.g. askpass (AFAIU, the tech-ctte decision will just define a new default init,... but not forbid any others). Cheers, Chris. decrypt_openpgp Description: application/shellscript smime.p7s Description: S/MIME cryptographic signature
Bug#618862: systemd: ignores keyscript in crypttab
Hi. Had a private conversation with Tollef and he pointed me to this bug... Even though it may be obvious to any developer, let me add the following: I had a short glance at http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n54 I guess another crypt_activate_by_? function would need to be implemented for keyscripts. One thing which need to be taken into account is the following: The keyscript is an arbitrary program (no necessarily a shell script... and the key file parameter (the 3rd field in crypttab(5)) may _not_ be a pathname at all. I for example use a keyscript for openpgp encrypted keys (a different one from that shipped in Debian, which has several functionality deficiencies and following from that: security issues) where one would see lines as the following in crypttab: root /dev/disk/by-uuid/74b4564a-728e-11e3-8a8d-502690aa641f device=/dev/disk/by-uuid/0faa9776-ccbe-4834-a853-501eb3b75372:pathname=/etc/dm-crypt/keys/someHost_root loud,luks,keyscript=decrypt_openpgp,tries=0 All of this is normal unless the 3rd field: device=/dev/disk/by-uuid/0faa9776-ccbe-4834-a853-501eb3b75372:pathname=/etc/dm-crypt/keys/someHost_root which is given to my keyscript decrypt_openpgp It basically combines two options (separated by a colon) into the one passed to the keyscript (which splits it again)... device= being a filesystem which the keyscript should wait to appear (i.e. a USB stick)... mount it ... and pathname= being a a file local to the filesystem on that device... which is then read, fed through gpg and so on. And this is just one example where one could need multiple options put together in the keyfile field of crypttab - unfortunately the Debian maintainer refused to standardise this. Another example could be a OpenPGP crypto smart card, where one waits for a specific smart card ID to appear, and reads key number n from it. Or one can think of examples where the key is read via secured network connections (ssh, ipsec, whatever) and where multiple parameters would be required. So the point is... any support for keyscripts in systemd MUST NOT try to be smarter than it should and somehow interpreting or modifying the keyfile field. It simply MUST pass that on the the keyscript, just as the Debian cryptsetup scripts do it. And it should be noted, that the cryptsetup scripts initialise a bunch of environment variables for the executed keyscript program, which of course systemd would need to do as well. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#733706: installation-report: installation on a Lenovo Thinkpad E431
On 01.01.2014 18:56, Antoine Beaupré wrote: voice style=crooked, old manIn my days, you had to to move bits around with a magnet to resize FAT12 partitions and NTFS was satan! You kids have it t easy./voice ;) Oh yeah, the good old days... ;) Yes, there was a firmware folder, it only contained a .deb of linux-firmware. You can safely have all the firmware .deb's in the /firmware folder. The installer installs only the needed ones. Well, #2 is about a serious bug that makes unrelated things just not work when you enable disable touchpad while typing. It seems to me this bug should be fixed, but it is not related to enabling the touch functionality on the... touch pad. ;) Probably not related to gnome only either... Sorry if I didn't make myself clear. I just meant that in this bug report, also your expected settings were chosen: - Then I set: - enable clicks with touchpad - two-finger scrolling - So your user is not the only one to want those enabled. Yeah, this seems to be a problem larger than plymouth actually. On the top of my head, fixing this would probably involve: * triggers * a way to hook into /etc/grub.d/10_linux to add boot parameters from outside * lots more bikeshedding Unless we make plymouth a hard dependency, which would probably involve around 1500 emails on -devel, so let's pretend I didn't say anything. ;) OK, let's just pretend that. ;) Do you agree that this bug can be closed now? Best regards and a happy new year, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733880: ITP: mediaelement -- HTML5 audio or video player with Flash and Silverlight shims
Package: wnpp Severity: wishlist Owner: David Prévot taf...@debian.org Control: affects -1 owncloud wordpress * Package name: mediaelement Version : 2.11.3 Upstream Author : John Dyer johnd...@gmail.com * URL : http://mediaelementjs.com/ * License : Expat Programming Lang: JavaScript Description : HTML5 audio or video player with Flash and Silverlight shims Instead of offering an HTML5 player to modern browsers and a totally separate Flash player to older browsers, MediaElement.js upgrades them with custom Flash and Silverlight plugins that mimic the HTML5 MediaElement API. This code is currently embedded in owncloud and wordpress, and this package aims at getting rid of these copies. Regards David signature.asc Description: Digital signature
Bug#670624: git-buildpackage: should not run clean command in the non-exported directory when using --git-export-dir
Hi Raphaël, On Tue, Dec 31, 2013 at 10:30:25AM +0100, Raphael Hertzog wrote: Hi, On Fri, 09 Nov 2012, Raphael Hertzog wrote: On Thu, 08 Nov 2012, Guido Günther wrote: So you're suggesting to not run clean by default? Or only when using --export-dir? I'm suggesting that when --export-dir is present, then git-buildpackage should not call debian/rules clean in the git repository. When --export-dir is not present, it's ok since dpkg-buildpackage would call it anyway a bit later. And it allows you to distinguish between an unclean tree due to changes/bugs from an unclean tree due to a former build, so it's certainly ok to keep it. Ping, could we have the bug fixed ? It annoys the hell out of me every time that I stumble on a upstream package whose make clean is broken and where I add the required patch but since the git repository doesn't have the patch applied, the build fails and I have to work around this annoying behaviour of git-buildpackage. I have now started using debian/gbp.conf with cleaner = /bin/true as work-around but it's a poor work-around IMO and I'd rather see the bug fixed. I'm a bit reluctant to make running the cleaner dependent on whether we use export-dir or not. However since I think there's little use for the cleaner itself nowadays I wonder if it might make more sense to use /bin/true as default for the cleaner (which I'm doing since ages). What do you think? Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs
On Wed, 2014-01-01 at 05:48 +0100, Mourad De Clerck wrote: So last time I tried, this just worked - my rootfs got mounted using a keyscript in the initramfs, and there were no problems, not a peep from systemd when it took over, no re-setup or anything. Sure... but that applies, AFAIU, only to the stuff mounted from within the initramfs (at most: rootfs / resume-fs). While I think that for most attack-scenarios, where on-disk-encryption makes sense (the notably exception being: coincidental theft of your device), a fully encrypted system (i.e. including the root-fs) is the only thing that makes sense... it's still necessary to support additional encrypted devices to be brought up during boot (which is AFAIU then systemd's task). I've added few thoughts to #618862, with things that IMHO are necessary to get proper keyscript support with systemd. Stacking causes no problems in my experience. There are of course still problems with devices that aren't mounted in the initramfs but still need some keyscript (f.e. decrypt_derived comes to mind). Well from inside the initramfs this definitely does not work out of the box... since they initramfs-scripts expect a specific order (i.e. MDADM first, and so on... and especially the lvm scripts are kinda bogus). Not that it would make much sense to put dmcrypt below MDADM (in the meantime not even performance-wise)... security wise this might be even disastrous. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#595553:
Intending to adopt the package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732666: [Pkg-libvirt-maintainers] Bug#732666: severity:serious, since it breaks the upgrade
On Tue, Dec 31, 2013 at 08:52:21PM +, Solveig wrote: Severity: serious found 732666 libvirt/1.2.0-1 thanks Setting up libvirt-bin (1.2.0-1) ... [ ok ] Stopping libvirt management daemon: libvirtd not running. [] Starting libvirt management daemon: libvirtdmount: special device cgroup_memory does not exist [warn] Can not mount cgroups layout ... (warning). invoke-rc.d: initscript libvirt-bin, action start failed. dpkg: error processing package libvirt-bin (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: libvirt-bin E: Sub-process /usr/bin/dpkg returned an error code (1) I increase the severity, since it breaks the upgrade. If you don't have memory cgroups enabled in the kernel you already broke the daemon restart yourself by configuring it in. The discussion is moot since we'll detect this dynamically in the future (with the next upload) but it's rather a configuration error than a bug. Cheers, -- Guido ___ Pkg-libvirt-maintainers mailing list pkg-libvirt-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733881: Please use autoreconf instead of autotools-dev
Package: telepathy-farstream Version: 0.6.0-2 Please switch from autottols-dev to dh-autoreconf to fix build issues with the .m4 macros. The patch from ubuntu is below === modified file 'debian/changelog' --- debian/changelog 2013-09-17 22:34:26 + +++ debian/changelog 2014-01-01 19:36:50 + @@ -1,3 +1,9 @@ +telepathy-farstream (0.6.0-2ubuntu1) trusty; urgency=medium + + * Replace autotools-dev with autoreconf, fixes FTBFS on ppc64el + + -- Jackson Doak nosk...@ubuntu.com Thu, 02 Jan 2014 06:36:06 +1100 + telepathy-farstream (0.6.0-2) unstable; urgency=low * Team upload. === modified file 'debian/control' --- debian/control 2013-09-17 22:34:26 + +++ debian/control 2014-01-01 19:36:58 + @@ -1,9 +1,10 @@ Source: telepathy-farstream Section: libs Priority: optional -Maintainer: Debian Telepathy maintainers pkg-telepathy-maintain...@lists.alioth.debian.org +Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com +XSBC-Original-Maintainer: Debian Telepathy maintainers pkg-telepathy-maintain...@lists.alioth.debian.org Uploaders: Sjoerd Simons sjo...@debian.org, Laurent Bigonville bi...@debian.org -Build-Depends: autotools-dev, debhelper (= 9), +Build-Depends: dh-autoreconf, debhelper (= 9), cdbs (= 0.4.93~), libglib2.0-dev (= 2.30), libdbus-1-dev (= 0.60), === modified file 'debian/rules' --- debian/rules 2012-04-11 21:35:55 + +++ debian/rules 2014-01-01 19:35:31 + @@ -1,7 +1,7 @@ #!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk -include /usr/share/cdbs/1/class/autotools.mk +include /usr/share/cdbs/1/rules/autoreconf.mk include /usr/share/cdbs/1/rules/utils.mk common-binary-post-install-arch:: list-missing
Bug#733867: [INTL:es] Spanish debconf template translation for bilibop
Hi, On 01/01/2014 17:03, Camaleón wrote: Package: bilibop Version: 0.4.20 Severity: wishlist Tags: l10n patch Greetings, Your po file will be included in the next release, thanks for your contribution. -- quidame signature.asc Description: OpenPGP digital signature
Bug#733883: Please test for binary Flash and Silverlight blobs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: lintian Version: 2.5.20 Severity: wishlist X-Debbugs-CC: Adam Williamson awill...@redhat.com X-Debbugs-CC: pkg-owncloud-maintain...@lists.alioth.debian.org Le 01/01/2014 14:59, Adam Williamson a écrit : [ Exchanging about bundled binary copy with people from Fedora ] No probs. We found that because someone did a Fedora-wide sweep looking for pre-built Flash and Silverlight blobs and found quite a lot - Debian might be interested in doing the same thing, if it hasn't already...other classic ones are TTFs and .exes, but I'd expect Debian already has checks for those... Right, I believe lintian would be the proper place to check this kind of files. $ apt-file search -x '\.xap$' Only point at four suspect packages – maybe a test on source packages would find more — and $ apt-file search -x '\.swf$' finds a bit more potential overlooks. Maybe a test à la source-contains-prebuilt-windows-binary would be worth it? Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBCAAGBQJSxG8TAAoJEAWMHPlE9r08H3UH/RFbzFpvmEKBCAJYo2vf5iqb rjq3vNRfBAZnkiKY4JpyfIR9PWrtf0xOvCbF5ERP9vROPVuGpjiaPOLZ/oL08FV+ SCJKUq4IULNLRYHtiYpKX/PjyFFIasiwHGYOt/dFWtal2XWjHLCh5IbOQGslsWL5 m2aiMduEWWitXcrayU/c3EMNxjhvtj2hIZytwi5jN9t0tB4gLR5TClD098uxrGo5 QyidBiHjHT3ywt2M3NR0z/10U6ntkD980iba82xuBY/ZKwmpU0B5JYbdSu2e1rOV 7ozQjh9vvoLEQdmROKHFvy1sEiL2fwv+kiuvEx2IlGL/RYpQxlqS3pkv8i0f32c= =pOrP -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#733882: RM: distribute - supserseded by python-setuptools
Package: ftp.debian.org Please remove the distribute source and python-distribute-doc binary. all other binary packages are now built by the python-setuptools source. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
