Bug#652064: vnc4server opens only IPv6 socket but there IPv4 address available
Hello, Now i see, it was my fault, thank you for your quick help, Regards, Neszt Tibor E-mail: ti...@neszt.hu PGP: 0xD4CC8D9F Fingerprint = B005 B009 E093 25D4 B9E5 F3E8 C477 8F5B D4CC 8D9F On Wed, 14 Dec 2011, Roman Mamedov wrote: On Wed, 14 Dec 2011 16:02:21 +0100 (CET) Neszt Tibor ti...@neszt.hu wrote: I saw this bug was fixed in #562169, but it seems, this is still an existsing problem: # lsof -n | grep 5901 Xvnc4 1174 neszt3u IPv6 13886440 0t0TCP *:5901 (LISTEN) My main network interface has both IPv4 and IPv6 addresses, and there are other network interfaces. Hello, This is not a problem, because you can connect to this socket via using both IPv4 and IPv6: $ sudo lsof -n | grep 5901 | grep LISTEN Xvnc4 4955 rm3u IPv6 163680t0 TCP *:5901 (LISTEN) $ nc6 -vvv4 localhost 5901 nc6: localhost (127.0.0.1) 5901 [5901] open nc6: using stream socket nc6: using buffer size of 8192 nc6: read 12 bytes from remote RFB 003.008 nc6: wrote 12 bytes to local $ nc6 -vvv6 localhost 5901 nc6: ip6-localhost (::1) 5901 [5901] open nc6: using stream socket nc6: using buffer size of 8192 nc6: read 12 bytes from remote RFB 003.008 nc6: wrote 12 bytes to local -- With respect, Roman ~~~ Stallman had a printer, with code he could not see. So he began to tinker, and set the software free. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651933: I can reproduce this
On Fri, Dec 16, 2011 at 07:52:29AM +0100, David Paleino wrote: On Thu, 15 Dec 2011 15:08:02 -0800, Peter Eckersley wrote: On Thu, Dec 15, 2011 at 02:58:03PM -0800, Peter Eckersley wrote: Answering your questions: a) wicd is running Correction. Wicd is /not/ running: That's why DBus can't see it, now it makes a bit more sense :) sudo service wicd restart Restarting Network connection manager: wicd. pde@xylophone:~$ ps aux | grep -v grep | grep wicd pde@xylophone:~$ sudo wicd -f (drops back to a shell) Would you please run sudo wicd -foe instead, and report back the output? Here we go! wicd is version 1.7.1~b3 655 Traceback (most recent call last): File /usr/share/wicd/daemon/wicd-daemon.py, line 1843, in module main(sys.argv) File /usr/share/wicd/daemon/wicd-daemon.py, line 1807, in main daemon = WicdDaemon(wicd_bus, auto_connect=auto_connect) File /usr/share/wicd/daemon/wicd-daemon.py, line 87, in __init__ manager-settings.conf)) File /usr/lib/python2.7/dist-packages/wicd/configmanager.py, line 55, in __init__ sanitize_config_file(path) File /usr/lib/python2.7/dist-packages/wicd/configmanager.py, line 37, in sanitize_config_file conf = open(path) IOError: [Errno 2] No such file or directory: '/etc/wicd/manager-settings.conf' -- Peter Eckersleyp...@eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652327: minidlna: Minidlna no longer works with the new firmware of the decoder tv internet service provider Orange
Package: minidlna Version: 1.0.21+dfsg-1+b1 Severity: important Minidlna no longer works with the new firmware of the decoder tv internet service provider Orange. As he works with a ps3 and sony bravia tv On the decoder minidlna is present but no longer displays directory or songs,video and photo upnpevents.c: 357: warn: upnp_event_send: send (): Connection timed out ethernet with cpl -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (987, 'stable'), (986, 'testing'), (985, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-pit-serv-38-1 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages minidlna depends on: ii adduser 3.112+nmu2 add and remove users and groups ii gawk 1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr ii libavformat53 4:0.7.2-1+b1 Libav file format library ii libavutil51 4:0.7.2-1+b1 Libav utility library ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libexif12 0.6.19-1 library to parse EXIF files ii libflac8 1.2.1-2+b1 Free Lossless Audio Codec - runtim ii libid3tag00.15.1b-10 ID3 tag reading library from the M ii libjpeg62 6b1-1 The Independent JPEG Group's JPEG ii libogg0 1.2.0~dfsg-1 Ogg bitstream library ii libsqlite3-0 3.7.3-1SQLite 3 shared library ii libvorbis0a 1.3.1-1The Vorbis General Audio Compressi ii mawk 1.3.3-15 a pattern scanning and text proces minidlna recommends no packages. minidlna suggests no packages. -- Configuration Files: /etc/minidlna.conf changed: port=8200 network_interface=eth0 media_dir=A,/var/www/multimedia/musiques media_dir=P,/var/www/multimedia/photo media_dir=V,/var/www/multimedia/videos friendly_name=Multimédia db_dir=/var/cache/minidlna album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg/AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg/Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg inotify=yes enable_tivo=no strict_dlna=no notify_interval=900 serial=12345678 model_number=1 log_dir=/var/log root_container=B -- 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#651481: provide external interface to query expected hardening features
Hi,
On Thu, 15 Dec 2011, Kees Cook wrote:
$flags-{'features'}{'hardening'} is mostly the same than %use_feature,
please do not duplicate it but rather modify the code so that it works
that way:
1/ generate %use_feature by directly taking into account the architecture
specificities
2/ record %use_feature with a $flags-set_feature()
3/ do the various $flags-apppend() based on %use_feature (and there must
be no supplementary conditions left in the tests at this point, it's
solely if ($use_feature{foo}) { $flags-append() } since the
supplementary conditions have been taken into account in 1/ already)
While doing this, it seemed that creating a full set_feature() callback
was more work than it needed to be. I can certainly add it, but I thought
I'd show you where I am now first. If you still want the set_feature()
calls, I can add those, but I think it'll make the code less readable.
I believe it's cleaner because we're doing this from Dpkg::Vendor::Debian
so we're not within Dpkg::BuildFlags and we should not have to access
the internals of the object except through a well defined API.
diff --git a/man/dpkg-buildflags.1 b/man/dpkg-buildflags.1
index a018edb..7bfbe46 100644
--- a/man/dpkg-buildflags.1
+++ b/man/dpkg-buildflags.1
@@ -87,6 +87,11 @@ the flag is set/modified by a user-specific configuration;
the flag is set/modified by an environment-specific configuration.
.RE
.TP
+.BI \-\-features area
+Print the features enabled for a given area. The only currently recognized
+area is \fBhardening\fP. Exits with 0 if the area is known otherwise exits
+with 1.
A word about the structure of the output is needed.
@@ -239,7 +244,8 @@ This setting (disabled by default) adds
.B \-Wl,\-z,now
to \fBLDFLAGS\fP. During program load, all dynamic symbols are resolved,
allowing for the entire PLT to be marked read-only (due to \fBrelro\fP
-above).
+above). This option cannot be enabled without \fBrelro\fP being enabled
+at the same time.
This can easily be misread. I understood that enabling bindnow also
enables relro. When in fact it's really that bindnow requires relro as a
pre-requisite.
+=item $bf-features($area)
+
+Returns true if the given area is a known, and false otherwise. The only
+recognized area is hardening.
Somehow I think that the method name is not clear enough. Maybe
has_features? At least it would more consistent in:
if ($bf-has_features()) {
$bf-get_features()
}
+}
+
+# Stack protector
+if ($use_feature{stackprotector}) {
$flags-append(CFLAGS, -fstack-protector --param=ssp-buffer-size=4);
$flags-append(CXXFLAGS, -fstack-protector
--param=ssp-buffer-size=4);
}
-# Fortify
+# Fortify Source
You added empty lines before each feature test except here.
if ($use_feature{fortify}) {
$flags-append(CPPFLAGS, -D_FORTIFY_SOURCE=2);
}
-# Format
+
+# Format Security
--- a/scripts/dpkg-buildflags.pl
+++ b/scripts/dpkg-buildflags.pl
@@ -47,6 +47,7 @@ Actions:
--get flag output the requested flag to stdout.
--origin flagoutput the origin of the flag to stdout:
value is one of vendor, system, user, env.
+ --features area output the enabled features for the given area.
It should be something more descriptive like --query-features,
--get-features or --print-features. Because otherwise it really
sounds like a command to ask whether area is supported (because
features is a verb).
+} elsif ($action eq features) {
+if ($build_flags-features($param)) {
+ my %features = $build_flags-get_features($param);
+ my @report;
+ foreach my $feature (sort keys %features) {
+ my $item = Feature: $feature\nEnabled: ;
+ if ($features{$feature} == 1) {
+ $item .= yes;
+ } else {
+ $item .= no;
+ }
+ push(@report, $item);
+ }
+ print join(\n\n, @report), \n;
Put the first \n at the end of the block and you might want to use the
ternary operator to be more concise:
$item .= $features{$feature} ? yes\n : no\n;
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651894: [cupt] Process killed by SIGABRT.
severity 651894 normal tags 651894 confirmed pending retitle 651894 pin priority value conversion errors are not handled properly quit On 2011-12-12 22:45, Karol Kozłowski wrote: Following example should probably end with a mistake, not a failure. example: #cat /etc/cupt/preferences.d/iotop Package: iotop Pin: release n=lenny Pin-Priority: 100 #cupt policy iotop . terminate called after throwing an instance of 'boost::exception_detail::clone_implboost::exception_detail::error_info_injectorboost::bad_lexical_cast ' what(): bad lexical cast: source type value could not be interpreted as target Process killed by SIGABRT: Przerwane Thank you for the report, a fix is committed for 2.3.2. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652328: libapache2-mod-perl2: FTBFS with apache2-mpm-itk: test failures
Package: libapache2-mod-perl2 Version: 2.0.5-4 Severity: important When building with apache2-mpm-itk instead of apache2-mpm-worker: Test Summary Report --- t/hooks/cleanup2.t(Wstat: 0 Tests: 2 Failed: 1) Failed test: 2 t/modperl/pnotes2.t (Wstat: 0 Tests: 12 Failed: 12) Failed tests: 1-12 t/perl/api.t (Wstat: 0 Tests: 2 Failed: 1) Failed test: 2 t/hooks/cleanup.t (Wstat: 0 Tests: 2 Failed: 1) Failed test: 2 This seems to have been the case for some time, see http://mail-archives.apache.org/mod_mbox/perl-modperl/201101.mbox/%3c4d4183a3.4080...@aparzev.com%3E I've only looked at the perl/api.t one, which fails because getpid() and getppid() unexpectedly return the same value. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651199: iwlwifi: Connection lost on WPA: Group rekeying
On Sun, Dec 11, 2011 at 11:05:06AM -0600, Jonathan Nieder wrote: I cant find any relevant log messages from the driver. Not even with iw event -t? I can confirm the bug, and there is no significant event displayed (in fact, no event at all except scanning at unrelated times). The only message is WPA: Group rekeying in syslog. Best, -- Gabriel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652325: qa.debian.org: mia-query returns 'No entries found'
Hi there, On Fri, Dec 16, 2011 at 08:06:18AM +0100, Salvatore Bonaccorso wrote: Package: qa.debian.org Severity: normal Hi When trying to query the mia database on qa.debian.org, ./mia-query -p $packagename result in 'No entries found', here tested with one of my packages: $ /srv/qa.debian.org/mia/mia-query -p w2do No entries found $ Trying to query by name, I see that Packages counted are 0. It's probably related as it started to happen yesterday: querying email addresses has stopped working too (but the corresponding files still in db/). Querying DD logins seems to work though, so not sure what has been changed on the machine. regards, -- Ricardo Mones ~ Physics is like sex: sure, it may give some practical results, but that's not why we do it.Richard Feynman signature.asc Description: Digital signature
Bug#652206: zabbix: Please add an Include directive for .d-style configuration of agent
Christoph Haas, 2011-12-15 16:41:29 +0100 : Roland, thanks for the bug report. Yes, I had adding zabbix_agent.conf.d/ on my list anyway since Zabbix supports including further configuration files. That will come with the upcoming 1.8.9 package. Yay! On 15.12.2011 16:24, Roland Mas wrote: I forgot to mention that if this patch (or something similar) is accepted, I'll volunteer to implement an dh_installzabbix and the related Lintian check (probably by some cut-and-pasting from dh_installlogcheck). The goal would be for packages using dh to only have to create a debian/$package.zabbix-agent, and that would be deployed to the appropriate location. Hmm, what is the idea of that? Can you imagine any Debian package adding automatic UserCommand lines? The particular use case that triggered my patch is a custom package not meant to go to Debian (client-specific code), but I would certainly make use of it in my FusionForge package for instance, to monitor the number of active users or groups, or the CVS/SVN/Git/Bazaar/etc. activity. I can also think of many others: the MySQL probes that are currently commented out could be enabled by the relevant package; mdadm could provide a probe for the number of degraded arrays and one for the current reconstruction speed; ditto for drbd; heartbeat and friends could list the number of resources currently up; apticron (or some other apt* thing) could list the number of packages pending an upgrade; and so on. In many cases (not all), the command is simple, but since it's going to be the same on many installations, I feel it makes sense to allow factoring it in somewhere. When you have a Zabbix hammer in hand, many things start looking like potential Zabbix probe/nails :-) Roland. -- Roland Mas Au royaume des aveugles, les borgnes sont mal vus. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639290: what can we do to help ?
Hi, For me, dpkg -r libdigest-sha1-perl libextutils-cbuilder-perl libextutils-parsexs-perl was sufficient. If this can help... cheers, -- Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652250: libavcodec53 (et al) freeze totem playing .WMV
Am 15.12.2011 19:11, schrieb Steven R. Wright: ii libavcodec53 5:0.9-0.2 d-m.o packages again. I have added a section to our FAQ to describe this issue: http://wiki.debian.org/DebianMultimedia/FAQ#Common_issues -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646994: please provide /etc/modules.d
Hi, what's the state of this bug? it would be nice to know if you're in favour of adding modules.d support or not; and if you'd like to have a patch for it or not. Regards, Daniel -- 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#652148: [Logcheck-devel] Bug#652148: Please add rules for dropbear
# fixed in 20a68db tags 652148 + pending thanks Hello, Thanks for your contribution. I've added the rules to git[0]. Best regards Hannes [0] http://anonscm.debian.org/gitweb/?p=logcheck/logcheck.git;a=commit;h=20a68dbcc687700e37fdcefdc423bdc24822f4ad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
Hi, On Thu, Dec 15, 2011 at 19:45:47 -0500, Adam C Powell IV wrote: Found the problem. PETSc built on November 16 with mpi-defaults 0.6 which depended on LAM on non-openmpi arches. Now mpi-defaults 1.0.1 released 12/4 depends on MPICH2, so we have a mix of architectures installed. And mpi-defaults just went into testing today... Crap! It may be that other PETSc dependencies need rebuilding too... and there are a lot of them! Let's see: suitesparse, spooles, hypre, scotch, blacs-mpi, scalapack, mumps, all have to be rebuilt with MPICH2! What was built when: * suitesparse: April 15 2010 * spooles: May 11 2010 * hypre: August 15 2010 * scotch: April 6 2011 * blacs-mpi: August 29 2011 * scalapack: September 18 2011 * mumps: March 31 2011 None was built recently, all need to be rebuilt. mpi-defaults should not be in testing until at least these are rebuilt, probably others. Note: HDF5 is not a problem for PETSc because PETSc only links to it on OpenMPI platforms. I forgot why that is, maybe it's worth a try building PETSc against HDF5-mpich2? Maybe later... Okay, cloning this bug to a bunch of packages, see above. I've been an uploader to all except blacs-mpi and scalapack, and many of them could use some maintenance, this is a good excuse to spend time on them. :-) If any of those can be fixed with a no-change rebuild on the buildds, rather than a source upload, let debian-release know, and we'll schedule them. Thanks, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651854: apt-cacher: problems finding port number in /etc/xinetd.d/apt-cacher
On Wed, Dec 14, 2011 at 10:42:49PM -0500, Jon Daley wrote: Looks like the local and the quotes on the for line do the trick. Thanks. I will queue them for the next upload. Mark -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652329: 32bit qemu-kvm does not work correctly with 64bit kernel
Package: qemu-kvm Version: 1.0+dfsg-1 Severity: normal Tags: upstream confirmed Since at least 1.0 (upstream) version, 32bit qemu-kvm binary does not always work on 64bit host kernel. The problem most often can be seen on restart of (windows) guests - qemu-kvm process just freezes after - apparently - losing some interrupt. Sending some signal to it, or attaching/detaching gdb makes it to go again. Some more details are available in upstream bugtracker, see https://bugs.launchpad.net/qemu/+bug/899961 -- Package-specific info: /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Athlon(tm) II X2 260 Processor stepping: 3 cpu MHz : 800.000 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save bogomips: 6436.47 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Athlon(tm) II X2 260 Processor stepping: 3 cpu MHz : 800.000 cache size : 1024 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save bogomips: 6437.55 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (990, 'stable'), (500, 'oldstable'), (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.1.5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages qemu-kvm depends on: ii adduser 3.112+nmu2 add and remove users and groups ii ipxe1.0.0+git-2.149b50-1 PXE boot firmware ii libaio1 0.3.107-7Linux kernel AIO access library - ii libasound2 1.0.24.1-4 shared library for ALSA applicatio ii libbluetooth3 4.96-3 Library to use the BlueZ Linux Blu ii libbrlapi0.54.2-7+squeeze1 braille display access via BRLTTY ii libc6 2.13-21 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.22.0-3 Multi-protocol file transfer libra ii libglib2.0-02.30.2-4 GLib library of C routines ii libgnutls26 2.12.14-3GNU TLS library - runtime library ii libjpeg88c-2 Independent JPEG Group's JPEG runt ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libpng12-0 1.2.44-1+squeeze1PNG library - runtime ii libpulse0 1.0-4PulseAudio client libraries ii librados2 0.35-1 RADOS distributed object store cli ii librbd1 0.35-1 RADOS block device client library ii libsasl2-2 2.1.23.dfsg1-7 Cyrus SASL - authentication abstra ii libsdl1.2debian 1.2.14-6.1 Simple DirectMedia Layer ii libspice-server10.10.0-1 Implements the server side of the ii libtinfo5 5.9-4shared low-level terminfo library ii libuuid12.17.2-9 Universally Unique ID library ii libvdeplug2 2.2.3-3 Virtual Distributed Ethernet - Plu ii libx11-62:1.3.3-4X11 client-side library ii python 2.7.2-9 interactive high-level object-orie ii qemu-keymaps0.14.1+dfsg-3QEMU keyboard maps ii qemu-utils 0.14.1+dfsg-3QEMU utilities ii seabios 1.6.3-2 Legacy BIOS
Bug#651837: missing translation (po) files
Hello Peter, Peter Eisentraut [2011-12-12 16:19 +0200]: This package contains no translation (po) files. They should be the same as in the python 2 package. Indeed; I think I'll ship them in the main server package instead, as we can't ship the same files in two different packages. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651199: iwlwifi: Connection lost on WPA: Group rekeying
# regression severity 651199 important quit Hi Marco, Marco d'Itri wrote: This could be the same bug I am experiencing. Facts: - 3.1 has it, 3.0 does not - everything works fine while I am at home (WPA2 PSK) - my connections break very often when I am at work (WEP) - wpa_cli reassociate fixed the link - iw event -t does not log anything when the link breaks - I do not use NM, just plain wpa_supplicant I am not 100% certain, but link loss appears to be perfectly correlated with the WPA: Group rekeying completed with (...) [GTK=TKIP] messages from wpa_supplicant in syslog. Thanks for a clear summary (and likewise, thanks to others for the quick feedback). There have been a few iwlwifi fixes upstream recently. Could you try[1] v3.2-rc5 or later? If it doesn't work, there are even newer patches to try in linville's tree, but let's ignore that and pester upstream in that case. Hope that helps, Jonathan [1] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652269: puredata-core: make package suggest rather than recommand gem
On 12/15/2011 09:23 PM, 0 1 wrote: Package: puredata-core Version: 0.43.0-4 Some kind of wishlist bug, I suppose puredata-core is meant to provide a strict vanilla version of puredata. Don't know how to argue but I don't feel Gem is particularly essential for puredata. By default, aptitude installs recommended packages. Gem in turn depends on several multimedia libraries. Eventually, I would understand puredata package to recommand Gem, while puredata-core would not. i think the arguing is as follows: - for whatever reasons gem has been a recommends to puredata for ages - after splitting out puredata-core,..., installing puredata should still give you exactly the same user experience than before. - anybody advanced enough to install puredata-core rather than puredata would have the knowlegde to tell their package manager to not install recommended package if they do wish so (apt-get install --no-install-recommends puredata-core) having said that, i think it's a good idea to move the recommends from puredata-core to puredata. fgm,asrd IOhannes signature.asc Description: OpenPGP digital signature
Bug#639871: gupnp transition also needs to include newer gupnp-igd
On 2011-12-06 13:35, Andreas Henriksson wrote: Hello! It's become apparent that gupnp-igd 0.1.x (current version in debian) breaks with gupnp 0.18.x. The fix is released as gupnp-igd 0.2.x which also bumps soname. $ grep-dctrl -sPackage -i -r -F Build-Depends,Build-Depends-Indep \blibgupnp-igd-1.0-dev\b /var/lib/apt/lists/*_Sources | sort -u Package: amsn Package: farsight2 Package: libnice Package: sushi I've spoken to bigon about updating it (in experimental for now)... Someone please update the transition tracker! (And could we start the transition soon? Please? Pretty Please?) Hi, Sorry for the late reply from our end. By the looks of it we are almost ready to start this. :) So far we have recorded the following SONAME/package name changes: libgssdp-1.0-2 = libgssdp-1.0-3 libgupnp-1.0-3 = libgupnp-1.0-4 libgupnp-igd-1.0-3 = libgupnp-igd-1.0-4 And new one all appear to be ready in experimental already. However, in the previous email, the following -dev packages were also mentioned: - libgupnp-av-1.0-dev - Has a new version in experimental, but no SONAME change? - libgupnp-dlna-1.0-dev - Nothing new in experimental So, will there be a sourceful upload of gupnp-av and gupnp-dlna bumping their SONAME? If not, I believe the tracker is curently up to date[1] and we should be ready to start. ~Niels [1] http://release.debian.org/transitions/html/gssdp_gupnp.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652330: libapache2-mod-perl2: occasional t/modperl/pnotes2.t failures
Package: libapache2-mod-perl2 Version: 2.0.5-4 Severity: normal I'm seeing occasional failures with t/modperl/pnotes2.t, mostly with apache2-mpm-prefork but also once or twice with apache2-mpm-worker when the system is loaded. It's pretty clearly about this part of the tests: select undef, undef, undef, 0.2; # give it time to write the logfile Filing this mostly to document the issue. It's clearly not feasible to try and fix the raciness, and I don't recall seeing this happen on the buildds even on slower architectures. If it becomes a problem, it should be easy to raise the timeout. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524155: RM: basilisk2
reassign 524155 ftp.debian.org retitle 524155 RM: basilisk2 -- RoQA; ROP; RC-buggy; abandoned upstream thanks Hi, No response from maintainer and no bugfix for RC bugs in years. Please remove. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615031: less should wait for its children (zombie child)
found 615031 444-1
thanks
On 2011-02-25 03:37:09 +0100, Vincent Lefevre wrote:
Package: less
Version: 436-1
Severity: minor
less doesn't seem to wait for the sh started for the lesspipe command:
[...]
To reproduce the bug...
xvii:~ cat foo
éê
xvii:~ less foo
== append : to filename to view the UTF-8 encoded data
éê
UIDPID PPID C STIME TTY TIME CMD
vinc17 17796 9247 0 10:33 pts/000:00:00 less foo
vinc17 17797 17796 0 10:33 pts/000:00:00 [sh] defunct
with LESS=-ciMR, LESSOPEN=|/home/vinc17/bin/lesspipe %s and the
attached lesspipe script.
--
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
#!/bin/bash
# lesspipe.sh, a preprocessor for less (version 1.71)
#===
### THIS FILE IS GENERATED FROM lesspipe.sh.in, PLEASE GET THE TAR FILE
### from http://sourceforge.net/projects/lesspipe/
### AND RUN configure TO GENERATE A lesspipe.sh THAT WORKS IN YOUR ENVIRONMENT
#===
#
# Usage: lesspipe.sh is called when the environment variable LESSOPEN is set:
# LESSOPEN=|lesspipe.sh %s; export LESSOPEN (sh like shells)
# setenv LESSOPEN |lesspipe.sh %s(csh, tcsh)
# Use the fully qualified path if lesspipe.sh is not in the search path
# View files in multifile archives:
# less archive_file:contained_file
# This can be used to extract ASCII files from a multifile archive:
# less archive_file:contained_fileextracted_file
# As less is not good for extracting binary data use instead:
# lesspipe.sh archive_file:contained_fileextracted_file
# Even a file in a multifile archive that itself is contained in yet
# another archive can be viewed this way:
# less super_archive:archive_file:contained_file
# Display the last file in the file1:..:fileN chain in raw format:
# Suppress input filtering:less file1:..:fileN: (append a colon)
# Suppress decompression: less file1:..:fileN:: (append 2 colons)
#
# Required programs and supported formats: see the separate file README
# License: GPL (see file LICENSE)
# History: see the separate file ChangeLog
# Author: Wolfgang Friebel, DESY (Wolfgang.Friebel AT desy.de)
#
# Changes by Vincent Lefevre vinc...@vinc17.net
# 2011-10-14: support for diff output.
# 2011-09-11: removed the use of pdftohtml because it doesn't work.
# 2011-08-22: support UTF-8 HTML files with html2text.
# 2011-08-16: in charset conversions, use transliteration.
# 2010-10-26: improved charset conversion support by using file -i.
# 2007-10-22: in charset conversions, use replacement characters (useful
# for iconv from libiconv) instead of getting an error.
#
#===
( [[ -n 1 -n 2 ]] ) /dev/null 21 || exec zsh -y --ksh-arrays -- $0
${1+$@}
#setopt KSH_ARRAYS SH_WORD_SPLIT 2/dev/null
set +o noclobber
tarcmd='tar'
cmd_exist () {
command -v $1 /dev/null 21 return 0 || return 1
}
if [[ $LESS_ADVANCED_PREPROCESSOR = '' ]]; then
NOL_A_P=_NO_L_A_P
fi
filecmd()
{
file -L -s $@ | cut -d : -f 2-
file -L -s -i $@ 2 /dev/null | sed -n 's/.*charset=/;/p' | tr a-z A-Z
}
sep=: # file name separator
altsep==# alternate separator character
if [[ -f $1 $1 = *$sep* || $1 = *$altsep ]]; then
sep=$altsep
xxx=${1%=}
set $xxx
fi
if cmd_exist mktemp; then
tmpdir=$(mktemp -d ${TMPDIR:-/tmp}/lesspipe.XX)
nexttmp () {
# nexttmp -d returns a directory
mktemp $1 ${tmpdir}/
}
else
tmpdir=${TMPDIR:-/tmp}/lesspipe.$RANDOM
mkdir $tmpdir
nexttmp () {
new=$tmpdir/lesspipe.$RANDOM
[[ $1 = -d ]] mkdir $new
echo $new
}
fi
[[ -d $tmpdir ]] || exit 1
trap rm -rf '$tmpdir' 0
trap - PIPE
unset iconv
iconv()
{
if [[ -z $iconv ]]; then
iconv=command iconv $(printf %s$(command iconv --help | sed -n \
's/.*\(--.*-subst=\)\(FORMATSTRING\).*/\1\\033[7m?\\033[m/p' | \
tr \\n ' ')) -t //TRANSLIT
fi
$iconv $@
}
filetype () {
# wrapper for 'file' command
typeset name
name=$1
if [[ $1 = - ]]; then
dd bs=4 count=1 $tmpdir/file 2/dev/null
set $tmpdir/file $2
name=$filen
fi
typeset type
# type= $($filecmd -b $1) # not supported by all versions of 'file'
type=$(filecmd $1)
if [[ $type = empty ]]; then
# exit if file returns empty (e.g., with less archive:nonexisting_file)
exit 1
elif [[ $type = *XML* $name = *html ]]; then
type= HTML document text
elif [[ $type != *lzip\ compressed* ($name =
Bug#652063: When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared
On Thu, 15 Dec 2011, Raphael Hertzog wrote:
Yeah, that's not correct. The attached patch should fix this. It's
untested though and it would be great if you could confirm that it works
as expected.
It turns out it was not enough as dpkg will try to disappear the packages
also when it installs other packages (that just happen to share some
directories with the M-A: same packages).
Here's an updated version of the patch. It's also more restrictive than
the former one since it will refuse to disappear M-A: same packages simply
due to their file sharing, but it will allow such disappearence for the
non M-A: same cases. It seemed logical to allow this in the spirit of
supporting cross-grades (overwriting a M-A: foreign package by one of
another arch can then automatically disappear the former one).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
commit 64c51324c656612bda90eef71643ddfad94e3288
Author: Raphaël Hertzog hert...@debian.org
Date: Thu Dec 15 10:28:30 2011 +0100
dpkg: do not try to disappear other packages from the same set
Packages within a set can rightfully share files and should not
be disappeared in the case where they share all the files!
Closes: #652063
Reported-by: Martin Pitt mp...@debian.org
diff --git a/src/archives.c b/src/archives.c
index e32185a..cf1dd0e 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -152,6 +152,13 @@ filesavespackage(struct fileinlist *file,
if (thirdpkg == pkgbeinginstalled || thirdpkg == pkgtobesaved)
continue;
+/* A Multi-Arch: same package can share files and their presence in a
+ * third package of the same set is not a sign that we can get rid of
+ * it. */
+if (pkgtobesaved-installed.multiarch == multiarch_same
+thirdpkg-set == pkgtobesaved-set)
+ continue;
+
/* If !fileslistvalid then we've already disappeared this one, so
* we shouldn't try to make it take over this shared directory. */
debug(dbg_eachfiledetail,filesavespackage ... is 3rd package);
diff --git a/src/processarc.c b/src/processarc.c
index f783670..eed8683 100644
--- a/src/processarc.c
+++ b/src/processarc.c
@@ -1253,6 +1253,12 @@ void process_archive(const char *filename) {
otherpkg-status == stat_configfiles ||
otherpkg-clientdata-istobe == itb_remove ||
!otherpkg-clientdata-files) continue;
+/* Do not try to disappear other packages from the same set
+ * if they are Multi-Arch: same */
+if (pkg-installed.multiarch == multiarch_same
+otherpkg-installed.multiarch == multiarch_same
+otherpkg-set == pkg-set)
+ continue;
debug(dbg_veryverbose, process_archive checking disappearance %s,
pkg_name(otherpkg, pno_nonambig));
assert(otherpkg-clientdata-istobe == itb_normal ||
Bug#652331: libapache2-mod-perl2: FTBFS with apache2-mpm-event: tests hang
Package: libapache2-mod-perl2 Version: 2.0.5-4 Severity: normal X-Debbugs-Cc: apache2-mpm-ev...@packages.debian.org When building libapache2-mod-perl2 with apache2-mpm-event instead of apache2-mpm-worker, the test suite hangs. The test order is randomized and the hanging test name isn't printed out when it hangs, but looking at the process list reveals at least these (from different attempts): t/error/runtime.t t/hooks/startup.t t/protocol/pseudo_http.t Given this paragraph in the apache2-mpm-event description: This MPM is experimental and less tested than the worker and prefork MPMs. I think that just a Build-Conflicts declaration would be an appropriate fix for this problem on the libapache2-mod-perl2 side. Ideally the issues should of course be investigated properly and fixed in the MPM code where applicable, but I'm not going to work on that. Cc'ing the apache2 maintainers. Feel free to clone/reassign if you want to track this. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651933: I can reproduce this
On 2011-12-16 00:11:09 -0800, Peter Eckersley wrote: IOError: [Errno 2] No such file or directory: '/etc/wicd/manager-settings.conf' I haven't had the time to try, but after the upgrade (for which wicd didn't work) and the downgrade to the working version, my config was lost (wireless_interface was empty instead of being set to the usual wlan0). So, I may have been affected by the same problem. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652088: apt-cacher-import.pl fails to find renamed/moved library
On Wed, Dec 14, 2011 at 06:50:01PM +0100, gregor herrmann wrote: Package: apt-cacher Version: 1.7.2 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 root@guinan:~# /usr/share/apt-cacher/apt-cacher-import.pl Can't locate apt-cacher-lib.pl in @INC (@INC contains: /usr/share/apt-cacher/lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/share/apt-cacher/apt-cacher-import.pl line 53. If I see it correctly, apt-cacher-lib.pl was moved and renamed to lib/apt-cacher.pl, and this change is reflected in some files, but only partially in apt-cacher-import.pl. This trivial patch indeed fixes the error: Thanks. I thought I had changed them all! Mark -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644174:
Some update. I left my laptop unattended the whole night. Windows did perform a reboot after that. For some reason my USB mouse was unplugged and this morning my laptop did boot successfully my debian system. So short story: just unplugged any USB device and it should boot nicely. Let me know if I should just close this bug. Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652063: When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared
Martin Pitt [2011-12-15 11:34 +0100]:
Raphael Hertzog [2011-12-15 10:35 +0100]:
Yeah, that's not correct. The attached patch should fix this. It's
untested though and it would be great if you could confirm that it works
as expected.
I just tested it, and it works perfectly. Many thanks!
For the record, seems I spoke too soon. While it works with the
original test case now
sudo apt-get install --reinstall libpthread-stubs0{,:i386}
libpthread-stubs0-dev
it still fails when you do it separately:
$ LANG= sudo apt-get install --reinstall libpthread-stubs0{,:i386}
libpthread-stubs0-dev
[...]
The following NEW packages will be installed:
libpthread-stubs0:i386
Preparing to replace libpthread-stubs0 0.3-2.1ubuntu1 (using
.../libpthread-stubs0_0.3-2.1ubuntu1_amd64.deb) ...
Unpacking replacement libpthread-stubs0 ...
Selecting previously unselected package libpthread-stubs0:i386.
Unpacking libpthread-stubs0:i386 (from
.../libpthread-stubs0_0.3-2.1ubuntu1_i386.deb) ...
Preparing to replace libpthread-stubs0-dev 0.3-2.1ubuntu1 (using
.../libpthread-stubs0-dev_0.3-2.1ubuntu1_amd64.deb) ...
Unpacking replacement libpthread-stubs0-dev ...
Setting up libpthread-stubs0 (0.3-2.1ubuntu1) ...
Setting up libpthread-stubs0:i386 (0.3-2.1ubuntu1) ...
Setting up libpthread-stubs0-dev (0.3-2.1ubuntu1) ...
$ LANG= sudo apt-get install --reinstall libpthread-stubs0-dev
[...]
Preparing to replace libpthread-stubs0-dev 0.3-2.1ubuntu1 (using
.../libpthread-stubs0-dev_0.3-2.1ubuntu1_amd64.deb) ...
Unpacking replacement libpthread-stubs0-dev ...
(Noting disappearance of libpthread-stubs0:i386, which has been completely
replaced.)
Setting up libpthread-stubs0-dev (0.3-2.1ubuntu1) ...
The following package disappeared from your system as
all files have been overwritten by other packages:
libpthread-stubs0
Note: This is done automatic and on purpose by dpkg.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
Bug#293179: tetex-bin: Bug in font pcrr7tn with dvips: Backticks wrong
On 01.02.05 Hans baier (hansba...@web.de) wrote: Hi, Package: tetex-bin Version: 2.0.2-25 Severity: important I use the pslatex package to print Linux Seminar courseware. This is heavily dependent on the correct rendering of backticks. The backticks are rendered correctly if viewed in xdvi or PDF generated by pdflatex, whereas they are rendered incorrectly when using dvips. Alas, I cant switch to pslatex because I would have to convert 2000+ pages and hundreds of images to pdflatex. This bug concerns font pcrr7tn which is used in the pslatex-Style. The bold-face variant works fine. I just got the information, that the issue is solved in the latest release of the URW fonts: http://bugs.ghostscript.com/show_bug.cgi?id=688022 snip Chris Liddell 2011-12-15 16:21:08 UTC I believe this is fixed with the latest URW font release: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ea9a9517 snip No, I don't have the chance to test it. H. -- sigmentation fault pgpCGjJV5a8tX.pgp Description: PGP signature
Bug#651933: I can reproduce this
tags 651933 confirmed upstream fixed-upstream retitle 651933 wrong existance check for config files thanks Hello Vincent and Peter, On Fri, 16 Dec 2011 10:44:59 +0100, Vincent Lefevre wrote: On 2011-12-16 00:11:09 -0800, Peter Eckersley wrote: IOError: [Errno 2] No such file or directory: '/etc/wicd/manager-settings.conf' I haven't had the time to try, but after the upgrade (for which wicd didn't work) and the downgrade to the working version, my config was lost (wireless_interface was empty instead of being set to the usual wlan0). So, I may have been affected by the same problem. Yup, this was already fixed both upstream and in -2. The configuration loss was a bug of -1, so all people who upgraded to *that* version unfortunately lost it (and I'm really sorry, it didn't happen here :/, or maybe I just tested it the wrong way). Upgrades to -2 don't have that bug though. This was fixed upstream already: http://bazaar.launchpad.net/~wicd-devel/wicd/experimental/revision/663 The easy solution is to recreate the configfiles lost during the upgrade; that should let you start wicd. There are still a couple of fixes I made upstream, so probably I will release a -3, so that you don't have to keep local patches around :) Thanks, and sorry for the brokenness, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#652332: RM: python-openstack-compute -- ROM; deprecated by upstream
Package: ftp.debian.org Severity: normal This package is deprecated by upstream and should not be used anymore. It has been used by horizon but is not needed anymore. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652026: amavisd-new: Init-script not working (stop/restart)
Hi, On Thu, 15 Dec 2011, Henrique de Moraes Holschuh wrote: 503 pcew80@reincke:~ ps -aef | grep amavis amavis2299 1 0 00:47 ?00:00:01 amavisd (master) amavis2496 2299 0 00:47 ?00:00:00 amavisd (ch7-avail) amavis2497 2299 0 00:47 ?00:00:00 amavisd (ch7-avail) amavis2498 2299 0 00:47 ?00:00:00 amavisd (ch6-avail) reincke 7749 7078 0 08:32 pts/100:00:00 grep amavis 504 pcew80@reincke:~ cat /proc/2299/stat 2299 (amavisd (master) S 1 2299 2299 0 -1 4202560 9771 0 4 0 119 5 0 0 20 0 1 0 22660083 221208576 22204 18446744073709551615 1 1 0 0 0 0 0 4224 81927 18446744073709551615 0 0 17 2 0 0 7 0 0 Crap. The kernel has done us in. Reassigning to dpkg to get some input on what should be done. Raising severity because it will cause some services to not be stopped or restarted properly, which has security implications. Guys, 3.1 changes /proc/pid/stat, and breaks anything using start-stop-daemon --name that also messes with the name of the process. Due to the chage in /proc/pid/stat, the executable name is not matched anymore. What are those changes exactly? Because the kernel doesn't seem to always respect the name that the process sets for itself. I run 3.1.0-1-amd64 here and I have this: ┏rivendell:~/deb/core/dpkg (test-build) ┗(706)$ ps axf|grep 1758 1758 ?S 0:00 \_ avahi-daemon: chroot helper 4660 pts/8S+ 0:00 | \_ grep 1758 ┏rivendell:~/deb/core/dpkg (test-build) ┗(707)$ sudo cat /proc/1758/stat 1758 (avahi-daemon) S 1756 1754 1754 0 -1 4202560 83 0 1 0 0 0 0 0 20 0 1 0 2639 3158016 21 18446744073709551615 134512640 134630244 4292694960 4292694424 4151297072 0 0 0 0 0 0 0 17 1 0 0 0 0 0 This probably affects only processes that change their visible identity (or whatever the string output by ps -aef is called) like amavisd-new does. Unfortunately, using --exec is not enough when you're dealing with perl, python or other scripts. How should we proceed? Drop use of start-stop-daemon --name in amavisd-new and document this kernel ABI issue in start-stop-daemon(8)? Reassign to the kernel on the grounds that it broke the userspace ABI? Enhance start-stop-daemon to take a --namere (regexp) and use that in amavisd-new instead? I would first like to understand the problem because you said probably multiple times and I prefer to decide in full knowledge. Can anyone from the kernel team say us if there have been relevant changes here? Henrique, what lead you to conclude that there was a kernel change? I tried to look at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=fs/proc/array.c;hb=refs/heads/master but did not find any relevant change. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Russ Allbery r...@debian.org writes: Zachary Harris zacharyhar...@hotmail.com writes: My understanding of the FHS would be that if a library is a dependency of a binary in /bin or /sbin, then such library belongs in /lib, not /usr/lib. (If for some reason the library is also desired in /usr/lib then a sym link from /lib to /usr/lib, but not the other way around, is acceptable.) A review of past bug reports (e.g. #633019 and #639939 from this summer) shows that this policy gets repeatedly violated in Debian until someone catches it. I'm increasingly convinced by the recent discussion on debian-devel that doing all the (rather substantial) work required to keep this separation working is a waste of our collective time. We're not doing a very good job at it anyway, chasing all the library dependencies is a fair amount of work, and things have to keep moving around as dependencies change. And this is all to support use cases that, while real, are fairly marginal in my estimation. This does not seem like the most effective place for us to be spending our time. I don't know if it's worth the effort to unify /bin and /usr/bin or the other similar things that have been discussed from time to time, but I do think it may be time for Debian to just officially say that we don't support /usr on a (meaningfully) separate partition from /bin and /lib, and that binaries in /bin may have dependencies on /usr/lib. Absolutely NO, NO, NO. You can't just break all the systems out there that do have a seperate /usr partition. And that isn't what was suggested. The suggested approach is to have /usr mounted in initramfs (or in one of the first boot scripts). So what Debian could officially say is that /usr will be mounted and packages may freely use it at any time during boot. That the seperation of / and /usr becomes unimportant because both will always be available. But before any of that happens please first show us a working implementation of mounting /usr from initramfs and as first thing during boot. And that should probably be included in a stable release before the seperation of / and /usr is declared meaningless. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644174: ACPI I/O resource conflicts with ACPI region SMBI
Mathieu Malaterre wrote: So short story: just unplugged any USB device and it should boot nicely. Let me know if I should just close this bug. Thanks for the follow up. No, we shouldn't close this --- it seems it's just another sign that xhci support is a little broken in squeeze. Nice to see that's the *only* problem here. :) What is the latest squeeze kernel you've tried and reproduced this with? (cat /proc/version will say the current version in parentheses.) To move forward: - Please attach acpidump output. (I doubt it's relevant, but it's useful to have for reference.) - Please test a v3.2 release candidate from experimental. The only packages from outside squeeze that should be needed for this, aside from the kernel image itself, are linux-base and initramfs-tools. - If it reproduces the problem, please blacklist the xhci_hcd module by writing blacklist xhci_hcd to a file /etc/modprobe.d/mm-blacklist-xhci.conf, run update-initramfs -u -k all and reboot to try again without USB 3.0 support. If we're very lucky, this will work around the problem. In that case, please write a summary of the problem to upstream (linux-...@vger.kernel.org, cc-ing Sarah Sharp sarah.a.sh...@linux.intel.com and either me or this bug log so we can track the resulting discussion). Be sure to include: - steps to reproduce the problem - symptoms, and how they differ from what you expected - ways to avoid triggering the problem (maybe some USB ports trigger it and others don't? etc) - full dmesg output from booting, and a photo of the screen after reproducing the problem (ideally by running modprobe xhci_hcd in the very same run of Linux), as attachments - which kernel versions you've tested, and what happened with each - a link to this bug log for the full story - any other weird symptoms or observations Thanks for your patience and hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652333: nis stop should trigger unscd
Package: nis Version: 3.17-31 If I stop NIS client (e.g. due to a run level change), then unscd is not triggered to forget user information. I stumbled about this when I tried to create a local user on a laptop. I had stopped NIS and umounted nfs:/home. adduser told me that the UID is still in use. After stopping unscd adduser did not complain anymore. Platform is squeeze. Please reassign, if necessary. Regards Harri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646396: Starting the program ends with SIGSEGV.
Attachment - backtrace with debugging symbols.
--
populus tremula [echo populus2tremula1yahoo2com|tr 12 @.]
(gdb) r
Starting program: /usr/bin/gtimer
[Thread debugging using libthread_db enabled]
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
(gtimer:8245): Gtk-WARNING **: Unable to locate theme engine in module_path:
pixmap,
** Message: Building menu Failed: (null)
(gtimer:8245): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT
(object)' failed
Program received signal SIGSEGV, Segmentation fault.
0xb7aec113 in gdk_x11_gc_values_to_xvalues (values=0xbfffe788,
mask=GDK_GC_CLIP_MASK, xvalues=0xbfffe6c0, xvalues_mask=0xbfffe71c) at
/build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gdk/x11/gdkgc-x11.c:511
511
/build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gdk/x11/gdkgc-x11.c:
No such file or directory.
in
/build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gdk/x11/gdkgc-x11.c
(gdb) bt full
#0 0xb7aec113 in gdk_x11_gc_values_to_xvalues (values=0xbfffe788,
mask=GDK_GC_CLIP_MASK, xvalues=0xbfffe6c0, xvalues_mask=0xbfffe71c) at
/build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gdk/x11/gdkgc-x11.c:511
No locals.
#1 0xb7aec540 in gdk_x11_gc_values_to_xvalues (xvalues_mask=0xbfffe71c,
xvalues=0xbfffe6c0, mask=optimized out, values=0xbfffe788) at
/build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gdk/x11/gdkgc-x11.c:398
No locals.
#2 gdk_x11_gc_set_values (gc=0x80c9820, values=0xbfffe788,
values_mask=optimized out) at
/build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gdk/x11/gdkgc-x11.c:370
x11_gc = 0x80c9820
xvalues = {function = 0, plane_mask = 3221219208, foreground =
135043152, background = 3076151347, line_width = -1217786677, line_style = 8,
cap_style = -1218519978, join_style = -1073748228, fill_style = 1, fill_rule =
-1218011904, arc_mode = -1218112592, tile = 3076151965, stipple = 3077180619,
ts_x_origin = 8, ts_y_origin = -1218519978, font = 3077193022, subwindow_mode =
-1217778686, graphics_exposures = -1207999056, clip_x_origin = 135861808,
clip_y_origin = -1218815392, clip_mask = 3077180619, dash_offset = -1216846400,
dashes = -40 '\330'}
xvalues_mask = 0
#3 0xb7ab116e in IA__gdk_gc_set_values (gc=0x80c9820, values=0xbfffe788,
values_mask=GDK_GC_CLIP_MASK) at
/build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gdk/gdkgc.c:372
priv = 0x80c9850
__PRETTY_FUNCTION__ = IA__gdk_gc_set_values
#4 0xb7ab1233 in IA__gdk_gc_set_clip_mask (gc=0x80c9820, mask=0x807c960) at
/build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gdk/gdkgc.c:632
values = {foreground = {pixel = 3087003636, red = 12359, green = 47031,
blue = 1}, background = {pixel = 3221219280, red = 2454, green = 47103, blue =
16824}, font = 0x0, function = GDK_INVERT, fill = GDK_TILED, tile = 0x0,
stipple = 0x1, clip_mask = 0x807c960, subwindow_mode = 4657820, ts_x_origin =
-1212936192, ts_y_origin = -1213628784, clip_x_origin = -1208284688,
clip_y_origin = 134969360, graphics_exposures = 6, line_width = 6, line_style =
3086968240, cap_style = 1919, join_style = 3081441696}
#5 0xb7e23443 in gtk_pixmap_expose (widget=0x80b7810, event=optimized out)
at /build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gtk/gtkpixmap.c:201
misc = 0x80b7810
y = 6
pixmap = 0x80b7810
x = 6
xalign = optimized out
#6 gtk_pixmap_expose (widget=0x80b7810, event=0x80a0238) at
/build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gtk/gtkpixmap.c:173
No locals.
#7 0xb7c838a2 in _gtk_marshal_BOOLEAN__BOXED (closure=0x80b6198,
return_value=0xbfffe9e4, n_param_values=2, param_values=0x8198718,
invocation_hint=0xbfffe9d0, marshal_data=0xb7e232e0) at
/build/buildd-gtk+2.0_2.24.8-2-i386-QCV9OW/gtk+2.0-2.24.8/gtk/gtkmarshalers.c:86
callback = 0xb7e232e0 gtk_pixmap_expose
cc = 0x80b6198
data1 = optimized out
data2 = optimized out
v_return =
Bug#648565: [pkg-bacula-devel] New upstream release
W dniu 15.12.2011 22:42, Luca Capello pisze: NB, your reply should have been a follow-up to [1] and to the Debian BTS: I replied on purpose to all the people who asked for an updated version to document the status on the BTS (which is supposed to stay forever, not like this mailing list). I just wanted to ask question and wasn't sure if cluttering BTS was a good idea. I'm also interested in building packages of Bacula 5.2.x. Recently Luca Capello said [1] that there is updated repo [2] that provides 5.2.1 version. debian/control file is quite old so I'm not sure if this repo is correct one or I miss something. [1] http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/2011-December/000113.html [2] http://git.debian.org/?p=pkg-bacula/pkg-bacula.git;a=summary What does it mean that the Git debian/control is quite old? Have you checked it against the last package available in Debian, to find out where is the problem? Indeed, the Git repository at [2] is missing the last uploaded Debian version: Hauke, I guess you forgot a `git pull`, can you do it, please? This is what I meant 'old debian/control' :) I looked for some development branch with you improved build procedure. I really look forward for it. I tried to fix it by myself (build all DB drivers at one time) but stuck in shlibs packaging. BTW, the Git repository should be 'bacula.git' and not 'pkg-bacula.git', given that it has never been included in any official Debian package yet I will fix it in the next days. Great :) -- Bartosz Cisek Admin email: bartosz.ci...@nasza-klasa.pl tel: +48 519 300 122 Nasza Klasa Sp. z o.o., ul. Gen. J. Bema 2, 50-265 Wrocław Sąd Rejonowy dla Wrocławia - Fabrycznej we Wrocławiu, VI Wydział Gospodarczy Krajowego Rejestru Sądowego, nr KRS:289629, NIP:898-21-22-104 REGON:020586020, Kapitał zakładowy: 67 850,00 PLN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Fri, Dec 16, 2011 at 07:34:16AM +0100, Christian PERRIER wrote: (reducing CC as I guess that most are subscribed to -devel) Quoting Russ Allbery (r...@debian.org): I don't think these things are alike. Separating /var and /tmp from the rest of the file systems is done because those partitions contain varying amounts of data and often fill if something goes wrong, but can fill without impacting the rest of the system and allowing easy recovery if they're not on the same partition as everything else. Separating /var continues to be good and recommended practice if you're running anything that's likely to produce a lot of output, IMO. (/tmp should probalby just be tmpfs, but that's another discussion.) I'm inclined to follow this advice and would indeed propose that the atomic partman-auto recipe is kept, however without a separate /usr partition (discussions on -devel and the current practice convinced me that a separate /usr is seomthing that probably belongs to the former century..:-) So, would it be OK for participants in this discussion is we, in the installer, just drop separate /usr but keep the atomic recipe (which is not the default choice, by the way)? Dropping /usr is a good idea, I think, and continuing to keep /var separate would also be sensible. Regarding /tmp, we're now defaulting to a tmpfs for new installs, so I'm not certain if having a separate /tmp by default is a good idea or not. I would certainly like for /tmp in particular (and tmpfses in general) to become configurable through the partitioner, which would then also check that sufficient swap is also allocated at the same time. Once we have /etc/fstab.d fully supported by mount (with the next util-linux release, probably in early January), I will be looking at making all the initscripts mountpoints currently hardcoded in the init scripts like mountkernfs etc. into conffiles in fstab.d. It would then be possible for the installer to edit these files quite simply to change the defaults, perhaps using the partitioner as a frontend. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Roger Leigh rle...@codelibre.net writes:
On Wed, Dec 14, 2011 at 12:53:24PM -0500, Zachary Harris wrote:
I could be wrong, but my (admittedly stereotyped) impression of the
standard use cases is that if you've got someone who DOES want to mount
/usr separately from / (e.g. over NFS or because of a selectively
encrypted LVM), such person is more likely wanting to do so in pure
Debian, rather than, say, in Ubuntu.
This is a bit beside the point. People keep bringing up mounting /usr
over NFS. No one to date has provided a sensible use case for it.
This is because old timers (or whoever) have failed to notice a
fundamental flaw: *package management does not work with a shared /usr*.
The cluster setup I use at work uses an initramfs with all the essential
stuff in it and mounts the rest over NFS. The reason why this works is
that the / is just as shared as /usr. Just one is shared via pxe and
then other via NFS.
The reason for not having everything on NFS is to reduce network load
and that nodes should be minimally functional without NFS. Esspecially
that you can still log in as root and diagnose problems.
On a Debian there are really only two categories for partitions:
those under the control of the package manager, and those which
are not (user data etc.). Does it make sense to split package-managed
files over multiple partitions? (other than /var)
This is *the* key point. Under a package managed distribution /
and /usr are part of a *managed whole*. They can't exist separately,
even if they are on different partitions, mounted over NFS, or
whatever. It's fine that such things /work/, but we do need to
question /why/ one would do such a thing. If you're mounting /usr
over NFS, the real question is why aren't you mounting / over NFS,
which also then includes /usr?. Mounting /usr separately makes no
sense *at all*.
The same argument applies to encryption. / and /usr both contain a
selection of programs, libraries etc. If you're encrypting one, why
would you not encrypt all of it? And the same for mounting read-only.
/, specifically /etc, contains sensitive information so it has to be
encrypted. /usr on the other hand does not and encrypting it is just a
waste of cpu time.
This would actually call for having /etc a seperate (encrypted)
partition and /usr not. Encrypting /bin or /lib is indeed as useless as
/usr.
The question that needs answering is this:
what are the reasons, today, for a separate /usr?
Excluding historical practice. What real function does it have?
Does it have any reason to continue to exist?
And regarding the LSB: I checked, and it would be entirely compliant
for Debian to merge the two.
Enforce a
policy that anything being put into /sbin or /bin must pass the ldd
test. If a dependency is in /usr/lib then negotiations have to be made
to reach an agreement to either downgrade the binary to /usr/{s,}bin
or upgrade the library to /lib. (In the case of downgrading the
binary, you can say that the user of the Debian package bears the
responsibility to have ensured that the executables he personally
considers essential in his own context were accessible where he would
need them when he would need them. But the distro itself should take
responsibility for being CONSISTENT, and thus should not say, Here's
something available to you in /sbin---oh, but you can't actually use it
from there (so to speak).)
The problem here is, can we /be/ consistent? What is one system's
essential package required for bringing up a working system is
someone else's occasionally-used tool that's not important at all.
Yet both might be required to be on the rootfs. We can't be all
things to all people in the current state. But unification /would/
*guarantee* things would always work and be consistent: every
program and library would always be right there on the rootfs.
You are not reading him.
consistent == if it is in /sbin or /bin then it works without /usr.
consistent != everything even some insane user might want in / is in /.
That was exactly his point.
The status quo is a best effort. Things sometimes break, and
there's an continuing migration of essential packages to the
rootfs. Given that a modern initramfs can mount pretty much any
filesystem, either locally or over a network, what's the *real*
reason for a separate /usr? It's certainly not for any booting-
related reason.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649417: [gnome-system-log] Program received signal SIGABRT, Aborted.
severity 649417 important quit Attachment - backtrace with debugging symbols. -- populus tremula [echo populus2tremula1yahoo2com|tr 12 @.] (gdb) r Starting program: /usr/bin/gnome-system-log [Thread debugging using libthread_db enabled] [New Thread 0xb707cb70 (LWP 9222)] [New Thread 0xb687bb70 (LWP 9223)] [New Thread 0xb186ab70 (LWP 9224)] [New Thread 0xb1069b70 (LWP 9225)] [Thread 0xb186ab70 (LWP 9224) exited] [Thread 0xb1069b70 (LWP 9225) exited] [New Thread 0xb1069b70 (LWP 9306)] [New Thread 0xb186ab70 (LWP 9307)] [Thread 0xb186ab70 (LWP 9307) exited] [Thread 0xb1069b70 (LWP 9306) exited] [New Thread 0xb1069b70 (LWP 9650)] [New Thread 0xb186ab70 (LWP 9651)] [Thread 0xb1069b70 (LWP 9650) exited] [New Thread 0xb1069b70 (LWP 9652)] [Thread 0xb186ab70 (LWP 9651) exited] *** glibc detected *** /usr/bin/gnome-system-log: free(): invalid next size (fast): 0x08302ae0 *** === Backtrace: = /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6aa81)[0xb7695a81] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6c2e8)[0xb76972e8] /lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d)[0xb769a39d] /lib/i386-linux-gnu/libglib-2.0.so.0(+0x4c38b)[0xb782538b] === Memory map: 08048000-08061000 r-xp 08:02 31608 /usr/bin/gnome-system-log 08061000-08062000 rw-p 00018000 08:02 31608 /usr/bin/gnome-system-log 08062000-084e7000 rw-p 00:00 0 [heap] b06e3000-b06ff000 r-xp 08:02 133073 /lib/i386-linux-gnu/libgcc_s.so.1 b06ff000-b070 rw-p 0001b000 08:02 133073 /lib/i386-linux-gnu/libgcc_s.so.1 b070-b0721000 rw-p 00:00 0 b0721000-b080 ---p 00:00 0 b0817000-b0869000 r--p 08:02 297819 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf b0869000-b086a000 ---p 00:00 0 b086a000-b106a000 rw-p 00:00 0 b106a000-b106b000 ---p 00:00 0 b106b000-b186b000 rw-p 00:00 0 b186b000-b187f000 r-xp 08:02 21428 /usr/lib/i386-linux-gnu/gio/modules/libgioremote-volume-monitor.so b187f000-b188 rw-p 00013000 08:02 21428 /usr/lib/i386-linux-gnu/gio/modules/libgioremote-volume-monitor.so b188-b19c9000 r-xp 08:02 6938 /usr/lib/libxml2.so.2.7.8 b19c9000-b19ce000 rw-p 00149000 08:02 6938 /usr/lib/libxml2.so.2.7.8 b19ce000-b19cf000 rw-p 00:00 0 b19cf000-b1a09000 r-xp 08:02 3271 /usr/lib/i386-linux-gnu/libcroco-0.6.so.3.0.1 b1a09000-b1a0c000 rw-p 00039000 08:02 3271 /usr/lib/i386-linux-gnu/libcroco-0.6.so.3.0.1 b1a0c000-b1a43000 r-xp 08:02 5299 /usr/lib/i386-linux-gnu/librsvg-2.so.2.34.2 b1a43000-b1a44000 rw-p 00037000 08:02 5299 /usr/lib/i386-linux-gnu/librsvg-2.so.2.34.2 b1a4b000-b1a5a000 r--p 08:02 297808 /usr/share/fonts/truetype/ttf-bitstream-vera/VeraBd.ttf b1a5a000-b1a5b000 r-xp 08:02 130902 /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so b1a5b000-b1a5c000 rw-p 1000 08:02 130902 /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so b1a5c000-b1a79000 r--s 08:02 265984 /usr/share/mime/mime.cache b1a79000-b1a86000 r--p 08:02 297809 /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf b1a86000-b1a88000 r-xp 08:02 29732 /usr/lib/i386-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so b1a88000-b1a89000 rw-p 1000 08:02 29732 /usr/lib/i386-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so b1a89000-b1a8f000 r--s 08:02 427448 /var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-le32d4.cache-3 b1a8f000-b1a96000 r--s 08:02 427446 /var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-le32d4.cache-3 b1a96000-b1a99000 r--s 08:02 427445 /var/cache/fontconfig/de156ccd2eddbdc19d37a45b8b2aac9c-le32d4.cache-3 b1a99000-b1a9d000 r--s 08:02 427444 /var/cache/fontconfig/3047814df9a2f067bd2d96a2b9c36e5a-le32d4.cache-3 b1a9d000-b1aaa000 r--s 08:02 427443 /var/cache/fontconfig/d52a8644073d54c13679302ca1180695-le32d4.cache-3 b1aaa000-b1aaf000 r--s 08:02 427442 /var/cache/fontconfig/105b9c7e6f0a4f82d8c9b6e39c52c6f9-le32d4.cache-3 b1aaf000-b1ab6000 r--s 08:02 427437 /var/cache/fontconfig/cabbd14511b9e8a55e92af97fb3a0461-le32d4.cache-3 b1ab6000-b1abe000 r--s 08:02 427434 /var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-le32d4.cache-3 b1abe000-b2504000 r--p 08:02 278787 /usr/share/icons/hicolor/icon-theme.cache b2504000-b5fa2000 r--p 08:02 278786 /usr/share/icons/gnome/icon-theme.cache b5fa2000-b5fd r-xp 08:02 543 /usr/lib/i386-linux-gnu/libbluray.so.1.0.0 b5fd-b5fd1000 r--p 0002d000 08:02 543 /usr/lib/i386-linux-gnu/libbluray.so.1.0.0 b5fd1000-b5fd2000 rw-p 0002e000 08:02 543 /usr/lib/i386-linux-gnu/libbluray.so.1.0.0 b5fd2000-b5fd4000 r-xp 08:02 131219
Bug#652335: python-apt: [INTL:nl] Dutch translation update
Package: python-apt Severity: wishlist Tags: patch l10n Hello, Attached is the updated Dutch translation of the python-apt package. Please include it in your next upload. Regards, -- Jeroen Schot # Ducht translation of python-apt. # Copyright (C) 2006-2011 THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the python-apt package. # Tino Meinen a.t.mei...@chello.nl, 2006. # Jeroen Schot sc...@a-eskwadraat.nl, 2011. # msgid msgstr Project-Id-Version: update-manager HEAD\n Report-Msgid-Bugs-To: python-...@packages.debian.org\n POT-Creation-Date: 2009-07-19 15:59+0200\n PO-Revision-Date: 2011-12-16 11:45+0100\n Last-Translator: Jeroen Schot sc...@a-eskwadraat.nl\n Language-Team: Debian l10n Dutch debian-l10n-du...@lists.debian.org\n Language: nl\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #. ChangelogURI #: ../data/templates/Ubuntu.info.in.h:4 #, no-c-format msgid http://changelogs.ubuntu.com/changelogs/pool/%s/%s/%s/%s_%s/changelog; msgstr http://changelogs.ubuntu.com/changelogs/pool/%s/%s/%s/%s_%s/changelog; #. Description #: ../data/templates/Ubuntu.info.in:13 msgid Ubuntu 9.10 'Karmic Koala' msgstr Ubuntu 9.10 'Karmic Koala' #. Description #: ../data/templates/Ubuntu.info.in:31 msgid Cdrom with Ubuntu 9.10 'Karmic Koala' msgstr CD met Ubuntu 9.10 'Karmic Koala' #. Description #: ../data/templates/Ubuntu.info.in:74 msgid Ubuntu 9.04 'Jaunty Jackalope' msgstr Ubuntu 9.04 'Jaunty Jackalope' #. Description #: ../data/templates/Ubuntu.info.in:92 msgid Cdrom with Ubuntu 9.04 'Jaunty Jackalope' msgstr CD met Ubuntu 9.04 'Jaunty Jackalope' #. Description #: ../data/templates/Ubuntu.info.in:135 msgid Ubuntu 8.10 'Intrepid Ibex' msgstr Ubuntu 8.10 'Intrepid Ibex' #. Description #: ../data/templates/Ubuntu.info.in:153 msgid Cdrom with Ubuntu 8.10 'Intrepid Ibex' msgstr CD met Ubuntu 8.10 'Intrepid Ibex' #. Description #: ../data/templates/Ubuntu.info.in:197 msgid Ubuntu 8.04 'Hardy Heron' msgstr Ubuntu 8.04 'Hardy Heron' #. Description #: ../data/templates/Ubuntu.info.in:215 msgid Cdrom with Ubuntu 8.04 'Hardy Heron' msgstr CD met Ubuntu 8.04 'Hardy Heron' #. Description #: ../data/templates/Ubuntu.info.in:252 msgid Ubuntu 7.10 'Gutsy Gibbon' msgstr Ubuntu 7.10 'Gutsy Gibbon' #. Description #: ../data/templates/Ubuntu.info.in:270 msgid Cdrom with Ubuntu 7.10 'Gutsy Gibbon' msgstr CD met Ubuntu 7.10 'Gutsy Gibbon' #. Description #: ../data/templates/Ubuntu.info.in:305 msgid Ubuntu 7.04 'Feisty Fawn' msgstr Ubuntu 7.04 'Feisty Fawn' #. Description #: ../data/templates/Ubuntu.info.in:323 msgid Cdrom with Ubuntu 7.04 'Feisty Fawn' msgstr CD met Ubuntu 7.04 'Feisty Fawn' #. Description #: ../data/templates/Ubuntu.info.in:357 msgid Ubuntu 6.10 'Edgy Eft' msgstr Ubuntu 6.10 'Edgy Eft' #. CompDescription #: ../data/templates/Ubuntu.info.in:362 msgid Community-maintained msgstr Door de gemeenschap beheerd #. CompDescription #: ../data/templates/Ubuntu.info.in:368 msgid Restricted software msgstr Beperkte software #. Description #: ../data/templates/Ubuntu.info.in:375 msgid Cdrom with Ubuntu 6.10 'Edgy Eft' msgstr CD met Ubuntu 6.10 'Edgy Eft' #. Description #: ../data/templates/Ubuntu.info.in:409 msgid Ubuntu 6.06 LTS 'Dapper Drake' msgstr Ubuntu 6.06 LTS 'Dapper Drake' #. CompDescriptionLong #: ../data/templates/Ubuntu.info.in:412 msgid Canonical-supported Open Source software msgstr Door Canonical ondersteunde opensourcesoftware #. CompDescription #: ../data/templates/Ubuntu.info.in:414 msgid Community-maintained (universe) msgstr Door de gemeenschap beheerd (universe) #. CompDescriptionLong #: ../data/templates/Ubuntu.info.in:415 msgid Community-maintained Open Source software msgstr Door de gemeenschap beheerde opensourcesoftware #. CompDescription #: ../data/templates/Ubuntu.info.in:417 msgid Non-free drivers msgstr Niet-vrije stuurprogramma's #. CompDescriptionLong #: ../data/templates/Ubuntu.info.in:418 msgid Proprietary drivers for devices msgstr Niet-vrije stuurprogramma's voor apparaten #. CompDescription #: ../data/templates/Ubuntu.info.in:420 msgid Restricted software (Multiverse) msgstr Beperkte software (Multiverse) #. CompDescriptionLong #: ../data/templates/Ubuntu.info.in:421 msgid Software restricted by copyright or legal issues msgstr Software die door auteursrechten of wettelijke regelingen beperkt wordt. #. Description #: ../data/templates/Ubuntu.info.in:427 msgid Cdrom with Ubuntu 6.06 LTS 'Dapper Drake' msgstr CD met Ubuntu 6.06 LTS 'Dapper Drake' #. Description #: ../data/templates/Ubuntu.info.in:439 msgid Important security updates msgstr Belangrijke veiligheidsupdates #. Description #: ../data/templates/Ubuntu.info.in:444 msgid Recommended updates msgstr Aanbevolen updates #. Description #: ../data/templates/Ubuntu.info.in:449 msgid Pre-released updates msgstr Voorgestelde updates #. Description #: ../data/templates/Ubuntu.info.in:454 msgid Unsupported updates msgstr
Bug#652336: conky: Conky segfaults when interval in execpi is big enough
Package: conky
Version: 1.8.1-6
Severity: normal
After update to version 1.8.1-6 conky started to segfault when using execpi
with big enough interval (i have segfault at ~2000 and more). To reproduce
write something like ${execpi 2800 date} in TEXT section of config.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.1.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages conky depends on:
ii conky-all 1.8.1-6
conky recommends no packages.
conky 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#524155: RM: basilisk2
On 11-12-16 at 11:35am, Riku Voipio wrote: No response from maintainer and no bugfix for RC bugs in years. Please remove. Hi, I am maintainer, and I agree with dropping this package from the archive. - 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: Digital signature
Bug#595106: E-MAIL DE VALIDAÇÃO
Caro Webmail / Conta de Usuário E-mail Estamos atualizando nosso banco de dados e e-mail centro conta. Estamos a excluir todas as contas de webmail não utilizados e criar mais espaço para novas contas. Para garantir que você não experimenta interrupção do serviço durante este período, por favor clique no link Validation E-mail: Link de validação https://docs.google.com/spreadsheet/viewform?formkey=dFUydU43SGhlSUtVTnZuVGR6TnMwY3c6MQ Depois de ter preenchido o formulário com sucesso, você terá que clicar em ENVIAR. Webmail © 2011 Atualização da equipe Código aviso: ID67565434. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Thu, Dec 15, 2011 at 06:19:54PM +0100, Marco d'Itri wrote:
On Dec 15, Roger Leigh rle...@codelibre.net wrote:
You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
/usr/ :-)
Well, I think I still need persuading that this is the right direction
to move the files. I still think that moving /usr to / is a better
strategy, albeit introducing some problems with users who would need
/usr to / does not allow any new features, while / to /usr allows
implementing new features like creating OS snapshots at file system
level (something which Fedora already supports) or a real complete OS
image (to be NFS-shared, replicated, etc).
I'm not quite sure I see why such new features would be dependent upon
this.
Please correct my confusion if I'm wrong, but I'm not sure I can see
why it wouldn't be possible to snapshot the rootfs whichever way we
migrate files. Both / and /usr would need to be snapshotted as a whole
in order to do proper rollbacks wouldn't they? So why would migrating
from /usr to / prevent this?
WRT mounting additional filesystems in the initramfs, how difficult
would it be to add an additional mount option to /etc/fstab entries,
e.g. init or initramfs to mark them as being required for mounting
in the initramfs. This could include /, /usr, /etc and anything else
the admin deems necessary for booting, and would just be checked and
added when creating/updating the initramfs.
/ is already mountable, while /etc obviously could not be if you want to
look at fstab. I see no compelling reasons to create standalone file
systems for the other directories, which are small and static.
If we could add an entry such as:
/dev/mapper/etc /etc ext4 initramfs 0 1
to /etc/fstab, then it could be added to a list of filesystems to be
mounted in the initramfs. Obviously a change to /etc/fstab would
require the initramfs to be updated, but when it came to mounting the
rest of the filesystems once the initramfs hands over to the rootfs
init, it could continue to use the real /etc/fstab. The only real
change would be that certain filesystems would have been pre-mounted.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650359: segmentation fault gmpc
I've just upgraded gmpc upto 11.8.16-1. It always crashes. The bug is reproducible in a few hosts (desktop, notebook, the other desktop). Hello ! Thanks a lot for the backtrace, that helps. I have a few questions to narrow a bit htis bug : * Do you have gmpc-plugins installed too (and which version) ? If so, does the problem occur when you launch gmpc with the --disable-plugins switch ? That was the first thing that I tried to do. When it chrashed the first time, I deleted gmpc-plugins. It crashes with plugins. It crashes without plugins. :( Thanks for the trace. Did you also try to remove (after making a backup) ~/.cache/gmpc (or $XDG_CACHE_HOME/gmpc) ? I am preparing gmyr (ITP #651416) in order to package a newer git snapshot, where the provider code has disappeared. Hi! After removing ~/.cache/gmpc gmpc began to work fine. Now is the second day it is started :) If it crashes I'll report the bug :) -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Bug#635569: Pending upload
Hi, there is a changelog in SVN saying ctk (0.1.0~git2003-1) experimental; urgency=low ... * Fix spelling in d/control. Closes: #635569 ... -- Mathieu Malaterre mathieu.malate...@gmail.com Sun, 04 Sep 2011 14:53:54 +0200 but despite the fact that the target dist is not UNRELEASED the package did not showed up in experimental. Mathieu, could you please either upload (prefered) or at least mark the status of packaging correctly? 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#651529: rsyslog: FTBFS on hurd-i386
While that could be the easy way out, it would definitely be wrong. Such limits can be OS or filesystem specific, if at all. They do not even represent reality on GNU/Linux! Try this: I try to stay out of these politics, but I found it beneficial to remove the dependency on MAX_PATH. It actually solved two error conditions that otherwise could occur (not sure if the dlopen call will fail in these cases, though). At least the code got smaller. I have enhanced v5-devel, patch is available here: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=01c7c9ffc6771f73df9ee0bc 18e30534d6c6974c I would appreciate if you could have a look at it; the pointer arithmetic is obviously easy to get wrong. Thanks, Rainer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553354: diff: shouldn't be marked as essential ...
forcemerge 216768 553354 affects 216768 + aptitude thanks `aptitude show' and `aptitude search ~e' both determine essential by: pkg-Flags pkgCache::Flag::Essential These flags are shared by *all* versions of a package. If one version is marked essential in it's control file, then all are considered essential by apt and aptitude. In the case of this bug, `diff' was essential in lenny but not in squeeze (now a transitional package). This is actually a long-standing issue in apt; merged. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648954: [patch] doc-base Conflicts are insufficient
found 648954 5.14.2-6
tag 648954 patch
thanks
Hello Niko, Dominic,
we still got quite a lot of upgrade failures with -6
(https://launchpad.net/bugs/902553).
-6 adds a Conflicts: doc-base ( 0.10.3) to perl-base. This correctly
prevents unpacking of perl-base 5.14 and breaking the doc-base
trigger. However, in above LP bug we see
Preparing to replace libuuid-perl 0.02-4build1 (using
.../libuuid-perl_0.02-4build2_i386.deb) ...
Unpacking replacement libuuid-perl ...
Preparing to replace update-inetd 4.38+nmu1 (using
.../update-inetd_4.41_all.deb) ...
Unpacking replacement update-inetd ...
Preparing to replace perl-modules 5.12.4-4 (using
.../perl-modules_5.14.2-6_all.deb) ...
Unpacking replacement perl-modules ...
Preparing to replace perl 5.12.4-4 (using .../perl_5.14.2-6_i386.deb) ...
Unpacking replacement perl ...
Selecting previously deselected package libperl5.14.
Unpacking libperl5.14 (from .../libperl5.14_5.14.2-6_i386.deb) ...
[...]
Unpacking replacement libpurple0 ...
[...]
Processing triggers for doc-base ...
/usr/bin/perl: symbol lookup error: /usr/lib/perl5/auto/UUID/UUID.so: undefined
symbol: Perl_xs_apiversion_bootcheck
dpkg: error processing doc-base (--unpack):
subprocess installed post-installation script returned error exit status 127
At this point neither doc-base nor perl-base was unpacked (which is
what -5 and -6 fixed). Full logs are in the LP bug and its duplicates,
but above is the gist of it.
So we need to Conflicts: harder. Patch attached.
Thanks for considering,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
diff -Nru perl-5.14.2/debian/changelog perl-5.14.2/debian/changelog
--- perl-5.14.2/debian/changelog2011-11-28 21:05:37.0 +0100
+++ perl-5.14.2/debian/changelog2011-12-16 12:31:26.0 +0100
@@ -1,3 +1,12 @@
+perl (5.14.2-6ubuntu1) precise; urgency=low
+
+ * debian/control: Add doc-base conflict also to perl, perl-modules, and
+libperl5.14. Otherwise they can get unpacked before upgrading perl-base
+and doc-base and thus still cause symbol lookup errors in the doc-base
+trigger. (Closes: #648954, LP: #902553)
+
+ -- Martin Pitt martin.p...@ubuntu.com Fri, 16 Dec 2011 12:25:31 +0100
+
perl (5.14.2-6) unstable; urgency=low
[ Niko Tyni ]
diff -Nru perl-5.14.2/debian/control perl-5.14.2/debian/control
--- perl-5.14.2/debian/control 2011-11-28 21:05:37.0 +0100
+++ perl-5.14.2/debian/control 2011-12-16 12:31:05.0 +0100
@@ -219,6 +220,7 @@
libfile-path-perl,
libshell-perl,
libperl4-corelibs-perl
+Conflicts: doc-base ( 0.10.3)
Description: Core Perl modules
Architecture independent Perl modules. These modules are part of Perl and
required if the `perl' package is installed.
@@ -247,6 +249,7 @@
Priority: optional
Architecture: any
Depends: ${shlibs:Depends}, perl-base (= ${binary:Version})
+Conflicts: doc-base ( 0.10.3)
Replaces: perl-base (= 5.8.7-4)
Description: shared Perl library
This package is required by programs which embed a Perl interpreter to
@@ -268,7 +271,7 @@
Priority: standard
Architecture: any
Depends: perl-base (= ${binary:Version}), perl-modules (= ${source:Version}),
${shlibs:Depends}
-Conflicts: libjson-pp-perl ( 2.27200-2)
+Conflicts: libjson-pp-perl ( 2.27200-2), doc-base ( 0.10.3)
Breaks: perl-doc ( ${Upstream-Version}-1),
libdigest-md5-perl ( 2.51),
libmime-base64-perl ( 3.13),
signature.asc
Description: Digital signature
Bug#474185: git-cvsimport fails silently converting cvs-buildpackage repos
# difficult severity 474185 wishlist quit Bdale Garbee wrote: git-cvsimport -o master -a -A ../author-conv-file $pkg git branch -m source-dist upstream done A couple packages had problems for reasons I understand after some reading, but even a simple package like 'sudo' with a purely linear revision history that showed no errors during the conversion ended up with a fundamentally broken git repository. Thanks. Now the package description says Unfortunately, in many situations the import leads to incorrect results. For reliable, one-shot imports, cvs2git from the cvs2svn package or parsecvs may be a better fit. so it seems safe to lower the severity. Keeping the bug because the lack of a robust incremental import tool from cvs is still unfortunate. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652035: wicd-curses: Crashs when running (Python UnicodeDecodeError)
On Thu, 15 Dec 2011 18:15:56 +0100, Florian Birée wrote: [..] If you think I should try your patch, I can do it, but I think it is not related to this bug... I just uploaded 1.7.1~b3-3, which contains the unicode-related fixes too. Please test it :) Thanks, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#631816: libqwt-dev: apt reinstalls the package
Hi, each time I run apt-get upgrade, apt-get reinstalls the libqwt-dev package. APT detects installed vs. the online version as different versions because of different dependencies. If we have a close look, we can see that: Online is: Replaces: libqwt5-qt4-dev ( 6.0.0-) After installation we have in dpkg/status: Replaces: libqwt5-qt4-dev ( 6.0.0) So dpkg is dropping the dash at the end of the versionnumber. Not that this is completely unreasonable as the dash doesn't make a lot of sense here, but i am cc'ing dpkg-mailinglist just in case they want to have a look at it. I think we had a similar issue with explicit mentioning of the zero epoch in the past. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652338: ubiquity-extension: spurious ${python:Depends} in debian/control
Source: ubiquity-extension
Version: 0.6.1~pre2023-1
Severity: wishlist
ubiquity-extension has Depends: ..., ${python:Depends}, ... in
debian/control. However, as far as I can tell, this package doesn't have
anything to do with python. I believe that this substitution variable
could be removed.
--
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#652339: Error code was NT code 0x1c010002 next a login failure in a samba server with winbind
Package: winbind Version: 2:3.5.6~dfsg-3squeeze5 Severity: important I have a samba server connected to a samba PDC. I can connect fine to the share folders but next a login failure appear the error NT code 0x1c010002 (0x1c010002) and it is impossible to connect with any user. I have to delete samba cache and restart samba and winbind to have a normal use. 1) First I can login without any problem from different clients with different OS. On the client: myuser@mycomputer:~$ smbclient -L sambaserver -U user1 Enter user1's password: Domain=[ORG1] OS=[Unix] Server=[Samba 3.5.6] Sharename Type Comment - --- mynewshare Disk My test share IPC$ IPC IPC Service (Samba 3.5.6) Domain=[ORG1] OS=[Unix] Server=[Samba 3.5.6] Server Comment ---- SAMBASERVER samba 3.5.6 WorkgroupMaster - --- ORG1 On the server: id user1 is running ok. getent passwd, getent group is running ok. wbinfo -u, wbinfo -g, wbinfo -a user1%passwd is running ok. 2) If I the passwd for user1 is wrong: On the client: myuser@mycomputer:~$ smbclient -L sambaserver -U user1 Enter user1's password: session setup failed: NT code 0x1c010002 On the server: id user1 is running ok. getent passwd, getent group is running ok. wbinfo -u, wbinfo -g is running ok. wbinfo -a user1%passwd: plaintext password authentication failed Could not authenticate user user1%user with plaintext password challenge/response password authentication failed error code was NT code 0x1c010002 (0x1c010002) error messsage was: NT code 0x1c010002 Could not authenticate user user1 with challenge/response 3) If the passwd for user1 is right but next the previous failure: On the client: myuser@mycomputer:~$ smbclient -L sambaserver -U user1 Enter user1's password: session setup failed: NT code 0x1c010002 On the server: id user1 not found user but yes other users from de domain. getent passwd(even user1), getent group is running ok. wbinfo -u, wbinfo -g is running ok. wbinfo -a user1%passwd: plaintext password authentication failed Could not authenticate user user1%user with plaintext password challenge/response password authentication failed error code was NT code 0x1c010002 (0x1c010002) error messsage was: NT code 0x1c010002 Could not authenticate user user1 with challenge/response 4) Commands for going to the first point: rm /var/cache/samba/*tdb /etc/init.d/samba restart /etc/init.d/winbind restart I have to add that the same test in a Debian Lenny server with the same configuration and samba version 3.2.5-4lenny15 is working fine. If user/passwd is right, I can login. If not give the message dsession setup failed: NT_STATUS_LOGON_FAILURE as normal. ** I have found a bug in samba that it looks like to be the same problem = https://bugzilla.samba.org/show_bug.cgi?id=7888 and have patches for different samba versions. Regards smb.conf Description: Binary data
Bug#646994: please provide /etc/modules.d
On Dec 16, Daniel Baumann daniel.baum...@progress-technologies.net wrote: it would be nice to know if you're in favour of adding modules.d support or not; and if you'd like to have a patch for it or not. I still have not made up my mind, the examples you described are not very relevant since they require a run time decision. A good argument against implementing this is that with time the number of modules which should be loaded unconditionally at boot time but cannot be autoloaded should get smaller and smaller. -- ciao, Marco signature.asc Description: Digital signature
Bug#652341: bugz: broken package after rebuild
Source: bugz
Version: 0.9.3-1
I rebuilt bugz in a minimal chroot. The resulting package didn't contain
any Python modules:
$ dpkg -c bugz_0.9.3-1_all.deb | grep -vE '/etc/|/share/(doc|man)/'
drwxr-xr-x root/root 0 2011-12-16 02:23 ./
drwxr-xr-x root/root 0 2011-12-16 02:23 ./usr/
drwxr-xr-x root/root 0 2011-12-16 02:23 ./usr/share/
drwxr-xr-x root/root 0 2011-12-16 02:23 ./usr/bin/
-rwxr-xr-x root/root 13518 2011-07-11 04:12 ./usr/bin/bugz
Interesting parts of the build log:
| debian/rules build
| dh build
|dh_testdir
|dh_auto_configure
|dh_auto_build
| Can't exec pyversions: No such file or directory at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 120.
| Use of uninitialized value $python_default in substitution (s///) at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 121.
| Use of uninitialized value $python_default in substitution (s///) at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 122.
|dh_auto_test
| fakeroot debian/rules binary
| dh binary
|dh_testroot
|dh_prep
|dh_installdirs
|dh_auto_install
| Can't exec pyversions: No such file or directory at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 120.
| Use of uninitialized value $python_default in substitution (s///) at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 121.
| Use of uninitialized value $python_default in substitution (s///) at
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 122.
[...]
|dh_gencontrol
| dpkg-gencontrol: warning: Depends field of package bugz: unknown substitution
variable ${python:Depends}
| dpkg-gencontrol: warning: package bugz: unknown substitution variable
${python:Versions}
--
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#650321: Setting severity to grave
severity 650321 grave thanks Quite some people asked me what is about ddate in Debian, so I guess it's not only essential for me. I set the bug hereby to grave, as it, quoting http://www.debian.org/Bugs/Developer#severities, | makes the package in question unusable or mostly so . There are discordians out there. Hail Eris, Sebastian signature.asc Description: Digital signature
Bug#651199: iwlwifi: Connection lost on WPA: Group rekeying
Hi, On Fri, Dec 16, 2011 at 03:17:30AM -0600, Jonathan Nieder wrote: There have been a few iwlwifi fixes upstream recently. Could you try[1] v3.2-rc5 or later? I did not test 3.2 yet but for people looking for a workaround until a fix is available, the following seems to work for me (found on openSUSE's bug report): $ echo options iwlagn swcrypto=1 /etc/modprobe.d/iwlagn Best, -- Gabriel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652342: puddletag: missing build-dep on python-support
Source: puddletag Version: 0.10.6.3-1 Severity: important This package uses dh_pysupport in debian/rules, but it doesn't build-depend on python-support. -- 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#645213: ITP: gtk3-engines-unico -- Unico Gtk+ 3 theme engine
No problem! :) Glad to have it done even before you asked! :) Enjoy, and Merry Christmas, Guido On Fri, Dec 16, 2011 at 5:40 AM, Yves-Alexis Perez cor...@debian.org wrote: On ven., 2011-12-16 at 06:17 +0100, Yves-Alexis Perez wrote: On ven., 2011-12-02 at 17:36 +0100, Karolina Kalic wrote: I'm sorry, I've just realized that I've missed to answer to this email. I've packaged the latest version, and I've uploaded it to mentors.debian.net. I'm waiting for my mentor (Guido Trotter) to answer me. He is probably busy at the moment, but he usually responds in a few days, so I don't expect any problems for this. Hey, the wait for unico is blocking #650709. Could we please move forward on this? Hum, sorry for that, I failed to notice the upload. Thanks! -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649018: bist: FTBFS when building with -Werror=format-security
Please update the patch to the version from message #10 which fixes the possible format string vulnerabilities instead of working around the gcc error. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652343: colorname: missing build-dep on python-support
Source: colorname Version: 0.4+dfsg.1-2 This package uses dh_pysupport in debian/rules, but it doesn't build-depend on python-support. -- 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#652344: skytools3-walmgr needs dependency on python-psycopg2
Package: skytools3-walmgr Version: 3.0~rc1-2 skytools3-walmgr needs a dependency on python-psycopg2. 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#486527: git-svn: use of uninitialised value in 'dcommit' operation
severity 486527 minor retitle 486527 SVN::Ra::new: colon instead of period in message for tunnel connection problems reassign 486527 libsvn1 1.6.17dfsg-3 quit Hi, Quentin Neill wrote: Setup an account on a remote system with /bin/false as a login shell: remote# useradd -s /bin/false blah remote# passwd blah ... Try something that tickles the SVN/Core.pm code from the local system: local# git svn init -Ttrunk svn+ssh://blah@remote/junk ... Thanks again for the reproduction recipe. With libsvn-perl 1.6.17dfsg-3: $ git svn init -Ttrunk svn+ssh://blah@localhost/junk blah@localhost's password: Network connection closed unexpectedly: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. at /usr/lib/git-core/git-svn line 2299 So the cause (svn_error_t with NULL message) is still present and still produces a weird symptom. This time the symptom is less severe than before: a goofy error message with colon promising explanation and no delivery. So the fix to bug#422699 indeed improved things. The svn_error_t comes from subversion/libsvn_ra_svn/marshal.c, in readbuf_input(): SVN_ERR(svn_ra_svn__stream_read(conn-stream, data, len)); if (*len == 0) return svn_error_create(SVN_ERR_RA_SVN_CONNECTION_CLOSED, NULL, NULL); This regression seems to have come about in r870846. I'm not familiar enough with libsvn to say if libsvn should be putting a message in the svn_error_t object or the bindings should use a period instead of a colon when the message is not present. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599646: dependencies on geoclue
Le Thu, 15 Dec 2011 14:35:27 -0500, Peter necedema...@gmail.com a écrit : Hi, Correct me if I'm wrong, but empathy seems to depend on geoclue? Also if you count the c wrapper, gedit, gimp, epiphany, etc., all depend on geoclue. I guess that's just a wrapper but, is there some way to remove it? Yes, empathy is depending on the geoclue (master) package. If you want to remove the geoclue support you need to recompile empathy without it. Cheers Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
On Fri, 2011-12-16 at 09:57 +0100, Julien Cristau wrote: Hi, On Thu, Dec 15, 2011 at 19:45:47 -0500, Adam C Powell IV wrote: Found the problem. PETSc built on November 16 with mpi-defaults 0.6 which depended on LAM on non-openmpi arches. Now mpi-defaults 1.0.1 released 12/4 depends on MPICH2, so we have a mix of architectures installed. And mpi-defaults just went into testing today... Crap! It may be that other PETSc dependencies need rebuilding too... and there are a lot of them! Let's see: suitesparse, spooles, hypre, scotch, blacs-mpi, scalapack, mumps, all have to be rebuilt with MPICH2! What was built when: * suitesparse: April 15 2010 * spooles: May 11 2010 * hypre: August 15 2010 * scotch: April 6 2011 * blacs-mpi: August 29 2011 * scalapack: September 18 2011 * mumps: March 31 2011 None was built recently, all need to be rebuilt. mpi-defaults should not be in testing until at least these are rebuilt, probably others. Note: HDF5 is not a problem for PETSc because PETSc only links to it on OpenMPI platforms. I forgot why that is, maybe it's worth a try building PETSc against HDF5-mpich2? Maybe later... Okay, cloning this bug to a bunch of packages, see above. I've been an uploader to all except blacs-mpi and scalapack, and many of them could use some maintenance, this is a good excuse to spend time on them. :-) If any of those can be fixed with a no-change rebuild on the buildds, rather than a source upload, let debian-release know, and we'll schedule them. Thanks Julien. I think blacs-mpi, scalapack and suitesparse make sense for no-change rebuilds. But I've been procrastinating maintenance on the rest (just took care of spooles last night, working on hypre now) so this will motivate me to finish up hypre, scotch and mumps -- I'll take care of those three. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#629243: Synaptics right button disabled
On Sat, Oct 22, 2011 at 05:59:54PM +0100, ael wrote: The Synaptics right button disabled is present almost every time I start X. The problem is not with X: gpm and mev also fail to detect the right button before X is started. Nor does it seem to be a kernel problem: using an older kernel before the problem occured does not fix things. I will investigate further when time allows: I suppose udev is the place to start... I would reassign this bug if I knew which package to target :-) ael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652345: scolasync: broken after rebuild
Source: scolasync Version: 2.2-2 Severity: serious I rebuilt scolasync in a minimal chroot. The resulting binary package didn't work at all: | $ scolasync | Traceback (most recent call last): | File /usr/bin/scolasync, line 3, in module | from scolasync import scolasync | ImportError: No module named scolasync -- 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#642709: ctsim: diff for NMU version 5.2.0-1.1
On Thu, 15 Dec 2011 22:02:16 -0700, Kevin Rosenberg wrote: I've prepared an NMU for ctsim (versioned as 5.2.0-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. I suspect I'll rework the patch a bit. Do you want me to cancel the NMU? Upstream needs to distribute config.guess and such. So, I think a more robust patch would be for the debian/rules to delete the upstream file and then copy the files from the autotools-dev build-time package to replace upstreams. Hm, that's what's happening, more or less: - dh_autotools-dev_updateconfig in the configure target backups the shipped config.* files and copies the one from autotools-dev before calling configure - dh_autotools-dev_restoreconfig in the clean target moves the backupped versions back if they exist. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key ID: 0x8649AA06 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Tanita Tikaram: World Outside Your Window signature.asc Description: Digital signature
Bug#584300:
tags 584300 - moreinfo + patch
thanks
2011/12/8 Mathieu Malaterre mathieu.malate...@gmail.com:
Denis,
Do you think you can update your patch for VTK 5.8.0 ?
Hello Mathieu,
Here it is. I checked that vtk builds fine, but did not try this time
to use the generated packages; it should work since I did test it last
time, but have no time just now to check.
Denis
commit e5dd0bdc11f7cbbea5f126b5c4c99745b8733078
Author: Denis Barbier bou...@gmail.com
Date: Fri Dec 16 12:44:10 2011 +0100
Remove information about wrapped languages from VTKConfig.cmake
The file /usr/lib/vtk-5.8/VTKConfig.cmake contains
configuration used when building package, in particular
information about wrapped languages are hardcoded.
For instance VTK_WRAP_PYTHON is always set to true
even if python-vtk is not installed.
This patch puts snippets about wrapped languages into
separate files, which are shipped by python-vtk, tcl-vtk
and libvtk-java.
diff --git a/VTKConfig-Java.cmake.in b/VTKConfig-Java.cmake.in
new file mode 100644
index 000..30f01b5
--- /dev/null
+++ b/VTKConfig-Java.cmake.in
@@ -0,0 +1,14 @@
+# The list of available languages.
+SET(VTK_LANGUAGES ${VTK_LANGUAGES} JAVA)
+
+SET(VTK_WRAP_JAVA 1)
+
+# The Java configuration.
+SET(VTK_JAVA_JAR @VTK_JAVA_JAR_CONFIG@)
+SET(VTK_PARSE_JAVA_EXE @VTK_PARSE_JAVA_EXE_CONFIG@)
+SET(VTK_WRAP_JAVA_EXE @VTK_WRAP_JAVA_EXE_CONFIG@)
+SET(VTK_JAVA_INCLUDE_DIR @JAVA_INCLUDE_PATH@;@JAVA_INCLUDE_PATH2@)
+SET(VTK_JAVA_AWT_LIBRARY @JAVA_AWT_LIBRARY@)
+SET(VTK_JVM_LIBRARY @JAVA_JVM_LIBRARY@)
+
+
diff --git a/VTKConfig-Python.cmake.in b/VTKConfig-Python.cmake.in
new file mode 100644
index 000..2b4e259
--- /dev/null
+++ b/VTKConfig-Python.cmake.in
@@ -0,0 +1,14 @@
+# The list of available languages.
+SET(VTK_LANGUAGES ${VTK_LANGUAGES} PYTHON)
+
+SET(VTK_WRAP_PYTHON 1)
+
+# The Python configuration.
+# If VTK_CONFIGURATION_TYPES is set (see below) then the VTK_PYTHONPATH_DIRS
+# will have subdirectories for each configuration type.
+SET(VTK_PYTHONPATH_DIRS @VTK_PYTHONPATH_DIRS_CONFIG@)
+SET(VTK_WRAP_PYTHON_EXE @VTK_WRAP_PYTHON_EXE_CONFIG@)
+SET(VTK_WRAP_PYTHON_INIT_EXE @VTK_WRAP_PYTHON_INIT_EXE_CONFIG@)
+SET(VTK_PYTHON_INCLUDE_DIR @PYTHON_INCLUDE_DIR@)
+SET(VTK_PYTHON_LIBRARY @PYTHON_LIBRARY@)
+
diff --git a/VTKConfig-Tcl.cmake.in b/VTKConfig-Tcl.cmake.in
new file mode 100644
index 000..fedf000
--- /dev/null
+++ b/VTKConfig-Tcl.cmake.in
@@ -0,0 +1,21 @@
+# The list of available languages.
+SET(VTK_LANGUAGES ${VTK_LANGUAGES} TCL)
+
+SET(VTK_WRAP_TCL 1)
+
+# The Tcl/Tk configuration.
+SET(VTK_TCL_TK_STATIC @VTK_TCL_TK_STATIC@)
+SET(VTK_TCL_TK_COPY_SUPPORT_LIBRARY @VTK_TCL_TK_COPY_SUPPORT_LIBRARY@)
+SET(VTK_TCL_SUPPORT_LIBRARY_PATH @VTK_TCL_SUPPORT_LIBRARY_PATH_CONFIG@)
+SET(VTK_TK_SUPPORT_LIBRARY_PATH @VTK_TK_SUPPORT_LIBRARY_PATH_CONFIG@)
+SET(VTK_TCL_TK_MACROS_MODULE @VTK_TCL_TK_MACROS_MODULE_CONFIG@)
+SET(VTK_TCL_HOME @VTK_TCL_HOME_CONFIG@)
+SET(VTK_WRAP_TCL_EXE @VTK_WRAP_TCL_EXE_CONFIG@)
+SET(VTK_WRAP_TCL_INIT_EXE @VTK_WRAP_TCL_INIT_EXE_CONFIG@)
+SET(VTK_TK_INTERNAL_DIR @VTK_TK_INTERNAL_DIR_CONFIG@)
+SET(VTK_TK_RESOURCES_DIR @VTK_TK_RESOURCES_DIR_CONFIG@)
+SET(VTK_TCL_INCLUDE_DIR @TCL_INCLUDE_PATH@)
+SET(VTK_TCL_LIBRARY @TCL_LIBRARY@)
+SET(VTK_TK_INCLUDE_DIR @TK_INCLUDE_PATH@)
+SET(VTK_TK_LIBRARY @TK_LIBRARY@)
+
diff --git a/VTKConfig.cmake.in b/VTKConfig.cmake.in
index 6aa6e77..ff52a5c 100644
--- a/VTKConfig.cmake.in
+++ b/VTKConfig.cmake.in
@@ -64,7 +64,7 @@ SET(VTK_CMAKE_EXTENSIONS_DIR @VTK_CMAKE_EXTENSIONS_DIR_CONFIG@)
SET(VTK_KITS @VTK_KITS@)
# The list of available languages.
-SET(VTK_LANGUAGES @VTK_LANGUAGES@)
+SET(VTK_LANGUAGES )
# VTK Configuration options.
SET(VTK_BUILD_SHARED_LIBS @BUILD_SHARED_LIBS@)
@@ -110,10 +110,16 @@ SET(VTK_USE_VIDEO_FOR_WINDOWS @VTK_USE_VIDEO_FOR_WINDOWS@)
SET(VTK_USE_VIEWS @VTK_USE_VIEWS@)
SET(VTK_USE_VOLUMEPRO_1000 @VTK_USE_VOLUMEPRO_1000@)
SET(VTK_USE_X @VTK_USE_X@)
-SET(VTK_WRAP_JAVA @VTK_WRAP_JAVA@)
-SET(VTK_WRAP_PYTHON @VTK_WRAP_PYTHON@)
-SET(VTK_WRAP_TCL @VTK_WRAP_TCL@)
-SET(VTK_WRAP_PYTHON_SIP @VTK_WRAP_PYTHON_SIP@)
+
+SET(VTK_WRAP_JAVA 0)
+SET(VTK_WRAP_PYTHON 0)
+SET(VTK_WRAP_TCL 0)
+SET(VTK_WRAP_PYTHON_SIP 0)
+
+INCLUDE(${VTK_DIR}/VTKConfig-Java.cmake OPTIONAL)
+INCLUDE(${VTK_DIR}/VTKConfig-Python.cmake OPTIONAL)
+INCLUDE(${VTK_DIR}/VTKConfig-Tcl.cmake OPTIONAL)
+# Python_sip is not provided by Debian packages
# The Hybrid and VolumeRendering kits are now switched with Rendering.
SET(VTK_USE_HYBRID @VTK_USE_RENDERING@)
@@ -133,44 +139,11 @@ SET(VTK_MPI_SERVER_PREFLAGS @VTK_MPI_SERVER_PREFLAGS_CONFIG@)
SET(VTK_MPI_INCLUDE_DIR @MPI_INCLUDE_PATH@)
SET(VTK_MPI_LIBRARIES @MPI_LIBRARY@;@MPI_EXTRA_LIBRARY@)
-# The Tcl/Tk configuration.
-SET(VTK_TCL_TK_STATIC @VTK_TCL_TK_STATIC@)
-SET(VTK_TCL_TK_COPY_SUPPORT_LIBRARY @VTK_TCL_TK_COPY_SUPPORT_LIBRARY@)
-SET(VTK_TCL_SUPPORT_LIBRARY_PATH @VTK_TCL_SUPPORT_LIBRARY_PATH_CONFIG@)
-SET(VTK_TK_SUPPORT_LIBRARY_PATH
Bug#651999: /usr/bin/pbuilder-dist: man 1 pbuilder-dist refers to non existant packages
tag 651999 pending thanks Hi Karl (2011.12.14_01:52:16_+0200) qemu-static and binfmt-misc don't appear as packages or commands on squeeze, and I can't find references to them on other releases either. Right, that should have been qemu-user-static and binfmt_misc (the kernel module). Fixed in r1259. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631816: libqwt-dev: apt reinstalls the package
#clone 631816 -1 #reassign -1 libqwt-dev 6.0.0-1 ## policy §7.1 Syntax of relationship fields #severity -1 important severity 633943 important found 633943 qwt/6.0.0-1 #merge -1 633943 quit David Kalnischkies wrote: APT detects installed vs. the online version as different versions because of different dependencies. If we have a close look, we can see that: Online is: Replaces: libqwt5-qt4-dev ( 6.0.0-) After installation we have in dpkg/status: Replaces: libqwt5-qt4-dev ( 6.0.0) From policy §7.1: parentheses should contain a relation from the list below followed by a version number, in the format described in Version, Section 5.6.12. 6.0.0- is not a valid version number. I'm not sure what dpkg and apt should do here, though. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On 12/16/2011 04:46 AM, Josh Triplett wrote: In all of the recent discussions about separate /usr partitions, most people seem to acknowledge them as unusual, special-purpose configurations, even those who use them. I do *not* agree that there's such a consensus. On 12/16/2011 04:46 AM, Josh Triplett wrote: Meanwhile, we don't want to steer any new users towards a setup with a pile of different partitions, which makes their system more complex with more potential failure modes. I hope that we are still the universal operating system, and that we don't want to force anyone to do anything. If I want to use many partitions, this is *my* call, and not everyone's business. Please don't try to force your view on partitioning to anyone. In the most recent thread, I noticed that someone mentioned they primarily chose a setup with a separate /usr partition because the installer offered such a setup as one of the standard guided partitioning options. Please consider removing the option in the guided partitioner for separate /usr, /var, and /tmp partitions; that would leave only the All files in one partition and Separate /home partition setups, both of which potentially make sense for users of the guided partitioner. Please don't remove the above option, I like it, and I don't see why it needs to be removed just because you Josh (and maybe others) don't like/use it. You feel like a separate partition for /home is useful. Good for you, and your desktop. But when it comes to servers, the /home separate partition is useless, and having a separate /var makes things faster. Also, having a separate /tmp avoids that the rootfs gets full, and I consider it quite important especially on servers. I would recommend using it for absolutely *every* setup (desktop or servers) as a security measure, especially considering any application can fill up the temp space. Anyone desiring a setup with more separate partitions should have no trouble using the manual partitioner to create whatever custom configuration they desire. And we have even less trouble using the automated option, also it's a way faster than doing it manually. Please don't remove it. Again, the way *I* and *others* use my/their computers is their choice. Please do not remove this choice from me/them. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652000: /usr/bin/pbuilder-dist: pbuilder-dist ignores environment and has no way to set a custom pbuilderrc
Hi Karl (2011.12.14_01:57:05_+0200) Because pbuilder-dist is available in squeeze, but qemu-debootstrap isn't, I've downloaded the script from bug 572952 and I'm trying to use it with pbuilder-dist. Unfortunately, despite saying install or change DEBOOTSTRAP option it seems to ignore the environment and the users .pbuilderrc. Could this be changed please? It makes it excessively hard to use the thing, to the extent that you need to be able to edit roots pbuilderrc. pbuilder-dist is passing --debootstrap qemu-debootstrap to pbuilder. That overrides anything in pbuilderrc. Can you not put it somewhere on your PATH? SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650321: util-linux: ddate missing from util-linux 2.20.1
+1 I don't want to build my own new util-linux package every time its being upgraded. Sounds too much like gentoo, to me. Please enable ddate again. It doesn't harm anyone, and some people really rely on it (ddate is NOT a joke program). E.g. some of my login scripts use it to warn me about hollidays; Right now these scripts won't work with the original debian package and i don't know when to party etc unless i repackage my own util-linux. Not even mentioning the _ugly_ error message i have to endure after each and every login. There are Discordians even in here. Hail Eris, riot -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651529: rsyslog: FTBFS on hurd-i386
On Fri, 2011-12-16 at 12:18 +0100, Rainer Gerhards wrote: While that could be the easy way out, it would definitely be wrong. Such limits can be OS or filesystem specific, if at all. They do not even represent reality on GNU/Linux! Try this: I try to stay out of these politics, but I found it beneficial to remove the dependency on MAX_PATH. It actually solved two error conditions that otherwise could occur (not sure if the dlopen call will fail in these cases, though). At least the code got smaller. I have enhanced v5-devel, patch is available here: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=01c7c9ffc6771f73df9ee0bc 18e30534d6c6974c I would appreciate if you could have a look at it; the pointer arithmetic is obviously easy to get wrong. Good that you took the time to change the code, I'm currently working on completing the dynamic allocation solution. I'll take a look at your changes, thank you. If Guillem is happy with your changes, let's settle with your solution. I have some more issues now when the package is building on GNU/Hurd, one is the configuration file. Is it OK to submit another bug report to the Debian bug data base? Or do you want me to contact the development list (if it exists) or you directly? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497469: git-gui: child window looks like part of parent
clone 497469 -1 retitle 497469 git-gui: the UTF-8 characters are shown as garbage submitter -1 jida...@jidanni.org retitle -1 git-gui: preferences window looks like part of parent quit Hi, 積丹尼 wrote: $ git gui blame some_file Click edit-options. The options window then appears directly on top of the file viewer window. It is shifted vertically, but not horizontally. It needs to be shifted horizontally too. Or else the user will just click edit-options again, getting into deep trouble. Could you explain further? I tried following your recipe, and I didn't find myself tempted to click Edit → Options again. For comparison, the preferences dialog for gitk seems to always appear in the top-left corner of the monitor. Which is not to say that the current positioning seems particularly sane. The code does wm geometry $w +[winfo rootx .]+[winfo rooty .] which based on tcl documentation should put the top-left edge of the window at an (x, y) position on the _screen_ (whatever that means) equal to the (x, y) position of the upper-left corner of the current window in the _root window of the screen_ (again, whatever that means). In practice, that seems to put it at the left edge of my monitor, right below the menu bar when my git-gui window is on the left side of the screen, and in the dead center of the screen when my git-gui window is on the right. Don't ask me way. I guess a link to some relevant UI guidelines document might help decide what the right thing to do is, or if this is just UI design 101, let me know and I'll pass it upstream (that's to Pat Thoyts). Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651529: rsyslog: FTBFS on hurd-i386
Good that you took the time to change the code, I'm currently working on completing the dynamic allocation solution. It's important to note that I used the chance to refactor the code a bit, so the logic is slightly different. When you read the code, note that I use a stack-based fixed size buffer as long as it is sufficient and go to dyn alloced memory only if necessary. I guess dyn alloc will never happen in practice (but I tested under valgrind control and it looks rather well). I'll take a look at your changes, thank you. If Guillem is happy with your changes, let's settle with your solution. I have some more issues now when the package is building on GNU/Hurd, one is the configuration file. Is it OK to submit another bug report to the Debian bug data base? Or do you want me to contact the development list (if it exists) or you directly? We have a bugzilla at http://bugzilla.adiscon.com and the mailing list is at http://lists.adiscon.net/mailman/listinfo/rsyslog Which way you use doesn't really matter to me, I am fine with either way. Just note that anything that is related to the packaging is not touched by me. I follow the debian bug tracker and try to pull out things that I can address. Michael does a great job to remind me if I overlook things (what happens...). Just be warned that I will soon leave for xmas vacation and I have a big bunch of things in front of me, so I will probably not be able to change anything before I leave. Rainer
Bug#641249: [Pkg-scala-maint] Bug#641249: Can't we just change it with the next upload?
On 12/15/2011 02:39 PM, Thomas Koch wrote: Hi, I need to parse the upstream version (2.9.1, not 2.9.1.final as in the manifest) to install the maven artefacts. I want to do it with UPSTREAM_VERSION=$(shell dpkg-parsechangelog | sed -rne 's,^Version: ([^-+]+).*,\1,p') Ok, I fixed this one using another method: I've used build.number shipped by upstream to get the correct version number, without much hacking. Then, I've used sed to put a correct verison number if pom files. All is pushed to the git repo. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556610: Please do incremental checks every night instead of a full monthly one
Attached slightly fixed version of the above patch: sync_min must be a multiple of chunk_size. checkarray.patch Description: Binary data
Bug#652347: common-lisp-controller: [INTL:nl] Dutch translation of debconf templates
Package: common-lisp-controller Severity: wishlist Tags: patch l10n Hello, Attached is the updated Dutch translation of the common-lisp-controller debconf templates. Please include it in your next upload. Regards, -- Jeroen Schot # Dutch translation of common-lisp-controller debconf templates. # Copyright (C) 2004-2011 THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the common-lisp-controller package. # Luk Claes luk.cl...@ugent.be, 2004-2008. # Jeroen Schot sc...@a-eskwadraat.nl, 2011. # msgid msgstr Project-Id-Version: common-lisp-controller 7.8\n Report-Msgid-Bugs-To: common-lisp-control...@packages.debian.org\n POT-Creation-Date: 2010-01-30 22:00+0100\n PO-Revision-Date: 2011-12-16 14:33+0100\n Last-Translator: Jeroen Schot sc...@a-eskwadraat.nl\n Language-Team: Debian l10n Dutch debian-l10n-du...@lists.debian.org\n Language: nl\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #. Type: string #. Default #. Default site name #: ../templates:2001 msgid Unknown msgstr Onbekend #. Type: string #. Description #: ../templates:2002 msgid Short Common Lisp site name: msgstr Korte Common Lisp-sitenaam: #. Type: string #. Description #: ../templates:2002 msgid You can configure what the Common Lisp implementations are going to use as 'short site name'. msgstr U kunt configureren wat de Common Lisp-implementaties gaan gebruiken als 'short site name'. #. Type: string #. Description #. Type: string #. Description #: ../templates:2002 ../templates:3002 msgid This is mostly unused except in some error reporting tools. msgstr Dit wordt meestal niet gebruikt, behalve in enkele foutrapporteringshulpmiddelen. #. Type: string #. Default #. Default long site name, just something longer than the default site name #: ../templates:3001 msgid Site name not initialized msgstr Sitenaam niet geïnitialiseerd #. Type: string #. Description #: ../templates:3002 msgid Long Common Lisp site name: msgstr Lange Common Lisp-sitenaam: #. Type: string #. Description #: ../templates:3002 msgid You can configure what the Common Lisp implementations are going to use as 'long site name'. msgstr U kunt configureren wat de Common Lisp-implementaties gaan gebruiken als 'long site name'.
Bug#607494: ftpcopy: ftpls cross-site scripting when generating HTML listing
On Tue, Dec 13, 2011 at 06:01:52PM +0100, Moritz Muehlenhoff wrote: On Sun, Dec 19, 2010 at 03:10:46AM +0100, non customers wrote: Subject: ftpcopy: ftpls cross-site scripting when generating HTML listing Package: ftpcopy Version: 0.6.7-2 Severity: important Tags: security The ftpls command has a cross-site scripting (XSS) security bug when generating HTML listings: Gerrit, what's the status? This bug hasn't seen any action since a year. Hi Moritz, I completely forgot this report, sorry. I'll try to take a look within the next days, due to christmas maybe next weeks. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616290: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]
On Thu, 2011-12-15 at 14:15 +, Ian Jackson wrote: Svante Signell writes ([Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]): Dear Debian/Hurd, GNU/Hurd and Debian-devel people. This arrived today. Any ideas on how to proceed? Is it possible to create a Hurd-specific fork of the latest ISC-DHCP release? DHCP is an essential package in the Debian Installer. I went and read the Debian bug report. The difficulty seems to be with the patch fix_ftbfs4hurd.dpatch. I have to say that on reading that patch I understood upstream's reluctance. I don't think it looks to me like a correct and appropriate fix for build portability problems. There are two things involved in that patch, the PATH_MAX issues in dh_client.c and dhcpd.c, and the changes to lpf.c. In my first version, I did split the relevant lpf.c parts into a Hurd-specific one called lpf_get_hw_addr.c. Later Samuel Thibault changed that into lpf.c directly, by defining a new macro USE_LPF_HWADDR, and use that. In case having a Hurd-specific part of lpf.c is more easily accepted by upstream, we can make these changes to the current patch. Unfortunately the upstream bug tracker is secret so we can't see any discussion there, but the initial message sent to dhcp-bugs@isc doesn't seem really to explain the thinking behind the patch. That message was sent by the DM, and did not contain much more information than the Debian bug report itself (and the patch). Where can I find the detailed explanation of why this patch is required and how it works to fix the problems ? At the moment I can't even seem to find an error message from an FTBFS log. More information can be found at the debian-hurd and bug-hurd ML archives: http://lists.gnu.org/archive/html/bug-hurd/2011-02/threads.html http://lists.gnu.org/archive/html/bug-hurd/2011-03/threads.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652000: Acknowledgement (/usr/bin/pbuilder-dist: pbuilder-dist ignores environment and has no way to set a custom pbuilderrc)
Hi Karl (2011.12.14_02:14:53_+0200) PATH=$PATH:/script/location/ in roots .pbuilderrc: PASS Hard coding the path in a copy of the script: PASS So it seems it might actually be a path issue, not a DEBOOTSTRAP one. Not sure if the script should be changed to match the man page, or the man page to match the script. Which manpage are we talking about? Having to set up *anything* in root's .pbuilderrc is a bad sign. It should be using your .pbuilderrc. This is why pbuilder-dist now refuses to be run under sudo, and calls sudo itself. A bit of an ugly hack, but not too much one can do about it... SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652348: ocaml: module Graphics: broken [sound] function
Package: ocaml Version: 3.12.1-2 Severity: normal Trying to use Graphics.sound (eg. [let fail = Graphics.sound;;]) triggers the following error: Error: The external function `caml_gr_sound' is not available -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ocaml depends on: ii libx11-dev2:1.3.3-4 X11 client-side library (developme ii ocaml-base [ocaml-base-3.12.1 3.12.1-2 Runtime system for OCaml bytecode ii ocaml-nox [ocaml-nox-3.12.1] 3.12.1-2 ML implementation with a class-bas ocaml recommends no packages. Versions of packages ocaml suggests: pn tcl8.5-devnone (no description available) pn tk8.5-dev none (no description available) -- 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#603129: git-email: git-send-email why bother prompting on Cc adds? (need edit option)
retitle 603129 git send-email: please allow editing cc list at send? [yn] time severity 603129 wishlist tags 603129 + upstream quit Hi David, David Fries wrote: From: David Fries da...@fries.net To: g...@vger.kernel.org Cc: David Fries da...@fries.net, David Fries da...@fries.net ... The Cc list above has been expanded by additional addresses found in the patch commit message. By default send-email prompts before sending whenever this occurs. This behavior is controlled by the sendemail.confirm configuration setting. ... Send this email? ([y]es|[n]o|[q]uit|[a]ll): It's nice that it stops to let me know that it added to the Cc list, but it would be better if it would also let me do something about it. Makes sense. Please make it so, and let me know if you have questions. (If you don't have time, that's fine, and it will probably get done anyway, though not as quickly.) Thanks and sorry for a slow response, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652349: dnprogs: [INTL:nl] Dutch translation of debconf templates
Package: dnprogs Severity: wishlist Tags: patch l10n Hello, Attached is the updated Dutch translation of the dnprogs debconf templates. Please include it in your next upload. Regards, -- Jeroen Schot # Dutch translation of dnprogs debconf templates. # Copyright (C) 2006-2011 THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the dnprogs package. # Vincent Zweije zwe...@xs4all.nl, 2006. # Jeroen Schot sc...@a-eskwadraat.nl, 2011. # msgid msgstr Project-Id-Version: dnprogs 2.57\n Report-Msgid-Bugs-To: chris...@debian.org\n POT-Creation-Date: 2011-01-18 15:38+0100\n PO-Revision-Date: 2011-12-16 14:53+0100\n Last-Translator: Jeroen Schot sc...@a-eskwadraat.nl\n Language-Team: Debian l10n Dutch debian-l10n-du...@lists.debian.org\n Language: nl\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #. Type: string #. Description #: ../dnet-common.templates:1001 msgid DECnet node name: msgstr DECnet-knoopnaam: #. Type: string #. Description #: ../dnet-common.templates:1001 msgid All nodes on a DECnet network have a node name. This is similar to the IP hostname but can only be a maximum of 6 characters long. It is common that the DECnet name is the same as the IP name (if your machine has one). If you do not know the answer to this question please contact your system administrator. msgstr Alle knopen op een DECnet-netwerk hebben een knoopnaam. Dit is vergelijkbaar met de IP-computernaam, maar ze mag slechts 6 karakters lang zijn. Het is gebruikelijk dat de DECnet-naam dezelfde is als de IP-naam (als uw machine er één heeft). Als u het antwoord op deze vraag niet weet, contacteer dan uw systeembeheerder. #. Type: string #. Description #: ../dnet-common.templates:2001 msgid DECnet node address: msgstr DECnet-knoopadres: #. Type: string #. Description #: ../dnet-common.templates:2001 msgid All nodes on a DECnet network have a node address. This is two numbers separated with a period (e.g. 3.45) where the first number denotes the area and the second is the node within that area. msgstr Alle knopen op een DECnet-netwerk hebben een knoopadres. Dit bestaat uit twee getallen, gescheiden door een punt (b.v. 3.45) waarbij het eerste getal het gebied aangeeft en het tweede de knoop in dat gebied. #. Type: string #. Description #: ../dnet-common.templates:2001 msgid Do not make up a number here. If you do not know your DECnet node address then ask your system administrator. msgstr Verzin niet zomaar een adres. Als u uw DECnet-knoopadres niet weet, vraag het dan aan uw systeembeheerder. #. Type: note #. Description #: ../dnet-common.templates:3001 msgid DECnet startup changes your ethernet hardware address msgstr Het opstarten van DECnet wijzigt uw ethernet-hardwareadres #. Type: note #. Description #: ../dnet-common.templates:3001 msgid The \setether\ program in this package will change the hardware (MAC) address of all ethernet cards in your system (by default) to match the DECnet node address. This is essential for the operation of DECnet and so is not optional. However, if you have more than one ethernet card you may want to edit /etc/default/decnet to alter the list of cards whose hardware addresses are changed. msgstr Het \setether\-programma in dit pakket zal het hardware- (MAC-) adres van al uw ethernetkaarten in uw systeem (standaard) laten overeenkomen met het DECnet-knoopadres. Dit is essentieel voor de werking van DECnet en is dus niet optioneel. Toch kunt u in /etc/default/decnet de lijst van kaarten wiens hardwareadres moet veranderd worden, wijzigen als u meer dan één ethernetkaart heeft. #. Type: note #. Description #: ../dnet-common.templates:3001 msgid Be aware that any other machines that have your system's MAC address in their ARP cache may no longer be able to communicate with you via IP protocols until this cache has timed out or been flushed. msgstr Merk op dat andere machines die het MAC-adres van uw systeem in hun ARP- cache hebben, misschien niet langer met u kunnen communiceren via IP- protocols totdat de cache is verlopen of is gewist. #. Type: note #. Description #: ../dnet-common.templates:3001 msgid The MAC address cannot be changed on-the-fly so you will need to reboot your machine before DECnet can function. msgstr Het MAC-adres kan niet \on-the-fly\ gewijzigd worden, dus u zal uw machine moeten herstarten opdat DECnet zou kunnen functioneren. #. Type: note #. Description #: ../dnet-common.templates:3001 msgid You should also edit /etc/decnet.conf to add the names and addresses of DECnet nodes you want to communicate with. msgstr U dient tevens de namen en adressen van de DECnet knopen waarmee u wilt communiceren aan /etc/decnet.conf toe te voegen. #. Type: select #. Description #: ../dnet-common.templates:4001 msgid Configure DECnet now: msgstr DECnet nu configureren: #. Type: select #. Description #: ../dnet-common.templates:4001 msgid You can configure
Bug#629820: broken package gitweb Version: 1:1.7.5.3-1
unmerge 629820 retitle 629820 gitweb: please support FCGI mode out of the box (add gitweb.fcgi wrapper) severity 629820 wishlist tags 629820 + upstream quit Denis Linvinus wrote: Perhaps it would be better to change the package name, for example Package: git-webconfig Replaces: gitweb ( 1:1.7.2.5-1) Breaks: gitweb ( 1:1.7.2.5-1) If we are to do something that disruptive, I think I would like to see gitweb folded into the main git package, and the decision about whether to use it in apache.conf to be a debconf question (defaulting to true in the usual more usable by default vein). But I am not sure the current webapps policy provides an easy way to do that. Also it would be nice, if package will contain simple FCGI startup script, #!/bin/sh export FCGI_SOCKET_PATH=127.0.0.1:9002 /usr/share/gitweb/gitweb.cgi --fastcgi script was found there http://sixohthree.com/1402/running-gitweb-in-fastcgi-mode Hm, this does sound interesting. I'm stealing the bug to just track that. :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625221: Gwibber still can't send messages
On Sat, Oct 08, 2011 at 09:20:58PM -0400, Benj. Mako Hill wrote: Thanks for maintaining Gwibber! This bug means that users of gwibber cannot send messages if they are using Network Manager. This affects users of unstable and testing now. There has been a patch for this bug since June (thanks Emilio!) and I've just tested it on my system against the version of Gwibber in Debian testing/sid. The patch applies cleanly and results in a fully functioning Gwibber. If this difficult, I'm happy to do an NMU to fix this bug. It seems that the package is on a good way for orphaning (see #573822). So, from a user point of view, I think a NMU would be much welcome, yes. Thanks in advance. Best regards, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), 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#651529: rsyslog: FTBFS on hurd-i386
On Fri, 2011-12-16 at 14:32 +0100, Rainer Gerhards wrote: Good that you took the time to change the code, I'm currently working on completing the dynamic allocation solution. It's important to note that I used the chance to refactor the code a bit, so the logic is slightly different. When you read the code, note that I use a stack-based fixed size buffer as long as it is sufficient and go to dyn alloced memory only if necessary. I guess dyn alloc will never happen in practice (but I tested under valgrind control and it looks rather well). OK! We have a bugzilla at http://bugzilla.adiscon.com and the mailing list is at http://lists.adiscon.net/mailman/listinfo/rsyslog Which way you use doesn't really matter to me, I am fine with either way. Just note that anything that is related to the packaging is not touched by me. I follow the debian bug tracker and try to pull out things that I can address. Michael does a great job to remind me if I overlook things (what happens...). Of course, I know packaging issues are not touched by upstream, so the configuration/startup scripts are Debian specific, right? Then, I'll file a Debian bug for /etc/init.d/rsyslog. Another issue is about writing a Hurd-specific plugin file: plugins/imklog/gnu.c. However, this is not an urgent matter so it can wait until later. Thanks! Just be warned that I will soon leave for xmas vacation and I have a big bunch of things in front of me, so I will probably not be able to change anything before I leave. I wish you a Merry Christmas then :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616290: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]
Svante Signell writes (Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]): On Thu, 2011-12-15 at 14:15 +, Ian Jackson wrote: Where can I find the detailed explanation of why this patch is required and how it works to fix the problems ? At the moment I can't even seem to find an error message from an FTBFS log. This was really my key question. Any submission of a patch allegedly fixing a bug (by which I mean to include a portability problem), to any project, should include a clear description, in detail, of what the bug is thought to be and how the patch solves it. More information can be found at the debian-hurd and bug-hurd ML archives: http://lists.gnu.org/archive/html/bug-hurd/2011-02/threads.html http://lists.gnu.org/archive/html/bug-hurd/2011-03/threads.html A reference to a mailing list thread may helpful as background reading, but I'm afraid it does not meet the standard I would expect for a patch submission. I'm afraid you need to go back and revise your submissions to isc-dhcp upstream. You need to: * Identify what the separate problems are * For each individual problem: - Research applicable best practices and standards - Decide accordingly whether the fault lies with isc-dhcp or hurd - Decide how to fix the problem - Create and test a separate patch, either against isc-dhcpd or hurd or perhaps both - Write a clear and detailed explanation; this explanation should cover all of the matters I've just mentioned. So far our (Debian's) communications with dhcpd upstream on this topic seem to be lacking in this area. If you like I would be happy to review your next submissiosn to upstream, before you send them. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649712: wordnet: diff for NMU version 1:3.0-26.1
* Andreas Tille ti...@debian.org, 2011-12-15, 11:35: thanks for the NMU and sorry for not caring for this issue earlier. Would you mind commiting your changes to Debian Science SVN which is writable for all DDs? Sure, I'll do it later today. -- 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#635930: ITP: octopussy -- log analyzer, alerter reporter
Hi, what is the state of this bug, do you need any help? Regards, Daniel -- 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#648954: [patch] doc-base Conflicts are insufficient
On Fri, Dec 16, 2011 at 12:35:49PM +0100, Martin Pitt wrote: we still got quite a lot of upgrade failures with -6 (https://launchpad.net/bugs/902553). -6 adds a Conflicts: doc-base ( 0.10.3) to perl-base. This correctly prevents unpacking of perl-base 5.14 and breaking the doc-base trigger. However, in above LP bug we see Processing triggers for doc-base ... /usr/bin/perl: symbol lookup error: /usr/lib/perl5/auto/UUID/UUID.so: undefined symbol: Perl_xs_apiversion_bootcheck dpkg: error processing doc-base (--unpack): subprocess installed post-installation script returned error exit status 127 At this point neither doc-base nor perl-base was unpacked (which is what -5 and -6 fixed). Full logs are in the LP bug and its duplicates, but above is the gist of it. debian/control: Add doc-base conflict also to perl, perl-modules, and libperl5.14. I don't think that guarantees a fix? The above error happens when libuuid-perl is upgraded before perl-base and doc-base. The perl and perl-modules packages don't necessarily come into it at all. This can be reproduced in a minimal squeeze chroot with just apt-get install doc-base libyaml-tiny-perl dpkg -i doc-base_0.10.2_all.deb # from snapshot.debian.org or Ubuntu Oneiric dpkg --unpack libuuid-perl_0.02-4+b2_amd64.deb # the 5.14 build from wheezy/sid dpkg --unpack recode-doc_3.6-17_all.deb # or anything with data in /usr/share/doc-base No conflicts in perl-modules and perl can definitely prevent that, althought it's possible that they would make higher level package managers pick the right upgrade order as a side effect. As a matter of fact, unpacking the 5.14 versions of perl and perl-modules alone doesn't break the trigger because the incompatible binary Perl modules are in a versioned path (/usr/lib/perl/5.1*). It therefore seems to me that this should to be fixed in libuuid-perl rather than in perl. Fortunately it looks like that's the only XS module affected: tracing an 'install-docs --install-all' run shows it only uses Locale::Gettext and UUID from /usr/lib/perl5, and liblocale-gettext-perl already Pre-Depends: perl-base (= 5.14.2-3) so it can't be upgraded before perl-base. BTW, I don't think this qualifies as release critical for Debian, as the problematic trigger was only introduced in doc-base 0.10.0, and squeeze has 0.9.5. I'm not sure if the right change for libuuid-perl is a conflict or a pre-dependency, and I'm not quite sure it even needs to go in Debian (as opposed to being a Ubuntu specific fix.) Will need to think about that a bit. Cc'ing the libuuid-perl maintainers. If others agree with the above analysis, this should probably be cloned there and the original perl bug should be closed again. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649712: NMU is faulty
* Martin Eberhard Schauer martin.e.scha...@gmx.de, 2011-12-15, 23:04: I'm afraid that the NMU does not do the right thing. The bug report stated Please replace the Build-Depends on gs-common to a Build-Depends on ghostscript. The NMU drops the build dependency. Yes, and I explained in the changelog why dropping the dependency is the right thing to do. This package hasn't been using ghostscript since 2007. -- 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#652351: quota: [INTL:nl] Dutch translation of debconf templates
Package: quota Severity: wishlist Tags: patch l10n Hello, Attached is the updated Dutch translation of the quota debconf templates. Please include it in your next upload. Regards, -- Jeroen Schot # Dutch translation of quota debconf templates. # Copyright (C) 2004-2011 THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the quota package. # Bart Cornelis cob...@linux.be, 2004. # Jeroen Schot sc...@a-eskwadraat.nl, 2011. # msgid msgstr Project-Id-Version: quota 4.00-1\n Report-Msgid-Bugs-To: qu...@packages.debian.org\n POT-Creation-Date: 2008-06-27 12:24+0200\n PO-Revision-Date: 2011-12-16 15:36+0100\n Last-Translator: Jeroen Schot sc...@a-eskwadraat.nl\n Language-Team: Debian l10n Dutch debian-l10n-du...@lists.debian.org\n Language: nl\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n # Type: boolean # Description #. Type: boolean #. Description #: ../templates:1001 msgid Send daily reminders to users over quota? msgstr Verstuur dagelijks een herinnering aan gebruikers die over hun quota heen zijn? #. Type: boolean #. Description #: ../templates:1001 msgid Enable this option if you want the warnquota utility to be run daily to alert users when they are over quota. msgstr Activeer deze optie indien u elke dag alle gebruikers die over hun quota heen zijn een waarschuwing wilt sturen. #. Type: string #. Description #: ../templates:2001 msgid Phone support number of the admin: msgstr Telefoonnummer van de beheerder: # Type: string # Description #. Type: string #. Description #: ../templates:2001 msgid Enter the phone number a user can call if he needs assistance with his \over quota\ emails. You do not have to enter anything here if you specify a signature later. msgstr Voer het telefoonnummer in dat gebruikers kunnen bellen voor ondersteuning betreffende \quota overschreden\-e-mails. Als u zo meteen een ondertekening invoert hoeft u hier niets in te voeren. #. Type: string #. Description #: ../templates:3001 msgid Support email of the admin: msgstr E-mail van de beheerder: # Type: string # Description #. Type: string #. Description #: ../templates:3001 msgid Enter the email address a user can write to if he needs assistance with his \over quota\ emails. You do not have to enter anything here if you specify a signature later. msgstr Voer het e-mailadres in dat gebruikers kunnen aanschrijven wanneer ze hulp nodig hebben met \quota overschreden\-e-mails. Als u zo meteen een ondertekening invoert hoeft u hier niets in te voeren. #. Type: string #. Description #: ../templates:4001 msgid From header of warnquota emails: msgstr Afzender-veld voor quota-waarschuwings-e-mails: # Type: string # Description #. Type: string #. Description #: ../templates:4001 msgid The email address you specify here is used as the \From:\ field of any mail sent by the warnquota utility. msgstr Het e-mailadres dat u hier opgeeft wordt opgegeven als afzender in het \From:\-veld van alle verstuurde waarschuwings-e-mails. #. Type: string #. Description #: ../templates:5001 msgid Message of warnquota emails: msgstr Inhoud van quota-waarschuwings-e-mails: # Type: string # Description #. Type: string #. Description #: ../templates:5001 msgid The text you specify here is used as message in any mail sent by the warnquota utility. Use \|\ to specify a line break. Leave empty if you want the default message. msgstr De tekst die u hier opgeeft vormt de inhoud van verstuurde quota- waarschuwings-e-mails. Gebruik \|\ om een regeleinde aan te geven. Laat dit leeg indien u het standaard bericht wil gebruiken. #. Type: string #. Description #: ../templates:6001 msgid Signature of warnquota emails: msgstr Ondertekening van quota-waarschuwings-e-mails: # Type: string # Description #. Type: string #. Description #: ../templates:6001 msgid The text you specify here is used as signature in any mail sent by the warnquota utility. Use \|\ to specify a line break. Leave empty if you want the default signature. msgstr De tekst die u hier opgeeft wordt gebruikt als ondertekening van verstuurde quota-waarschuwings-e-mails. Gebruik \|\ om een regeleinde aan te geven. Laat dit leeg indien u het standaard bericht wil gebruiken. #. Type: note #. Description #: ../templates:7001 msgid rpc.rquota behaviour changed msgstr gedrag van rpc.rquota is veranderd # Type: note # Description #. Type: note #. Description #: ../templates:7001 msgid The behaviour of rpc.rquotad changed. To be able to set quota rpc.rquotad has to be started with option '-S'. msgstr Het gedrag van rpc.rquotad is veranderd. Om quota's te kunnen instellen dient rpc.rquotad gestart te worden met de optie '-S'. #. Type: string #. Description #: ../templates:8001 msgid Message of warnquota group emails: msgstr Inhoud van groepsquota-waarschuwings-e-mails: # Type: string # Description #. Type: string #. Description #: ../templates:8001 msgid The text you
Bug#597897: [Pkg-alsa-devel] alsa-firmware - bug #597897
reassign 597897 firmware-linux-nonfree thanks Hi Gents of the firmware linux-team, coluld you please distribute the alsa-firmware [10] within firmware-linux-nonfree? [10] ftp://ftp.alsa-project.org/pub/firmware/alsa-firmware-1.0.24.1.tar.bz2 Thanks Elimar * Jaromír Mikeš [111216 02:15 +0100]: [...] Hello Elimar, Jordi I am original submitter of this bug [1] and I contact you as admins of pkg-alsa-devel To be confused by your answer here, I would like to ask what is your attitude to the process of including missing alsa-firmwares to linux-firmware-non-free package? I think it was quite natural that alsa-devel has been asked for opinion and help or am I wrong? Sadly this process seems to be stuck now :( Best regards mira [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627153 -- Experience is something you don't get until just after you need it! signature.asc Description: Digital signature
Bug#652019: Uninstalllable and needs porting to zita-convolver's new API
Hi here is a patch for ir.lv2 to make it work with zita-convolver3, just 2 small changes are needed. regards hermann --- /home/brummer/Projekte/ir/ir.lv2-1.3.1/ir.cc2011-12-16 15:18:35.0 +0100 +++ /home/brummer/Projekte/ir/ir.lv2-1.3.1/plug/ir.cc 2011-12-16 15:18:24.0 +0100 @@ -165,8 +165,8 @@ treq.tv_nsec = 1000; nanosleep(treq, trem); - conv-check(); - state = conv-state(); + if(conv-check_stop()) +state = conv-state(); } delete conv; } @@ -558,7 +558,7 @@ ir-nchan); } - conv-start_process(0); + conv-start_process(0, SCHED_FIFO); ir-conv_req_to_use = req_to_use; } -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
