Bug#735757: caused by buggy libncursesw5-dev package
Control: reassign -1 libncursesw5-dev Control: forcemerge 735782 -1 Control: severity 735782 serious This FTFBS was caused by bug 735782 which has been fixed in the meantime. Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730868: freeciv: New upstream version 2.4.1 available
Hi Markus,
On Thu, Jan 30, 2014 at 5:19 AM, Markus Koschany a...@gambaru.de wrote:
Hi all,
I think I have finished version 2.4.1 of freeciv. You can find all changes
in Debian's git repository. Please let me know if you would like me to improve
something. Otherwise I suggest to test this version a little and then upload
it
at the weekend, if everything works as intended.
http://git.debian.org/?p=pkg-games/freeciv.git;a=summary
Looks good; built, signed, and uploaded, thanks for your work!
Some minor nitpicks (none of which block upload):
- since you're building all the client and data binary packages from
the same source package, for the client packages, why not just depend
on freeciv-data (= ${source:Version}) instead of your current approach
( freeciv-data (= ${source:Version}), freeciv-data (=
${source:Upstream-Version}))? The former approach will work equally
well for source uploads and won't break on binNMUs, so I'm unsure what
the benefit of using the latter is?
- you don't need autotools-dev if you're already using dh-autoreconf
(you're invoking both helpers in d/rules)
- add-keywords-to-desktop-files.patch doesn't have a proper DEP-3
header (assuming you've forwarded this upstream, it's missing a link
to upstream's bug tracker)
Jacob, Marko: would it be possible to sign upstream's tarball with a
gpg key (rationale can be found at [1])? It's certainly not required
or anything, just a suggestion. :)
Cheers,
Vincent
[1] http://lintian.debian.org/tags/debian-watch-may-check-gpg-signature.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735202: speakup crashes debian
On 26-01-14 19:28, Geoff Shang wrote: It seems to happen when working in more primitive environments with no readline. Triggered by the mail of Jude, do you confirm that installing readline prevents this bug from happening? Than indeed adding that as a dependency would solve your issue. Paul signature.asc Description: OpenPGP digital signature
Bug#735202: speakup crashes debian
On 01-02-14 22:12, Jude DaShiell wrote: I understand this bug existed not much prior to the present kernel version from what I read on the spea...@linux-speakup.org mailing list so this bug was carried into this kernel version from at least one earlier version. Do you have an URL or message-id to the discussion that you mean? Does this now agree or disagree with my hypothesis? Paul signature.asc Description: OpenPGP digital signature
Bug#570377: aptitude chooses to remove packages instead of upgrading
Tags: patch
Ah, now I got a proper patch from debdiff. I hadn't gotten aptitude built
yet the first time.
In actual usage on my system, it suggests upgrades first rather than
removals (without any prefs in apt.conf or on the cmdline).
.
On Sun, Feb 2, 2014 at 7:56 PM, Chris Tillman toff.till...@gmail.comwrote:
Tags: patch
I think the root of the problem (removing being preferential to upgrading
in Aptitude's worldview) is that the safe-level and remove-level default
scores are the same.
*Table 2.2. Default safety cost levels*
Cost levelDescriptionConfiguration option 10,000 Solutions that include
only safe actions (installing the default target for a package or
keeping a package at its current version) and package removals.
Aptitude::ProblemResolver::Safe-Levelhttp://aptitude.alioth.debian.org/doc/en/ch02s05s05.html#configProblemResolver-Safe-Level,
Aptitude::ProblemResolver::Remove-Levelhttp://aptitude.alioth.debian.org/doc/en/ch02s05s05.html#configProblemResolver-Remove-Level
When I use a level just one more than the default for remove-level, I get
the desired result:
121-73-239-129:/home/ctillman/aptitude-0.6.8.3/src# aptitude -P -o
'Aptitude::ProblemResolver::Remove-Level=1' -vv full-upgrade
gir1.2-evince-3.0
The following packages will be upgraded:
gir1.2-evince-3.0 libevdocument3-4 libevview3-3
3 packages upgraded, 0 newly installed, 0 to remove and 364 not upgraded.
Need to get 0 B/1,934 kB of archives. After unpacking 85.0 kB will be used.
The following packages have unmet dependencies:
evince : Depends: libevdocument3-4 (= 3.8.3-2) but 3.10.0-2 is to be
installed.
Depends: libevview3-3 (= 3.8.3-2) but 3.10.0-2 is to be
installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) evince
2) gnome
3) gnome-core
Leave the following dependencies unresolved:
4) epiphany-browser recommends evince
vs.
121-73-239-129:/home/ctillman/aptitude-0.6.8.3/src# aptitude -P -o
'Aptitude::ProblemResolver::Remove-Level=10001' full-upgrade
gir1.2-evince-3.0
The following packages will be upgraded:
gir1.2-evince-3.0 libevdocument3-4 libevview3-3
3 packages upgraded, 0 newly installed, 0 to remove and 364 not upgraded.
Need to get 0 B/1,934 kB of archives. After unpacking 85.0 kB will be used.
The following packages have unmet dependencies:
evince : Depends: libevdocument3-4 (= 3.8.3-2) but 3.10.0-2 is to be
installed.
Depends: libevview3-3 (= 3.8.3-2) but 3.10.0-2 is to be
installed.
The following actions will resolve these dependencies:
Upgrade the following packages:
1) evince [3.8.3-2 (now) - 3.10.0-2 (testing)]
2) evince-common [3.8.3-2 (now) - 3.10.0-2 (testing)]
I tried to prepare a one-line patch with quilt, as referenced in
http://raphaelhertzog.com/2011/07/04/how-to-prepare-patches-for-debian-packages/
but I only got one .dsc file instead of two. I'm attaching that and the
patch file quilt generated in debian/patches.
On Thu, Jan 30, 2014 at 10:01 PM, Axel Beckert a...@debian.org wrote:
Hi,
Vincent Lefevre wrote:
aptitude sometimes prefers to remove packages instead of upgrading.
Which is IMHO fine in general. I though must admit that it seems to do
that quite often in Debian Unstable.
Chris King wrote:
This is a very annoying behavior
In Debian Unstable, yes. But it is configurable behaviour, too:
Use
Aptitude::ProblemResolver::Remove-Level maximum;
or
Aptitude::ProblemResolver::Hints {
reject !~M :UNINST;
};
in your apt.conf and you're done.
The latter works better for this issue, but no more allows you to
choose solutions which remove packages unless you explicitly select
them for removal with - in the package list or on the commandline.
This can be annoying, too, and is totally unsuited for dist-upgrades
between two stable releases. It hence is _NOT_ a general solution, but
is very suitable for unattended upgrades of security upates.
aptitude-robot uses it for a while now.
The first variant is probably better suited for general use case, but
can still cause packages to not be upgraded at all due to conflicts
with obosolete packages which actually really should be removed. (I
think, this is one of the reasons why this issue is not trivial to fix
generally without regressions in other fields like dist-upgrades
between two stable releases.)
which Aptitude didn't exhibit a year or so ago.
Hrm, I would be curious which patch introduced that change...
Having to hit n twenty times before Aptitude decides to upgrade
one package rather than removing 50 is just silly.
... and not necessary at all, even without the above configuration.
Just type r on all (often suffices to do it only for some) packages
and hit . only afterwards. (I don't know by mind the commandline
keybindings for that -- these are for the TUI -- but typing ? on
the prompt may give you
Bug#737371: libvdpau-va-gl1: dpkg-architecture used without dependency on dpkg-dev
❦ 2 février 2014 05:15 CET, Vincent Cheng vch...@debian.org : libvdpau-va-gl1 ships /etc/X11/Xsession.d/20vdpau-va-gl, which contains: [ ! -f /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/vdpau/libvdpau_va_gl.so.1 ] || \ export VDPAU_DRIVER=va_gl However, $ dpkg -S /usr/bin/dpkg-architecture dpkg-dev: /usr/bin/dpkg-architecture And your package is missing a depends on dpkg-dev. Unfortunately I don't know of a sane way to get the multiarch triplet without adding a dependency on dpkg-dev (for dpkg-architecture) or gcc. Thanks for noticing. I have searched a bit and didn't find a way to get this acrhitecture. Maybe I could just build it from `arch`-`uname -s | tr '[A-Z]' '[a-z]'`-*? -- Follow each decision as closely as possible with its associated action. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Bug#737375: bootlogd: Segfaults during boot on Hurd booting using sysvinit
Package: bootlogd Version: 2.88dsf-46 User: debian-h...@lists.debian.org Usertags: hurd When booting hurd after installing the experimental version of sysvinit and running update-alternatives --config runsystem to enable sysvinit on Hurd, I noticed a segfault in the early boot. Investigating further, I found the cause - bootlogd. This is the crash when running the same command after boot within gdb: (gdb) run -c -l /run/bootlog Starting program: /sbin/bootlogd -c -l /run/bootlog [New Thread 932.5] Program received signal SIGSEGV, Segmentation fault. 0x010e7409 in __mempcpy (dstpp=dstpp@entry=0x102942c, srcpp=0x0, len=len@entry=4) at mempcpy.c:62 62 mempcpy.c: No such file or directory. (gdb) bt #0 0x010e7409 in __mempcpy (dstpp=dstpp@entry=0x102942c, srcpp=0x0, len=len@entry=4) at mempcpy.c:62 #1 0x011528f1 in in (count=optimized out, type=IOC_32) at ../sysdeps/mach/hurd/ioctl.c:125 #2 0x01152af4 in send_rpc (ioport=103) at ../sysdeps/mach/hurd/ioctl.c:137 #3 0x010827a5 in _hurd_ctty_output (port=port@entry=103, ctty=ctty@entry=141, rpc=rpc@entry=0x10294c4) at ctty-output.c:52 #4 0x0115305b in __ioctl (fd=0) at ../sysdeps/mach/hurd/ioctl.c:271 #5 0x08049152 in ?? () #6 0x01085188 in __libc_start_main (main=0x8048f40, argc=4, ubp_av=0x1029df4, init=0x804a1e0, fini=0x804a250, rtld_fini=0xffe0 _dl_fini, stack_end=0x1029dec) at libc-start.c:307 #7 0x08049663 in ?? () (gdb) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737371: libvdpau-va-gl1: dpkg-architecture used without dependency on dpkg-dev
On Sun, Feb 2, 2014 at 12:33 AM, Vincent Bernat ber...@debian.org wrote: ❦ 2 février 2014 05:15 CET, Vincent Cheng vch...@debian.org : libvdpau-va-gl1 ships /etc/X11/Xsession.d/20vdpau-va-gl, which contains: [ ! -f /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/vdpau/libvdpau_va_gl.so.1 ] || \ export VDPAU_DRIVER=va_gl However, $ dpkg -S /usr/bin/dpkg-architecture dpkg-dev: /usr/bin/dpkg-architecture And your package is missing a depends on dpkg-dev. Unfortunately I don't know of a sane way to get the multiarch triplet without adding a dependency on dpkg-dev (for dpkg-architecture) or gcc. Thanks for noticing. I have searched a bit and didn't find a way to get this acrhitecture. Maybe I could just build it from `arch`-`uname -s | tr '[A-Z]' '[a-z]'`-*? That sounds like a possible workaround, sure. Alternatively, maybe just drop that line and only keep export VDPAU_DRIVER=va_gl in that file (given that end users have to uncomment that line manually to begin with anyways)? Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737376: texlive-extra-utils: Debian pythontex can't use python3
Package: texlive-extra-utils Version: 2013.20131219-1 Tags: patch I just read about pythontex in TUGboat - it sounds great! I was a little surprised that it says, though, that it's only for Python 2.7. So I looked at the code, and it has support for Python 3.2+; yay! Unfortunately, though, the invocation doesn't allow this to work on Debian: /usr/bin/pythontex - /usr/share/texlive/texmf-dist/scripts/pythontex/pythontex.py has the first line: #!/usr/bin/env python and on Debian, /usr/bin/python is a symlink to python2.7, so the rest of the pythontex.py code, which checks whether python2 or python3 is being used, is effectively redundant. My suggested patch is as follows: Create a copy of pythontex.py in /usr/share/texlive/texmf-dist/scripts/pythontex, called say pythontex3-init.py (pythontex3.py is already used), which has the first line #!/usr/bin/python3 or #!/usr/bin/env python3 and symlink /usr/bin/pythontex3 to it. That way, pythontex will use Python 2.7 and pythontex3 will use Python 3.x. Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731992: [pkg-octave/master] princomp-one-arg.patch: new patch, fixes princomp with only one arg.
tag 731992 pending thanks Date: Sun Feb 2 10:09:21 2014 +0100 Author: Sébastien Villemot sebast...@debian.org Commit ID: 33910d8e8e41e1c7b80fc6a81ead96126e3f4c5f Commit URL: http://anonscm.debian.org/gitweb/?p=pkg-octave/octave-statistics.git;a=commitdiff;h=33910d8e8e41e1c7b80fc6a81ead96126e3f4c5f Patch URL: http://anonscm.debian.org/gitweb/?p=pkg-octave/octave-statistics.git;a=commitdiff_plain;h=33910d8e8e41e1c7b80fc6a81ead96126e3f4c5f princomp-one-arg.patch: new patch, fixes princomp with only one arg. Closes: #731992 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736060: closed by Petter Reinholdtsen p...@debian.org (Bug#736060: fixed in sysvinit 2.88dsf-46)
On Sat, Feb 01, 2014 at 11:06:23PM +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the sysv-rc package: #736060: sysv-rc: update-rc.d documentation bugs (usage message and manpage) It has been closed by Petter Reinholdtsen p...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Petter Reinholdtsen p...@debian.org by replying to this email. I am surprised indeed that dak closes bugs on an upload to experimental; I would have assumed that it only did so when uploaded to unstable. Anyway, thanks for fixing this! Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730868: freeciv: New upstream version 2.4.1 available
Hi Vincent,
thanks for taking your time to review the package.
On 02.02.2014 09:20, Vincent Cheng wrote:
[...]
Some minor nitpicks (none of which block upload):
- since you're building all the client and data binary packages from
the same source package, for the client packages, why not just depend
on freeciv-data (= ${source:Version}) instead of your current approach
( freeciv-data (= ${source:Version}), freeciv-data (=
${source:Upstream-Version}))? The former approach will work equally
well for source uploads and won't break on binNMUs, so I'm unsure what
the benefit of using the latter is?
I thought that someone who had already downloaded freeciv-data version
2.4.1-1 could avoid further downloads and thus save bandwidth. Since the
arch:all package doesn't change from 2.4.1-1 to 2.4.1-2, it doesn't
matter which version of the same source package is installed. Using (=
${source:Version}) is more strict and forces a download every time.
- you don't need autotools-dev if you're already using dh-autoreconf
(you're invoking both helpers in d/rules)
That's right. Here I simply left the line in question intact because I
wasn't sure whether the package is affected by
http://bugs.debian.org/698765
and whether dh-autoreconf is really a superset of autotools_dev in this
case.
- add-keywords-to-desktop-files.patch doesn't have a proper DEP-3
header (assuming you've forwarded this upstream, it's missing a link
to upstream's bug tracker)
True. I forwarded this patch upstream yesterday.
https://gna.org/bugs/index.php?21573
Cheers,
Markus
signature.asc
Description: OpenPGP digital signature
Bug#735898: pavucontrol segmentation fault
On 2014-01-20 15:36:37 +0400, Vlad Orlov wrote: Can't reproduce it. I can't reproduce it either. If this doesn't affect most users, the bug severity should be lowered to important, if the bug is not reassigned in case it would be: Run dmesg after that and check the last lines of the output for the hints about the cause of segfault. If it says something about libgtk-3.so then you've probably been hit by a known bug in gtk3-engines-unico [1] and need to change your GTK+ theme to something not using unico. If not, posting the relevant lines here won't hurt anyway. [1] http://bugs.debian.org/706330 -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737343: [calibre] use version 1.0 of DEP-5 copyright format
tag 737343 pending thanks Hey Felix, Felix Gruber [2014-02-01 21:42 +0100]: Currently the debian/copyright file of calibre uses an old draft of the DEP-5 machine readable copyright file format. The attached patch updates the file to use the current version 1.0 of the machine readable copyright file format as defined in Many thanks! Applied to packaging bzr. Viele Gruesse, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.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#737321: [Pkg-xfce-devel] Bug#737321: lightdm: After starting gnome-shell with LightDM, screen is not locked on suspend/hibernate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Control: tag -1 moreinfo wontfix On Sat, Feb 01, 2014 at 05:00:57PM +, Nick wrote: Package: lightdm Severity: normal Dear Maintainer, After starting gnome-shell with LightDM, screen is not locked on suspend/hibernate. This apparently works using GDM3 (see closed bug: http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=736093) so seems to be related to KDM. (Please note that I haven't tested this myself, but the maintainer for the above bug has). Cheers. That's not really a proper way to report a bug, you know? Also, lightdm (and KDM I guess) are meant to be desktop-agnostic, so I fail to see what we should do here. I don't want to special-case one desktop over another. If GNOME needs special care, then it needs to express it itself. Regards, - -- Yves-Alexis Perez -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJS7hFtAAoJEG3bU/KmdcClxBUIALAhtll2xv3f2qJswRY/kFb3 bO3xwbjlxh2KD5iKz/704XsXWDJB5AnaPLA/6NKd3qJuI84rMbClbO3mHKyBkR7S aSkpQuX7aZJXUTunSb3K2iia3YH7MJ3gONalQHUhnLeF3thClB7Zl7627L3cx9Dg b0VMy5hyZD0gJIsnZnO2XBrwCRAdT2+fK15bV3uWIF1jYvB6aa4W10WRmB+Si/Ot qKR+15lsh5ZCvs7Aey/GJTkex/Vx6OOqmzXgVBYK+RmV/HTuLg1fQInwi5NZ3WGT mxG2sBpwHSZzhEuGuUj3vDKL9xqLSUjvSB2eiULfQNcKUnAF5SIR0r0eI98weZc= =ebqy -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#727708: multiple init systems - formal resolution proposal
Steve Langasek writes (Re: Bug#727708: multiple init systems - formal
resolution proposal):
As things stand, it seems that each set of dependency rider options will
have some members of the TC voting them below FD. Which means I don't think
we've actually gotten to the bottom of this issue and identified the
consensus position, and I think we should be doing so.
I think that there probably isn't a consensus position.
Where would this ballot option rank vis-à-vis FD, for those TC members who
are opposed to the loose coupling option?
Well, I'm not one of those so your question is not really aimed at me.
But your S is for me basically a version of T, so I don't like it for
that reason. (To an extent, the first and second sentences of the 2nd
para are contradictory, and I don't think that's helpful.)
And the requirement you set out about dependencies is IMO too
technologically specific, and ought to be covered by the 3rd
paragraph about reasonable patches.
AFAICT neither Russ or Bdale have directly answered your question.
Given that and what I have said, do you want (a) to discuss this
further (perhaps with another irc drafting meeting) (b) to vote on
{T,L}{D,U,O,R} etc. (c) to propose your S or some variant on it as
well (as S{D,U,O,R} I expect) (d) something else ?
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737377: network-manager-kde: turning off ipv4 is required in a wireless profile does not persist
Package: network-manager-kde Version: 1:0.9.0.3-1 Severity: normal Dear Maintainer, On FOSDEM2014 IPv6 only network.. the network nanager keeps waiting for the IPv4 (legacy) IP from dhcp none is forthcomming.. so i open the profile .. turn on ipv6 .. turn off IPv4 is required .. save and close .. reopen the profile .. IPv4 is required is once again enabled. -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (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 network-manager-kde depends on: ii plasma-widget-networkmanagement 0.9.0.3-1 network-manager-kde recommends no packages. network-manager-kde 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#737370: mkdir: directories created with weird mode when -p is used
On Sat, 1 Feb 2014, Bob Proulx wrote: Fredrik Tolf wrote: I can't really imagine that this behavior is intended, and it seems to go against any reasonable principle of least surprise. It is intended because that is the way traditional legacy Unix systems have always behaved. And because that is the legacy behavior it is required by POSIX for reasons of legacy portability. http://pubs.opengroup.org/onlinepubs/009695399/utilities/mkdir.html Huh, I was not aware of that. One might argue that it should be mentioned in the manpage then, though; but I see that the texinfo manual does mention it, so perhaps that's intentional. Can you produce a small test case that illustrates the ACL behavior? Sure, here: $ mkdir /tmp/a $ cd /tmp/a $ setfacl -m d:g::rwx . $ mkdir b $ mkdir -p c $ ls -l total 8 drwxrwxr-x+ 2 fredrik users 4096 Feb 2 10:38 b drwxr-xr-x+ 2 fredrik users 4096 Feb 2 10:38 c Ideally, b and c should be created with the same permissions. It should be mentioned that what I would consider the expected behavior, and the behavior specified by POSIX would both be obtained if mkdir simply does not attempt to do anything special with the mode and/or umask whenever ((umask 0300) == 0), the most common case anyway. Or, alternatively, just sets the umask to (umask ~0300) before doing the -p operation. If you wish a behavior change with regards to ACLs would you be so kind as to request it upstream at coreut...@gnu.org? Sure, I could do that, but I was under the impression that Debian generally preferred to handle bug reports internally. Was I mistaken about that? -- Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736148: cloud-init: please upgrade to 0.7.5 for OpenNebula support
Le Mon, Jan 20, 2014 at 11:38:58AM +0100, Olivier Sallou a écrit : Package: cloud-init Version: 0.7.2-3 Severity: wishlist Dear Maintainer, please upgrade in unstable and backports to v0.7.5 that integrates OpenNebula support in cloud-init. I expect to use it in build-debian-cloud to generate OpenNebula virtual machines. Bonjour Olivier, v0.7.5 is not released yet. Would v0.7.4 be enough ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: package to change init systems
On Sat, Feb 01, 2014 at 10:44:27PM -0800, Russ Allbery wrote: ... I think L is a bad technical design, regardless of the relative merits of the possible init systems that we might switch to. It's effectively equivalent to requiring sysvinit support for all packages indefinitely, and if we thought that was a reasonable design, we would be having a much different discussion. No, it does not require sysvinit support for all packages indefinitely. The current TC decision is *for jessie*. Since the current proposal sets the default only for jessie, it basically implies that a new TC decision and/or GR about init systems will have to be discussed and voted on for jessie+1. AFAIR so far noone has suggested dropping sysvinit support in jessie if jessie supports multiple init systems, but for jessie+1 that can be discussed when the init system discussion for jessie+1 will take place. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737378: libkakasi2-dev: arch-dependent file in Multi-Arch: same package
Package: libkakasi2-dev
Version: 2.3.5-1
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch
libkakasi2-dev is marked as Multi-Arch: same, but the following file
is architecture-dependent:
/usr/bin/kakasi-config
An example diff between i386 and amd64 is attached.
--
Jakub Wilk
diff -ur libkakasi2-dev_2.3.5-1_i386/usr/bin/kakasi-config
libkakasi2-dev_2.3.5-1_amd64/usr/bin/kakasi-config
--- libkakasi2-dev_2.3.5-1_i386/usr/bin/kakasi-config 2014-02-01
14:25:36.0 +0100
+++ libkakasi2-dev_2.3.5-1_amd64/usr/bin/kakasi-config 2014-02-01
13:55:28.0 +0100
@@ -72,7 +72,7 @@
;;
--libs)
- echo -L${prefix}/lib/i386-linux-gnu -lkakasi
+ echo -L${prefix}/lib/x86_64-linux-gnu -lkakasi
;;
*)
Bug#728059: RFS: gnome-shell-pomodoro/0.6.20131027-1 [ITA]
Dear Vincent, I first understood that I needed --with quilt and then lintian was complaining about a missing build-dep for quilt. That's why I added them. But I doubled checked, tested on the package and you're right I don't need this! :-) That's great, I removed them. Yep, you guessed why priority was extra: I let them to the default value of dh_make. Changed that! :-) I didn't know this wrap-and-sort script. This is a great tool in its way! It even cleans up the commented Vcs-*! :-D Thanks a lot for all your help and time. I know feel I have a pretty awesome package thanks to you! ;-) I have to make a big sticky note with all your advises for next package with a lot of smileys! Thanks again, Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737312: libosmgpsmap-1.0-0-dev ?
Hi Sylvestre, On Sun, Feb 02, 2014 at 07:19:44AM -0800, Sylvestre Ledru wrote: Well, I switched the package to d-shlibs which is implementing the Debian Library Packaging Guide (that strictly that you need to follow names conventions like this - most packages without using d-shlibs are more sloppy). I think that many people consider this guide as deprecated. While I have no doubt that this is the case - I admit I consider this naming convention also a bit clumsy - I have never read about this. For me the guide was the *only* *existing* documentation. This is simply the reason why I did follow it. Anyway, myself, I don't really see the point of having 1.0-0-dev in the library. :( I'm keeping Jonas as the d-shlibs maintainer in CC. Jonas, would you suggest a relevant list to discuss this and perhaps adapt d-shlibs to accept less verbose version numbers inside package names? I found that a bit silly, useless and broken the only dependency of it (subsurface) :( Really? THe virtual package libosmgpsmap-dev remains provided and there should be no conflict. How can I verify this obvervation of yours? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737312 Well, I did not intend to break anything but I keep on wondering why the build is broken since the virtual package exists. I'm fine with reverting the change but I'd like to stick to d-shlibs if possible. May be Jonas could come up with some suggestion about the requirement of the version numbers inside the package names. Greetings from Debian Med sprint in Stonehaven Cool :) I guess you are at FOSDEM which is cool as well. :-) Sorry for the inconvience I might have created Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730868: freeciv: New upstream version 2.4.1 available
On Sun, Feb 2, 2014 at 1:22 AM, Markus Koschany a...@gambaru.de wrote:
Hi Vincent,
thanks for taking your time to review the package.
On 02.02.2014 09:20, Vincent Cheng wrote:
[...]
Some minor nitpicks (none of which block upload):
- since you're building all the client and data binary packages from
the same source package, for the client packages, why not just depend
on freeciv-data (= ${source:Version}) instead of your current approach
( freeciv-data (= ${source:Version}), freeciv-data (=
${source:Upstream-Version}))? The former approach will work equally
well for source uploads and won't break on binNMUs, so I'm unsure what
the benefit of using the latter is?
I thought that someone who had already downloaded freeciv-data version
2.4.1-1 could avoid further downloads and thus save bandwidth. Since the
arch:all package doesn't change from 2.4.1-1 to 2.4.1-2, it doesn't
matter which version of the same source package is installed. Using (=
${source:Version}) is more strict and forces a download every time.
Practically speaking, if saving bandwidth is a concern, the end user
should be using something like debdelta; apt-get/aptitude will update
all of freeciv's packages at once anyways. I suppose it doesn't really
matter either way though.
- you don't need autotools-dev if you're already using dh-autoreconf
(you're invoking both helpers in d/rules)
That's right. Here I simply left the line in question intact because I
wasn't sure whether the package is affected by
http://bugs.debian.org/698765
and whether dh-autoreconf is really a superset of autotools_dev in this
case.
I'm not an autohell^Wautotools expert, so I can't comment on this, but
I'll note that the same bug report mentions dh-autoreconf(7) saying
that combining the two can have unexpected results as well.
- add-keywords-to-desktop-files.patch doesn't have a proper DEP-3
header (assuming you've forwarded this upstream, it's missing a link
to upstream's bug tracker)
True. I forwarded this patch upstream yesterday.
https://gna.org/bugs/index.php?21573
Great, please add it into the patch header before the next upload.
Cheers,
Vincent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737379: glib2.0: FTBFS on powerpc: several GIO tests fail
Source: glib2.0 Version: 2.38.2-1 Severity: serious Justification: fails to build from source (but built successfully in the past) https://buildd.debian.org/status/fetch.php?pkg=glib2.0arch=powerpcver=2.38.2-1stamp=1387998733: /usr/bin/make check-TESTS make[8]: Entering directory `/«PKGBUILDDIR»/debian/build/deb/gio/tests' make[9]: Entering directory `/«PKGBUILDDIR»/debian/build/deb/gio/tests' ... FAIL: proxy-test ... FAIL: socket ... FAIL: gdbus-threading FAIL: gmenumodel ... proxy-tests, socket, gdbus-auth, gdbus-threading and gmenumodel are all a GSLice assertion failure. gdbus-peer is a different assertion failure. I suspect that multi-threading might be involved: AIUI, these tests all exercise threaded functionality. S # Start of proxy tests ok 1 /proxy/direct_sync ok 2 /proxy/direct_async ok 3 /proxy/single_sync ok 4 /proxy/single_async ok 5 /proxy/multiple_sync ok 6 /proxy/multiple_async ok 7 /proxy/dns ok 8 /proxy/override ok 9 /proxy/enumerator-ports # End of proxy tests 1..9 ***MEMORY-ERROR***: /«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-proxy-test[821]: GSlice: assertion failed: sinfo-n_allocated 0 Aborted # Start of socket tests ok 1 /socket/ipv4_sync ok 2 /socket/ipv4_async ok 3 /socket/ipv6_sync ok 4 /socket/ipv6_async ***MEMORY-ERROR***: /«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-socket[950]: GSlice: assertion failed: sinfo-n_allocated 0 Aborted # Start of gdbus tests ok 1 /gdbus/peer-to-peer ok 2 /gdbus/delayed-message-processing ok 3 /gdbus/nonce-tcp ok 4 /gdbus/tcp-anonymous ok 5 /gdbus/credentials # GLib-GObject-FATAL-CRITICAL: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (/«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-gdbus-peer:1473): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Trace/breakpoint trap # random seed: R02S8ce510186132ed0b29d50f6368a47888 # Start of gdbus tests # Start of auth tests # Start of client tests ***MEMORY-ERROR***: /«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-gdbus-auth[1658]: GSlice: assertion failed: sinfo-n_allocated 0 Aborted # random seed: R02S4eac70c89667a26463b7b679991f2691 # Start of gdbus tests ok 1 /gdbus/delivery-in-thread ok 2 /gdbus/method-calls-in-thread ***MEMORY-ERROR***: /«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-gdbus-threading[3138]: GSlice: assertion failed: sinfo-n_allocated 0 Aborted cleaning up pid 3158 # Start of gmenu tests ok 1 /gmenu/equality ok 2 /gmenu/random ok 3 /gmenu/attributes ok 4 /gmenu/links ok 5 /gmenu/mutable ok 6 /gmenu/convenience ok 7 /gmenu/menuitem # Start of dbus tests ok 8 /gmenu/dbus/roundtrip ok 9 /gmenu/dbus/subscriptions ***MEMORY-ERROR***: /«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-gmenumodel[3194]: GSlice: assertion failed: sinfo-n_allocated 0 Aborted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737380: glib2.0: FTBFS on mipsel: gapplication test failed: ECHILD was received by waitpid()
Source: glib2.0 Version: 2.38.2-1 Severity: serious Justification: fails to build from source (but built successfully in the past) https://buildd.debian.org/status/fetch.php?pkg=glib2.0arch=mipselver=2.38.2-1stamp=1387885448: # random seed: R02S852f3ece8c5f76fcefb61e81eb83e7a7 # Start of gapplication tests ok 1 /gapplication/no-dbus ok 2 /gapplication/basic # GLib-FATAL-WARNING: In call to g_spawn_sync(), exit status of a child process was requested but ECHILD was received by waitpid(). Most likely the process is ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive first argument; either behavior can break applications that use g_spawn_sync either directly or indirectly. (/«PKGBUILDDIR»/debian/build/deb/gio/tests/.libs/lt-gapplication:10577): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but ECHILD was received by waitpid(). Most likely the process is ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive first argument; either behavior can break applications that use g_spawn_sync either directly or indirectly. Trace/breakpoint trap -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737381: glib2.0: FTBFS on armel: param test failed: stderr of child process failed to match: *remove functionality*
Source: glib2.0 Version: 2.38.2-1 Severity: serious Justification: fails to build from source (but built successfully in the past) https://buildd.debian.org/status/fetch.php?pkg=glib2.0arch=armelver=2.38.2-1stamp=1388753949 # random seed: R02S1a8743cbe43b1ad88d0266704b9dac5a # Start of param tests ok 1 /param/value ok 2 /param/strings ok 3 /param/qdata ok 4 /param/validate ok 5 /param/convert ** GLib-GObject:ERROR:/«PKGBUILDDIR»/./gobject/tests/param.c:772:test_param_implement: stderr of child process (/param/implement/subprocess/7-0-2-1 [4726]) failed to match: *remove functionality* # GLib-GObject:ERROR:/«PKGBUILDDIR»/./gobject/tests/param.c:772:test_param_implement: stderr of child process (/param/implement/subprocess/7-0-2-1 [4726]) failed to match: *remove functionality* Aborted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695303: Upstream SVN seems to support gcc 4.7
Hi Wesley, upstream SVN contains: r149 | gingold | 2012-12-11 04:45:35 +0200 (Tue, 11 Dec 2012) | 5 lines Update to gcc 4.7 Can you check whether that might help resolving this issue? Thanks Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736391: get yourself some GTK+ 3-compatible themes.
Synaptic didn't stop recognizing Appearance settings. Synaptic has been ported from GTK+ 2 to GTK+ 3. Get some themes that support both GTK+ 2 and 3. Moreover, you'll need to get themes that are compatible with GTK+ 3.8 because it's the version that's currently in Testing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735202: speakup crashes debian
On Sun, 2 Feb 2014, Paul Gevers wrote: On 26-01-14 19:28, Geoff Shang wrote: It seems to happen when working in more primitive environments with no readline. Triggered by the mail of Jude, do you confirm that installing readline prevents this bug from happening? Than indeed adding that as a dependency would solve your issue. No it doesn't. Just because readline is installed, it doesn't mean that everything you run wil use it. Apart from my `cat` example which crashes reliably even with readline6 installed, there are commands which don't use readline (e.g. at) where I believe it will occur. right now I'm not in a position to test it. IMHO, tryign to work around the bug isn't the right approach. A bug that will crash the entire system hard needs to be treated as a bug that needs to be fixed. Geoff. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728059: RFS: gnome-shell-pomodoro/0.6.20131027-1 [ITA]
On Sun, Feb 2, 2014 at 2:01 AM, Joseph Herlant herla...@gmail.com wrote:
Dear Vincent,
I first understood that I needed --with quilt and then lintian was
complaining about a missing build-dep for quilt. That's why I added
them.
But I doubled checked, tested on the package and you're right I don't
need this! :-)
That's great, I removed them.
Source format '3.0 (quilt)' means that dpkg-source will automatically
deal with (un-)applying patches, so you don't need to use
dh_quilt_{patch,unpatch} to do so. If you were using an older source
format (e.g. 1.0), then yes, you would need to explicitly declare a
build-dep on quilt.
Yep, you guessed why priority was extra: I let them to the default
value of dh_make. Changed that! :-)
I didn't know this wrap-and-sort script. This is a great tool in its
way! It even cleans up the commented Vcs-*! :-D
Thanks a lot for all your help and time. I know feel I have a pretty
awesome package thanks to you! ;-)
I have to make a big sticky note with all your advises for next
package with a lot of smileys!
Great, thanks for fixing all those rather pedantic complaints!
One last nitpick (sorry!) is that other gnome-shell extensions
packaged in Debian seem to prefix their packages with
gnome-shell-extension- (e.g. gnome-shell-extension-weather,
gnome-shell-extension-autohidetopbar), so can you please do the same
for your binary package as well, i.e. rename it
gnome-shell-extension-pomodoro?
Vincent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737383: maildrop: notmuch complains about maildrop delivered messages
Package: maildrop Version: 2.7.1-1 Severity: normal Dear Maintainer, I'm using maildrop to deliver to various Maildirs (which are then indexed with notmuch and read with mutt). As of 2.7.1-1 maildrop adds on top of any message a header like: From amp@sid.nuvreauspam Sun Feb 2 12:28:13 2014 As a consequence notmuch complains like this: amp@sid:~$ notmuch new Warning: /home/amp/Maildir/new/1391336893.M959803P4710V0806I0004236B_0.sid,S=1902 is an mbox containing a single message, likely caused by misconfigured mail delivery. Support for single-message mboxes is deprecated and may be removed in the future. Processed 1 file in almost no time. Added 1 new message to the database. Removed 1 message. The complete file is attached to prevent mangling by MUA/MTA/MDA. Downgrading to 2.6.0-1 makes the warning disappear. This happens both for locally delivered messages or Debian list messages retrieved with getmail. Postfix invokes maildrop with mailbox_command = maildrop Getmail invokes maildrop with [destination] type = MDA_external path = /usr/bin/maildrop unixfrom = True If you need more information please don't hesitate to ask. Kind regards, Andrei -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages maildrop depends on: ii courier-authlib 0.63.0-6+b1 ii libc62.17-97 ii libgcc1 1:4.8.2-14 ii libgdbm3 1.8.3-12 ii libpcre3 1:8.31-2 ii libstdc++6 4.8.2-14 Versions of packages maildrop recommends: ii postfix [mail-transport-agent] 2.10.2-1 maildrop suggests no packages. -- Configuration Files: /etc/maildroprc changed: DEFAULT=$HOME/Maildir SENDMAIL=/usr/sbin/sendmail -- no debconf information From amp@sid.nuvreauspam Sun Feb 2 12:28:13 2014 Return-Path: amp@sid.nuvreauspam X-Original-To: amp@sid.nuvreauspam Delivered-To: amp@sid.nuvreauspam Received: by sid.nuvreauspam (Postfix, from userid 1077) id D5664C0797; Sun, 2 Feb 2014 12:28:13 +0200 (EET) Date: Sun, 2 Feb 2014 12:28:13 +0200 From: Andrei POPESCU amp@sid.nuvreauspam To: Andrei POPESCU amp@sid.nuvreauspam Subject: Test maildrop Message-ID: 20140202102813.GC1706@sid.nuvreauspam MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol=application/pgp-signature; boundary=t0UkRYy7tHLRMCai Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable test --=20 If you can't explain it simply, you don't understand it well enough. (Albert Einstein) http://nuvreauspam.ro/gpg-transition.txt --t0UkRYy7tHLRMCai Content-Type: application/pgp-signature; name=signature.asc Content-Description: Digital signature -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJS7h29AAoJEP/HhUTvIjQcyEsQAIamZkcuUytfR+BYXo03Ny9f MFvseQ4cDoFPQ6mOwF221lkfD1UV2K5Dtt2Yz/Y60g7tzNqKlmoYWap9pMXfyaFX GfOa22zfrPdbDaiUDe2sh+1EbhLQnOUa3+vM6tVtF01xem+8gkZBVRz7YUS5IOy6 UauEDVhdgvJwD2FliE6KdB9/GXZeHSTC8wKsw+VxliQlHFKSLf8w+F4SkMtU2J/l jT856J0TEvP4v2txXAtSgzyYPXKKMN77e+cqsdOVmHCm9YOvhluXaZWt3GeHSqic TiTpZLohbWPlx3Ast+DnYW38631LXqT08nhw1KQiU5W517MZ9k0EVi0uHVOCssGV 6CnJdlUAua0KyTpRJggcXLeoyWl9tSRWE9vK20A1VEaymZO5SGl7JjxjgnTefsSq FdGBZVVwYtmY0Lb6MJgRtgL+Cm1iaMZeXSOEaBZ9RLNlY2kSMXRi5P/CfS9NxRKn BSiwD7dA4t0dIRFcjmn7+Bb8ODfy7DUpIiINM9yw+kDZaF7S+f/1KD7rrd4KJv4q splFkOqRaO+/s/DJE6dKdx/iwOKM25mU0uxHiCpacMP89hKEVJokZSTJH4vxmPFd mJuxXn/hUd+IIpKd6qFt9L+nwo7t0Qrpg7uYoOsv6hv/Z47rV7WnEskckbOaHIPf OuY/PW5tbrrWxZAUd4Ql =DTcW -END PGP SIGNATURE- --t0UkRYy7tHLRMCai--
Bug#733391: abiword: FTBFS: itex2MML.y:298:25: error: 'ret_str' undeclared (first use in this function)
On Wed, 29 Jan 2014 15:21:46 Markus Koschany wrote: It appears the FTBFS is caused by bison3 and Ubuntu applied this patch for it. Thanks very much for this information, Markus. Too bad on this instance ubuntu developer did not trouble himself sharing the improvement with us or even with upstream. I'd like to think that it was a mere negligence rather than agenda to stay ahead of us with their added value... :( -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- The gods offer no rewards for intellect. There was never one yet that showed any interest in it. -- Mark Twain, 1900 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695303: Upstream SVN seems to support gcc 4.7
On Sun, Feb 02, 2014 at 12:32:13PM +0200, Adrian Bunk wrote: Hi Wesley, upstream SVN contains: r149 | gingold | 2012-12-11 04:45:35 +0200 (Tue, 11 Dec 2012) | 5 lines Update to gcc 4.7 Can you check whether that might help resolving this issue? And as happens so often, I am discovering the most important information immediately *after* sending an email... Upstream development moved to a different site, and there is a new release 0.31 that does support gcc 4.8: http://sourceforge.net/projects/ghdl-updates/ cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737382: libtolua++5.1-dev: Please build new package with upstream changes
Package: libtolua++5.1-dev Version: 1.0.93-4 Severity: normal Dear Maintainer, as discussed in email earlier this week, there have been several changes to tolua++ since the Debian package was built, notably the tolua_outside modifier (which my project needs). It would be great if those could make it into a new Debian pacakge. I've taken this opportunity to commit the Debian patches into the upstream SVN at berlios, so you should be able to build directly from those sources now. Thanks, Enno. -- System Information: Debian Release: 7.2 Architecture: armhf (armv6l) Kernel: Linux 3.10.28+ (PREEMPT) 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 libtolua++5.1-dev depends on: ii libc62.17-97 ii liblua5.1-0 5.1.5-4 ii liblua5.1-0-dev [liblua5.1-dev] 5.1.5-4 libtolua++5.1-dev recommends no packages. libtolua++5.1-dev 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#737384: Should use GTK+2 useful for LXDE and Xfce users
Package: galculator Version: 2.1.2-1 Severity: wishlist Tags: patch Dear Maintainer, since 2.0 version galculator uses GTK+3 libralies, but it isn't good for LXDE and Xfce where galculator is as default calculator appliacation. This enviroment uses only GTK+2. In my opinion your package should back to GTK+2 - look on my patch or provide galculator-gtk2 or something like package. Mateusz galculator-gtk2.patch Description: Binary data
Bug#737379: glib2.0: FTBFS on powerpc: several GIO tests fail
On 02/02/14 11:18, Simon McVittie wrote: Source: glib2.0 Version: 2.38.2-1 Severity: serious Justification: fails to build from source (but built successfully in the past) https://buildd.debian.org/status/fetch.php?pkg=glib2.0arch=powerpcver=2.38.2-1stamp=1387998733: proxy-tests, socket, gdbus-auth, gdbus-threading and gmenumodel are all a GSLice assertion failure. gdbus-peer is a different assertion failure. I suspect that multi-threading might be involved: AIUI, these tests all exercise threaded functionality. The gslice assertion is a bug in the valgrind support, already fixed in glib upstream and in our repo. https://bugzilla.gnome.org/show_bug.cgi?id=710983 https://bugs.kde.org/show_bug.cgi?id=278808 I don't know if the gdbus-peer failure is caused by this or is a different bug. Regards, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737385: a2ps: insecure use of /tmp
Package: a2ps
Version: 1:4.14-1.1
Severity: important
Tags: security
src/main.c contains this code:
/* Use one of the temp file names so that cleanup can be correctly
done. */
tempname_ensure (job-tmp_filenames[0]);
spyname = job-tmp_filenames[0];
spy = fopen (spyname, w);
tempname_ensure() is defined in lib/routines.h as:
#define tempname_ensure(Str) \
do { \
(Str) = (Str) ? (Str) : tempnam (NULL, a2_);\
} while (0)
From the tempnam(3) manpage: “Although tempnam() generates names that
are difficult to guess, it is nevertheless possible that between the
time that tempnam() returns a pathname, and the time that the program
opens it, another program might create that pathname using open(2), or
create it as a symbolic link. This can lead to security holes. To avoid
such possibilities, use the open(2) O_EXCL flag to open the pathname. Or
better yet, use mkstemp(3) or tmpfile(3).”
(There are other calls to tempname_ensure() in the a2ps code, but I
haven't checked them.)
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737386: g++-4.8: Segmentation fault thread_local
Package: g++-4.8
Version: 4.8.2-14
Severity: important
Tags: upstream
Dear Maintainer,
When compiling the code below (with --std=c++11) I got internal compiler
error: Segmentation fault with g++-4.8 (or g++-4.9):
#include random
thread_local std::uniform_real_distributiondouble uniformDistribution_(0.0,
1.0);
int main(int argc, char *argv[])
{
return 0;
}
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages g++-4.8 depends on:
ii gcc-4.84.8.2-14
ii gcc-4.8-base 4.8.2-14
ii libc6 2.17-97
ii libcloog-isl4 0.18.1-3
ii libgmp10 2:5.1.3+dfsg-1
ii libisl10 0.12.1-2
ii libmpc31.0.1-1
ii libmpfr4 3.1.2-1
ii libstdc++-4.8-dev 4.8.2-14
ii zlib1g 1:1.2.8.dfsg-1
g++-4.8 recommends no packages.
Versions of packages g++-4.8 suggests:
pn g++-4.8-multilibnone
ii gcc-4.8-doc 4.8.2-2
pn libstdc++6-4.8-dbg 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#734164: console-data: should conflict with console-setup
Hey, On Sat, Jan 11, 2014 at 07:42:34PM +0200, Anton Zinoviev wrote: anyway, i don't know whether i'm talking about console-data at all at this point, because things are such a mess. it's where i configured my keymap, in any case. previously. open /etc/init.d/kbd and look for HAVE_SETUPCON. I didn't realise this. /etc/init.d/kbd belongs to kbd but uses configuration provided by console-data. This is indeed such a mess... By the way, if you uninstall kbd and install console-tools, then console-setup won't necessarily make the configuration of console-data ineffective. :) Anyways, I am adding the maintainers of kbd and console-tools to the CC list of this message. I think the best thing to do (in terms of maintainability) is to remove from kbd, console-tools and console-data any Debconf related stuff and any /etc/init.d scripts. If there is something that the scripts of console-setup don't currently do, then bug reports should be filled so that the required functionality will be added in some future version of console-setup. I'm generally on board with removing the kbd init script; it would be conceptually much simpler (or indeed based on a concept in the first place) to have the kbd package ship only the tools needed for font/keymap setup etc., and leave the actual boot-time configuration to console-setup for those users (clearly the majority) who want it. Right now I can think of two points to consider: * The kbd init script offers several things that console-setup doesn't, namely the option to configure different fonts on different consoles, the possibility to modify the keymap through a sed script, the configuration of the screensaver through setterm from util-linux, and the startup of other console-related utilities shipped with kbd (vcstime, kbdrate, setleds). I don't know if these features would be considered a good fit for console-setup; I suspect that all of them are used very rarely. * /etc/init.d/kbd will have to remain on upgrade if /etc/kbd/config has local changes, otherwise some users who don't have console-setup installed might be unable to log in. Things will continue to be confusing for this minority of users. console-tools is gone in sid, so I assume that we don't have to worry about it at all any more. 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#733391: abiword: FTBFS: itex2MML.y:298:25: error: 'ret_str' undeclared (first use in this function)
On 02.02.2014 11:37, Dmitry Smirnov wrote: On Wed, 29 Jan 2014 15:21:46 Markus Koschany wrote: It appears the FTBFS is caused by bison3 and Ubuntu applied this patch for it. Thanks very much for this information, Markus. Too bad on this instance ubuntu developer did not trouble himself sharing the improvement with us or even with upstream. I'd like to think that it was a mere negligence rather than agenda to stay ahead of us with their added value... :( Always look on the bright side of life... *whistle* :-) ...at least one RC bug less! Cheers, Markus signature.asc Description: OpenPGP digital signature
Bug#648965: Bug#736376: RFS: comixcursors/0.8.2-1 -- X11 mouse pointer themes with a comic art feeling
tags 726615 + pending block 726615 by 736376 tags 684869 + pending block 684869 by 736376 tags 708133 + pending block 708133 by 736376 tags 648965 + pending block 648965 by 736376 thanks On 23-Jan-2014, Ben Finney wrote: I am looking for a sponsor for release 0.8.2-1 of “comixcursors”. […] This release fixes these bugs: * bug#726615: New upstream version available, 0.8.2 * bug#684869, bug#708133: Background rendered as semi-transparent grey square for all cursors * bug#648965: update-alternatives not used These bugs have a fix, in a new release pending upload to Debian. Resolving bug#736376 URL:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736376, by sponsoring the upload, will resolve these bugs. -- \ “Please leave your values at the front desk.” —hotel, Paris | `\ | _o__) | Ben Finney b...@benfinney.id.au signature.asc Description: Digital signature
Bug#727708: Processed: block 726763 with 727708
On Sat, Feb 01, 2014 at 06:21:13PM -0800, Cameron Norman wrote: I think there is a huge problem with recommending that systemd be installed by the user changing the init line in grub: a package can not depend on an init system being PID 1. Can a package be made that changes the init line to systemd? I think that is preferable, because it folows the upstream convention of installing systemd by changing the init value, while also allowing packages to depend on systemd being PID 1. There are a few reasonable possibilities for that; see my comments in #736678. I don't particularly like the convention of passing init=, for much the same kind of reason as I'm in favour of the injunction in http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9 that a program must not depend on environment variables to get reasonable defaults; the set of boot parameters is user-visible configuration, and I think that the preferred init on any given system, not to mention Debian's default, should be the default value. I can understand the pragmatic reasons for systemd being hooked in using init= while it's a non-default system trying to gain acceptance and to be easy to experiment with on an ad-hoc basis, but as a GRUB maintainer I would prefer that GRUB not need to be involved in the establishment of a default. Furthermore, not everyone uses GRUB and it's going to be pretty tedious to go round all the boot loaders. The de facto interface for making an init system the default is to install it as /sbin/init. While I'm coming at this from a starting point different from Cameron's above - I haven't yet decided whether I think it would be good for packages to be able to depend on specific pid 1 implementations - nevertheless, if we select systemd as the default I would argue that there should be some arrangement in packaging to put it in place as /sbin/init, even if that isn't upstream's advertised method. -- 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#736744: Permission denied issues with blueman
I'd suggest checking /etc/dbus-1/system.d/bluetooth.conf for the following lines: policy at_console=true allow send_destination=org.bluez/ /policy This allows users with the at_console right access to the org.bluez bus. The at_console right should be set by consolekit for local users by default. You could try to remove the at_console requirement to check if your user is lacking it. That would be a consolekit issue then. (Or maybe you are just not logged in locally? Then it would be the expected behavior.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727084: #727084: pyabiword: libabiword-3.0 mini-transition
In order to fix RC bug I just uploaded abiword-3.0.0 to unstable hence I'm raising severity of this bug to serious... -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737387: please support multi-arch
Package: libmpfi0 Version: 1.5.1-2 Severity: wishlist Hi Laurent, could you please add multi-arch support to MPFI? This is the last important dependency of CGAL that does not support multi-arch yet. Thanks, Joachim -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (810, 'stable-updates'), (800, 'stable'), (700, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.7-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737388: debhelper: update dh_installemacsen postinst etc. scripts to newest emacs policy
Package: debhelper Version: 9.20131227 The emacs policy has recently changed; the 2.0.7 version of emacsen-common has a slightly different set of snippets to place in the maintainer scripts (section 5 of the policy). Please could you update debhelper to reflect this change? Thanks! Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721621: [Pkg-nagios-devel] Bug#721621: dependency change s/libradiusclient-ng2/libfreeradius-client2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Daniel, Am 02.09.13 15:22, schrieb Daniel Pocock: libfreeradius-client2 supersedes libradiusclient-ng2 and is 99% the same code libfreeradius-client2 has just entered unstable, so please remove your package dependency on libradiusclient-ng2 I discovered that this is not a drop-in replacement and thus nagios-plugins-standard has unfortunately no check_radius shipped. As upstream is not supporting this right now, this has to be implemented first to switch over to libfreeradius-client2. To fix this for now, I'm falling back to libradiusclient-ng2 until we get support for libfreeradius-client2. Cheers, Jan. - -- Never write mail to w...@spamfalle.info, you have been warned! - -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLuJ34ACgkQ9u6Dud+QFyRyCwCfRWbgVe8nH+QuMawemTNWBcXs IrkAoKNyeUSiRVBdLmy0GKoTpM6elcTy =X/Z0 -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#737202: devscripts-el: fails to upgrade from 'wheezy': ERROR: install script from devscripts-el package failed (during Install devscripts-el for emacs23)
clone 737202 -1 reassign -1 emacsen-common 2.0.7 retitle -1 emacsen-common: incorrectly handles dependencies during emacsXX upgrade thanks Hi Rob, Please do have a look at this one - it's messy :-/ On Fri, Jan 31, 2014 at 09:57:08PM +0900, Tatsuya Kinoshita wrote: On January 31, 2014 at 11:33AM +0100, anbe (at debian.org) wrote: Install emacsen-common for emacs23 [...] install/devscripts-el: Handling emacs23, logged in /tmp/elc_tCbg9i.log ERROR: install script from devscripts-el package failed [...] devscripts.el:19:1:Error: Cannot open load file: mcharset It seems apel's mcharset.elc is not found when byte-compiling. The devscripts-el package depends on apel, so install/devscripts-el called from devscripts-el.postinst succeed, but install/devscripts-el called from emacsen-common or emacsen could fail as above. I've looked into this one. I've applied a temporary patch to devscripts-el to avoid compiling if apel is not compiled, but it seems to me that the source of the breakage is in emacsen-common's handling of dependencies. I thought I had figured out what was going on, but now I have no idea: I simply don't understand why emacs-install was attempting to byte-compile devscripts-el when it had been unpackage earlier on during the upgrade (and hence run the emacs-package-remove script). The only thing I can think is that maybe the wheezy version of emacsen-common's scripts didn't correctly remove the installed marker file. Anyway, I'm uploading a version of devscripts-el which patches around this bug, but it would be nice if it could be fixed properly. This may be by using the new code in the emacs policy (about packages handling their own touch/rm of the installed marker file), but not quite understanding what happened, I'm not convinced that this will solve it. Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721621: [Pkg-nagios-devel] Bug#721621: dependency change s/libradiusclient-ng2/libfreeradius-client2
On 02/02/14 12:09, Jan Wagner wrote: Hi Daniel, Am 02.09.13 15:22, schrieb Daniel Pocock: libfreeradius-client2 supersedes libradiusclient-ng2 and is 99% the same code libfreeradius-client2 has just entered unstable, so please remove your package dependency on libradiusclient-ng2 I discovered that this is not a drop-in replacement and thus nagios-plugins-standard has unfortunately no check_radius shipped. As upstream is not supporting this right now, this has to be implemented first to switch over to libfreeradius-client2. To fix this for now, I'm falling back to libradiusclient-ng2 until we get support for libfreeradius-client2. libradiusclient-ng2 may well be orphaned and removed from jessie Please have a look at the patch we applied on the Asterisk package to use freeradius-client, it is very trivial -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737384: Should use GTK+2 useful for LXDE and Xfce users
On Sun, 2 Feb 2014 11:42:22 Mateusz Łukasik wrote: since 2.0 version galculator uses GTK+3 libralies, but it isn't good for LXDE and Xfce How/why it isn't good? Last time I checked galculator were looking just fine in XFCE... Did you check with upstream if he wants to continue supporting GTK-2? IMHO there is no harm in moving to GTK-3 and the dependency burden from GTK-3 is little... -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- It is impossible to imagine Goethe or Beethoven being good at billiards or golf. -- H. L. Mencken -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737390: RFS: kerneltop/0.91-1 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package kerneltop * Package name: kerneltop Version : 0.91-1 Upstream Author : Randy Dunlap rdun...@infradead.org * URL : http://www.infradead.org/~rdunlap/src/ * License : GPL-2+ Section : devel It builds those binary packages: kerneltop - shows Linux kernel function usage in a style like top To access further information about this package, please visit the following URL: http://mentors.debian.net/package/kerneltop Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/k/kerneltop/kerneltop_0.91-1.dsc Changes since the last upload: * Closes orphaned bug (closes: #729381) * Migration to dh * Updated copyright and FSF address * Migration to format 3.0 * Restored proper versioning * New upstream version * Updated project homepage -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Bug#414385: Removing RC buggy leaf packages with low popularity?
On Sat, Jan 25, 2014 at 03:30:47PM +0100, Olof Johansson wrote: On 2014-01-25 14:46 +0100, Salvatore Bonaccorso wrote: Hi, On Fri, Jan 24, 2014 at 09:19:26PM +0100, intrigeri wrote: libimdb-film-perl [popcon:13] Fine to remove this one. I adopted it some time ago into the group, for pushing the libdigest-sha1-perl removal. The RC bug is open since very early, to not let libimdb-film-perl, as the imdb.com website is likely to change during the lifetime of a stabel release to cite the former maintainer. I personally don't use this module, and wouldn't mind if this is removed. On the other hand, the bug [1] doesn't document any actual issues seen today afaict, and the note about using volatile seems relevant. Also, upstream is active, with releases in 2013. The situation is not unlike those faced by various video fetchers (e.g. libquvi-scripts, youtube-dl etc etc). Of course, it's your choice; I don't really know the burden of maintaining scraping modules and updating them via *-updates. I'm CCing the bug so this discussion is recorded in the relevant place. I think I would tend to agree that we should give the package the benefit of the doubt; closing this bug and dealing with issues as they arise, via stable-updates if needed. But then again I also don't use the module... Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736551: [Pkg-javascript-devel] Bug#736551: Please include jquery-hashchange
Quoting Jerome Charaoui (2014-02-01 18:26:34) Dear Maintainers, I am part of the Javascript team, but not involved in maintaining jQuery plugins specifically. If you're unavailable to integrate this patch and others queued in BTS, and publish an update of jquery-goodies to the archive, I would be happy to upload version 9-1 myself and have it reviewed by a sponsor. Did you consider the option of joining the Javascript team, to help maintain it long-term instead of only this single upload? Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#717330: wrong date and time in notification mail
A simpler and less intrusive change is to edit /etc/init.d/fail2ban and add at the beginning of the file: # see Debian bug #717330 export LC_TIME=C Only 1 file to change. -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Processed: block 726763 with 727708
]] Colin Watson The de facto interface for making an init system the default is to install it as /sbin/init. While I'm coming at this from a starting point different from Cameron's above - I haven't yet decided whether I think it would be good for packages to be able to depend on specific pid 1 implementations - nevertheless, if we select systemd as the default I would argue that there should be some arrangement in packaging to put it in place as /sbin/init, even if that isn't upstream's advertised method. You mean, like installing the systemd-sysv package? (Those packaging choices are done by us in Debian, not upstream.) -- 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#737391: Please package upstream version 0.4.0
Package: libxkbcommon0 Version: 0.3.1-2 Severity: normal This report is to inform you that upstream has just released libxkbcommon 0.4.0. Please package that new release, since it contains a new library called xkbcommon-x11 that I’d like to use in i3lock. Thanks! -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libxkbcommon0 depends on: ii libc6 2.17-93 ii multiarch-support 2.13-38 ii xkb-data 2.5.1-3 libxkbcommon0 recommends no packages. libxkbcommon0 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#737307: libcgal-dev: multiarch support
Hi Marc, I agree that multi-arch support for CGAL would be nice. Unfortunately, MPFI does not support it yet. I've filed a wishlist bug for that. In the meantime I'm going to look at your patch and probably use it as a starting point and see what's needed to complete multi-arch support. Regards, Joachim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737392: Document --terse in dpkg-reconfigure(8)
Package: debconf Version: 1.5.52 Severity: minor Tags: patch --- dpkg-reconfigure.old2014-02-02 14:17:35.0 +0200 +++ dpkg-reconfigure2014-02-02 14:16:50.0 +0200 @@ -62,6 +62,11 @@ However, it may be useful in constrained environments where rewriting the templates database is expensive. +=item B--terse + +Enable terse mode, in which debconf frontends +cut down on the verbiage as much as possible. + =item B-h, B--help Display usage help. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737307: libcgal-dev: multiarch support
On Sun, 2 Feb 2014, Joachim Reichel wrote: Unfortunately, MPFI does not support it yet. I've filed a wishlist bug for that. Thanks. I thought MPFI wasn't a dependency of any of the cgal packages, so this shouldn't block. Qt4 is likely to be a bigger issue, though it seems ok to have a multiarch-ready package before all dependencies are ready, and in any case I am more interested in libcgal-dev than the qt part. -- Marc Glisse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733386:
Hi, Siphon Website - *Extreme* List Builder. http://www.5iphon.com/?ref=55535 Get your free Siphon website and join me! The buzz on this is growing like mad ,so get in early... Simple, dead quick, and ready to build you a *private* email list in seconds. P.S. There's NO charge. Talk soon, Bren To stop getting mails contact me.
Bug#736744: Permission denied issues with blueman
Le 02/02/2014 12:12, Christopher Schramm a écrit : I'd suggest checking /etc/dbus-1/system.d/bluetooth.conf for the following lines: policy at_console=true allow send_destination=org.bluez/ /policy This allows users with the at_console right access to the org.bluez bus. The at_console right should be set by consolekit for local users by default. You could try to remove the at_console requirement to check if your user is lacking it. That would be a consolekit issue then. (Or maybe you are just not logged in locally? Then it would be the expected behavior.) I have that chunk of configuration, and: jpuydt@newton:~$ ck-list-sessions Session2: unix-user = '1000' realname = 'Julien Puydt' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2014-01-26T12:42:19.777255Z' login-session-id = '1' I changed the configuration to at_console='false', restarted dbus and bluetooth, and blueman-browse accepted to run! So for some reason is-local from consolekit and at_console from dbus don't match. It indeed looks like blueman isn't the real problem here... it's further up. It reminds me of another bug I opened: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729134 where I must admit I don't know what the conclusion exactly is! Can this bluetooth issue also be related to bad interactions between lightdm/systemd/dbus/consolekit (and who knows what else...) ? Snark on #debian-science -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737363: higan: crashes when importing or loading unheadered NES ROM
Hi Michael, thanks for all those nice bug reports! I'm quite sure that higan can only import NES games with iNES headers because I saw byuu say they contain crucial information that is needed to generate the manifests. If you can also provide a patch adding a check for iNES headers you are my favourite bug submitter. ;) Cheers, Tobias Am 02.02.2014 00:35, schrieb Michael Gold: When I try to import an NES ROM without an iNES header, higan segfaults. signature.asc Description: OpenPGP digital signature
Bug#736628: procps: ftbfs due to pbuilder problems are not serious
severity 736628 important thanks hi, imho this bug should not stop the transition of procps to testing - not having /sys in a build chroot sounds more like a bug in pbuilder. It builds fine on the Debian buildds and works well - so I'm setting the severity to important. Feel free to rise it again if you think I'm wrong. Thanks, Bernd -- Mit freundlichen Grüßen Bernd Zeimetz Systems Engineer Debian Developer conova communications GmbH Web| http://www.conova.com/ E-Mail | b.zeim...@conova.com Zentrale Salzburg Karolingerstraße 36A 5020 Salzburg Tel | +43 (0) 662 22 00 - 313 Fax | +43 (0) 662 22 00 - 209 Es gelten die Allgemeinen Geschäftsbedingungen der conova communications GmbH, http://www.conova.com/de/agb/ smime.p7s Description: S/MIME cryptographic signature
Bug#737394: RM: cia-clients -- ROM; no longer useful, as cia.vc is down
Package: ftp.debian.org Severity: normal The tools in cia-clients are only useful for use with cia.vc, which has since shut down and is not returning (https://lwn.net/Articles/518955/). Please remove the cia-clients package from the archive. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737395: funny-manpages: Copyright problem
Package: funny-manpages Version: 1.3-5 Severity: serious The contents of /usr/share/doc/funny-manpages/copyright does not at all look as if the package would be DFSG-free: -- snip -- This package was debianized by Pawel Wiecek co...@pwr.wroc.pl on Wed, 10 Dec 1997 01:10:17 +0100. This set of manpages was collected from all over the net. No specific location can be given. Copyright: To the best of my knowledge all of these manpages are free to use and redistribute. The authors are: baby.1fun - unknown, based on man page by Joe Beck b...@cs.ualberta.ca celibacy.1fun - unknown condom.1fun - Ken Maupin mau...@cs.washington.edu flame.1fun - unknown flog.1fun - unknown gong.1fun - unknown grope.1fun - unknown party.1fun - unknown rescrog.1fun- unknown rtfm.1fun - unknown sex.1fun- unknown tm.1fun - unknown xlart.1fun - James McPherson date.1fun - Glen Overby ove...@sendit.nodak.edu echo.1fun - unknown rm.1fun - Matthew Farwell dy...@ibmpcug.co.uk strfry.3fun - ch...@druco.att.com xkill.1fun - Claudio Calvelli clau...@edinburgh.ac.uk uubp.1fun - unknown -- snip -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737396: kscreensaver: locked screen allows any password if a third session (vt9) is also active
Package: kscreensaver Version: 4:4.8.4-5 Justification: causes serious data loss Severity: critical Tags: security Dear Maintainer, after activating tree (kde-)sessions on vt7,vt8 and vt9, one of the sessions does not need having a password entered at the login widget, still, it lets you in. Which session is affected is not clear, seems to be random. Not sure, but it I think even root sessions could be started this way. Thanks -- 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.9-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kscreensaver depends on: ii kde-runtime 4:4.11.3-1 ii kde-workspace-bin 4:4.11.3-2 ii libc6 2.17-97 ii libgl1-mesa-glx [libgl1] 9.1.3-6 ii libglu1-mesa [libglu1]9.0.0-2 ii libkdecore5 4:4.11.3-2 ii libkdeui5 4:4.11.3-2 ii libkexiv2-10 4:4.8.4-1 ii libkio5 4:4.11.3-2 ii libkparts44:4.11.3-2 ii libkscreensaver5 4:4.11.3-2 ii libqt4-opengl 4:4.8.4+dfsg-4 ii libqtcore44:4.8.4+dfsg-4 ii libqtgui4 4:4.8.4+dfsg-4 ii libstdc++64.8.2-10 ii libx11-6 2:1.6.2-1 Versions of packages kscreensaver recommends: ii kde-window-manager4:4.11.3-2 ii kscreensaver-xsavers 4:4.8.4-5 kscreensaver 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#736812: open-vm-tools: drag-and-drop doesnt block and files are transfered incomplete
Hi Norbert! Thanks a lot for your research! After some research and alot more trial and error, I found that there are multiple Issues: 1. the vmblock filesystem is never started 2. the file /usr/bin/vmware-user-suid-wrapper is missing the apparently critical suid bit (I never knew about this bit before) 3. the vmtoolsd instances spawned by vmware-user-suid-wrapper dont handle SIGUSR1 and SIGUSR2 as they should. [...] For Point 1 I attached a fixed etc/init.d/open-vm-tools. It has some things commented out because of Point 3. Actually I'm not sure if all of these changes should go into the init script of open-vm-tool - for running VMs in ESX and managing them via vcenter - especially when they don't have a Desktop enabled at all - I'm not sure if one really wants to have all the dragdrop features and other fancy stuff. It might make more sense to put these things into an extra init script in the open-vm-tools-desktop package, which should ship what you need if you run a Debian installation with a full blown desktop, at least in non-esx installations (vmware player, or however that thing was called :)) Point 2 is easily fixed with chmod 04555 /usr/bin/vmware-user-suid-wrapper. Makes sense. I'll add a dpkg-statoverride. Point 3 is likely for upstream? The issue here is that you cant stop/start the vmblock filesystem as long as anyone is using it. Supposedly you would send a signal to the user daemons, telling them to give up any references to it - but its not handled and instead the user daemon terminates. And another bug would be that the vmxnet driver is not picked up automatically, for this to work you would need to add the module to the initital ramdisk. Along with other m0dules which should have the same problem, but I cant verify it: which version of open-vm-tools are you using now? There is a pre-inst hook in the current version which should load vmxnet before loading pcnet32. I'd guess it should find its way into the initrd, too. But I don't have any oldish vmware installations to give vmxnet a try. These days vmxnet3 is being used, which is shipped with the upstream kernel and happily put into the initrd by default as it is a used module. vmw_pvscsi Actually I've never seen that module in use bevore, I'll have to investigate what I have to do to use it - I guess I have to pass a full disk device into the VM. As it is shipped with the vanilla kernel I would not expect problems. I'm thinking about organizing a bug squashing party here in salzburg around the end of may - maybe you'd like to come so we can bring the package into a useful shape together? I can handle the server/vm parts, but I'm not really a desktop/gui user. Thanks for your work, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718580: ITP: mayan -- Django-based Electronic Document Management System (EDMS)
Hi Matteo, I am just starting to use mayan and I want to ask, if there are already some results for this ITP. This only to give feedback, that I am interested to have this package in Debian as well. Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Bug#707851: Proposed changes on menu systems
Le Sat, Jan 25, 2014 at 02:36:35PM +0100, Markus Koschany a écrit : Charles Plessy wrote: [...] I have read a lot of scepticism about the Debian menu in this thread, and no actual support for it. Perhaps I was trying to be too consensual and proposed an over-complicated solution while it is clear that the FreeDesktop system is superior. Hello Charles, I wanted to clarify that there are also efforts to support both menu systems and that the majority of games already integrate both. https://wiki.debian.org/Games/JessieReleaseGoal In my opinion the policy should at least mention the Debian menu as an alternative menu system, so that all the effort until now was not completely wasted. Menu files are easy to write and once written do not impose more work for the maintainer. If the Debian menu is not mentioned at all in Debian's policy, people will use this as a justification to ignore even wishlist bugs for menu files. Hello Markus, thank you for your feedback. I think that the absence of a feature in the Debian Policy is not a good justification for refusing a patch that is not invasive and does not require further attention. We should assume people's good faith on both sides. Because a counter-argument to yours would be that people will use the presence of the Debian menu in the Debian policy as a justification to file serious bugs on packages and bully maintainers to do a work that they do not want to contribute by themselves. As you probably see in your release goal, there are packages from your own team that have bugs tagged desktop-integration related to menus, which are old of multiple monthes and still not fixed. From this I conclude that the problem is not obstruction from a minority of maintainers, but lack of manpower. In that sense, I am getting concerned that having the Policy encouraging work on the Debian Menu is counter-productive. If there is no vibrant community to keep the Debian Menu alive (and your release goal brilliantly demonstrate that there is not much momentum), then it is better to let it dissapear. Are you yourself a user of the Debian menu ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737393: Processed: cloning 697755, reassign -1 to llvm-3.4
Hi, On 02/02/2014 22:48, Sylvestre Ledru wrote: thanks :) You're welcome ;-) As soon as I will have a bit of free time, I will try to complete the packaging of pocl (free OpenCL implementation) that uses llvm. Do you know if this bug will be addressed soon (ie in a few months) or if I should find a workaround for it (ie ignoring/modifying the output of llvm-config) in pocl packaging ? Regards, Vincent On 02/02/2014 04:48, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: clone 697755 -1 Bug #697755 [llvm-3.3] llvm-3.2: Please, cleanup compilation flags reported by llvm-config Bug 697755 cloned as bug 737393 reassign -1 llvm-3.4 1:3.4-1 Bug #737393 [llvm-3.3] llvm-3.2: Please, cleanup compilation flags reported by llvm-config Bug reassigned from package 'llvm-3.3' to 'llvm-3.4'. No longer marked as found in versions llvm-toolchain-3.3/1:3.3-16. Ignoring request to alter fixed versions of bug #737393 to the same values previously set Bug #737393 [llvm-3.4] llvm-3.2: Please, cleanup compilation flags reported by llvm-config Marked as found in versions llvm-toolchain-3.4/1:3.4-1. thanks Stopping processing here. Please contact me if you need assistance. -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737393: Processed: cloning 697755, reassign -1 to llvm-3.4
On 02/02/2014 14:11, Vincent Danjean wrote: Hi, On 02/02/2014 22:48, Sylvestre Ledru wrote: thanks :) You're welcome ;-) As soon as I will have a bit of free time, I will try to complete the packaging of pocl (free OpenCL implementation) that uses llvm. Do you know if this bug will be addressed soon (ie in a few months) or if I should find a workaround for it (ie ignoring/modifying the output of llvm-config) in pocl packaging ? llvm-config is a nightmare... Here are plenty of pending issues: http://llvm.org/bugs/buglist.cgi?quicksearch=llvm-configlist_id=50584 If you have a workaround, I think it would be faster.. ;) S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734437: [BTS#734437] templates://init-select/{templates} : Final update for English review
On Thu, Jan 30, 2014 at 1:14 AM, Christian PERRIER wrote: Dear Debian maintainer, On Saturday, January 11, 2014, I notified you of the beginning of a review process concerning debconf templates for init-select. The debian-l10n-english contributors have now reviewed these templates, and the final proposed changes are attached to this update to the original bug report. Please review the suggested changes, and if you have any objections, let me know in the next 3 days. However, please try to avoid uploading init-select with these changes right now. The second phase of this process will begin on Sunday, February 02, 2014, when I will coordinate updates to translations of debconf templates. Would you mind waiting on the translation work? I'm going to be making somewhat large adjustments to the program flow and English dialogs, which I would like to upload in the next couple days. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720426: pu: package openssl/1.0.1e-2
Control: tags -1 + pending On Thu, 2014-01-30 at 21:52 +, Adam D. Barratt wrote: On Thu, 2014-01-30 at 22:27 +0100, Kurt Roeckx wrote: On Thu, Jan 30, 2014 at 08:09:44PM +, Adam D. Barratt wrote: On Mon, 2013-09-23 at 09:05 +0200, Kurt Roeckx wrote: On Mon, Sep 23, 2013 at 05:35:23AM +0200, Cyril Brulebois wrote: Kurt Roeckx k...@roeckx.be (2013-08-21): [...] * Enable assembler for the arm targets, and remove armeb. Patch by Riku Voipio riku.voi...@iki.fi (Closes: #676533) * enable ec_nistp_64_gcc_128 on *-amd64 (Closes: #698447) [...] The changes have obviously had significant testing in unstable and testing by now; have any further related changes been required? Have the changes had any testing in a stable environment? There have no changes related to it. I'm also pretty sure that people actually do use that in production. Okay. Please go ahead, bearing in mind that p-u freeze for 7.4 is this coming weekend. Flagged for acceptance. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733145: ITA: read-edid -- hardware information-gathering tool for VESA PnP monitors
Hi, I intend to take over this fine package. It helped me a lot in the past, it would be pleasure to package it. I am currently working on packaging the new version 3.0.0, as the upstream Author informed in this thread. -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Bug#570623: reprepro: please add multiple version management
* Benjamin Drung benjamin.dr...@profitbricks.com [140108 15:51]:
First sorry for my late reply. I must have totally missed your mail.
The first step is to agree on the database layout change. I came up with
two alternatives:
1) Allow duplicate entries in packages.db and sort duplicate entries by
their Debian version. They can be sorted a) upwards or b) downwards.
Depending on the request, we will either search for all versions of a
package, one specific version of the package, or for the latest version
of a package.
2) Rename the key of packages.db to also contain the version of the
package, e.g. sl|3.03-17 or hello_2.8-4 (which delimiter should we
use?). This would allow us to check directly for a specific version of a
package. We need to add a secondary table that allows us to access the
database as described in 1) through the secondary table. This secondary
table will allow duplicate entries and the values of the secondary table
point to the key in packages.db. Depending on the task, we either query
the first or secondary table. The secondary table will be kept in sync
by BerkeleyDB.
In the first case, we need to add a function to iterate over the
duplicate packages to find a specific version. In the second case, we
need to create the secondary table and transform the database.
Which layout do you prefer?
I think that layout is better that better fits the code. Not yet having
looked at the code, I cannot say. I guess 1 might be simpler. In the
case of 2 I think | is fine, as it is already used elsewhere (though
I guess one should make sure reprepro does not allow | in package
names).
Another issue is the sorting of the packages in the database. We need
one function to sort all entries in the table. So we need one function
to sort binary packages and source packages, but we have
binaries_getversion() and source_getversion(). Here's the example code
(without the error handling) of the sorting function:
static int debianversioncompare(UNUSED(DB *db), const DBT *a, const DBT *b) {
char *a_version, *b_version;
int versioncmp;
binaries_getversion(a-data, a_version);
binaries_getversion(b-data, b_version);
dpkgversions_cmp(a_version, b_version, versioncmp);
return versioncmp;
}
Do you have a suggestion how to improve this function?
It sounds quite slow either way. Perhaps the way to go is instead
changing the data format, like having the version first (perhaps even in
preparsed format to speed things up).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737309: meld: segfaults when selecting source for directory comparison
tags 737309 unreproducible moreinfo thanks Hi Philipp, On 02/01/2014 02:43 PM, Philipp Huebner wrote: ... Hi, I am unable to use meld for directory comparisons. As soon as I try to select a drive/folder it crashes. The warnings below only appear right before the crash. debalance@emmagan:~$ meld /usr/bin/meld:172: GtkWarning: gtk_tree_model_filter_get_value: assertion `GTK_TREE_MODEL_FILTER (model)-priv-stamp == iter-stamp' failed gtk.main() /usr/bin/meld:172: Warning: /tmp/buildd/glib2.0-2.36.4/./gobject/gtype.c:4239: type id `0' is invalid gtk.main() /usr/bin/meld:172: Warning: can't peek value table for type `invalid' which is not currently referenced gtk.main() Segmentation fault I tried to reproduce the problem without luck on Sid and Jessie. Could you please add more detailed instructions or logs which could help? Maybe an strace log would be the best. Cheers, Balint signature.asc Description: OpenPGP digital signature
Bug#736758: [Pkg-swan-devel] Bug#736758: strongswan is just too bloated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, Jan 26, 2014 at 11:12:18PM +0100, Yves-Alexis Perez wrote: On Sun, Jan 26, 2014 at 07:03:42PM +0400, Michael Tokarev wrote: Source: strongswan Version: 5.1.0-3~bpo70+1 Severity: normal This is going to be not a trivial bugreport. The subject says it: strongswan is just too bloated. Default install does (or tries to do) so many things which aren't necessary on most of setups, it is just insane. For example, it tries to iteract with dhcp, it opens raw sockets for ARP, it explicitly loads 2 crypto libraries (openssl and gcrypt) using plugins, and so on. Actually, we're indeed considering splitting the strongswan package to have a small default install, fitting common setup, and a larger plugin package. Also, it might help to report that directly upstream, since there's not so much we can do here without upstream help. Splitting the package is more or less like providing an hardcoded list of plugins, so the complains will stay. Regards, - -- Yves-Alexis Perez -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJS7k/BAAoJEG3bU/KmdcClHZwH/3xXJOZE11V9JGgqxz6iOMni YwCBTA/RBCCGSlSmX0NDUP1n4CyycYVi/7jlUtFiHzMHdTf4LfMb47fYGmXXVh3s r/o2Op0IORQkXVlw1BHn8/P6VU+45+9gZmM5oL6LlL2rLVgVhr8IabSsQiHsDHWl J/9Ap/B1G7Sf/Ga5Sk4PB8xcsJxSiltdjIYhFEzoQLQ14aXnYU9sQkOG6LNfgTK+ HS8VKdcPnvE/HgkqIoLB4vLSooo0c8YMNFI8LvpqXeiwDMSLtCh+2BcjlbxqdKKP o/BF1ARRP5kBUBLvOCElJ0vyTB1jIi1/rKy66kd5e3MFKUGIaM0hYW+KtBRBaLU= =HZUB -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#736812: open-vm-tools: drag-and-drop doesnt block and files are transfered incomplete
Hi again, Point 3 is likely for upstream? The issue here is that you cant stop/start the vmblock filesystem as long as anyone is using it. Supposedly you would send a signal to the user daemons, telling them to give up any references to it - but its not handled and instead the user daemon terminates. what I forgot here: upstream ships a pam config, which doesn't find its way into the package into the package yet. I have to investigate what else is missing. I think I'll do everything form scratch, but I just didn't have the time to do so since I took over the maintenance. for /etc/pam.d/vmtoolsd: #%PAM-1.0 auth sufficient pam_unix2.so nullok auth sufficient pam_unix.so shadow nullok auth required pam_unix_auth.so shadow nullok accountsufficient pam_unix2.so accountsufficient pam_unix.so accountrequired pam_unix_acct.so Could you give that a try (I guess it needs some modifications), but it might fix some issues - not sure though. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712696: debian-installer: Add Cinnamon and Mate as alternative DEs.
Hi, On 02.02.2014 02:32, Steven Chamberlain wrote: The bug wasn't closed by spam, but by Ben Hutchings who said: That was the first time it got closed, but the second time it was definitely spam, unless Ben Hutchings changed his mail to: UNITED NATIONSgabrielso...@adinet.com.uy Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542104: closing 542104
close 542104 thanks Feel free to reopen, but AFAICT, there are now touchpad settings in Gnome 3. Hope this helps. Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736148: cloud-init: please upgrade to 0.7.5 for OpenNebula support
Le 2 févr. 2014 10:57, Charles Plessy ple...@debian.org a écrit : Le Mon, Jan 20, 2014 at 11:38:58AM +0100, Olivier Sallou a écrit : Package: cloud-init Version: 0.7.2-3 Severity: wishlist Dear Maintainer, please upgrade in unstable and backports to v0.7.5 that integrates OpenNebula support in cloud-init. I expect to use it in build-debian-cloud to generate OpenNebula virtual machines. Bonjour Olivier, v0.7.5 is not released yet. Would v0.7.4 be enough ? No What i need is opennebula support which is (will?) In 075 So i can wait for this release. Merci Olivier Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan
Bug#734437: [BTS#734437] templates://init-select/{templates} : Final update for English review
Quoting Michael Gilbert (mgilb...@debian.org): Would you mind waiting on the translation work? I'm going to be making somewhat large adjustments to the program flow and English dialogs, which I would like to upload in the next couple days. Sure, I can wait. Do these changes affect the debconf dialogs? signature.asc Description: Digital signature
Bug#737397: gnome-control-center: No option allowing to set touchpad setting for vertical edge scrolling
Package: gnome-control-center Version: 1:3.8.3-4 Severity: normal Dear Maintainer, I can't find a way to activate the vertical edge scrolling settings for touchpad in Gnome (flashback session). Using synclient VertEdgeScroll=1 on the command line works. It seems it would have been possible to re-activate it on resume, with a hack like the script described in http://www.olivierberger.com/weblog/index.php?post/2013/12/29/Touchpad-side-scrolling-enabling-in-gnome-flashback (set through gsettings set org.gnome.settings-daemon.peripherals.input-devices hotplug-command) but that won't work at initial session start. Also, it seems to me that settings are reinitialized to improper defaults by gnome between calls to the hotplug command, which kind of looks like #576456). Thanks in advance. Best regards, -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-control-center depends on: ii accountsservice0.6.34-2 ii apg2.2.3.dfsg.1-2 ii colord 1.0.6-1 ii desktop-file-utils 0.22-1 ii gnome-control-center-data 1:3.8.3-4 ii gnome-desktop3-data3.8.4-2 ii gnome-icon-theme 3.10.0-1 ii gnome-icon-theme-symbolic 3.10.1-1 ii gnome-menus3.8.0-2 ii gnome-settings-daemon 3.8.5-2 ii gsettings-desktop-schemas 3.8.2-2 ii libaccountsservice00.6.34-2 ii libatk1.0-02.10.0-2 ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libcheese-gtk233.10.1-1sid1 ii libcheese7 3.10.1-1sid1 ii libclutter-gtk-1.0-0 1.4.4-3 ii libcolord-gtk1 0.1.25-1.1 ii libcolord1 1.0.6-1 ii libcups2 1.7.1-2 ii libdbus-glib-1-2 0.100.2-1 ii libfontconfig1 2.11.0-2 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libglib2.0-0 2.36.4-1 ii libgnome-bluetooth11 3.8.1-2 ii libgnome-desktop-3-7 3.8.4-2 ii libgoa-1.0-0 3.8.3-2 ii libgtk-3-0 3.8.6-1 ii libgtop2-7 2.28.5-2 ii libibus-1.0-5 1.5.5-1 ii libkrb5-3 1.11.3+dfsg-3+nmu1 ii libnm-glib-vpn10.9.8.0-5 ii libnm-glib40.9.8.0-5 ii libnm-gtk0 0.9.8.4-1 ii libnm-util20.9.8.0-5 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-01.36.0-1+b1 ii libpolkit-gobject-1-0 0.105-4 ii libpulse-mainloop-glib04.0-6+b1 ii libpulse0 4.0-6+b1 ii libpwquality1 1.2.3-1 ii libsmbclient 2:4.1.4+dfsg-3 ii libsocialweb-client2 0.25.20-6 ii libupower-glib10.9.23-2+b1 ii libwacom2 0.8-1 ii libx11-6 2:1.6.2-1 ii libxi6 2:1.7.2-1 ii libxml22.9.1+dfsg1-3 Versions of packages gnome-control-center recommends: ii cups-pk-helper 0.2.5-2 ii gkbd-capplet 3.6.0-1 ii gnome-online-accounts 3.8.3-2 ii gnome-user-guide 3.8.2-1 ii gnome-user-share 3.8.3-1 ii iso-codes 3.50-1 ii mesa-utils 8.1.0-2+b1 ii mousetweaks3.8.0-1 ii network-manager-gnome 0.9.8.4-1 ii ntp1:4.2.6.p5+dfsg-3 ii policykit-1-gnome 0.105-2 ii rygel 0.20.3-1 ii rygel-tracker 0.20.3-1 ii system-config-printer 1.4.3-1 Versions of packages gnome-control-center suggests: ii gnome-screensaver3.6.1-1 ii gstreamer1.0-pulseaudio 1.2.2-1 ii libcanberra-gtk-module 0.30-2 ii libcanberra-gtk3-module 0.30-2 ii x11-xserver-utils7.7+2 -- 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#735202: speakup crashes debian
On 02-02-14 11:29, Geoff Shang wrote: IMHO, tryign to work around the bug isn't the right approach. A bug that will crash the entire system hard needs to be treated as a bug that needs to be fixed. I agree with you. But a missing dependency can also very well be a bug, so I wasn't trying to work around the bug. But indeed, bringing a system completely to a halt does hardly look like a missing dependency issue. Paul signature.asc Description: OpenPGP digital signature
Bug#737398: PTS is confused by trailing commas in Uploaders
Package: qa.debian.org
Severity: minor
Tags: patch
Hi,
It seems that the PTS is confused by fields containing trailing
commas (as inserted by wrap-and-ort -t).
For example on the PTS entry of babelfish, it displays
maint Debian Python Modules Team (a), Etienne Millon (u), Oxan van
Leeuwen (u), (u)
http://packages.qa.debian.org/b/babelfish.html
The attached patch seems to fix the issue by filtering empty strings,
but I'm not too familiar with the PTS source code so testing is
advised.
Thanks!
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
Etienne Millon
Index: www/bin/sources_to_xml.py
===
--- www/bin/sources_to_xml.py (revision 3108)
+++ www/bin/sources_to_xml.py (working copy)
@@ -29,7 +29,8 @@
# Just as address_from_string, it tries to be forgiving about unquoted
# commas in addresses. [PvR]
def addresses_from_string(content):
-return map(address_from_string, re.split('(?=)\s*,\s*', content))
+matches = re.split('(?=)\s*,\s*', content)
+return [address_from_string(m) for m in matches if m]
def add_maintainer_info(child, name, mail, doc):
text = doc.createTextNode(unicode(name, 'UTF-8', 'replace')) # Take care of non-ascii
Bug#737399: coreutils: The command df lists not lle NFS mounted file systems
Package: coreutils Version: 8.21-1 Severity: normal Dear Maintainer, I have found that the command df does not list all NFS mounted file system. This only works with df-a or df-t nfs. In my system five NFS file system are mounted, of which only two are shown in the df or df-t nfs. Only if the option -a is specified lists all file system correctly. For me this is an error in the command df, because the standard behavior should list all file systems. Here is the command output: # df -t nfs Dateisystem 1K-blocksBenutzt Verfügbar Verw% Eingehängt auf diskstation:/volume1/VM 1918213760 698252544 1219858816 37% /mnt/import/vm diskstation:/volume2/Backup_Archive 1918213760 1595099520 323011840 84% /mnt/import/archive # df -a -t nfs Dateisystem1K-blocksBenutzt Verfügbar Verw% Eingehängt auf diskstation:/volume1/Exchange 1918213760 698252544 1219858816 37% /mnt/import/dataexchange diskstation:/volume1/VM 1918213760 698252544 1219858816 37% /mnt/import/vm diskstation:/volume1/Backup_Diskimages1918213760 698252544 1219858816 37% /mnt/import/diskdump diskstation:/volume2/Backup_Filesnapshots 1918213760 1595099520 323011840 84% /mnt/import/rsnapshot diskstation:/volume2/Backup_Archive 1918213760 1595099520 323011840 84% /mnt/import/archive # df Dateisystem 1K-blocksBenutzt Verfügbar Verw% Eingehängt auf /dev/mapper/VGsys-LVroot 657768853936401167664 83% / udev 10240 0 102400% /dev tmpfs 163380848016333281% /run tmpfs 5120 0 51200% /run/lock tmpfs 3267600 032676000% /run/shm /dev/mapper/VGsys-LVhome 657768853596761201628 82% /home /dev/mapper/VGsys-LVvar457897632836441278948 72% /var /dev/mapper/VGsys-LVvm30832636 19070664 11745588 62% /mnt/vm/fast /dev/mapper/VGdata-LVvm 82438832 48532340 33890108 59% /mnt/vm/normal /dev/mapper/VGdata-LVmisc 61796348 42367900 19412064 69% /mnt/share/misc /dev/mapper/VGdata-LVmusic51475068 419253609533324 82% /mnt/share/music /dev/mapper/VGdata-LVphoto51475068 37458180 14000504 73% /mnt/share/photo /dev/mapper/VGdata-LVuserdata 1019013616987328475020 17% /mnt/share/userdata /dev/mapper/VGdata-LVvideo20511356 119090568585916 59% /mnt/share/videostream diskstation:/volume1/VM 1918213760 698252544 1219858816 37% /mnt/import/vm diskstation:/volume2/Backup_Archive 1918213760 1595099520 323011840 84% /mnt/import/archive # df -a Dateisystem1K-blocksBenutzt Verfügbar Verw% Eingehängt auf rootfs 657768853936401167664 83% / sysfs 0 0 0 - /sys proc 0 0 0 - /proc udev 10240 0 10240 0% /dev devpts 0 0 0 - /dev/pts tmpfs16338084801633328 1% /run /dev/mapper/VGsys-LVroot 657768853936401167664 83% / tmpfs 5120 0 5120 0% /run/lock pstore 0 0 0 - /sys/fs/pstore tmpfs3267600 03267600 0% /run/shm fusectl0 0 0 - /sys/fs/fuse/connections /dev/mapper/VGsys-LVhome 657768853599241201380 82% /home /dev/mapper/VGsys-LVvar 457897632836441278948 72% /var /dev/mapper/VGsys-LVvm 30832636 19070664 11745588 62% /mnt/vm/fast /dev/mapper/VGdata-LVvm 82438832 48532340 33890108 59% /mnt/vm/normal /dev/mapper/VGdata-LVmisc 61796348 42367900 19412064 69% /mnt/share/misc /dev/mapper/VGdata-LVmusic 51475068 419253609533324 82% /mnt/share/music /dev/mapper/VGdata-LVphoto 51475068 37458180 14000504 73% /mnt/share/photo /dev/mapper/VGdata-LVuserdata 1019013616987328475020 17% /mnt/share/userdata /dev/mapper/VGdata-LVvideo 20511356 119090568585916 59% /mnt/share/videostream rpc_pipefs 0 0 0 - /run/rpc_pipefs
Bug#737363: higan: crashes when importing or loading unheadered NES ROM
On Sun, Feb 02, 2014 at 13:24:30 +0100, Tobias Hansen wrote:
Hi Michael,
thanks for all those nice bug reports! I'm quite sure that higan can
only import NES games with iNES headers because I saw byuu say they
contain crucial information that is needed to generate the manifests. If
you can also provide a patch adding a check for iNES headers you are my
favourite bug submitter. ;)
ananke/heuristics/famicom.hpp already has a check, but
ananke/famicom.cpp doesn't check for info.markup==. I'll see if I can
propagate a failure from there.
There's an interesting comment at the bottom of that file:
//this currently cannot work:
//game folders discard iNES header required for heuristic detection
//a games database of all commercial Famicom software will be required
string Ananke::syncFamicom(const string pathname) {
return ;
}
...and I see there's already a Super Famicom database.
-- Michael
signature.asc
Description: Digital signature
Bug#737400: ow-shell: missing dependency on tcl/tk
Package: ow-shell Version: 2.8p15-1 Severity: normal Dear Maintainer, owtap is a tcl/tk program, but ow-shell has no dependency on tcl and/or tk. Regards, Stefano -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages ow-shell depends on: ii libc6 2.13-38 ow-shell recommends no packages. Versions of packages ow-shell suggests: ii owserver 2.8p15-1 -- 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#735202: speakup crashes debian
This disagrees with your hypothesis I'll look for a msgid I may not have archived that issue of the digest. Squeeze and wheezy were mentioned in that message and I've been running Jessie/sid for quite a while. The motherboard I have in this amd athelon k8 is a southbridge model not a more recent northbridge model, I only know this since the builder of this computer comes over and cleans it out with compressed air every so often and he checked out the hardware in it for me. On Sun, 2 Feb 2014, Paul Gevers wrote: On 01-02-14 22:12, Jude DaShiell wrote: I understand this bug existed not much prior to the present kernel version from what I read on the spea...@linux-speakup.org mailing list so this bug was carried into this kernel version from at least one earlier version. Do you have an URL or message-id to the discussion that you mean? Does this now agree or disagree with my hypothesis? Paul jude jdash...@shellworld.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736992: [lintian] Moreinfo about rel link with schema.dct
Package: lintian Version: 2.5.21 control: tags -1 + pending Could you check if you do not load an external dtd ? Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737363: higan: crashes when importing or loading unheadered NES ROM
Am 02.02.2014 15:25, schrieb Michael Gold:
There's an interesting comment at the bottom of that file:
//this currently cannot work:
//game folders discard iNES header required for heuristic detection
//a games database of all commercial Famicom software will be required
string Ananke::syncFamicom(const string pathname) {
return ;
}
...and I see there's already a Super Famicom database.
Yes byuu obtained every single SNES game that was released in the US and
dumped them himself to make sure they are all preserved properly.
The section about information accuracy on
http://byuu.org/higan/features/game-library/
describes a bit what's the deal with iNES headers. They are needed to
guess memory mappings but are still imprecise so the memory mapping
itself rather than the iNES header is stored in the game folder format.
Cheers,
Tobias
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709922: ITP: svtplay-dl -- media downloader for play sites (e.g. SVT Play)
On 2014-01-28 23:32 +0100, Per Andersson wrote: Some comments: * The Python Policy 1.4.2 states that /usr/bin/python should be used as interpreter in favour of /usr/bin/env python. [0] * The license is Expat. * Bump Standards-Version to 3.9.5. If you need a sponsor, ping me when the package is ready for another review round and upload. Hi, I've uploaded a new version to mentors.d.n, addressing your comments and importing a new upstream version (0.9.2014.01.18). The source package is available at: https://mentors.debian.net/package/svtplay-dl The git repository for it is at github: https://github.com/olof/debian-svtplay-dl Note that I've been rebasing the master-next branch, but I've pushed the old master-next as archived/20140202/master-next for now, for comparison. Thanks a lot for the review! -- --- | Olof Johansson http://stdlib.se/ | | irc: zibri https://github.com/olof | --- signature.asc Description: Digital signature
Bug#702705: Package vlock and RC bug
Hi, vlock has a RC bug (#702705). I was working on it and requesting help, without success. The bug seems to be in kernel, not in vlock. But vlock was removed from testing. I sent a patch, and Bastien sent other patch, but these patches doesn't solve the problem, only mitigate it. Could be possible apply the patches and change the severity to normal? What should I do? Thanks, kix. -- .''`. Rodolfo García Peñas (kix) k...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 3F48 0B8C C385 AD41 9E28 006A 7B1F 5490 72B7 4923 `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature
Bug#730798: ITA: ldc - LLVM D compiler
retitle 730798 ITA: ldc LLVM D compiler stop Package: wnpp Version: 0.9.1+hg1634-1 I'd like to help on this package and willing to adopt it. I intend to build an updated package and upload to the archive soon (=in the next couple of weeks hopefully), if there are no objections. Konstantinos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737379: glib2.0: FTBFS on powerpc: several GIO tests fail
On Sun, 02 Feb 2014 at 11:43:11 +0100, Emilio Pozuelo Monfort wrote: On 02/02/14 11:18, Simon McVittie wrote: proxy-tests, socket, gdbus-auth, gdbus-threading and gmenumodel are all a GSLice assertion failure. gdbus-peer is a different assertion failure. The gslice assertion is a bug in the valgrind support, already fixed in glib upstream and in our repo. [...] I don't know if the gdbus-peer failure is caused by this or is a different bug. I don't own a working powerpc, and I couldn't reproduce the FTBFS by building the unfixed version 2.38.2-1 on Debian's only powerpc porterbox (partch). I'm now trying 10 repetitions of make -C debian/build/deb/gio check to see whether it's non-deterministic; the first 3 have all passed. I'm going to assume that this patch fixes all of the test failures mentioned in this bug unless we discover otherwise, and close this bug in the changelog; it seems plausible, at least. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735134: perl: rename(1) is ancient
[CCing debian-devel to get feedback on a de facto 'standard' tool]. On Sat, Jan 18, 2014 at 03:34:29PM +, Dominic Hargreaves wrote: On Tue, Jan 14, 2014 at 12:59:04PM -0800, Don Armstrong wrote: On Tue, 14 Jan 2014, Niko Tyni wrote: I suggest something like - package libfile-rename-perl - make it supply a better /usr/bin/rename with the alternatives system libfile-rename-perl is now on its way to NEW. - make the old one from the perl package issue warnings, Recommend libfile-rename-perl for one release cycle I don't know if this is actually necessary. We could just have perl depend on libfile-rename-perl once we remove debian/rename. Or just keep rename as it is currently. But I'm OK with either option so long as /usr/bin/rename keeps the same syntax. I think removing the rename from the Debian package is the best long-term option, otherwise we still end up carrying dead code around. The question of whether we carry around a Depends long-term rather depends on whether users generally consider rename a fundamental part of the perl package. It's certainly become quite a basic tools that I expect to see on Debian systems, but others may disagree. The alternative, of course, is for libfile-rename-perl to just be Standard, without any actual long-term dependencies. So to summarise: for many years the perl package has provided /usr/bin/rename, a stanalone utility implemented in perl. The issue is we don't want to provide the utility from the perl package any more because it's been added locally inside debian/ and is not being maintained. A maintained version is available as a separate package, libfile-rename-perl. The proposals on the table are: 1) Have perl Depend on libfile-rename-perl (and therefore have the latter become Priority: standard) 2) Make libfile-rename-perl be Standard, to match perl, without adding any dependencies. 3) Have perl Recommend libfile-rename-perl for one release cycle and then drop it - optionally with a warning being emitted by the built-in script 4) 2) + 3) combined. Option 1 would imply that the utility is fundamentally a part of using perl, which since it's a standalone command line program which happens to be written in perl, seems wrong. Option 2 is my preferred option because it seems like the 'least surprise' option. 4) can be considered a mostly-harmless enhancement to that, although adding warnings could be irritating or harmful in some circumstances. Any further thoughts or alternative options? 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#737381: glib2.0: FTBFS on armel: param test failed: stderr of child process failed to match: *remove functionality*
Doing a test build on abel to see whether this is reproducible. ARM porters are very welcome to take over, I don't know much about ARM. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737380: glib2.0: FTBFS on mipsel: gapplication test failed: ECHILD was received by waitpid()
Doing a test build on eder to see whether this is reproducible. mips* porters are more than welcome to take over - I know virtually nothing about the mips* architectures. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737402: liblightdm-qt-3-0: Update to version 1.8.6-1 breaks lightdm-kde-greeter 0.3.2.1-2
Package: liblightdm-qt-3-0 Version: 1.9.6-1 Severity: important Dear Maintainer, After upgrading liblightdm-qt-3-0 to 1.8.6-1 I could no longer log in per lightdm-kde-greeter. The problem seems to be a missing symbol in liblightdm- qt-3-0 (excerpt from file /var/log/lightdm/x-0-greeter.log): /usr/sbin/lightdm-kde-greeter: symbol lookup error: /usr/lib/x86_64-linux-gnu /liblightdm-qt-3.so.0: undefined symbol: lightdm_greeter_authenticate_remote and the greeter process exits. As a result, I cannot log in via the KDE Greeter. HTH -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (1001, 'stable'), (51, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/8 CPU cores) Locale: LANG=uk_UA.utf8, LC_CTYPE=uk_UA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages liblightdm-qt-3-0 depends on: ii libc6 2.17-93 ii libgcc1 1:4.8.1-10 ii liblightdm-gobject-1-0 1.2.2-4 ii libqt4-dbus 4:4.8.5+git121-g2a9ea11+dfsg-1 ii libqt4-xml 4:4.8.5+git121-g2a9ea11+dfsg-1 ii libqtcore4 4:4.8.5+git121-g2a9ea11+dfsg-1 ii libqtgui4 4:4.8.5+git121-g2a9ea11+dfsg-1 ii libstdc++6 4.8.1-10 ii multiarch-support 2.13-38 liblightdm-qt-3-0 recommends no packages. liblightdm-qt-3-0 suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
