Bug#759101: please don't warn about having explicitly set M-A:no
Hi, I don't think it's a good idea to create a pedantic warning when a package declares Multi-Arch:no. Some packages just cannot technically be multiarched. Such a package should set Multi-Arch:no explicitly to indicate that the maintainer looked at the problem of multiarching their binary package and decided that the right multiarch value is no. If this was widely adapted, then we could have an archive wide check about which packages have been converted to multiarch (or decided that they cannot be multiarched) and which ones still need to be decided upon. Such information would be useful for cross building where multiarching of packages is important. If a binary package explicitly sets Multi-Arch:no then a maintainer could quickly decide that a certain other source package cannot be cross built instead of first looking into multiarching said binary package. So if anything I'd put a pedantic warning if the Multi-Arch field is *not* explicitly set. But I agree that this needs wider discussion, so probably the best course of action is to not do anything until that discussion happened. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760347: lists.debian.org: New list: debian-dug-nyc
On Tue, 02 Sep 2014, Brian Gupta wrote: Package: lists.debian.org Severity: wishlist Dear Maintainer, Name: debian-dug-nyc (Debian User Group New York City) We need to create a mailing list to coordinate Debian events in New York City. Historically we have used: http://lists.vireo.org/mailman/listinfo/debiannyc However, the list seems to go offline more often than ideal, and we recently lost 4 years of archives. We plan to try reconstruct and migrate the existing archives. Great, for migration I need: a) a list of subscribers (if you don't want to attach them to the bug, drop them to the listmaster role mail) b) the archives in mbox format Thanks Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760350: [pgadmin3] pgadmin crashes every time, 100% reproducible
Package: pgadmin3
Version: 1.18.1-3.pgdg70+1
Severity: important
--- Please enter the report below this line. ---
pgadmin crashes every time when I try to create a new DB:
Here is the bt:
(gdb) bt full
#0 __lll_unlock_elision (lock=0xf46110, private=0) at
../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
No locals.
#1 0x768790d9 in wxMutexInternal::Unlock() () from /usr/lib/x86_64-
linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#2 0x0062617a in frmMain::OnSelRightClick (this=0x19ee620, event=...)
at frm/events.cpp:751
item = {m_pItem = 0x1ba7c00}
#3 0x7687b61c in
wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const,
wxEvtHandler*, wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#4 0x7687b6d3 in wxEventHashTable::HandleEvent(wxEvent,
wxEvtHandler*)
() from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#5 0x7687ba6b in wxEvtHandler::ProcessEvent(wxEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#6 0x7687b9e0 in wxEvtHandler::ProcessEvent(wxEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#7 0x772295f9 in wxWindowBase::TryParent(wxEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#8 0x7687b9e0 in wxEvtHandler::ProcessEvent(wxEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#9 0x7726b386 in wxScrollHelperEvtHandler::ProcessEvent(wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#10 0x7727f8dd in wxGenericTreeCtrl::OnMouse(wxMouseEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#11 0x7687b61c in
wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const,
wxEvtHandler*, wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#12 0x7687b6d3 in wxEventHashTable::HandleEvent(wxEvent,
wxEvtHandler*)
() from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#13 0x7687ba6b in wxEvtHandler::ProcessEvent(wxEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#14 0x7687b9e0 in wxEvtHandler::ProcessEvent(wxEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#15 0x7726b386 in wxScrollHelperEvtHandler::ProcessEvent(wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#16 0x7713983f in ?? () from /usr/lib/x86_64-linux-
gnu/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#17 0x7412101f in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-
x11-2.0.so.0
No symbol table info available.
#18 0x72edc415 in g_closure_invoke () from /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0
No symbol table info available.
---Type return to continue, or q return to quit---
#19 0x72eee9dc in ?? () from /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0
No symbol table info available.
#20 0x72ef6d16 in g_signal_emit_valist () from /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0
No symbol table info available.
#21 0x72ef746f in g_signal_emit () from /usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0
No symbol table info available.
#22 0x7423140c in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-
x11-2.0.so.0
No symbol table info available.
#23 0x7411f774 in gtk_propagate_event () from /usr/lib/x86_64-linux-
gnu/libgtk-x11-2.0.so.0
No symbol table info available.
#24 0x7411fbeb in gtk_main_do_event () from /usr/lib/x86_64-linux-
gnu/libgtk-x11-2.0.so.0
No symbol table info available.
#25 0x73d9903c in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-
x11-2.0.so.0
No symbol table info available.
#26 0x72525ecd in g_main_context_dispatch () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
No symbol table info available.
#27 0x725261b8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#28 0x725264e2 in g_main_loop_run () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
No symbol table info available.
#29 0x7411ebc7 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-
x11-2.0.so.0
No symbol table info available.
#30 0x771219ea in wxEventLoop::Run() () from /usr/lib/x86_64-linux-
gnu/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#31 0x771ab8ab in wxAppBase::MainLoop() () from /usr/lib/x86_64-linux-
gnu/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#32 0x768202fa in wxEntry(int, wchar_t**) () from /usr/lib/x86_64-
linux-gnu/libwx_baseu-2.8.so.0
No symbol table info available.
#33 0x0044a5e2 in main (argc=1,
Bug#760351: cpp-netlib: cppnetlibConfig.cmake missing in deb pkg?
Source: cpp-netlib Severity: normal Dear Ximin Luo, I'm trying yo use the cpp-netlib package and link to it when building my program. However, my cmake build setup cannot find cpp-netlib because there are no cmake config files in the deb pkgs. I can find a cppnetlibConfig.cmake.in in the 0.11-devel branch on GitHub and Alioth, which as I understand helps cmake to find cpp-netlib. Was the cppnetlibConfig.cmake.in intentionally not added to the deb pkgs? If so, how to I link to cpp-netlib? If not, can it be added? Thanks a lot, Sten -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-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#752897: rm -rf debian/tmp/usr/share/doc/lucene++-3.0.6/
On Tue, 2014-09-02 at 11:01 +0100, Gianfranco Costamagna wrote:
Il Lunedì 1 Settembre 2014 15:42, Tobias Frost t...@frost.de ha scritto:
Hi Tobias
Hi Gianfranco,
Yes, collab-maint would be indeed the best option and can be done after
the initial upload. So just remove VCS-* for now and re-add once
you've
decided how to go on.
Removed
Back to the package. Sorry, took me longer than expected to take deeper
look, but the review should be complete now. So I think this will be
the
last iteration...
During the review of d/copyright I found those mismatches which might
need clarification:
- ./src/contrib/analyzers/common/analysis/ar/ArabicAnalyzer.cpp
./src/contrib/analyzers/common/analysis/fa/PersianAnalyzer.cpp
seems to be generated from BSD Data. Not sure how they have been
generated and what is the effective license is indeed tricky. Can you
check with upstream how the data is processed and if that is enough to
constitute a new copyright? (However, It would be best if the files
could be autogenerated at build time and the stoplist file distributed
with the tarball.)
For now, I'd recommend to add an comment to d/copyright stating
that the
file has been created using BSD-Licensed data from http://...
https://github.com/luceneplusplus/LucenePlusPlus/issues/70
- ./src/contrib/snowball/libstemmer_c/* is missing in d/copyright
and
it is (as far as can see) an embedded code copy. (Debian source package
snowball). As convenience copies are strongly discouraged, please try
to
patch lucene so it will link against the package version.
(If you find out, this is not feasible, please let me know along with
your reasoning)
https://github.com/luceneplusplus/LucenePlusPlus/issues/71
So, this seems now to be the last two points to be fixed. Then I'll
upload it :)
thanks again, I opened the two above upstream issues, because the problem
is not debian-specific and I'm not in the position of force a system
library
when a custom delta might be needed (and moreover I don't see it used,
as
I wrote on the issue).
So I'll update as soon as I get upstream feedbacks!
Hi again Tobias
Great. Regarding the issue 70 (let me quote it by the issue number), as said
it would be ok for me just to comment the fact in d/copyright (and in a
later
upload act according upstream's decission).
Wonderful, updated
Regarding 71, if you are sure that it won't be used, just use a
debian-specific patch to remove it.
Regarding the submitted issue upstream, please note that according to the
package libstemmer Snowball upstream doesn't build shared libraries,
so they
are Debian-specific.
yes, for the moment I disabled them, I think nobody will complain since the
package is a newly packaged one in debian.
With the next upload we can enable the debian version safely (if upstream
agrees) :)
We can wait for upstreams' reaction, but we can also go on; just decide and
let me know.
Would be nice to go on, in this way ftpmaster can look at the package, since
the freeze is approaching ;)
As soon as the package is accepted I'll take care of ask for a new release,
fixing all this kind of doubts here :)
many thanks again
diff -Nru lucene++-3.0.6/debian/changelog lucene++-3.0.6/debian/changelog
--- lucene++-3.0.6/debian/changelog2014-08-26 12:49:11.0 +0200
+++ lucene++-3.0.6/debian/changelog2014-09-01 12:28:56.0 +0200
@@ -1,10 +1,3 @@
-lucene++ (3.0.6-2) unstable; urgency=medium
-
- * Update copyright file.
- * move doxygen to Build-Depends-Indep.
-
- -- Gianfranco Costamagna costamagnagianfra...@yahoo.it Tue, 26 Aug 2014
11:36:24 +0200
-
lucene++ (3.0.6-1) unstable; urgency=low
* Initial release (Closes: #750148).
diff -Nru lucene++-3.0.6/debian/control lucene++-3.0.6/debian/control
--- lucene++-3.0.6/debian/control2014-08-26 11:36:18.0 +0200
+++ lucene++-3.0.6/debian/control2014-09-01 12:31:42.0 +0200
@@ -17,8 +17,6 @@
Standards-Version: 3.9.5
Section: libs
Homepage: https://github.com/luceneplusplus/LucenePlusPlus
-Vcs-Bzr: https://code.launchpad.net/~ubuntu-unity/lucene++/debian
-Vcs-Browser: http://bazaar.launchpad.net/~ubuntu-unity/lucene++/debian/files
Package: liblucene++-dev
Section: libdevel
diff -Nru lucene++-3.0.6/debian/copyright lucene++-3.0.6/debian/copyright
--- lucene++-3.0.6/debian/copyright2014-08-26 13:01:05.0 +0200
+++ lucene++-3.0.6/debian/copyright2014-09-02 11:33:24.0 +0200
@@ -10,6 +10,16 @@
Copyright: 1999, 2000, 2002 Aladdin Enterprises
License: zlib
+Files:
src/contrib/analyzers/common/analysis/{ar/ArabicAnalyzer.cpp,fa/PersianAnalyzer.cpp}
+Copyright: 2009-2014 Alan Wright
+License: Apache-2.0 or LGPL-3+
+Comment: Generated from
Bug#760352: gnome-shell-extension-brightness-control: Not suitable for jessie
Package: gnome-shell-extension-brightness-control Severity: serious this extension is not working under gnome = 3.12 and as this version of gnome is going into jessie this extension should not. (Also gnome 3.12 has basically this extension built-in; so upstream already said some time ago it will not fix this) I will request removal of the package soon. -- tobi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-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#756117: Resurrecting patch-tracker.d.o
Hi, On Tue, 02 Sep 2014, Colin Watson wrote: On Tue, Sep 02, 2014 at 10:57:19AM +0200, Raphael Hertzog wrote: I saw on #debian-admin that both of you are interested in resurrecting patch-tracker.debian.org. I don't know what are your plans but I would like to suggest you to try to resurrect it within the context of Distro-Tracker aka the software behind http://tracker.debian.org If this is what I need to do then I'm afraid it would cause me no longer to be interested. I think I have the time to pick up the current service and make sure it keeps working, but I'm not going to have time for any major refactoring. Wouldn't a better approach be to resurrect the existing service as-is for the sake of the people who want to use it today, and *then* worry about getting somebody to reimplement it on top of a different framework? I won't forbid anyone from resurrecting it. I was just trying to share my own plans in the hope to get some help :-) I'm not part of DSA and DSA imposes no requirement to merge it in tracker.d.o. So there's no need to worry. Both projects are written in Python so it should not be a full rewrite either. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758116: Please be verbose whether you would like to get your Blend promoted by tasksel
Hi, On Wed, Sep 03, 2014 at 07:45:12AM +0200, Per Andersson wrote: I don't think this is a particularly good measure since the blends are relatively unknown. I think it is not a measure for a sequence but rather a measure whether a Blend should be included or not. For instance I missed multimedia-tasks in my list (for the simple reason that I have not seen any relevant commit since nearly one year). But for sure multimedia is quite important for our users and perhaps the fact that there is a chance to prominently be shown in the installer might be a motivation for multimedia maintainers to review the tasks (both team members who previously commited to Git in CC). $ curl -s 'http://popcon.debian.org/by_inst' | grep -e '-tasks ' 10053 education-tasks 983 355 448 173 7 (Debian Edu Developers) 10929 science-tasks83076 6605836 (Debian Science Team) 11000 junior-tasks 818 0 0 0 818 (Debian Junior) 15895 plasma-widget-smooth-tasks 37071 28514 0 (Salvo Rinaldi) 17234 gis-tasks305 0 0 0 305 (Debian Gis Project) 17279 med-tasks30426 2501117 (Debian Med Packaging Team) 21947 multimedia-tasks 166 0 0 0 166 (Debian Multimedia Maintainers) 32922 games-tasks 57 0 0 057 (Debian Games Team) 34392 debichem-tasks50 0 0 050 (Debichem Team) 35076 ezgo-tasks47 0 0 047 (Debain Ezgo Packaging Team) 41997 tine20-tasks 271311 1 2 (Not in sid) 69244 site-tasks 5 0 0 0 5 (Not in sid) 93698 agenda-tasks 1 1 0 0 0 (Not in sid) (column 3 is install count among active popcon users; descending order) It would also only rate Science, Edu, and Med (in that order) which might be good top candidates anyway, but other blends have zero (0) installations among active popcon users. So in any case, some ordering except popcon install count is necessary. I'd consider alphabetic ordering as sensible enough. I would not (mis)use popcon stats as ordering criterion in this case. I suppose questions regarding ordering can be: 1) What do we think Debian users want to install? 2) Are there any blends in particular good shape? I think both criterions are not as objective as alphabetic order. Think of our language selection menu? Should we try to rank it according to the user base of a certain language or the translation status? I think this gets a clear no. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760119: /devdisk/by-uuid: Is a directory
Hi Michael, On Tue, 02 Sep 2014, Michael Prokop wrote: I'm definitely interested in getting to the root of the problem. Could you please provide output of mount and cat /proc/mounts when running the 3.16 kernel? Here we go: output of mount --- /dev/sda7 on / type btrfs (rw,relatime,ssd,space_cache) devtmpfs on /dev type devtmpfs (rw,relatime,size=4041796k,nr_inodes=1010449,mode=755) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/debug type cgroup (rw,nosuid,nodev,noexec,relatime,debug) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) mqueue on /dev/mqueue type mqueue (rw,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) tmpfs on /run/user type tmpfs (rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) debug on /sys/kernel/debug type debugfs (rw,relatime) /dev/sda3 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=850,iocharset=iso8859-15,shortname=mixed,errors=remount-ro) /dev/sda5 on /xp type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime) /proc/mount rootfs / rootfs rw 0 0 /dev/sda7 / btrfs rw,relatime,ssd,space_cache 0 0 devtmpfs /dev devtmpfs rw,relatime,size=4041796k,nr_inodes=1010449,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0 tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0 cgroup /sys/fs/cgroup/debug cgroup rw,nosuid,nodev,noexec,relatime,debug 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 mqueue /dev/mqueue mqueue rw,relatime 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 tmpfs /run/user tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755 0 0 tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 debug /sys/kernel/debug debugfs rw,relatime 0 0 /dev/sda3 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=850,iocharset=iso8859-15,shortname=mixed,errors=remount-ro 0 0 /dev/sda5 /xp fuseblk rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0 rpc_pipefs /run/rpc_pipefs rpc_pipefs rw,relatime 0 0 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 Norbert PREINING, Norbert http://www.preining.info
Bug#759832:
Hi Lucas, thanks a lot for your report, I'm already working on it. Cheers,
Bug#760266: fio: Please enable RBD support
On Tue, Sep 02, 2014 at 04:09:50PM +0200, Martin Steigerwald wrote: Hi, Please sponsor. Sven sponsored so far, but I bet as AFAIK he is quite busy, he wouldn't if you sponsor it. Sven? FYI Uploaded. Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760353: sssd-common: Startup settings in /etc/default/sssd prevents service (re)start
Package: sssd-common Version: 1.11.6-1 Severity: normal Dear Maintainer, The options passed to the sssd service during startup packaged in ssd-common are: DAEMON_OPTS=-i -f This will prevent a system start or service (re)start, because the -i option forces the service to run in the foreground. The correct options should be: DAEMON_OPTS=-D -f which were the settings in previous versions. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-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 sssd-common depends on: ii init-system-helpers 1.21 ii libbasicobjects0 0.4.0-1 ii libc-ares2 1.10.0-2 ii libc62.19-9 ii libcollection4 0.4.0-1 ii libcomerr2 1.42.11-2 ii libdbus-1-3 1.8.6-2 ii libdhash10.4.0-1 ii libglib2.0-0 2.40.0-4 ii libini-config5 0.4.0-1 ii libk5crypto3 1.12.1+dfsg-7 ii libkeyutils1 1.5.9-5 ii libkrb5-31.12.1+dfsg-7 ii libldap-2.4-22.4.39-1.1+b1 ii libldb1 1:1.1.17-1 ii libnl-3-200 3.2.24-2 ii libnl-route-3-2003.2.24-2 ii libnspr4 2:4.10.7-1 ii libnss3 2:3.17-1 ii libpam0g 1.1.8-3.1 ii libpcre3 1:8.35-3 ii libpopt0 1.16-8 ii libref-array10.4.0-1 ii libselinux1 2.3-1 ii libsss-idmap01.11.6-1 ii libtalloc2 2.1.1-2 ii libtdb1 1.3.0-1.1 ii libtevent0 0.9.21-1 ii python 2.7.8-1 ii python-sss 1.11.6-1 Versions of packages sssd-common recommends: ii bind9-host 1:9.9.5.dfsg-4 ii libnss-sss 1.11.6-1 ii libpam-sss 1.11.6-1 ii libsss-sudo 1.11.6-1 Versions of packages sssd-common suggests: pn apparmornone pn sssd-tools 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#760354: gnupg: --faked-system-time option documented, but not understood
Package: gnupg Version: 1.4.18-2 Severity: minor Tags: upstream man:gpg(1) documents a --faked-system-time option, but gpg doesn't understand the option: % gpg --faked-system-time 0 gpg: Invalid option --faked-system-time Grepping through the source package only found hits for faked-system-time in the documentation. I wanted to use the option to create keys that expired in the past and used faketime instead. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755761: gdm3: Unable to start KDE after last gdm3 upgrade
The problem still persists after the latest updates in testing (KDE, upower, systemd,...). Is there anything more I can do to help track down the problem? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753485: Status of samtools
Hi, currently we have samtools/0.1.19-1 with bug #753485 tagged patch but are missing a confirmation from upstream for this patch. We also have a new upstream version of samtools (1.0) in experimental (that might or might have not applied this patch). Can anybody give some status update what the plan for samtools regarding the Jessie release might be? Alexander, in [1] you wrote: I am currently adapting changes to the latest version of samtools. When I'm done I will contact upstream. Did you succeeded to contact upstream or should we ping again? Thanks a lot to Alexander for his effort to provide a patch Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753485#27 -- 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#739030: severity of 739030 is serious, severity of 755207 is serious
Hello Michael, I saw that you raised the severity of #739030 to a RC level for the upcoming removal of valac-0.16. I prepared an upload that makes it possible to build gmpc with a recent vala. If you're interested in sponsoring this fix, I filed a RFS as #759535. Thanks! -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760356: ITP: python-colorlog -- formatter to use with python's logging module
Package: wnpp Severity: wishlist Owner: Philipp Huebner debala...@debian.org * Package name: python-colorlog Version : 2.4.0 Upstream Author : Sam Clements s...@borntyping.co.uk * URL : https://github.com/borntyping/python-colorlog * License : MIT Programming Lang: Python Description : formatter to use with python's logging module This library allows colors to be placed in the format string, which is mostly useful when paired with a StreamHandler that is outputting to a terminal. This is accomplished by adding a set of terminal color codes to the record before it is used to format the string. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760355: tuxonice-userui: FTBFS - missing include of stdio.h
Package: tuxonice-userui Version: 1.1+dfsg1.gc3bdd83-1 Severity: serious Usertags: goto-cc During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder and pbuilder) the build failed with the following error. [...] cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -O3 -DUSE_FBSPLASH -Wall -O3 -g -I/usr/include/freetype2/ -I. -c mng_callbacks.c -o mng_callbacks.o In file included from /usr/include/libmng_types.h:210:0, from /usr/include/libmng.h:386, from mng_callbacks.c:12: /usr/include/jpeglib.h:954:30: error: unknown type name 'FILE' EXTERN(void) jpeg_stdio_dest JPP((j_compress_ptr cinfo, FILE * outfile)); ^ /usr/include/jpeglib.h:955:29: error: unknown type name 'FILE' EXTERN(void) jpeg_stdio_src JPP((j_decompress_ptr cinfo, FILE * infile)); ^ Makefile:15: recipe for target 'mng_callbacks.o' failed make[3]: *** [mng_callbacks.o] Error 1 The full build log is attached; please do let me know if the problem is unreproducible, in which case I shall try to investigate further. This problem may have surfaced due to changes in the jpeg libraries, in which case the resolution may lie in either the jpeg libraries or tuxonice-userui. Best, Michael tuxonice-userui-build-log.txt.gz Description: application/gunzip pgpJzZ8vIlHFU.pgp Description: PGP signature
Bug#752897: rm -rf debian/tmp/usr/share/doc/lucene++-3.0.6/
Il Mercoledì 3 Settembre 2014 8:24, Tobias Frost t...@debian.org ha scritto:
On Tue, 2014-09-02 at 11:01 +0100, Gianfranco Costamagna wrote:
Il Lunedì 1 Settembre 2014 15:42, Tobias Frost t...@frost.de ha scritto:
Hi Tobias
Hi Gianfranco,
Yes, collab-maint would be indeed the best option and can be done after
the initial upload. So just remove VCS-* for now and re-add once
you've
decided how to go on.
Removed
Back to the package. Sorry, took me longer than expected to take deeper
look, but the review should be complete now. So I think this will be
the
last iteration...
During the review of d/copyright I found those mismatches which might
need clarification:
- ./src/contrib/analyzers/common/analysis/ar/ArabicAnalyzer.cpp
./src/contrib/analyzers/common/analysis/fa/PersianAnalyzer.cpp
seems to be generated from BSD Data. Not sure how they have been
generated and what is the effective license is indeed tricky. Can you
check with upstream how the data is processed and if that is enough to
constitute a new copyright? (However, It would be best if the files
could be autogenerated at build time and the stoplist file distributed
with the tarball.)
For now, I'd recommend to add an comment to d/copyright stating
that the
file has been created using BSD-Licensed data from http://...
https://github.com/luceneplusplus/LucenePlusPlus/issues/70
- ./src/contrib/snowball/libstemmer_c/* is missing in d/copyright
and
it is (as far as can see) an embedded code copy. (Debian source package
snowball). As convenience copies are strongly discouraged, please try
to
patch lucene so it will link against the package version.
(If you find out, this is not feasible, please let me know along with
your reasoning)
https://github.com/luceneplusplus/LucenePlusPlus/issues/71
So, this seems now to be the last two points to be fixed. Then I'll
upload it :)
thanks again, I opened the two above upstream issues, because the problem
is not debian-specific and I'm not in the position of force a system
library
when a custom delta might be needed (and moreover I don't see it used,
as
I wrote on the issue).
So I'll update as soon as I get upstream feedbacks!
Hi again Tobias
Great. Regarding the issue 70 (let me quote it by the issue number), as
said
it would be ok for me just to comment the fact in d/copyright (and in a
later
upload act according upstream's decission).
Wonderful, updated
Regarding 71, if you are sure that it won't be used, just use a
debian-specific patch to remove it.
Regarding the submitted issue upstream, please note that according to the
package libstemmer Snowball upstream doesn't build shared libraries,
so they
are Debian-specific.
yes, for the moment I disabled them, I think nobody will complain since the
package is a newly packaged one in debian.
With the next upload we can enable the debian version safely (if upstream
agrees) :)
We can wait for upstreams' reaction, but we can also go on; just decide and
let me know.
Would be nice to go on, in this way ftpmaster can look at the package, since
the freeze is approaching ;)
As soon as the package is accepted I'll take care of ask for a new release,
fixing all this kind of doubts here :)
many thanks again
diff -Nru lucene++-3.0.6/debian/changelog lucene++-3.0.6/debian/changelog
--- lucene++-3.0.6/debian/changelog2014-08-26 12:49:11.0 +0200
+++ lucene++-3.0.6/debian/changelog2014-09-01 12:28:56.0 +0200
@@ -1,10 +1,3 @@
-lucene++ (3.0.6-2) unstable; urgency=medium
-
- * Update copyright file.
- * move doxygen to Build-Depends-Indep.
-
- -- Gianfranco Costamagna costamagnagianfra...@yahoo.it Tue, 26 Aug 2014
11:36:24 +0200
-
lucene++ (3.0.6-1) unstable; urgency=low
* Initial release (Closes: #750148).
diff -Nru lucene++-3.0.6/debian/control lucene++-3.0.6/debian/control
--- lucene++-3.0.6/debian/control2014-08-26 11:36:18.0 +0200
+++ lucene++-3.0.6/debian/control2014-09-01 12:31:42.0 +0200
@@ -17,8 +17,6 @@
Standards-Version: 3.9.5
Section: libs
Homepage: https://github.com/luceneplusplus/LucenePlusPlus
-Vcs-Bzr: https://code.launchpad.net/~ubuntu-unity/lucene++/debian
-Vcs-Browser: http://bazaar.launchpad.net/~ubuntu-unity/lucene++/debian/files
Package: liblucene++-dev
Section: libdevel
diff -Nru lucene++-3.0.6/debian/copyright lucene++-3.0.6/debian/copyright
--- lucene++-3.0.6/debian/copyright2014-08-26 13:01:05.0 +0200
+++ lucene++-3.0.6/debian/copyright2014-09-02 11:33:24.0 +0200
@@ -10,6 +10,16 @@
Copyright: 1999, 2000, 2002 Aladdin Enterprises
License: zlib
+Files:
src/contrib/analyzers/common/analysis/{ar/ArabicAnalyzer.cpp,fa/PersianAnalyzer.cpp}
+Copyright: 2009-2014 Alan
Bug#760158: dpkg: please implement the new build profiles syntax
Hi, Quoting Guillem Jover (2014-09-02 01:07:08) Thanks for the patch! I'm preemtively merging this locally, and will be doing some testing. At a first glance I see some very minor issues that I'll be fixing (because it's going to be faster that way :) and posting a diff for your peruse. I think I might have comments on some of the design decisions made that AFAIR we left hanging in Paris, but nothing dramatic. :) Thanks! I also have a minor addendum that I found while I implemented the same logic in OCaml for dose3: The not (A xor B) in evaluate_restriction_formula could be better done by doing (A == B). I don't know how well that works in perl because of its types but assuming A and B are booleans, this expresses the same and looks better than xor. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758449: hedgewars: FTBFS with cmake 3.0
Hi Felix, Il Martedì 2 Settembre 2014 22:03, Felix Geyer fge...@debian.org ha scritto: Hi, On Sun, 17 Aug 2014 19:13:28 +0200 Felix Geyer fge...@debian.org wrote: Source: hedgewars Version: 0.9.20.5-7 Severity: normal Tags: patch User: cm...@packages.debian.org Usertags: cmake-3.0 Hi, I have prepared cmake 3.0 in experimental and would like to upload it to unstable soon. hedgewars fails to build from source with cmake 3.0 because of a syntax error on one of the CMakeLists.txt files: CMake Error: Error in cmake code at /tmp/buildd/hedgewars-0.9.20.5/tools/CMakeLists.txt:60: Parse error. Function missing ending ). Instead found bad character with text [. -- Configuring incomplete, errors occurred! This has already been fixed upsteam: https://github.com/hedgewars/hw/commit/b2d1b0d292c71b5a4266c9359280fa32a35ac56d I wouldn't mind doing a team upload for this. However there is a 0.9.20.5-8 in experimental. Gianfranco, is the change in experimental suitable to include in an upload to unstable? I'm so, so sorry I missed this bug. For some reasons I wasn't subscribed to hedgewars BTS and I missed the bug on debian-games :( thanks for manually ccing me and making me aware of this! I'm always there to upload everything I can, I don't want to block a transition or to be a ball and chain for DDs. I'm rebuilding and uploading right now ;) (and of course now I'm subscribed to hedgewars BTW too, receiving double mails now). Cheers, Gianfranco Cheers, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758788: [pkg-cryptsetup-devel] Bug#758788: cryptsetup: Passphrase caching broken in decrypt_keyctl
Hi encountered the exact same problem on a laptop with two different encrypted partition (one for a LVM on a SSD and one for a LVM on a HDD). Setting echo CRYPTTAB_TRIED: $CRYPTTAB_TRIED' at line 36 of the script does NOT work, and in fact it completely prevent the computer to boot, as it gets stuck in an infinite loop complaining about wrong passwphrase. The echo is not displayed at all during this loop. I don't know were the echo goes and I don't know what passphrase is read (I wonder the echo may garble the input). I had to reboot the computer on a live system containing cryptsetup to manually reset everything back to work (running all the commands manually: cryptsetup luksOpen for the two encrypted partitions, vgchange -a y to find the LVM components, mounting everything, mounting /dev, /sys and /proc with --bind, chroot, edit the script to remove the echo, update-initramfs -u -k all to make sure the updated script is in the initramfs, and reboot). So, back to square one, how can we identify the reason why the caching script does not work anymore? best regards, Luc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760350: [pgadmin3] pgadmin crashes every time, 100% reproducible
Re: Bogdan Vatra 2014-09-03 3681993.y8eldTnWdk@zmeu Package: pgadmin3 Version: 1.18.1-3.pgdg70+1 Architecture: amd64 Kernel: Linux 3.14-2-amd64 Debian Release: jessie/sid 500 unstablewww.deb-multimedia.org 500 unstableftp.ro.debian.org 500 stable dl.google.com 1 experimentalftp.debian.org --- Package information. --- Package's Depends field is empty. Hi Bogdan, 1.18.1-3.pgdg70+1 is a Wheezy package. Are you running that on Jessie or Sid? Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760357: lxc: can not start container which used to work after recent system update
Package: lxc Version: 1:1.0.5-2 Severity: important that's what I get when I try to start a container: lxc-start -n sid lxc-start: No such file or directory - failed to read /sys/fs/cgroup/lxc/cpuset.cpus lxc-start: Failed to initialize cpuset for '/lxc' in '/sys/fs/cgroup'. lxc-start: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup//systemd lxc-start: Directory not empty - cgroup_rmdir: failed to delete /sys/fs/cgroup//cgmanager lxc-start: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/ lxc-start: failed creating cgroups lxc-start: failed to spawn 'sid' lxc-start: The container failed to start. lxc-start: Additional information can be obtained by setting the --logfile and --log-priority options. #mount | grep cgroup cgroup on /sys/fs/cgroup type cgroup (rw,relatime,cpuset,cpu,cpuacct,devices,freezer,net_cls,blkio,perf_event) cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,size=12k) systemd on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,name=systemd) lxc-checkconfig Kernel configuration found at /boot/config-3.14-2-amd64 --- Namespaces --- Namespaces: enabled Utsname namespace: enabled Ipc namespace: enabled Pid namespace: enabled User namespace: enabled Network namespace: enabled Multiple /dev/pts instances: enabled --- Control groups --- Cgroup: enabled Cgroup namespace: required Cgroup device: enabled Cgroup sched: enabled Cgroup cpu account: enabled Cgroup memory controller: enabled Cgroup cpuset: enabled --- Misc --- Veth pair device: enabled Macvlan: enabled Vlan: enabled File capabilities: enabled It seems that for some reason Cgroup namespace is missing.. a kernel issue ? --- Cgroup namespace: required cat /proc/cgroups #subsys_namehierarchy num_cgroups enabled cpuset 2 1 1 cpu 2 1 1 cpuacct 2 1 1 memory 0 1 0 devices 2 1 1 freezer 2 1 1 net_cls 2 1 1 blkio 2 1 1 perf_event 2 1 1 dpkg -l | egrep (cgroup|cgmanager|lxc) ii cgmanager 0.30-1 amd64Central cgroup manager daemon ii cgroup-bin 0.41-5 all control and monitor control groups (transitional package) ii cgroup-tools 0.41-5 amd64control and monitor control groups (tools) ii cgroupfs-mount 1.0 all Light-weight package to set up cgroupfs mounts ii libcgmanager0:amd640.30-1 amd64Central cgroup manager daemon (client library) ii libcgroup1:amd64 0.41-5 amd64control and monitor control groups (library) ii lxc1:1.0.5-2 amd64Linux Containers userspace tools ii lxc-stuff 1.0.4-3 all Linux Containers userspace tools (additional utilities) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lxc depends on: ii init-system-helpers 1.21 ii libapparmor1 2.8.0-5.1+b2 ii libc62.19-10 ii libcap2 1:2.24-4 ii libseccomp2 2.1.1-1 ii libselinux1 2.3-1 ii multiarch-support2.19-10 ii python3 3.4.1-1 Versions of packages lxc recommends: ii lua5.2 5.2.3-1 ii rsync 3.1.1-2 Versions of packages lxc suggests: ii debootstrap 1.0.60 -- debconf information: * lxc/directory: /var/lib/lxc lxc/auto: true lxc/shutdown: /usr/bin/lxc-halt lxc/title:
Bug#760329: [INTL:tr] Turkish debconf template translation for icinga2
Sorry, I used the template on the l10n status page. I will update it today. On Sep 3, 2014 8:38 AM, Christian PERRIER bubu...@debian.org wrote: Quoting Mert Dirik (mertdi...@gmail.com): Package: icinga2 Severity: wishlist Tags: l10n patch Please find the attached Turkish translation of icinga2 debconf messages. This file should be put as debian/po/tr.po in your build tree. Hello Mert, There are only 7 translated strings in the file, while the POT file has 13 strings. Can you also translate the extra strings? See attached file.
Bug#760358: please add [SECURITY] subject prefix for debian-lts-announce
Package: lists.debian.org Severity: wishlist Hi, Can you please configure the debian-lts-announce list so it has a subject prefix [SECURITY] , in the same way that debian-security-announce has? Current difference between d-s-a and d-l-a: Subject: [SECURITY] [DSA 3017-1] php-cas security update Subject: [DLA 43-1] eglibc security update Desired situation: Subject: [SECURITY] [DSA 3017-1] php-cas security update Subject: [SECURITY] [DLA 43-1] eglibc security update Thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760350: [pgadmin3] pgadmin crashes every time, 100% reproducible
On Wednesday 03 September 2014 10:01:07 Christoph Berg wrote:
Re: Bogdan Vatra 2014-09-03 3681993.y8eldTnWdk@zmeu
Package: pgadmin3
Version: 1.18.1-3.pgdg70+1
Architecture: amd64
Kernel: Linux 3.14-2-amd64
Debian Release: jessie/sid
500 unstablewww.deb-multimedia.org
500 unstableftp.ro.debian.org
500 stable dl.google.com
1 experimentalftp.debian.org
--- Package information. ---
Package's Depends field is empty.
Hi Bogdan,
1.18.1-3.pgdg70+1 is a Wheezy package. Are you running that on Jessie
or Sid?
Christoph
Hi Christoph,
Ah, I forgot to remove the one from http://apt.postgresql.org/pub/repos/apt/
wheezy-pgdg main :).
Anyway, I just reinstall it now from sid and I have the same problem, here is
the log and the bt:
$ sudo apt-get remove --purge pgadmin3*
bla bla bla
$ sudo apt-get install pgadmin3-dbg
[..]
Luat:1 http://ftp.ro.debian.org/debian/ sid/main pgadmin3-data all 1.18.1-3
[2.435 kB]
Luat:2 http://ftp.ro.debian.org/debian/ sid/main pgadmin3 amd64 1.18.1-3
[2.405 kB]
Luat:3 http://ftp.ro.debian.org/debian/ sid/main pgadmin3-dbg amd64 1.18.1-3
[27,1 MB]
Aduși: 31,9 MB în 3s (9.469 kB/s)
[..]
bogdan@zmeu:~$ gdb pgadmin3
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from pgadmin3...Reading symbols from
/usr/lib/debug//usr/bin/pgadmin3...done.
done.
(gdb) r
Starting program: /usr/bin/pgadmin3
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
11:06:36: Debug: Adding duplicate image handler for 'PNG file'
Program received signal SIGSEGV, Segmentation fault.
__lll_unlock_elision (lock=0xfea040, private=0) at
../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
29 ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such file or
directory.
(gdb) bt full
#0 __lll_unlock_elision (lock=0xfea040, private=0) at
../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
No locals.
#1 0x7603fabe in ?? () from /usr/lib/x86_64-linux-
gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#2 0x0065163a in frmMain::OnSelRightClick (this=0x19a6b80, event=...)
at frm/events.cpp:751
item = {wxItemIdvoid* = {m_pItem = 0x1c13600}, No data fields}
#3 0x75ed71ae in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
wxEventFunctor, wxEvent) const ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#4 0x76073f08 in
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const,
wxEvtHandler*, wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#5 0x7607400b in wxEventHashTable::HandleEvent(wxEvent,
wxEvtHandler*)
() from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#6 0x760743b8 in wxEvtHandler::TryHereOnly(wxEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#7 0x760741c3 in wxEvtHandler::DoTryChain(wxEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#8 0x760744a5 in wxEvtHandler::ProcessEvent(wxEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#9 0x76c51e58 in wxWindowBase::TryAfter(wxEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
No symbol table info available.
#10 0x76cbfbab in wxScrollHelperEvtHandler::ProcessEvent(wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
No symbol table info available.
#11 0x76cda4e9 in wxGenericTreeCtrl::OnMouse(wxMouseEvent) () from
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
No symbol table info available.
#12 0x75ed71ae in wxAppConsoleBase::CallEventHandler(wxEvtHandler*,
wxEventFunctor, wxEvent) const ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#13 0x76073f08 in
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const,
wxEvtHandler*, wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#14 0x7607400b in wxEventHashTable::HandleEvent(wxEvent,
wxEvtHandler*)
() from
Bug#760359: libssh2-1-dev: pkgconfig missing dependency on -lgpg-error
Package: libssh2-1-dev Version: 1.4.3-3 Severity: normal Dear Maintainer, /usr/lib/x86_64-linux-gnu/pkgconfig/libssh2.pc has line: Libs.private: -lgcrypt however, libgcrypt depends on libgpg-error, so static linking fails. This should be: Libs.private: -lgcrypt -lgpg-error -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to ja_JP.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libssh2-1-dev depends on: ii libgcrypt20-dev 1.6.1-3 ii libssh2-11.4.3-3 libssh2-1-dev recommends no packages. libssh2-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#758325: clang: trying to overwrite files from clang-3.3
On Sun, 17 Aug 2014 10:23:27 +0200 Sylvestre Ledru sylves...@debian.org wrote: severity 758325 normal thanks On 16/08/2014 23:31, Bernd Zeimetz wrote: clang fails to install together with clang-3.3: [...] As clang-3.3 will be removed I guess it should be fine to downgrade the bug, but the current state doesn't make regular testing/unstable users happy ;) Yes, I don't really care about 3.3 anymore... We still have it just for bug 753971. Dear Sylvestre, this means that many unstable and testing users (all those who installed 3.3) will stumble over this bug and need to recover from a failed upgrade manually, then check whether the bug was reported already. Can you not just add the right break/replace? Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#760257: RFS: plowshare4/1.0.5-1 -- file sharing tools
On Tue, Sep 2, 2014 at 5:05 AM, Eriberto Mota eribe...@debian.org wrote: tags 760257 moreinfo thanks Hi Carl, 2014-09-02 0:54 GMT-03:00 Carl Suster c...@contraflo.ws: I'm not sure if it's best to wait until that is accepted before attempting to upload this new release? If the package got bumped to the end of the queue then it probably won't have a chance of making it into testing before the jessie freeze, so it would be nice to avoid that. Yes, we need wait your package arrives in testing. Don't worry, we have time (two months). So, I need you notify me when in testing and I will solve this bug quickly for you. Why would you need to wait until the package gets accepted through NEW and migrates to testing before sponsoring a newer version of this package? Assuming the package is ready for upload, you can go ahead and upload it to NEW now without any negative consequences. Carl, it doesn't particularly matter whether a package in NEW is at the front, middle, or end of the queue, because ftpmasters don't review every package in NEW in the order that it got into the queue; it's most certainly not a FIFO queue. That being said, I don't know the exact specifics of how ftpmasters decide which package to review next, but if you're worried about a particular package being stuck in the queue for a long period of time (where long is 1 month), I suggest simply giving them a friendly ping via email. 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#751508: parallel: package building is not idempotent
ping. -- m. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760350: [pgadmin3] pgadmin crashes every time, 100% reproducible
Re: Bogdan Vatra 2014-09-03 2820715.rg99T84yOy@zmeu 1.18.1-3.pgdg70+1 is a Wheezy package. Are you running that on Jessie or Sid? Christoph Hi Christoph, Ah, I forgot to remove the one from http://apt.postgresql.org/pub/repos/apt/ wheezy-pgdg main :). Anyway, I just reinstall it now from sid and I have the same problem, here is the log and the bt: The sid package is crashing in all sorts of ways, there's been several other reports for it. What's new is that you've seen the pgdg70 package crash as well. My theory was that the wx3.0 switch was to blame, but the pgdg70 package depends on wx2.8. 11:06:36: Debug: Adding duplicate image handler for 'PNG file' Fwiw, this warning is probably harmless. Program received signal SIGSEGV, Segmentation fault. __lll_unlock_elision (lock=0xfea040, private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29 29 ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such file or directory. This seems to be an illegal instruction on some machines. Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739030: severity of 739030 is serious, severity of 755207 is serious
On Wed, 03 Sep 2014 at 09:32:26 +0200, Etienne Millon wrote: I prepared an upload that makes it possible to build gmpc with a recent vala. If you're interested in sponsoring this fix, I filed a RFS as #759535. I occasionally use gmpc, and the debdiff looks good, so I'll sponsor this (assuming the build that's running now is successful and the result works). Thanks for maintaining this package. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760257: RFS: plowshare4/1.0.5-1 -- file sharing tools
* Vincent Cheng vch...@debian.org, 2014-09-03, 01:36: Carl, it doesn't particularly matter whether a package in NEW is at the front, middle, or end of the queue, because ftpmasters don't review every package in NEW in the order that it got into the queue; it's most certainly not a FIFO queue. Indeed! https://lists.debian.org/87bpmu2p98@gkar.ganneff.de -- 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#749096: Updated version
El 29/08/14 a les 23:33, Ghislain Vaillant ha escrit: Well, you are supposed to target what's in there in unstable if you want your package to be accepted in the archive. Afterwards, Ubuntu will automatically pick it up for its current development version (14.10 or 15.04) depending on how fast the upload to Debian goes. Regarding support for 14.04, this could be done by requesting a backport from the Ubuntu package of a newer release (14.10 or 15.04) and then adding your 14.04 specific patching to the backported package. OK, understood. So the bottom-line of your answer, if I understand you correctly (taken the fact that the little change in the patch is already too much): Helping downstream distributions happens via other channels, the Debian package is not supposed/allowed to include anything that is unnecessary for Debian unstable. Thanks! Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758325: clang: trying to overwrite files from clang-3.3
On 03/09/2014 10:35, Thibaut Paumard wrote: On Sun, 17 Aug 2014 10:23:27 +0200 Sylvestre Ledru sylves...@debian.org wrote: severity 758325 normal thanks On 16/08/2014 23:31, Bernd Zeimetz wrote: Dear Sylvestre, this means that many unstable and testing users (all those who installed 3.3) will stumble over this bug and need to recover from a failed upgrade manually, then check whether the bug was reported already. Can you not just add the right break/replace? OK. I understand the issue. My bad. Thanks for insisting :) I will fix that in experimental (I have other pending changes in there). Thanks Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759916: MNE v0.8 packaging
Hi Alexandre, On Tue, Sep 02, 2014 at 06:01:03PM +0200, Alexandre Gramfort wrote: By the way we have now release tag v0.8.3 that you can get with uscan. Would you mind testing it also with latest lintian? otherwise I could find some time later this week. It would be great if you could try debian/rules get-orig-source git import-orig --pristine-tar downloaded_tarbal dch -i ... new version ... and test yourself. I'm more than busy with other stuff on my todo list. Please ping the list in case of any trouble. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760360: openclipart: build requires 100 GB of memory, errors ignored
Package: openclipart Version: 1:0.18+dfsg-14 Severity: wishlist Usertags: goto-cc The following is a kind of experience report as I'm not entirely sure whether there is anything wrong with my set up, but I'm seeing the following problem when auto-building the package using pbuilder/cowbuilder: [...] Processing ./office/telephone/mobile_phone_01.svg ** (inkscape:32107): WARNING **: helper-fns::helperfns_read_vector() Unable to convert 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0 to number ** (inkscape:32107): WARNING **: helper-fns::helperfns_read_vector() Unable to convert 0,0,0,0,0.01672,0,0,0,0,0,0,0,0,0,0,0,0,0,0.8916,0 to number ** (inkscape:32107): WARNING **: helper-fns::helperfns_read_vector() Unable to convert 0,0.025022,0.008303,0.375,0,0,0,0,0.07506,0,0,0,0,0.033326,0,0,0,0,0,1 to number ** (inkscape:32107): WARNING **: helper-fns::helperfns_read_vector() Unable to convert 1,0.3285714285714286,0,0,0,0,0,0,0.2571428571428571,0,0,0,1,0,0,1,1,0,0,0 to number ** (inkscape:32107): WARNING **: helper-fns::helperfns_read_vector() Unable to convert ,0.8571428571428572,1,1 to number Killed Processing ./office/telephone/telephone_sauvetage_yves_01.svg Background RRGGBBAA: ff00 Area 0:0:163.286:163.286 exported to 163 x 163 pixels (90 dpi) [...] The reason this was killed was me manually killing that inkscape process running beyond 100 GB of main memory. I'm not quite sure what sort of system the package was originally built on, but requiring that much memory seems hardly practical. Furthermore, having the build continue despite the errors isn't a good idea I believe, as indeed the package build succeeded despite me having killed the conversion process. Best, Michael pgpFIltg5Hsi0.pgp Description: PGP signature
Bug#759804: Correction from author of bug-report.
I'm sorry, my bug-report has mistake. After executing this command (chmod o+x /var/spool/lastfm) problem has disappeared. is not right. I wanted to write: After executing this command (chmod o+w /var/spool/lastfm) problem has disappeared.
Bug#760363: swift-object: Missing init script for swift-object-expirer
Package: swift-object Version: 1.13.1-1 Severity: normal An init script should be provided for the swift-object-expirer daemon that deletes expired object from the cluster. Since only one such daemon per cluster is needed, perhaps it should be packaged separately? -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (400, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/32 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 swift-object depends on: ii dpkg 1.16.15 ii lsb-base 4.1+Debian8+deb7u1 ii python-swift 1.13.1-1 pn python:anynone ii rsync 3.0.9-4 ii swift 1.13.1-1 swift-object recommends no packages. swift-object suggests no packages. -- Configuration Files: /etc/swift/object-expirer.conf changed [not included] /etc/swift/object-server.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760361: linux: chown on NFS4 mounts impossible
Package: linux-image-2.6.32.5-amd64 Severity: grave File: linux Justification: renders package unusable We are having an NFS4 server on Debian Squezze and trying a chown on a client mounting exported directories from that server fails: ~$ chown 1261:201 /home/pcs/lars/foo chown: changing ownership of '/home/pcs/foo': Remote I/O error Stumbled over that because pulsesaudio is not working on newer Ubuntu and SUSE clients. It turned out through a bug report to SUSE using tcpdump that the server returns errors: 43 1.515130 $SERVER_IP $CLIENT_IP NFS 134 V4 Reply (Call In 42) SETATTR Status: Unknown error: 4261412863 See https://bugzilla.novell.com/show_bug.cgi?id=893787 especially https://bugzilla.novell.com/show_bug.cgi?id=893787#c18 -- System Information: Debian Release: 6.0.10 APT prefers squeeze-lts APT policy: (500, 'squeeze-lts'), (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760362: ftp.debian.org: dists/sid/main/Contents-armhf.diff/ should drop old files like others Contents-*.diff/
Package: ftp.debian.org Severity: normal The Debian mirrors still contains files such as dists/sid/main/Contents-armhf.diff/2011-11-24-1415.31.gz. Other arches only have a few weeks back but armhf has multiple years! Please ensure that old files get cleaned up in this directory too. TIA. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756205: gvfs-daemons: gvfsd-metadata continuously does disk accesses
One of gvfs developers posted a patch [1] which might fix this bug. [1] https://bugzilla.gnome.org/show_bug.cgi?id=637095#c50 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760188: ITP: scoop -- concurrent parallel programmming library
Control: tags -1 pending Hi again, I've advanced with the package, and would like to accept your offer for sponsoring this. Please cf http://anonscm.debian.org/cgit/debian-science/packages/scoop.git/ http://www.danielstender.com/buildlogs/scoop_0.7.1-1_amd64.build http://mentors.debian.net/debian/pool/main/s/scoop/scoop_0.7.1-1.dsc Greetings, Daniel On 02.09.2014 08:12, Daniel Stender wrote: On 02.09.2014 06:46, PICCA Frederic-Emmanuel wrote: sorry, here the right adress git://anonscm.debian.org/debian-science/packages/scoop.git Ah, that's already in Git, too. Thanks, Frederic. Greetings, Daniel -- https://qa.debian.org/developer.php?login=debian%40danielstender.com PGP key: 2048R/E41BD2D0 C879 5E41 1ED7 EE80 0F2E 7D0C DBDD 4D96 E41B D2D0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760355: tuxonice-userui: FTBFS - missing include of stdio.h
Control: tags -1 upstream Control: tags 759856 upstream This was already reported by https://bugs.debian.org/759856 and reassigned to libmng. With the 'affects' BTS command, I expected that #759856 would still be visible on the tuxonice-userui PTS page. Anyway, unless stdio.h is included by upstream libmng or libjpeg, upstream tuxonice-userui will want to include it. signature.asc Description: OpenPGP digital signature
Bug#749096: Updated version
Hi Martin, On Wed, Sep 3, 2014 at 2:05 AM, Martin Steghöfer mar...@steghoefer.eu wrote: El 29/08/14 a les 23:33, Ghislain Vaillant ha escrit: Well, you are supposed to target what's in there in unstable if you want your package to be accepted in the archive. Afterwards, Ubuntu will automatically pick it up for its current development version (14.10 or 15.04) depending on how fast the upload to Debian goes. Regarding support for 14.04, this could be done by requesting a backport from the Ubuntu package of a newer release (14.10 or 15.04) and then adding your 14.04 specific patching to the backported package. OK, understood. So the bottom-line of your answer, if I understand you correctly (taken the fact that the little change in the patch is already too much): Helping downstream distributions happens via other channels, the Debian package is not supposed/allowed to include anything that is unnecessary for Debian unstable. No, there is no rule saying that a package cannot include anything that's unnecessary for sid and/or would benefit downstream distributions. There's nothing that compels maintainers to do so either; it's entirely up to the maintainer. Personally, for my own packages I do my best to eliminate/minimize the diff in my packages for stable backports and Ubuntu/downstream distros in general, even at the cost of introducing extra complexity to that package. Again, it's up to you as maintainer to decide whether you would like to deal with this extra workload, or push it to downstream maintainers/backporters. 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#760364: ITP: python-elasticsearch -- Python client for Elasticsearch
Package: wnpp Severity: wishlist Owner: Michael Fladischer fladischermich...@fladi.at -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-elasticsearch Version : 1.2.0 Upstream Author : Honza Král honza.k...@gmail.com * URL : https://github.com/elasticsearch/elasticsearch-py * License : Apache Programming Lang: Python Description : Python client for Elasticsearch Official low-level client for Elasticsearch. Its goal is to provide common ground for all Elasticsearch-related code in Python; because of this it tries to be opinion-free and very extendable. The client's features include: * translating basic Python data types to and from json (datetimes are not decoded for performance reasons) * configurable automatic discovery of cluster nodes * persistent connections * load balancing (with pluggable selection strategy) across all available nodes * failed connection penalization (time based - failed connections won't be retried until a timeout is reached) * thread safety * pluggable architecture -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUBt48AAoJEGlMre9Rx7W2l3IQAKAg3CTH95+Sy4hT+cgVM1LZ xfOcbyAN7+tgHGqeLu9rsh5BleyvQE9Miw8o/B2FIGTkCjGbZUo0Kj/bJufDYcgF Vq9HuXdjZz7Bxim71K+EpQMktEM7/OaBzxVeSAJuO/0j9DPdKmi3v7YbZyARjkEq Ie5MJgALbrTOhpFfvpuop2PhduUDBHFksHJ887kjTOSL13hy9gys5C5qfbtUVq+L aSnUURTTuB2qoIvz5ta2GE4n91UIml09P5dSVKtij1DbTeEYOQsh6scmUUj7GH2m 0im1y2IHPNqkXQDKqpjOWNVk31KGEosOoQ722u17Vv5+nDWLoaBG5c+VNiMfYTEC w0JZ4sPygrtDBU3cWhl85q/0zZW4c5z70TJGkkN3rO6I3fbxGHsuS2CjNbyM6tpV TVatr9/0M+ykEffbQeX1AbevE23A5WQr1CcLbqB1kgDhG7TaT02pfUMHYa+zX1gx ncSKVztPhPKmQ61gnyBIsRflm3Ipdc3FOza15MjPO6APav+tKrDRlh7verTj5hWC jGsntar+Vv9Tm9TMy9EhaQQJB+ooWl8b0K358VlwcvnJYitQ6iOxmFXSQud0rUHx CsnmDcWxnqPitbpEdZLmMYiTLgmLHqgxvcG26oYYSE1qj4z+oZck70Ey+YcAvA8r wM9QYGFpcxyOw2iJxq8X =2p9j -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#749096: Updated version
Le 03/09/2014 11:05, Martin Steghöfer a écrit : El 29/08/14 a les 23:33, Ghislain Vaillant ha escrit: Well, you are supposed to target what's in there in unstable if you want your package to be accepted in the archive. Afterwards, Ubuntu will automatically pick it up for its current development version (14.10 or 15.04) depending on how fast the upload to Debian goes. Regarding support for 14.04, this could be done by requesting a backport from the Ubuntu package of a newer release (14.10 or 15.04) and then adding your 14.04 specific patching to the backported package. OK, understood. So the bottom-line of your answer, if I understand you correctly (taken the fact that the little change in the patch is already too much): Helping downstream distributions happens via other channels, the Debian package is not supposed/allowed to include anything that is unnecessary for Debian unstable. Thanks! Martin Dear Martin, I think you are over-interpreting what Ghislain wrote. What he said is rather that your package will likely build unmodified on the next release of Ubuntu, if not on the current one, because Ubuntu will also upgrade there version of libav. You don't *have* to go out of your way to ease the downstream work. Likewise, you don't *have* to make any efforts to make it easier to backport your package to older versions of Debian. However, when it is practical, it is good practice to make the adjustments that will make your package compile unmodified on Debian stable and up-to-date derivative distributions. On the other hand you don't want to obfuscate your package just for the sake of backports. If the patch becomes unreadable, your sponsor will give up on checking it. In the end, it's up to you (and your sponsor) to decide the level of complexity you want to allow in your package. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Tuesday 02 September 2014 01:33 PM, Ritesh Raj Sarraf wrote: Could you elaborate a bit more, why those are needed? What is upstream doing about this? The block storage has many components that work closely with one another. Take an example, root fs on LVM on Multipath on iSCSI. The flow for such a setup is to: 1) Start iSCSI and discover the LUNs 2) Detect and create mulitpath maps for matching LUNs in DM Multipath 3) Detect and Activate Volume Group out of the newly detected DM Multipath Physical Volumes 4) Mount the file system. The same can be applied to the shutdown sequence. You want to have proper checks in place before initiating a shutdown of the service. One would argue that the service should not stop if it has active services. Many of the services (mulitpath, iscsi, for example) have a 2 part component. One in the kernel and the other in userspace. The kernel space service will not terminate if any service is active. But the userspace is not so forgiving. In open-iscsi, if you ask the daemon to shutdown, it will. If there are active sessions, the kernel component will not terminate the current sessions. But the userspace daemon will be shutdown. That means, that when there is the next state failure, open-iscsi will have no idea of determining that a LUN state has changed Similar is the case with DM Multipath. The userspace DM Multipath daemon is responsible for polling and keeping an up-to-date status of the Device Mapper maps. If the userspace daemon is inactive, and underneath there is a fabric state change, there is no way to propagate that error to the upper layers. These design issues, since they are part of the core storage stack, if triggered, leave you with a machine with no access to your root disk. Any process at that time, may get into a 'DI' process state or an immediate device failure. The only action then would be to hardware reset your machine. This is why we do a lot of checks in the init scripts to warn the user. Similar approaches were taken in RHEL (5 and 6) and SLES (10 and 11). I'm not sure what Red Hat or SUSE has chosen for their latest releases, as I don't work on those products any more. My inclination is to ship both, the systemd service files and the init scripts, in their current form along with whatever limitations each may have, and let the user choose. Hi, I did not get any comment on this. How are others doing similar stuff while migrating to systemd ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749096: Updated version
Thanks for the clarification, Vincent! Cheers, Martin El 03/09/14 a les 11:22, Vincent Cheng ha escrit: Hi Martin, No, there is no rule saying that a package cannot include anything that's unnecessary for sid and/or would benefit downstream distributions. There's nothing that compels maintainers to do so either; it's entirely up to the maintainer. Personally, for my own packages I do my best to eliminate/minimize the diff in my packages for stable backports and Ubuntu/downstream distros in general, even at the cost of introducing extra complexity to that package. Again, it's up to you as maintainer to decide whether you would like to deal with this extra workload, or push it to downstream maintainers/backporters. 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#703969: git-buildpackage: Always tries to run cowbuilder even with --git-pbuilder
Hi. On Tue, Mar 26, 2013 at 11:43:45AM +0100, John Paul Adrian Glaubitz wrote: the git-pbuilder script always tries to run cowbuilder to build packages, even when using git-buildpackage --git-pbuilder to build: I'm not sure I understand your point (and I'm not an expert in pbuilder/cowbuilder or gbp, so maybe it's obvious), as I'm reading the manpage : git-pbuilder is a wrapper around pdebuild intended for use by git-buildpackage. It configures pdebuild to use cowbuilder by default, Maybe you wanted to configure it so it doesn't use the default, and that doesn't work ? 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#760365: qemu-system-x86: Showing Could not initialize SDL(No available video device) since last upgrade
Package: qemu-system-x86 Version: 2.1+dfsg-2 Severity: important I've been running qemu-system-x86_64 -display sdl [..] for months without problems. Now it shows an error Could not initialize SDL(No available video device) - exiting I'm hoping for a soon fix. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qemu-system-x86 depends on: ii ipxe-qemu 1.0.0+git-2013.c3d1e78-2 ii libaio1 0.3.109-4 ii libasound2 1.0.28-1 ii libbluetooth3 5.21-3 ii libbrlapi0.65.0-2+b1 ii libc6 2.19-10 ii libcurl3-gnutls 7.37.1-1 ii libfdt1 1.4.0+dfsg-1 ii libgcc1 1:4.9.1-4 ii libglib2.0-02.40.0-5 ii libgnutls-deb0-28 3.3.6-2 ii libiscsi2 1.12.0-2 ii libjpeg88d1-1 ii libncurses5 5.9+20140712-2 ii libpixman-1-0 0.32.6-3 ii libpng12-0 1.2.50-2 ii libpulse0 5.0-6 ii librados2 0.80.5-1 ii librbd1 0.80.5-1 ii libsasl2-2 2.1.26.dfsg1-11 ii libsdl1.2debian 1.2.15-10 ii libseccomp2 2.1.1-1 ii libspice-server10.12.5-1 ii libssh2-1 1.4.3-3 ii libtinfo5 5.9+20140712-2 ii libusb-1.0-02:1.0.19-1 ii libusbredirparser1 0.7-1 ii libuuid12.20.1-5.8 ii libvdeplug2 2.3.2-4 ii libx11-62:1.6.2-3 ii libxen-4.3 4.3.0-3+b1 ii libxenstore3.0 4.4.0-2 ii qemu-system-common 2.1+dfsg-2 ii seabios 1.7.5-1 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages qemu-system-x86 recommends: ii qemu-utils 2.1+dfsg-2 Versions of packages qemu-system-x86 suggests: ii kmod 18-1 pn ovmf none pn sambanone pn sgabios none pn vde2 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#760366: gdm3: Stopped showing any users, no way to log in
Package: gdm3 Version: 3.12.2-2.1 Severity: important Since I upgraded my system today, gdm3 does not show any users for selection and no input fields asking for user names or passwords. So log-in to anyone is not possible. I needed to switch to another terminal and install kdm. I'm hoping for a quick fix so I can switch back to gdm3. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gdm3 depends on: ii accountsservice0.6.37-3 ii adduser3.113+nmu3 ii dconf-cli 0.20.0-2 ii dconf-gsettings-backend0.20.0-2 ii debconf [debconf-2.0] 1.5.53 ii gir1.2-gdm33.12.2-2.1 ii gnome-session-bin 3.12.1-3 ii gnome-settings-daemon 3.12.2-1+b1 ii gnome-shell3.12.2-3 ii gsettings-desktop-schemas 3.12.2-1 ii guake [x-terminal-emulator]0.4.4-1 ii libaccountsservice00.6.37-3 ii libatk1.0-02.12.0-1 ii libaudit1 1:2.3.7-1 ii libc6 2.19-10 ii libcairo-gobject2 1.12.16-3 ii libcairo2 1.12.16-3 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgdm13.12.2-2.1 ii libglib2.0-0 2.40.0-5 ii libglib2.0-bin 2.40.0-5 ii libgtk-3-0 3.12.2-3+b1 ii libpam-modules 1.1.8-3.1 ii libpam-runtime 1.1.8-3.1 ii libpam-systemd 208-8 ii libpam0g 1.1.8-3.1 ii libpango-1.0-0 1.36.6-1 ii libpangocairo-1.0-01.36.6-1 ii librsvg2-common2.40.3-1 ii libselinux12.3-1 ii libsystemd-daemon0 208-8 ii libsystemd-id128-0 208-8 ii libsystemd-journal0208-8 ii libsystemd-login0 208-8 ii libwrap0 7.6.q-25 ii libx11-6 2:1.6.2-3 ii libxau61:1.0.8-1 ii libxdmcp6 1:1.1.1-1 ii libxrandr2 2:1.4.2-1 ii lsb-base 4.1+Debian13 ii metacity [x-window-manager]1:3.12.0-2 ii policykit-10.105-6.1 ii ucf3.0030 ii x11-common 1:7.7+7 ii x11-xserver-utils 7.7+3 ii xfce4-session [x-session-manager] 4.10.1-8 ii xfwm4 [x-window-manager] 4.10.1-2 ii xterm [x-terminal-emulator]308-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.12.0-2 ii desktop-base 7.0.3 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii x11-xkb-utils 7.7+1 ii xserver-xephyr 2:1.16.0-1 ii xserver-xorg 1:7.7+7 ii zenity 3.12.1-1.1 Versions of packages gdm3 suggests: pn gnome-orcanone ii libpam-gnome-keyring 3.12.2-1 -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703969: git-buildpackage: Always tries to run cowbuilder even with --git-pbuilder
On 09/03/2014 11:30 AM, Olivier Berger wrote: Maybe you wanted to configure it so it doesn't use the default, and that doesn't work ? No. Look at the source code. git-buildpackage should run pbuilder when you invoke it with --git-pbuilder and that simply doesn't work. This isn't a question about the default configuration when I explicitly tell the script to use pbuilder instead of cowbuilder: glaubitz@z6:..debian/z80ex-debian git-buildpackage --git-pbuilder Base directory /var/cache/pbuilder/base.cow does not exist gbp:error: 'git-pbuilder' failed: it exited with 1 glaubitz@z6:..debian/z80ex-debian git-pbuilder Base directory /var/cache/pbuilder/base.cow does not exist glaubitz@z6:..debian/z80ex-debian Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749096: Updated version
Hi Thibaut, Thanks for the clarification to you, too. I'm sorry I misread Ghislain's answer. I interpreted it in the specific context of the commit I had referenced in my first message as an example, which IMO introduces very little additional complexity - although it may seem somewhat complex in the link I've given, due to the representation as a git diff of a patch. But I understand that it may not even be necessary, as Ubuntu will have Libav10 at the time they pick up the package. Cheers, Martin El 03/09/14 a les 11:30, Thibaut Paumard ha escrit: Dear Martin, I think you are over-interpreting what Ghislain wrote. What he said is rather that your package will likely build unmodified on the next release of Ubuntu, if not on the current one, because Ubuntu will also upgrade there version of libav. You don't *have* to go out of your way to ease the downstream work. Likewise, you don't *have* to make any efforts to make it easier to backport your package to older versions of Debian. However, when it is practical, it is good practice to make the adjustments that will make your package compile unmodified on Debian stable and up-to-date derivative distributions. On the other hand you don't want to obfuscate your package just for the sake of backports. If the patch becomes unreadable, your sponsor will give up on checking it. In the end, it's up to you (and your sponsor) to decide the level of complexity you want to allow in your package. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757308: grass: Please update to use wxpython3.0
On Wed, Aug 20, 2014 at 05:53:18PM +1200, Hamish wrote: Hamish wrote: grass 6.4.4.packaging is currently (basically) ready in DebianGIS git. Sebastiaan: But not by using git-import-orig. The upstream branch hasn't been updated with the grass_6.4.4.orig.tar.gz contents. it was done in the master branch, http://git.linuxminded.nl/?p=pkg-grass/grass;a=commit;h=d183a32b883dbad88e0d751d030e177dd90926a0 tagging is currently incomplete, but known todo and discussed privately. ... Do you mind to discuss NOT privately? You should run lintian showing all tags after your build to get an idea of what is left to fix before I would consider an upload. er, you really think we don't do that and know exactly what they are? We've been busy packaging this software for more than a dozen years! Not masking false positives and real but won't-fix in this major version lintian issues is not a bug IMHO. Bas, the grass package has a long list of lintian issues due mainly to specific choices of upstream team and historical reasons. It is quite pointless trying to respect the full policy by patching at every new release, and it would be also an heavy job (with no hopes of being accepted upstream for merging). This is well expected for such a scientific program born in the 80s and having a very conservative and tiny development team. No doubt the main rules file could use a bit of a refresh here and there (supporting 'make -j' would be nice), but let's continue this conversation on the DebainGIS list, not in a ticket about transitioning to wxpython3.0. I don't understand *why* the d-gis repo is not already up-to-date with an appropriate branching and tagging for the proper support. It is quite annoying working with yet-another-git-archive. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760230: ITP: python-sk1libs -- Set of python non-GUI extensions for sK1 Project
On Tue, Sep 02, 2014 at 11:58:18AM +0200, Agustin Martin wrote: On Mon, Sep 01, 2014 at 03:54:31PM -0700, Javi Merino wrote: Package: wnpp Severity: wishlist Owner: Javi Merino vi...@debian.org * Package name: python-sk1libs Version : 0.9.1 Upstream Author : Igor E. Novikov igor.e.novi...@gmail.com * URL : http://sk1project.org/modules.php?name=Productsproduct=sk1 * License : LGPL-2+ Programming Lang: Python, C Description : Set of python non-GUI extensions for sK1 Project sk1libs is a set of python non-GUI extensions for sK1 Project. The package includes multiplatform non-GUI extensions which are usually native extensions. This package is a dependency of the new upstream version of python-uniconvertor . It'll be maintained in the Python Modules Team. Hi, Javi, Note that original sources name is sk1libs, even if I named my git repo python-sk1libs. sk1libs is also what is used in my pristine-tar branch. I know, but I've changed the source package name to python-sk1libs to make it consistent with the binary package. Cheers, Javi signature.asc Description: Digital signature
Bug#760367: whatmaps: [INTL:ja] New Japanese debconf translation
Package: whatmaps Version: 0.0.8-3 Severity: wishlist Tags: patch l10n Dear whatmaps package maintainer, Here's Japanese po-debconf template translation (ja.po) file that reviewed by several Japanese Debian developers and users. Could you apply it, please? -- victory http://userscripts.org/scripts/show/102724 0.0.1.4 http://userscripts.org/scripts/show/163846 0.0.1 http://userscripts.org/scripts/show/163848 0.0.1 -- victory no need to CC me :-) http://userscripts.org/scripts/show/102724 0.0.1.4 http://userscripts.org/scripts/show/163846 0.0.1 http://userscripts.org/scripts/show/163848 0.0.1 whatmaps-0.0.8-3-ja.po.gz Description: Binary data
Bug#760365: Forgot to mention sudo
I forget to mention I use sudo (and always have been): # sudo qemu-system-x86_64 -display sdl No protocol specified Could not initialize SDL(No available video device) - exiting Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760365: qemu-system-x86: Showing Could not initialize SDL(No available video device) since last upgrade
On 09/03/2014 11:53 AM, Michael Tokarev wrote: For a start, SDL requires X11, can you run xterm the same way as you're trying to run qemu-system-x86_64? It seems I cannot: # sudo xterm No protocol specified Warning: This program is an suid-root program or is being run by the root user. The full text of the error or warning message cannot be safely formatted in this environment. You may get a more descriptive message by running the program as a non-root user or by removing the suid bit on the executable. xterm: Xt error: Can't open display: %s -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760365: qemu-system-x86: Showing Could not initialize SDL(No available video device) since last upgrade
Control: tag -1 + moreinfo unreproducible 03.09.2014 13:42, Sebastian Pipping wrote: Package: qemu-system-x86 Version: 2.1+dfsg-2 Severity: important I've been running qemu-system-x86_64 -display sdl [..] for months without problems. Now it shows an error Could not initialize SDL(No available video device) - exiting I use that version with sdl here with multiple guests, and it definitely works, just the same way as all previous versions. It also works for version backported to wheezy. I'm hoping for a soon fix. Please provide some more information about your environment. For a start, SDL requires X11, can you run xterm the same way as you're trying to run qemu-system-x86_64? Do you run it as root? So far I don't see what _can_ be fixed because it Just Works. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703969: git-buildpackage: Always tries to run cowbuilder even with --git-pbuilder
On Wed, Sep 03, 2014 at 11:46:02AM +0200, John Paul Adrian Glaubitz wrote: On 09/03/2014 11:30 AM, Olivier Berger wrote: Maybe you wanted to configure it so it doesn't use the default, and that doesn't work ? No. Look at the source code. git-buildpackage should run pbuilder when you invoke it with --git-pbuilder and that simply doesn't work. --git-pbuilder means use git-pbuilder (as documented in the manpage) to build the package. A more correct option name would have been --git-git-pbuilder but that didn't look nice. It will then use the builder configured for git-pbuilder (via the BUILDER environment variable). Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748130: scotch autoremoval from jessie not usefull : only stable/amd64 package has RC bug
Dear all, The RC bug #748130 founded in the scotch library causes to mark for autoremoval many packages in the jessie distribution. Notice that the bug do not concern the actual jessie distribution : it is restricted to the stable one on the amd64 architecture. Recall that, in that specific case, the actual stable/amd64 scotch package links to both mipch and openmpi and this produce a segfault at run time. A simple recompilation of the stable scotch packages for amd64 should fix this bug (see bug #748130 for more). So, the jessie scotch packages are not concerned by this bug and all packages that depend one do not need to be marked for autoremoval. Regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760368: RM: lxshortcut -- deprecated by upstream
Package: ftp.debian.org Severity: normal Please remove the package lxshortcut from Jessie. The source package is deprecated by upstream because the appropriate binary executable now is provided by libfm. In Jessie it is packaged into libfm-tools binary which provides lxshortcut as virtual package and conflicts with the one that I ask you to remove. I am co-maintainer of it, in case you ask that. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703969: git-buildpackage: Always tries to run cowbuilder even with --git-pbuilder
On 09/03/2014 11:54 AM, Guido Günther wrote: --git-pbuilder means use git-pbuilder (as documented in the manpage) to build the package. A more correct option name would have been --git-git-pbuilder but that didn't look nice. It will then use the builder configured for git-pbuilder (via the BUILDER environment variable). Why would a script called git-pbuilder try to run cowbuilder? That doesn't seem logical to me. I would expect the following: git-cowbuilder = run cowbuilder git-pbuilder = run pbuilder git-Xbuilder = run Xbuilder Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492359: [Pkg-openldap-devel] Bug#492359: ldap-utils: ldapsearch fails to connect to MS AD with user certificate
On 20.05.2014 07:08, Ryan Tandy wrote: On 15/02/09 04:56 PM, Quanah Gibson-Mount wrote: --On Monday, February 16, 2009 12:48 AM +0100 Stefan Pietsch stefan.piet...@lsexperts.de wrote: After changing configure.options to --with-tls=openssl and recompiling openldap I can connect to the domain controller. So there seems to be something wrong with GnuTLS. Try with OpenLDAP 2.4.14 or later (not that anything later exists right at this moment. ;) ). Did you ever get a chance to test this with a more recent version of openldap, like Quanah suggested? I don't have access to a Windows domain controller, so I'm not able to verify this bug myself. I can confirm that it works in wheezy with ldap-utils 2.4.31-1+nmu2 and Windows 2003 SP2 on the other side. Regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760369: ircd-irc2: Installation/Upgrade fails and hangs
Package: ircd-irc2 Version: 2.11.2p3~dfsg-2 Severity: normal Did a dist-upgrade, which hung during installation of ircd-irc2 2.11.2p3~dfsg-1. I cancelled the installation with ^C and kill -9 of several processes. Today I retried to discover the source of the problem. In the meantime 2.11.2p3~dfsg-2 appeared with the same problem. Here's the output of dpkg --configure -a: # dpkg --configure -a Setting up ircd-irc2 (2.11.2p3~dfsg-2) ... grep: ^[PM]:: No such file or directory /etc/ircd/ircd.conf:A:This is Debian's default ircd configurations:Please edit your /etc/ircd/ircd.conf file:Contact root@localhost for questions::ExampleNet insserv: warning: current stop runlevel(s) (0 1 6) of script `ircd-irc2' overrides LSB defaults (empty). Starting irc server daemon: ircdWarning: Network name is not set in ircd.conf Server irc.localhost (000A) version 2.11.2p3 starting. ^Cdpkg: error processing package ircd-irc2 (--configure): subprocess installed post-installation script was interrupted Processing triggers for libc-bin (2.19-10) ... Errors were encountered while processing: ircd-irc2 There was an IRC daemon running before. However, I assume it was a different package. The timestamp of the configuration file /etc/ircd/ircd.conf assumes that it was recently installed by the new package. Regards Joey -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages ircd-irc2 depends on: ii libc6 2.19-10 ii zlib1g 1:1.2.8.dfsg-2 ircd-irc2 recommends no packages. ircd-irc2 suggests no packages. -- no debconf information # This is ircd's config-file. Look at # /usr/share/doc/ircd-irc2/ircd.conf.example.gz and # and /usr/share/doc/ircd-irc2/INSTALL.* for more detailled information # and instructions # M-Line M%irc.localhost%%Debian ircd default configuration%%000A # A-Line A:This is Debian's default ircd configurations:Please edit your /etc/ircd/ircd.conf file:Contact root@localhost for questions::ExampleNet # Y-Lines Y:1:90::100:512000:5.5:100.100 Y:2:90::300:512000:5.5:250.250 # I-Line I:*:::0:1 I:127.0.0.1/32:::0:1 # P-Line P6667%
Bug#760370: libpcap0.8-dev is not Multi-Arch compatible
Package: libpcap0.8-dev
Version: 1.6.1-1
Severity: normal
Dear Maintainer,
The amd64 version conflicts with the i386 one which makes it impossible to
install both. As a result the /usr/lib/i386-linux-gnu/libpcap.so symbolic link
is missing so that developping 32 bit applications (e.g. Wine) using this
library is impossible on a 64 bit system.
Al look at the package shows that there is no header conflict which is a good
start.
There is however a difference in pcap-config that will need a resolution:
diff -ur amd64/usr/bin/pcap-config i386/usr/bin/pcap-config
--- amd64/usr/bin/pcap-config 2014-07-30 21:07:45.0 +0200
+++ i386/usr/bin/pcap-config2014-07-30 21:10:33.0 +0200
@@ -7,7 +7,7 @@
prefix=/usr
exec_prefix=${prefix}
includedir=${prefix}/include
-libdir=${prefix}/lib/x86_64-linux-gnu
+libdir=${prefix}/lib/i386-linux-gnu
V_RPATH_OPT=-Wl,-rpath,
LIBS=
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libpcap0.8-dev depends on:
ii libc6-dev 2.19-9
ii libpcap0.8 1.6.1-1
libpcap0.8-dev recommends no packages.
libpcap0.8-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#760365: qemu-system-x86: Showing Could not initialize SDL(No available video device) since last upgrade
On 09/03/2014 12:08 PM, Michael Tokarev wrote: And second, if you want your X11 environment to be accessible across sudo, configure sudo to pass $DISPLAY and $XAUTHORITY variables, so that X clients will be able to connect to your X server. It did work like that until this morning before the upgrade. Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745960: libgit2: Please upload to unstable
Laurent Bigonville bi...@debian.org writes: I see. And moreover libgit is not using proper soname versioning either. I've opened https://github.com/libgit2/libgit2/issues/2398 about this. Thanks for doing that! I didn't really understand the soname stuff, so I didn't really know to ask. I have also asked that the new release 0.21.1 be uploaded by my mentor into unstable, that will happen soon. Thanks! Russell -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760371: ircd-irc2: Discrepancy between documentation and configuration
Package: ircd-irc2 Version: 2.11.2p3~dfsg-2 Severity: normal Hi, apparently this irc daemon requires the configuration to use the percent sign (%) as delimiter instead of the colon (:) as denoted in its documentation and partially written in its own configuration file. For example, the configuration lists the following setting as valid: P6667:: However, this results in No valid P line available (or phrased similar). The default configuration of this package contains the proper line: P6667% Different to the A line where the configuration uses the colon as delimiter, but the software requires a percent sign. When I say configuration I refer to the file referenced on top of the configuration: - # This is ircd's config-file. Look at # /usr/share/doc/ircd-irc2/ircd.conf.example.gz and # and /usr/share/doc/ircd-irc2/INSTALL.* for more detailled information # and instructions - Regards Joey -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-1 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages ircd-irc2 depends on: ii libc6 2.19-10 ii zlib1g 1:1.2.8.dfsg-2 ircd-irc2 recommends no packages. ircd-irc2 suggests no packages. -- Configuration Files: /etc/ircd/ircd.conf changed [not included] /etc/ircd/ircd.motd changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760365: qemu-system-x86: Showing Could not initialize SDL(No available video device) since last upgrade
03.09.2014 14:20, Sebastian Pipping wrote: On 09/03/2014 12:08 PM, Michael Tokarev wrote: And second, if you want your X11 environment to be accessible across sudo, configure sudo to pass $DISPLAY and $XAUTHORITY variables, so that X clients will be able to connect to your X server. It did work like that until this morning before the upgrade. So you should check what else has changed on your system with this upgrade. qemu can't magically recover missing $DISPLAY variable if it is not exported by sudo. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758256: scribus: FTBFS with cmake 3.0
On 2014-09-02 23:59, Mattia Rizzolo wrote: On Sep 2, 2014 10:21 PM, Felix Geyer fge...@debian.org wrote: When do you plan to upload 1.4.4 to unstable? The upload is pending at my sponsor's list. I hope in an upload before the end of the week... That sounds great, thanks! Cheers, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620367: protocol = milter not implemented
Package: gross Version: 1.0.2-3 Followup-For: Bug #620367 Dear Maintainer, Please either update the description of this package, removing all references to milter and sendmail, or turn on the milter support by adding --enable-milter to ./configure. As it is now, the package description is misleading, causing the package to be installed on systems it does not support. There is no sendmail support at all in the current Debian gross package. Please don't fool administrators to install and configure the package only to discover this... Bjørn -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages gross depends on: ii adduser 3.113+nmu3 ii libc-ares2 1.9.1-3 ii libc6 2.13-38+deb7u4 ii sendmail8.14.4-4 gross recommends no packages. gross suggests no packages. -- Configuration Files: /etc/grossd.conf changed: protocol = milter dnsbl = bl.spamcop.net;2 dnsbl = combined.njabl.org dnsbl = cbl.abuseat.org dnsbl = dnsbl.sorbs.net milter_listen = inet:5523@localhost -- 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#755539: Elastix needs binnmu after ITK
On 02/09/14 07:23, Steve M. Robbins wrote: The recent build failure of elastix (#759945) is caused by the libhdf5.so path having changed, presumably due to #755539. The path is encoded into insighttoolkit4-dev's file /usr/lib/cmake/ITK-4.6/ITKTargets-none.cmake so Elastix will need a binnmu as soon as insighttoolkit is rebuilt. It should build fine now, right? So why is the binNMU needed? There was a temporary problem on insighttoolkit4 that is now fixed, but no binNMUs on elastix or plastimatch should be needed AFAICS. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758787: lilypond-doc: Broken usage of dpkg-maintscript-helper
Hi! On Tue, 2014-09-02 at 09:30:25 -0700, Don Armstrong wrote: On Thu, 21 Aug 2014, Guillem Jover wrote: The dpkg-maintscript-helper usage in this package is broken, because it's using a relative symlink target. The dpkg-maintscript-helper has been doing sanity checks to see if the canonicalized symlink targe (from «readlink -f») matches the passed symlink target argument, which will just not match, and not perform the switch. This doesn't match what the documentation still says (as of 1.17.13)[1], and also seems sort of backwards to me. Hmm, this was supposed to be fixed with the upload that made the check coherent with the implementation, this is what the man page says for the symlink to directory switch (which is what lilypond-doc is using): pathname is the absolute name of the old symlink (the path will be a directory at the end of the installation) and old-target the absolute target name of the former symlink at pathname. or is there something else I missed on the update (perhaps the omitted stuff referenced by [1]?). The package can control the symlink's target (after all, that's what the symlink did), but has less control over the place in the filesystem that the symlink eventually points to. [In the instant case, we've previously done a /usr/doc to /usr/share/doc migration, which would have worked seamlessly if the target was checked, but would have required more changes if the cannonical target was checked. Sure, it seems and it is a bit backwards, but that's because the initial implementation could only handle absolute symlink targets for dir_to_symlink, so “it seemed to make more sense” to have both be symmetric. When the dir_to_symlink got fixed to also accept relative symlinks, I actually got a bit bothered by the new asymmetry, but… Starting with dpkg 1.17.13 the program will error out on such parameters (the documentation has been updated too now), so the package becomes uninstallable/unremovable. Please switch to use an absolute path for the symlink target. I'll do this for the time being, but either the documentation needs to be fixed, or the implementation changed. [An easy change would be to check both readlink -f or just readlink.] … neither me nor Helmut did think of this obvious solution, I don't know why!? maybe just because we had our minds elsehwere during the Bootstrap Sprint :), I'll try to recall if there was actually any problem. But otherwise, I'll just be adding relative symlink support to symlink_to_dir in dpkg 1.17.14, but be aware that previous dpkg version will either accept them but not perform the actual switch or outright refuse them. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730405: freeorion: input textfields doesn't work after a while.
Since libOIS upstream is apparently dead, and the projects that use it (mostly games[1] using Ogre3D libraries like freeorion) are gradually abandoning this library (including Ogre3D), clearly the bug will never be resolved. So I want to sumarize my last discoveries about the bug itself. First, the bug is caused by a weird interaction with xscreensaver. The behaviour of xscreensaver in some way causes the appearance of the unexpected KeyRelease events that leads to the libOIS misbehaviour already explained. More details here: http://www.freeorion.org/forum/viewtopic.php?p=70165#p70165 My suspects of the root of the problem are detailed here: http://www.freeorion.org/forum/viewtopic.php?p=71435#p71435 Long explanation short: I think the bug could be in X.Org Server event queue handling code, but that code is too complex (and prone to errors) to be worth check it without a good reason (and there is no good reason if upstream and dowstream are not going to apply any patches). So I recommend to anyone affected by this bug to talk to the developers of the application to move away from libOIS to another library with actual suport (like SDL). It's going to be a better solution in the long term. [1] By the way, it's a bit strange that libOIS is under the umbrella of Debian Multimedia Maintainers instead of Debian Games Team due to its nature and users. signature.asc Description: Digital signature
Bug#760329: [INTL:tr] Turkish debconf template translation for icinga2
On 09/03/2014 08:38 AM, Christian PERRIER wrote: Quoting Mert Dirik (mertdi...@gmail.com): Package: icinga2 Severity: wishlist Tags: l10n patch Please find the attached Turkish translation of icinga2 debconf messages. This file should be put as debian/po/tr.po in your build tree. Hello Mert, There are only 7 translated strings in the file, while the POT file has 13 strings. Can you also translate the extra strings? See attached file. I'm attaching the updated file. # Turkish translation of icinga2 package # Copyright (C) 2014 Mert Dirik # This file is distributed under the same license as the icinga2 package. # Mert Dirik mertdi...@gmail.com, 2014. # msgid msgstr Project-Id-Version: icinga2\n Report-Msgid-Bugs-To: icin...@packages.debian.org\n POT-Creation-Date: 2014-08-18 15:18+0200\n PO-Revision-Date: 2014-09-03 12:37+0200\n Last-Translator: Mert Dirik mertdi...@gmail.com\n Language-Team: Debian L10n Turkish debian-l10n-turk...@lists.debian.org\n Language: tr\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n X-Generator: Poedit 1.5.4\n #. Type: password #. Description #: ../icinga2-classicui.templates:2001 msgid Icinga 2 ClassicUI administration password: msgstr Icinga 2 ClassicUI yönetim parolası: #. Type: password #. Description #: ../icinga2-classicui.templates:2001 msgid Please provide the password to be created with the \icingaadmin\ user. msgstr Lütfen yeni oluşturulacak olan \icingaadmin\ kullanıcısının kullanacağı parolayı girin. #. Type: password #. Description #: ../icinga2-classicui.templates:2001 msgid This is the username and password to use when connecting to the Icinga server after completing the configuration. If you do not provide a password, you will have to configure access to Icinga manually later on. msgstr Bu kullanıcı adı ve parola, yapılandırılması tamamlandıktan sonra Icinga sunucusuna bağlanmak için kullanılacaktır. Eğer şimdi bir parola girmezseniz Icinga'yı daha sonra elle yapılandırmanız gerekecektir. #. Type: password #. Description #: ../icinga2-classicui.templates:3001 msgid Re-enter password to verify: msgstr Parolayı doğrulamak için tekrar girin: #. Type: password #. Description #: ../icinga2-classicui.templates:3001 msgid Please enter the same user password again to verify you have typed it correctly. msgstr Lütfen doğru yazıldığından emin olmak için aynı parolayı tekrar girin. #. Type: error #. Description #: ../icinga2-classicui.templates:4001 msgid Password input error msgstr Parola girme hatası #. Type: error #. Description #: ../icinga2-classicui.templates:4001 msgid The two passwords you entered were not the same. Please try again. msgstr Girdiğiniz iki parola aynı değil. Lütfen tekrar deneyin. #. Type: boolean #. Description #: ../icinga2-ido-mysql.templates:2001 msgid Enable Icinga 2's ido-mysql feature? msgstr Icinga 2'nin ido-mysql özelliği etkinleştirilsin mi? #. Type: boolean #. Description #: ../icinga2-ido-mysql.templates:2001 msgid Please specify whether Icinga 2 should use MySQL. msgstr Icinga 2'nin MySQL kullanmasını istiyor musunuz? #. Type: boolean #. Description #: ../icinga2-ido-mysql.templates:2001 msgid You may later disable the feature by using the \icinga2-disable-feature ido- mysql\ command. msgstr Bu özelliği daha sonra \icinga2-disable-feature ido-mysql\ komutu ile kapatabilirsiniz. #. Type: boolean #. Description #: ../icinga2-ido-pgsql.templates:2001 msgid Enable Icinga 2's ido-pgsql feature? msgstr Icinga 2'nin ido-pgsql özelliği etkinleştirilsin mi? #. Type: boolean #. Description #: ../icinga2-ido-pgsql.templates:2001 msgid Please specify whether Icinga 2 should use PostgreSQL. msgstr Icinga 2'nin PostgreSQL kullanmasını istiyor musunuz? #. Type: boolean #. Description #: ../icinga2-ido-pgsql.templates:2001 msgid You may later disable the feature by using the \icinga2-disable-feature ido- pgsql\ command. msgstr Bu özelliği daha sonra \icinga2-disable-feature ido-pgsql\ komutu ile kapatabilirsiniz.
Bug#760372: loganalyzer: CVE-2014-6070
Source: loganalyzer Version: 3.6.5+dfsg-7 Severity: important Tags: security upstream fixed-upstream Hi, the following vulnerability was published for loganalyzer. But I was not yet able to verify the vulnerability, but it is said to be fixed in 3.6.6 upstream. CVE-2014-6070[0]: Syslog LogAnalyzer persistent XSS injection If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2014-6070 [1] http://seclists.org/fulldisclosure/2014/Sep/17 [2] http://loganalyzer.adiscon.com/downloads/ Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760361: Acknowledgement (linux: chown on NFS4 mounts impossible)
Ok, I stumbled over the kernel parameter /sys/module/nfs/parameters/nfs4_disable_idmapping which is N on our older (Ubuntu 12.04, Kernel 3.2) clients Y on the newer (Ubuntu 14.04, Kernel 3.13). Setting it to N seems to make chown work again, pulseaudio working too. tcpdump now: 128 1.505072 $SERVER_IP $CLIENT_IP NFS 122 V4 Reply (Call In 127) OPEN Status: NFS4ERR_NOENT Thought that could be helpful, not sure if that is a solution or a workaround smime.p7s Description: S/MIME Cryptographic Signature
Bug#760357: lxc: can not start container which used to work after recent system update
severity 760357 normal tag 760357 unreproducible tag 760357 moreinfo thanks Hi, i'm running lxc 1.0.5-2 and systemd 208-8 here, on sid with kernel 3.14-2-amd64. creating/starting/stopping containers created with lxc-create -t debian works flawlessly, so your problem is a local problem. On 09/03/2014 10:12 AM, Alex Mestiashvili wrote: lxc-start -n sid lxc-start: No such file or directory - failed to read /sys/fs/cgroup/lxc/cpuset.cpus lxc-start: Failed to initialize cpuset for '/lxc' in '/sys/fs/cgroup'. lxc-start: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup//systemd lxc-start: Directory not empty - cgroup_rmdir: failed to delete /sys/fs/cgroup//cgmanager lxc-start: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/ lxc-start: failed creating cgroups lxc-start: failed to spawn 'sid' lxc-start: The container failed to start. lxc-start: Additional information can be obtained by setting the --logfile and --log-priority options. please do so by calling your lxc-start with debug logs enabled. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760372: [Pkg-monitoring-maintainers] Bug#760372: loganalyzer: CVE-2014-6070
Hi Rainer, Andre, Could you please comment on this security report? Is the current Debian package affected? Regards, Daniel On 03/09/14 13:04, Salvatore Bonaccorso wrote: Source: loganalyzer Version: 3.6.5+dfsg-7 Severity: important Tags: security upstream fixed-upstream Hi, the following vulnerability was published for loganalyzer. But I was not yet able to verify the vulnerability, but it is said to be fixed in 3.6.6 upstream. CVE-2014-6070[0]: Syslog LogAnalyzer persistent XSS injection If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2014-6070 [1] http://seclists.org/fulldisclosure/2014/Sep/17 [2] http://loganalyzer.adiscon.com/downloads/ Regards, Salvatore ___ Pkg-monitoring-maintainers mailing list pkg-monitoring-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-monitoring-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760372: [Pkg-monitoring-maintainers] Bug#760372: loganalyzer: CVE-2014-6070
Andre just went to vacation, but to the best of my knowledge he worked with the reporter and has released a new version to address this issue. Rainer On Wed, Sep 3, 2014 at 1:11 PM, Daniel Pocock dan...@pocock.pro wrote: Hi Rainer, Andre, Could you please comment on this security report? Is the current Debian package affected? Regards, Daniel On 03/09/14 13:04, Salvatore Bonaccorso wrote: Source: loganalyzer Version: 3.6.5+dfsg-7 Severity: important Tags: security upstream fixed-upstream Hi, the following vulnerability was published for loganalyzer. But I was not yet able to verify the vulnerability, but it is said to be fixed in 3.6.6 upstream. CVE-2014-6070[0]: Syslog LogAnalyzer persistent XSS injection If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2014-6070 [1] http://seclists.org/fulldisclosure/2014/Sep/17 [2] http://loganalyzer.adiscon.com/downloads/ Regards, Salvatore ___ Pkg-monitoring-maintainers mailing list pkg-monitoring-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-monitoring-maintainers
Bug#755539: Elastix needs binnmu after ITK
Hi Emilio, On Wed, Sep 03, 2014 at 12:44:22PM +0200, Emilio Pozuelo Monfort wrote: On 02/09/14 07:23, Steve M. Robbins wrote: The recent build failure of elastix (#759945) is caused by the libhdf5.so path having changed, presumably due to #755539. The path is encoded into insighttoolkit4-dev's file /usr/lib/cmake/ITK-4.6/ITKTargets-none.cmake so Elastix will need a binnmu as soon as insighttoolkit is rebuilt. It should build fine now, right? So why is the binNMU needed? There was a temporary problem on insighttoolkit4 that is now fixed, but no binNMUs on elastix or plastimatch should be needed AFAICS. So you mean simply closing the bug would be sufficient, right? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711500: Is there a patch available for gnome 3.4.2 ?
Not a solution, but with complete removal of Google Chrome using Synaptic (removal method recommended by Google on Chrome page) software update is now back to normal for me. uname -a includes: 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux gnome-shell --version: GNOME Shell 3.4.2 best regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760357: (no subject)
Have the problem as well. mount cpu /sys/fs/cgroup -t cgroup did work for me. Wonder which component should do this mount command . -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760297: [Pkg-javascript-devel] Bug#760297: libjs-mediaelement: completely useless without the flash/silverlight parts
Quoting David Prévot (2014-09-02 21:50:54) Control: severity -1 wishlist You honestly consider lack of those parts merely a wish, no bug at all? Control: rename -1 Please, (build and) ship Flash and Silverlight parts Le 02/09/2014 12:29, Jonas Smedegaard a écrit : The very purpose of MediaElement.js is to act as a polyfill for browsers that does not support html5 audio and video tags, and it does so by use of either flash or silverlight code. As (not enough) documented in the package description and (better) in the upstream homepage, the purpose is to offer an unified interface in order to offer the same experience whatever the browser. The Flash or Silverlight shim are only used if needed to help legacy browsers not HTML5-compatible to mimic those expectations. The middle-term goal is of course to offer the the Flash and Silverlight shims, but the upstream build process was not really open and properly documented at the time the package was uploaded to Debian. Let's see - here are the bullet points from the front page: * HTML5 audio and video players in pure HTML and CSS. * Custom Flash and Silverlight players that mimic the HTML5 MediaElement API for older browsers * Accessibility standards including WebVTT Of those, the first point is not Javascript at all, the second is not working at all, so your argument must be related to the third somehow. Please elaborate!! - 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#760056: each upgrade locks nobody
RA == Russ Allbery r...@debian.org writes: RA You're focusing on the idea that the debconf prompt controls what RA shell... OK, all this needs to be added to e.g., man 7 debconf below, else many of us will just think it is so simple: Reconfiguring packages Suppose you installed the package, and answered debconf's questions, but now that you've used it awhile, you realize you want to go back and change some of your answers. In the past, reinstalling a package was often the thing to do when you got in this situation, but when you reinstall the package, deb‐ conf seems to remember you have answered the questions, and doesn't ask them again (this is a feature). Luckily, debconf makes it easy to reconfigure any package that uses it. Suppose you want to reconfigure debconf itself. Just run, as root: dpkg-reconfigure debconf This will ask all the questions you saw when debconf was first installed. It may ask you other questions as well, since it asks even low priority questions that may have been skipped when the package was installed. You can use it on any other package that uses debconf, as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748130: scotch autoremoval from jessie not usefull : only stable/amd64 package has RC bug
Hi Pierre, On Wed, Sep 03, 2014 at 11:27:02AM +0200, Pierre Saramito wrote: Dear all, The RC bug #748130 founded in the scotch library causes to mark for autoremoval many packages in the jessie distribution. Notice that the bug do not concern the actual jessie distribution : it is restricted to the stable one on the amd64 architecture. Recall that, in that specific case, the actual stable/amd64 scotch package links to both mipch and openmpi and this produce a segfault at run time. A simple recompilation of the stable scotch packages for amd64 should fix this bug (see bug #748130 for more). So, the jessie scotch packages are not concerned by this bug and all packages that depend one do not need to be marked for autoremoval. Note that the version-tracking is corrected since yesterday, so that the packages are not anymore scheduled for autoremoval from jessie. For stable I have opened a binnmu request, see [1]. [1] https://bugs.debian.org/760282 Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760373: check_libs filename parsing error on OpenVZ guests
Package: nagios-plugins-contrib
Version: 11.20140704
Tags: patch
Hi,
I noticed that check_libs sometimes parses files incorrectly
inside an OpenVZ container (wheezy host and guest, proxmox ve
2.6.32 kernel):
# /usr/lib/nagios/plugins/check_libs --verbose
Running /usr/bin/lsof -F0 -n
adding bash(28081) because of [ (deleted)/tmp/tmpfXKFYTG]:
f1aul tREGG0x8002;0x0D0x6ds218i9441399k0n (deleted)/tmp/tmpfXKFYTG
adding bash(28081) because of [ (deleted)/tmp/tmpfXKFYTG]:
f2aul tREGG0x8002;0x0D0x6ds218i9441399k0n (deleted)/tmp/tmpfXKFYTG
adding puppet(28244) because of [ (deleted)/tmp/tmpfXKFYTG]:
f1aul tREGG0x8002;0x0D0x6ds218i9441399k0n (deleted)/tmp/tmpfXKFYTG
adding puppet(28244) because of [ (deleted)/tmp/tmpfXKFYTG]:
f2aul tREGG0x8002;0x0D0x6ds218i9441399k0n (deleted)/tmp/tmpfXKFYTG
The following processes have libs linked that were upgraded: root: bash
(28081), puppet (28244)
So in some cases there is a space in front of (deleted).
Attached is a patch that fixes this.
Regards,
Felix
diff -Nur a/check_libs/nagios-check-libs b/check_libs/nagios-check-libs
--- a/check_libs/nagios-check-libs
+++ b/check_libs/nagios-check-libs
@@ -170,7 +170,7 @@
my $inode = $fields{i};
my $path = $fields{n};
if ($path =~ m/\.dpkg-/ || $path =~ m/\(deleted\)/ || $path =~ /path inode=/ || $fd eq 'DEL') {
- $path =~ s/^\(deleted\)//; # in some cases (deleted) is at the beginning of the string
+ $path =~ s/^ ?\(deleted\)//; # in some cases (deleted) is at the beginning of the string
for my $i (@{$config-{'ignorelist'}}) {
my $ignore = eval($i);
next LINE if $ignore;
Bug#760374: nmu: evolution-ews_3.12.1-1, evolution-rss_0.3.95~20140414-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, Could you please binNMU evolution-ews and evolution-rss. They are uninstallabe ATM due to the libgtkhtml-4.0-0 transition. nmu evolution-ews_3.12.1-1 . ALL . -m Rebuild against new libgtkhtml-4.0-0 nmu evolution-rss_0.3.95~20140414-2 . ALL . -m Rebuild against new libgtkhtml-4.0-0 Cheers, Laurent Bigonville -- 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.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760357: lxc: can not start container which used to work after recent system update
It seems that the problem was caused by cgroup mount defined in fstab. This configuration worked fine with 3.12 ( just rebooted and tested - container started). Currently I commented out cgroup in fstab and after reboot everything works fine. I also see cgmanager process and cgroup mounts. Sorry for the noise. Alex
Bug#755539: Elastix needs binnmu after ITK
On 03/09/14 13:24, Andreas Tille wrote: Hi Emilio, On Wed, Sep 03, 2014 at 12:44:22PM +0200, Emilio Pozuelo Monfort wrote: On 02/09/14 07:23, Steve M. Robbins wrote: The recent build failure of elastix (#759945) is caused by the libhdf5.so path having changed, presumably due to #755539. The path is encoded into insighttoolkit4-dev's file /usr/lib/cmake/ITK-4.6/ITKTargets-none.cmake so Elastix will need a binnmu as soon as insighttoolkit is rebuilt. It should build fine now, right? So why is the binNMU needed? There was a temporary problem on insighttoolkit4 that is now fixed, but no binNMUs on elastix or plastimatch should be needed AFAICS. So you mean simply closing the bug would be sufficient, right? After verifying it builds fine now (which I guess it does), sure. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760357: lxc: can not start container which used to work after recent system update
On 09/03/2014 01:51 PM, Alex Mestiashvili wrote: It seems that the problem was caused by cgroup mount defined in fstab. well, yes.. if you use systemd, you shoudn't mount it through fstab. since this is probably going to be a quite common case since we had to instruct people to write it in fstab (eventhough #601757 was filled years ago to make sysvinit mount it).. ..i'll add a preinst check to give out a warning about that. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759683: gcc: internal compiler error: Killed (program cc1)
Control: forwarded -1 https://gcc.gnu.org/PR63155 Control: tags -1 + upstream Am 29.08.2014 um 11:11 schrieb Chauveau Wilfried: While compiling the joined file, gcc crash without warning. I don't see the crash, but both 4.9 and the trunk need about 10GB memory to build this file. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760375: radvd: FTBFS on x32 due to lack of sysctl
Source: radvd
Version: 1:1.9.1-1.3
Severity: important
Tags: patch
Justification: fails to build from source
Hi,
attached patch fixes the issue by autoconf’ing sysctl(2) and
disabling the use of it if it’s not there, such as on x32,
and probably arm64.
Please apply.
-- System Information:
Debian Release: jessie/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
diff -Nru radvd-1.9.1/debian/changelog radvd-1.9.1/debian/changelog
--- radvd-1.9.1/debian/changelog 2014-08-05 17:47:20.0 +0200
+++ radvd-1.9.1/debian/changelog 2014-09-03 12:47:34.0 +0200
@@ -1,3 +1,9 @@
+radvd (1:1.9.1-1.3+x32.1) unreleased; urgency=medium
+
+ * Work around lack of sysctl(2) in x32 (which I disagree with)
+
+ -- Thorsten Glaser t...@mirbsd.de Wed, 03 Sep 2014 12:47:33 +0200
+
radvd (1:1.9.1-1.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru radvd-1.9.1/debian/patches/series radvd-1.9.1/debian/patches/series
--- radvd-1.9.1/debian/patches/series 2012-01-23 18:05:54.0 +0100
+++ radvd-1.9.1/debian/patches/series 2014-09-03 12:38:19.0 +0200
@@ -2,3 +2,4 @@
0006-removing-mdelay-in-unicast-only-case.patch
0007-checking-iface-name-more-carefully.patch
kfreebsd.patch
+x32.patch
diff -Nru radvd-1.9.1/debian/patches/x32.patch radvd-1.9.1/debian/patches/x32.patch
--- radvd-1.9.1/debian/patches/x32.patch 1970-01-01 01:00:00.0 +0100
+++ radvd-1.9.1/debian/patches/x32.patch 2014-09-03 12:47:33.0 +0200
@@ -0,0 +1,50 @@
+--- a/configure.ac
b/configure.ac
+@@ -179,7 +179,7 @@ int u = in6_u.s6_addr16;], [AC_MSG_RESU
+ AC_MSG_RESULT(no))
+
+ dnl Checks for library functions.
+-AC_CHECK_FUNCS(getopt_long)
++AC_CHECK_FUNCS([getopt_long sysctl])
+
+ CONDITIONAL_SOURCES=device-${arch}.${OBJEXT} ${CONDITIONAL_SOURCES}
+ if test x${arch} = xlinux ; then
+--- a/includes.h
b/includes.h
+@@ -72,7 +72,9 @@
+
+ #include arpa/inet.h
+
++#ifdef HAVE_SYSCTL
+ #include sys/sysctl.h
++#endif
+
+ #include net/if.h
+
+--- a/radvd.c
b/radvd.c
+@@ -763,7 +763,9 @@ check_conffile_perm(const char *username
+ int
+ check_ip6_forwarding(void)
+ {
++#ifdef HAVE_SYSCTL
+ int forw_sysctl[] = { SYSCTL_IP6_FORWARDING };
++#endif
+ int value;
+ size_t size = sizeof(value);
+ FILE *fp = NULL;
+@@ -785,8 +787,12 @@ check_ip6_forwarding(void)
+ or the kernel interface has changed?);
+ #endif /* __linux__ */
+
+- if (!fp sysctl(forw_sysctl, sizeof(forw_sysctl)/sizeof(forw_sysctl[0]),
+- value, size, NULL, 0) 0) {
++ if (!fp
++#ifdef HAVE_SYSCTL
++ sysctl(forw_sysctl, sizeof(forw_sysctl)/sizeof(forw_sysctl[0]),
++ value, size, NULL, 0) 0
++#endif
++ ) {
+ flog(LOG_DEBUG, Correct IPv6 forwarding sysctl branch not found,
+ perhaps the kernel interface has changed?);
+ return(0); /* this is of advisory value only */
Bug#760372: [Pkg-monitoring-maintainers] Bug#760372: Bug#760372: loganalyzer: CVE-2014-6070
On 03/09/14 13:15, Rainer Gerhards wrote: Andre just went to vacation, but to the best of my knowledge he worked with the reporter and has released a new version to address this issue. Thanks for the feedback Salvatore, I'd prefer to update the package closer to the freeze and roll up any other changes in a single release. People should not be making LogAnalyzer available to the world, especially without additional access controls (HTTP authentication) so that provides some protection against flaws that do exist in this product. How would the security team feel if this package was classified in a similar way to the ganglia-web package, e.g. security alerts are not RC bugs and users advised to protect the URL with the webserver?
Bug#760188: ITP: scoop -- concurrent parallel programmming library
Hello, here a quick review of all the patches * dropped docs package (REJECT-FAQ: split this only if it's big) I think that this patch should be reverted. The problem if you add the documentation in python-scoop seems to me problematic when python3-scoop will come. It is best to my opinion especially for the python pacakging to put the documentation nto a dedicated package which can be recommended by python2 and python3. I do not think that this -doc package would be rejected by ftp-master. There argument is understandable when you have only one binary pacakge. But here we can intall python2 and/or python3 version but in both cases you want the documentation. * finalized ok, do not hesitate to use cme to fix your control file. * changelog: restored 'initial release' and added info on previous package is there common binary packages between this old scoop package and the new one ? * build docs package ok * running testsuite nice to have a test suite. You can look at the debci and autopkgtest infrastructure to implement also the integration continuous integration for scoop. * changelog: improved package info * copyright: indent correction ok * control: corrected dependency, copyright: shortened too long line why did you removed the virtual package ssh-client ? * added no-adsense.patch could you discuss with the upstream to remove these privacy breach things. If they really want them, it should be nice to have a setup.py flag which allow to get rid of these google analytic links, instead of carrying a dedicated patch all the time. * updated some files in deb/, removed source/local-options and egg-info, added examples and doc-base You removed the local-options (are you using gbp-buildpackage to build scoop ?) So I will consiede the pacakge ready for upload once 1) you regenerate the -doc package (this will simplify thinks when python3 pacakge will be possible) 2) re-add the ssh-client dependency (cheap) 3) add the autopkgtest part (will simplify a lot the maintenance of the package, so important for me) I need to build it and do the copyright check. then I think that it will be ok for me to sponsor the upload. Cheers Frederic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760376: amd-opencl-dev: missing breaks/replaces on packages that shipped libOpenCL.so
Package: amd-opencl-dev Version: 1:14.4.2-1 Hi Maintainer Your package ships a libOpenCL.so symlink. In the past, this package has also been shipped by amd-libopencl1, nvidia-libopencl1 and ocl-icd-libopencl1. In order to provide a smooth upgrade path, please add the missing breaks/replaces relationships as follows: Package: amd-opencl-dev [...] Conflicts: opencl-dev Breaks: ocl-icd-libopencl1 ( 2.1.3-5~), nvidia-libopencl1 (304.88-7~), amd-libopencl1 (1:13.4-4~) Replaces: opencl-dev, ocl-icd-libopencl1 ( 2.1.3-5~), nvidia-libopencl1 (304.88-7~), amd-libopencl1 (1:13.4-4~) [...] Please see bug #755513 for more information. Regards Graham -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555544: blocking the ppc64el architecture bootstrap
Ok, I´ll upload a package this week. Thanks, -- Ludovic Drolez On 25 août 2014 05:27:43 UTC+02:00, Aurelien Jarno aure...@debian.org wrote: Dear maintainer, The ppc64el architecture has been added to the Debian archive. Your package swish-e fails to build as reported in bug #44 and the build log is available on [1]. It would be very nice if you can upload a fixed version of this package. Don't hesitate to ask questions if you need help to fix this bug. If you lack time for that, I can also proceed with an NMU. Thanks, Aurelien [1] https://buildd.debian.org/status/logs.php?pkg=swish-earch=ppc64el -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
