Bug#733057: [dpkg] Please explain rpm verification format
On Sun, 2014-01-19 at 19:30:19 -0500, Filipus Klutiero wrote: On 2014-01-15 14:27, Guillem Jover wrote: On Tue, 2013-12-24 at 13:20:38 -0500, Filipus Klutiero wrote: The only currently supported output format is rpm, which consists of a line for every path that failed any check. The lines start with 9 characters to report the specific check results, a '?' implies the check could not be done (lack of support, file permissions, etc), '.' implies the check passed, and an alphanumeric character implies a specific check failed; the only functional check is an md5sum verification denoted with a '5' on the third character. The line is followed by a space and an attribute character (currently 'c' for conffiles), another space and the pathname. On my system, the rpm format gives: # dpkg --verify ??5?? c /etc/sane.d/dll.conf […] It would help understand what is wrong if the output explained why a check failed, or if the manpage documented what the third check does. The md5sum verification failed, so the file's contents do not match the recorded hash in the database. This is explained in the --verify and --verify-format options in the man page, I'm not sure what information you find it's missing, TBH. Which recorded hash? The manpage doesn't say anything about hashes. The md5sum hash… The man page also says: -V, --verify [package-name...] Verifies the integrity of package-name or all packages if omit‐ ted, by comparing information from the installed paths with the database metadata. At this point, I'm just considering closing this report. Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: On diversity
Steve Langasek vor...@debian.org writes: On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote: I think (a) and (b) are pretty non-controversial. (c) and (d) are required if we want to deal with new GNOME stuff and anything other than systemd probably, and don't seem very hard to either do or document. (e), (f) and (g) seem like a fairly straightforward of allowing for multiple init systems in Debian. I think something like (i) might be a good way of sunsetting tech ctte decisions so if there's an actual consensus in future, there's no need to get a pro-forma vote from the ctte to make changes in future. YMMV of course. For my part I think this is generally a good idea, but I have the impression that at least Russ would be strongly opposed to this because it's too prescriptive. Probably not much sense in fleshing out such a resolution if there's not a consensus for it. I think this is all great work to do. I'm just dubious about enforcing it with a technical committee decision. This is the sort of thing that I was expecting to need to do on the Policy front once we have a decision. I think that's the right forum for drilling into the details. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736133: poppler: new stable version 0.24
package: src:poppler severity: wishlist Hi, there is a new stable version available. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735975: Dpkg::Control::Hash: would like more subtle pgp check
On Sun, 2014-01-19 at 11:39:50 +, Ian Jackson wrote:
Guillem Jover writes (Re: Bug#735975: Dpkg::Control::Hash: would like more
subtle pgp check):
...
Starting with version 1.17.0 the Dpkg::Control::Hash module records
that fact in the is_pgp_signed option. This is not documented, so you
might not want to rely on it, expecting to be an internal detail. But
I can make it part of the public interface by documenting it in the
next release, as it seems useful outside of Dpkg::Source::Package too.
Great.
The way to retrieve it, as of now is:
$ctrl-get_option('is_pgp_signed');
Would that be enough for your needs?
Yes, that would be exactly the kind of thing I want.
Ok, then I'm documenting that for 1.17.7.
Since I want to make dgit easy to use even on older releases of Debian
(and derivatives thereof), I will want to have some kind of way of
telling whether the version of Dpkg::Control::Hash supports this
feature.
Experimentation with squeeze and sid[1] shows me that when the feature
is supported but the message isn't signed, that get_option returns
0, whereas if the feature isn't supported it returns undef. Can I
rely on this or is there a better way ?
Yes, you could rely on this, but there's actually another option, in
this case you could use Dpkg::Source::Package instead which has a
is_signed() method since its inception (it only got documented as a
public interface in 1.16.1, but that interface has never changed).
The drawback is that your code might need to end up parsing the .dsc
file twice, but that should not be such a performance issue.
[1]
perl -e 'use Data::Dumper; use Dpkg::Control::Hash; my $h = new
Dpkg::Control::Hash; $h-load(debian/control) or die; my $y =
$h-get_option(is_pgp_signed); print Dumper($y);'
BTW, you might want to use instead, something like:
,---
my $dsc = Dpkg::Control-new(type = CTRL_PKG_SRC);
`---
which will set a correct name for error messages and similar, and
field ordering for that type.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736134: Remove amd64 and s390x flavours for 32-bit architectures
Package: src:linux Version: 3.13~rc6-1~exp1 Severity: normal It is now possible to install linux-headers packages from a foreign architecture (at least when the primary and foreign architectures are both supported by a biarch/triarch compiler). There should no longer be any need to provide the amd64 or s390x kernel flavours on the corresponding 32-bit architectures. (We can't yet do this for other 64-bit mips/powerpc/sparc flavours because only the 32-bit architectures are release architectures.) However, it turns out there is a problem with module-assistant that will need to be fixed first. Ben. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735760: handbrake: FTBFS: dvdnav.c:1230: undefined reference to `dvdnav_dup'
reassign 735760 libdvdnav-dev
found 735760 4.2.1-1
severity 735760 serious
retitle 735760 libdvdnav: removed dvdnav_dup{,_free} API
thanks
Am Sonntag, den 19.01.2014, 12:38 +0100 schrieb Fabian Greffrath:
Am Freitag, den 17.01.2014, 18:11 +0100 schrieb David Suárez:
/«BUILDDIR»/handbrake-0.9.9+dfsg/build/../libhb/dvdnav.c:1230: undefined
reference to `dvdnav_dup'
/«BUILDDIR»/handbrake-0.9.9+dfsg/build/../libhb/dvdnav.c:1237: undefined
reference to `dvdnav_free_dup'
collect2: error: ld returned 1 exit status
Why have these symbols been removed again from libdvdnav? They were the
reason we packaged the 20120524 git snapshot in the first place!
Also, ABI-incompatible changes require a SONAME bump.
- Fabian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736135: Missing multiarch support
Package: module-assistant Version: 0.11.6 Severity: normal module-assistant cannot install headers for a foreign-architecture kernel: # dpkg --print-architecture i386 # uname -r 3.12-1-amd64 # dpkg -l linux-image-$(uname -r) Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii linux-image-3. 3.12.8-1 amd64Linux 3.12 for 64-bit PCs # m-a --text a-i leds-alix . Updated infos about 1 packages Getting source for kernel version: 3.12-1-amd64 apt-get install linux-headers-3.12-1-amd64 Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libgroupsock0 libkdc2-heimdal liblivemedia7 libserf1 libusageenvironment0 python-logilab-astng Use 'apt-get autoremove' to remove them. The following extra packages will be installed: linux-compiler-gcc-4.8-x86 linux-headers-3.12-1-common linux-kbuild-3.12 The following NEW packages will be installed: linux-compiler-gcc-4.8-x86 linux-headers-3.12-1-amd64 linux-headers-3.12-1-common linux-kbuild-3.12 0 upgraded, 4 newly installed, 0 to remove and 5 not upgraded. Need to get 4,945 kB of archives. After this operation, 31.9 MB of additional disk space will be used. Do you want to continue? [Y/n] This sometimes works at present, because the amd64 flavour is functionally identical and ABI-compatible on i386 and amd64, but I actually want to get rid of the amd64 flavour on i386 as it is now a waste of space and build time. (Similarly for the s390x flavour on s390.) But even now, the resulting module packages are built for the primary architecture, and some of them (depending on the 'source' package's template - dahdi-source is one example) have dependencies on linux-image-$kversion. That makes them uninstallable when the kernel is foreign. So I think that module-assistant should select a target architecture as follows: 1. Provide an option to set the target architecture explicitly. 2. If the option is not set, look for an installed linux-image or linux-headers package for the target kernel version. (a) If either or both are present then the target architecture is the architecture of the installed package(s). If both are installed but with different architectures, you could report an error or pick one as the winner. (b) If neither is present then the target architecture is the primary architecture. It should then explicitly specify that target architecture when installing linux-headers packages and when building packages. Ben. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages module-assistant depends on: ii bzip2 1.0.6-5 ii libtext-wrapi18n-perl 0.06-7 ii perl 5.18.1-5 ii xz-utils 5.1.1alpha+20120614-2 Versions of packages module-assistant recommends: ii liblocale-gettext-perl 1.05-7+b2 Versions of packages module-assistant suggests: ii build-essential 11.6 ii whiptail 0.52.15-3 -- 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#727708: On diversity
On 20 January 2014 14:29, Russ Allbery r...@debian.org wrote: Steve Langasek vor...@debian.org writes: On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote: I think (a) and (b) are pretty non-controversial. (c) and (d) are required if we want to deal with new GNOME stuff and anything other than systemd probably, and don't seem very hard to either do or document. (e), (f) and (g) seem like a fairly straightforward of allowing for multiple init systems in Debian. I think something like (i) might be a good way of sunsetting tech ctte decisions so if there's an actual consensus in future, there's no need to get a pro-forma vote from the ctte to make changes in future. YMMV of course. For my part I think this is generally a good idea, but I have the impression that at least Russ would be strongly opposed to this because it's too prescriptive. Probably not much sense in fleshing out such a resolution if there's not a consensus for it. I think this is all great work to do. I'm just dubious about enforcing it with a technical committee decision. This is the sort of thing that I was expecting to need to do on the Policy front once we have a decision. I think that's the right forum for drilling into the details. Personally, I'm still not really clear on where the ctte is leaning wrt supporting multiple init systems; if the idea is that [OpenRC] becomes the new default, and declares itself as Essential:yes, and the Debian maintainers of [systemd and upstart] say okay, I give up, I'm going to work on [OpenRC] now, it doesn't seem like there'd be much need for policy work. Obviously, switch the init systems around as appropriate. I believe I've seen comments along those lines from both systemd and upstart maintainers should upstart or systemd be chosen as the default, but maybe I'm mistaken. I'm pretty sure I've seen numerous comments that Debian should only support one init system (per kernel, at any rate), which would make the Essential:yes part make sense. To me that seems like it would be a bad outcome (even if we adopted upstart everywhere and abandoned sysvrc, systemd and openrc entirely; it would still make it unduly difficult to experiment with the next next-generation init systems in a Debian environment). I'd expect the tech ctte's decision to be prescriptive enough that it's clear what non-default-init-system maintainers and users should do, post-apocalypse, I guess. On a practical note, having a quick look at the policy list, it seems like that's not actually crazy active/responsive at present either (long overdue updates to menu policy and triggers documentation are the only topics this month?), so relying on -policy for detail work doesn't seem like it would actually work out in a timely fashion? Honestly, I was a bit surprised that Steve thinks the above's a good idea, given I wrote it from the (my) perspective of wanting to support multiple init systems within Debian; and my understanding is his opinion is that that's kind-of nuts. I think that's pretty great through, especially in that it affirms my naive faith that drilling down into technical details is a good way of achieving consensus amongst people with very different goals and political/philosophical stances... ;) Cheers, aj -- Anthony Towns a...@erisian.com.au -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736123: ITP: sbbi-upnplib -- Java library for universal plug and play (upnp)
Hi, Most java library source packages don't respect the format libXXX-java, which is rather meant for the binary package. Keeping the upstream name for the source and, as noted by Jonathan, considering the fact that one source might create more than a library, e.g. a javadoc package, that sounds right to me. Eric Jonathan Yu jaw...@cpan.org wrote: Hey Scott, It has been said that There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton :-) The binary package was of the most concern to me, because that's what users will look for when installing. I actually have no experience with Java packaging, so I'm not sure what the conventions are there. Personally, my preference would be for source + binary packages to be the same name. I used to work on packaging Perl libraries mainly, and in that case, our convention was generally to stick with the lib*-perl pattern, for both source and binary packages. Initially, we also did this for applications (e.g. libcpanminus-perl), but later decided to go with just application names (i.e. cpanminus) in cases where the application is meant to be used standalone and not as a library. We codified these conventions in the policy for the Debian Perl Group [0]. Whether something is more appropriately a library or application requires some discretion on the part of the packaging Debian contributor/developer, of course. And I'm not sure what to name the source package in a case where there is both a library and application component. I guess the analogue with Perl modules is also different because upstream Perl package names (Module::Name) are not valid Debian package names anyway, so they have to be transmogrified to fit our convention, and lib*-perl seems as fine a convention as any. Does apt-get source expect the source package name, or will it also work with binary package names? If I do apt-get source libupnp-java, will it download the sbbi-upnplib package? If so, then this seems to be an especially trivial point, and I'd be happy with either name. In any case, since I'm not an expert here, let's see if someone on the debian-java list chimes in :-) Cheers, Jonathan [0] http://pkg-perl.alioth.debian.org/policy.html#package_naming_policy On Sun, Jan 19, 2014 at 9:43 PM, Scott Howard showard...@gmail.com wrote: Hi all, The binary package is named libupnp-java, seen here: http://anonscm.debian.org/gitweb/?p=pkg-java/sbbi-upnplib.git;a=blob;f=debian/control;h=8014fb5b4d2c3eb60968caaa6c239562002dd9f7;hb=HEAD I named the source package to match the name of the upstream tarball file (sbbi-upnplib-1.0.4.tar.gz) I struggled with either naming the source package the same as the binary package, or to name it like I suggest here. Since upstream refers to the project as sbbi-upnplib and their tarball had that in it, I'm leaning toward keeping the name what they call it. It will be discoverable since the binary package has the proper java library package name. I was worried about it not being discoverable if I didn't put the sbbi-upnplib source package name. Given that, do you still think it should be renamed? I don't mind either way. ~Scott On Sun, Jan 19, 2014 at 8:50 PM, Jonathan Yu jaw...@cpan.org wrote: Hey Scott, I don't presume to be an expert here, but I wanted to mention that the package name specified in your ITP does not match the usual conventions for libraries in Debian, nor for Java libraries specifically: Java libraries packages must be named libXXX[version]-java (without the brackets) [0] Might you consider renaming this package to make it more easily discoverable? Cheers, Jonathan [0] http://www.debian.org/doc/packaging-manuals/java-policy/x104.html On Sun, Jan 19, 2014 at 5:33 PM, Scott Howard show...@debian.org wrote: Package: wnpp Severity: wishlist Owner: Scott Howard show...@debian.org * Package name: sbbi-upnplib Version : 1.0.4 Upstream Author : SuperBonBon Industries * URL : http://sourceforge.net/p/triplea/code/HEAD/tree/upnp/ * License : Apache-1.1 Programming Lang: Java Description : Java library for universal plug and play (upnp) This is a dependency of the newest versions of the triplea package. To be maintained under the java team umbrella. Initial repo: http://anonscm.debian.org/gitweb/?p=pkg-java/sbbi-upnplib.git -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140119223359.15198.7602.report...@esc-303123.ee.nd.edu -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/camdxsejlkidda__v6lfzbe+iaf0j5yocl6uoaongoq0rr3z...@mail.gmail.com -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble?
Bug#727708: On diversity
Anthony Towns a...@erisian.com.au writes: To me that seems like it would be a bad outcome (even if we adopted upstart everywhere and abandoned sysvrc, systemd and openrc entirely; it would still make it unduly difficult to experiment with the next next-generation init systems in a Debian environment). I'd expect the tech ctte's decision to be prescriptive enough that it's clear what non-default-init-system maintainers and users should do, post-apocalypse, I guess. For as long as they're interested in making the effort, try to get as many packages as possible supported under their init system, particularly in advance of the point at which we might start dropping sysvinit scripts that currently provide the common denominator across all the systems. Obviously, to the extent that this can reuse work done for the default init system, that's going to make this much easier. That means that implementing the key integration features of the default init system will make things much easier (for example, things like the notification protocol, non-forking daemon startup, and possibly socket activation). It's going to be particularly important to have good docs for maintainers to write configuration for the non-default init system, since a lot of maintainers aren't going to be able to easily test, so you want people to be able to write things that work without a lot of debugging. Obviously, that includes Policy. On a practical note, having a quick look at the policy list, it seems like that's not actually crazy active/responsive at present either (long overdue updates to menu policy and triggers documentation are the only topics this month?), so relying on -policy for detail work doesn't seem like it would actually work out in a timely fashion? Policy is in general not horribly healthy right now, but as I mentioned in passing earlier in this huge thread, I'm committing to shephard the Policy work for this decision through and try to help with the documentation and specifics. I can't do that and participate in this discussion at the same time, though, since this is basically eating all my Debian time at the moment. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736136: nmu: binutils-mingw-w64_2.23.52.20130612-1+3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear release team, I would appreciate a binNMU of binutils-mingw-w64 so it's rebuilt with binutils 2.24. Thanks in advance, Stephen nmu binutils-mingw-w64_2.23.52.20130612-1+3 . ALL . -m Rebuild with binutils 2.24. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735924: closed by Changwoo Ryu cw...@debian.org (Re: Bug#735924: keyboard layout)
hi thanks for the report Eric Le 20/01/2014 02:03, Debian Bug Tracking System a écrit : This is an automatic notification regarding your Bug report which was filed against the ibus-hangul package: #735924: hangul: after lat ugdrade, it's not possible to type in Korean any more It has been closed by Changwoo Ryu cw...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Changwoo Ryu cw...@debian.org by replying to this email. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713501: doc-debian: FTBFS: ** WML:Error: input file `mailing-lists.wml' not found
On Sat, Jun 22, 2013 at 03:51:52PM +0200, Lucas Nussbaum wrote: Source: doc-debian Version: 6.1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20130620 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. lynx -dump -nolist constitution.1.3.html constitution.1.3.txt ERROR: Cannot find ~/debian/www/webwml/english to regenerate the sources. Please read the TODO. wml -q mailing-lists.wml mailing-lists.html ** WML:Error: input file `mailing-lists.wml' not found make[1]: *** [mailing-lists.html] Error 1 I can also reproduce this in stable. Once fixed in sid, it would be nice if that FTBFS could also be fixed in wheezy. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736137: /usr/bin/display.im6: random crash (SIGSEGV)
Package: imagemagick
Version: 8:6.7.7.10-7
Severity: normal
File: /usr/bin/display.im6
I got this random crash from display.im6. I tried reporting it upstream
but didn't get a reply or any way to check if they recieved it. If the
following backtrace is not useful please close the bug.
$ gdb -batch -n -ex bt -ex 'thread apply all bt full' --core
/var/crash/1000/4298-1000-1000-11-1390119462-chianamo--usr-bin-display.im6.core
/usr/bin/display.im6
warning: core file may not match specified executable file.
[New LWP 4298]
[New LWP 4370]
[New LWP 4371]
[New LWP 4369]
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need set solib-search-path or set sysroot?
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x7fff469fe000
Core was generated by `display -'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f526e9ab0eb in raise (sig=sig@entry=11) at
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
38 ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
#0 0x7f526e9ab0eb in raise (sig=sig@entry=11) at
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:38
#1 0x7f5270ba6872 in MagickSignalHandler (signal_number=11) at
magick/magick.c:1151
#2 signal handler called
#3 0x7f526de57cd8 in XFreeCursor (dpy=0x23f2e80, cursor=41943052) at
../../src/FreeCurs.c:38
#4 0x7f5270c61c59 in DestroyXResources () at magick/xwindow.c:281
#5 0x7f5270c61ec5 in XComponentTerminus () at magick/xwindow.c:1652
#6 0x7f5270ba728b in MagickCoreTerminus () at magick/magick.c:1364
#7 0x0040098e in DisplayMain (argv=optimized out, argc=2) at
utilities/display.c:93
#8 main (argc=2, argv=optimized out) at utilities/display.c:100
Thread 4 (Thread 0x7f5268a4f700 (LWP 4369)):
#0 futex_wait (val=12, addr=0x2456cc4) at
../../../src/libgomp/config/linux/x86/futex.h:44
r10 = 0
res = -512
#1 do_wait (val=12, addr=0x2456cc4) at
../../../src/libgomp/config/linux/wait.h:64
val = 12
addr = 0x2456cc4
#2 gomp_barrier_wait_end (bar=0x2456cc0, state=12) at
../../../src/libgomp/config/linux/bar.c:47
No locals.
#3 0x7f526dc2c2fe in gomp_thread_start (xdata=optimized out) at
../../../src/libgomp/team.c:119
team = 0x246b3c0
data = optimized out
pool = 0x2456c80
local_fn = 0x7f5270c02cf0 HorizontalFilter._omp_fn.2
local_data = 0x7fff468d44d0
#4 0x7f526e9a3e0e in start_thread (arg=0x7f5268a4f700) at
pthread_create.c:311
__res = optimized out
pd = 0x7f5268a4f700
now = optimized out
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139991919687424,
2229628000393634533, 0, 139992007644320, 4096, 139991919687424,
-2281658616700591387, -2281662626619186459}, mask_was_saved = 0}}, priv = {pad
= {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
pagesize_m1 = optimized out
sp = optimized out
freesize = optimized out
__PRETTY_FUNCTION__ = start_thread
#5 0x7f526d6630fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113
No locals.
Thread 3 (Thread 0x7f5267a4d700 (LWP 4371)):
#0 futex_wait (val=12, addr=0x2456cc4) at
../../../src/libgomp/config/linux/x86/futex.h:44
r10 = 0
res = -512
#1 do_wait (val=12, addr=0x2456cc4) at
../../../src/libgomp/config/linux/wait.h:64
val = 12
addr = 0x2456cc4
#2 gomp_barrier_wait_end (bar=0x2456cc0, state=12) at
../../../src/libgomp/config/linux/bar.c:47
No locals.
#3 0x7f526dc2c2fe in gomp_thread_start (xdata=optimized out) at
../../../src/libgomp/team.c:119
team = 0x246b3c0
data = optimized out
pool = 0x2456c80
local_fn = 0x7f5270c02cf0 HorizontalFilter._omp_fn.2
local_data = 0x7fff468d44d0
#4 0x7f526e9a3e0e in start_thread (arg=0x7f5267a4d700) at
pthread_create.c:311
__res = optimized out
pd = 0x7f5267a4d700
now = optimized out
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139991902902016,
2229628000393634533, 0, 139992007644320, 4096, 139991902902016,
-2281647620510571803, -2281662626619186459}, mask_was_saved = 0}}, priv = {pad
= {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
pagesize_m1 = optimized out
sp = optimized out
freesize = optimized out
__PRETTY_FUNCTION__ = start_thread
#5 0x7f526d6630fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113
No locals.
Thread 2 (Thread 0x7f526824e700 (LWP 4370)):
#0 futex_wait (val=12, addr=0x2456cc4) at
../../../src/libgomp/config/linux/x86/futex.h:44
r10 = 0
res = -512
#1 do_wait (val=12, addr=0x2456cc4) at
../../../src/libgomp/config/linux/wait.h:64
val = 12
addr = 0x2456cc4
Bug#736138: RM: gnat-mingw-w64 [armhf] -- NVIU; Split source package, not building on armhf
Package: ftp.debian.org
Severity: normal
Dear FTP team,
The gnat-mingw-w64 packages, which used to be built by gcc-mingw-w64,
now have their own source package. The latter isn't building on armhf,
but that's blocking the transition of gcc-mingw-w64...
I'd appreciate it if gnat-mingw-w64{,-i686,-x86-64} could be removed
on armhf.
Thanks,
Stephen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: On diversity
On Mon, Jan 20, 2014 at 03:51:20PM +1000, Anthony Towns wrote: Honestly, I was a bit surprised that Steve thinks the above's a good idea, given I wrote it from the (my) perspective of wanting to support multiple init systems within Debian; and my understanding is his opinion is that that's kind-of nuts. I think that's pretty great through, especially in that it affirms my naive faith that drilling down into technical details is a good way of achieving consensus amongst people with very different goals and political/philosophical stances... ;) :) So to expand on where I'm coming from: I think that it's important to choose a default for jessie, and that it's important that this not be sysvinit; and I think whatever init system we choose for jessie will wind up having a significant boost in momentum within Debian which will give it staying power for a long time to come, and the non-default init systems will receive little if any attention. But I don't think the TC decision should be a *permanent* one; as you say, there's always a next next-generation to think about. So I think we shouldn't have any particular init system marked as Essential: yes. Indeed, sysvinit being marked Essential: yes was an obstacle for upstart in Debian for quite a while; less so for systemd because the systemd maintainers made the expedient - but IMHO technically undesirable - decision to split all conflicting files into a separate package. So that's to e). f) is the sort of thing I think should be time limited to jessie; g) seems obviously correct as far as it goes, but I think we might quibble on the details of what packages are allowed to do this and why, because one of the important features of Debian is that you can install nearly anything from the archive together on the same system. Having packages with mutually incompatible dependencies on specific init systems would undermine this badly. And c) and d) are completely aligned with what I've been arguing (perhaps poorly) that should be done with logind integration, because it's relevant even if we don't adopt upstart as the default, as long as we want to have non-Linux ports going forward. So while I don't want to encourage the project to divide its efforts across multiple different init systems in jessie, I think the particular points you raise here are good ones, and I would only quibble on some of the minor details. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#707178: Breakin - stress-test and hardware diagnostics tool - Please see if you are able to assist to an issue we are having now for more than a month on 3 servers
Thank you very much Andreas! Kind regards, Bryan -Original Message- From: Andreas Cadhalpun [mailto:andreas.cadhal...@googlemail.com] Sent: 17 January 2014 09:51 PM To: Bryan Fisher Cc: 707...@bugs.debian.org; 733...@bugs.debian.org; Antoine Beaupré; tagg...@debian.org; d...@fifthhorseman.net; jroll...@finestructure.net Subject: Re: Bug#707178: Breakin - stress-test and hardware diagnostics tool - Please see if you are able to assist to an issue we are having now for more than a month on 3 servers Hi Bryan, On 17.01.2014 10:13, Bryan Fisher wrote: I was hoping that maybe you could assist me in the issue that I am getting with server h/w please. Attached is a screenshot of what happens when I insert a USB key to copy the Breakin log file. It also indicates that 'Failid - Other tests have errors, tuning on ID light..' would it be possible if you could point me in a direction to find the fault please? The error message (repeated 3 times) I read from the screenshot is: kernel: [ 3009.877308] sd 9:0:0:0: [sdb] No Caching mode page present kernel: [ 3009.877311] sd 9:0:0:0: [sdb] Assuming drive cache: write through This reminds me of bug #733565 [1], which is about a request to silence these error messages. I have seen similar messages and they seem to be totally harmless and have nothing to do with hardware failure. Best regards, Andreas 1: http://bugs.debian.org/733565 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736117: Perl installation on sompek (was: Re: Bug#736117: nmu: libgeo-proj4-perl_1.04-1)
Hi, On the 4th of January, libgeo-proj4-perl on sparc was built in a sid environment against perl5.14 on sompek (see link below). Before I schedule a binNMU for it, I would to get confirmation that the chroot has been updated to use perl5.18. Thanks, ~Niels On 2014-01-19 22:14, Andreas Beckmann wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu libgeo-proj4-perl_1.04-1 . sparc . -m Rebuild against perl 5.18 The buildd chroot on sompek.debian.org that built the package on 04 Jan 2014 21:30 https://buildd.debian.org/status/fetch.php?pkg=libgeo-proj4-perlarch=sparcver=1.04-1stamp=1388871357 still had (maybe has) perl 5.14 installed, producing a package that is uninstallable elsewhere. * the chroot needs to be fixed (and other similar buggy ones as well) * the rebuild should enforce some additional build-dependency on perl-base ( 5.18) Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736139: blockdiag: Fails to build from source in stable
Package: blockdiag
Version: 1.1.6-1.1
Severity: serious
Hi,
blockdiag fails to build from source in Wheezy (sid properly builds from
source):
Cheers,
Moritz
--
copying src/blockdiag/tests/diagrams/errors/unknown_group_orientation.diag -
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_group_shape.diag -
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_node_attribute.diag -
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_node_class.diag -
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_node_shape.diag -
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_node_style.diag -
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
copying src/blockdiag/tests/diagrams/errors/unknown_plugin.diag -
_build/lib.linux-x86_64-2.7/blockdiag/tests/diagrams/errors
debian/rules override_dh_auto_test
make[1]: Entering directory `/home/jmm/scratch/wheezy/blockdiag-1.1.6'
set -e; \
PYTHONPATH=/home/jmm/scratch/wheezy/blockdiag-1.1.6/src nosetests -d
..E
==
ERROR:
blockdiag.tests.test_generate_diagram.test_generator_svg('node_icon.diag',
'svg')
--
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File /home/jmm/scratch/wheezy/blockdiag-1.1.6/src/blockdiag/tests/utils.py,
line 14, in wrap
func(*args, **kwargs)
File /home/jmm/scratch/wheezy/blockdiag-1.1.6/src/blockdiag/tests/utils.py,
line 29, in wrap
func(*args, **kwargs)
File
/home/jmm/scratch/wheezy/blockdiag-1.1.6/src/blockdiag/tests/test_generate_diagram.py,
line 51, in __build_diagram
raise RuntimeError(sys.stderr.getvalue())
RuntimeError: ERROR: cannot identify image file
begin captured stdout -
('node_icon.diag', 'svg') {}
---[ stderr ] ---
ERROR: cannot identify image file
- end captured stdout --
--
Ran 299 tests in 4.219s
FAILED (errors=1)
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory `/home/jmm/scratch/wheezy/blockdiag-1.1.6'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735251: [Pkg-xfce-devel] Bug#735251: lightdm: user locale tweaks are clobbered by non-default locale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, Jan 20, 2014 at 01:02:26PM +0900, Olaf Meeuwissen wrote: At the very beginning of the /etc/X11/Xsession script LANG=C. Well, this one is a problem, it's should not be the case (and it's not the case for me on any of my box). C is the default locale on my system. Ok, I don't have a default locale here (so it means it defaults to POSIX). Okay, I've been looking at the source code a bit. Turns out that session_set_env() does not set any environment variables directly. It adds them to an internal list (session-priv-env). This list is written to the session in `session_real_run()`. I didn't find any calls to `session_unset_env()` for either LANG and GDM_LANG so would expect both to be set in the session. However, the greeter and user session inherit the system default locale courtesy of PAM as per comment in src/session-child.c. This probably explains why I see LANG=C at the start of my Xsession. That might make sense, although I don't think it's the correct behavior in case an user actually choose a language in the selector. Anyway, I now nuke GDM_LANG in ~/.xsessionrc and have not seen any breakage yet. The `locale` output is as I expect it and my input method editor works as it used to. I no longer have a ~/.dmrc (and it is not recreated when you don't save your session). I can pick any language I please from the chooser without this having *any* effect on my session. That is, the chooser does not interfere with my customizations which is what I want. .dmrc has nothing to do with saving the session. And it's created (or at least should be) *before* the session is actually started. Regards. - -- Yves-Alexis Perez -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJS3MYFAAoJEG3bU/KmdcCl/vEH/3s8idL1HPHVw+23abnGMte7 3ZefLPY4d+Mzyrd55eKmwUiU2UTO36P7uf3BhqrtmXPePdz7+jLkWHMSElly4NR4 /ucfGYD6VQyEZ4nvsJRV3a182wlhSXqDq2GXfYEFJ6DOZnUkB/sa7VfIJm9lBDH1 e4rWHpDRCbEVepvEZgQbDiJDKEXXCT/g4CzTSKsWGrMa1LRZLHUVOcI0ErN2DPGY Iz1ep4Pq2MbAXRbN7dqkrSibIEPWhoYSEACo2TQOOgFUeG4a4sMh4y3HBlS+LooV 9i3+pfrb3pYcr/sgkXBodepQ3EkvPPNww8Ksu3y0ydQ46inCXLdK7NWOGNDyKz4= =ap2m -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736140: bash: set -v and appending to /dev/stderr in a file looses a little data
Package: bash
Version: 4.2+dfsg-1
Severity: normal
Dear Maintainer,
Thank you very much for maintaining Debian's
bash package.
It's important.
People using the nicknames geirha and ormaaj
in the #bash channel at freenode's IRC network and
I happened to notice bash doing something we
didn't expect.
We found two circumstances where it appeared to
lose a little data.
I duplicated the little loss with versions
4.2.45(1)-release and 4.3.0(1)-rc1.
The later was running as a bot in freenode's
#evalbot channel.
OK, here's the first code that elicits the odd
behavior:
$ echo 'set -x; echo a /dev/stderr ; echo b /dev/stderr' ./c ;
chmod 755 ./c ; ./c ./d 21 ; cat ./d ; rm ./c ./d
I expected the first echo statement to produce an
output line containing just an a.
However, all I got was
echo 'set -x; echo a /dev/stderr ; echo b /dev/stderr' ./c ;
chmod 755 ./c ; ./c ./d 21 ; cat ./d ; rm ./c ./d
++ echo a
++ echo b
b
The second sample code is:
$ set -v; echo 'f() { echo a /dev/stderr ; }; f; echo b 2' ./c; chmod
755 ./c; ./c ./d 21; cat ./d ; rm ./c ./d
Likewise, I expected its first echo statement to produce an
output line containing just an a.
However, I got only
set -v; echo 'f() { echo a /dev/stderr ; }; f; echo b 2' ./c; chmod
755 ./c; ./c ./d 21; cat ./d
b
The a line reappears if set -x is not used ...
$ echo 'echo a /dev/stderr ; echo b /dev/stderr' ./c ; chmod
755 ./c ; ./c ./d 21 ; cat ./d ; rm ./c ./d
a
b
It also reappears if a file is not used ...
$ { set -x; echo a /dev/stderr ; echo b /dev/stderr ; } 21
+ echo a
a
+ echo b
b
I hope that helps,
Kingsley
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages bash depends on:
ii base-files 7.2
ii dash 0.5.7-3
ii debianutils 4.4
ii libc62.17-97
ii libtinfo55.9+20130608-1
Versions of packages bash recommends:
ii bash-completion 1:2.0-1
Versions of packages bash suggests:
ii bash-doc 4.2+dfsg-1
-- Configuration Files:
/etc/bash.bashrc changed [not included]
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733087: [LCFC] templates://apt-cacher-ng/{apt-cacher-ng.templates}
This is the last call for comments for the review of debconf
templates for apt-cacher-ng.
The reviewed templates will be sent on Wednesday, January 22, 2014 to this bug
report
and a mail will be sent to this list with [BTS] as a subject tag.
--
# These templates have been reviewed by the debian-l10n-english
# team
#
# If modifications/additions/rewording are needed, please ask
# debian-l10n-engl...@lists.debian.org for advice.
#
# Even minor modifications require translation updates and such
# changes should be coordinated with translators and reviewers.
Template: apt-cacher-ng/gentargetmode
Type: select
__Choices: Set up once, Set up now and update later, No automated setup
Default: Set up once
_Description: Automatic remapping of client requests:
Apt-Cacher NG can download packages from repositories other than those
requested by the clients. This allows it to cache content effectively,
and makes it easy for an administrator to switch to another mirror later.
.
This remapping of URLs can be configured now in an automated way based on the
current state of /etc/apt/sources.list. Optionally, this process can be
repeated on every package update (modifying the configuration files each
time).
.
Selecting No automated setup will leave the existing configuration
unchanged. It will need to be updated manually.
Template: apt-cacher-ng/bindaddress
Type: string
Default: keep
_Description: Address(es) for apt-cacher-ng to listen to:
Please enter the addresses or hostnames which should be used by
apt-cacher-ng (multiple entries must be separated by spaces).
.
Each entry must be an exact address (IP or hostname) which is
associated with a local network interface. Generic protocol specific addresses
are supported, such as 0.0.0.0 for listening on all IPv4 enabled interfaces.
.
If this field is left empty, apt-cacher-ng wille listen on all
interfaces, with all supported protocols.
.
The special word keep keeps the value from the current (or default)
configuration unchanged.
Template: apt-cacher-ng/port
Type: string
Default: keep
_Description: Listening TCP port:
Please configure the TCP port where Apt-Cacher NG should listen for incoming
HTTP
(proxy) requests. The default value is port 3142, and it can be set to to
emulate
apt-proxy.
.
If left empty, the value from the current configuration remains unchanged.
Template: apt-cacher-ng/cachedir
Type: string
Default: keep
_Description: Top level directory for packages cache:
The main cache storage directory should be located on a file system without
file name restrictions.
.
If left empty, the value from the current configuration remains unchanged or
is set to default directory /var/cache/apt-cacher-ng.
Template: apt-cacher-ng/proxy
Type: string
Default: keep
_Description: Proxy to use for downloads:
Please specify the proxy server to use for downloads.
.
Username and password for the proxy server can be included here following the
user:pass@host:port scheme. However, please check the documentation for
limitations.
.
If this field is left empty, apt-cacher NG will not use any proxy
server.
.
The special word keep keeps the value from the current (or default)
configuration unchanged.
Source: apt-cacher-ng
Section: net
Priority: optional
Maintainer: Eduard Bloch bl...@debian.org
Build-Depends: debhelper (= 9), cmake (= 2.6.2), libbz2-dev, zlib1g-dev,
liblzma-dev, libfuse-dev [!hurd-i386], pkg-config, libwrap0-dev, lsb-base (
3.0-6), dh-systemd (= 1.5), po-debconf, libssl-dev
Standards-Version: 3.9.5
Homepage: http://www.unix-ag.uni-kl.de/~bloch/acng/
Package: apt-cacher-ng
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, adduser
Pre-Depends: dpkg (= 1.15.6)
Recommends: ed, avahi-daemon
Conflicts: logrotate ( 3.8.0)
Suggests: doc-base, libfuse2 (= 2.5), curl | wget
Description: caching proxy server for software repositories
Apt-Cacher NG is a caching proxy for downloading packages from Debian-style
software repositories (or possibly from other types).
.
The main principle is that a central machine hosts the proxy for a local
network, and clients configure their APT setup to download through it.
Apt-Cacher NG keeps a copy of all useful data that passes through it, and when
a similar request is made, the cached copy of the data is delivered without
being re-downloaded.
.
Apt-Cacher NG has been designed from scratch as a replacement for
apt-cacher, but with a focus on maximizing throughput with low system
resource requirements. It can also be used as replacement for apt-proxy and
approx with no need to modify clients' sources.list files.
signature.asc
Description: Digital signature
Bug#736141: Support for Aladdins 72kb eToken
Package: libccid Severity: normal Hi! I'd like to use Aladdin's eToken 72k Java on linux. Attached is an output of ./src/parse and parse -p. How can I help you to implement this? Thanks a lot! Marco Parsing USB bus/device: 05C6:9205 (bus 2, device 5) idVendor: 0x05C6 iManufacturer: [34mQualcomm Incorporated [0m idProduct: 0x9205 iProduct: [34mQualcomm Gobi 2000 [0m[35m Found a possibly CCID/ICCD device (bInterfaceClass = 0xFF). Use ./parse -p [0mParsing USB bus/device: 0529:0620 (bus 2, device 9) idVendor: 0x0529 iManufacturer: [34mAladdin [0m idProduct: 0x0620 iProduct: [34mToken JC [0m[32m Found a CCID/ICCD device at interface 0 [0mParsing USB bus/device: 8087:0020 (bus 2, device 2) idVendor: 0x8087 Can't get iManufacturer string idProduct: 0x0020 Can't get iProduct string [31m NOT a CCID/ICCD device [0mParsing USB bus/device: 1D6B:0002 (bus 2, device 1) idVendor: 0x1D6B iManufacturer: [34mLinux 3.12-1-686-pae ehci_hcd [0m idProduct: 0x0002 iProduct: [34mEHCI Host Controller [0m[31m NOT a CCID/ICCD device [0mParsing USB bus/device: 17EF:480F (bus 1, device 7) idVendor: 0x17EF iManufacturer: [34mChicony Electronics Co., Ltd. [0m idProduct: 0x480F iProduct: [34mIntegrated Camera [0m[31m NOT a CCID/ICCD device [0mParsing USB bus/device: 0603:00F2 (bus 1, device 8) idVendor: 0x0603 iManufacturer: [34mNOVATEK [0m idProduct: 0x00F2 iProduct: [34mUSB Keyboard [0m[31m NOT a CCID/ICCD device [0mParsing USB bus/device: 13FD:1840 (bus 1, device 10) idVendor: 0x13FD iManufacturer: [34mGeneric [0m idProduct: 0x1840 iProduct: [34mExternal [0m[31m NOT a CCID/ICCD device [0mParsing USB bus/device: 17EF:100A (bus 1, device 6) idVendor: 0x17EF Can't get iManufacturer string idProduct: 0x100A Can't get iProduct string [31m NOT a CCID/ICCD device [0mParsing USB bus/device: 147E:2016 (bus 1, device 4) idVendor: 0x147E iManufacturer: [34mUPEK [0m idProduct: 0x2016 iProduct: [34mBiometric Coprocessor [0m[35m Found a possibly CCID/ICCD device (bInterfaceClass = 0xFF). Use ./parse -p [0mParsing USB bus/device: 046D:C521 (bus 1, device 3) idVendor: 0x046D iManufacturer: [34mLogitech [0m idProduct: 0xC521 iProduct: [34mUSB Receiver [0m[31m NOT a CCID/ICCD device [0mParsing USB bus/device: 8087:0020 (bus 1, device 2) idVendor: 0x8087 Can't get iManufacturer string idProduct: 0x0020 Can't get iProduct string [31m NOT a CCID/ICCD device [0mParsing USB bus/device: 1D6B:0002 (bus 1, device 1) idVendor: 0x1D6B iManufacturer: [34mLinux 3.12-1-686-pae ehci_hcd [0m idProduct: 0x0002 iProduct: [34mEHCI Host Controller [0m[31m NOT a CCID/ICCD device [0m idVendor: 0x0529 iManufacturer: Aladdin idProduct: 0x0620 iProduct: Token JC bcdDevice: 1.00 (firmware release?) bLength: 9 bDescriptorType: 4 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 3 bulk-IN, bulk-OUT and Interrupt-IN bInterfaceClass: 0x0B [Chip Card Interface Device Class (CCID)] bInterfaceSubClass: 0 bInterfaceProtocol: 0 bulk transfer, optional interrupt-IN (CCID) iInterface: Main Interface CCID Class Descriptor bLength: 0x36 bDescriptorType: 0x21 bcdCCID: 1.10 bMaxSlotIndex: 0x00 bVoltageSupport: 0x07 5.0V 3.0V 1.8V dwProtocols: 0x 0x0003 T=0 T=1 dwDefaultClock: 4.000 MHz dwMaximumClock: 4.000 MHz bNumClockSupported: 0 (will use whatever is returned) IFD does not support GET CLOCK FREQUENCIES request: Resource temporarily unavailable dwDataRate: 10752 bps dwMaxDataRate: 10752 bps bNumDataRatesSupported: 0 (will use whatever is returned) IFD does not support GET_DATA_RATES request: Resource temporarily unavailable dwMaxIFSD: 49 dwSynchProtocols: 0x dwMechanical: 0x No special characteristics dwFeatures: 0x0001023C 04 Automatic activation of ICC on inserting 08 Automatic ICC voltage selection 10 Automatic ICC clock frequency change according to parameters 20 Automatic baud rate change according to frequency and Fi, Di params ..02.. NAD value other than 00 accepted (T=1) 01 TPDU level exchange dwMaxCCIDMessageLength: 271 bytes bClassGetResponse: 0x00 bClassEnvelope: 0x00 wLcdLayout: 0x bPINSupport: 0x00 bMaxCCIDBusySlots: 1 Parsing USB bus/device: 05C6:9205 (bus 2, device 5) idVendor: 0x05C6 iManufacturer: [34mQualcomm Incorporated [0m idProduct: 0x9205 iProduct: [34mQualcomm Gobi 2000 [0m[32m Found a CCID/ICCD device at interface 0 [0mCan't claim interface (bus 2, device 5): Device or resource busy [01;31m Please, stop pcscd and retry [0mParsing USB bus/device: 0529:0620 (bus 2, device 9) idVendor: 0x0529 iManufacturer: [34mAladdin [0m idProduct: 0x0620 iProduct: [34mToken JC [0m[32m Found a CCID/ICCD device at interface 0 [0mParsing USB bus/device: 8087:0020 (bus 2, device 2) idVendor: 0x8087 Can't get iManufacturer string idProduct: 0x0020 Can't get
Bug#727708: On diversity
Have you think in having a Systemd team in Debian taking care of providing support for its packages? That way, people should be able to run it in some weeks and, as soon as existing init.d files are not dropped, people won't lose support for that (apart of the cases like GNOME that needs systemd running to work better) That is the way we went on Gentoo and looks to work well: we started from openRC only setup, when we needed better systemd support along our portage tree due Gnome 3.8 requirements, we (Gentoo systemd team) started to work in adding systemd support and unit files to our packages, that way, our maintainers weren't forced to run systemd to test their unit files work fine and test both systems themselves. We now have a working Systemd setup and, for our BSD ports, people still have openRC support (even not being able to run all features of GNOME but... much more cannot be done on that since http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml isn't enough to not lose any features since 3.8) From my perspective, I would support both setups: systemd (due it being required by more upstreams along the time, and, *in my personal opinion*, I think it works pretty well) and another one for BSDs and people hating so much Systemd (I would choose openRC... but since I come from Gentoo and know about it more than about upstart... ;)) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: Thoughts on Init System Debate
Hi Don, On Fri, Jan 17, 2014 at 08:41:32PM -0800, Don Armstrong wrote: Systemd's socket-based activation and cgroup based tracking are technically superior to upstart, even though the latter causes problems with portability to non-linux systems. However, if we were to decide on upstart, we could have just a single init system everywhere, which would be beneficial.[3] snip I should point out that I have not extensively examined openrc, nor have I taken into account planned features and development in either systemd or upstart which could sway my opinion. As you say that planned features or development could sway your opinion: are there particular features that you have in mind, here? For instance, correcting upstart's socket-based activation interface is on the upstart roadmap in the jessie timeframe. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#730100: autopkgtest still present [was: Bug#730100 closed by D Haley my...@gmx.com (Bug#730100: fixed in 3depict 0.0.15-1)]
found 730100 0.0.15-1 user autopkgtest-de...@lists.alioth.debian.org usertag 730100 autopkgtest thanks Debian Bug Tracking System [2013-12-13 21:21 +]: * Remove unit tests (Closes: #730100) I guess that was supposed to say autopkgtest? Anyway, 0.0.15-1 still has the XS-Testsuite: header in debian/control and the debian/tests/control script which merely checks the source tree. Please either drop XS-Testsuite: or fix debian/tests/ to actually test the installed package. This can be a simple smoke test that the program works at all, to ensure it's compiled/linked alright and that its dependencies are sufficient. Thank you, 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#727708: On diversity
]] Steve Langasek GNOME certainly uses these interfaces already. Whether they should be considered a dependency or not is probably something that should be left to the maintainers' discretion. But I think they should certainly be handled the same way as logind, generally - with a dependency on some virtual package that other implementations could provide (or that can be provided by a binary package from systemd source that doesn't depend on pid 1 - since these dbus services all work fine on non-systemd systems, and there's no technical reason that should ever change given the function of the services in question). I'm willing to look at adding virtual packages for those once we actually see alternative implementations happening. Adding them because somebody might, maybe, possibly add them somewhere down the line sounds premature. As for whether they should work with non-pid1 or not, it's also a question about what we (the systemd maintainers) want to support. The daemons currently don't require systemd as pid1, but given all the flak over maybe making logind require systemd as pid1 there is a very strong incentive to not make those implementations work with another init. The CTTE here and in the past (see NM) views regressions as much more serious than lacking implementations. I think this is pretty sad and gives maintainers perverse incentives, since there's not really any graceful way to say «this will no longer be/is no longer supported» without risking being struck down. It's a somewhat separate discussion from the whole «what should be the default init system» discussion, but it's one we (as a project) should be having at some point. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733087: [LCFC] templates://apt-cacher-ng/{apt-cacher-ng.templates}
On Mon, 20 Jan 2014 07:57:48 +0100 Christian PERRIER wrote: If this field is left empty, apt-cacher-ng wille listen on all interfaces, with all supported protocols. s/wille/will/ -- victory no need to CC me :-) http://userscripts.org/scripts/show/102724 0.0.1.4 http://userscripts.org/scripts/show/163846 0.0.1 http://userscripts.org/scripts/show/163848 0.0.1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736122: [Pkg-libvirt-maintainers] Bug#736122: virtinst: Installing debian fails with AttributeError: 'virStream' object has no attribute 'upload'
Hi Sami, On Mon, Jan 20, 2014 at 12:30:27AM +0200, Sami Liedes wrote: Package: virtinst Version: 0.600.4-2 Severity: normal Installing Debian from an URL like that suggested by the man page (but with .us. replaced with .fi.) fails with the error mentioned in the subject. I also tried with virtinst from experimental (however this run is from the unstable version). This seems to be caused by a change in the python bindings. The attached patch fixes this but afterwards sending data over the stream fails for me. I'll need to check this in more detail. Cheers, -- Guido From 4a9bdf51a99807949a52773a2c0c034187fc9955 Mon Sep 17 00:00:00 2001 Message-Id: 4a9bdf51a99807949a52773a2c0c034187fc9955.1390204086.git@sigxcpu.org From: =?UTF-8?q?Guido=20G=C3=BCnther?= a...@sigxcpu.org Date: Mon, 20 Jan 2014 08:25:27 +0100 Subject: [virt-manager PATCH] Use vol.upload(stream, ...) instead of stream.upload(vol, ...) Libvirt-python's commit 9bc81a156d281294b79192d04a5db10997566299 removed the incorrectly generated methods. --- virtinst/distroinstaller.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/virtinst/distroinstaller.py b/virtinst/distroinstaller.py index 1641f15..13ceb6b 100644 --- a/virtinst/distroinstaller.py +++ b/virtinst/distroinstaller.py @@ -130,7 +130,7 @@ def _upload_file(conn, meter, destpool, src): offset = 0 length = size flags = 0 -stream.upload(vol, offset, length, flags) +vol.upload(stream, offset, length, flags) # Open source file fileobj = file(src, r) -- 1.8.5.2
Bug#690328: All links in documentation's index.html are broken
Control: tags -1 + moreinfo Le 12/10/2012 19:44, Ryan Kavanagh a écrit : All of the links (well, the dozen or so I've tried to follow, excluding the alphabetical ones at the very top) in /usr/share/doc/libssreflect-coq/html/index.html are broken. Is that still true? I just tried with 1.5~rc1-2 and I couldn't find broken links. Maybe it was just fixed meanwhile... Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736130: linux-image-3.12-1-powerpc64 crashes during shutdown of PowerPC G5 Mac. But PowerPC g4 Mac (23-bit) works OK.
On Jan 19, 2014, at 7:41 PM, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2014-01-19 at 19:23 -0800, Rick Thomas wrote: Thanks, Ben, for the very quick response! I'd love to do that. But I don't have a serial console for this machine (no serial port -- it's a PowerMac MacPro G5, 64-bit CPU) and the messages logged at crash time scroll off the screen too fast for me to copy them down (or even photograph). I'll make a photograph of the last screen's worth of messages and send that to the bug, if you think that will help. It might do. OK. That's worth a try then. Do you know of any way to get more information than that? I'd really like to help get this bug fixed (I've got plans for this machine but I can't go forward with them until I can reboot it reliably) You might also be able to use netconsole https://www.kernel.org/doc/Documentation/networking/netconsole.txt. I'll read up and see if I can make it work for this case. Does it help any that the G4 (32-bit CPU) sitting right beside it, running an identical software setup, reboots just fine? I have no idea what the differences could be. Unfortunately there are no kernel maintainers for powerpc in Debian so all I can do is prompt for useful information and then refer you upstream. Thanks! for helping any way you can… Ben. Rick -- Ben Hutchings One of the nice things about standards is that there are so many of them. Words to live by! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
