Bug#347567: console-data: euro sign doesn't work on vt's
Package: console-data Version: 2002.12.04dbs-52 Severity: normal Hi. When I'm on a real virtual console (not an X emulation or so) the euro-sign doesn't appear when I press AltGr+e, but the sign that appears is (I thin) the international currency sign. Pressing AltGr+c leads to the cent-sign, which is correct. vt-is-UTF8 says that my vt is in UTF8 mode. kbd_mode says that my keyboard is in UTF8 mode, too. You can see my console-configuration below. As you can see, I'm using my own locale. I have it attaced at the end. btw: Can you point me to a good ressource where everything about locales/charsets/keyboardmodes/etc is explained. -I mean introductory things about how charmaps/keyboardsettings/locales relate to each other, and how to properly create them. And epecially for locales, how to properly include new locales in a Debian system. Currently I've done the following: copied my locale file to /usr/share/i18n/locales and added the name to /etc/local.gen (as dpkg-reconfigure locale doesn't show me my own locale). But there are lots of other questions left, like: -is everything in X, on plain VTs UTF8 (charmaps/keyboard modes, etc.) -is my locale file set up correctly -and correctly integradet to debian (which it is obviously not, as dpkg-reconfigure doesn't recognize it) -What's the different betwenn libc locales and X locales and is the stuff I did for both? (-> At least X always complain that: "Warning: locale not supported by Xlib, locale set to C". And what are the different locale.alias files for (one in /etc and also in some other locations). Lots of thanks, Chris. - [EMAIL PROTECTED]:~$ cat /usr/share/i18n/locales/[EMAIL PROTECTED] escape_char / comment_char % LC_IDENTIFICATION title "scientia.net default locale" source "scientia.net" address "" contact "Christoph Anton Mitterer" email "[EMAIL PROTECTED]" tel "" fax "" language"eng" territory "DE" revision"1.0" date"2005-05-29" category"[EMAIL PROTECTED]:2000";LC_IDENTIFICATION category"[EMAIL PROTECTED]:2000";LC_CTYPE category"[EMAIL PROTECTED]:2000";LC_COLLATE category"[EMAIL PROTECTED]:2000";LC_TIME category"[EMAIL PROTECTED]:2000";LC_NUMERIC category"[EMAIL PROTECTED]:2000";LC_MONETARY category"[EMAIL PROTECTED]:2000";LC_MESSAGES category"[EMAIL PROTECTED]:2000";LC_PAPER category"[EMAIL PROTECTED]:2000";LC_NAME category"[EMAIL PROTECTED]:2000";LC_ADDRESS category"[EMAIL PROTECTED]:2000";LC_TELEPHONE END LC_IDENTIFICATION LC_CTYPE copy"i18n" END LC_CTYPE LC_COLLATE %copy "i18n" copy"iso14651_t1" END LC_COLLATE LC_MONETARY int_curr_symbol "" currency_symbol "" mon_decimal_point "" mon_thousands_sep "" mon_grouping3;3 positive_sign "" negative_sign "" int_frac_digits 2 frac_digits 2 p_cs_precedes 1 p_sep_by_space 1 n_cs_precedes 1 n_sep_by_space 1 p_sign_posn 1 n_sign_posn 1 END LC_MONETARY LC_NUMERIC copy"i18n" END LC_NUMERIC LC_TIME abday "";"";"";"";"";"";"" day "";"";"";"";"";"";"" week7;19971201;4 abmon "";"";"";"";"";"";"";"";"";"";"";"" mon "";"";"";"";"";"";"";"";"";"";"";"" am_pm "";"" d_t_fmt "" d_fmt "" t_fmt "" t_fmt_ampm "" date_fmt "" END LC_TIME LC_MESSAGES yesexpr "" noexpr "" END LC_MESSAGES LC_PAPER copy"i18n" END LC_PAPER LC_NAME name_fmt "" name_miss "" name_mr "" name_mrs"" name_ms "" END LC_NAME LC_ADDRESS postal_fmt "" country_name "" cou
Bug#347568: console-data: euro sign doesn't work on vt's
Subject: console-data: euro sign doesn't work on vt's Package: console-data Version: 2002.12.04dbs-52 Severity: normal *** Please type your report below this line *** Hi. When I'm on a real virtual console (not an X emulation or so) the euro-sign doesn't appear when I press AltGr+e, but the sign that appears is (I thin) the international currency sign. Pressing AltGr+c leads to the cent-sign, which is correct. vt-is-UTF8 says that my vt is in UTF8 mode. kbd_mode says that my keyboard is in UTF8 mode, too. You can see my console-configuration below. As you can see, I'm using my own locale. I have it attaced at the end. btw: Can you point me to a good ressource where everything about locales/charsets/keyboardmodes/etc is explained. -I mean introductory things about how charmaps/keyboardsettings/locales relate to each other, and how to properly create them. And epecially for locales, how to properly include new locales in a Debian system. Currently I've done the following: copied my locale file to /usr/share/i18n/locales and added the name to /etc/local.gen (as dpkg-reconfigure locale doesn't show me my own locale). But there are lots of other questions left, like: -is everything in X, on plain VTs UTF8 (charmaps/keyboard modes, etc.) -is my locale file set up correctly -and correctly integradet to debian (which it is obviously not, as dpkg-reconfigure doesn't recognize it) -What's the different betwenn libc locales and X locales and is the stuff I did for both? (-> At least X always complain that: "Warning: locale not supported by Xlib, locale set to C". And what are the different locale.alias files for (one in /etc and also in some other locations). Lots of thanks, Chris. - [EMAIL PROTECTED]:~$ cat /usr/share/i18n/locales/[EMAIL PROTECTED] escape_char / comment_char % LC_IDENTIFICATION title "scientia.net default locale" source "scientia.net" address "" contact "Christoph Anton Mitterer" email "[EMAIL PROTECTED]" tel "" fax "" language"eng" territory "DE" revision"1.0" date"2005-05-29" category"[EMAIL PROTECTED]:2000";LC_IDENTIFICATION category"[EMAIL PROTECTED]:2000";LC_CTYPE category"[EMAIL PROTECTED]:2000";LC_COLLATE category"[EMAIL PROTECTED]:2000";LC_TIME category"[EMAIL PROTECTED]:2000";LC_NUMERIC category"[EMAIL PROTECTED]:2000";LC_MONETARY category"[EMAIL PROTECTED]:2000";LC_MESSAGES category"[EMAIL PROTECTED]:2000";LC_PAPER category"[EMAIL PROTECTED]:2000";LC_NAME category"[EMAIL PROTECTED]:2000";LC_ADDRESS category"[EMAIL PROTECTED]:2000";LC_TELEPHONE END LC_IDENTIFICATION LC_CTYPE copy"i18n" END LC_CTYPE LC_COLLATE %copy "i18n" copy"iso14651_t1" END LC_COLLATE LC_MONETARY int_curr_symbol "" currency_symbol "" mon_decimal_point "" mon_thousands_sep "" mon_grouping3;3 positive_sign "" negative_sign "" int_frac_digits 2 frac_digits 2 p_cs_precedes 1 p_sep_by_space 1 n_cs_precedes 1 n_sep_by_space 1 p_sign_posn 1 n_sign_posn 1 END LC_MONETARY LC_NUMERIC copy"i18n" END LC_NUMERIC LC_TIME abday "";"";"";"";"";"";"" day "";"";"";"";"";"";"" week7;19971201;4 abmon "";"";"";"";"";"";"";"";"";"";"";"" mon "";"";"";"";"";"";"";"";"";"";"";"" am_pm "";"" d_t_fmt "" d_fmt "" t_fmt "" t_fmt_ampm "" date_fmt "" END LC_TIME LC_MESSAGES yesexpr "" noexpr "" END LC_MESSAGES LC_PAPER copy"i18n" END LC_PAPER LC_NAME name_fmt "" name_miss "" name_mr "" name_mrs"" n
Bug#347576: java-package: support for Java Cryptography Extension (JCE)
Package: java-package Version: 0.27 Severity: wishlist Hi. First of all, great tool :-) However. Would it be possible to support Suns "Java Cryptography Extension (JCE) - Unlimited Strength Jurisdiction Policy Files 5.0"? btw: What's the state on the other (very old) wishlist topics like binfmt support, are these bugs/whishes dead? Best wishes, Chris. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages java-package depends on: ii coreutils 5.93-5 The GNU core utilities ii debhelper 5.0.12 helper programs for debian/rules ii fakeroot 1.5.6 Gives a fake root environment ii unzip 5.52-6 De-archiver for .zip files java-package recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347684: aptitude: should be move to wishlist
Followup-For: Bug #258682 Package: aptitude Version: 0.4.1-1 I'd like to see that feature too, but this is not a bug I think. The report should be moved. btw: Is this feature going to be implemented? Chris. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-6-3.1 0.6.43.1 Advanced front-end for dpkg ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-6 GCC support library ii libncursesw5 5.5-1 Shared libraries for terminal hand ii libsigc++-2.0-0c2a2.0.16-2 type-safe Signal Framework for C++ ii libstdc++64.0.2-6The GNU Standard C++ Library v3 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.4.1-1English manual for aptitude, a ter -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345340: esound: esd crashes gnome at startup and sometimes the whole system
Package: esound Version: 0.2.36-1 Severity: normal *** Please type your report below this line *** Hi. I'm using Debian sid and currently GNOME 2.12 from experimental (but exactly the same happened with unstable GNOME). What I describe here happens for me since the introduction of esd 0.2.36-1 packages (when we moved away from 0.2.35-2). As you can see I'm using alsa, and all the other esd related stuff (esound-common /-clients and libesd-alsa0 is also at its newest version). I've also tried the whole thing with different soundcards, and different user accounts (including a newely created on) so the problem should not be in my GNOME configuration. When I start up GNOME with the current version of esd, it hangs after esd is started. This doesn't change until I kill X (/etc/init.d/gdm restart). Even when I kill esd it still hangs. Sometimes it even kills the whole system If I downgrade to 0.2.35-2 (it works again if I only downgrade esound- package) and I do a restart while. If you need further material please ask. Any ideas? Chris -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.5 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages esound depends on: ii esound-common 0.2.36-1 Enlightened Sound Daemon - Common ii libaudiofile0 0.2.6-6Open-source version of SGI's audio ii libc6 2.3.5-9GNU C Library: Shared libraries an ii libesd-alsa0 [libesd0]0.2.36-1 Enlightened Sound Daemon (ALSA) - ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra esound recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343286: Same problem
Hi. As I've described in bug #345340 I have the same problem. This bugs may be merged,... There are though some minor differences, so please se my report too (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345340). Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345392: mldonkey-server: Update to version 2.7.1-2 fails
Package: mldonkey-server
Version: 2.7.1-2
Severity: normal
*** Please type your report below this line ***
Hi, when dpkg tries to configure, the following error appears:
Setting up mldonkey-server (2.7.1-2) ...
Fatal error: exception Failure("lexing: empty token")
Fatal error: exception Failure("lexing: empty token")
Fatal error: exception Failure("lexing: empty token")
Unable to parse option to set
Last word seen : =
Position : 256-257
Fatal error: exception Parsing.Parse_error
dpkg: error processing mldonkey-server (--configure):
subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
mldonkey-server
Any ideas? If you neet further information, please ask.
Chris.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.5
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)
Versions of packages mldonkey-server depends on:
ii adduser 3.80Add and remove users and groups
ii debconf [debconf-2.0]1.4.66 Debian configuration
management sy
ii dpkg 1.13.11.0.1 package maintenance system
for Deb
ii libbz2-1.0 1.0.2-11high-quality block-sorting
file co
ii libc62.3.5-9 GNU C Library: Shared
libraries an
ii libfreetype6 2.1.10-1FreeType 2 font engine,
shared lib
ii libgcc1 1:4.0.2-5 GCC support library
ii libgd2-xpm 2.0.33-3GD Graphics Library version 2
ii libjpeg626b-11 The Independent JPEG
Group's JPEG
ii libpng12-0 1.2.8rel-5 PNG library - runtime
ii libstdc++6 4.0.2-5 The GNU Standard C++ Library v3
ii mime-support 3.35-1 MIME files 'mime.types' &
'mailcap
ii ucf 2.004 Update Configuration File:
preserv
ii zlib1g 1:1.2.3-9 compression library - runtime
mldonkey-server recommends no packages.
-- debconf information:
* mldonkey-server/max_hard_download_rate:
* mldonkey-server/launch_at_startup: true
mldonkey-server/config_exist_no_options:
* mldonkey-server/plugin: Directconnect, Opennap, Overnet, Soulseek,
Bittorent, Gnutella
* mldonkey-server/mldonkey_group: mldonkey
mldonkey-server/false_password:
* mldonkey-server/max_hard_upload_rate:
* mldonkey-server/max_alive: 24
* mldonkey-server/run_as_user: mldonkey
mldonkey-server/reown_file: false
* mldonkey-server/mldonkey_niceness: 10
mldonkey-server/config_exist_no_dir:
mldonkey-server/fasttrack_problem:
mldonkey-server/shared_directories: share
* mldonkey-server/mldonkey_dir: /srv/mldonkey
* mldonkey-server/restart_after_upgrade: true
* mldonkey-server/client_name:
mldonkey-server/mldonkey_move: false
* mldonkey-server/mldonkey_umask: 0027
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
Package: kernel Severity: critical Justification: causes serious data loss Hi everybody. I'm currently (together with others) investigating in a severe data corruption problem that at least many users might suffer from. A short description, when you validate lots of GBs over and over with md5sums (or another hash) there are errors found. We do not yet know the real reson for the problems but it might relate to Opteron (and perhaps Athlon) CPUs and/or Nvidia chipsets (mainboard). So it might be a hardware design error (but even a kernel error could be possible). This is definitely not a single hardware issue of my system as many other users on lkml reported the problem (and we all did very extensive hardware tests). The error occurs only if on has so much memory that the system uses memory mapping (and the hardware iommu). At lkml we currently found two "solutions" (I consider them more workarounds, as we don't know exactly why they're solving the problem): 1) Disabling memory hole mapping in the system BIOS. The downside is that there is no memory hole mapping at all, and the users looses much of his main memory (in my case 1,5 GB) 2) Setting iommu=soft. The users keeps it full memory, and in all our tests (at least as far as I am informed), and we do very much tests as I and someone else administer some big linux clusters,... the error did _not_ occur. Windows users do generally not suffer from this corruption, as Windows (at least until Vista) was not able to make use of the hardware iommu, and always uses the software iommu. The Intel CPUs with EMT64/Intel64 don't suffer from that problem either, as they don't have an hwiommu, too (at least as far as I know). We are not yet sure if this is a large scale problem or affects only some special hardware combinations. We do however think that the issue occurs only with PCI-DMA accesses. (Tests showed, that when disabling dma or at least using slower dma modes on the disks, the issue disappeared). The problem is vendors (at least Nvidia) does not help very much, they even didn't answer my mails. And most "normal" users won't recognise this problem, as they don't have enought main memory and even it they have the error occurs very rarely (perhaps some 100 bytes every 30 GB <- only a very imprecise scale). What I suggest know: As this is a very grave I suggest - to configure all the default kernels for etch that may be affected (as far as I know that are the amd64-k8 and amd64-generic kernels. Perhaps the i386 packages too, have a look at lkml for this) to use iommu=soft. - to update all packages in sarge and woody (as far as they might be affected) - put some warnings in the packages where users might configure their own kernel and the boot-loaders. Have a look at this thread at lkml http://marc.theaimsgroup.com/?t=11650212181&r=1&w=2 for in-depth information. It also contains links to some previous threads. There are also some posts to lkml about this topics in separate threads (e.g. "amd64 iommu causing corruption? (was Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!)"). Best wishes, Chris. btw: please CC me as I'm off-list at the moment. PS: I'll also write this the debian-kernel mailinglist. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Bug#397248: memtest86+: program freezes during execution without any errors
Subject: memtest86+: program freezes during execution without any errors Package: memtest86+ Version: 1.65-1 Severity: important Hi. I have the following problem: During execution of memtest86+ it randomly freezes after some time, meaning the system totally hangs nothing works than power off/on. My harware is the following: Mainboard: Tyan S2895 CPU: 2x DualCore Opteron 275 (note that these CPUs have an integratet memory controller, thus memory is directly connected to the CPU and not via the Northbridge) RAM: 4x Kingston ValueRAM ECC/Reg 1GB (on each NUMA node 2 GB) The Chipsets of the mainboard are the following: -Nvidia nForce Professional 2200 -Nvidia nForce Professional 2050 -AMD 8131 Please note I'm pretty sure that the memory and CPU is ok: - I run a gimps/mprime torture test on all 4 cores for about 16 hours with no problems at all (all computet results were ok). - Most of the time,.. the program freezes after some successfully completet passes (so e.g. 3 passes without any error,.. but then a freeze) Ok: The Debian version reports me the following: Chipset AMD8000 (which is not what I have, I think), ECC Detect/Correct, DDR401 (this is not a typo,.. it says 401) For the test settings ECC is set to _on_ I've seen that this was maybe introduced due to a patch in Version 1.60-2 (see bug #303049, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=303049). So I've tried the original version from memtest86+ 1.65 (http://www.memtest.org/) With this version I have not had any freezes until now,.. and my longest running time was about 6 hours with 5 completet passes. (I'm going to make an even longer test with more passes tomorrow.) This version reports the following: Chipset nforce 4 (which is not nforce professional AND different from what the Debian version detects), ECC Detect/Correct, DDR401 (this is not a typo,.. it says 401) For the test settings ECC is set to _off_ (the Debian version sets this to on per default). Any ideas? You may also have at a look at my bugreport in the memtest86+ forum at: http://forum.x86-secret.com/showthread.php?t=5242 Best wishes, Chris. PS: Do not hesitate to ask for further help/information. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -- no debconf information begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Bug#404148: i'm not convinced release notes are enough
Steve Langasek wrote: >> In all doing respect, I think that it's a much greater risk to not use >> iommu=soft per default than doing so. Even if we imagine that there >> would by systems that don't work with the sw-iommu it's likely that >> they simply break (at boot time). And then the affected user at least >> knows that something is happening to him, while with no iommu=soft he >> would probably never realize that he has problems. >> > That doesn't address how to set iommu=soft as a default, though. The only > practical way that I see to accomplish this is in the kernel package itself, > and there was doubt that there would be an opportunity to update the kernel > again before release. > One possibility would be too add it per default to the grub and lilo configs, perhaps with a pointer to this bug. This way every users could simply decide wheter to remove this or not. >> So such a patch would have to whitelist systems that are known to work, >> instead of blacklist the others. >> > But AIUI the problem has so far only been reported on systems using an > nvidia chipset, right? Yes (and perhaps no). First of all there were some people who had and Opteron and an Nvidia chipset and that much main memory etc etc. (I mean a system configuration where "we" would have supposed that they would suffer from the error) but they at least claimed to not suffer from it. Perhaps some BIOSes might somewho workaround (not solve) it. Another issue is the following: Just today someone added to the bugzilla.kernel.org bug that he probably has the same error but his system doesn't have an Nvidia chipset (see http://bugzilla.kernel.org/show_bug.cgi?id=7768). Anyway I don't believe that this is actually the same error. > I'm not going to hold up as release-critical a > bugfix for other systems where the problem hasn't been reported yet. If > more information becomes available showing that the bug exists on non-nvidia > systems, we should of course revisit it at that point. > see above > In the meantime, I don't see any reason why we shouldn't patch the kernel to > disable hw iommu on nvidia systems only. I believe the attached patch > should do this. Are you in a position to confirm that this does disable hw > iommu for you? > Unfortunately I'm not currently able to validate it, but I will forward it to the thread at lkml and to the bug at kernel.org. begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Bug#337384: Add PgSQL support to bugzilla
Is there anything going to happen in this issue? When will we get pgsql support? Best wishes, Chris. begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Hi Steve. As I've told you in my email before I just tested your patch with the following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from testing, of course on an amd64 system): - The patch applies without problems - The kernel compiles with it without problems (at least with my config) - It boots correctly - and it automatically disables the hardware iommu (look at my dmesg below): Bootdata ok (command line is root=/dev/sda1 ro snd-ice1724.index=0 snd-intel8x0.index=1 ) Linux version 2.6.18debtest (Version:) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP PREEMPT Sat Mar 31 00:42:51 CEST 2007 BIOS-provided physical RAM map: Normal zone: 387840 pages, LIFO batch:31 Nvidia board detected. Ignoring ACPI timer override. Looks like an nvidia chipset. Disabling HW IOMMU. Override with "iommu=allowed" ACPI: PM-Timer IO Port: 0x8008 CPU 0: aperture @ ac00 size 64 MB CPU 1: aperture @ ac00 size 64 MB PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing software IO TLB between 0x165 - 0x565 Memory: 4036552k/5767168k available (3007k kernel code, 156324k reserved, 1245k data, 216k init) Calibrating delay using timer specific routine.. 4422.28 BogoMIPS (lpj=2211140) Security Framework v1.0.0 initialized So you see later on the kernel correctly reports to use the swiotlb. I would say (although I'm by any means not kernel expert) that your patch looks good and I _strongly_ recommend to include it in etch r0 (!!)... You're the release manager,... so you should get managed this :-) But I would say that you should add some notes to the release notes. btw: I've CC'ed the mail to Andy so if you don't have time to do this he might... uh and for Andy: have you already signed the etch release key and did you have found some time to sign my personal key I gave you on the last Stammtisch?! Best wishes, Chris. begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Steve Langasek wrote: > But regardless, there are no plans > for another kernel update before etch r0, and including one is likely to > delay the release. I'm of the opinion that this bug does not justify a > delay at this point. > Uhm, sad to hear this... > With the consent of the kernel team and the stable release managers, I'm > happy to commit this patch to the queue for the next kernel update though, > so it can be included in etch r1. > k,... perhaps we will have a real solution in the meantime. It seems like AMD makes some progress. >> But I would say that you should add some notes to the release notes. >> > Yes, that's now bug #416374, which includes a suggested text. k,.. at least something ;-) Best wishes, Chris. begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Andreas Barth wrote: > BTW, we intended to have frequent kernel uploads to proposed-updates, > and frankly speaking, I personally don't mind to already have a newer > kernel in proposed-updates during the release, but that's something I > want to have signed-off by Martin. The main problem with the whole release-notes-only-issue is,... that data corruption might already occur during installation. So even if the user reads the release notes (I assume this happens mostly (if at all) after installation) he might already have some corruptions. Chris. begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
Steve Langasek wrote: > Well, there's no reason that someone can't use iommu=soft when booting the > installer, as well. So perhaps it would be best to clone that bug and > include this information in the installation guide or errata? > Yes that's a good idea. I assume it would be also a problem, too just set the installer to iomm=soft (e.g. via the bootloader)? One last thing perhaps. I'd include a link to the kernel.org bug report in your release notes text and maybe some information that systems might already have some data corruption (as this bug is not new). btw: Is the kernel team now aware of your patch and will it use it in following linux-* packages? i.e. in unstable? Best wishes, Chris. begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Bug#404148: i'm not convinced release notes are enough
Hi. Sorry that I've ignored the last answers to the bug but I somehow missed the mail. First of all,.. there is still no other solution than iommu=soft (at least as of my knowledge) and we had even someone on the bugreport at bugzilla.kernel.org who claimed that _only_ iommu=soft helped, but not BIOS memhole mapping = disabled. > AIUI the bug triggers on systems with memory in excess of 5GB. Limited to > server-class hardware. I hope server admins are aware of the contents of > release notes. > I don't think that you can rely on this. And even if so. Some could probably just ignore it because their "small" tests don't show an corruption and people might think they're on the safe side. >> what is the performance impact of using the safe option on all hardware >> even that not affected by this bug? would using that option by default >> result in a noticable performance degrdation? >> > It's unknown to me whether all other currently-supported systems even *work* > if iommu=soft is set. As far as I know,.. everything should. For example Intel CPUs don't have an IOMMU at all,... Windows uses always a kind of software iommu (even on AMD CPUs). > This is not the time to gamble with the kernel. > In all doing respect, I think that it's a much greater risk to not use iommu=soft per default than doing so. Even if we imagine that there would by systems that don't work with the sw-iommu it's likely that they simply break (at boot time). And then the affected user at least knows that something is happening to him, while with no iommu=soft he would probably never realize that he has problems. > If a targetted patch is available that sets iommu=soft for the chipset in > question, I think this will never happen. The problem is simply: Kernel developers cannot tell which chipsets are affected, or which chipset/CPU combinations. We even don't know yet where the error comes from (CPU or nvidia chipset). According to Andi Kleen this is still being investiagted by nvidia and AMD. So such a patch would have to whitelist systems that are known to work, instead of blacklist the others. > that would be a good candidate for the next kernel upload, which > may or may not make it into r0. But if no one has a good fix to offer, I > think we need to settle for documenting it as errata given that upstream > doesn't have a proper fix for this yet Let me qoute Andi Kleen: "Unless a good workaround comes around soon I'll probably default to iommu=soft on Nvidia." You see that even he thinks about using iommu=soft as default (on nvidia). And until such a patch is available I think the saftest would be to use it as a general default on amd64. Perhaps Debians kernel team could even maintain their own patch that would activate iommu=soft only on nvidia chipsets. Best wishes, Chris. begin:vcard fn:Mitterer, Christoph Anton n:Mitterer;Christoph Anton email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Bug#394776: apt-listchanges fails with custom locale
Subject: apt-listchanges fails with custom locale Package: apt-listchanges Version: 2.70 Severity: important Hi. I'm using my own custom locale in debian. It seems that apt-listchanges doesn't support the use of custom locales. The error I get is the following: Reading changelogs... Done Traceback (most recent call last): File "/usr/bin/apt-listchanges", line 215, in ? main() File "/usr/bin/apt-listchanges", line 179, in main frontend.display_output(changes) File "/usr/share/apt-listchanges/apt_listchanges.py", line 431, in display_output tmp.write(self._render(text)) File "/usr/share/apt-listchanges/apt_listchanges.py", line 365, in _render newtext.append(uline.encode(locale.getlocale()[1] or 'ascii', 'replace')) File "/usr/lib/python2.4/locale.py", line 365, in getlocale return _parse_localename(localename) File "/usr/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: [EMAIL PROTECTED] Extracting templates from packages: 100% Any ideas? For additional information please ask me :) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages apt-listchanges depends on: ii apt 0.6.46.2 Advanced front-end for dpkg ii debconf [debconf-2.0] 1.5.6 Debian configuration management sy ii debianutils 2.17.3 Miscellaneous utilities specific t ii python2.4.3-11 An interactive high-level object-o ii python-apt0.6.19 Python interface to libapt-pkg ii python-support0.5.4 automated rebuilding support for p ii ucf 2.0015 Update Configuration File: preserv Versions of packages apt-listchanges recommends: ii ssmtp [mail-transport-agent] 2.61-10extremely simple MTA to get mail o -- debconf information: * apt-listchanges/confirm: true * apt-listchanges/which: changelogs * apt-listchanges/frontend: pager * apt-listchanges/email-address: * apt-listchanges/save-seen: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394776: apt-listchanges fails with custom locale
Pierre Habouzit wrote: > yes, what is that "custom" locale you're using ? > Uhm,.. it's only used by myself and perhaps some friends here I've attached the locale file if that helps: escape_char / comment_char % LC_IDENTIFICATION title"scientia.net default locale" source"scientia.net" address"" contact"Christoph Anton Mitterer" email"[EMAIL PROTECTED]" tel"" fax"" language"eng" territory"DE" revision"1.0" date"2005-05-29" category"[EMAIL PROTECTED]:2000";LC_IDENTIFICATION category"[EMAIL PROTECTED]:2000";LC_CTYPE category"[EMAIL PROTECTED]:2000";LC_COLLATE category"[EMAIL PROTECTED]:2000";LC_TIME category"[EMAIL PROTECTED]:2000";LC_NUMERIC category"[EMAIL PROTECTED]:2000";LC_MONETARY category"[EMAIL PROTECTED]:2000";LC_MESSAGES category"[EMAIL PROTECTED]:2000";LC_PAPER category"[EMAIL PROTECTED]:2000";LC_NAME category"[EMAIL PROTECTED]:2000";LC_ADDRESS category"[EMAIL PROTECTED]:2000";LC_TELEPHONE END LC_IDENTIFICATION LC_CTYPE copy"i18n" END LC_CTYPE LC_COLLATE %copy"i18n" copy"iso14651_t1" END LC_COLLATE LC_MONETARY int_curr_symbol"" currency_symbol"" mon_decimal_point"" mon_thousands_sep"" mon_grouping3;3 positive_sign"" negative_sign"" int_frac_digits2 frac_digits2 p_cs_precedes1 p_sep_by_space1 n_cs_precedes1 n_sep_by_space1 p_sign_posn1 n_sign_posn1 END LC_MONETARY LC_NUMERIC copy"i18n" END LC_NUMERIC LC_TIME abday "";"";"";"";"";"";"" day "";"";"";"";"";"";"" week7;19971201;4 abmon "";"";"";"";"";"";"";"";"";"";"";"" mon "";"";"";"";"";"";"";"";"";"";"";"" am_pm"";"" d_t_fmt"" d_fmt"" t_fmt"" t_fmt_ampm"" date_fmt "" END LC_TIME LC_MESSAGES yesexpr "" noexpr "" END LC_MESSAGES LC_PAPER copy"i18n" END LC_PAPER LC_NAME name_fmt "" name_miss"" name_mr"" name_mrs"" name_ms"" END LC_NAME LC_ADDRESS postal_fmt "" country_name "" country_post"" country_ab2"" country_ab3"" country_num276 country_car"" country_isbn3 lang_name"" lang_ab"" lang_term"" lang_lib"" END LC_ADDRESS LC_TELEPHONE tel_int_fmt "" tel_dom_fmt"" int_select"" int_prefix"" END LC_TELEPHONE LC_MEASUREMENT copy"i18n" END LC_MEASUREMENT Regards, Chris. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs
Hi. Now that systemd could become default in Debian (well at least I favour it over upstream)... I started wondering how well it supports booting from a root fs on top of multiple block device layers? Some time ago I wrote [0] (with some contributions from others AFAICS)... So is there any information from the side of the systemd (Debian) maintainers, how far these scenarios are supported already? Right now there is a rather fixed order in which things work (i.e. phys->MD->LVM->dm-crypt->rootfs) out of the box (well in some cases at least) and IIRC, due to some "obscure" code in the cryptsetup initramfs scripts it works also with (dm-crypt->LVM)... but ideally all this should be handled more generally... Looking over the bugs from the systemd package in Debian give quite some concern here,... many things seem to not work yet (e.g. support for cryptsetup key scripts)... and many other bugs seem to be quite old and not having been worked on for very long. There's also the issue that apparently there are subtle issues when it comes to udev rules deployed with systemd or that systemd needs in a specific way (e.g. #712439) ... where we have problems since Debian maintainers from other packages divert from the upstrem udev rules for whichever reason. Cheers, Chris. [0] https://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs
On Tue, 2013-12-31 at 11:15 -0800, Russ Allbery wrote: > For whatever it's worth, I've been using systemd on a system with LVM and > dm-crypt (with LUKS) for about a month now, in the dm-crypt -> LVM -> > filesystem mode, and haven't had any trouble. Do you use it on your root-fs? With keyscripts? > The page you linked to makes several assertions that I find curious. That > doesn't mean that they're wrong, but they seem somewhat contrary to my > experience. For example, I'm not sure where "however, for we really > should should try to avoid forcing users to use initramfs images, for > setups where they're not strictly needed" comes from; I've been using > initramfs images for every Debian system I run, and every Debian system > Stanford runs, for so long that I can't remember when we originally > changed. I don't understand why this would be something one would want to > avoid. Well so do I,.. haven't a single system which doesn't use initramfs... OTOH I'm always sceptical about "forcing" people to do so (when e.g. the kernel itself can just happily life without an initrd)... because there might be scenarios I/we can't even think of where it may make sense to run without one. After all, Debian should be the universal OS ;) > Similarly, I'm not sure why the focus on only adding necessary tools to > the initramfs image. Surely this doesn't matter much if the tools are > harmless when unneeded? Well it costs time when creating the initramfs, makes the initramfs image bigger (possibly not an advantage with embedded systems) and the useless stuff has to be decompressed every boot. Sure,... most people won't bother.. but why adding stuff that's not needed... I mean in many cases the initramfs-scripts actually run and do something, even if the respective thing (a filesystem or what ever) is not even present and that makes it more likely for problems to occur or performance to be wasted... as if such stuff isn't in place. Neither do we add libreoffice to initramfs ;-) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs
On Tue, 2013-12-31 at 21:07 +0100, Tollef Fog Heen wrote: > That's handled by the initramfs where we currently don't use systemd. > (It's supported upstream to do so and we might eventually investigate > that, but I don't believe anybody has done any work on it for Debian.) Sure... but - using systemd inside the initramfs _may_ come at a later point - even though the root-fs (and the resume-fs) is mounted in the initramfs image... it may still interfere with the boot process by systemd, e.g. when the later might accidentally try to re-setup such dm-crypt mappings or else... which were already set up in the initramfs. - all the questions, about whether systemd supports stacking of multiple block layers is also interesting for non-root-filesystems. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618862: systemd: ignores keyscript in crypttab
Oh and I forget (but it seems this is already clear as well): keyscripts may make use of arbitrary other programs... OpenSSL, pcscd, gpg, etc. pp. I've just attached my own keyscript to give an example (just the script, not the initramfs-tools hook or documentation). The biggest problem is likely stuff that requires terminal input (AFAIU systemd takes this over or at least should do so). In Debians cryptsetup, there's /lib/cryptsetup/askpass which I for example use to gather the passphrase (which is used to decrypt the OpenPGP encrypted actual key). So I guess that needs to be adapted somehow as well... either this, or properly documented how to do things in the systemd-way. And of course, any keyscripts would then need to support both,... a systemd-way of interactive input (if there is any)... and the traditional via e.g. askpass (AFAIU, the tech-ctte decision will just define a new default init,... but not forbid any others). Cheers, Chris. decrypt_openpgp Description: application/shellscript smime.p7s Description: S/MIME cryptographic signature
Bug#618862: systemd: ignores keyscript in crypttab
Hi. Had a private conversation with Tollef and he pointed me to this bug... Even though it may be obvious to any developer, let me add the following: I had a short glance at http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n54 I guess another crypt_activate_by_? function would need to be implemented for keyscripts. One thing which need to be taken into account is the following: The keyscript is an arbitrary program (no necessarily a shell script... and the key file parameter (the 3rd field in crypttab(5)) may _not_ be a pathname at all. I for example use a keyscript for openpgp encrypted keys (a different one from that shipped in Debian, which has several functionality deficiencies and following from that: security issues) where one would see lines as the following in crypttab: root /dev/disk/by-uuid/74b4564a-728e-11e3-8a8d-502690aa641f device=/dev/disk/by-uuid/0faa9776-ccbe-4834-a853-501eb3b75372:pathname=/etc/dm-crypt/keys/someHost_root loud,luks,keyscript=decrypt_openpgp,tries=0 All of this is "normal" unless the 3rd field: device=/dev/disk/by-uuid/0faa9776-ccbe-4834-a853-501eb3b75372:pathname=/etc/dm-crypt/keys/someHost_root which is given to my keyscript decrypt_openpgp It basically combines two options (separated by a colon) into the one passed to the keyscript (which splits it again)... device= being a filesystem which the keyscript should wait to appear (i.e. a USB stick)... mount it ... and pathname= being a a file local to the filesystem on that device... which is then read, fed through gpg and so on. And this is just one example where one could need multiple options put together in the keyfile field of crypttab - unfortunately the Debian maintainer refused to standardise this. Another example could be a OpenPGP crypto smart card, where one waits for a specific smart card ID to appear, and reads key number n from it. Or one can think of examples where the key is read via secured network connections (ssh, ipsec, whatever) and where multiple parameters would be required. So the point is... any support for keyscripts in systemd MUST NOT try to be smarter than it should and somehow interpreting or modifying the keyfile field. It simply MUST pass that on the the keyscript, just as the Debian cryptsetup scripts do it. And it should be noted, that the cryptsetup scripts initialise a bunch of environment variables for the executed keyscript program, which of course systemd would need to do as well. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#727708: systemd status when using multiple block device layers (MD/LVM/dm-crypt) below the root-fs
On Wed, 2014-01-01 at 05:48 +0100, Mourad De Clerck wrote: > So last time I tried, this just worked - my rootfs got mounted using a > keyscript in the initramfs, and there were no problems, not a peep from > systemd when it took over, no re-setup or anything. Sure... but that applies, AFAIU, only to the stuff mounted from within the initramfs (at most: rootfs / resume-fs). While I think that for most attack-scenarios, where on-disk-encryption makes sense (the notably exception being: coincidental theft of your device), a fully encrypted system (i.e. including the root-fs) is the only thing that makes sense... it's still necessary to support additional encrypted devices to be brought up during boot (which is AFAIU then systemd's task). I've added few thoughts to #618862, with things that IMHO are necessary to get proper keyscript support with systemd. > Stacking causes no problems in my experience. There are of course still > problems with devices that aren't mounted in the initramfs but still > need some keyscript (f.e. decrypt_derived comes to mind). Well from inside the initramfs this definitely does not work out of the box... since they initramfs-scripts expect a specific order (i.e. MDADM first, and so on... and especially the lvm scripts are kinda bogus). Not that it would make much sense to put dmcrypt below MDADM (in the meantime not even performance-wise)... security wise this might be even disastrous. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#603810: desktop-base: /etc/kde3/kdeglobals obviously dropped but still there
On Thu, 2010-11-18 at 09:50 +0100, Yves-Alexis Perez wrote: > Yeah, I'll try to do that. Thx :) > Is that really important or is it just a > useless file on the system? Yes it's just the useless thingy,... problem is for the end-users IMHO to keep track which stuff is legacy and can be deleted, if packages don't do this. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#603810: closed by Yves-Alexis Perez (Bug#603810: fixed in desktop-base 6.0.1)
Hi Yves-Alexis. On Sun, 2010-11-21 at 10:33 +, Debian Bug Tracking System wrote: > >* debian/preinst, debian/postinst, debian/postrm: > > - remove /etc/kde3/kdeglobals using dpkg-maintscript-helper closes: > > #603810 It seems that the directory /etc/kde3 itself still remains and is not removed (although it is empty. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#603432: linux-image-2.6.32-5-amd64 hangs when booted as VM under Xen
Hi. Unfortunately it turned out, that my ISP had to but that respective cluster into production now, and was therefore not longer able to play around very much. Also, the commands you've mentioned seemed to not have been available there. So I guess you might close the bug, at least from my side there's not much more I can to for debugging/tracing :-( Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#603810: closed by Yves-Alexis Perez (Bug#603810: fixed in desktop-base 6.0.1)
On Sun, 2010-11-21 at 22:03 +0100, Yves-Alexis Perez wrote: > What does: > dpkg -S /etc/kde3 nothing... I wouldn't have written if it still belongs to another package ;) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#603810: closed by Yves-Alexis Perez (Bug#603810: fixed in desktop-base 6.0.1)
On Mon, 2010-11-22 at 19:44 +0100, Yves-Alexis Perez wrote: > And the packages doesn't contain /etc/kde3 folder, so in any case it's > not in desktop-base package. Afaiui, dpkg should remove it, there's > nothing we can do here. What does it tell you at upgrade time? There was a "could not remove /etc/kde3 directory, as not empty"-like line. Perhaps you call the debhelper stuff too late, when dpkg already tried to remove it? smime.p7s Description: S/MIME cryptographic signature
Bug#603810: closed by Yves-Alexis Perez (Bug#603810: fixed in desktop-base 6.0.1)
On Mon, 22 Nov 2010 21:00:20 +0100, Yves-Alexis Perez wrote: >> There was a "could not remove /etc/kde3 directory, as not empty"-like >> line. > > And are you sure it's now empty? :) Yes... at least if rmdir hasn't started removing non-empty dirs over the weekend ;) > I don't call debhelper, I call dpkg-maintscript-helper which is the > right way to do it, see > http://raphaelhertzog.com/2010/10/07/the-right-way-to-remove-an-obsolete-conffile-in-a-debian-package/ Ah,.. I've meant dpkg-maintscript-helper ;) No idea then, why it doesn't remove it... :( Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604980: remove/disable /etc/apache2/conf.d/apache2-doc per default
Package: apache2-doc Version: 2.2.16-4 Severity: wishlist Hi. May I suggest to disable or even better remove /etc/apache2/conf.d/apache2-doc per default? I guess most people _don't_ want their servers to the apache documentation provided to the web. IMHO the file should go to some /u/s/d/apache2-doc/example directory. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595384: acpi-support-base: use consolekit to determine whether sessions are still open on powerdown/etc.
On Fri, 2010-11-26 at 11:48 +0100, Michael Meskes wrote: > I checked that and tried exactly those steps with gdm3 instead of gdm though. > Yes, the power button doesn't work anymore after loggin off, but the reason > was > not a bug in one of the scripts but gnome-power-manager which was still > running > albeit under a different user. I have no idea why this happens, but as far as > acpi-support is concerned the behaviour seems to be correct. > > Are you sure that gnome-power-manager is no longer running? That means did > you check via ps? Checked it again, and indeed it was running,.. nut sure why I haven't seen it last time (I did ps),... Nevertheless, this one is invoked by gdm3 itself, so I guess it's simply not really possible to use gnome-power-manager to check whether one is logged on or not... (it might not be installed anyway). Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#605123: apache2.2-common: "incorrect" definitions of Common Log Format and Combined Log Format
Package: apache2.2-common Version: 2.2.16-4 Severity: minor Hi. In the apache2.conf you make some predefined log-formats, including one for the Common Log Format and one for the Combined Log Format. Those are defined there using %O for the number of bytes. Most other resources I could find (e.g. Apache documentation and W3C) use %b however or defined this to be the size of the document being transmitted (therefore without the Header stuff). Althoug I personally also prefer the total raw size (and therfore %O) I'd suggest to use %b here, to be _absolutely_ compatible to everything else. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605123: apache2.2-common: "incorrect" definitions of Common Log Format and Combined Log Format
btw: This applies als to the other vhost combined version. Another reason to really use the _same_ definition of CLF as apache does is, that this format is already hardcoded in case no LogFormat Directive is given and TransferLog is used. smime.p7s Description: S/MIME cryptographic signature
Bug#605125: apache2.2-common: the last LogFormat entry in apache2.conf should be CLF
Package: apache2.2-common
Version: 2.2.16-4
Severity: wishlist
Hi.
Currently the last LogFormat in apache2.conf is (per default):
LogFormat "%{User-agent}i" agent
For the TransferLog directive, the most recent LogFormat directive
specifies the format.
So may I suggest, to put the combined definition last (which is also
what would have been hardcoded).
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605149: apache2.2-common: mod_authn_default should be enabled by default
Package: apache2.2-common Version: 2.2.16-4 Severity: wishlist Hi. IMHO, mod_authn_default should be enabled in the default config, just as mod_authz_default already is. It probides a fall-back (denying) authorisation provider. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605250: mime-support: application/rss+xml is not a registered MIME Type
Package: mime-support Version: 3.51-1 Severity: normal Hi. You list "application/rss+xml" as registered MIME type, which it is however not. Although there was an application (http://tools.ietf.org/id/draft-nottingham-rss-media-type-00.txt) this has expired since 4 years... and unofficial MIME types should only be used with the "x-". Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605251: mime-support: missing mime types
Package: mime-support Version: 3.51-1 Severity: wishlist Hi. I found that several types may be missing: - text/sgml (though this is deprecated in favour of application/sgml) - text/xml (though this is deprecated in favour of application/xml) - text/ecmascript (though this is deprecated in favour of application/ecmascript) - text/javascript (though this is deprecated in favour of application/javascript) => so one migh argue whether these should be still included... - application/atomsvc+xml (defined in the same RFC - forgot the number - as application/atomcat+xml) Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605254: mime-support: compression schemes inconsistencies
Package: mime-support Version: 3.51-1 Severity: normal Hi. In the notes you describe, that compression schemes are not erally mime types but encodings of types. I understand that you include such types when they're official (like "application/zip"). But why do you include unofficial stuff like application/x-7z-compressed 7z application/x-cab cab application/x-cpio cpio application/x-gtar gtar application/x-gtar-compressed tgz taz application/x-lha lha application/x-lzx lzx application/x-shar shar application/x-tar tar application/x-wingz wz + possibly others I didn't identify as general purpose compressing tools? I mean it's clear that for e.g. those it's ok: application/x-bittorrenttorrent application/x-debian-packagedeb udeb because even though compressed, it's about their special content. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605251: missing mime types
Hi. Ignore the application/atomsvc+xml thingy,.. it's already in ;) Cheers, Chris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605250: mime-support: application/rss+xml is not a registered MIME Type
There are other unofficial mappings, outside the "x-" namesapce, e.g. for rar. What's the policy of the mime-support package on them? IMHO all unofficials (except the "x-*"'s) should be removed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605254: mime-support: compression schemes inconsistencies
Guess I was wrong with some of the above: All of them, whose _decompressed_ data is more than just any raw data (i.e. all archives which can have multiple files, or so) can have their own (un)official mime type. Especially application/x-gtar-compressed tgz taz however not (don't know about the others). tgz and taz should be added to application/x-tar (in addition to .tar), as they're both tar archives just with an gzip/compress Content-Encoding. You already do this nicely with svgz, which is just an gzipped svg and which you map to the svg mime type. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595384: gnome-power-manager started by gdm3?
On Mon, 2010-11-29 at 11:09 +0100, Michael Meskes wrote: > > I also agree with the reporter: checking for running power managers is > > just a hack, and you should use ConsoleKit instead. But this won’t solve > > I don't see how this could be a hack. The script is not trying to findout if > somebody is logged in, it couldn't care less. All it needs to fnd out is > whether some other software is running that is supposed to handle the power > button and if so don't react on it itself. If somebody is loggedinto X but not > running a power manager the acpi-support script is supposed to take action on > pressing the power button. But this (knowing whether somebody's logged) in is what we should actually want to know. Just checking for some running process is extremely error prone (program not installed, disabled by user, process died for other reasons, etc. pp.). I agree with Josseling that ConsoleKit is the way to go, which does not mean that you have to implement it. But IMHO it's better to leave this open and wait until someone has time, than to hack a fix, just to get it closed. Best wishes, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#605250: mime-support: application/rss+xml is not a registered MIME Type
On Mon, 2010-11-29 at 22:44 +0100, Brian White wrote: > When it comes to mappings, official mappings take precedence. Beyond > that, I don't care. Mapping an extension to an unofficial type is not > worse than no mapping at all. Not sure,.. because people get used to it (and use it),... and if there should be ever a conflicting assignment one has really problems. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#605254: mime-support: compression schemes inconsistencies
On Mon, 2010-11-29 at 22:52 +0100, Brian White wrote: > If an application stores information about the original file (like > it's filename) rather than just act without thought on a data stream, > then it's more than just an encoding. Yes that's what I've meant... > > > Especially > application/x-gtar-compressed tgz taz > > however not (don't know about the others). > tgz and taz should be added to application/x-tar (in addition > to .tar), as > they're both tar archives just with an gzip/compress > Content-Encoding. > > Correct, but not so simple. Expecting a program/person to > recognize .gz and meaning gzipped is more reasonable than expecting > it/them to reliably recognize that some (but not all) extensions > ending with a "z" are also such. > > > After that, we're left with the fact that tar will not process a tgz > or taz file without an added option on the command line. Thus, it > must map to a different type to get opened in a different way. I > gather newer version of tar can recognize some file extensions but I > don't know to what degree and apparently not by analyzing the data > stream itself (which is important should the data be coming from > stdin). There's also something to be said for backwards > compatibility. Well this might be true in practise... (or better said with all programs that don't use MIME types as they should But it makes problem e.g. with Apache and in general the way how MIME types are defined to be used. The standard says that the type is really just for the content. So e.g. with apache, if I would like to have the correct: type=application/tar + encoding=gzip I need to first manually remove the mapping from /etc/mime.types. I mean I totally see your point, but IMHO these are bugs in the applications using that mime types because they lack the concept of an encoding. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#605535: apache2.2-common: a2dissite bash completion cannot cope with 000-default/default site
Package: apache2.2-common Version: 2.2.16-4 Severity: minor Hi. It seems that you've added code to a2dissite/a2ensite to nicely handle the special(?) sites "default" to be added automatically as "000-default". Both tools also provide bash-completion, but a2dissite only identifies the "000-default" site, not the "default" original name. Perhaps (but not sure whether it's really worth it) this might be added. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738927: mcelog: fails to install when CPU unsupported
Package: mcelog Version: 1.0~pre3-72-gcbd4da4-1 Severity: grave Justification: renders package unusable Hi. It seems that when the CPU is unsupported, the package fails to install/upgrade: Setting up mcelog (100-1) ... /run/udev or .udevdb or .udev presence implies active udev. Aborting MAKEDEV invocation. insserv: warning: current stop runlevel(s) (empty) of script `mcelog' overrides LSB defaults (0 1 6). Starting Machine Check Exceptions decoder: CPU is unsupported invoke-rc.d: initscript mcelog, action "start" failed. dpkg: error processing package mcelog (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: mcelog Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mcelog depends on: ii debconf [debconf-2.0] 1.5.52 ii libc6 2.17-97 ii makedev2.3.1-93 ii udev 204-7 mcelog recommends no packages. mcelog suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737587: RFP: commander-genius -- Commander Genius is a software piece that interprets the Commander Keen Invasion of the Vorticons and Galaxy series.
Package: wnpp Severity: wishlist * Package name: commander-genius Version : 1.6.5.5 Upstream Author : Gerhard Wolfgang Stein * URL : http://clonekeenplus.sourceforge.net/ * License : GPL Programming Lang: C++ Description : Commander Genius is a software piece that interprets the Commander Keen Invasion of the Vorticons and Galaxy series. This is an interpreter for the well known Commander Keen games. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722006: xserver-xorg-input-synaptics: new version breaks middle mouskey
tags 722006 + patch stop Hi. Upstream has a fix for this, could you please cherry pick commit e0069c154440305ece6def92a9813a9f8004b2fb ? http://cgit.freedesktop.org/~whot/xf86-input-synaptics/commit/?h=wip/restore-scrollbuttons&id=e0069c154440305ece6def92a9813a9f8004b2fb Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#738554: libbluray-bdj security issues
Package: libbluray-bdj Version: 1:0.5.0-2 Severity: normal Hi. AFAIU, BD-J allows BluRays to run some Java code for an "extended experience"... No even if that was sandboxed... we all know how problematic this is with respect to security and that Java has a really bad record in terms of that. In the end this probably means, that if installed, more or less arbitrary code from BluRays (especially video BluRays) may be executed. I think that at least the package description should clearly warn the user about that, since many people may not fully realise what BD-J means. And IMHO it would be even better, if libbluray-bdj was "disabled" by default, even when installed... like that any function of it simply returns an error, or that it's not loaded by libbluray unless some configuration file enables it explicitly. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738593: openssh-server: changelog mis-description, ... upgrades create ed25519 host keys as well
Package: openssh-server Version: 1:6.5p1-1 Severity: minor Hi. As far as I'd understand the changelog entry * Generate ED25519 host keys on fresh installations. Upgraders who wish to add such host keys should manually add 'HostKey /etc/ssh/ssh_host_ed25519_key' to /etc/ssh/sshd_config and run 'ssh-keygen -q -f /etc/ssh/ssh_host_ed25519_key -N "" -t ed25519'. for 1:6.5p1-1... ED25519 are not created on package upgrades but only fresh installations. This does not seem to be the case (I'm generally unsure whether I like the idea of automatically created keys... since this may also happen in low entropy situations)... anyway... perhaps that should be corrected ;-) Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738594: e2fsprogs: is missing /lost+found really that big problem?
Package: e2fsprogs Version: 1.42.9-3 Severity: wishlist Hi. I just wondered about missing /lost+found, and whether it couldn't be handled as a "non-failure" issue... Like when cheking an fs and not creating it: /dev/sdb1 was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity /lost+found not found. Create? no Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sdb1: ** WARNING: Filesystem still has errors ** that fsck, doesn't call that an error? Moreover, and it seems this might be actually a bug... when an filesystem was not cleanly unmounted and a check is forced, as in the example above, then even if no further failure was found but the /lost+found is not created, then the fs will still be marked as unclean, and a full check will be enforced when running fsck on it again. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738593: openssh-server: changelog mis-description, ... upgrades create ed25519 host keys as well
On Tue, 2014-02-11 at 11:19 +, Colin Watson wrote: > Oops, right. No real problem... I'm just a perfectionist... even regarding typos in changelogs ;) > I'll retroactively correct the changelog. (You still need > to add the HostKey entry manually on upgrades.) Actually I didn't understand that at all.. why do you need that? It seems to be that ssh looks per default at /etc/ssh/ssh_host_ed25519_key AFAIU the 6.5 release notes, ED25519, should be used per default (when client/server both support it)... but it seems the case,... the default for HostKeyAlgorithms seems to still have ECDSA first, while KexAlgorithms prefers Curve25519 now... Any idea about that? > Well, that's why I prefer to do this in the postinst rather than at boot > time as some other distributions do, as I think it's much more likely > that sufficient entropy will be available when installing packages. Sure... that's already much much better than what other distros do... but it might be still not enough in some corner cases... anyway as I said... I'm not really sure whether I'd prefer to not have that initialised at all. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#732240: qemu: please build guest agent for non-Debian platforms
Source: qemu Version: 1.7.0+dfsg-2 Severity: wishlist Hi. While there is a qemu-guest-agent package, it would be nice if there was something comparable to virtualbox-guest-additions-iso for non-Debian and/or non-Linux platforms (especially Windows). I'm not sure whether qemu itself already provides such a ISO based solution,... there is http://wiki.qemu.org/Features/GuestAgent/ISO but I have no idea about its status. Would be nice though, if there was at least a container package, which contiains built and probably statically linked versions of the guest agents for other platforms (Windows, non-Debian distros). Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602807: libvirt: Support esx hypervisor
Hey. While I hate vmware as much as possible and while I use KVM with all my own VMS the local computing centre at the university insists on vmware and I guess many people would prefer to use that over some proprietary browser plugins on their system in order to connect to the vcenter (or however it's called right now). Just enabling it wouldn't make Debian or the maintainers responsible to provide support for upstream issues... Do you fear that an enabled vmware driver causes stability issues with the other drivers supported by you guys? And even if, you could simply exclude such systems from being supported... and explicitly mention that it's just provided on an as-is basis. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#726675: gnome-settings-daemon: requires systemd
Package: gnome-settings-daemon Version: 3.8.5-2 Severity: normal Hi. gnome-settings-daemon depends on systemd now,... While I think systemd IS the future, it is not yet the default in Debian, neither does it work in all circumstances yet (AFAIK, there are e.g. still issues with dm-crypt). Of course, just installint systemd, doesn't replace sysvinit as init, nevertheless,... 1) systemd brings a lot of stuff which will get active, even when just installing it and not installing systemd-sysv. udev rules, polkit and dbus stuff and more. So the question arises, when gnome forces people now to install systemd, does this cause any side effects? And even more,... as you say you depend now on systemd, does that functionality work, when it is not actually used. So short question... couldn't systemd be made voluntary for now? Or even better: forever. Even when systemd should become default in debian, people still might want to use alternatives. A desktop environment shouldn't force users upon such low level stuff like the init- system,... what comes next? Forcing us to use a special kernel? IMHO this would be broken by design. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727073: ifupdown: current version somehow brings the ifaces up too late
Package: ifupdown Version: 0.7.45 Severity: critical Justification: breaks unrelated software Hi. Since 0.7.45 I see a problem, that many deamons fail to start during boot, since some of the configured addresses are not yet ready, See the following bootlogd snipped, where apache, and bind fail: (Nothing has been logged yet.)$ Tue Oct 22 04:16:54 2013: [] Setting parameters of disc: (none)^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:16:54 2013: [] Setting preliminary keymap...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:54 2013: [] Activating swap...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:54 2013: [] Checking root file system...fsck from util-linux 2.20.1$ Tue Oct 22 04:16:54 2013: root: clean, 168884/30195712 files, 5681928/120753152 blocks$ Tue Oct 22 04:16:55 2013: ^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:55 2013: [] Cleaning up temporary files... /tmp^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:16:55 2013: [^[[36minfo^[[39;49m] Loading kernel module fuse.$ Tue Oct 22 04:16:55 2013: [^[[36minfo^[[39;49m] Loading kernel module w83627ehf.$ Tue Oct 22 04:16:55 2013: [] Generating udev events for MD arrays...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:55 2013: [] Starting early crypto disks...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:55 2013: [] Setting up LVM Volume Groups...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:56 2013: [] Starting remaining crypto disks...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:56 2013: [] Activating lvm and md swap...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:56 2013: [] Checking file systems...fsck from util-linux 2.20.1$ Tue Oct 22 04:16:56 2013: ^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:56 2013: [] Mounting local filesystems...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:56 2013: [] Activating swapfile swap...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:56 2013: [] Cleaning up temporary files...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:16:56 2013: [] Setting kernel variables ...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:58 2013: [] Stopping authentication failure monitor: fail2ban^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:16:58 2013: [] Loading iptables rules... IPv4... IPv6...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:58 2013: [] Setting up resolvconf...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:58 2013: [] Configuring network interfaces...ifup: interface eth0 already configured$ Tue Oct 22 04:16:59 2013: ^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:59 2013: [] Starting rpcbind daemon...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:16:59 2013: [] Starting NFS common utilities:^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:16:59 2013: [] Cleaning up temporary files...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:16:59 2013: [^[[36minfo^[[39;49m] Setting console screen modes.$ Tue Oct 22 04:16:59 2013: ^[[9;30]^[[14;30][] Setting up console font and keymap...^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0cdone.$ Tue Oct 22 04:16:59 2013: [] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:16:59 2013: Loading the saved-state of the serial devices... $ Tue Oct 22 04:16:59 2013: ... handled by kernel$ Tue Oct 22 04:16:59 2013: [] Setting sensors limits^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:17:00 2013: [^[[36minfo^[[39;49m] zfs-fuse is disabled by /etc/default/zfs-fuse..$ Tue Oct 22 04:17:00 2013: [] Loading IPsec SA/SP database: $ Tue Oct 22 04:17:00 2013: - /etc/ipsec-tools.conf^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:17:01 2013: INIT: Entering runlevel: 2$ Tue Oct 22 04:17:01 2013: [^[[36minfo^[[39;49m] Using makefile-style concurrent boot in runlevel 2.$ Tue Oct 22 04:17:01 2013: [] Starting NFS common utilities:^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c.$ Tue Oct 22 04:17:01 2013: Not starting udftools packet writing: No devices listed in /etc/default/udftools$ Tue Oct 22 04:17:01 2013: [] Not enabling Memory Error Detection and Correction since EDAC_DRIVER is not set:^[[?25l^[[?1c^[7^[[1G
Bug#727074: bootlogd broken - initscripts missing
Package: bootlogd Version: 2.88dsf-43 Severity: grave Justification: renders package unusable Hi. Since a while bootlogd stopped working (which I've ignored as I was lazy and didn't need it). Now I had to dig into it and found the problem to be missing initscripts (see below). Now I'm like 100% sure, hat I haven't removed those,... and since I maintain a dozen of different systems (each manually, not via puppet or so) it's also highly unlikely that I accidentally removed them without noticing it on _all_ thodes nodes (they're missing everywhere). Any idea how that could happen? Reinstalling bootlogd alone doesn't help (since dpkg thinks it was intentionally removed, I guess)... one really has to purge/reinstall it. Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bootlogd depends on: ii libc6 2.17-93 ii lsb-base 4.1+Debian12 bootlogd recommends no packages. bootlogd suggests no packages. -- Configuration Files: /etc/init.d/bootlogd [Errno 2] No such file or directory: u'/etc/init.d/bootlogd' /etc/init.d/stop-bootlogd [Errno 2] No such file or directory: u'/etc/init.d/stop-bootlogd' /etc/init.d/stop-bootlogd-single [Errno 2] No such file or directory: u'/etc/init.d/stop-bootlogd-single' -- 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#727073: ifupdown: current version somehow brings the ifaces up too late
On Tue, 2013-10-22 at 07:00 +0200, Andrew Shadura wrote: > The major difference between 0.7.44 and 0.7.45 is that 0.7.45 waits for > DAD to complete for 'inet6 static' interfaces. Well couldn't that be connected? Since my it seem to be exactly the inet6 addrs that are not _yet_ configured. (They are though configured, once I log in.) > Could you please get some > more information from the system? Sure... but nothing it special,.. what exactly would you like to see? Cheers, Chris smime.p7s Description: S/MIME cryptographic signature
Bug#727073: ifupdown: current version somehow brings the ifaces up too late
Both fixes the problem On Tue, 2013-10-22 at 20:20 +0200, Andrew Shadura wrote: > Do you have your eth0 as allow-hotplug? Try changing it to auto and see > what happens. ...either using allow-auto respectively auto or > Also, please note the new dad-attempts parameter. If you set it to 0, > it behaves as in 0.7.44. setting dad-attempts 0 for each interface, while continuing to use allow-hotplug Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#722006: xserver-xorg-input-synaptics: new version breaks middle mouskey
Hi. Anything new here? The problem persists in the most recent version of sid. The problem seems to be that in previous versions the middle mouse key (which are actually one up, one down) produced button event 1/2, nowadays 4/5. Attached is my xorg.log and the following is my xorg.conf: Section "InputDevice" Identifier "Configured Mouse" Driver "synaptics" Option "CorePointer" Option "VertTwoFingerScroll" "true" Option "HorizTwoFingerScroll" "true" Option "UpDownScrolling" "false" Option "TapButton1""1" Option "TapButton2""2" Option "TapButton3""3" Option "MinSpeed" "0.2" Option "MaxSpeed" "0.6" Option "AccelFactor" "0.008" EndSection It seems as if "UpDownScrolling" would be ignored? Also,.. all the accels/speeds have changed again with the new version... this is really annoying. Chris. [ 4590.513] X.Org X Server 1.14.3 Release Date: 2013-09-12 [ 4590.513] X Protocol Version 11, Revision 0 [ 4590.513] Build Operating System: Linux 3.10-2-amd64 x86_64 Debian [ 4590.513] Current Operating System: Linux heisenberg 3.11-1-amd64 #1 SMP Debian 3.11.5-1 (2013-10-17) x86_64 [ 4590.513] Kernel command line: BOOT_IMAGE=/vmlinuz-3.11-1-amd64 root=/dev/mapper/root ro [ 4590.513] Build Date: 05 October 2013 02:04:26PM [ 4590.513] xorg-server 2:1.14.3-4 (Julien Cristau ) [ 4590.513] Current version of pixman: 0.30.2 [ 4590.513] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 4590.513] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 4590.513] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Oct 25 13:37:07 2013 [ 4590.513] (==) Using config file: "/etc/X11/xorg.conf" [ 4590.513] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 4590.513] (==) No Layout section. Using the first Screen section. [ 4590.513] (==) No screen section available. Using defaults. [ 4590.513] (**) |-->Screen "Default Screen Section" (0) [ 4590.513] (**) | |-->Monitor "" [ 4590.514] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 4590.514] (==) Automatically adding devices [ 4590.514] (==) Automatically enabling devices [ 4590.514] (==) Automatically adding GPU devices [ 4590.514] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 4590.514] Entry deleted from font path. [ 4590.514] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 4590.514] (==) ModulePath set to "/usr/lib/xorg/modules" [ 4590.514] (==) |-->Input Device "Configured Mouse" [ 4590.514] (==) No Layout section. Using the first core pointer device. [ 4590.514] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 4590.514] (II) Loader magic: 0x7f5ca170ed00 [ 4590.514] (II) Module ABI versions: [ 4590.514] X.Org ANSI C Emulation: 0.4 [ 4590.514] X.Org Video Driver: 14.1 [ 4590.514] X.Org XInput driver : 19.1 [ 4590.514] X.Org Server Extension : 7.0 [ 4590.514] (II) xfree86: Adding drm device (/dev/dri/card0) [ 4590.516] (--) PCI:*(0:0:2:0) 8086:0166:10cf:16c1 rev 9, Mem @ 0xf000/4194304, 0xe000/268435456, I/O @ 0x4000/64 [ 4590.516] (II) Open ACPI successful (/var/run/acpid.socket) [ 4590.516] Initializing built-in extension Generic Event Extension [ 4590.516] Initializing built-in extension SHAPE [ 4590.516] Initializing built-in extension MIT-SHM [ 4590.516] Initializing built-in extension XInputExtension [ 4590.516] Initializing built-in extension XTEST [ 4590.516] Initializing built-in extension BIG-REQUESTS [ 4590.516] Initializing built-in extension SYNC [ 4590.516] Initializing built-in extension XKEYBOARD [ 4590.516] Initializing built-in extension XC-MISC [ 4590.516] Initializing built-in extension SECURITY [ 4590.516] Initializing built-in extension XINERAMA [ 4590.516] Initializing built-in extension XFIXES [ 4590.516] Initializing built-in extension RENDER [ 4590.516] Initializing built-in extension RANDR [ 4590.516] Initializing built-in extension COMPOSITE [ 4590.516] Initializing built-in extension DAMAGE [ 4590.516] Initializing built-in extension MIT-SCREEN-SAVER [ 4590.516] Initializing built-in extension DOUBLE-BUFFER [ 4590.516] Initializing built-in extension RECORD [ 4590.516] Initializing built-in extension DPMS [ 4590.516] Initializing built-in extensio
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
For those who haven't seen it, Lennart has posted some of his comments about all this on G+: https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, 2013-10-29 at 00:45 +, Steven Chamberlain wrote: > a commitment to > support two chosen init systems. The question is would supporting two be enough to give a considerable benefit? I guess the competition will be mostly between: systemd vs. upstart. And not between sysvinit, anything else vs. systemd or upstart. sysvinit is simply too old and lacks many modern features. With anything-else, Debian would be more or less completely alone since all world (except *buntu) seems to settle on systemd. So from that POV, I'd even say upstart is already an island solution. Look at most core daemons and systems/technologies (read about CUPS and Wayland just a few days ago) - their upstreams seem to focus on systemd. So when Debian really supports two init systems... what could that be? Either a) systemd AND upstart I guess that would largely be a political benefit, since then the two major fractions are happy. b) (EITHER systemd OR upstart) AND sysvinit That could have a real technical benefit, with respect to !Linux flavours- since then we'd have systemd|upstart for Linux and sysvinit for !Linux. At least systemd does not support !Linux... and I guess it's the same for upstart(??). But then we'd have again the political problem of systemd vs. upstart, since only one could win. So *if* supporting multiple init-systems, and by supporting I mean, that every package must support _at least_ those, then supporting 3(!) seems to make more sense: sysvinit, systemd and upstart. I generally hope, that the tech-ctte will not *forbid* the use of any other init system, but just rule about a _minimum_ set of initsystems (or one) that MUST be supported. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#734517: brasero: suggest brasero-cdrkit
Package: brasero Version: 3.8.0-2 Severity: wishlist Hi. It may make sense for brasero to suggest the brasero-cdrkit package. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734520: mediainfo: suggest mediainfo-gui
Package: mediainfo Version: 0.7.65-1 Severity: wishlist Hey. It may make sense for the mediainfo package to suggest mediainfo-gui. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734822: gnome-session-flashback: NM, Power and Volume applets don't start anymore
Package: gnome-session-flashback Version: 3.8.0-1 Severity: important Hi. A while since ago, NM applet didn't anymore start with GNOME classic (this was already before 3.8 and gnome-session-flashback)... but since then, neither the volume, nor the battery/power applet show's up anymore. Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-session-flashback depends on: ii gnome-panel3.8.0-1 ii gnome-screensaver 3.6.1-1 ii gnome-session-bin 3.8.4-3 ii gnome-session-common 3.8.4-3 ii gnome-settings-daemon 3.8.5-2 ii metacity 1:2.34.13-1 ii nautilus 3.8.2-2 ii notification-daemon0.7.6-1 ii policykit-1-gnome 0.105-2 Versions of packages gnome-session-flashback recommends: ii gnome-power-manager 3.8.2-1 Versions of packages gnome-session-flashback suggests: ii desktop-base 7.0.3 ii gnome-keyring 3.8.2-2 ii gnome-user-guide 3.8.2-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734908: gcr-prompter steals all focus
Package: gcr Version: 3.8.2-4 Severity: critical Justification: breaks unrelated software Hi. Apparently gcr-prompter (well I guess it is this)... seems to have the "nice" effect of stealing mouse and keyboard focus, when a "enter password" dialog is open. So I cannot even start a terminal, or switch to an existing one and kill the crap. To me this happens when Evolution (as so often) forgets out of the blue all of it's configured passwords and wants me to reenter them. critical/breaks unrelated software ... well because it does just that... I cannot use/control other software anymore, once this kicks in. Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gcr depends on: ii dbus-x11 1.7.10-2 ii dconf-gsettings-backend [gsettings-backend] 0.18.0-1 ii libc62.17-97 ii libgcr-base-3-1 3.8.2-4 ii libgcr-ui-3-13.8.2-4 ii libglib2.0-0 2.36.4-1 ii libgtk-3-0 3.8.6-1 gcr recommends no packages. gcr 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#734948: cinnamon: package orphaned?
Package: cinnamon Version: 1.7.4-2.2+b1 Severity: wishlist Dear maintainer. It looks like that package has been orpahned. It's broken since august,.. lacks behind 2 major versions... etc. Are you still into maintaining it or could it be orphaned, so there is the chance someone else might take over? Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734951: [Pkg-systemd-maintainers] Bug#734951: Bug#734951: systemd: somehow starts LSB stuff in the wrong order
On Sun, 2014-01-12 at 00:00 +0100, Michael Biebl wrote: > Are you really running the unstable version then? > This is from the journalctl man page: Damn... you're right... it's there... O:-) ... and yes it's sid. Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#734951: [Pkg-systemd-maintainers] Bug#734951: systemd: somehow starts LSB stuff in the wrong order
Hey Uoti and Michael. >Something on your system is explicitly stopping fail2ban, by calling >"systemctl stop fail2ban.service" or something which maps to that such >as invoke-rc.d. Under sysvinit stopping the service before it has >actually been started would have no noticeable effect, but under systemd >it cancels the queued start action. Ah I see... and actually you're right... What I do is about the following: Since my iptables rules provide "hooks" (i.e. dummy rules), which fail2ban should replace with its own when started ... AND reverted to be hooks when stopped, I've also changed the iptables-persistent script to stop/start fail2ban, when iptables-persistent is stopped/started/restarted. (Obviously a hack, but not really possible to do that better in sysinit, I guess.) I wasn't aware that this would have a queueing effect (and admittedly I've totally forgot about it). Now... is there any clean way to do that with fail2ban/iptables persistent.. i.e. that when iptables-persistent is stopped/restarted, systemd automatically stops/restarts fail2ban as well? Especially since both are not yet converted to systemd. >In general, if you want to make sure that a service cannot start unless >another has been successfully started, add the "Requires" or "Requisite" >field to the unit. But AFAIU, this would be like that every service for, which iptables rules MUST be in place due to e.g. the site's local security constraints, would need to Requires/Requisite iptables-persistent (or something similar). Realistically,.. it's not going to happen that all maintainers add something like this to their unit files (once they convert). Isn't there something like what we've had in sysvinit... e.g. that you reverse-depend on $networking? On Tue, 2014-01-14 at 21:28 +0100, Michael Stapelberg wrote: > In general, the sysvinit configuration source works fairly well in > systemd, but there are good reasons why we want to migrate to systemd > entirely and not live with the compatibility layer forever. Edge cases > such as this one are such reasons :). sure... but yet we have #727708 bothering us ;-) > Now this is interesting. Something is communicating with systemd and > tells it to stop fail2ban. This is the reason you first see the > “stopped” message. I don’t really know what the thing is that talks to > systemd here, but my guess is that it’s some sort of ifup.d-hook or > something like that. The iptables-persistent package doesn’t ship > anything like that, so maybe it’s a local system modification of yours? Yeah... see above :-) I didn't imagine that systemd tries to be that smart, and also "converts" calls of /etc/init.d/xx stop to be queued. I haven't thought that through... but wouldn't the compatibility to legacy LSB script be better,... if it doesn't try to be that smart? > I don’t think that’s true, but I have worked with systemd far more than > with sysvinit, so I might be biased. Apart from the extensive logfile > that systemd can produce, there are tools to generate graphs out of the > boot order and other simulation tools (e.g. systemd --test). Obviously, > none of this can predict what actually happens _outside of systemd_, > such as the stop request systemd receives in your logfile. Okay maybe I explained it wrong: I'm absolutely sure that units can be configured in a way, that it is at least as secured as with sysvinit that e.g. iptables is loaded before network-critical things run. The question though is: are our units in Debian set up this way... and if not what's actually the best way do get that behaviour. I mean it's not only iptables. Imagine services like haveged or any similar entropy gathering daemon (ekeyed and friends). One basically wants that these guys are initialised in the very beginning, ideally as early as possible... just like you want to have the random seed read early in boot and fed to the PRNG (which AFAIU is done by systemd in C code, right?). For "services" like iptables-persistent or similar firewall programs, people would usually expect that the rules are in place before anything except perhaps the loopback network interface is brought up. And I think this should not be like that other services as Apache httpd, or postgresql depend on iptables-persistent.service... since people WILL forget this. I think some general solution must be found, like e.g. having it in the ifup generators... but is that enough? What if some other tool like NM does playing around with interfaces. For services like OpenVPN/IPsec... well I think it's also "important" to have them already running _before_ any other services do networking... but I also think it's not as critical as with e.g. iptables-persistent,... since when it's really that critical for a site to have certain routes secured, they should probably have this reflected y according netfilter rules. Actually I think that this is at least partially also the responsibility of the systemd maintainers in Debian,... since you gu
Bug#726838: mplayer depends upon old libavutil under unstable
Removing mplayer in favour of mplayer2 seems to be quite a bad idea,... as the later seems to be more or less dead upstream, while the former is actively developed. So this is probably a no-go. It should be mentioned btw, that the mplayer and mplayer2 packages from DMO just work fine (and can even be installed concurrently),... so I wonder a bit why the ones from Debian can't. Cheers, Chris. -- 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 Fri, 2014-01-17 at 16:13 +0100, Josselin Mouette wrote: > Just because you don’t understand that sentence doesn’t mean you can use > it to justify whatever convoluted position of yours. I wonder who really doesn't understand here... > An operating system is universal if it can be used for all purposes. > An operating system that supports several kernels and init systems, but > all incompletely, letting the user choose between different ways of > failing to boot, is not universal. It is irrelevant to any serious use > case. ... since which king is then,... who decides which way/init system/kernel/etc... is the "right", the universal, for all people? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#727708: personal views of Debian users
Hey. Well not sure whether this is actually welcomed or not,... but since some people have already started to share their personal feelings about the debate, I want to do so as well. I've been using sysvinit for countless years (as most of us)... and I've tried both, systemd and upstart when the recent discussion began (which was, I guess, actually sparked indirectly by a post of mine, when I "asked" whether systemd was now mandatory due to GNOME depending on it))... I haven't really looked in depth at OpenRC or other solutions, since from the descriptions made by other people, I think it's not comparable to systemd/upstart. I'm maintaining a large Tier-2 for the LHC Computing Grid... so I guess I do have "some" ;) experience in what is useful in real life (like most other people here have of course as well). Now I guess it doesn't make much sense to repeat all technical arguments people have already brought up over and over again in this bug, so to make it short: >From a technical POV, I'd clearly go for systemd. Not only are (IMHO) it's core concepts and design superior... it also seems to provide much more and better features. Speaking only about Debian GNU/Linux... I'd even go as far, that I'd say we should in the long term, think about integrating the "other" features of systemd, like the Journal replacing rsyslog, or perhaps even having it in the initramfs (well, that is of course something one would really need to investigate closely)... In any case we should try to get something like the un-initramfs at shutdown, which systemd seems to support quite well. I think however, that a main part (50%) of the question systemd vs. upstart vs. something-else is not a technical one. Code, design and features can be improved or added. I think there is a strong political part in this decision. - At most upstream projects (the kernel, wayland, X, etc. pp.) people seem to at least think first about systemd... if they support upstart at all. Just look at recent developments like kdbus, which are clearly strongly "influenced/triggered" by systemd. So I fear that when going for upstart, Debian might sooner or later sit on a lone island (next to *buntu's island), having to spend a lot time to keep things working and adapted to upstart. - Most other major distros (except *buntu) have decided for systemd,... so again here,... with upstart we'd sit on a lone island, which ultimately would lead to many problems for sure. - In my opinion (and I'm sure some people will agree and others will contrary): RedHat has proven to be more "neutral" to projects it "governs" than Canonical. Actually, many people seem to think,... that Canonical has recently gone some strange paths, which somehow seem to lead them away from the community and classical open source ecosystem (just think about the whole Mir-story). - With upstart there is the contributor license agreement issue... which I think is a major political problem. - Last but not least... there are people (including myself, I guess),... which are concerned about the Debian/*buntu relationship in several ways... so having upstart the default init system, would give Canonical for sure some bit more of influence on Debian (and if it was just by technical decisions they make upstream). Of course one can argue, that this kind of influence might now be taken by RedHat. As another side note (which is not really a reason against upstart), but has also some political "impact", I guess... I really wonder what the decision "systemd vs. upstart in Debian" means to upstart? systemd for sure wouldn't bother much, if Debian decides for upstart. But it seems to me, that if Debian decides for systemd, this could be the end of upstart itself. Why? - *buntu would then permanently be completely alone on the upstart-island. - And since Debian packages would then focus on systemd, *buntu would get proper support for that for free - so why continuing to spend much efforts just for having an own init-system, which even provides no real technical benefits? Actually Canonical *is* known for dropping support or at least active development for their praised products,... think about bzr. Some last things: - While I think there should be a default init-system which all packages MUST support (which I'd want to be systemd)... others should be allowed as well. - I do have a big problem with projects (especially like GNOME) which sometimes seem to have an agenda of enforcing people to use the techniques they want. IMHO, open source IS about choice. But reality is probably, that one cannot do much about it. - I strongly like the idea of having k/freebsd and other non-Linux Debians,... and if it is just for diversity. Whatever decision is taken in the end,...care should be taken, that these ports can continue to exist. Best wishes, Chris. -- 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 Fri, 2014-01-17 at 16:01 +, Ian Jackson wrote: > The "universal operating system" > phrase is a slogan. Sure it is, but that slogan actually stands for some important principles in the open source world... like not to "force" stuff upon users... and allowing many different things to happily co-exist. Open source is also a lot about freedom (not only that of developers but also that of users) Now looking at the GNOME-background,... there are surely people who'd say that these folks have sometimes forgotten a bit those ideals. Anyway... I guess that's off topic to this discussion (sorry for that)... except perhaps that part,... that neither choice for an init-system should restrict the freedom of others (k/freebsd, hurd, the guys who like another init-system more) more than absolutely necessary. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726838: mplayer depends upon old libavutil under unstable
severity 726838 grave stop Raising severity, since the issue makes the package uninstallable and thus unusable. Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#687624: ITP: libdvdcss-pkg -- automated installer for libdvdcss
Hi. Anything new on this? Now that Debian has accepted stuff like libaacs, this shouldn't be much more of a problem, should it? And I guess it's one of THE reasons why people still need to use DMO. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#749795: apt: no authentication checks for source packages
On Mon, 2014-06-16 at 09:35 +0200, Michael Vogt wrote: > I think for the future we actually should not allow a apt-get update > of untrusted repos without --allow-unauthenticated or > [trusted=no]. But this will probably break some setups so we need to > be careful and not rush it. And what about the setups, which assume secure data to be retrieved (as far as I can see the whole build stack of Debian), which is already broken now? Security is much more critical here then things continuing to work... if someone's setup really depend on not verifying integrity... he will immediately notice (and can add the flag),... but no one notices if his security is compromised by MitMs... :-( So I see not much of a reason to not implement that right away. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751825: kernel-package: doesn't clean up correctly
Package: kernel-package Version: 13.014 Severity: normal Hi. The new version doesn't clean up those wrong config files correctly: Unpacking kernel-package (13.014) over (13.013) ... dpkg: warning: unable to delete old directory '/etc/etc/bash_completion.d': Directory not empty dpkg: warning: unable to delete old directory '/etc/etc': Directory not empty $ tree /etc/etc/ /etc/etc/ ├── bash_completion.d │ └── make_kpkg └── kernel-pkg.conf Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kernel-package depends on: ii bc 1.06.95-9 ii binutils 2.24.51.20140604-3 ii build-essential 11.6 ii bzip21.0.6-5 ii dpkg-dev 1.17.10 ii file 1:5.19-1 ii gettext 0.18.3.2-2 ii kmod 17-2 ii po-debconf 1.0.16+nmu2 ii xmlto0.0.25-2 ii xz-utils [lzma] 5.1.1alpha+20120614-2 Versions of packages kernel-package recommends: ii cpio 2.11+dfsg-2 pn docbook-utils ii kernel-common 13.014 pn uboot-mkimage Versions of packages kernel-package suggests: ii libncurses5-dev [libncurses-dev] 5.9+20140118-1 ii linux-source 3.14+57 -- 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#752017: libguestfs0: depends on legacy iproute package
Package: libguestfs0 Version: 1:1.26.3-1 Severity: normal Hi. libguestfs0 depends on the ransitional dummy package iproute. Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libguestfs0 depends on: ii binutils 2.24.51.20140617-1 ii bsdmainutils 9.0.5 ii btrfs-tools3.14.1-1 ii cpio 2.11+dfsg-2 ii cryptsetup 2:1.6.4-4 ii diffutils 1:3.3-1 ii dosfstools 3.0.26-2 ii file 1:5.19-1 ii icoutils 0.31.0-2 ii iproute1:3.15.0-1 ii jfsutils 1.1.15-2.1 ii kmod 17-2 ii ldmtool0.2.3-3 ii libaugeas0 1.0.0-1.1 ii libc6 2.19-3 ii libfuse2 2.9.3-11 ii libmagic1 1:5.19-1 ii libpcre3 1:8.31-5 ii libselinux12.3-1 ii libvirt0 1.2.4-3 ii libxml22.9.1+dfsg1-3 ii libyajl2 2.1.0-1 ii lsof 4.86+dfsg-1 ii lvm2 2.02.106-2 ii multiarch-support 2.19-3 ii net-tools 1.60-26 ii netpbm 2:10.0-15+b2 ii ntfs-3g1:2014.2.15AR.1-2 ii parted 2.3-20 ii procps 1:3.3.9-5 ii qemu-system-x862.0.0+dfsg-6+b1 ii reiserfsprogs 1:3.6.24-1 ii scrub 2.5.2-2 ii strace 4.5.20-2.3 ii supermin 100 ii udev 204-10 ii vim-tiny 2:7.4.273-2+b1 ii xfsprogs 3.2.0 ii xz-utils 5.1.1alpha+20120614-2 ii zerofree 1.0.3-1 ii zfs-fuse 0.7.0-11 libguestfs0 recommends no packages. libguestfs0 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#752240: torbrowser-launcher: shouldn't be arch=all
Package: torbrowser-launcher Version: 0.0.7-1 Severity: normal Hi. Even though the program itself is just a script running under any architecture... the package makes AFAIU not much sense on architectures where the browser bundle is not available, which AFAICS is only amd64 and i386. Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.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#752275: torbrowser-launcher: several possible/probably security issues
Package: torbrowser-launcher Version: 0.0.7-1 Severity: grave Tags: security Justification: user security hole Hi. This is basically a follow up from the lengthy discussion at debian-devel: https://lists.debian.org/debian-devel/2014/06/msg00171.html (somewhere deeper in the thread). Admittedly I didn't read through the whole code of torbrowser-launcher. Some of the issues below might be mitigated when e.g. no locally downloaded browser would be ever started when the launcher couldn't connect online to check for new versions... but that would mitigate the downgrade attacks described below ONLY if connections to the server are only made via SSL/TLS and if that doesn't allow replaying. Given that TLS/SSL is very... uhm.. fragile... I wouldn't trust on this. And one would need to check specifically for a X.509 cert that is known to belonging to Tor,... checking for just some CA would still allow attacks. Anyway... the problem described below, that any Tor upstream developer whose key is accepted by that launcher can introduce any code in a Debian system, is imho already critical enough. AFAICS, torbrowser-launcher uses the gnupg keys from upstream to verify the downloaded executables. As already pointed out in the aforementioned thread, this has several critical security issues: - anyone from these upstream people, whose key is included, and who are not DDs, can in principle introduce any software they like into the Debian system of any single user or all users. This is especially problematic, since it allows selective attacks on single users, which are not possible via the package management system where it's guaranteed, that all users will download the same binaries, which in turn increases the chance that any backdoor/etc. is found. - since it automatically determines the most recent version and downloads it, it completely circumvents the package management system. People won't notice via their usual means (aptitude, or other notifiers) that there are newer versions (possibly fixing critical security issues) unless they run the torbrowser-launcher again? (or is it always run via that?) - another really big problem are blocking/downgrade attacks. AFAICS from a shore glance, there is no (cryptographically secured) check as to whether the information from the server (i.e. the currently most recent version) is really current, i.e. a "valid from-through information". This should allow attackers very easily to perform replay/downgrade attacks tricking people into downloading old versions with already known security issues. Since thes are signed with valid keys (but AFIACS with no valid from/through information) the downloader will just happily accept them. I'm not sure, but I guess it doesn't help if you download things via https. Another issue are blocking attacks... when no connection can be made at all to the tor download servers, will it start the currently downloaded version of the bundle or will it simply fail? In case it doesn't fail, it could again be used to trick people into using software with known security deficiencies. Such "downloader packages" are quite danerous per se,... as it's very tricky to really securely do it. Usually the best way is to hard code a secure hash (i.e. not MD5) of the upstream package which is currently considered secure... every time a new upstream version comes out, a new downloader package should come out as well with a new hash,...so that people regularly (via the package management system) notice about [security] updates. Cheers, Chris. btw: Apart from that... I've always wondered how secure something like torbrowser bundle can be... per se, they will always lag a bit behind FF with security updates,... and FF in turn already has enough security issues. btw2: Since torbrowser-launcher is probably usually launched as normal user, I marked this as "user security hole" only. But given that torbrowser-launcher will typically be run on desktops/notebooks... successfully attacking that user is usually equivalent to root exploit (the attacker could simply wait for the user to sudo/su to root and keylog his password). So actually severity is IMHO critical. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752277: flashplugin-nonfree: several security issues
Package: flashplugin-nonfree Version: 1:3.4 Severity: critical Tags: security Justification: root security hole Hi. This is basically a follow up from the lengthy discussion at debian-devel: https://lists.debian.org/debian-devel/2014/06/msg00171.html (somewhere deeper in the thread). I've head a short glance over the code and assume the following: - You use OpenPGP to verify whether the flash plugin downloaded from Debian servers is "valid" (whatever that means, since it's closed source). - The key used for signing is solely under YOUR (i.e. the package maintainer's) control. It is especially NOT a key that is under the control of upstream. - AFAICS, you never use https, TLS/SSL or X.509 in that security framework (which would make things usually just more insecure). While all this sounds nice and secure at first, it is acutally not in several places: - I rather don't like the idea that a key is used to sign the binary at all. If your key would be compromised, an attacker could _selectively_ attack single users by giving them forged code. Of course you may say "if my key is compromised, than an attacker can as well use it to upload new packages to Debian". Yes, but such a package would then be delivered to _all_ users, thereby increasing the chance that any forgery is noticed. The whole schema has one big problem as it basically circumvents the package management system and the security support, as it is it's "own" package installation system. This leads to several problems: - User won't notice when new versions of the binary (and with flash this most definitely means critical security updates) are available. Only when they run the installer, they will get a new version). Thus, any of the standard mechanisms (apt, aptitude, notifiers) that tell people of new versions are kicked out of the game. - As you implemented your OpenPGP signature based verification system, you allow for both, downgrade and blocking attacks: As far as I can see, you never check for any cryptographically secured "valid-from/through" period. This means, an attacker can simply download packages and signatures from the server and when such version of the binary is long known to have security holes, he could MitM someone that runs the installer, present him some binary and your still valid (but old) signature. Even signature revocations or that like won't help (since he could just block such). - Also, even if you'd run the installer automatically via e.g. cron, he could do blocking attacks (when you don't check for some "valid-from/through" period), i.e. he could just block any "messages" from the server, that there are new versions/signatures available... making the downloader believe that everything is still fine. Please have a look at the aforementioned mailing list thread (the stuff about downloader packages is rather deep in it) and familiarise yourself with potential problems. Another resource might be bug #752275, which is vaguley the same for torbrowser-launcher (actually with some issues more, since they use the upstream GPG keys)- The best advise I can give for such downloader packages is the following: - Hard code the hashsum of the binary/bundle/archive to be downloaded in your package. - Use a "good" state of the art hash algo (i.e. not MD5)... or even use more (I'd suggest SHA512 and SHA3 - since those two even base on different cryto) and fail with bells and whistles when _any_ of them doesn't verify. - If anything didn't verify,... make sure you remove everything that was downloaded (users might think it's safe and use it themselves) - When you extract archives (tar/zip/etc.) take care that leading / in the archive would be forcibly ignored. - Everytime, you see that upstream has a new package,... make a new debian package and replace the hashes - that way you also get all the notifications and stuff in package management for free. Further. - Never use TLS/SSL/X.509 for security... it can be made secure - but it's tricky - Don't use OpenPGP as well... while it's much (and I really mean veeeyyy much better than X.509) you still may run into tricky isses as the downgrading attacks described above. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752278: iceweasel shouldn't advertise for external programs
Package: iceweasel Version: 30.0-2 Severity: normal Tags: security Hi. Apparently there are cases where Iceweasel automatically suggests users an external program or plugin, like when you click an URI: irc://irc.freenode.net:6667/btrfs it suggests Mibbit. I think this is really a bad idea, especially security wise, as the user may click on this perhaps already downloading/starting something as local user (I didn't try it out, since it didn't tell me what will happen). If at all, iceweasel should rather suggest any packages in the Debian main archive, which are capable of handling the requrested file type / URI schema are whatever. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752277: flashplugin-nonfree: several security issues
Well since Jakup has already said everything here and I fully agree with him Since I'm not in the mood of starting a titles/severity/tags war with some apparently security ignorant member from the security team (o.O)... I'm out of the game here (see also https://lists.debian.org/debian-devel/2014/06/msg00393.html),... Bart, if you have technical questions/comments/etc. I'll happily try to help as good as I can... but I'm really out of the "political" discussion here unless Debian has decided whether it wants security or not. And looking at the whole thread above and the disturbing view of at least some security team members... I rather think that Debian has some much deeper problems with respect to it's security attitude, than just this concrete technical issue. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#752277: flashplugin-nonfree: several security issues
Hey Bart On Sun, 2014-06-22 at 21:55 +, Bart Martens wrote: > The rest is quite vague to me What do you mean by: the rest? Apart from the downgrading/blocking attacks the two most notable issues I've described were: - people are not notified about [security] updates the usual ways (apt, aptitude, notifiers for that), which I think is at the least quite unfortunate and at the most a security issue - given that software is signed by your key (rather then the Debian archive key),... it's in principle much easier for an attacker to only attack selective users (and thus be noticed much harder)... if - of course - your key would be compromised. Anything else that I forgot now? > or applicable to the entire > Debian repository The above two points to IMHO not apply to the "normal" Debian archive. > or already covered in the package. How? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
Package: ftp.debian.org Severity: important Tags: security Dear ftp masters. I've thought about that before but then forgot it again and it came back to my mind during the recent thread[0] about security, that I've started on debian-devel. As Jakub Wilk pointed out[1] these are the current validity periods for Release files: unstable, experimental: 7 days testing: 7 days wheezy: no limit wheezy(-proposed)-updates: 7 days wheezy/updates at security.d.o: 10 days wheezy-backports: 7 days squeeze: no limit squeeze(-proposed)-updates: 7 days squeeze/updates at security.d.o: 10 days squeeze-lts: 7 days IMHO all of them are far too long. Maintainers and our Security Team are usually doing a great job in trying to provide fixes for security issues ASAP. But even if they're incorporated only hours or less after being released, an attacker can do a downgrade attack for 7-10 days and trick a system into not "seeing" these new packages. Such downgrade attack is very easy to perform, as soon as one can MitM, and we generally must expect that not only powerful groups like NSA and friends are able to do this. Since many unattended systems (especially in the stable branches) are more or less automatically updated, and since an attacker that can MitM can likely also block any security announcement mails, users/admins have no chance to take note about such updates being available for 7-10 days. I'd suggest to reduce the validity to at most 1 day in all cases. Actually I'd choose much smaller values if this causes no other problems. Many users run unstable/testing as their normal system, so it's not enough to only tighten the periods for the stable branches. My proposal would be something like that: unstable/testing: 4-12 hours [wheezy|squeeze]/updates at security.d.o: 1-6 hours For the others, it depends how security updates are distributed, i.e. since they come via [wheezy|squeeze]/updates at security.d.o it probably makes not much sense to have that short times for wheezy and for squeeze. Not sure about wheezy(-proposed)-updates, squeeze(-proposed)-updates and wheezy-backports, squeeze-lts. Cheers, Chris. btw: I'll CC the security team, the debian lts guys and affect the bug to release.debian.org... at least these are hopefully the responsible guys acording to [1]. [0] https://lists.debian.org/debian-devel/2014/06/msg00171.html [1] https://lists.debian.org/debian-devel/2014/06/msg00407.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752277: flashplugin-nonfree: several security issues
On Mon, 2014-06-23 at 16:19 +, Bart Martens wrote: > OK, your answer confirms that I wasn't overlooking anything. I'll also briefly > answer your questions : Well as said... I think the problem that people don't notice updates unless they run the installer again, is also some severe problem... Or do I miss anything here? > > How? > > For example I'm already using SHA512. Uhm I'm a bit confused now... ^^ I've seen your message #66 and had a short glance at the code... but it's a bit hard to read since there are so many files downloaded where I don't quite understand why... - where are you using SHA512? - and how did you solve the issue with downgrade attacks now - and how the one with blocking attacks? (i.e. when an attacker blocks contact to the server with your files... does the plugin tell the user some appropriate error? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#752277: flashplugin-nonfree: several security issues
On Mon, 2014-06-23 at 16:19 +, Bart Martens wrote: > > Anything else that I forgot now? > Not that I know of. Ah one more thing that I've remembered: Do you extract the downloaded archive in such way that any leading / in the pathnames is ignored? And apart from that... as mentioned before... the safest method is probably the one where you don't use GPG but always update the package when a new version of flash comes out. That also fits best with most assumtions one has from a package (changelog, being notified in APT/etc. about updates, and so on) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#752275: torbrowser-launcher: several possible/probably security issues
Sorry for the late reply. On Sat, 2014-06-21 at 23:01 -0700, Micah Lee wrote: > The keys that are signing keys that are included torbrowser-launcher are > for: Alexandre Allaire, Erinn Clark, Mike Perry, and Sebastian Hahn. > Keys are here: > https://github.com/micahflee/torbrowser-launcher/tree/master/keys Well who they are and which names they have doesn't really matter, does it? I think the only thing that is important here: at least not all of them are DDs > > - anyone from these upstream people, whose key is included, and > > who are not DDs, can in principle introduce any software they like > > into the Debian system of any single user or all users. > > I don't think these people could introduce any software they like into > the Debian system. > > torbrowser-launcher downloads the TBB software from a predictable > location at https://www.torproject.org/ and also downloads the signature > for it. If the signature verifies, then it trusts the TBB as being valid > and extracts it into the current user's ~/.torbrowser/.tbb folder, and > launches > ~/.torbrowser/tbb/stable/x86_64/tor-browser_en-US/start-tor-browser (or > similar, depending on your architecture, language, and if you're running > stable or alpha). It runs this as the current user. From what you describe it just means that any of the above people could sign any piece of software, place it at https://www.torproject.org/ and distribute it (even selectively per possibly specifically attacked user) to Debian systems. Just as I've said - or do I understand anything wrong? > So even if the TBB tarball that downloaded was malicious, it would only > get code execution as the current user, not as root. They wouldn't be > able to, for example, install another debian package. Although arbitrary > code exec as the current user is really bad, of course. As I described in the end of my ticket: On those systems that probably will use TBB (i.e. desktops, notebooks) gaining user access is typically identical to gaining root access (even if there wouldn't be any privilege escalation bugs). If the user acc is taken over, a malicious software would simply install some keylogger or whatever and wait until the user sooner or later switches user to root. And as you've said, introducing code with just user rights *is* bad enough ;) > > This is especially problematic, since it allows selective attacks on > > single users, which are not possible via the package management system > > where it's guaranteed, that all users will download the same binaries, > > which in turn increases the chance that any backdoor/etc. is found. > > How could this be used to do selective attacks against specific users? *If* Tor developers would be evil (and I'm not saying this - I rather just think they're not DDs and should therefore not have this potentialpower)... they can probably return different binaries to http[s] requrests based on the downloading client (e.g. via IP address). So it would be possible to deliver malicious code to just a portion of the downloading users... which would make such an attack even more difficult to detect. > Are you assuming that the attacker has access to one of the Tor devs > trusted signing keys listed above I neither claim that this is the case, nor do I say that the Tor upstream people are "evil" and would misuse their powers ;-) But you can never know... keys can be compromised... and people can be forced to do things (especially in countries like the US - with national security letters and gag orders). And I think it's simply what one can/should expect when installing a Debian package: That all software directly/indirectly installed by it went thorough the hands of some DD or DM (who decided what gets in - and not some upstream developer)... AND to be sure, that what you get is the same on all Debian systems. > and that the attacker either has > access to the https://www.torproject.org/ web server Well TLS/SSL are known to have many issues (not to talk about those not yet discovered)... so generally we should try to avoid depending on them for hard security... Next things is: The tor servers seem to use a digicert X.509 cert... DigiCert Inc in turn is US based - now guess which country has some organisations constantly trying to undermine Tor and who can probably easily force DigiCert to issue a forged certificate? ;-) The only thing around that would be to hardcode the server cert itself in the launcher program ... and as far as I can see... you do just that. But how did you get that cert? Just via downloading it? Or somehow securely ;) > > - since it automatically determines the most recent version and downloads > > it, it completely circumvents the package management system. > > People won't notice via their usual means (aptitude, or other notifiers) > > that there are newer versions (possibly fixing critical security issues) > > unless they run the torbrowser-launcher again? > > (or is it always run via that?) > > It's
Bug#752670: systemd: breaks USB stick detection and/or cryptsetup keyscript
Hi Michael. On Wed, 2014-06-25 at 16:15 +0200, Michael Biebl wrote: > Looks like a duplicate of #752591/#752605 > > -12 has been uploaded already. You can either wait for that or apply the > fix manually. > > Please confirm if -12 (or the fix [1]) works for you. Just arrived at home and could verify it... it works again with -12... AFAICS you've already merged it with #752591. Thanks, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#745018: network-manager: NM restarts itself and breaks existing networking then
Package: network-manager Version: 0.9.8.8-6 Severity: critical Justification: breaks unrelated software Hi. Any once again one of the many annoyances due to NM :-( Apparently NM doesn't really integrate with ifupdown (which is the canonical and native place of network configuration in Debian) nicely. I.e. EAP connections don't work, which I've reported bugs before upstream (which is unwilling to fix this though) and I think even here in the DebBTS. So I have to deactivate NM whenever I want to use a non PSK connection o.O But since some recent upgrade now, some component (god knows which) restarts NM then by itself. o.O Apr 17 11:59:36 heisenberg NetworkManager[27771]: (wlan0): cleaning up... Apr 17 11:59:36 heisenberg NetworkManager[27771]: exiting (success) Apr 17 11:59:36 heisenberg dbus[2663]: [system] Activating via systemd: service name='org.freedesktop.NetworkManager' unit='dbus-org.freedesktop.NetworkManager.service' Apr 17 11:59:36 heisenberg systemd[1]: Starting Network Manager... Apr 17 11:59:36 heisenberg systemd[1]: Starting Network Manager... Apr 17 11:59:36 heisenberg NetworkManager[27993]: NetworkManager (version 0.9.8.8) is starting... Apr 17 11:59:36 heisenberg NetworkManager[27993]: Read config file /etc/NetworkManager/NetworkManager.conf Apr 17 11:59:36 heisenberg NetworkManager[27993]: WEXT support is enabled Apr 17 11:59:37 heisenberg NetworkManager[27993]: VPN: loaded org.freedesktop.NetworkManager.vpnc Apr 17 11:59:37 heisenberg NetworkManager[27993]: VPN: loaded org.freedesktop.NetworkManager.strongswan Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: init! Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: update_system_hostname Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPluginIfupdown: guessed connection type (eth0) = 802-3-ethernet Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: update_connection_setting_from_if_block: name:eth0, type:802-3-ethernet, id:Ifupdown (eth0), uuid: 681b428f-beaf-8932-dce4-687ed5bae28e Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: adding eth0 to connections Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: adding iface eth0 to eni_ifaces Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPluginIfupdown: guessed connection type (eth1) = 802-3-ethernet Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: update_connection_setting_from_if_block: name:eth1, type:802-3-ethernet, id:Ifupdown (eth1), uuid: 7b635ed6-2640-7ad8-675d-744db12dd9fa Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: adding eth1 to connections Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: adding iface eth1 to eni_ifaces Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: adding mapping wlan0 to eni_ifaces Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPluginIfupdown: guessed connection type (wlan0-scientia.net) = 802-11-wireless Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: update_connection_setting_from_if_block: name:wlan0-scientia.net, type:802-11-wireless, id:Ifupdown (wlan0-scientia.net), uuid: 9375b2e6-428a-71f6-32f7-4e37e36f0bdd Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: update wireless settings (wlan0-scientia.net). Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: setting wpa ssid = 12 Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: update wireless security settings (wlan0-scientia.net). Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: setting wpa security key: key-mgmt=wpa-psk Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: setting wpa security key: psk= Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: adding wlan0-scientia.net to connections Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: adding iface wlan0-scientia.net to eni_ifaces Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPluginIfupdown: guessed connection type (wlan0-eduroam) = 802-11-wireless Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: update_connection_setting_from_if_block: name:wlan0-eduroam, type:802-11-wireless, id:Ifupdown (wlan0-eduroam), uuid: f624dc9f-5572-0f7a-a751-e34905e074a0 Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: update wireless settings (wlan0-eduroam). Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: setting wpa ssid = 7 Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: update wireless security settings (wlan0-eduroam). Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: setting wpa security key: key-mgmt=wpa-eap Apr 17 11:59:37 heisenberg NetworkManager[27993]:SCPlugin-Ifupdown: setting wp
Bug#745677: igtf-policy-classic: fails during installation
Package: igtf-policy-classic Version: 1.56-2 Severity: grave Justification: renders package unusable Hi. The package fails during installation: Setting up igtf-policy-classic (1.56-2) ... basename: extra operand ‘/etc/grid-security/certificates/036b3363.signing_policy’ Try 'basename --help' for more information. dpkg: error processing package igtf-policy-classic (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: igtf-policy-classic Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages igtf-policy-classic depends on: ii debconf [debconf-2.0] 1.5.53 Versions of packages igtf-policy-classic recommends: pn fetch-crl ii openssl1.0.1g-3 Versions of packages igtf-policy-classic suggests: ii ca-certificates 20140325 -- debconf information: * igtf-policy-classic/install_profile: true * igtf-policy-classic/exclude_ca: igtf-policy-classic/include_ca: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741132: lives: opening a file makes the program crash
Package: lives Version: 2.2.2~ds0-1 Severity: grave Justification: renders package unusable Hi. When opening a video file I get: avformat detected format: mov,mp4,m4a,3gp,3g2,mj2 /usr/lib/lives/lives-exe: symbol lookup error: /usr/lib//lives/plugins/decoders/zzavformat_decoder.so: undefined symbol: av_find_stream_info And the program crashes. Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lives depends on: ii frei0r-plugins1.1.22git20091109-1.4 ii imagemagick 8:6.7.7.10+dfsg-1 ii libasound21.0.27.2-3 ii libatk1.0-0 2.10.0-2 ii libavc1394-0 0.5.4-2 ii libavcodec-extra-54 6:9.11-3 ii libavformat54 6:9.11-3 ii libavutil52 6:9.11-3 ii libc6 2.18-4 ii libcairo-gobject2 1.12.16-2 ii libcairo2 1.12.16-2 ii libdv41.0.0-6 ii libfftw3-single3 3.3.3-7 ii libgcc1 1:4.8.2-16 ii libgdk-pixbuf2.0-02.30.5-1 ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libglee0d15.4.0-2 ii libglib2.0-0 2.38.2-5 ii libglu1-mesa [libglu1]9.0.0-2 ii libgtk-3-03.10.7-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.9.5+20130622git7de15e7a-1 ii libmjpegutils-2.1-0 1:2.1.0+debian-2.1 ii libogg0 1.3.1-1 ii liboil0.3 0.3.17-2 ii libpango-1.0-01.36.2-2 ii libpangocairo-1.0-0 1.36.2-2 ii libpng12-01.2.50-1 ii libpulse0 4.0-6+b1 ii libraw1394-11 2.1.0-1 ii libsdl1.2debian 1.2.15-8 ii libstdc++64.8.2-16 ii libswscale2 6:9.11-3 ii libtheora01.1.1+dfsg.1-3.1 ii libunicap20.9.12-2 ii libweed0 2.2.2~ds0-1 ii libx11-6 2:1.6.2-1 ii libxrender1 1:0.9.8-1 ii lives-data2.2.2~ds0-1 ii mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 ii ogmtools 1:1.5-3+b1 ii perl 5.18.2-2+b1 ii procps1:3.3.9-4 ii python2.7.5-5 ii sox 14.4.1-3 ii zlib1g1:1.2.8.dfsg-1 Versions of packages lives recommends: pn dvgrab pn icedax ii libtheora-bin 1.1.1+dfsg.1-3.1 ii mencoder 2:1.0~rc4.dfsg1+svn34540-1+b2 ii mkvtoolnix 6.8.0-1 ii pulseaudio 4.0-6+b1 ii x11-utils 7.7+1 pn youtube-dl Versions of packages lives suggests: pn libdv-bin ii mjpegtools 1:2.1.0+debian-2.1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718434: fixed in ca-certificates 20140223
On Tue, 2014-03-25 at 18:58 +0100, Bas Wijnen wrote: > No, the point is that an attacker is detectable. Why should he be? And even if he was... if I already sent my valuable data, then it's too late. > Do you think the NSA > does MITM attacks on all connections? I seriously thought that they > might. Well the question is less whether they actually try it with any connection... which is of course unlikely since people would notice that far to easy... the question is rather whether they could do it with all connections... and I guess that might be the case... the only thing they need to do is to hijack only such connections for which they know no verification will be made. > If the NSA starts doing this, someone will catch them. That will be big > news and everyone will start checking their keys. I doubt that... and how should it work anyway? How can I check the public key of my e.g. bank? Right now, only by trusting Verisign&friends... which again are all under the control of NSA&friends. > Well, not exactly, of course. It is still very likely that they are > trying to (and also that they succeeded to) put back doors into the > encryption protocols, or at least their implementations. Sure but that's another field... > Depending on what you mean by "sitting on the line". They can always > read, but to tamper they need to sit "in" the line, not just on it. > They have to make sure the original packets don't reach their > destination. I take it that's what you mean. > > (Note that this is a much smaller group of machines; for example, I can > read all traffic on the subnet of my block of houses, but I can't > effectively tamper with it.) Well if one has to assume that they sit "in" the big internet exchange points... this already gives them a lot... > But if they start to doubt, they can check if they have been attacked, > by comparing their keys through an independent channel. Well but that simply doesn't happen, does it? At least since Snowden, all world should really know: NSA&friends spy _everything_ ... I mean most of use expected it for sure before... but now there is no way to not know. And what changed? Well we still have the broken X.509 strict hierarchical trust model,... and it won't go away very soon. Of course the NSA won't issue forged certs (by forcing verisign&friends) at large (because that would be rather easily noticed) but they will do so for targets worth it. So people must have your "doubts" by know, but nothing really changes. Actually the contrary... like e.g. Debian who puts its own certificates under some commercial CA now, instead of using its own, which people could really trust (well at least as much as they can trust Debian itself). > If any of them is found to be under > attack, more checks will be done; if many of those will fail, all hell > will break loose. You can be sure that they do all this... and no hell broke loose. > to convince people that > not encrypting is better than encrypting with unchecked keys. Well that's not what I said... I rather say the later is simply not enough. > You're claiming that having an evil CA in the list means that my > communication is in danger of being eavesdropped. I'm saying that this > is nonsense, because: > > > > An evil CA cannot read your traffic (unless they are in > > > the path of your communication). > > You are saying that the NSA has control over evil CAs, and also is in > the path of communication. So they can eavesdrop. Technically this is > true. But there are two things to consider: > > 1. Due to the fact that they would be detected if they tried this on a >large scale, they won't actually do this. Well first... why is an attack only a problem if it's done at large scale? If the NSA does this only for the Snowdens, Applebaums, etc. ... then this is enough for them... Secondly,... "being detected" in that case means, that someone trustworthy regularly scans for forged certificates... (in the sense of having a different fingerprint, than the ones from the same CA, which are however known to be in the possession of their rightful owner). - This is difficult by the mass of certificates... even for single companies like google you have gazillions of domains and even more certs... This is the reason why programs like certificate patrol are only little helpful in practise. - It would need to mean, that this someone is not under the control of such government (also, not necessarily the case). - It would need to mean, that that someone does actually know the correct cert (if he only ever saw the forged one, he will never notice it). - And it would need to mean that the rightful owner is not evil... or not forced to be evil (by law)... which we again know is the case at least in the US. So you may be "lucky" to notice such forgery... but there is no guarantee. Anyway... the topic of that bug was rather the CAcert certificate... and I think Debian is doing very bad if it tries to give any
Bug#742649: icc-profiles: include sRGB_v4_ICC_preference_displayclass.icc
Package: icc-profiles Version: 2.0.1-1 Severity: wishlist Hi. Perhaps it makes sense to include sRGB_v4_ICC_preference_displayclass.icc from http://www.color.org/srgbprofiles.xalter as well. btw: I've noted that the sRGB profile in the package differs from that e.g. shipped by Microsoft... any idea why? Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742651: icc-profiles: add a location for local profiles
Package: icc-profiles Version: 2.0.1-1 Severity: wishlist Hi. I think a location for local color profiles should be shipped (and ideally other packages looking for such profiles) should be modified to look there as well,... like e.g. /usr/local/share/color/icc Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742658: argyll: new upstream version
Source: argyll Version: 1.5.1-5 Severity: wishlist Hi. A far newer upstream version is available, which seems to include many fixes amongst others for ColorHug. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742971: network-manager: network manager upgrade fails
Package: network-manager Version: 0.9.8.8-4 Severity: critical Justification: breaks the whole system Hi. The last NM upgrade seems to not work: # dpkg --configure -a Setting up network-manager (0.9.8.8-4) ... Job for NetworkManager.service failed. See 'systemctl status NetworkManager.service' and 'journalctl -xn' for details. invoke-rc.d: initscript network-manager, action "restart" failed. dpkg: error processing package network-manager (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: network-manager breaking all networking... Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages network-manager depends on: ii adduser3.113+nmu3 ii dbus 1.8.0-3 ii init-system-helpers1.18 ii isc-dhcp-client4.2.4-7 ii libc6 2.18-4 ii libdbus-1-31.8.0-3 ii libdbus-glib-1-2 0.102-1 ii libgcrypt111.5.3-4 ii libglib2.0-0 2.38.2-5 ii libgnutls262.12.23-13 ii libgudev-1.0-0 204-8 ii libmm-glib01.0.0-4 ii libnl-3-2003.2.21-1 ii libnl-genl-3-200 3.2.21-1 ii libnl-route-3-200 3.2.21-1 ii libnm-glib40.9.8.8-4 ii libnm-util20.9.8.8-4 ii libpolkit-gobject-1-0 0.105-4 ii libsoup2.4-1 2.44.2-1 ii libsystemd-login0 204-8 ii libuuid1 2.20.1-5.7 ii lsb-base 4.1+Debian12 ii udev 204-8 ii wpasupplicant 1.1-1 Versions of packages network-manager recommends: ii crda 1.1.2-1 ii dnsmasq-base 2.68-1 ii iptables 1.4.21-1 pn modemmanager ii policykit-1 0.105-4 ii ppp 2.4.5+git20130610-4 ii systemd 204-8 Versions of packages network-manager suggests: pn avahi-autoipd -- Configuration Files: /etc/NetworkManager/NetworkManager.conf changed: [main] plugins=ifupdown,keyfile [ifupdown] managed=true -- 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#743256: iceweasel doesn't work with ICC v4 color profiles
Package: iceweasel
Version: 24.4.0esr-1
Severity: normal
Hi.
It seems iceweasel doesn't work with ICC v4 profiles in images.
See e.g. http://www.color.org/version4html.xalter
Perhaps some old lib is used somewhere?
Cheers,
Chris.
-- Package-specific info:
-- Extensions information
Name: Adblock Plus
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: enabled
Name: Certificate Patrol
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/certpat...@psyc.eu
Package: xul-ext-certificatepatrol
Status: enabled
Name: Cookie Monster
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{45d8ff86-d909-11db-9705-005056c8}
Package: xul-ext-cookie-monster
Status: enabled
Name: Default theme
Location:
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled
Name: Download Statusbar
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{D4DD63FA-01E4-46a7-B6B1-EDAB7D6AD389}
Package: xul-ext-downloadstatusbar
Status: enabled
Name: DownThemAll!
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{DDC359D1-844A-42a7-9AA1-88A850A938A8}
Package: xul-ext-downthemall
Status: enabled
Name: Firebug
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/fire...@software.joehewitt.com
Package: xul-ext-firebug
Status: user-disabled
Name: FirePath
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/firexp...@pierre.tholence.com
Package: xul-ext-firexpath
Status: enabled
Name: Flashblock
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{3d7eb24f-2740-49df-8937-200b1cc08f8a}
Package: xul-ext-flashblock
Status: enabled
Name: GNOME Keyring integration
Location:
/usr/lib/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{6f9d85e0-794d-11dd-ad8b-0800200c9a66}
Package: xul-ext-gnome-keyring
Status: user-disabled
Name: HTTPS-Everywhere
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/https-everywh...@eff.org
Package: xul-ext-https-everywhere
Status: enabled
Name: Live HTTP headers
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{8f8fe09b-0bd3-4470-bc1b-8cad42b8203a}
Package: xul-ext-livehttpheaders
Status: enabled
Name: NoScript
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{73a6fe31-595d-460b-a920-fcc0f8843232}
Package: xul-ext-noscript
Status: enabled
Name: SearchLoad Options
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/searchloadoptions@esteban.torres
Package: xul-ext-searchload-options
Status: enabled
Name: Status-4-Evar
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/status4e...@caligonstudios.com
Package: xul-ext-status4evar
Status: enabled
Name: Tab Mix Plus
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{dc572301-7619-498c-a57d-39143191b318}
Package: xul-ext-tabmixplus
Status: enabled
Name: User Agent Switcher
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}
Package: xul-ext-useragentswitcher
Status: enabled
Name: Web Developer
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{c45c406e-ab73-11d8-be73-000a95be3b12}
Package: xul-ext-webdeveloper
Status: enabled
Name: Y U no validate
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{20d36f97-15da-47ed-9f0a-13cbe85bdc84}
Package: xul-ext-y-u-no-validate
Status: enabled
-- Plugins information
Name: Cinnamon Integration
Location: /usr/lib/mozilla/plugins/libcinnamon-browser-plugin.so
Package: cinnamon
Status: disabled
Name: DivX® Web Player
Location: /usr/lib/mozilla/plugins/libtotem-mully-plugin.so
Package: totem-mozilla
Status: enabled
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: disabled
Name: QuickTime Plug-in 7.6.6
Location: /usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so
Package: totem-mozilla
Status: enabled
Name: Shockwave Flash
Location: /usr/lib/gnash/libgnashplugin.so
Package: browser-plugin-gnash
Status: enabled
Name: VLC Multimedia Plugin (compatible Videos 3.8.2)
Location: /usr/lib/mozilla/plugins/libtotem-cone-plugin.so
Package: totem-mozilla
Status: enabled
Name: Windows Media Player Plug-in 10 (compatible; Videos)
Location: /usr/lib/mozilla/plugins/libtotem-gmp-plugin.so
Package: totem-mozilla
Status: enabled
-- Addons package information
ii browser-plugin 0.8.11~git20 amd64GNU Shockwave Flash (SWF) player
ii cinnamon 1.7.4-2.2+b2 amd64Innovative and comfortable deskto
ii gnome-shell3.8.4-5+b2 amd64graphical shell for the GNOME de
Bug#743257: imagemagick: doesn't support ICC profiles?
Package: imagemagick Version: 8:6.7.7.10+dfsg-1 Severity: normal Hi. When I open the test images there (with display): http://www.color.org/version4html.xalter I get just the results which would mean that color spaces (both ICC v2 and v4) are ignored. Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages imagemagick depends on: ii hicolor-icon-theme 0.13-1 ii libbz2-1.0 1.0.6-5 ii libc6 2.18-4 ii libfontconfig1 2.11.0-5 ii libfreetype62.5.2-1 ii libglib2.0-02.38.2-5 ii libgomp14.8.2-18 ii libice6 2:1.0.8-2 ii libjpeg88d-2 ii liblcms2-2 2.5-1 ii liblqr-1-0 0.4.1-2 ii libltdl72.4.2-1.7 ii liblzma55.1.1alpha+20120614-2 ii libmagickcore5 8:6.7.7.10+dfsg-1 ii libmagickwand5 8:6.7.7.10+dfsg-1 ii libsm6 2:1.2.1-2 ii libtiff54.0.3-8 ii libx11-62:1.6.2-1 ii libxext62:1.3.2-1 ii libxt6 1:1.1.4-1 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages imagemagick recommends: ii ghostscript 9.05~dfsg-8+b1 ii libmagickcore5-extra 8:6.7.7.10+dfsg-1 ii netpbm2:10.0-15+b2 ii ufraw-batch 0.19.2-2 Versions of packages imagemagick suggests: ii autotrace 0.31.1-16+b1 ii cups-bsd [lpr]1.7.1-11 ii curl 7.36.0-1 pn enscript pn ffmpeg ii gimp 2.8.6-1 ii gnuplot 4.6.5-1 pn grads ii groff-base1.22.2-5 pn hp2xx pn html2ps ii imagemagick-doc 8:6.7.7.10+dfsg-1 ii libwmf-bin0.2.8.4-10.3 ii mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 pn povray pn radiance ii sane-utils1.0.24-1.1+b1 pn texlive-base-bin ii transfig 1:3.2.5.e-1 ii xdg-utils 1.1.0~rc1+git20111210-7 -- 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
