Bug#785457: cloud.debian.org: AMI don't need getty
На 18.05.2015 в 17:17, Emmanuel Kasper написа: My understanding of that applied to Xen virtualization platform that Amazon uses, is that systemd will *always* start a getty on the default system console, which for Xen will be /dev/hvc0 instead of /dev/tty1 Actually you *want* to have this one getty started, as this is where your rescue console will be. I'm new to Amazon EC2 but I don't see any way to access Xen console (hvc0). Quick googling didn't find anything. All the best, Ognyan signature.asc Description: OpenPGP digital signature
Bug#782772: logging into metnors.debian.net crashes iceweasel ..
Control: reassign 782772 iceweasel Control: found 782772 37.0.2-1 38.0-2 Control: tags 782772 + upstream Control: forwarded 782772 https://bugzilla.mozilla.org/show_bug.cgi?id=1165911 On Mon 2015-05-18 10:07:48 -0400, Daniel Kahn Gillmor wrote: After upgrading to 38.0-2, with iceweasel-dbg, i get the following backtrace during the segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd94fe700 (LWP 10459)] 0x7403bb87 in GatherEKUTelemetry (certList=...) at /tmp/buildd/iceweasel-38.0/security/manager/ssl/src/SSLServerCertVerification.cpp:1047 http://sources.debian.net/src/iceweasel/38.0-2/security/manager/ssl/src/SSLServerCertVerification.cpp/?hl=1024#L1047 Digging a little bit further, it looks like a bug when iceweasel's telemetry code tries to deal with an X.509v3 certificate which has no extensions. I've reported the problem uptsream at https://bugzilla.mozilla.org/show_bug.cgi?id=1165911 In the meantime, i note that the end-entity certificate offered by mentors.debian.net is provided twice in the TLS handshake (which is not advisable), and it has no X.509v3 extensions. The Debian CA (cc'ing debina-ad...@debian.org here), which issued the mentors.debian.net certificate, should probably re-issue the certificate with some v3 extensions in it, at least: * basicConstraints (CA:False) * keyUsage (digitalSignature at least, keyEncipherment if you want to support RSA key exchange on mentors.debian.net) * extendedKeyUsage (TLS www server) * subjectAltName (mentors.debian.net) These are good ideas for certificate issuance anyway, and they would also fix the iceweasel segfault. please let me know if i can help diagnose or repair this further. Regards, --dkg Processed 156 CA certificate(s). Resolving 'mentors.debian.net'... Connecting to '185.22.221.46:443'... - Certificate type: X.509 - Got a certificate list of 4 certificates. - Certificate[0] info: - subject `CN=mentors.debian.net', issuer `O=Debian,CN=ca.debian.org,EMAIL=debian-ad...@debian.org', RSA key 2048 bits, signed using RSA-SHA1, activated `2014-04-09 14:59:15 UTC', expires `2016-04-28 14:59:15 UTC', SHA-1 fingerprint `82906f583787e47bf78594160895becae554ee89' Public Key ID: cce07f1ed3b6cc884d372d5a1062c8915f342f03 Public key's random art: +--[ RSA 2048]+ | ..E.o | | ..o ..o | | +.o.+ .| | . =.. + | | . S . | | . o . | |. = B . | | * @ + | |. = +| +-+ -BEGIN CERTIFICATE- MIID5zCCAc+gAwIBAgIBcjANBgkqhkiG9w0BAQUFADBRMQ8wDQYDVQQKEwZEZWJp YW4xFjAUBgNVBAMTDWNhLmRlYmlhbi5vcmcxJjAkBgkqhkiG9w0BCQEWF2RlYmlh bi1hZG1pbkBkZWJpYW4ub3JnMB4XDTE0MDQwOTE0NTkxNVoXDTE2MDQyODE0NTkx NVowHTEbMBkGA1UEAxMSbWVudG9ycy5kZWJpYW4ubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA0KDLpr1TgPJOfINyuzz9Gl9Goad/y3WmzfkGsrwA 6yVdPsQgXCZifESHLvAQH4FsE+EA1HH8Xn7Lj0X5o5ovrm8Z1myFo07TZ6Ib66Fy ErZFQSZHSpZyeq4OqOLDFx3yp7kZrJgpB6uc+YFq3+6rnqGUuuujGWcYak9KV0oJ R9yPG4ezS/b7eOXeoGwvBiaMzTlqQsm2vJBMjn3CnjB2nVK694BxdpoStU6rybtK v8Y/m2p3HA/LVGbUE1kzarr8m4QmpyzympzH37y5nQuwUBW5PG8r2+mBSmaOqN5m yEiuTVqCWb0me1oddqPKIJm9p3QKJby+vg6AVTmfp8SX/wIDAQABMA0GCSqGSIb3 DQEBBQUAA4ICAQAalklKXmri2Kay0m4ps2QXZbDb1fY6mxFKMHAm98CNMla2jd5V +xYCCU2szsQSltpXZPN+PbRTI/pI7KVNOw6aopgcUIj5qYt5p9haJBmVl4aYdiNW NTlK/lcOCsHNrrU0QTqIJ7cR/sh0FY1joGr6jCmDt1lRbRVliZw8kTe4mLezHuQz vt5faNoiURxtAu7LagI8P+llOrNu5X3+Ww6cXwS8konZnGLslbBlcHYSo5b7MNN9 e75E1lXMITnO9ChUIA79shA1xcF8GcFdfEJUS1z5hnWWs21Rw5Y8c6NZXpth2sHT w0qXZXP4arCMAft8O0f2YxKvUGPBX0Gbbv66RXTPw6ztCiQFKol8o3Cv61plm15j jsfq5465ab62vOYctn8iwSUyU+LML2QuG0hnUBppOwxXwxqOtwYbO026tmsii3Ia UbpvxAs7n0saKzkG8zY94E6J4hqG/5JQoaeWSaQTRwfs5jShvg7BpkDotyCz94vm iuKYNJ1HghWv8LW7UUwxR6PZA7cRUclLNpJO3tX5ZxA7UtCUjuwvBuXDNr91Itq7 7JWQDrAKtMBZeC67mvZvhYOWw9Z9FlMUZ6OXu6GrEU4CVCqGj84SfolarOgrVeji std2VPFc4HXU/YDIp7gCCM0WL1DaOF9Ba58B08mmgN7H2Qa4IvvCBKl8tw== -END CERTIFICATE- - Certificate[1] info: - subject `CN=mentors.debian.net', issuer `O=Debian,CN=ca.debian.org,EMAIL=debian-ad...@debian.org', RSA key 2048 bits, signed using RSA-SHA1, activated `2014-04-09 14:59:15 UTC', expires `2016-04-28 14:59:15 UTC', SHA-1 fingerprint `82906f583787e47bf78594160895becae554ee89' -BEGIN CERTIFICATE- MIID5zCCAc+gAwIBAgIBcjANBgkqhkiG9w0BAQUFADBRMQ8wDQYDVQQKEwZEZWJp YW4xFjAUBgNVBAMTDWNhLmRlYmlhbi5vcmcxJjAkBgkqhkiG9w0BCQEWF2RlYmlh bi1hZG1pbkBkZWJpYW4ub3JnMB4XDTE0MDQwOTE0NTkxNVoXDTE2MDQyODE0NTkx NVowHTEbMBkGA1UEAxMSbWVudG9ycy5kZWJpYW4ubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA0KDLpr1TgPJOfINyuzz9Gl9Goad/y3WmzfkGsrwA 6yVdPsQgXCZifESHLvAQH4FsE+EA1HH8Xn7Lj0X5o5ovrm8Z1myFo07TZ6Ib66Fy ErZFQSZHSpZyeq4OqOLDFx3yp7kZrJgpB6uc+YFq3+6rnqGUuuujGWcYak9KV0oJ
Bug#785629: ITP: ruby-knife-windows -- Plugin that adds functionality to Chef's Knife CLI for configuring/interacting with nodes running Microsoft Windows
Package: wnpp Severity: wishlist Owner: Hleb Valoshka 375...@gmail.com * Package name: ruby-knife-windows Version : 0.8.4 Upstream Author : Seth Chisamore schis...@chef.io * URL : https://github.com/chef/knife-windows * License : Apache-2.0 Programming Lang: Ruby Description : Plugin that adds functionality to Chef's Knife CLI for configuring/interacting with nodes running Microsoft Windows This plugin adds additional functionality to the Chef Knife CLI tool for configuring/interacting with nodes running Microsoft Windows. The subcommands should function on any system running Ruby 1.9.3+ but nodes being configured via these subcommands require Windows Remote Management (WinRM) 1.0+.WinRM allows you to call native objects in Windows. This includes, but is not limited to, running PowerShell scripts, batch scripts, and fetching WMI variables. For more information on WinRM, please visit Microsoft's WinRM site. You will want to familiarize yourself with (certain key aspects) of WinRM because you will be writing scripts / running commands with this tool to get you from specific point A to specific point B. It usefull for those who works with chef. I plan to maintain it inside a ruby package extra team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783293: browsers using webkit crash with 'illegal instruction' on i586
On Mon, May 18, 2015 at 12:33:13PM +0100, Mark Hindley wrote: This patch at least fixes the environment variable so that JavaScriptCoreUseJIT=0 is honoured as a work-araound. If this is not working properly then it should be fixed upstream. You're using 2.4.x, right? I anyway wonder, what's the problem with the current code? Doesn't the part inside #if USE(CF) || OS(UNIX) handle this already? --- /tmp/VM.cpp 2015-05-18 12:04:42.183140915 +0100 +++ /tmp/VM-edited.cpp2015-05-18 12:16:41.478098153 +0100 @@ -135,6 +135,11 @@ } #if USE(CF) +#if OS(UNIX) +char* canUseJITString = getenv(JavaScriptCoreUseJIT); +if (canUseJITString) + return !canUseJITString || atoi(canUseJITString); +#endif // OS(UNIX) #if COMPILER(GCC) !COMPILER(CLANG) // FIXME: remove this once the EWS have been upgraded to LLVM. // Work around a bug of GCC with strict-aliasing. @@ -146,11 +151,6 @@ RetainPtrCFTypeRef canUseJIT = adoptCF(CFPreferencesCopyAppValue(canUseJITKey, kCFPreferencesCurrentApplication)); if (canUseJIT) return kCFBooleanTrue == canUseJIT.get(); -#endif - -#if USE(CF) || OS(UNIX) -char* canUseJITString = getenv(JavaScriptCoreUseJIT); -return !canUseJITString || atoi(canUseJITString); #else return true; #endif Berto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver
On Mon, May 18, 2015 at 3:28 AM, Owen Riddy owen.ri...@gmail.com wrote: I have not, but if I reboot the computer to an install of Jessie using fglrx the tinge is not present; and it appeared shortly after updating to Jessie + unstable. I'll try a few things with the cable report back if any of them have an impact, but the fglrx test suggests this problem is 100% fixable in software. Is it only the HDMI display that is problematic? It might be HDMI packet related. Does your display support audio? You can disable HDMI packets by setting radeon.audio=0 on the kernel command line in grub or at runtime using xrandr (e.g., xrandr --output HDMI-0 --set audio off). If that helps, can you try kernel 4.1? Alex Owen Riddy Email: owen.ri...@gmail.com Mobile: 040 163 2663 -- On 18 May 2015 at 12:56, Michel Dänzer mic...@daenzer.net wrote: On 16.05.2015 21:21, Owen Riddy wrote: Package: xserver-xorg-video-ati Version: 1:7.5.0-1+b1 Severity: important Dear Maintainer, I'm using the open source ati graphics with a 3-screen setup. After upgrading to unstable after the release of Jessie everything ran without issue. I booted into a seperate install of Jessie on the same computer that had flgrx installed, and after rebooting into unstable one of the screens (connected by a HDMI cable) has acquired a distinct green tinge that obscures whatever the screen is trying to show. It is a sort of neon green. This image is a graphical corruption bug - I took a screenshot using ksnapshot and on my other two screens the image dispaled withouth the green tinge. The tinge is not present: * In the BIOS * When GRUB is active * Early in the boot process when the kernel is still printing text * On a separate Debian install on the same hardware, using fglrx I tried changing the gamma settings of the screen and poking at the backlight settings but this did not help. Changing the gamma made a very slight difference but the tinge does nto seem to be caused by a rogue gamma setting. At some points during, eg, shutdown my screens go blank - usually this is black but at present the green tinged screen goes straight green. It sounds like there might be a problem with the physical display connection. Have you checked the connector seating at both ends, maybe unplugging and re-plugging them, or even using a different cable? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785329: lintian: Add check for CMake private files
On 2015-05-18 15:36, Lisandro Damián Nicanor Pérez Meyer wrote: On Sunday 17 May 2015 19:54:03 Niels Thykier wrote: Control: tags -1 moreinfo [snip] Hi, Thanks for working on this. And thank you all for looking at this :) You are welcome. :) We will need a test case in the test suite before merging it. Cool, I'll see to code it during this week (I might need some help though, is there an IRC channel for lintian?) We tend to use #debian-qa for lintian related chats. [...] More suggestions: * If you got any related documentation, please consider adding a Ref field listing it. Well, I wanted to make a question here: we have multiple URLs so what we did is adding a URL to a Debian's wiki page in which to put them all. But if somehow the Ref field supports more than one URL it might be better to add them there (although I like the Wiki idea). Indeed it does - by using comma as a separator. It also supports several short-hand references: * https://raw-link.com/to/some-where = raw link - Also supports FTP and file:// links, though these are less common. * /usr/share/doc/pkg/some/file = raw file link (alternative to using the file:// protocol) * #123456 = debian bug * program(1) = manpage link * policy 1.2, devref 1.2 = common Debian manual links - see /usr/share/lintian/data/output/manual-references for the list of supported links. Again, thanks *a lot* you all for your help and time :) :) Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785630: dpkg: Store a log of package installations
Package: dpkg Version: 1.17.25 Severity: wishlist Dear Maintainer, There should be a detailed log of which packages were installed when and which old versions (if any) were updated, with the exact times of the operations. The log should be preserved at least during a month. This would help to seek bugs in Debian. A GUI interface to this log would be also useful. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.10-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-7+b3 ii libc62.19-18 ii liblzma5 5.1.1alpha+20120614-2+b3 ii libselinux1 2.3-2 ii tar 1.27.1-2+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 1.0.9.9 -- 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#785209: apt-cacher-ng: provide a switch to retrieve stats information
Ah, now I see what you wanted... I should have read your second mail to the end. For me, the stats are the ones that are displayed at the end of index stuff processing. gotcha, but maybe some information also about the size of the cache itself would be useful (split per source? just the total size? dunno) The other stats are actually a cheap hack. apt-cacher.log contains the incoming/outgoing data counts and those are counted together, eventually grouped in ranges based on time stamps for the last hour, 24hours, week, etc.. also consider a more consistent output: last 24h is what we have on the acng report page and it creates a rolling stat info as it depends on when the command is executed; a report of every day from 00:00:00 to 23:59:59 would be awesome I guess this can be implemented in the same way with a dozen lines of perl code, or I could rip out the calculating code and make it reusable, providing an external tool. I guess I will try that soon. awesome, thanks! -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784565: [pkg-x2go-devel] Bug#784565: Bug#784565: nx-libs-lite: parts are derived from non-free code
On Thu, 14 May 2015 05:55:42 + Mike Gabriel mike.gabr...@das-netzwerkteam.de wrote: TL;DR; So here comes my actual question: are you (Brian Pane, Zachary Vonler, Gian Filippo Pinzari) ok with retroactively regarding pre-3.8.1 code of DXPC (that you probably all worked on at that time) as BSD-2-clause? Are you ok with others having taken or taking the pre-3.8.1 DXPC code and distribute it in a modified form? A yes from all of you as DXPC copyright holders is essential for the continuation of nx-libs development under a free license. This may also possibly be an issue for NXv4 in case parts of it have been derived from DXPC. Yes, I am fine with considering the license change to be retroactive to cover the time I was the maintainer. I have no objections to others distributing modified versions of that code. Zach
Bug#783293: browsers using webkit crash with 'illegal instruction' on i586
On Mon, May 18, 2015 at 03:28:09PM +0100, Mark Hindley wrote: I anyway wonder, what's the problem with the current code? Doesn't the part inside #if USE(CF) || OS(UNIX) handle this already? I think the current code returns from the line return kCFBooleanTrue == canUseJIT.get(); Hmmm... but that would be inside an #if USE(CF) block, I think that's only enabled in Mac. Berto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785618: [rt.debian.org #5802] Account for Fabian Greffrath
Fabian Greffrath dijo [Mon, May 18, 2015 at 03:33:37PM +0200]: Am Montag, den 18.05.2015, 15:06 +0200 schrieb Fabian Greffrath: Some 17 hours, maybe. But I was so nervous... ;) No, wait a moment. I have just seen that the key has been moved from the DM keyring to the DD keyring on May 10, i.e. 7 days before I got the confirmation email that my account has been created and thus 8 days before I tried to upload that package. Umh, 17 hours should be more than enough IMO. As for the Git commits: That's the time it hit our Git working tree, but all updates were pushed together at 2015.05.17. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785618: [rt.debian.org #5802] Account for Fabian Greffrath
On Mon, May 18, 2015 at 01:36:04PM +0200, Fabian Greffrath wrote: Am Sonntag, den 10.05.2015, 11:54 +0100 schrieb Jonathan Wiltshire (DAM): Keyring maintainers: please move the key from the maintainers keyring to the developers keyring. yesterday I've got a confirmation email that my account 'fabian' has just been created in the central LDAP database of the Debian project. and also stated If you applied for Debian Developer with uploading rights, you should be able to upload packages already. Since then, I have added the fab...@debian.org uid to my GPG key and sent it to the keyring.d.o. server. However, the first package I wanted to upload today was rejected with the following message: No keyring for fingerprint 22C17648A9526B84DF191C96CBEA8E970CCD59DF Have I done anything wrong? I'm not sure why this has been raised against debian-keyring; the key is in the debian-keyring.gpg file as far as I can see. http://anonscm.debian.org/cgit/keyring/keyring.git/commit/?id=70aedc987f2a8fd1380d19e5d72ae8c975288d0a noodles@kaufmann:~$ gpg --no-default-keyring \ --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \ --list-key 0xCBEA8E970CCD59DF pub 4096R/0CCD59DF 2014-10-23 [expires: 2016-10-22] uid Fabian Greffrath fab...@greffrath.com uid Fabian Greffrath fabian+deb...@greffrath.com sub 4096R/8E377AA0 2014-10-23 [expires: 2016-10-22] J. -- Web [ Every program is either trivial or it contains at least one ] site: http:// [ bug. ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 signature.asc Description: Digital signature
Bug#739104: debcheckout: should create a local tracking branch for pristine-tar
Hello On Mon, 18 May 2015 00:42:57 +0900 Hideki Yamane henr...@debian.org wrote: I've made tiny workaround patch for this issue (and more for with upstream branch). Could you check it, please? This is good start. But it can be improved: Instead of using 'git checkout', I think you can setup the branches with 'git branch --track'. E.g. 'git branch --track pristine-tar remotes/origin/pristine-tar' An alternative to run 'cd $wcdir' in the forked shell script is to run cd within the Perl script: use Cwd; my $dir = cwd(); chdir($wcdir) || die; system(qw/git whatever/) or die system git whatever failed: $?; chdir($dir); # go back This way, you have a better control of the forked command: one command in one system call enables you to check for error as shown above. One last trick: calling system with an array avoid forking a shell: the command is run directly, thus you avoid subtitutions problems with bash. Feel free to get back to me if I was not clear enough. Hope this helps -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785602: libcairo2: version 1.14.2-2 causing glyph corruption in iceweasel
Emilio Pozuelo Monfort wrote on 18/05/15 20:33: Control: notfound -1 1.14.0-2.1 Control: found -1 1.14.2-2 On 18/05/15 10:47, Arthur Marsh wrote: Package: libcairo2 Version: 1.14.0-2.1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Upgrading libcairo2 and related packages to 1.14.2-2 caused glyph corruption in iceweasel. * What exactly did you do (or not do) that was effective (or ineffective)? Downgrading libcairo2 and related packages to 1.14.0-2.1 resolved the problem. Can you bisect this and report the bug upstream? Emilio I did a local build using: git checkout -b build 1.14.2 ./autogen.sh --enable-glesv2 --prefix=/usr and using the library built that way seems fine. I could try rebuilding the Debian package from the Debian source package for 1.14.2-2 Arthur. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785618: [rt.debian.org #5802] Account for Fabian Greffrath
Fabian Greffrath dijo [Mon, May 18, 2015 at 02:04:07PM +0200]: Am Montag, den 18.05.2015, 12:51 +0100 schrieb Jonathan McDowell: noodles@kaufmann:~$ gpg --no-default-keyring \ --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \ --list-key 0xCBEA8E970CCD59DF pub 4096R/0CCD59DF 2014-10-23 [expires: 2016-10-22] uid Fabian Greffrath fab...@greffrath.com uid Fabian Greffrath fabian+deb...@greffrath.com sub 4096R/8E377AA0 2014-10-23 [expires: 2016-10-22] Ah, I have set the Uploaders field to my fab...@debian.org account and the updated key which contains this added uid has not yet been merged into debian-keyring. Does this make sense? It should not make any difference, we deal with the key, and put the key as a whole in the keyring. Having or lacking specific identities should make no difference. How long did you wait after the keyring was pushed before attempting your upload? Maybe the changes had not yet propagated. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781054: packaging python-dockerpty
On 17 May 2015 at 20:07, Jason Pleau ja...@jpleau.ca wrote: retitle 781054 ITP: python-dockerpty -- pseudo-tty handler for docker Python client owner 781054 ja...@jpleau.ca thanks -- Hi Felipe, I'll package this to help you with docker-compose. I have a working package right now, it seems to work well! Great! If you need sponsoring I am available to do that. There might be more work required to get the package into Debian: dockerpty's test suites require behave and expects, two python modules that are not in Debian right now. Will see what I can do about those too :) Maybe we can have a non-testsuite-enabled dockerpty in Debian and then upload the missing dependencies and enable the suite? My offer for sponsorship extends to these python modules as well. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736398: gap-dev: multi-architecture support
On Sun, Jun 29, 2014 at 11:08:34PM +0200, Bill Allombert wrote: On Sat, Feb 08, 2014 at 07:57:29PM +0100, Jerome BENOIT wrote: But /usr/share/gap/pkg/GAP PKG/bin - ../../../../lib/gap/pkg/GAP PKG/bin /usr/lib/gap/pkg/GAP PKG/bin/multiarch triplet - ../../../multiarch triplet/gap/pkg/GAP PGK sounds a good compromise. To start with GAP itself, I plan to add a symlink in GAP 4r7p5, /usr/lib/gap/bin/$(GAParch) - /usr/lib/$(multiarch triplet)/gap/bin and make sure packages like IO can be compiled without patching the configure system. Unfortunately some packages like Browse currently expect a file sysinfo.gap-CONFIG, so I will probably add it to GAP 4r7p8. CONFIG is normaly either default64 or default32, but this does not seem suitable for Debian, so maybe I will pick something else. Maybe 'debian'. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783293: browsers using webkit crash with 'illegal instruction' on i586
On Mon, May 18, 2015 at 05:18:59PM +0300, Alberto Garcia wrote: On Mon, May 18, 2015 at 12:33:13PM +0100, Mark Hindley wrote: This patch at least fixes the environment variable so that JavaScriptCoreUseJIT=0 is honoured as a work-araound. If this is not working properly then it should be fixed upstream. Yes You're using 2.4.x, right? Yes, packages from current jessie I anyway wonder, what's the problem with the current code? Doesn't the part inside #if USE(CF) || OS(UNIX) handle this already? I think the current code returns from the line return kCFBooleanTrue == canUseJIT.get(); ie it returns the application default. The env variable never gets checked. My patch just reorders and allows JavaScriptCoreUseJIT to override the app default, if set. Mark -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785426: RFS: cv/0.6-1 [ITP] -- cv - Coreutils (progress) Viewer)
Hi guys, On Mon, 2015-05-18 at 14:24 +0200, Christoph Egger wrote: I'll give it a look shortly Thank you ;) probably not that one, right? OMG, I missed that line ... Additionally I noticed there's already a package shipping /usr/bin/cv: radiance: /usr/bin/cv maybe you can use a different name? Let me CC the author to discuss the name issue ... Xfennec (the author of cv): In fact there is a package named radiance in debian archive, which includes a executable named cv. So this is a conflict again... The description of cv I wrote in control file is Coreutils (progress) Viewer. Well, Xfennec, can we pick a new name for it ? And please give your opinion. Thank you both :-) -- Regards, C.D.Luminate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785602: libcairo2: version 1.14.2-2 causing glyph corruption in iceweasel
I'm not seeing the problem using 1.14.2-2 built from Debian source on my machine. I'll try re-installing the 1.14.2-2 package from the Debian repositories and see if the problem is reproducible. After re-installing 1.14.2-2 from the Debian repositories and restarting iceweasel I can't reproduce the original problem, so please close the bug for now. Arthur. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785418: [Pkg-mpd-maintainers] Bug#785418: mpd: port 6600 is exposed to non-localhost despite `bind_to_address localhost`
Hi, The default mpd.socket unit makes mpd available via both IPv4 and IPv6 on all interfaces, so you'll likely want to customize the ListenStream directive in a local copy. Thanks for your hint, I found the file, changed the directive in question to ListenStream=localhost:6600 and probably through systemctl reenable mpd.socket, I managed to apply the change. I guess I'm not systemd savvy :-) Oh, it's (relatively) new for all of us... Just in case you changed the file in /lib/systemd/system/... (instead of creating a copy in /etc), have a look at Example 2 at http://www.freedesktop.org/software/systemd/man/systemd.unit.html#idm139689694041952 for proper ways of doing this as the change to the file in /lib will be overwritten without notice upon the next package upgrade. I'm not sure if this classifies as systemd common knowledge that we still need a little time to thoroughly grasp, or if a helpful comment in the mpd sample configuration is called for? A comment would probably save this pitfall from some mpd users that have proviously only used non-systemd Debian. Care to make a suggestion? Florian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785457: cloud.debian.org: AMI don't need getty
Ognyan, Can you please post a a process list of the getty processes you see in the Amazon hvm ? I am not aware of all the modifications made to the Debian AWS but according to http://0pointer.de/blog/projects/serial-console.html: Two VTs are handled specially by the auto-spawning logic: firstly tty1 gets special treatment: if we boot into graphical mode the display manager takes possession of this VT. If we boot into multi-user (text) mode a getty is started on it -- unconditionally, without any on-demand logic[2]. My understanding of that applied to Xen virtualization platform that Amazon uses, is that systemd will *always* start a getty on the default system console, which for Xen will be /dev/hvc0 instead of /dev/tty1 Actually you *want* to have this one getty started, as this is where your rescue console will be. Now if you have more than one getty started, then there is indeed room for improvement. Emmanuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785457: cloud.debian.org: AMI don't need getty
На 18.05.2015 в 17:17, Emmanuel Kasper написа: Can you please post a a process list of the getty processes you see in the Amazon hvm ? Now if you have more than one getty started, then there is indeed room for improvement. I already fixed my EC2 instance, so just now I artificially unmasked these services to show what processes are in current 8.0.0 HVM AMI: 26510 tty1 Ss+0:00 232 15595 1948 0.0 /sbin/agetty --noclear tty1 linux 26512 tty6 Ss+0:00 032 15595 1916 0.0 /sbin/agetty --noclear tty6 linux 26513 tty5 Ss+0:00 032 15595 1912 0.0 /sbin/agetty --noclear tty5 linux 26514 tty4 Ss+0:00 032 15595 1988 0.0 /sbin/agetty --noclear tty4 linux 26515 tty3 Ss+0:00 032 15595 1912 0.0 /sbin/agetty --noclear tty3 linux 26516 tty2 Ss+0:00 032 15595 1908 0.0 /sbin/agetty --noclear tty2 linux 26546 hvc0 Ss+0:00 032 12623 1772 0.0 /sbin/agetty --keep-baud 115200 38400 9600 hvc0 vt102 26548 ttyS0Ss+0:00 032 12623 1716 0.0 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt102 All the best, Ognyan signature.asc Description: OpenPGP digital signature
Bug#785628: ITP: ruby-knife-solo -- knife-solo adds a handful of commands that aim to make working with chef-solo as powerful as chef-server.
Package: wnpp Severity: wishlist Owner: Hleb Valoshka 375...@gmail.com * Package name: ruby-knife-solo Version : 0.4.2 Upstream Author : m...@schaffer.me * URL : http://matschaffer.github.io/knife-solo/ * License : MIT Programming Lang: Ruby Description : knife-solo adds a handful of commands that aim to make working with chef-solo as powerful as chef-server. knife-solo adds a handful of commands that aim to make working with chef-solo as powerful as chef-server. It currently adds 5 subcommands to knife: * knife solo init is used to create a new directory structure (i.e. “kitchen”) that fits with Chef's standard structure and can be used to build and store recipes. * knife solo prepare installs Chef on a given host. It's structured to auto-detect the target OS and change the installation process accordingly. * knife solo cook uploads the current kitchen (Chef repo) to the target host and runs chef-solo on that host. * knife solo bootstrap combines the two previous ones (prepare and cook). knife-solo also adds --solo command line option and +knife+ configuration parameter to knife bootstrap that can be used for triggering “knife solo bootstrap” instead of the normal template based chef-client bootstrap. * knife solo clean removes the uploaded kitchen from the target host. It usefull for those who works with chef. I plan to maintain it inside a ruby package extra team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775812: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
Thank you Tim, Deepee On Sat, May 16, 2015 at 3:42 PM, Tim debian-bugrep...@quuk.eu wrote: On Tue, 2015-05-12 at 14:03 -0400, Deepee Khosla wrote: Now I've discovered your bug report, but I'm still not sure what action I should take to get my laptop to power down. Do you have any advice for me? As the reporter of this bug, Miguel Ortiz Lombardía, on Mon, 30 Mar 2015 23:28:53 +0200 wrote: [...] I must say that eventually after much reading I solved my problem by tweaking the BIOS and making sure that Wake on WLAN was inactive... I still don't understand why this manipulation had not been necessary previously, but anyway, that's not important to me : I don't need/want to wake up my computer when a known wifi becomes available... I can confirm that disabling “Wake on WLAN” in the notebook's BIOS settings solved the problem for me as well. If you really rely on this option, then I can only help you by advising you to look into the notebook's wireless or wired drivers. I have the suspicion that the bug is caused by one of these. Hope this helps. Best, Tim
Bug#785631: vagrant VERSION contains newline, breaking downloads
Package: vagrant Version: 1.7.2+dfsg-2 Severity: important Dear Maintainer, The 1.7.2+dfsg-2 package from collab-maint git tree contains a bug where the Debian patch 0003-VERSION-fallback-to-usr-share-vagrant-version.txt.patch doesn't .chomp the version string read from debian-specific directory. In effect the version is 1.7.2\n which breaks all instances of vagrant box or vagrant up which results in downloading packages. A patch against git master was sent in private, it adds a .chomp call to the fallback in the obvious spot. -- System Information: Debian Release: jessie/sid APT prefers wily-updates APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), (100, 'wily-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-17-generic (SMP w/8 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vagrant depends on: ii bsdtar 3.1.2-11 ii bundler1.7.4-1 ii curl 7.38.0-3ubuntu3 ii openssh-client 1:6.7p1-6 ii ruby 1:2.1.0.4ubuntu1 ii ruby-childprocess 0.5.2-1ubuntu1 ii ruby-erubis2.7.0-3 ii ruby-i18n 0.6.11-1 ii ruby-listen2.4.0-4 ii ruby-log4r 1.1.10-4 ii ruby-net-scp 1.2.1-2 ii ruby-net-sftp 1:2.1.2-3 ii ruby-net-ssh 1:2.9.2-2 ii ruby-nokogiri 1.6.6.2+ds-2 ii ruby-rb-inotify0.9.5-1 ii ruby-rest-client 1.6.7-6 vagrant recommends no packages. Versions of packages vagrant suggests: ii virtualbox 4.3.26-dfsg-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776563: DejaVu is not the only font that makes printing fail
Dear All, another me too from my side - unfortunately without any new info. I upgraded from wheezy to jessie recently and it did work before the upgrade. I tried different monospace fonts/sizes as suggested but no go, I also have the truncation issue and also in my case printing from editors (or textfiles directly via lpr) works without problems. cheers Georg
Bug#761052: gap-gapdoc: BibTeX's names Jr part issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, thanks for the update. On 18/05/15 14:58, Bill Allombert wrote: reassign 761052 gap-guava quit On Wed, Sep 10, 2014 at 12:03:58PM +0200, Jerome Benoit wrote: Package: gap-gapdoc Version: 1.5.1-1 Severity: normal Tags: upstream Dear Maintainer, I was encountering this issue while I was trying to generate thedocumentation for the GUAVA GAP package: it appears that the encountered issue is caused by the Jr of the fifth name in the author entry of the last reference, aka TSSFC04: a closer look (Print within the gapdoc code itself) shows that the non ASCII char is introduced and ultimately introduces a `fail' that break the documentation composition. Please find in attachment an expurged material that reproduces the bug. As second thought, I will not be surprised that in fact GAPDoc does not fully support the Jr part of BibTeX's names as described in section 18 in the document entitle BibTeXing by Oren Patashnik (aka `btxdoc.pdf'). Dear Jérome, I have contacted the upstream authors, and they told me that this was not a bug in GAPDoc but in GUAVA, for not following the GAPDoc documentation, and that this problem will be fixed in next release of the GUAVA package. So I reassign this bug to gap-guava. I have nothing against the reassignment. I hope it will not become endless: the main issue here is that GAPDoc does not fully support BibTeX features: it sounds that the issue is exported. Whatever, let wait for the next GUAVA. Cheers, Jerome Cheers, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEbBAEBAgAGBQJVWfLyAAoJEIC/w4IMSybjR5gH92ebQDP/mB+tZ/fwXxFnoJeb PrZBu7CkvjFXXzdFMUNvyHaTp36t9WtSRLYWGQgmnSg1uTk7TXj5HcFMBVOFgyNr l0aS8b9hK4y+miwhnq7ll0i6Fkx/0NCelYFryD9kbVIHJBbD/mYViu1C4U41I3/q zUbGn1YmaaF+XuM7SIYQ1waIBOBLvhmQoGgoh8mpzL2VAMART52tqgqwlg5YHa0H I/qv5tJdeC+gOAUaczP+oRqHF920ciXpcMG8bkIq5TjFGJpnbhSFsSwNY06bNazW 8ByhE0uqkaK6i4pxI65xYptcaJKIuRxGx1zwlQCj90LWp8kjYGPRjg4xUwPKMw== =9cxy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785384: arduino-mk: attiny example does not build
Package: arduino-mk Version: 1.3.4-1 Followup-For: Bug #785384 Hello, FWIW the example does build with the attiny core from https://github.com/damellis/attiny/ (the 1.0 branch). I still have no idea how to install the core system-wide in /usr/share but installing it in user sketchbook does work. I rebuilt the ATtinyBlink example with it and uploaded it with micronucleus by hand. Automated support for micronucleus is not available afaict. My board has USB on pin 3 and led on pin 1 so I had blinking USB bus instead of led after uploading. Verifies that uploads work all right. Unfortunately, not all the files in the attiny core project have clear licensing terms so including this core in Debian would be problematic. Thanks Michal -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (910, 'testing'), (900, 'stable'), (410, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 3.18.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages arduino-mk depends on: ii arduino-core 2:1.0.5+dfsg2-4 ii python 2.7.9-1 ii python-serial 2.6-1.1 arduino-mk recommends no packages. arduino-mk 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#775760: reopening, needs a backport
reopen 775760 tags 775760 + jessie stretch found 775760 2.5.30+deb8u4 notfound 775760 2.5.31 thanks Ganneff doko__: it needs a lintian backport to arrive in jessie-backports, then dsa can install it, then we can add checks from it Ganneff (or not have it reject based on errors, whatever the bug is/was) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784334: [PKG-Openstack-devel] Bug#784334: Inaccessible emergency shell on serial console
Hi Thomas
Thomas Goirand tho...@goirand.fr writes:
Hi Gaudenz,
Thanks for this useful bug report.
Do you know how to tweak systemd to use tty1 instead? Is it possible to
just add something on the command line?
I investigated this some more and thin I found the optimal solution
which keeps regular console output on the serial console but starts the
emergency shell on tty0.
To do this the ExecStart setting of the emergency.service systemd unit
needs to be overriden. Create a file
/etc/systemd/system/emergency.service.d/console.conf with the following
content:
[Service]
ExecStart=
ExecStart=-/bin/sh -c /sbin/sulogin /dev/tty0; /bin/systemctl --fail
--no-block default
This first reset the ExecStart setting and then sets it to start the
emergency shell on tty0.
The same should be done for rescue.service. The first attached patch
implements this for both services.
During my investigation I also found several other things that are
suboptimal about the boot setup:
1. The kernel is booted with the quiet commandline parameter. While this
is a nice setting for physical hardware (especially laptop/desktops)
to not clutter the boot I think this is suboptimal for cloud images
where you only access the boot logs in case of problems. There the
quiet parameter might suppress usefull output.
2. There are two copies of extlinux.conf one in / and another one in
/boot/extlinux. There should only be one to not confuse users.
3. extlinux is installed into / for no good reason. Why not remove all
the copying of extlinux.conf to / and just install to /boot/extlinux.
This also avoids additional files in /
4. The kernel and initrd.img are referenced in extlinux.conf by their
full path in /boot. This leads to problems if the kernel is updated
to an ABI incompatible new version because then the filename changes.
This can be avoided by just referencing the symlinks in /.
The second attached patch fixes these issues.
BTW, why are you using extlinux instead of grub2 which is the standard
bootloader in Debian? I would prefer the images to be as similar to the
default install as possible. With grub also the kernel update issue
would completely go away because update-grub takes care of this.
And one more thing. Why is the string 7.0.0-3 hardcoded into the image
filename? I would suggest to either just use debian-${RELEASE}-amd64 or
read the version number from /etc/debian_version (after debootstrap of
course and read from ${MOUNT_DIR}/etc/debian_version, we don't want the
version of the build host in the filename).
Gaudenz
From 330eb695e0ec3f5b6519ccb2218ad4019d7f0a0e Mon Sep 17 00:00:00 2001
From: Gaudenz Steinlin gaud...@soziologie.ch
Date: Mon, 18 May 2015 16:24:43 +0200
Subject: [PATCH 1/2] Start rescue and emergency shells on tty1
By default the rescue and emergency shell are started on the boot
console. This is ttyS0 on this image in order to have the boot output on
the serial console which is accessible by nova console-log. But there
is no input device connected to this console, so the shells there are
pretty useless. On the other hand tty0 is accessible via the spice or
VNC console.
Closes: #784334
---
build-openstack-debian-image | 9 +
1 file changed, 9 insertions(+)
diff --git a/build-openstack-debian-image b/build-openstack-debian-image
index e503fa9..bd7824f 100755
--- a/build-openstack-debian-image
+++ b/build-openstack-debian-image
@@ -358,6 +358,15 @@ chroot ${MOUNT_DIR} update-initramfs -u
rm ${MOUNT_DIR}/var/cache/apt/archives/*.deb
+# Set console for emergency and rescue shells
+SYSTEMD_DIR=${MOUNT_DIR}/etc/systemd/system/
+for service in emergency.service rescue.service ; do
+mkdir ${SYSTEMD_DIR}/${service}.d
+echo '[Service]
+ExecStart=
+ExecStart=-/bin/sh -c /sbin/sulogin /dev/tty0; /bin/systemctl --fail --no-block default' ${SYSTEMD_DIR}/${service}.d/console.conf
+done
+
###
### Setting-up extlinux ###
###
--
2.1.4
From caee39deebc111a0dfa40f4b6579c40f43a8 Mon Sep 17 00:00:00 2001
From: Gaudenz Steinlin gaud...@soziologie.ch
Date: Mon, 18 May 2015 16:27:35 +0200
Subject: [PATCH 2/2] Improved extlinux configuration
* Only install extlinux in /boot/extlinux. Some parts were installed in
/ only, others in both locations.
* Remove the quiet flag from the standard boot command. This is usefull
on desktops to not clutter the boot screen, but not on a cloud image.
* Use symlinks to kernel and initrd. This allows seamless kernel
upgrades.
---
build-openstack-debian-image | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/build-openstack-debian-image b/build-openstack-debian-image
index bd7824f..d318810 100755
--- a/build-openstack-debian-image
+++ b/build-openstack-debian-image
@@ -370,19 +370,14 @@ done
###
### Setting-up extlinux ###
###
-KERNEL=`chroot ${MOUNT_DIR} find boot -name 'vmlinuz-*'`
Bug#782942: Please provide a python3 module
Hi,
On Sun, Apr 19, 2015 at 03:02:39PM -0400, Paul Tagliamonte wrote:
Package: python-hl7
Severity: wishlist
User: py3porters-de...@lists.alioth.debian.org
Usertags: patchme-python3
...
As part of an ongoing process to migrate as much as we can to Python 3 to
ensure we're ready for our glorious Python 3 future, please build a Python 3
module.
This is fixed in SVN.
If you need help doing this, please feel free to contact the Debian Python
Modules Team (DPMT), and we can help! If you would welcome a NMU, please do
let the team know (py3porters-de...@lists.alioth.debian.org).
I have one remaining question: setup.py installs also a wrapper script
to /usr/bin and it does it for both, Python and Python3, with the same name.
In the python3 case it looks like
#!/usr/bin/python3
# EASY-INSTALL-ENTRY-SCRIPT: 'hl7==0.3.2','console_scripts','mllp_send'
__requires__ = 'hl7==0.3.2'
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.exit(
load_entry_point('hl7==0.3.2', 'console_scripts', 'mllp_send')()
)
for Python just the #! line points to /usr/bin/python. This script would
create a conflict between the python-hl7 and python3-hl7 package which is
unneeded. Do you have some advise what to do in cases like this?
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785632: vagrant is broken by ruby-timers 4.0.1-1
Package: vagrant Version: 1.7.2+dfsg-2 Severity: important Dear Maintainer, Installing vagrant along with updated version if ruby-timers leads to this crash on startup: zyga@fx:~/checkbox$ vagrant Vagrant experienced a version conflict with some installed plugins! This usually happens if you recently upgraded Vagrant. As part of the upgrade process, some existing plugins are no longer compatible with this version of Vagrant. The recommended way to fix this is to remove your existing plugins and reinstall them one-by-one. To remove all plugins: rm -r ~/.vagrant.d/plugins.json ~/.vagrant.d/gems Note if you have an alternate VAGRANT_HOME environmental variable set, the folders above will be in that directory rather than your user's home directory. The error message is shown below: Could not find gem 'timers (~ 1.1.0) ruby', which is required by gem 'vagrant (= 1.7.2) ruby', in any of the sources. Downgrading to 1.0.1-1 fixes the issue. -- System Information: Debian Release: jessie/sid APT prefers wily-updates APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), (100, 'wily-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-17-generic (SMP w/8 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vagrant depends on: ii bsdtar 3.1.2-11 ii bundler1.7.4-1 ii curl 7.38.0-3ubuntu3 ii openssh-client 1:6.7p1-6 ii ruby 1:2.1.0.4ubuntu1 ii ruby-childprocess 0.5.2-1ubuntu1 ii ruby-erubis2.7.0-3 ii ruby-i18n 0.6.11-1 ii ruby-listen2.4.0-4 ii ruby-log4r 1.1.10-4 ii ruby-net-scp 1.2.1-2 ii ruby-net-sftp 1:2.1.2-3 ii ruby-net-ssh 1:2.9.2-2 ii ruby-nokogiri 1.6.6.2+ds-2 ii ruby-rb-inotify0.9.5-1 ii ruby-rest-client 1.6.7-6 vagrant recommends no packages. Versions of packages vagrant suggests: ii virtualbox 4.3.26-dfsg-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785426: RFS: cv/0.6-1 [ITP] -- cv - Coreutils (progress) Viewer)
lumin cdlumin...@gmail.com (18/05/2015 14:37) : Hi guys, On Mon, 2015-05-18 at 14:24 +0200, Christoph Egger wrote: I'll give it a look shortly Thank you ;) probably not that one, right? OMG, I missed that line ... Additionally I noticed there's already a package shipping /usr/bin/cv: radiance: /usr/bin/cv maybe you can use a different name? Let me CC the author to discuss the name issue ... Xfennec (the author of cv): In fact there is a package named radiance in debian archive, which includes a executable named cv. So this is a conflict again... The description of cv I wrote in control file is Coreutils (progress) Viewer. Well, Xfennec, can we pick a new name for it ? And please give your opinion. Thank you both :-) Hi, Well, the best tip I can give is the following GitHut issue: https://github.com/Xfennec/cv/issues/8 The summary of this is that I'm pleased with the current name, and think the name conflict is quite unlikely, and is easy to deal with simple aliases. But in the other end, I'm completely OK with a rename of the project if a good name is found (short, pronounceable, possibly explicit, …) Julien. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762132: fglrx-driver: Update to 1:14.6~ga14.201-1 amd64: Mouse cursor gone
Same problem here. Jessie clean install, now working with integrated grapics card --px-igpu but no ATI accel.
Bug#785480: ITP: bcg729 -- ITU G.729 Annex A compatible audio codec
On Sat, May 16, 2015, at 18:01, Felix Lechner wrote: Bcg729 is an open source implementation of the ITU G729 Annex A speech codec. Written in C 99, the library is fully portable. It runs on many platforms, including ARM and x86. . Bcg729 supports concurrent channels encoding/decoding for multi call application such as conferencing. . The project was developed as part of mediastreamer2, Linphone's media processing engine. It also contains the glue forintegration into Linphone/mediastreamer2. G.729 is a patent minefield, and some of them are actively enforced last time I checked. Has the situation changed? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785618: [rt.debian.org #5802] Account for Fabian Greffrath
On Mon, May 18, 2015 at 02:04:07PM +0200, Fabian Greffrath wrote: Am Montag, den 18.05.2015, 12:51 +0100 schrieb Jonathan McDowell: noodles@kaufmann:~$ gpg --no-default-keyring \ --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \ --list-key 0xCBEA8E970CCD59DF pub 4096R/0CCD59DF 2014-10-23 [expires: 2016-10-22] uid Fabian Greffrath fab...@greffrath.com uid Fabian Greffrath fabian+deb...@greffrath.com sub 4096R/8E377AA0 2014-10-23 [expires: 2016-10-22] Ah, I have set the Uploaders field to my fab...@debian.org account and the updated key which contains this added uid has not yet been merged into debian-keyring. Does this make sense? I do not believe the FTP infrastructure cares at all about the UIDs on the key. It's possible that there's some confusion about the fact your key has moved from the DM to the DD keyring, but ftp-master is going to have to comment about what's going on here. From a keyring-maint perspective your key is correctly in the debian-keyring. J. -- /-\ | If I save time, when do I get it |@/ Debian GNU/Linux Developer |back? \- | signature.asc Description: Digital signature
Bug#785622: [Pkg-xfce-devel] Bug#785622: xfce4: black screen after resume from suspend
On lun., 2015-05-18 at 14:19 +0200, Manolo Díaz wrote: After that, I'm still able to change to a vt, but things like 'xrandr --output HDMI-0 --auto' fails with 'Configure crtc 0 failed'. That looks more like a problem in the driver or in Xorg. It might help to have more detailed Xorg.0.log and xrandr output. Perhaps is worth to know: - TV connected through HDMI port as monitor. - No power manager application. Suspend is done via echoing 'mem' to /sys/power/state. - DPMS disabled. - Systemd and policy-kit aren't installed, not even systemd-shim. - The above configuration worked fine with Xfce 4.10 for months. Can you confirm Xfce was the only changed thing in that upgrade round? - Enable/disable 'Configure new displays when connected' doesn't work. I'm just assuming it gives the same “Configure CRTC 0 failed” error, actually. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#785626: caja: lost preferences after upgrade
Package: caja Version: 1.8.2-4 Severity: normal Hello, on every upgrade of caja package, the file /usr/share/caja/ui/caja-navigation-window-ui.xml has overwritten thanks Pol -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages caja depends on: ii caja-common 1.8.2-4 ii desktop-file-utils0.22-1 ii gvfs 1.22.2-1 ii libatk1.0-0 2.16.0-2 ii libc6 2.19-18 ii libcairo2 1.14.0-2.1 ii libcaja-extension11.8.2-4 ii libexempi32.2.1-2 ii libexif12 0.6.21-2 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.5.2-4 ii libgail18 2.24.25-3 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libglib2.0-0 2.44.0-2 ii libglib2.0-data 2.44.0-2 ii libgtk2.0-0 2.24.25-3 ii libice6 2:1.0.9-1+b1 ii libmate-desktop-2-17 1.8.1+dfsg1-3 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libselinux1 2.3-2 ii libsm62:1.2.2-1+b1 ii libstartup-notification0 0.12-4 ii libunique-1.0-0 1.1.6-5 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxml2 2.9.1+dfsg1-5 ii libxrender1 1:0.9.8-1+b1 ii mate-desktop 1.8.1+dfsg1-3 ii shared-mime-info 1.3-1 Versions of packages caja recommends: ii gvfs-backends 1.22.2-1 Versions of packages caja suggests: ii engrampa 1.8.1+dfsg1-1 ii gstreamer0.10-tools 0.10.36-1.5 pn meld none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785329: lintian: Add check for CMake private files
On Sunday 17 May 2015 19:54:03 Niels Thykier wrote: Control: tags -1 moreinfo [snip] Hi, Thanks for working on this. And thank you all for looking at this :) We will need a test case in the test suite before merging it. Cool, I'll see to code it during this week (I might need some help though, is there an IRC channel for lintian?) The description might be needing a bit of rewording. How about: Info: This package contains a file in a path reserved solely for ttCMake/tt. This normally means you are shipping a ttFind/tt module. Libraries should not ship Find modules at all but Config files instead. . The Config files should be installed in the unversioned path usr/(lib/lt;archgt;|lib|share)/cmake/lt;namegt;*/ . By using CMake Config files in the unversioned path, the package will continue to work as expected when a new version of CMake is uploaded. Excellent! Admittedly, I presumed there was only one (valid) prefix and it was always usr. Indeed :) More suggestions: * If you got any related documentation, please consider adding a Ref field listing it. Well, I wanted to make a question here: we have multiple URLs so what we did is adding a URL to a Debian's wiki page in which to put them all. But if somehow the Ref field supports more than one URL it might be better to add them there (although I like the Wiki idea). Again, thanks *a lot* you all for your help and time :) -- perezmeyer: Gus no tiene inet :-( PabloOdorico: oh perezmeyer: te mando una copia de lo que hagamos esta noche PabloOdorico: de ultima mandame un loro del parque con una flash en la pata ;) Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#784854: MIA for Karolina Kalic karol...@resenje.org
On Mon, May 18, 2015 at 10:58:08AM +0200, Karolina Kalic wrote: Hi everybody, As I can remember, MIA team contacted me a while ago. And I explained that I can not continue my work for Debian at the moment. The packages should have been orphaned properly after that. I don't know what happened. I'm glad that someone wants to continue the work on unico. I don't have any objections. Thanks for the reply Karolina. There was a misunderstanding here, somebody decided to orphan the package in their own and later when Ricardo Mones from the MIA team orphaned it properly, he kept the first bug and merged it with his own orphaning but from the MIA team. Vincent probably overlooked the second orphaning bug and therefore his, understandable, request about following the MIA procedure. So please James Lu, feel free to adopt the package. Vincent or Dmitry feel free to sponsor it and Karolina, I hope you'll be able to be back in the project in the future! Ana on behalf of the MIA team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785623: mirror submission for mirror.sinavps.ch
Package: mirrors Severity: wishlist Submission-Type: new Site: mirror.sinavps.ch Type: leaf Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ IPv6: no Archive-upstream: ftp.ch.debian.org Updates: push Maintainer: Marco Naef i...@sinavps.ch Country: CH Switzerland Location: Zug, Switzerland Sponsor: SinaVPS http://sinavps.ch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785622: xfce4: black screen after resume from suspend
Package: xfce4 Version: 4.12.1 Severity: important Dear Maintainer, After that, I'm still able to change to a vt, but things like 'xrandr --output HDMI-0 --auto' fails with 'Configure crtc 0 failed'. Perhaps is worth to know: - TV connected through HDMI port as monitor. - No power manager application. Suspend is done via echoing 'mem' to /sys/power/state. - DPMS disabled. - Systemd and policy-kit aren't installed, not even systemd-shim. - The above configuration worked fine with Xfce 4.10 for months. - Enable/disable 'Configure new displays when connected' doesn't work. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.0.4 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xfce4 depends on: ii gtk2-engines-xfce 3.2.0-2 ii libxfce4ui-utils 4.12.1-2 ii orage 4.12.1-1+b1 ii thunar 1.6.8-2 ii xfce4-appfinder4.12.0-2 ii xfce4-mixer4.10.0-3+b1 ii xfce4-panel4.12.0-2 ii xfce4-session 4.12.1-2 ii xfce4-settings 4.12.0-2 ii xfconf 4.12.0-2+b1 ii xfdesktop4 4.12.1-2 ii xfwm4 4.12.2-3 Versions of packages xfce4 recommends: ii desktop-base 8.0.2 ii tango-icon-theme 0.8.90-5 pn thunar-volman none ii xfce4-notifyd 0.2.4-3+b1 pn xorg none Versions of packages xfce4 suggests: pn gtk3-engines-xfcenone pn xfce4-goodiesnone pn xfce4-power-manager none -- no debconf information -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785625: /usr/share/emacs/24.4/lisp/progmodes/ruby-mode.elc : insert encoding unknown to ruby
Package: emacs24-common Version: 24.4+1-5 Severity: normal When saving a file in ruby mode, the line # coding: utf-8-emacs is inserted as second line But ruby tries to interpret it and fails since utf-8-emacs is an unknown encoding (utf-8 works) ruby is ruby --version ruby 2.1.5p273 (2014-11-13) [x86_64-linux-gnu] -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (600, 'stable'), (500, 'proposed-updates'), (500, 'oldstable-proposed-updates'), (400, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages emacs24-common depends on: ii dpkg1.17.25 ii emacsen-common 2.0.8 ii install-info5.2.0.dfsg.1-6 emacs24-common recommends no packages. Versions of packages emacs24-common suggests: pn emacs24-common-non-dfsg none pn emacs24-el none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785618: [rt.debian.org #5802] Account for Fabian Greffrath
Am Montag, den 18.05.2015, 15:06 +0200 schrieb Fabian Greffrath: Some 17 hours, maybe. But I was so nervous... ;) No, wait a moment. I have just seen that the key has been moved from the DM keyring to the DD keyring on May 10, i.e. 7 days before I got the confirmation email that my account has been created and thus 8 days before I tried to upload that package. - Fabian signature.asc Description: This is a digitally signed message part
Bug#761052: gap-gapdoc: BibTeX's names Jr part issue
reassign 761052 gap-guava quit On Wed, Sep 10, 2014 at 12:03:58PM +0200, Jerome Benoit wrote: Package: gap-gapdoc Version: 1.5.1-1 Severity: normal Tags: upstream Dear Maintainer, I was encountering this issue while I was trying to generate thedocumentation for the GUAVA GAP package: it appears that the encountered issue is caused by the Jr of the fifth name in the author entry of the last reference, aka TSSFC04: a closer look (Print within the gapdoc code itself) shows that the non ASCII char is introduced and ultimately introduces a `fail' that break the documentation composition. Please find in attachment an expurged material that reproduces the bug. As second thought, I will not be surprised that in fact GAPDoc does not fully support the Jr part of BibTeX's names as described in section 18 in the document entitle BibTeXing by Oren Patashnik (aka `btxdoc.pdf'). Dear Jérome, I have contacted the upstream authors, and they told me that this was not a bug in GAPDoc but in GUAVA, for not following the GAPDoc documentation, and that this problem will be fixed in next release of the GUAVA package. So I reassign this bug to gap-guava. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785457: cloud.debian.org: AMI don't need getty
I'm a little confused, we should already be doing that for AWS images: https://github.com/andsens/bootstrap-vz/blob/f3be3e4543a37ef1af7b2b5193a8bb7b590d1b79/bootstrapvz/common/tasks/boot.py#L31 systemd does not use the /etc/inittab file. signature.asc Description: OpenPGP digital signature
Bug#785457: cloud.debian.org: AMI don't need getty
На 18.05.2015 в 16:43, Ognyan Kulev написа: I'm a little confused, we should already be doing that for AWS images: https://github.com/andsens/bootstrap-vz/blob/f3be3e4543a37ef1af7b2b5193a8bb7b590d1b79/bootstrapvz/common/tasks/boot.py#L31 systemd does not use the /etc/inittab file. Oh, actually it has code for jessie and =jessie. Probably it sets NAutoVTs=0 and ReserveVT=0 (I haven't checked the content of source logind.conf) but the reality is that getty processes exist in the official Jessie HVM AMI. All the best, Ognyan signature.asc Description: OpenPGP digital signature
Bug#785624: Timestamps in manpages generated makes builds non-reproducible
Source: doxygen Version: 1.8.9.1-3 Severity: normal Hi, the libqb build is currently not reproducible because the manpages generated from docs/man.dox include a timestamp in the .TH line: .TH qb_util_overview 3 Mon May 18 2015 Version 0.17.1 libqb \ -*- nroff -*- https://reproducible.debian.net/rb-pkg/unstable/amd64/libqb.html I've created a issue tag for this: https://wiki.debian.org/ReproducibleBuilds/TimestampsInManpagesGeneratedByDoxygen It would be nice if doxygen offered a way to disable the timestamps, or to use a fixed/predetermined timestamp. Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785618: [rt.debian.org #5802] Account for Fabian Greffrath
Am Montag, den 18.05.2015, 08:03 -0500 schrieb Gunnar Wolf: How long did you wait after the keyring was pushed before attempting your upload? Maybe the changes had not yet propagated. Some 17 hours, maybe. But I was so nervous... ;) - Fabian signature.asc Description: This is a digitally signed message part
Bug#785534: ITP: goobook -- access your Google contacts from command-line or mutt
Hi Christian, Thanks for your advice. I read these[1][2] two guidelines about writing Debian package descriptions which were very helpful. So I am going to change my package description to: Description: command-line interface to Google contacts GooBook is a command-line interface to Google contacts which supports: . * Searching contacts . * Adding new contacts . * Mutt integration . GooBook is written in Python and is designed for use with MUAs such as Mutt in the same way as abook. Cheers, Ilias [1] https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-desc-basics [2] https://people.debian.org/~bubulle/smith/descriptions.html On Mon, May 18, 2015 at 07:23AM, Christian PERRIER wrote: Quoting Ilias Tsitsimpis (i.tsitsim...@gmail.com): Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis i.tsitsim...@gmail.com * Package name: goobook Version : 1.6 Upstream Author : Christer Sjöholm goob...@furuvik.net * URL : https://pypi.python.org/pypi/goobook * License : GPL-3.0+ Programming Lang: Python Description : access your Google contacts from command-line or mutt goobook can be used to access your Google contacts from the command-line and from MUAs such as Mutt. It can be used from Mutt the same way as abook. The opackage description might need some review by debian-l10n-english (use of your). Apart from that no specific advice abou tthe package..:-) signature.asc Description: Digital signature
Bug#785457: cloud.debian.org: AMI don't need getty
On 18 May 2015 at 15:43, Ognyan Kulev ogn...@ognyankulev.com wrote: I'm a little confused, we should already be doing that for AWS images: https://github.com/andsens/bootstrap-vz/blob/f3be3e4543a37ef1af7b2b5193a8bb7b590d1b79/bootstrapvz/common/tasks/boot.py#L31 systemd does not use the /etc/inittab file. I am aware. Hence this file: https://github.com/andsens/bootstrap-vz/blob/f3be3e4543a37ef1af7b2b5193a8bb7b590d1b79/bootstrapvz/common/assets/systemd/logind.conf It is copied into the system when jessie or above is bootstrapped.
Bug#785457: cloud.debian.org: AMI don't need getty
but the reality is that getty processes exist in the official Jessie HVM AMI Ooh! And I know why :-) The HVM AMIs are generated from James Brombergers fork, which most likely does not have those adjustments. OK, the issue here is then that James and I need to get together and figure out this merge (which is rather big, hence the delay).
Bug#785622: [Pkg-xfce-devel] Bug#785622: xfce4: black screen after resume from suspend
On Monday, May 18 2015 at 14:57 UTC+2, Yves-Alexis Perez wrote: On lun., 2015-05-18 at 14:19 +0200, Manolo Díaz wrote: After that, I'm still able to change to a vt, but things like 'xrandr --output HDMI-0 --auto' fails with 'Configure crtc 0 failed'. That looks more like a problem in the driver or in Xorg. It might help to have more detailed Xorg.0.log and xrandr output. Please, see below. Perhaps is worth to know: - TV connected through HDMI port as monitor. - No power manager application. Suspend is done via echoing 'mem' to /sys/power/state. - DPMS disabled. - Systemd and policy-kit aren't installed, not even systemd-shim. - The above configuration worked fine with Xfce 4.10 for months. Can you confirm Xfce was the only changed thing in that upgrade round? No. Some xorg related packages were upgraded at the same time. See history.log (an excerpt) below for a complete list of that upgrade round. - Enable/disable 'Configure new displays when connected' doesn't work. I'm just assuming it gives the same “Configure CRTC 0 failed” error, actually. Yes. And there's something I find weird: the xrandr output is those cases is almost the same that when run on the desktop. TV dimensions seem missed, and there's no selected mode. Anyway, I forgot to mention that failures happen most of the time, but not always. I've been unable to find a pattern. Regards, Best Regards. xrandr output (desktop) == Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384 HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 886mm x 498mm 1920x1080 60.00*+ 50.0059.9430.0024.0029.9723.98 1920x1080i60.0050.0059.94 1600x900 59.98 1280x1024 60.02 1280x720 60.0050.0030.0059.9429.9724.0023.98 1024x768 60.00 800x600 60.32 720x576 50.00 720x576i 50.00 720x480 60.0059.94 720x480i 60.0059.94 640x480 60.0059.94 DVI-0 disconnected (normal left inverted right x axis y axis) VGA-0 disconnected (normal left inverted right x axis y axis) == xrandr output after failure (from vt) == Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384 HDMI-0 connected (normal left inverted right x axis y axis) 1920x1080 60.00 + 50.0059.9430.0024.0029.9723.98 1920x1080i60.0050.0059.94 1600x900 59.98 1280x1024 60.02 1280x720 60.0050.0030.0059.9429.9724.0023.98 1024x768 60.00 800x600 60.32 720x576 50.00 720x576i 50.00 720x480 60.0059.94 720x480i 60.0059.94 640x480 60.0059.94 DVI-0 disconnected (normal left inverted right x axis y axis) VGA-0 disconnected (normal left inverted right x axis y axis) = Xorg.0.log = X.Org X Server 1.17.1 Release Date: 2015-02-10 [ 16082.064] X Protocol Version 11, Revision 0 [ 16082.067] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [ 16082.069] Current Operating System: Linux alcyone 4.0.4 #1 SMP Sun May 17 21:15:40 CEST 2015 x86_64 [ 16082.069] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.0.4 root=/dev/sda2 ro [ 16082.075] Build Date: 04 May 2015 11:22:06PM [ 16082.077] xorg-server 2:1.17.1-2 (http://www.debian.org/support) [ 16082.080] Current version of pixman: 0.32.6 [ 16082.085]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 16082.085] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 16082.095] (==) Log file: /var/log/Xorg.0.log, Time: Mon May 18 15:26:00 2015 [ 16082.098] (==) Using config directory: /etc/X11/xorg.conf.d [ 16082.100] (==) Using system config directory /usr/share/X11/xorg.conf.d [ 16082.101] (==) ServerLayout serverlayout0 [ 16082.101] (==) No screen section available. Using defaults. [ 16082.101] (**) |--Screen Default Screen Section (0) [ 16082.101] (**) | |--Monitor default monitor [ 16082.101] (==) No device specified for screen Default Screen Section. Using the first device section listed. [ 16082.101] (**) | |--Device AMD Radeon R5 230 [ 16082.101] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [ 16082.101] (**) Option BlankTime 0 [ 16082.101] (**) Option StandbyTime 0 [ 16082.101] (**) Option SuspendTime 0 [ 16082.101] (**) Option OffTime 0 [ 16082.101] (==) Automatically adding devices [ 16082.101] (==) Automatically enabling devices [ 16082.101] (==) Automatically adding GPU devices [ 16082.101] (WW) The directory /usr/share/fonts/X11/misc does not exist. [
Bug#780409: Patch for ABySS on 32-bit architectures and license
Hi Shaun,
I just uploaded abyss with the patch proposed by Graham. It would be
great if you could evaluate the patch and take it over upstream - or
alternatively declare that ABySS should only be used on 64 bit
architectures and thus I would restrict the architectures accordingly.
BTW, autobuilding on Debian for non-free packages is disabled. I wonder
whether you might like to consider a DFSG-free license for ABySS.
Recently we (=the Debian Med team) were lucky to free some software in
our scope and it would be really great if ABySS could be distributed
under a free license as well. This would not only enable us to
distribute it with official Debian but also would enable us to detect
problems as described below way earlier.
Kind regards
Andreas.
On Fri, Mar 13, 2015 at 04:41:09PM +0200, Graham Inggs wrote:
Source: abyss
Version: 1.5.2-1
Severity: normal
Tags: patch
Hi maintainer
Version 1.5.2-1 of abyss FTBFS on 32-bit architectures (armhf, i386
and powerpc) in Ubuntu [1].
Previous versions built fine on all architectures.
I found there were a couple of places in the code that was
introduced in version 1.5.2 where size_t data type was used instead
of a fixed size data type.
I was able to get abyss 1.5.2-1 to build on amd64, i386 and armhf
with the attached patch in place and all unit tests passed.
I have no idea where to begin actually testing abyss itself.
Is it worth me uploading abyss with this patch into Ubuntu?
This will at least allow version 1.5.2-1 to migrate from proposed to
release.
Alternatively, is this software useful on a 32-bit system? The
other solution is for me to disable building for these
architectures.
Regards
Graham
[1] https://launchpad.net/ubuntu/+source/abyss/1.5.2-1
--- a/Common/StringUtil.h
+++ b/Common/StringUtil.h
@@ -106,7 +106,7 @@
return false;
}
-static inline size_t SIToBytes(std::istringstream iss)
+static inline unsigned long long SIToBytes(std::istringstream iss)
{
double size;
std::string units;
@@ -122,7 +122,7 @@
// no units given; clear fail flag
// and assume bytes
iss.clear(std::ios::eofbit);
- return (size_t)ceil(size);
+ return (unsigned long long)ceil(size);
}
if (units.size() 1) {
@@ -133,22 +133,22 @@
switch(tolower(units[0])) {
case 'k':
- size *= (size_t)110; break;
+ size *= (unsigned long long)110; break;
case 'm':
- size *= (size_t)120; break;
+ size *= (unsigned long long)120; break;
case 'g':
- size *= (size_t)130; break;
+ size *= (unsigned long long)130; break;
case 't':
- size *= (size_t)140; break;
+ size *= (unsigned long long)140; break;
default:
iss.setstate(std::ios::failbit);
return 0;
}
- return (size_t)ceil(size);
+ return (unsigned long long)ceil(size);
}
-static inline size_t SIToBytes(const std::string str)
+static inline unsigned long long SIToBytes(const std::string str)
{
std::istringstream iss(str);
return SIToBytes(iss);
--- a/Bloom/Bloom.h
+++ b/Bloom/Bloom.h
@@ -165,10 +165,10 @@
// bloom filter bits
size_t bits = endBitPos - startBitPos + 1;
- size_t bytes = (bits + 7) / 8;
+ unsigned long bytes = (bits + 7) / 8;
char buf[IO_BUFFER_SIZE];
for (size_t i = 0, j = 0; i bytes;) {
- size_t writeSize = std::min(IO_BUFFER_SIZE, bytes - i);
+ unsigned long writeSize = std::min(IO_BUFFER_SIZE,
bytes - i);
for (size_t k = 0; k writeSize; k++) {
buf[k] = 0;
for (unsigned l = 0; l 8; l++, j++) {
@@ -270,11 +270,11 @@
size_t offset = header.startBitPos;
size_t bits = header.endBitPos - header.startBitPos + 1;
- size_t bytes = (bits + 7) / 8;
+ unsigned long bytes = (bits + 7) / 8;
char buf[IO_BUFFER_SIZE];
for (size_t i = 0, j = offset; i bytes; ) {
- size_t readSize = std::min(IO_BUFFER_SIZE, bytes - i);
+ unsigned long readSize = std::min(IO_BUFFER_SIZE, bytes
- i);
in.read(buf, readSize);
assert(in);
for (size_t k = 0; k readSize; k++) {
___
Debian-med-packaging mailing list
debian-med-packag...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to
Bug#782772: logging into metnors.debian.net crashes iceweasel ..
On Mon 2015-05-18 00:45:34 -0400, Norbert Preining wrote: On Sun, 17 May 2015, Paul Wise wrote: it seems there is a serious problem with iceweasel crashing on https sites even from Debian, like mentors.debian.org (interestingly *not* https://www.debian.org/) I have contacted the Debian Mentors Team, and Paul Wise advised me to contact both security and icewease packaging team. I have reproduced this with iceweasel --safe-mode, it crashes (segfaults) repeatetly when accessing any https://mentors.debian.org/ I think this was supposed to be https://mentors.debian.net/, not .org. I guess this must be a but in Iceweasel, but follow the advise of Paul to contact security, too. There is now a public bug report about this: https://bugs.debian.org/782772 Unfortunately, this seems to be different. I have HTTPS Everywhere disabled, and it still crashes. Then I removed the package from Debian and it still crashes. So it seems there are more things concerned. I have also disabled other SSL related addons, without success. Crash is 100% repeatable. I can replicate it as well with 37.0.2-1, starting from a fresh profile and in safe-mode: 0 dkg@alice:~$ iceweasel -no-remote -profile $(mktemp -d) -safe-mode https://mentors.debian.net/ (process:7717): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed Segmentation fault 139 dkg@alice:~$ iceweasel -version (process:7782): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed Mozilla Iceweasel 37.0.2 0 dkg@alice:~$ After upgrading to 38.0-2, with iceweasel-dbg, i get the following backtrace during the segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd94fe700 (LWP 10459)] 0x7403bb87 in GatherEKUTelemetry (certList=...) at /tmp/buildd/iceweasel-38.0/security/manager/ssl/src/SSLServerCertVerification.cpp:1047 1047 /tmp/buildd/iceweasel-38.0/security/manager/ssl/src/SSLServerCertVerification.cpp: No such file or directory. (gdb) bt #0 0x7403bb87 in mozilla::psm::(anonymous namespace)::AuthCertificate(mozilla::psm::CertVerifier, mozilla::psm::TransportSecurityInfo*, CERTCertificate*, mozilla::ScopedCERTCertList, SECItem*, uint32_t, mozilla::pkix::Time) (certList=...) at /tmp/buildd/iceweasel-38.0/security/manager/ssl/src/SSLServerCertVerification.cpp:1047 #1 0x7403bb87 in mozilla::psm::(anonymous namespace)::AuthCertificate(mozilla::psm::CertVerifier, mozilla::psm::TransportSecurityInfo*, CERTCertificate*, mozilla::ScopedCERTCertList, SECItem*, uint32_t, mozilla::pkix::Time) (certList=...) at /tmp/buildd/iceweasel-38.0/security/manager/ssl/src/SSLServerCertVerification.cpp:1117 #2 0x7403bb87 in mozilla::psm::(anonymous namespace)::AuthCertificate(mozilla::psm::CertVerifier, mozilla::psm::TransportSecurityInfo*, CERTCertificate*, mozilla::ScopedCERTCertList, SECItem*, uint32_t, mozilla::pkix::Time) (certVerifier=..., infoObject=0x7fffcccfdbc0, cert=optimized out, peerCertChain=..., stapledOCSPResponse=0x0, providerFlags=optimized out, time=...) at /tmp/buildd/iceweasel-38.0/security/manager/ssl/src/SSLServerCertVerification.cpp:1182 #3 0x7403be5b in mozilla::psm::(anonymous namespace)::SSLServerCertVerificationJob::Run() (this=0x7fffcc2e1920) at /tmp/buildd/iceweasel-38.0/security/manager/ssl/src/SSLServerCertVerification.cpp:1310 #4 0x72c1f799 in nsThreadPool::Run() (this=0x76b53e80) at /tmp/buildd/iceweasel-38.0/xpcom/threads/nsThreadPool.cpp:225 ---Type return to continue, or q return to quit--- #5 0x72c1d3a3 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7fffcfff8ed0, aMayWait=optimized out, aResult=0x7fffd94fddf7) at /tmp/buildd/iceweasel-38.0/xpcom/threads/nsThread.cpp:855 #6 0x72c32829 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=optimized out, aMayWait=aMayWait@entry=false) at /tmp/buildd/iceweasel-38.0/xpcom/glue/nsThreadUtils.cpp:265 #7 0x72de9f64 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) (this=0x7fffce44fbc0, aDelegate=0x7fffd4cb9fc0) at /tmp/buildd/iceweasel-38.0/ipc/glue/MessagePump.cpp:339 #8 0x72dde9d7 in MessageLoop::Run() (this=0x7fffd4cb9fc0) at /tmp/buildd/iceweasel-38.0/ipc/chromium/src/base/message_loop.cc:226 #9 0x72dde9d7 in MessageLoop::Run() (this=this@entry=0x7fffd4cb9fc0) at /tmp/buildd/iceweasel-38.0/ipc/chromium/src/base/message_loop.cc:200 #10 0x72c21aa1 in nsThread::ThreadFunc(void*) (aArg=0x7fffcfff8ed0) at /tmp/buildd/iceweasel-38.0/xpcom/threads/nsThread.cpp:356 #11 0x71aeefa8 in _pt_root (arg=0x7fffd1d6dca0) at ptthread.c:212 #12 0x77bc70a4 in start_thread (arg=0x7fffd94fe700) at pthread_create.c:309 #13 0x770eb04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb) hth, --dkg signature.asc Description: PGP signature
Bug#754483: Further observations
I also experienced these errors after upgrading a couple of laptops from Wheezy to Jessie (basically, when attempting to connect to established access points which have been used without issue for ages, a connection failed dialog appears with the original report's libnm-glib error). I seem to have fixed the issue by the somewhat drastic steps of sudo apt-get purge network-manager-gnome network-manager sudo rm -r -f /etc/NetworkManager/system-connections rm -r -f ~/.gconf/system/networking/wireless/networks sudo apt-get install network-manager-gnome network-manager gnome Then when you try and connect... well it still fails but if you go and edit the connection information to enter the password. Then it connects (reliably, even after reboots). I note Wheezy's behaviour of prompting for a password on the first attempt to connect to an access point which needs one seems to have completely vanished. (In fact I suspect this libnm error dialog is appearing at the point at which the system is trying to prompt the user for a wifi password). FWIW I use Gnome Flashback and the issue was seen on a Lenovo S10e and a Thinkpad X40. Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714768: documentation ?
Just for the record, getbuildlog currently supports this. Could someone please document this ? Currenly my ilmbase symbol file does not work on ports: http://buildd.debian-ports.org/status/package.php?p=ilmbasesuite=experimental Would have been nice to download them as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785618: [rt.debian.org #5802] Account for Fabian Greffrath
Am Montag, den 18.05.2015, 12:51 +0100 schrieb Jonathan McDowell: noodles@kaufmann:~$ gpg --no-default-keyring \ --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \ --list-key 0xCBEA8E970CCD59DF pub 4096R/0CCD59DF 2014-10-23 [expires: 2016-10-22] uid Fabian Greffrath fab...@greffrath.com uid Fabian Greffrath fabian+deb...@greffrath.com sub 4096R/8E377AA0 2014-10-23 [expires: 2016-10-22] Ah, I have set the Uploaders field to my fab...@debian.org account and the updated key which contains this added uid has not yet been merged into debian-keyring. Does this make sense? - Fabian signature.asc Description: This is a digitally signed message part
Bug#785621: bindex is obsolete and should be replaced by repoindex
Source: bindex Version: 2.2+svn101-1 Severity: wishlist While I was updating bnd, I discovered that bindex is now obsolete and was replaced by repoindex according to its own homepage. http://www.osgi.org/Repository/BIndex https://github.com/osgi/bindex#introduction The successor is called repoindex and is maintained in the same repository as bnd. https://github.com/bndtools/bnd Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783293: browsers using webkit crash with 'illegal instruction' on i586
Hi, I have been bitten by this too: all of my webkit browsers crash with SIGILL since upgrading to Jessie on non SSE hardware. This patch at least fixes the environment variable so that JavaScriptCoreUseJIT=0 is honoured as a work-araound. Mark --- /tmp/VM.cpp 2015-05-18 12:04:42.183140915 +0100 +++ /tmp/VM-edited.cpp 2015-05-18 12:16:41.478098153 +0100 @@ -135,6 +135,11 @@ } #if USE(CF) +#if OS(UNIX) +char* canUseJITString = getenv(JavaScriptCoreUseJIT); +if (canUseJITString) + return !canUseJITString || atoi(canUseJITString); +#endif // OS(UNIX) #if COMPILER(GCC) !COMPILER(CLANG) // FIXME: remove this once the EWS have been upgraded to LLVM. // Work around a bug of GCC with strict-aliasing. @@ -146,11 +151,6 @@ RetainPtrCFTypeRef canUseJIT = adoptCF(CFPreferencesCopyAppValue(canUseJITKey, kCFPreferencesCurrentApplication)); if (canUseJIT) return kCFBooleanTrue == canUseJIT.get(); -#endif - -#if USE(CF) || OS(UNIX) -char* canUseJITString = getenv(JavaScriptCoreUseJIT); -return !canUseJITString || atoi(canUseJITString); #else return true; #endif -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785426: RFS: cv/0.6-1 [ITP] -- cv - Coreutils (progress) Viewer)
Hi! lumin cdlumin...@gmail.com writes: To access further information about this package, please visit the following URL: http://mentors.debian.net/package/cv I'll give it a look shortly More information about hello can be obtained from http://www.example.com. probably not that one, right? Additionally I noticed there's already a package shipping /usr/bin/cv: radiance: /usr/bin/cv maybe you can use a different name? Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer signature.asc Description: PGP signature
Bug#785627: mayavi2: malicious dynamic python interpreter lookup via /usr/bin/env python in main executable
Package: mayavi2 Version: 4.3.1-3.1 Severity: serious Justification: Debian Python Policy 2.4.2: Interpreter Location Dear Maintainer, when running /usr/bin/mayavi2 it uses the first python interpreter found in $PATH by using #!/usr/bin/env python as shebang in line 1. If a local user-space Python environment is coming first in $PATH this is bound to fail, because module dependencies might not be there or might be there in the wrong versions. See Debian Python Policy 2.4.2 Interpreter location: https://www.debian.org/doc/packaging-manuals/python-policy/ch- python.html#s-interpreter_loc === quote start The preferred specification for the Python interpreter is /usr/bin/python or /usr/bin/pythonX.Y. This ensures that a Debian installation of python is used and all dependencies on additional python modules are met. Maintainers should not override the Debian Python interpreter using /usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it bypasses Debian's dependency checking and makes the package vulnerable to incomplete local installations of python. === quote end best regards, Tobias Megies -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mayavi2 depends on: ii libc6 2.19-18 ii libjs-jquery 1.7.2+dfsg-3.2 ii python2.7.9-1 ii python-apptools 4.2.1-1 ii python-configobj 5.0.6-1 ii python-envisage 4.4.0-1 ii python-numpy [python-numpy-abi9] 1:1.8.2-2 ii python-pkg-resources 5.5.1-1 ii python-traits 4.4.0-1 ii python-traitsui 4.4.0-1.3 ii python-vtk5.8.0-17.5 ii python-wxgtk3.0 3.0.1.1+dfsg-2 mayavi2 recommends no packages. Versions of packages mayavi2 suggests: pn ipython none ii python-scipy 0.14.0-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785484: systemd: on Raspberry pi B+, several essential services fail, including systemd-logind
Am 18.05.2015 um 13:32 schrieb Michael Biebl: Do you have any tools installed, which mess around with cgroups, like cgmanager, lxc, etc? cgmanager, cgroup-bin and cgroup-tools were installed. After removing them, everything works nicely! Thanks so much for this hint, and sorry for the misplaced bug report... Johannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785478: jessie-pu: package node-groove/2.2.6-1
On 16 May 2015 at 17:31, Adam D. Barratt a...@adam-barratt.org.uk wrote: Control: tags -1 + moreinfo On Sat, 2015-05-16 at 17:16 -0300, Felipe Sateler wrote: Node-groove has a bug that is pretty annoying: a missing check in a loop causes an almost-tight loop to run as long as an encoder object is attached. More details at the upstream tracker[1]. This is not a dealbreaker on multicore machines, but it is still annoying and pretty bad in single-core machines. We think the smallness of the fix and the greatness of the improvement makes it good for a stable update. It may well be, but it needs to be fixed in unstable first. The fix in unstable was delayed because Andrew is working on getting the new upstream version of node-groove ready. This includes way more than just the above fix (and requires new upstream versions of dependencies). Anyhow, I have uploaded the fix to unstable. The upload should be essentially the same as the upload in unstable, modulo the version string. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718843: console-kit-daemon : GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Package: consolekit Version: 0.4.6-5 Followup-For: Bug #718843 Dear Maintainer, I just saw the same message in my daemon.log after lightdm crashed. I'm running xfce as my desktop. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages consolekit depends on: ii dbus 1.8.16-1 ii libacl12.2.52-2 ii libc6 2.19-18 ii libck-connector0 0.4.6-5 ii libdbus-1-31.8.16-1 ii libdbus-glib-1-2 0.102-1 ii libglib2.0-0 2.44.0-2 ii libpolkit-gobject-1-0 0.105-8 ii libudev1 215-17 ii libx11-6 2:1.6.3-1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages consolekit recommends: ii libpam-ck-connector 0.4.6-5 consolekit 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#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver
I have not, but if I reboot the computer to an install of Jessie using fglrx the tinge is not present; and it appeared shortly after updating to Jessie + unstable. I'll try a few things with the cable report back if any of them have an impact, but the fglrx test suggests this problem is 100% fixable in software. Owen Riddy Email: owen.ri...@gmail.com Mobile: 040 163 2663 -- On 18 May 2015 at 12:56, Michel Dänzer mic...@daenzer.net wrote: On 16.05.2015 21:21, Owen Riddy wrote: Package: xserver-xorg-video-ati Version: 1:7.5.0-1+b1 Severity: important Dear Maintainer, I'm using the open source ati graphics with a 3-screen setup. After upgrading to unstable after the release of Jessie everything ran without issue. I booted into a seperate install of Jessie on the same computer that had flgrx installed, and after rebooting into unstable one of the screens (connected by a HDMI cable) has acquired a distinct green tinge that obscures whatever the screen is trying to show. It is a sort of neon green. This image is a graphical corruption bug - I took a screenshot using ksnapshot and on my other two screens the image dispaled withouth the green tinge. The tinge is not present: * In the BIOS * When GRUB is active * Early in the boot process when the kernel is still printing text * On a separate Debian install on the same hardware, using fglrx I tried changing the gamma settings of the screen and poking at the backlight settings but this did not help. Changing the gamma made a very slight difference but the tinge does nto seem to be caused by a rogue gamma setting. At some points during, eg, shutdown my screens go blank - usually this is black but at present the green tinged screen goes straight green. It sounds like there might be a problem with the physical display connection. Have you checked the connector seating at both ends, maybe unplugging and re-plugging them, or even using a different cable? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#707850: gwibber/experimental no longer depends on python-gtkspell
On Sun, 16 Jun 2013 17:55:52 +0200 Emilio Pozuelo Monfort po...@debian.org wrote: Version: 3.5.2-1 Just found out gwibber no longer depends on python-gtkspell in experimental, so marking as fixed for that version. Can you upload the package in experimental to sid? Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784900: Installing of a new language causes that other locales are registered as outdated
On 2015-05-17 18:57, sworddrag...@aol.com wrote: And again: I'm reporting this specifically against upstream. At least the manpage of locale-gen from Ubuntu implies that this is here. And since the binary locale-gen does contain this bug (except it should be fixed in a newer version) theoretically the current maintainer should be responsible for handling it. Also as long as Debian does provide the binary locale-gen in any package it is theoretically affected by this bug but maybe just hiding it in the default setup. But maybe an user that makes some user-defined changes could stumble over it. I don't consider Debian being the upstream of a file that has been heavily modified by Ubuntu. Again please show that the bug affects Debian, and then I might consider looking at it. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785018: KVM internal error and emulation failure
[Dropping Paolo as this is now related solely to debian internals] 18.05.2015 10:42, Josh Triplett wrote: [] I would have gone upstream if Paolo hadn't immediately jumped in and started diagnosing this. Oh. So my attempt to get upstream's attention was actually wrong :) There's no reason to close a bugreport if it can't be fixed, for that there's wontfix resolution, or it can remain open, whatever. I was hesitant to suggest wontfix for something that's really cantfix, which is what it sounds like. But whichever you prefer. Closing a cantfix bug is even more in-appropriate, I think. But wontfix fits perfectly, since the prob is tricky enough and infrequent enough in real life that major surgery isn't wanted. Also, I don't think minor is appropriate here. Why? As far as I can see, the prob is quite rare, one needs special software (often old version) to hit it. So it does not affect majority of users, only some rare configurations are affected and even there it is possible to work around it by applying patches. To me it sounds perfectly minor :) Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707856: espeak-gui update needed
Hi Siegfried, On Sat, 13 Sep 2014 10:19:30 +0800 Paul Wise p...@debian.org wrote: On Sun, Dec 29, 2013 at 12:54:29AM +0100, Siegfried-Angel Gevatter Pujals wrote: Update: I've finally got around to porting the app, but there's some weird segmentation fault happening that I need to figure out before I can upload the changes. Any luck? The freeze for Debian jessie is coming soon (Nov 5th). Ping? Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785557: perl: FTBFS on i386 and amd64: itimer problems on buildds?
Hi, On Sun May 17, 2015 at 22:18:52 +0300, Niko Tyni wrote: DSA (also cc'd): What's the virtualization setup with x86-grnet-01, brahms and binet? Is there a difference with babin, which managed to build the i386 binaries? Are the underlying virtualization hosts running jessie too? ganeti, using qemu for all architectures. The underlying virtualization hosts for x86-grnet-01 and brahms run jessie, binet's virtualization host still runs wheezy. All VMs are bootstraped by DSA with the same script, which is available at [1]. After the bootstrapping is done, buildd maintainers take over and setup the buildd on the VM. Cheers, Martin [1]http://anonscm.debian.org/cgit/mirror/dsa-misc.git/tree/scripts/VM-installs/ganeti-unified -- Martin Zobel-Helas zo...@debian.orgDebian System Administrator Debian GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785601: linux-image-3.16.0-4-amd64: DualPoint TouchPad at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away
Package: src:linux Version: 3.16.7-ckt9-2 Severity: normal Dear Maintainer, Since I migrated away from wheezy to jessie, I am having lots of trouble using the touchpad. I keep getting: [ 536.216745] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away. [ 536.729797] psmouse serio1: resync failed, issuing reconnect request [ 716.338204] psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away. [ 716.849390] psmouse serio1: resync failed, issuing reconnect request which result in unrelable behavior (pointer stops and jumps around). Using debugfs I can see the following pattern: [ 717.30] psmouse serio1: alps: E6 report: 00 00 64 [ 717.328605] psmouse serio1: alps: E7 report: 73 02 64 [ 717.352794] psmouse serio1: alps: EC report: 88 07 9d [ 717.374019] psmouse serio1: alps: EC report: 88 07 9d [ 717.423501] psmouse serio1: alps: EC report: 88 07 9d As far as I remember it used to work properly in older linux kernel version. This laptop (DELL Vostro 3750) is a dual boot system and I do not have any single issue when running Windows 7/64bits Pro on it. If that matter: i8kfan 1 1 does not have any effect anymore of the fan, and my fan are running very oddly since the upgrade (runs quickly and stop quickly). My USB mouse does not seems to be powered for the first few seconds (gnome session). And keyboard seems to produce duplicate key events. -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=0b17f6ae-4025-41be-ab21-1f6e2472ad73 ro quiet acpi_backlight=vendor ** Not tainted ** Kernel log: [ 14.944538] ACPI: Video Device [PEGP] (multi-head: yes rom: yes post: no) [ 14.944668] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:26/LNXVIDEO:00/input/input11 [ 14.960484] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 14.960611] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input12 [ 14.960714] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [ 14.961098] snd_hda_intel :00:1b.0: irq 54 for MSI/MSI-X [ 14.977235] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUG disabled [ 14.977238] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUGFS disabled [ 14.977240] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [ 14.977241] iwlwifi :02:00.0: Detected Intel(R) Centrino(R) Wireless-N 1030 BGN, REV=0xB0 [ 14.977334] iwlwifi :02:00.0: L1 Enabled - LTR Disabled [ 15.160582] sound hdaudioC0D0: autoconfig: line_outs=2 (0x14/0x1a/0x0/0x0/0x0) type:speaker [ 15.160586] sound hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 15.160588] sound hdaudioC0D0:hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 15.160589] sound hdaudioC0D0:mono: mono_out=0x0 [ 15.160591] sound hdaudioC0D0:inputs: [ 15.160593] sound hdaudioC0D0: Mic=0x18 [ 15.160594] sound hdaudioC0D0: Internal Mic=0x12 [ 15.165784] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/sound/card0/hdaudioC0D0/input13 [ 15.165957] input: HDA Intel PCH Mic as /devices/pci:00/:00:1b.0/sound/card0/input14 [ 15.166010] input: HDA Intel PCH Headphone as /devices/pci:00/:00:1b.0/sound/card0/input15 [ 15.167005] intel_rapl: Found RAPL domain package [ 15.167009] intel_rapl: Found RAPL domain core [ 15.167012] intel_rapl: Found RAPL domain uncore [ 15.408162] media: Linux media interface: v0.10 [ 15.438314] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [ 15.526200] Linux video capture interface: v2.00 [ 15.566019] cfg80211: Calling CRDA to update world regulatory domain [ 15.844754] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 16.177267] uvcvideo: Found UVC 1.00 device Laptop_Integrated_Webcam_FHD (1bcf:2b81) [ 16.199867] input: Laptop_Integrated_Webcam_FHD as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input16 [ 16.200119] usbcore: registered new interface driver uvcvideo [ 16.200123] USB Video Class driver (1.1.1) [ 17.082461] cfg80211: World regulatory domain updated: [ 17.082469] cfg80211: DFS Master region: unset [ 17.082472] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 17.082476] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 17.082479] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 17.082481] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [ 17.082484] cfg80211: (517 KHz - 525 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 17.082488] cfg80211: (525 KHz - 533 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm),
Bug#784603: wordpress: Wordpress 4.2.2 critical security release
On Sat, 16 May 2015, Craig Small wrote: I mean, instead of using 4.2.x to extract the patches and backport, isn't it easier to extract them from 4.1.x for stable ? Or just do a new upstream release based on 4.1.5 ? The stable track is basically whatever version was there with security patches so going to 4.1.5 isn't really an option. Again the 4.1.5 changesets use terrible comments. That's the general case. But with wordpress, the security team is rather open to integrate new upstream releases. We did it multiple times already. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785018: KVM internal error and emulation failure
On 18/05/2015 03:54, Josh Triplett wrote: On Thu, May 14, 2015 at 05:04:19PM +0200, Paolo Bonzini wrote: OVMF used to place page tables in ROM, which works on real hardware, and also works on VMs except: - on AMD systems - on Intel systems, if you have EPT page tables with A/D bits on Why? Because on these systems, the processor treat page table accesses as writes. That's...special. Is there no way to work around that? In general, it seems like a bug if KVM cannot faithfully simulate real hardware. Nope. You can use eptad=N or ept=N. As it's a microcode issue, I think closing as cantfix is the right thing to do. Paolo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver
No worries. It turns out that the problem was the Color Format of my screen. Dunno what that is, but it was configuring poorly and the open source driver seems happier when it is set to RGB rather than YCbCr. Maybe Catalyst is a bit more forgiving or maybe there is some configuration issue here I don't understand. My problem is solved; there may still be a minor bug here in how the auto-configuration of the driver works. Owen Riddy Email: owen.ri...@gmail.com Mobile: 040 163 2663 -- On 18 May 2015 at 17:41, Michel Dänzer mic...@daenzer.net wrote: On 18.05.2015 16:28, Owen Riddy wrote: I have not, but if I reboot the computer to an install of Jessie using fglrx the tinge is not present; and it appeared shortly after updating to Jessie + unstable. I'll try a few things with the cable report back if any of them have an impact, but the fglrx test suggests this problem is 100% fixable in software. I guess I misunderstood the comments about fglrx in your original report. I agree it's probably a software bug then, though it's more likely in the kernel driver than in the Xorg driver. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#678340: gnome-packagekit: gpk-update-viewer fails listing available updates
2015-05-16 16:50 GMT+02:00 Alan Jenkins alan.christopher.jenk...@gmail.com: On 16 May 2015 at 11:42, Matthias Klumpp matth...@tenstral.net wrote: [...] Thanks for your time Matthias. I don't see an automatic update setting in gpk-prefs, but it does show the update repos are enabled. See attached screenshot. (and it's a VM install primarily for this test, I haven't had reason to mess anything up). Best regards Alan Right, I forgot that this was dropped from gpk-prefs. Please open the dconf-editor (GUI editor for dconf) and navigate to the /org/gnome/settings-daemon/plugins/updates section. Is the active value set to true? Cheers, Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785597: lxc: fails to create or start unprivileged containers as user
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: lxc Version: 1:1.0.6-6 Severity: minor Dear Maintainer, I was trying to make unprivileged user-containers, but failed. I also tried to make a container usind 'sudo', then moving it into the home-directory of the user and changing ownership and group, but this did not work out either, see below. Logfiles are attached. There is a report saying, lxc version 1.1 should be backported to Jessie, but it is not there yet. Upon trying to start the container, I made with 'sudo', there is a problem with the ssh-session, i need to log out and log in again, because it does not show, what I type anymore. I say it's a minor issue, because I can use a root-containers instead, which works well enough. Very high security is not really necessary for my application case. contain@dhsrv:~$ lxc-start -n privo-squid -d -F --logfile=lxc.log.txt --logpriority=DEBUG unshare: Operation not permitted read pipe: No such file or directory lxc-start: Failed to chown /dev/pts/7 lxc-start: Failed to shift tty into container lxc-start: failed to initialize the container lxc-start: The container failed to start. lxc-start: Additional information can be obtained by setting the --logfile and --logpriority options. . .. . contain@dhsrv:~$ lxc-create -t download -n testcont --logfile=lxcc.log.txt --logpriority=DEBUG unshare: Operation not permitted read pipe: No such file or directory lxc-create: Failed to chown container dir lxc-create: Error creating container testcont contain@dhsrv:~$ lxc-create -t download -n testcont -P /home/contain/stora --logfile=lxcc.log.txt --logpriority=DEBUG unshare: Operation not permitted read pipe: No such file or directory lxc-create: Failed to chown container dir lxc-create: Error creating container testcont - -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.7-ckt9-es-via-c7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lxc depends on: ii init-system-helpers 1.22 ii libapparmor1 2.9.0-3 ii libc62.19-18 ii libcap2 1:2.24-8 ii libseccomp2 2.1.1-1 ii libselinux1 2.3-2 ii multiarch-support2.19-18 ii python3 3.4.2-2 Versions of packages lxc recommends: ii debootstrap 1.0.67 ii openssl 1.0.1k-3 ii rsync3.1.1-3 Versions of packages lxc suggests: pn lua5.2 none - -- Configuration Files: /etc/lxc/default.conf changed: lxc.arch = x86 lxc.network.type = veth lxc.network.flags = up lxc.network.link = cbr0 lxc.id_map = u 0 10 65537 lxc.id_map = g 0 10 65537 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlVZj7UACgkQ5+rBHyUt5wsCBwCfcmeQ7gl5mucdDG+lVKHkVPps YD8An3zoixC3rzcv/4nSlrh99u3aieGL =CCzq -END PGP SIGNATURE- lxc-create 1431931713.508 WARN lxc_log - lxc_log_init called with log already initialized lxc-create 1431931713.510 INFO lxc_confile - read uid map: type u nsid 0 hostid 10 range 65536 lxc-create 1431931713.510 INFO lxc_confile - read uid map: type g nsid 0 hostid 10 range 65536 lxc-create 1431931713.522 ERRORlxc_container - Failed to chown container dir lxc-create 1431931713.522 ERRORlxc_create_ui - Error creating container testcont lxc-create 1431931836.838 WARN lxc_log - lxc_log_init called with log already initialized lxc-create 1431931836.839 INFO lxc_confile - read uid map: type u nsid 0 hostid 10 range 65536 lxc-create 1431931836.839 INFO lxc_confile - read uid map: type g nsid 0 hostid 10 range 65536 lxc-create 1431931836.850 ERRORlxc_container - Failed to chown container dir lxc-create 1431931836.850 ERRORlxc_create_ui - Error creating container testcont lxc-start 1431931179.231 INFO lxc_start_ui - using rcfile /home/contain/stora/privo-squid/config lxc-start 1431931179.233 INFO lxc_confile - read uid map: type u nsid 0 hostid 10 range 65537 lxc-start 1431931179.233 INFO lxc_confile - read uid map: type g nsid 0 hostid 10 range 65537 lxc-start 1431931179.234 WARN lxc_log - lxc_log_init called with log already initialized lxc-start 1431931179.234 INFO lxc_lsm - LSM security driver nop lxc-start 1431931179.249 INFO lxc_conf - tty's configured lxc-start 1431931179.252 INFO lxc_caps - Last supported cap was 36 lxc-start 1431931179.273 ERRORlxc_conf - Failed to chown /dev/pts/7 lxc-start 1431931179.273 ERRORlxc_start - Failed to shift tty into container lxc-start 1431931179.274 ERRORlxc_start - failed to initialize the container lxc-start 1431931179.274 ERRORlxc_start_ui - The container
Bug#785590: ITP: freefall -- daemon to protect disk for laptops with supported sensors
Hi pabs and Evgeni, On 05/18/2015 02:17 PM, Evgeni Golov wrote: Hi, On Mon, May 18, 2015 at 01:21:13PM +0800, Paul Wise wrote: On Mon, 18 May 2015 12:36:04 +0800 Jesse Sung wrote: * Package name : freefall * URL : https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/laptops/freefall.c ... I notice that there is another implementation of this idea that supports more laptops than the Linux one, should these two be merged or what? https://packages.debian.org/sid/hdapsd The freefall interface is pretty cool and easy, because the decision is done in hardware and the userspace only has to actually trigger parking the heads. That's also supported by hdapsd (and if not properly, I, with my upstream hat on, want patches as I do not own any HP/Dell hardware). hdapsd also supports other motion sensors, that only report motion and no binary decision. That said, I would favour only having one complete implementation in the archive (and wonder why noone told me about the in-kernel tool for 7 years), but would not oppose someone else maintaining the version built from src:linux ;) Sorry, didn't notice that the freefall interface is already supported by newer hdapsd. I'm totally fine with using hdapsd instead since it's more complete than the freefall.c. Thanks, Jesse -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785018: KVM internal error and emulation failure
Control: retitle -1 KVM emulation failure: eptad, triggered by (old) OVMF code Control: severity -1 minor Control: tag -1 + upstream confirmed 18.05.2015 04:54, Josh Triplett wrote: [] I can confirm that updating to a newer OVMF makes this problem go away. If there's no way of supporting page tables in ROM with eptad, then you can go ahead and close this bug. Josh, I remind you again: such bugs should be opened against upstream qemu. I especially asked Paolo to take a look at this bugreport, but generally these bugs, especially when the problem is that deep, should be filed against upstream qmeu bugtracker. There's no reason to close a bugreport if it can't be fixed, for that there's wontfix resolution, or it can remain open, whatever. I'm re-titling and re-tagging it in debian. It'd be much better if it were in launchpad BT and Debian can link to that bug, though. Thank you Paolo for explaining it all to us! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785600: xdg-utils: xdg-open fails to open audio and video files in totem
Package: xdg-utils Version: 1.1.0~rc1+git20111210-7.4 Severity: important Dear Maintainer, as originally reported in bug #784735... * What led up to the situation? A program (in my case gpodder) uses xdg-open to open audio and video files. * What exactly did you do (or not do) that was effective (or ineffective)? When starting a media file ... * What was the outcome of this action? only a Videos (Totem) window opens with no option to start the file. * What outcome did you expect instead? That the file is directly being played or, at least, that I have the option to play it by clicking a play button. There is a workaround which should be included in the package: Using the command totem --play %U works just fine. This command should be used in xdg-open, too. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) xdg-utils depends on no packages. Versions of packages xdg-utils recommends: ii libfile-mimeinfo-perl 0.26-1 ii libnet-dbus-perl 1.0.0-2+b2 ii libx11-protocol-perl 0.56-6 ii x11-utils 7.7+2 ii x11-xserver-utils 7.7+3+b1 Versions of packages xdg-utils suggests: ii gvfs-bin 1.22.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#785018: KVM internal error and emulation failure
On Mon, May 18, 2015 at 10:31:14AM +0300, Michael Tokarev wrote: Control: retitle -1 KVM emulation failure: eptad, triggered by (old) OVMF code Control: severity -1 minor Control: tag -1 + upstream confirmed 18.05.2015 04:54, Josh Triplett wrote: [] I can confirm that updating to a newer OVMF makes this problem go away. If there's no way of supporting page tables in ROM with eptad, then you can go ahead and close this bug. Josh, I remind you again: such bugs should be opened against upstream qemu. I especially asked Paolo to take a look at this bugreport, but generally these bugs, especially when the problem is that deep, should be filed against upstream qmeu bugtracker. I would have gone upstream if Paolo hadn't immediately jumped in and started diagnosing this. There's no reason to close a bugreport if it can't be fixed, for that there's wontfix resolution, or it can remain open, whatever. I was hesitant to suggest wontfix for something that's really cantfix, which is what it sounds like. But whichever you prefer. Also, I don't think minor is appropriate here. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver
On 18.05.2015 16:28, Owen Riddy wrote: I have not, but if I reboot the computer to an install of Jessie using fglrx the tinge is not present; and it appeared shortly after updating to Jessie + unstable. I'll try a few things with the cable report back if any of them have an impact, but the fglrx test suggests this problem is 100% fixable in software. I guess I misunderstood the comments about fglrx in your original report. I agree it's probably a software bug then, though it's more likely in the kernel driver than in the Xorg driver. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784735: gpodder: wrong standard media player
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.05.2015 um 15:35 schrieb tony mancill: Perhaps this is related to your desktop environment? I run MATE and encountered a (very frustrating issue) with my browser refusing to open my configured email program. [...] Perhaps you have found another issue with the xdg-utils package? You can review the open bug reports here [2]. Hey Tony, my desktop environment is GNOME3. I checked all the issued and filed a new bug for xdg-utils [1]. Bye Björn [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785600 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJVWZhTAAoJECNNcxO8k0eoWycP/0igxlKXlE07Y5HbdxiddEHT CMkpAWpO4kFxS/1N7K5yynH2Fe583Y2ZUns0d+4JIrOFi1WHxWnnaA5RBws+sq+y Q0VtXLbK/dT3F+U5nHJ0nahuv5tCYSaCCba9YJv71vMNl7719JgAIp4hmc+zpbLT xNdloHpjQGb1jwB94r1TJvd/1M+rTUKvp0J7lSGVrN/pfnifBjST6oaMT9WsTQ72 3YdSIPPLlB+BID/l2XIlwR9L8eG7slApA0mG3L9ZXcYg/kwjQAYqQDTuBo0Jiho7 sMHwnwZ/TjVBYTnJe1JAapjjyndqX/cmcF/ODTH1KWcyF1K2+fgE8/1jbTVX0j+j 9/xUwXP34We8boKF1gx3tkzZuh3n/R5NSuvDxSMHGJSecVSqdDVr1r7swtLLPB91 TKmbY4PW5JGzad9U92SIZpJknDqECrxQGeUOUOaiD4uAI8rvQEqGhfFm/Ea7JWhy k/SRN6QNa9gw35iP8ZXkyRsw1oqxyOUWCmKfQavJMW+/En8bxltZL2saVzR9HPTl xCotm1u1UvSky+JnSzLvo0TH3U2FPPGO9nqaHuv5csPfupEwTn4f5Jp7IBoAN2vl srwU13CFER7dr5CEp45SSpRS5kpo1FfNdJEONLou7JyV6Rvf96S1wk+lbo9V7cDU J1kEGLN7IYxznH4glxOt =Jjy7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785601: debugfs cmd
Forgot to mention debugfs command: # echo file drivers/input/mouse/* +p /sys/kernel/debug/dynamic_debug/control -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785597: lxc: fails to create or start unprivileged containers as user
close 785597 1:1.0.7-1 thanks On 05/18/2015 09:06 AM, Andreas Glaeser wrote: I was trying to make unprivileged user-containers, but failed. works with above version, closing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785457: cloud.debian.org: AMI don't need getty
На 18.05.2015 в 17:29, Ognyan Kulev написа: I'm new to Amazon EC2 but I don't see any way to access Xen console (hvc0). Quick googling didn't find anything. The only tty thing that I found is ec2-get-console-output command http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-GetConsoleOutput.html. And it is only output, no interactive session that would justify getty process. So it looks to me that hvc0 getty could be disabled as well, if it is impossible to use it (on EC2 instance). Correct me if I'm wrong. All the best, Ognyan signature.asc Description: OpenPGP digital signature
Bug#785634: advene: Python-pygoocanvas deprecated
Package: advene Version: 1.1-2 Severity: important Dear Maintainer, The latest version of goocanvas (2.0.2) has been sitting in experimental for some time. Now that Jessie has been released, I am looking at all the reverse dependencies to see what would be required to start the transition. Python-pygoocanvas is one of the reverse dependencies that blocks the transition. It has been deprecated upstream, and all software projects using pygoocanvas are encouraged to port their applications to use the GObject Introspection library provided in the latest goocanvas package and to move away from GTK+2 to GTK+3. Are there any plans upstream to switch to gir1.2-goocanvas-2.0? Regards, Ross -- System Information: Debian Release: jessie/sid APT prefers utopic-updates APT policy: (500, 'utopic-updates'), (500, 'utopic-security'), (500, 'utopic'), (100, 'utopic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-37-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785630: dpkg: Store a log of package installations
Control: tags -1 moreinfo Hi! On Mon, 2015-05-18 at 17:58:04 +0300, Victor Porton wrote: Package: dpkg Version: 1.17.25 Severity: wishlist There should be a detailed log of which packages were installed when and which old versions (if any) were updated, with the exact times of the operations. The log should be preserved at least during a month. Isn't /var/log/dpkg.log* what you are looking for? This would help to seek bugs in Debian. A GUI interface to this log would be also useful. A GUI for this is out of scope within dpkg, there's #608930 which asks for a perl module and a CLI tool, which I'm fine with. If I've not misunderstood the request I'll be closing it in a bit. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785457: cloud.debian.org: AMI don't need getty
On Mon, May 18, 2015 at 10:29 AM, Ognyan Kulev ogn...@ognyankulev.com wrote: На 18.05.2015 в 17:17, Emmanuel Kasper написа: My understanding of that applied to Xen virtualization platform that Amazon uses, is that systemd will *always* start a getty on the default system console, which for Xen will be /dev/hvc0 instead of /dev/tty1 Actually you *want* to have this one getty started, as this is where your rescue console will be. I'm new to Amazon EC2 but I don't see any way to access Xen console (hvc0). Quick googling didn't find anything. It's logged. (No interactive output). [1] -Brian [1] - http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html All the best, Ognyan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785508: nano: python highlighting fragile in v2.4
But with the python.nanorc from v2.2, the docstring at the top (the one that says expansion packages include...) wil not get coloured green, right? Only the triple quotes themselves are green, no? Surely this is not correct either? What you're seeing is a manifestation of nano bug # 41313 (https://savannah.gnu.org/bugs/?41313) -- the start and end regexes of multiline strings being far too similar. Comment #7 contains a patch to avoid that problem: https://savannah.gnu.org/support/download.php?file_id=33430 If you can, please test, and report your findings. Benno -- http://www.fastmail.com - Accessible with your email software or over the web -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638619: [pkg-gnupg-maint] Bug#638619: Bug#638619: Bug#638619: Misleading gpg: Ohhhh jeeee: no decrypt() for 17 message from gpg when trying to decrypt a file without the public key being importe
On Mon, 18 May 2015 04:15, gni...@fsij.org said: gpg: public key decryption failed: public key not found gpg: decryption failed: secret key not available - I think that the message would be confusing for a user a bit (as it Right, and this gives us a hint that the error is due to a special key. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785463: Confirmed as a bug in ext4 driver by upstream
Control: forwarded -1 http://thread.gmane.org/gmane.comp.file-systems.ext4/48676 Control: reassign -1 linux/4.0.2-1 Control: tags -1 + upstream Theodore Ts'o tytso at mit.edu wrote: Yep, the bug is on my side, in ext4_remount(). I'll get this fixed and marked as something that should get bacported to the stable tree. My apologies for the oversight. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784439: uglifyjs version failing
Quoting Jérémy Lal (2015-05-06 14:08:09) 2015-05-06 13:31 GMT+02:00 Pau Garcia i Quiles pgqui...@elpauer.org: The package.json file does exist: [...] /usr/lib/nodejs/uglify-js/package.json that's why it's usually simpler and safer to install original hierarchy with - package.json - lib/* in /usr/lib/nodejs/uglify-js, instead of changing it and not installing package.json. You are barking up the wrong tree, Jérémy: package.js *is* installed at the *correct* location. Please read what Pau Garcia wrote. Problem is upstream script expecting to be installed in ~/bin/ and assuming its library is in ~/lib/ I will extend 2001 to also cover hardcoded path to parse.js. Thanks for your bugreport, Pau Garcia, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#785642: queue runner dies with uncaught UnicodeDecodeError
Package: mailman Version: 1:2.1.18-2 Severity: grave Justification: causes data loss Hi, I received a message from one of my list admins that he couldn't send a mail to his list. Investigating turned up the following in /var/log/mailman/error: May 17 15:32:20 2015 (981) Uncaught runner exception: 'utf8' codec can't decode byte 0xe9 in position 18: invalid continuation byte May 17 15:32:20 2015 (981) Traceback (most recent call last): File /var/lib/mailman/Mailman/Queue/Runner.py, line 119, in _oneloop self._onefile(msg, msgdata) File /var/lib/mailman/Mailman/Queue/Runner.py, line 190, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File /var/lib/mailman/Mailman/Queue/IncomingRunner.py, line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File /var/lib/mailman/Mailman/Queue/IncomingRunner.py, line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File /var/lib/mailman/Mailman/Handlers/CookHeaders.py, line 239, in process i18ndesc = uheader(mlist, mlist.description, 'List-Id', maxlinelen=998) File /var/lib/mailman/Mailman/Handlers/CookHeaders.py, line 65, in uheader return Header(s, charset, maxlinelen, header_name, continuation_ws) File /usr/lib/python2.7/email/header.py, line 183, in __init__ self.append(s, charset, errors) File /usr/lib/python2.7/email/header.py, line 267, in append ustr = unicode(s, incodec, errors) UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 18: invalid continuation byte May 17 15:32:20 2015 (981) SHUNTING: 1431869540.389822+156779307d54473d0eb732994bb67eee95733285 I'm not sure why mailman needs to decode the data in the mail as part of running the queue, but at any rate that shouldn't case the mail to get lost... -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 3.16.0-4-kirkwood Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mailman depends on: ii apache2 [httpd] 2.4.10-10 ii apache2-mpm-prefork [httpd] 2.4.10-10 ii cron 3.0pl1-127 ii debconf [debconf-2.0]1.5.56 ii libc62.19-18 ii logrotate3.8.7-1+b1 ii lsb-base 4.1+Debian13+nmu1 ii python-dnspython 1.12.0-1 pn python:any none ii ucf 3.0030 Versions of packages mailman recommends: ii exim4-daemon-heavy [mail-transport-agent] 4.84-8 Versions of packages mailman suggests: pn listadmin none pn lynx none ii spamassassin 3.4.0-6 -- debconf information: * mailman/create_site_list: * mailman/used_languages: en fr nl * mailman/gate_news: false * mailman/default_server_language: fr mailman/queue_files_present: abort installation * mailman/site_languages: fr, en, nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785484: systemd: on Raspberry pi B+, several essential services fail, including systemd-logind
Dear all,
I assume that Bernhard has spotted the culprit. Personally, I cannot
reproduce the bug now just by reinstalling those packages, as I had
purged the original configuration, so it is probably something carried
over during the upgrade from wheezy.
Cheers,
Johannes
Am 18.05.2015 um 19:04 schrieb Bernhard Übelacker:
Hello,
as I got the same problem on my raspberry, probably I can give
some details.
This is the situation I started:
- put 2015-05-05-raspbian-wheezy.img on SD-card and booted
- changed sources.list and did the upgrade
- appended systemd.debug-shell to /boot/cmdline.txt
- reboot
For some reason it looks like /etc/init.d/cgroup-bin is still
installed even cgroup-bin is a transitional package.
This script tries to mount /sys/fs/cgroup/memory but seems to fail
and it then unmounts /sys/fs/cgroup.
Therefore systemd cannot create new cgroups or spawning
processes cannot attach to them.
By purging just cgroup-bin I got expected booting again.
cgroup-bin[455]: Kernel lacks cgroups or memory controller not available, not
starting cgroups. ... (warning).
systemd[1]: Failed to create cgroup /system.slice/ntp.service: No such file or
directory
systemd[481]: Failed at step CGROUP spawning /etc/init.d/ntp: No such file or
directory
Kind regards,
Bernhard
root@raspberrypi:/# dpkg -l cgroup-bin
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name VersionArchitecture Description
+++-==-==-==-=
ii cgroup-bin 0.41-6 allcontrol
and monitor control groups (transitional package)
root@raspberrypi:/# dpkg -L cgroup-bin
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/cgroup-bin
/usr/share/doc/cgroup-bin/changelog.Debian.gz
/usr/share/doc/cgroup-bin/copyright
/etc/init.d/cgroup-bin
root@raspberrypi:/# ls -lisah /etc/init.d/cgroup-bin
36115 4.0K -rwxr-xr-x 1 root root 950 Dec 18 2013 /etc/init.d/cgroup-bin
root@raspberrypi:/# cat /etc/init.d/cgroup-bin
#! /bin/sh
### BEGIN INIT INFO
# Provides: init-cgroups
# Required-Start:mountkernfs
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Mounts cgroup filesystems
### END INIT INFO
PATH=/sbin:/bin
. /lib/lsb/init-functions
do_start () {
log_action_msg Initializing cgroups
mount -t tmpfs none /sys/fs/cgroup
mkdir /sys/fs/cgroup/memory
if ! mount -t cgroup none /sys/fs/cgroup/memory -o memory 2
/dev/null; then
umount /sys/fs/cgroup
log_warning_msg Kernel lacks cgroups or memory controller not
available, not starting cgroups.
exit 0
fi
chmod a+r /sys/fs/cgroup/memory/memory.pressure_level
}
case $1 in
start)
do_start
;;
restart|reload|force-reload)
echo Error: argument '$1' not supported 2
exit 3
;;
stop)
# No-op
;;
*)
echo Usage: $0 start|stop 2
exit 3
;;
esac
root@raspberrypi:/root# dpkg --purge cgroup-bin
(Reading database ... 100744 files and directories currently installed.)
Removing cgroup-bin (0.41-6) ...
Purging configuration files for cgroup-bin (0.41-6) ...
root@raspberrypi:/root# reboot -f
# as regular reboot did not work at this point anymore
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785484: systemd: on Raspberry pi B+, several essential services fail, including systemd-logind
reassign 785484 cgroup-bin severity 785484 grave found 785484 0.41-6 retitle 785484 cgroup-bin: breaks boot with systemd thanks Thanks for the further information, Bernhard. I'm going to re-assign this bug report to cgroup-bin. Am 18.05.2015 um 19:04 schrieb Bernhard Übelacker: Hello, as I got the same problem on my raspberry, probably I can give some details. This is the situation I started: - put 2015-05-05-raspbian-wheezy.img on SD-card and booted - changed sources.list and did the upgrade - appended systemd.debug-shell to /boot/cmdline.txt - reboot For some reason it looks like /etc/init.d/cgroup-bin is still installed even cgroup-bin is a transitional package. This script tries to mount /sys/fs/cgroup/memory but seems to fail and it then unmounts /sys/fs/cgroup. Therefore systemd cannot create new cgroups or spawning processes cannot attach to them. Right, I don't think umounting /sys/fs/cgroup is a sensible behaviour, if the init cgroup-bin init script didn't mount it itself, thus breaking systemd. The cgroup-bin should behave more sensible if systemd is active. If the init script needs to test for that, it can use test -d /run/systemd/system, see http://www.freedesktop.org/software/systemd/man/sd_booted.html By purging just cgroup-bin I got expected booting again. cgroup-bin[455]: Kernel lacks cgroups or memory controller not available, not starting cgroups. ... (warning). systemd[1]: Failed to create cgroup /system.slice/ntp.service: No such file or directory systemd[481]: Failed at step CGROUP spawning /etc/init.d/ntp: No such file or directory Kind regards, Bernhard root@raspberrypi:/# dpkg -l cgroup-bin Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionArchitecture Description +++-==-==-==-= ii cgroup-bin 0.41-6 allcontrol and monitor control groups (transitional package) root@raspberrypi:/# dpkg -L cgroup-bin /. /usr /usr/share /usr/share/doc /usr/share/doc/cgroup-bin /usr/share/doc/cgroup-bin/changelog.Debian.gz /usr/share/doc/cgroup-bin/copyright /etc/init.d/cgroup-bin root@raspberrypi:/# ls -lisah /etc/init.d/cgroup-bin 36115 4.0K -rwxr-xr-x 1 root root 950 Dec 18 2013 /etc/init.d/cgroup-bin root@raspberrypi:/# cat /etc/init.d/cgroup-bin #! /bin/sh ### BEGIN INIT INFO # Provides: init-cgroups # Required-Start:mountkernfs # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Mounts cgroup filesystems ### END INIT INFO
Bug#785508: [Nano-devel] Debian Bug#785508: nano: python highlighting fragile in v2.4
On Mon, May 18, 2015, at 19:29, Alexandre Detiste wrote: the starting sequence must be followed by a non-newline character (exactly one occurence in the pgm I'm working on, see attachments) Well, yes. But that is my favourite docstring: the triple quotes on lines by themselves. :) Well I spent all my day in nano on a raspberry pi editing a 3000 lines pgm; so I'd prefer to pick fast matching (#5) over 100% correct matching. (#7) Well, comment #7 says that the patch is costly, but I doubt that it will be noticeably slower than the current method of invalidating the precalculations and then recalculating them (possibly wrongly) on the fly. I think that up to ten, twenty, thirty thousand lines the difference will be hardly noticeable. Could you try? Could apply the patch and rehearse it on a testing file that consists of ten concatenated copies of your real pgm file? Benno -- http://www.fastmail.com - Faster than the air-speed velocity of an unladen european swallow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c
On Sat, May 16, 2015 at 03:43:37PM +0200, Alessandro Ghedini wrote: On Sat, May 16, 2015 at 03:07:57PM +0200, Sebastian Ramacher wrote: On 2015-05-15 15:22:28, Alessandro Ghedini wrote: On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote: Version: 6:11.3-1 On 2015-05-14 20:41:15, Arne Wichmann wrote: Package: libavcodec56 Version: 6:11.3-2 Severity: grave Tags: security Justification: user security hole Hi, as far as I can see this has not yet been reported or fixed: CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c in FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, allow remote attackers to cause a denial of service (use-after-free) or possibly have unspecified other impact via crafted Vorbis I data [1] I marked this as grave as the impact is unclear and might include arbitrary code execution. Feel free do downgrade if this can be ruled out. (Actually I would like to have a look at the test case to check a bit more thoroughly, but AFAICS I would need to talk to google for this.) [1] https://security-tracker.debian.org/tracker/CVE-2014-7937 https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html A similar commit to the one maintained in this mailing list post was applied to 11.3. So closing with that version. Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg patch at all, and the commit message doesn't even mention the bug fix. How can you be so sure that the bug is fixed? I might have read the commit wrong. Do you have a sample for this CVE? Unfortunately the reproducer isn't public. I contacted ffmpeg-security about it, I'll keep you posted. I got the reproducer from ffmpeg and it seems that libav in sid isn't affected like Sebastian said. So yeah, this bug should stay closed. I don't know if the patch linked above is what fixed the issue though. Cheers signature.asc Description: Digital signature
Bug#785508: [Nano-devel] Debian Bug#785508: nano: python highlighting fragile in v2.4
But with the python.nanorc from v2.2, the docstring at the top (the one that says expansion packages include...) wil not get coloured green, right? Only the triple quotes themselves are green, no? Surely this is not correct either? This is already correct in v2.2; the only docstrings not matched correctly are the one stated in comment #5: the starting sequence must be followed by a non-newline character (exactly one occurence in the pgm I'm working on, see attachments) Comment #7 contains a patch to avoid that problem: https://savannah.gnu.org/support/download.php?file_id=33430 If you can, please test, and report your findings Well I spent all my day in nano on a raspberry pi editing a 3000 lines pgm; so I'd prefer to pick fast matching (#5) over 100% correct matching. (#7) This single docstring could easily be fixed. 5) The downfall being the starting sequence must be followed by a non-newline character. I think that's a small price to pay to allow you have the rest of your syntax highlighting rules. If you really hate using the first line of your docstring you can always use \ to enable the regex. 7) Well, there is a patch for that, but it is costly: it reevaluates the multiline regexes for the whole file for every single edit. On a large file this will probably cause some slowdown. (With src/text.c, 3480 lines, I /think/ to notice a small delay.) Alexandre Detiste
