Bug#787298: (no subject)
On 2015-05-31 13:01:54, Martin Zobel-Helas wrote: Hi, Hi Martin, If we want to provide a vagrant box, that is an official image, i think our users will expect any of those provisioning providers to work out of the box. Thus including those into the vagrant default box makes sense. Cheers, Martin, who is a heavy user of vagrant at work! Honestly I do not know anybody who is using vagrant boxes without any additional configuration. All people I know messing around with them. So I think having minimal base and allow users to build on top of it is a good thing. I also have to agree that having base minimal box and multiply boxes with different provisioners is having lots of sense; only problem with it may be maintenance overhead but as Jan wrote this can be overcome with automated build process. Cheers, Marcin, who is a heavy user of vagrant at work as well :-) -- |_|0|_| | |_|_|0| Heghlu'Meh QaQ jajVam | |0|0|0| kuLa - | gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: Digital signature
Bug#784009: Bug#785376: transition: nettle
On 02/06/15 08:53, Jonathan Wiltshire wrote: Well that didn't appear to go so well on arm64 after all... could you look at the build log and check the version of gcc was correct please? https://buildd.debian.org/status/fetch.php?pkg=nettlearch=arm64ver=3.1.1-3stamp=1433198670 I've given it back with the gcc-4.9 b-d bumped and it has built fine. We can start with the binNMUs soon. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787411:
*Update* Today something new happened. The same freeze occurred when I connected a second monitor (this is a laptop, not sure if it's relevant). The screen was not locked. I'm not sure how these events are related... Best Regards Magnus Jonsson
Bug#787173: [Pkg-libvirt-maintainers] Bug#787173: Problem solved
On Mon, Jun 01, 2015 at 11:00:21PM +0200, Adrián Arévalo Tirado wrote: After changing the permissions and rebooting the system I am able to create new virtual machines. Changing which permissions? Please document this so others don't run into the same error. The bug can be closed. Will do once we have the root cause. Cheers, -- Guido ___ Pkg-libvirt-maintainers mailing list pkg-libvirt-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787492: ooniprobe: [l10n:cs] Initial Czech PO debconf template translation
Package: ooniprobe Version: 1.3.1-2 Severity: wishlist Tags: l10n patch Dear Maintainer, In attachment there is initial Czech translation of PO debconf template (cs.po) for package ooniprobe, please include it. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=cs_CZ.utf8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) # Czech PO debconf template translation of ooniprobe. # Copyright (C) 2015 Michal Simunek michal.simu...@gmail.com # This file is distributed under the same license as the ooniprobe package. # Michal Simunek michal.simu...@gmail.com, 2015. # msgid msgstr Project-Id-Version: ooniprobe 1.3.1-2\n Report-Msgid-Bugs-To: oonipr...@packages.debian.org\n POT-Creation-Date: 2015-06-01 08:43+0200\n PO-Revision-Date: 2015-06-02 09:15+0200\n Last-Translator: Michal Simunek michal.simu...@gmail.com\n Language-Team: Czech debian-l10n-cz...@lists.debian.org\n Language: cs\n MIME-Version: 1.0\n Content-Type: text/plain; charset=utf-8\n Content-Transfer-Encoding: 8bit\n #. Type: boolean #. Description #: ../templates:2001 msgid Run ooniprobe daily? msgstr Spouštět ooniprobe denně? #. Type: boolean #. Description #: ../templates:2001 msgid ooniprobe can be configured to run a set of basic network tests on a daily basis. This will test the current network for signs of surveillance and censorship, and send the results to the main OONI collector through the Tor network. msgstr ooniprobe lze nastavit tak, aby každý den spouštěl sadu základních testů sítě. Toto bude testovat, zda-li stávající síť nejeví známky sledování a cenzury a přes síť Tor odesílat výsledky na hlavní sběrač OONI. #. Type: boolean #. Description #: ../templates:2001 msgid If you choose this option, a daily cron job will run network tests as the \Debian-ooni\ user. msgstr Pokud tuto možnost zvolíte, bude denní úloha pro cron spouštět testy sítě pod uživatelem \Debian-ooni\. #. Type: boolean #. Description #: ../templates:2001 msgid You should be aware that running OONI may break the terms of service of your ISP or be legally questionable in your country. The software will attempt to connect to web services that may be banned, using web censorship circumvention methods such as Tor. The OONI project will publish data submitted by probes, possibly including your IP address or other identifying information. In addition, your use of OONI will be clear to anybody who has access to your computer, and to anybody who can monitor your Internet connection (such as your employer, ISP, or government). msgstr Měli byste si být vědomi toho, že spouštění OONI může porušovat podmínky služby vašeho ISP, nebo může být v rozporu s právními předpisy ve vaší zemi. Tento software se za pomoci technik obcházení cenzury webu pokusí připojit k webovým službám, jako je Tor. Údaje zjištěné sondami projekt OONI pravděpodobně zveřejní i s vaší IP adresou a dalšími identifikačními údaji. Kromě toho bude každému, kdo má přístup k počítači, a každému, kdo může sledovat vaše připojení k Internetu (jako je zaměstnavatel, ISP nebo vláda), zřejmé, že OONI používáte. #. Type: boolean #. Description #: ../templates:2001 msgid For more information on the risks associated with running ooniprobe, see / usr/share/doc/ooniprobe/RISKS. msgstr Pro více informací o rizicích spojených se spouštěním ooniprobe se podívejte do /usr/share/doc/ooniprobe/RISKS.
Bug#787298: (no subject)
On Tue, Jun 2, 2015 at 5:36 PM, Marcin Kulisz deb...@kulisz.net wrote: On 2015-05-31 13:01:54, Martin Zobel-Helas wrote: Hi, Hi Martin, If we want to provide a vagrant box, that is an official image, i think our users will expect any of those provisioning providers to work out of the box. Thus including those into the vagrant default box makes sense. Cheers, Martin, who is a heavy user of vagrant at work! Honestly I do not know anybody who is using vagrant boxes without any additional configuration. All people I know messing around with them. So I think having minimal base and allow users to build on top of it is a good thing. I also have to agree that having base minimal box and multiply boxes with different provisioners is having lots of sense; only problem with it may be maintenance overhead but as Jan wrote this can be overcome with automated build process. Cheers, Marcin, who is a heavy user of vagrant at work as well :-) http://docs.vagrantup.com/v2/provisioning/ansible.html http://docs.ansible.com/apt_module.html Either ansible via its vagrant provisioning should install aptitude or via a vagrant plugin (or just use shell provisioning in vagrant). Besides the fact that its completely silly design that the apt module depends on aptitude, the problem is upstream and it shouldn't be included in any base images. In Chef, we've been going naked for a long time now :) -- |_|0|_| | |_|_|0| Heghlu'Meh QaQ jajVam | |0|0|0| kuLa - | gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3
Bug#784009: Bug#785376: transition: nettle
Well that didn't appear to go so well on arm64 after all... could you look at the build log and check the version of gcc was correct please? https://buildd.debian.org/status/fetch.php?pkg=nettlearch=arm64ver=3.1.1-3stamp=1433198670 Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787478: jessie-pu: package how-can-i-help/10
Control: tags -1 + moreinfo On 2015-06-01 23:59, Tomasz Nitecki wrote: I'd like to update how-can-i-help with a patch that fixes grave bug #787471. It appears that all http request sent to UDD are now redirected through https. how-can-i-help was unable to handle that so the patch switched data source from http to https. Without this patch, how-can-i-help is left in an unusable state. debdiff attached. Thanks for caring about fixing this bug in stable. However, the debdiff that you attached is against the package in unstable, which is currently the same as stable and does not contain the bug fix. The expected workflow is that the bug is fixed in unstable and we'd then look at fixing it in stable as well (in a package versioned 10+deb8u1 that was built and tested on stable). Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757916: closed by Rob Browning r...@defaultvalue.org (Re: Bug#757916: emacs24-nox: abort byte-compiling notmuch-show.el on mipsel)
Debian Bug Tracking System ow...@bugs.debian.org writes: This is an automatic notification regarding your Bug report which was filed against the emacs24-nox package: #757916: emacs24-nox: abort byte-compiling notmuch-show.el on mipsel I see the same symptoms on powerpc with 24.4+1-5, so I reopened the bug. I have attached an updated version of notmuch-show.el, although I'm not sure if the changes are relevant. notmuch-show.el Description: application/emacs-lisp
Bug#785508: trading speed against correctness
I had to sudo rm /usr/share/nano/python.nanorc on several computer to get work done... I feel that reverting to 2.2 behaviour for now (matching starting as a start of block only if it's not followed directly by a new-line) would be better than letting this as-is until a correct/optimal solution is found. Alexandre 2015-05-28 17:35 GMT+02:00 Benno Schulenberg bensb...@justemail.net: So... what do others think about this tradeoff? Should the patch be applied so that syntax colouring is always recalculated and correct upon every single key stroke? Or is that too much of a cost? Or should we make the recalculation conditional? For example, up to ten thousand lines always recalculate, but beyond that let it go, give up correctness? On Thu, May 21, 2015, at 20:40, Alexandre Detiste wrote: Le mercredi 20 mai 2015, 13:15:58 Benno Schulenberg a écrit : Without the recalculation patch it gives me this: Function 805ef96 took 17 milliseconds. Function 804d564 took 21 milliseconds. *With* the recalculation patch this: Function 805efba took 840 milliseconds. Function 804d57c took 848 milliseconds. That is on a C file of a 185 thousand lines. Quite a considerable difference. How do you fare with your 30 thousand lines of Python? 400 milliseconds for both insert and removal with the patch, 2ms per insert and 12ms per removal without the patch; all of this with a very small deviation from the mean. Benno -- http://www.fastmail.com - Access your email from home and 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#697821: ITP: ppsspp -- ppsspp: A portable PSP emulator
Hi Sergio! On 06/02/2015 07:42 AM, Sergio benjamim Rocha filho wrote: Are there any progress in this ITP? I actually had an almost finished package but at some point I forgot about it because I was busy with other stuff. I had already packed it (I didn't know someone was working on it), the problem is I use 2 packages, one for SDL and other for Qt, so I need to merge them to push to mentors. You mean, you have two packages, one for the SDL and one for the Qt port? In any case, yes, you should merge them. Are you going to work yet in the packaging? I'm happy to work on the package with you together if you like. PS: they use a different version of ffmpeg, with atrac3+ enabled... I don't know if it's possible to use ffmpeg/libav from the repo. You will have to use ffmpeg or libav from the repositories. Embedded libraries, especially something like ffmpeg/libav are a no-no on Debian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787398: Acknowledgement (evolution-data-server: SMTP connection lost while reading message data)
Control: fixed -1 3.16.2-1 *sigh* will this work? signature.asc Description: This is a digitally signed message part
Bug#787430: Please provide udeb of libncursesw5
Hello Sven Joachim. Thanks for your quick and very useful reply. On Mon, Jun 01, 2015 at 09:10:17PM +0200, Sven Joachim wrote: On 2015-06-01 18:55 +0200, Andreas Henriksson wrote: [...] Since util-linux builds tools used by the debian installer and thus provides udebs, all dependencies will also need to provide udebs. AFAIK the only affected program would be cfdisk, or is there any other program in util-linux which currently uses slang? Only cfdisk-udeb. Thus, please provide an udeb for libncursesw5 (and in turn libtinfo5). I'm not too keen on doing that. Have you asked on debian-boot about their opinion? Last time the issue came up, just dropping cfdisk-udeb was among the proposals[1]. My attempts at poking the installer people have not resulted in any useful feedback. Given that we're now early in the cycle I'm willing to just go with something and wait for the installer people to scream if I broke something, and then fix it. Thanks for your historic reference, which I was not aware of. Maybe dropping cfdisk-udeb is an ok solution... [...] _If_ we are to build udebs from ncurses, I gladly accept patches, but I would like to avoid that if possible. Sounds like you're not totally opposed to it then. How about the following plan: I send a mail to debian-boot suggesting dropping cfdisk-udeb. If noone says anything I'll follow up with uploading such a package. If there are backlashes, we'll handle it by adding the udeb to ncursesw5 and reenabling cfdisk-udeb (now built against ncursesw5). Does that sound ok to you? Cheers, Sven 1. https://lists.debian.org/debian-boot/2011/02/msg00990.html 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#787494: dolfin: FTBFS on arm64 and armel
Source: dolfin Version: 1.5.0-3 See https://buildd.debian.org/status/package.php?p=dolfinsuite=sid The relevant part of the log is, I think: -- The Fortran compiler identification is unknown ... -- Try OpenMP Fortran flag = [ ] -- Performing Test OpenMP_FLAG_DETECTED -- Performing Test OpenMP_FLAG_DETECTED - Failed -- Try OpenMP Fortran flag = [-fopenmp] -- Performing Test OpenMP_FLAG_DETECTED CMake Error: CMAKE_Fortran_COMPILER not set, after EnableLanguage CMake Error: Internal CMake error, TryCompile configure of cmake failed A Fortran compiler is not getting installed by the Build-Depends on arm64, though it is on some other architectures. The cause seems to be this part of debian/control: libpetsc3.4.2-dev [!armel !arm64 !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386], libslepc3.4.2-dev [!armel !arm64 !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386], It's explained in debian/changelog for 29 Aug 2014: - Disable libpetsc3.4.2-dev and libslepc3.4.2-dev on amr64 since they are not available on this architecture. ( s/amr/arm/; ) Those packages are now available on arm64, so debian/control should be updated. Then dolfin should build on arm64. The same is probably true for armel. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703226: ITP: patchwork. Change to RFP
retitle 703226 RFP: patchwork -- a console or web based patch tracking system thanks I'm no longer working on this. I haven't managed to find the required spare time. best regards. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787258: FTBFS on mipsel: test-suite failures
Hi, On Mon, 2015-06-01 at 16:41 +0200, Martin Pitt wrote: Martin Pitt [2015-06-01 8:02 +0200]: Since this doesn't happen on our mipsel porter box, and I don't have any other mipsel hardware to check this on, it seems this needs some help from the mipsel buildd maintainers. It would be really helpful if our buildd and the porter box were more alike, to be able to reproduce such issues? Today's upload had no test failures: https://buildd.debian.org/status/fetch.php?pkg=systemdarch=mipselver=220-3stamp=1433167263 This was built on mipsel-aql-01. Looking into the history on https://buildd.debian.org/status/logs.php?pkg=systemdarch=mipsel it seems that mipsel-aql-01 never failed, while mipsel-manda-01 recently always failed, and eberlin is somewhat random. I guess one shouldn't read too much into that short history, presumably they are all a bit flaky. But do you know anything fundamental (kernel version etc.) where the porter box (eder) is different from these buildds? I tried building systemd on a few different machines and couldn't get it to fail on any of them. Then I looked at what packages were installed on the buildds. On the machines it fails on, sysvinit-core is installed and on mipsel-aql-01 (which passed the tests) systemd-sysv is installed. I then found this: https://bitbucket.org/Tarnyko/uselessd/issue/7/uselessd-7-test-strv-fails-on-slackware Presumably systemd has never been installed within the mipsel-manda-01 buildd chroot and so no machine-id has ever been generated for it (which the tests rely on). Thanks, James signature.asc Description: This is a digitally signed message part
Bug#787490: curl: VMWare doesn't start anymore
Package: curl Version: 7.42.1-1 Severity: important Dear Maintainer, since upgrade of curl from 7.42.1-1 to 7.42.1-2 vmware stopps with signal 11 during start (if you switch the vm-windows): $ vmware Unexpected signal: 11. VMware Workstation Error: VMware Workstation unrecoverable error: (vmui) Unexpected signal: 11. A log file is available in /tmp/vmware-schroed/vmware-ui-3652.log. You can request support. To collect data to submit to VMware support, choose Collect Support Data from the Help menu. You can also run the vm-support script in the Workstation folder directly. We will respond on the basis of your support entitlement. From the .log: 2015-06-02T09:52:53+02:00[+0.175]| vmui| W110: Caught signal 11 -- tid 3652 (addr 88) 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: SIGNAL: rip 0x7f75755d6833 rsp 0x7ffd3bf27b10 rbp 0x7ffd3bf27b50 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: SIGNAL: rax 0x80 rbx 0x100 rcx 0x3f0 rdx 0x7ffd3bf27b50 rsi 0x7f75752d7260 rdi 0x7f757a1f85a0 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: r8 0x7f7579947018 r9 0x7f757a090390 r10 0x7ffd3bf27910 r11 0x7f75755d67f0 r12 0x7f75752d7260 r13 0x30 r14 0x6 r15 0x7f757a1f85a0 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: SIGNAL: stack 7FFD3BF27B10 : 0x7ffd3bf27b50 0x0100 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: SIGNAL: stack 7FFD3BF27B20 : 0x7f757a1f82b0 0x7f757a06de00 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: SIGNAL: stack 7FFD3BF27B30 : 0x 0x7f757a7fb050 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: SIGNAL: stack 7FFD3BF27B40 : 0x7f756b4900c8 0x7f75752d66e7 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: SIGNAL: stack 7FFD3BF27B50 : 0x7f757a1f82b0 0x 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: SIGNAL: stack 7FFD3BF27B60 : 0x7f757a1f85a0 0x7f757555d1cd 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: SIGNAL: stack 7FFD3BF27B70 : 0x7f757a06e000 0x7f75752d3e1a 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: SIGNAL: stack 7FFD3BF27B80 : 0x7f757a06e000 0x7f757a06e010 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: Backtrace: 2015-06-02T09:52:53+02:00[+0.175]| vmui| I120: Backtrace[0] 7ffd3bf27460 rip=7f756b84d7de rbx=7f756b84d5b0 rbp= r12=7f757803d6c0 r13=7ffd3bf27b90 r14=7ffd3bf27b90 r15=000b 2015-06-02T09:52:53+02:00[+0.176]| vmui| I120: Backtrace[1] 7ffd3bf27490 rip=7f756b6342b9 rbx=000b rbp=0004 r12=7f757803d6c0 r13=7ffd3bf27b90 r14=7ffd3bf27b90 r15=000b 2015-06-02T09:52:53+02:00[+0.176]| vmui| I120: Backtrace[2] 7ffd3bf27580 rip=7f75775668d0 rbx=0100 rbp=7ffd3bf27b50 r12=7f75752d7260 r13=0030 r14=0006 r15=7f757a1f85a0 2015-06-02T09:52:53+02:00[+0.177]| vmui| I120: Backtrace[3] 7ffd3bf27b10 rip=7f75755d6833 rbx=0100 rbp=7ffd3bf27b50 r12=7f75752d7260 r13=0030 r14=0006 r15=7f757a1f85a0 2015-06-02T09:52:53+02:00[+0.180]| vmui| I120: SymBacktrace[0] 7ffd3bf27460 rip=7f756b84d7de in function Util_BacktraceWithFunc in object /usr/lib/vmware/lib/libvmwarebase.so.0/libvmwareb ase.so.0 loaded at 7f756b491000 2015-06-02T09:52:53+02:00[+0.180]| vmui| I120: SymBacktrace[1] 7ffd3bf27490 rip=7f756b6342b9 in function (null) in object /usr/lib/vmware/lib/libvmwarebase.so.0/libvmwarebase.so.0 loaded at 7f756b491000 2015-06-02T09:52:53+02:00[+0.180]| vmui| I120: SymBacktrace[2] 7ffd3bf27580 rip=7f75775668d0 in function (null) in object /lib/x86_64-linux-gnu/libpthread.so.0 loaded at 7f7577557000 2015-06-02T09:52:53+02:00[+0.180]| vmui| I120: SymBacktrace[3] 7ffd3bf27b10 rip=7f75755d6833 in function lh_doall_arg in object /usr/lib/vmware/lib/libcrypto.so.1.0.1/libcrypto.so.1.0.1 l oaded at 7f75754f8000 2015-06-02T09:52:53+02:00[+0.180]| vmui| I120: SymBacktrace[4] 7ffd3bf27b50 rip=7f75752d66e7 in function SSL_CTX_flush_sessions in object /usr/lib/vmware/lib/libssl.so.1.0.1/libssl.so.1.0 .1 loaded at 7f7575291000 2015-06-02T09:52:53+02:00[+0.180]| vmui| I120: SymBacktrace[5] 7ffd3bf27b80 rip=7f75752d3e1a in function SSL_CTX_free in object /usr/lib/vmware/lib/libssl.so.1.0.1/libssl.so.1.0.1 loaded at 7f7575291000 2015-06-02T09:52:53+02:00[+0.180]| vmui| I120: SymBacktrace[6] 7ffd3bf27ba0 rip=7f756b274c3f in function (null) in object /usr/lib/x86_64-linux-gnu/libcurl.so.4 loaded at 7f756b21c000 2015-06-02T09:52:53+02:00[+0.180]| vmui| I120: SymBacktrace[7] 7ffd3bf27bc0 rip=7f756b23ec11 in function (null) in object /usr/lib/x86_64-linux-gnu/libcurl.so.4 loaded at 7f756b21c000 2015-06-02T09:52:53+02:00[+0.180]| vmui| I120: SymBacktrace[8] 7ffd3bf27be0 rip=7f756b2422f8 in function (null) in object /usr/lib/x86_64-linux-gnu/libcurl.so.4 loaded at 7f756b21c000 2015-06-02T09:52:53+02:00[+0.180]| vmui|
Bug#787489: curl: vmware crashs with signal 11
Package: curl Version: 7.42.1-1 Severity: important Dear Maintainer, since upgrade of curl from 7.42.1-1 to 7.42.1-2 vmware stopps with signal 11 during start. Is there a problem with libcurl3-gnutls (#342719)? $ vmware --version VMware Workstation 11.1.0 build-2496824 Bye -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-1-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 curl depends on: ii libc6 2.19-18 ii libcurl3 7.42.1-1 ii zlib1g1:1.2.8.dfsg-2+b1 curl recommends no packages. curl 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#766352: transition: libplist
On 27/05/15 23:47, Emilio Pozuelo Monfort wrote: Control: tags -1 = confirmed On 27/05/15 22:12, Chow Loong Jin wrote: On Sat, May 16, 2015 at 04:49:45PM +0100, Jonathan Wiltshire wrote: Control: tag -1 moreinfo Hi, On 2014-10-22 14:18, Chow Loong Jin wrote: libplist recently has had an ABI bump with the new upstream release, changing libplist.so.2 - libplist.so.3 and libplist++.so.2 - libplist++.so.3. Do all reverse dependencies build successfully with the new SONAME? The list can be found at https://release.debian.org/transitions/html/libplist.html Yes, except xbmc. However, xbmc itself FTBFS due to a libcec-related error. It doesn't look related to the libplist change. Shall I reupload it to unstable to begin the transition? Yes, go ahead. It is failing on many arches with symbol mismatches: https://buildd.debian.org/status/package.php?p=libplist Cheers, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787491: ITP: sphde -- Shared Persistent Heap Data Environment
Package: wnpp Severity: wishlist SPHDE is composed of two major software layers: The Shared Address Space (SAS) layer provides the basic services for a shared address space and transparent, persistent storage. The Shared Persistent Heap (SPH) layer organizes blocks of SAS storage into useful functions for storing and retrieving data. License: EPL-1 Copyright: 2015 International Business Machines Corporation and others. URL: https://github.com/sphde/sphde -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766352: transition: libplist
On Tue, Jun 02, 2015 at 10:11:16AM +0200, Emilio Pozuelo Monfort wrote: On 27/05/15 23:47, Emilio Pozuelo Monfort wrote: Control: tags -1 = confirmed On 27/05/15 22:12, Chow Loong Jin wrote: On Sat, May 16, 2015 at 04:49:45PM +0100, Jonathan Wiltshire wrote: Control: tag -1 moreinfo Hi, On 2014-10-22 14:18, Chow Loong Jin wrote: libplist recently has had an ABI bump with the new upstream release, changing libplist.so.2 - libplist.so.3 and libplist++.so.2 - libplist++.so.3. Do all reverse dependencies build successfully with the new SONAME? The list can be found at https://release.debian.org/transitions/html/libplist.html Yes, except xbmc. However, xbmc itself FTBFS due to a libcec-related error. It doesn't look related to the libplist change. Shall I reupload it to unstable to begin the transition? Yes, go ahead. It is failing on many arches with symbol mismatches: https://buildd.debian.org/status/package.php?p=libplist Odd. Let me just fix that.. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#787488: one more screenshot
Hello, And now this (see the attachment). -- Cheers, Andrew pgpy2c5ZZqhZR.pgp Description: OpenPGP digital signature
Bug#787497: python-daemon: Unusable with new version of python-lockfile
Package: python-daemon Version: 1.5.5-1 Severity: important This code no longer works due to changes in python-lockfile: import daemon.pidlockfile Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/pymodules/python2.7/daemon/pidlockfile.py, line 33, in module class PIDLockFile(LinkFileLock, object): TypeError: Error when calling the metaclass bases function() argument 1 must be code, not str python-daemon needs to migrate to the new python-lockfile support and depend on that version. This is mentioned in the python-lockfile NEWS file which was uploaded (by you) to unstable: As of version 0.9, the Python API in ‘lockfile’ breaks backward compatibility with older versions. I've had to downgrade python-lockfile to the version in testing to get a working python-daemon operation. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores) 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 python-daemon depends on: ii python 2.7.9-1 ii python-lockfile 1:0.8-2 ii python-support 1.0.15 python-daemon recommends no packages. python-daemon 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#782126: apt-cacher: apt-cacher-import.pl calculates invalid Content-Length header
package apt-cacher tag 782126 pending thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742832: newer tinymce version needed by zarafa-webapp
block 783640 with 742832 thanks On Sat, Oct 18, 2014 at 04:23:20PM -0400, Simon Fondrie-Teitler wrote: This is also a Mediagoblin dependency. Could you update to the newest version? If you don't have time, do you mind if someone puts together an NMU? The zarafa-webapp is also needing a newer tinymce package. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787496: libdrm: FTBFS: unconditionally includes deprecated-on-Linux sysctl header
Source: libdrm Version: 2.4.60-3 Severity: important Justification: fails to build from source (but built successfully in the past) Hi, your last kFreeBSD patch added an unconditional inclusion of the sys/sysctl.h header. Unfortunately, people on Linux don’t like it and deprecated it to the point it’s a hard failure on new architectures, such as x32. I’m currently building libdrm with a local trivial patch to use autoconf mechanisms to check for it. @kFreeBSD porters: please *never* add this header unconditionally any more but *always* use autoconf mechanisms to check whether it is actually usable first (note it exists but has a hard #error). Thanks! -- System Information: Debian Release: stretch/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787477: swap-cwm: Error importing uripath when running cant
Hi Martin, Quoting Martin Martinez Rivera (2015-06-02 00:52:31) When I run the command cant from the terminal the python interpreter throws an error stating uripath could not be found. I looked at the code of cant.py and I realized the probable source of the error. Line 62 in my version of the file states: import uripath However, in the previous lines, that library is already being imported using an try-catch block to first try to import it from the swap module and if an exception is triggered import it as in the line above. I believe, the possible cause of the error is simply that someone forgot to delete that second import statement. Commenting it out fixes the crash and I am confident that it should not affect the correctness of the outcome but I am not familiar with the command, as I need swap-cwm for some personal work and I was just getting acquinted with the package. Thanks for the detailed bugreport. I agree with your assesment. - 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#787496: libdrm: FTBFS: unconditionally includes deprecated-on-Linux sysctl header
tags 787496 + patch thanks Hi again, now I’ve got the bugnumber, a debdiff and a build log. Enjoy, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steegdiff -u libdrm-2.4.60/debian/changelog libdrm-2.4.60/debian/changelog --- libdrm-2.4.60/debian/changelog +++ libdrm-2.4.60/debian/changelog @@ -1,3 +1,11 @@ +libdrm (2.4.60-3+x32) unreleased; urgency=medium + + * Non-maintainer upload. + * Fix kfreebsd patch that caused an FTBFS on Linux/x32: (Closes: #787496) +only include sys/sysctl.h if configure detects it. + + -- Thorsten Glaser t.gla...@tarent.de Tue, 02 Jun 2015 11:29:50 +0200 + libdrm (2.4.60-3) unstable; urgency=medium [ Timo Aaltonen ] diff -u libdrm-2.4.60/debian/patches/Fix-headers-inclusion-in-xf86drmMode.c.diff libdrm-2.4.60/debian/patches/Fix-headers-inclusion-in-xf86drmMode.c.diff --- libdrm-2.4.60/debian/patches/Fix-headers-inclusion-in-xf86drmMode.c.diff +++ libdrm-2.4.60/debian/patches/Fix-headers-inclusion-in-xf86drmMode.c.diff @@ -9,8 +9,22 @@ xf86drmMode.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) -diff --git a/xf86drmMode.c b/xf86drmMode.c -index 61d5e01..de37548 100644 +Updated by Thorsten “mirabilos” Glaser t.gla...@tarent.de +to add autoconf check and only include sys/sysctl.h if it +is detected by configure as it’s unusable on Linux/x32 (and +others, e.g. other new architectures). + +--- a/configure.ac b/configure.ac +@@ -41,7 +41,7 @@ AC_USE_SYSTEM_EXTENSIONS + AC_SYS_LARGEFILE + AC_FUNC_ALLOCA + +-AC_CHECK_HEADERS([sys/mkdev.h]) ++AC_CHECK_HEADERS([sys/mkdev.h sys/sysctl.h]) + + # Initialize libtool + LT_PREREQ([2.2]) --- a/xf86drmMode.c +++ b/xf86drmMode.c @@ -32,6 +32,9 @@ @@ -26,17 +40,15 @@ -@@ -39,12 +42,9 @@ +@@ -39,11 +42,10 @@ */ #include stdint.h #include sys/ioctl.h -+#include sys/sysctl.h - #include stdio.h - +-#include stdio.h +- -#ifdef HAVE_CONFIG_H -#include config.h --#endif -- ++#ifdef HAVE_SYS_SYSCTL_H ++#include sys/sysctl.h + #endif ++#include stdio.h + #include xf86drmMode.h #include xf86drm.h - #include drm.h --- -2.1.4 - libdrm_2.4.60-3+x32_x32.build.xz Description: application/xz
Bug#786715: stellarium: Uses private copies of external headers
Le 01/06/2015 21:20, Sune Vuorela a écrit : On Monday 01 June 2015 16:21:59 Thibaut Paumard wrote: Le 24/05/2015 20:46, Sune Vuorela a écrit : Source: stellarium Version: 0.13.3-1 Severity: serious Hi, I think the severity of this bug is overstated. There is no reason why this should warrant removing stellarium from testing. It is fragile and broken and just waiting to fall apart. Upstream is working on the issue, I suggest downgrading the severity to normal or important at most. 3) in my case would have been 'normal' or 'important', but the fact that it uses *its own* copy of headers and the actual symbols from Qt is just broken. Had it at least used it's own copy of qzip.cpp, we could have started a discussion, but this isn't the case. (src/CMakeLists.txt in the archive contains IF(!WIN32), and given it is more or less nonsense from a cmake pov, it just evaluates to false. IF(NOT WIN32) would likely have given closer to expected behaviour ) /Sune Hi, Quoting: https://www.debian.org/Bugs/Developer.en.html#severities serious is a severe violation of Debian policy (roughly, it violates a must or required directive), or, in the package maintainer's or release manager's opinion, makes the package unsuitable for release. In this instance, I fail to see which section of the Policy is being violated. Anyway, the bug is going to be resolved soon. The only difference between the important and serious severities at the moment is whether or not stellarium will be removed from testing and loose exposure to beta testers. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785681: apt-cacher: Infinite loop in ssl_proxy()
package apt-cacher tag 785681 pending thanks On Tue, Jun 02, 2015 at 02:38:04AM +, Michael Deegan wrote: Hello, On Mon, 1 Jun 2015 at 19:05:19, Mark Hindley m...@hindley.org.uk wrote: I have been thinking about this, in particular this thread: http://www.perlmonks.org/bare/?node_id=167036 shutdown(1) seems to be the best we can do to pass the EOF on. How does this patch work for you? Seems to work, according to my testing. Good. I will queue this for the next upload (1.7.11) which I hope will be within the next week. Mark -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787495: Debian Bug Tracking System sub...@bugs.debian.org
Package: rdesktop Version: 1.8.2-3 Severity: grave Tags: newcomer Justification: renders package unusable Dear Maintainer, I've a script to use Windows machines remotely. It worked fine on wheezy. No I have problem even at browsing directories provided from my Linux client with disk argument. The used command is: rdesktop -d OUR-DOMAIN -k hu -r disk:becks=/home/ratki/becks -g 1650x990 msoffice-0$1 If I try to browse on becks disk the window is closed after some clicks and I get the following message: WARNING: rdp_out_unistr: iconv(2) fail, errno 84 *** Error in `rdesktop': free(): invalid pointer: 0x0107155c *** It would be great to use it again as before upgrade. Thanks, Tamás -- 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/2 CPU cores) Locale: LANG=hu_HU.utf8, LC_CTYPE=hu_HU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rdesktop depends on: ii libasound21.0.28-1 ii libc6 2.19-18 ii libgssglue1 0.4-2 ii libpcsclite1 1.8.13-1 ii libssl1.0.0 1.0.1k-3 ii libx11-6 2:1.6.2-3 ii libxrandr22:1.4.2-1+b1 rdesktop recommends no packages. Versions of packages rdesktop suggests: pn pcscd 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#742110: ITP gestioip, change to RFP
Control: retitle -1 RFP: gestioip -- Web-based IP address management software I haven't enough spare time to work on this package. The code of my package is at https://github.com/aborrero/pkg-gestioip best regards -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786401: dose: Fatal error: exception Parsing.Parse_error
On Mon, 2015-06-01 at 21:50 +0200, Ralf Treinen wrote: should be done now. Thanks for that, with today's dose-job we are down to this: (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used (W)Sources: modifier any for indep dependency python used -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#786401: dose: Fatal error: exception Parsing.Parse_error
On Tue, Jun 02, 2015 at 02:58:53PM +0800, Paul Wise wrote: On Mon, 2015-06-01 at 21:50 +0200, Ralf Treinen wrote: should be done now. Thanks for that, with today's dose-job we are down to this: (W)Sources: modifier any for indep dependency python used I have to leave for work now - Josch, do you where this is coming from ? Maybe passing the --quiet option helps. -Ralf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787488: screen image is randomly corrupted
Package: xserver-xorg-video-intel Version: 2:2.99.917-1 Severity: normal Hi, I'm not sure this is the right package to file a bug against, so please reassign if needed. A recent update to something in the X stack causes random font corruptions. Some of the characters display as blocks or random noise, or change over time (first render normally, but after a window refresh display incorrectly). I have also noticed window manager decorations are sometimes corrupted too. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Apr 3 2009 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 2544344 May 5 00:49 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) Xorg X server configuration file status: -rw-r--r-- 1 root root 1683 Apr 23 2013 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section ServerLayout Identifier Layout 1 Screen Default Screen InputDevice Generic Keyboard CoreKeyboard InputDevice Configured Mouse CorePointer EndSection Section ServerFlags Option DontZap off EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbOption grp:ctrl_shift_toggle Option XkbModel pc104 Option XkbLayout by(latin),ru(winkeys),by(winkeys) EndSection Section InputDevice Identifier Configured Mouse Driver mouse EndSection Section Device Identifier Configured Video Device # Driver vesa # Driver ati EndSection Section Monitor Identifier VGA1 EndSection Section Monitor Identifier DVI1 EndSection Section Monitor Identifier LVDS1 DisplaySize 331 207 EndSection Section Screen Identifier Default Screen Monitor LVDS1 DefaultDepth24 SubSection Display Depth 24 #Modes 1024x768 800x600 640x480 #Virtual 1024 768 EndSubSection EndSection /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 4.0.0-1-686-pae (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11) Xorg X server log files on system: -- -rw-r--r-- 1 root root 40098 Aug 7 2013 /var/log/Xorg.21.log -rw-r--r-- 1 root root 36966 Aug 7 2013 /var/log/Xorg.20.log -rw-r--r-- 1 root root 125805 Apr 1 07:34 /var/log/Xorg.1.log -rw-r--r-- 1 root root 99530 Apr 1 07:34 /var/log/Xorg.2.log -rw-r--r-- 1 root root 34426 Jun 2 05:58 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 358.825] X.Org X Server 1.17.1 Release Date: 2015-02-10 [ 358.825] X Protocol Version 11, Revision 0 [ 358.825] Build Operating System: Linux 3.16.0-4-amd64 i686 Debian [ 358.825] Current Operating System: Linux ileemo 4.0.0-1-686-pae #1 SMP Debian 4.0.2-1 (2015-05-11) i686 [ 358.825] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.0.0-1-686-pae root=UUID=c2f152ed-b2d8-43f4-8064-d89f5d53cab2 ro fastboot quiet [ 358.825] Build Date: 04 May 2015 10:46:42PM [ 358.825] xorg-server 2:1.17.1-2 (http://www.debian.org/support) [ 358.825] Current version of pixman: 0.30.2 [ 358.825]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 358.825] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 358.825] (==) Log file: /var/log/Xorg.0.log, Time: Mon Jun 1 11:18:00 2015 [ 358.826] (==) Using config file:
Bug#787493: FTBFS with GCC 5 and Perl 5.22
Source: libapache2-mod-perl2 Version: 2.0.9~rc2-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Building with GCC 5 and Perl 5.22 (also built with GCC 5) from experimental. Build stops with [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /raid/build/work/libapache2-mod- perl2-2.0.9~rc2/t/TEST -httpd_conf '/raid/build/work/libapache2-mod- perl2-2.0.9~rc2/debian/apache2.conf' -bugreport -verbose=1 AH00558: apache2: Could not reliably determine the server's fully qualified doma in name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message (2)No such file or directory: AH02291: Cannot access directory '/raid/build/work/libapache2-mod-perl2-2.0.9~rc2/t/logs/' for main error log AH00014: Configuration check failed /usr/sbin/apache2 -d /raid/build/work/libapache2-mod-perl2-2.0.9~rc2/t -f /raid/build/work/libapache2-mod-perl2-2.0.9~rc2/t/conf/httpd.conf -D APACHE2 -D APACHE2_4 -D PERL_USEITHREADS using Apache/2.4.12 waiting 300 seconds for server to start: .[Mon Jun 01 22:31:36.041661 2015] [env:warn] [pid 15692:tid 140437197727616] AH01506: PassEnv variable LD_LIBRARY_PATH was undefined Segmentation fault (core dumped) [ error] oh golly, server dumped core Running under gdb shows: Program received signal SIGSEGV, Segmentation fault. 0x735f89ce in modperl_env_init () at modperl_env.c:639 639 StructCopy(MP_vtbl_env, PL_vtbl_env, MGVTBL); (gdb) b modperl_env_init Breakpoint 1 at 0x735f88e0: file modperl_env.c, line 635. (gdb) l 634 /* save originals */ 635 StructCopy(PL_vtbl_env, MP_PERL_vtbl_env, MGVTBL); 636 StructCopy(PL_vtbl_envelem, MP_PERL_vtbl_envelem, MGVTBL); 637 638 /* replace with our versions */ 639 StructCopy(MP_vtbl_env, PL_vtbl_env, MGVTBL); 640 StructCopy(MP_vtbl_envelem, PL_vtbl_envelem, MGVTBL); 641 } 642 643 void modperl_env_unload(void) StructCopy(src, dst, type) from Perl API essentially does *dst = *src. In line 639 the destination is PL_vtbl_env which is #define'd as some element of the array PL_magic_vtables from Perl internals (I checked that it's index is well within the bounds of the array) (gdb) whatis PL_magic_vtables type = const MGVTBL [31] Note the const here! (gdb) info symbol PL_magic_vtables PL_magic_vtables in section .data.rel.ro of /usr/lib/x86_64-linux- gnu/libperl.so.5.22 So, GCC has put PL_magic_vtables into a read-only section, hence trying to write to it deservedly produces a segfault. Cheers, Roderich -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers wily APT policy: (500, 'wily'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-rc6 (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) -- 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#787522: libfile-monitor-perl: list of features in package description probably should have one item split in two
On Tue, 02 Jun 2015 15:38:53 +0200, Beatrice Torracca wrote: Seeing how the second Notify starts with a capital letter, I imagine that it should be split into 2 items like so: « * Notify when a monitored file is deleted * Notify when files are added or removed from a directory » Nice catch, thank you. Fixed in git, will be in the next upload. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Alanis Morisette: Mary Jane signature.asc Description: Digital Signature
Bug#787440: libpar-packer-perl: FTBFS with perl 5.22
Control: tags -1 + fixed-upstream On Tue, 02 Jun 2015 20:20:03 +0200, gregor herrmann wrote: Doesn't look good with 1.025: Gnarf. Both me and the build system missed - Module::ScanDeps: '1.15' + Module::ScanDeps: '1.17' at the first try. After upgrading libmodule-scandeps-perl and installing it in the chroot all is fine. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Funny van Dannen: Holy Man signature.asc Description: Digital Signature
Bug#776536: /usr/bin/eog: Crash raising a gdk error when opening png test images
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=672990#c2 Seems that this is a know limitation of cairo. It can't handle images with an horizontal or vertical size greater than 32K pixels. :( signature.asc Description: OpenPGP digital signature
Bug#782475: libcap2 needs an udeb package for d-i, since udev depends on it
On Sun, 12 Apr 2015 22:17:49 +0200 Matthias Klumpp m...@debian.org wrote: Package: libcap2 Version: 1:2.24-6 Severity: normal Tags: patch Hi! Since systemd 217[1], libudev1, and therefore libudev1-udeb, depends on libcap2. In order to still get d-i to build, libcap would need to provide a udeb for d-i. A debdiff for adding the required udeb is attached. Just a quick comment on the patch: I see you added a debian/shlibs.local file, but since the package itself doesn't build other udebs, which depend on libcap2-udeb, it looks like this shlibs.local is not needed and can be dropped. Is this maybe just CP from an existing package like udev? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#787561: modules virtio_net and virtio_pci are allowed to be removed but they should not be
Package: linux-image-3.16.0-4-amd64
Version: 3.16.7-ckt9-3~deb8u1
Severity: important
Note: I'm not sure which package to blame here. I chose the kernel
because I believe the kernel knows better than anybody else which
modules are suitable to be unloaded and which modules are not, but
this could also be a bug in qemu or a bug in kmod, so feel free to
reassign.
rmmod(8) says:
-f, --force
This option can be extremely dangerous: it has no effect unless
CONFIG_MODULE_FORCE_UNLOAD was set when
the kernel was compiled. With this option, you can remove modules which
are being used, or which are not
designed to be removed, or have been marked as unsafe (see lsmod(8)).
which implicitly means that as long as you don't use --force, rmmod
will refuse to remove a module if it's being used.
Well, I tried this today on a virtual machine running qemu:
lsmod | awk '$3 == 0 { print $1 }' | xargs -r rmmod
and the machine *crashed*, which I think it should count as
module being used or not designed to be removed.
To debug this, I tried to remove modules one by one until problems
started to appear. This is the result:
Attach lsmod-starting-point.txt is the output of lsmod before the tests.
Attach modules-that-may-be-removed.txt is the list of modules that may
be removed safely, this way:
rmmod `cat modules-that-may-be-removed.txt`
After that, the output of lsmod is like this:
Module Size Used by
evdev 17445 1
autofs435529 2
ext4 473802 1
crc16 12343 1 ext4
mbcache17171 1 ext4
jbd2 82413 1 ext4
virtio_net 26553 0
virtio_blk 17345 3
virtio_pci 17389 0
virtio_ring17513 3 virtio_blk,virtio_net,virtio_pci
virtio 13058 3 virtio_blk,virtio_net,virtio_pci
and now it comes the fun part:
I'm not using the console but ssh. So I'm using the net.
However:
rmmod virtio_net
works and makes the ssh connection to be lost.
I think this should not happen.
Then it comes the really fun part:
rmmod virtio_pci
also works, but the result is I/O error in the root partition,
which becomes read-only and the system needs to be rebooted.
See last attach screenshot.png.
I think this should not happen either.
Thanks.Module Size Used by
joydev 17063 0
hid_generic12393 0
ppdev 16782 0
usbhid 44460 0
evdev 17445 2
hid 102264 2 hid_generic,usbhid
psmouse99143 0
serio_raw 12849 0
pcspkr 12595 0
virtio_console 22655 0
virtio_balloon 13047 0
pvpanic12563 0
parport_pc 26300 0
parport35749 2 ppdev,parport_pc
ttm77862 0
drm_kms_helper 49210 0
processor 28221 0
thermal_sys27642 1 processor
drm 249955 2 ttm,drm_kms_helper
i2c_piix4 20864 0
i2c_core 46012 3 drm,i2c_piix4,drm_kms_helper
button 12944 0
autofs435529 2
ext4 473802 1
crc16 12343 1 ext4
mbcache17171 1 ext4
jbd2 82413 1 ext4
virtio_net 26553 0
virtio_blk 17345 3
ata_generic12490 0
crc32c_intel 21809 0
ehci_pci 12512 0
uhci_hcd 43499 0
ehci_hcd 69837 1 ehci_pci
usbcore 195340 4 uhci_hcd,ehci_hcd,ehci_pci,usbhid
usb_common 12440 1 usbcore
ata_piix 33592 0
floppy 65068 0
virtio_pci 17389 0
virtio_ring17513 5
virtio_blk,virtio_net,virtio_pci,virtio_balloon,virtio_console
virtio 13058 5
virtio_blk,virtio_net,virtio_pci,virtio_balloon,virtio_console
libata177457 2 ata_generic,ata_piix
scsi_mod 191405 1 libata
joydev
hid_generic
ppdev
usbhid
hid
psmouse
serio_raw
pcspkr
virtio_console
virtio_balloon
pvpanic
parport_pc
parport
ttm
drm_kms_helper
processor
thermal_sys
drm
i2c_piix4
i2c_core
button
ata_generic
crc32c_intel
ehci_pci
uhci_hcd
ehci_hcd
usbcore
usb_common
ata_piix
floppy
libata
scsi_mod
Bug#787342: RFP - ITP
Control: retitle -1 ITP: ptyprocess -- Run a subprocess in a pseudo terminal from Python I had a look and it seems like it should be pretty easy to package. Snark on #debian-python -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787553: fails to boot with a dracut generated initramfs
Control: tags -1 moreinfo hi Am 02.06.2015 um 19:43 schrieb Arto Jantunen: Package: systemd Version: 220-1 Severity: grave The new upload to unstable broke booting with dracut. The initramfs attempts to run /usr/lib/systemd/systemd-fsck to fsck the rootfs. Since on Debian (and in the initramfs) this binary is actually at /lib/systemd/systemd-fsck this fails The binary has always been named /lib/systemd/systemd-fsck and hasn't changed between v215 and v220, so I doubt this is really the issue here. I wonder if this is the addition of /lib/systemd/systemd-fsckd, a component which is not shipped by systemd upstream and is responsible for fsck progress reporting. Could you rebuild your dracut initramfs and include /lib/systemd/systemd-fsckd /lib/systemd/system/systemd-fsckd.socket /lib/systemd/system/systemd-fsckd.service and see if that makes a difference. When you're dropped into the emergency shell, you should be able to get a journalctl -alb dump. Please attach that to the bug report. Thanks Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#319575: Patch for one-per-line
I took a stab at adding a configuration option for one-package-per-line
output. I'm not sure if adding a configuration option is the best way to
(though it certainly works for me), and I imagine the documentation also
needs to be updated if this is accepted.
Description: Add CmdLine::One-Per-Line configuration option
Added a configuration option for forcing aptitude 'package list' output
to be one-package-per-line. Defaults to OFF.
Author: Tim Gokcen hexe...@gmail.com
Bug-Debian: http://bugs.debian.org/540081
Bug-Debian: http://bugs.debian.org/319575
--- aptitude-0.6.8.2.orig/src/cmdline/cmdline_util.cc
+++ aptitude-0.6.8.2/src/cmdline/cmdline_util.cc
@@ -119,21 +119,32 @@ void cmdline_show_stringlist(strvector
int loc=2;
- printf( );
-
- for(strvector::iterator i=items.begin(); i!=items.end(); ++i)
+ const bool onePerLine = aptcfg-FindB(PACKAGE ::CmdLine::One-Per-Line, false);
+ if (!onePerLine)
{
- if(loc + i-size() (unsigned)(screen_width - 5))
- {
- printf(\n );
- loc=2;
- }
+printf( );
- printf(%s , i-c_str());
- loc+=i-size()+1;
-}
+for(strvector::iterator i=items.begin(); i!=items.end(); ++i)
+ {
+ if(loc + i-size() (unsigned)(screen_width - 5))
+ {
+ printf(\n );
+ loc=2;
+ }
+
+ printf(%s , i-c_str());
+ loc+=i-size()+1;
+ }
- printf(\n);
+printf(\n);
+}
+ else
+{
+for(strvector::iterator i=items.begin(); i!=items.end(); ++i)
+ {
+ printf( %s\n, i-c_str());
+ }
+}
}
void cmdline_show_pkglist(pkgvector items,
Bug#787553: fails to boot with a dracut generated initramfs
Package: systemd Version: 220-1 Severity: grave The new upload to unstable broke booting with dracut. The initramfs attempts to run /usr/lib/systemd/systemd-fsck to fsck the rootfs. Since on Debian (and in the initramfs) this binary is actually at /lib/systemd/systemd-fsck this fails, thus stopping the boot and dropping me into the emergency shell. It is possible to symlink those paths together and restart the failing unit (iirc systemd-fsck-root.service), which succeeds. However if I follow the instructions and simply exit the emergency shell bootup does not continue (nothing happens). -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-rc5 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-2 ii libapparmor12.9.2-3 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.26.2-6 ii libc6 2.19-18 ii libcap2 1:2.24-8 ii libcap2-bin 1:2.24-8 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.3-2 ii libkmod220-1 ii liblzma55.1.1alpha+20120614-2+b3 ii libmount1 2.26.2-6 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 220-4 ii mount 2.26.2-6 ii sysv-rc 2.88dsf-59.2 ii udev220-4 ii util-linux 2.26.2-6 Versions of packages systemd recommends: ii dbus1.8.18-1 ii libpam-systemd 220-4 Versions of packages systemd suggests: pn systemd-ui none -- Configuration Files: /etc/systemd/journald.conf changed [not included] /etc/systemd/logind.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787554: initramfs-tools: failed to start /dev/mdx, Usage: readlink, Can't find /root in /etc/fstab
Hi So I now use my old initrd and my old kernel (2.6.32) to boot my system. (from Wheezy/oldstable) I got that wrong, it is 3.2.0 ... Jochen -- ZX81 - C64 - Amiga - x86-Linux - iMac (OS X) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787440: libpar-packer-perl: FTBFS with perl 5.22
Control: tags -1 + confirmed - fixed-upstream On Mon, 01 Jun 2015 19:28:18 +0100, Dominic Hargreaves wrote: Source: libpar-packer-perl Version: 1.022-1 Severity: important User: debian-p...@lists.debian.og Usertags: perl-5.22-transition Tags: fixed-upstream This package FTBFS with perl 5.22: Unicode::Normalize: CombiningClass.pl not found at if.pm line 13. Compilation failed in require at if.pm line 13. BEGIN failed--compilation aborted at Unicode/UCD.pm line 399. Compilation failed in require at script/ppPYaNN.pl line 1. BEGIN failed--compilation aborted at script/ppPYaNN.pl line 1. # Failed test 'successfully ran /tmp/B8uwzaNV6n/rt59710' # at t/90-rt59710.t line 27. # Failed test 'name of U+0042' # at t/90-rt59710.t line 28. # got: '' # expected: 'LATIN CAPITAL LETTER B' # Looks like you failed 2 tests of 3. t/90-rt59710.t ... 1..3 This is probably fixed upstream in version 1.023 and later. Doesn't look good with 1.025: Unicode::Normalize: CombiningClass.pl not found at if.pm line 13. Compilation failed in require at if.pm line 13. BEGIN failed--compilation aborted at Unicode/UCD.pm line 399. Compilation failed in require at script/ppBfffc.pl line 1. BEGIN failed--compilation aborted at script/ppBfffc.pl line 1. # Failed test 'successfully ran /tmp/SspjnYVy8M/rt59710' # at t/90-rt59710.t line 27. # Failed test 'name of U+0042' # at t/90-rt59710.t line 28. # got: '' # expected: 'LATIN CAPITAL LETTER B' # Looks like you failed 2 tests of 3. t/90-rt59710.t ... 1..3 ok 1 - successfully packed /tmp/SspjnYVy8M/rt59710 not ok 2 - successfully ran /tmp/SspjnYVy8M/rt59710 not ok 3 - name of U+0042 Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests Test Summary Report --- t/90-rt59710.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 Files=6, Tests=73, 51 wallclock secs ( 0.05 usr 0.00 sys + 43.78 cusr 5.34 csys = 49.17 CPU) Result: FAIL Failed 1/6 test programs. 2/73 subtests failed. Makefile:922: recipe for target 'test_dynamic' failed Cheers, gregor, forwarding the bug report -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Misha Alperin: Psalm No.2 signature.asc Description: Digital Signature
Bug#787146: ITP: Gambatte - Game Boy and Game Boy Color emulator
owner 541157 ! thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787146: ITP: Gambatte - Game Boy and Game Boy Color emulator
owner 787146 ! thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787559: urlopen error [SSL: CERTIFICATE_VERIFY_FAILED]
Hi Ingmar, On Tue, Jun 02, 2015 at 08:23:37PM +0200, I. Schrey wrote: feeds are becoming unusable when they get switched from http to https. ---snip config--- feed 1h https://rss.packetstormsecurity.com/ http_proxy=http://proxy:3128/ ---snip config--- Since that's an https: URL rather than an http: one, you'll need to specify https_proxy rather than (or as well as) http_proxy. If you're using proxies for all your feeds, it's easier to put the proxy settings in a feeddefaults command rather than specifying them on each feed individually: feeddefaults http_proxy http://proxy:3128/ https_proxy http://proxy:3128/ Thanks, -- Adam Sampson a...@offog.org http://offog.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787554: initramfs-tools: failed to start /dev/mdx, Usage: readlink, Can't find /root in /etc/fstab
Package: initramfs-tools Version: 0.120 Severity: important Hi I have some problems booting with initrd, it doesn't look linke other bug reports I saw, so here my bug report ... :-) Screenshot: http://jochen.hin.de/diverses/initramfs-tools-bug.jpg First the kernel has already startet /dev/md2 and /dev/md3 on my system. So could I ignore the messages which try to Assemblling MD array? Then there seems to be a problem with a readlink-call: Usage: readlink ... Then it says Can't find /root in /etc/fstab After than I am stuck in BusyBox. The Raid is already startet, the Root FS is /dev/md2 and ready to mount. The /usr FS is on a LVM (on /dev/md3) which is not started yet. I could manualy mount the Root FS and the /usr FS, also /dev, /proc, /sys (to /root) but I don't know how to initiate the init from there. (chroot and start the real init) So I now use my old initrd and my old kernel (2.6.32) to boot my system. (from Wheezy/oldstable) Could you help please? Jochen -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 16M May 29 19:11 /boot/initrd.img-3.16.0-4-686-pae -rw-r--r-- 1 root root 11M May 30 08:17 /boot/initrd.img-3.2.0-4-686-pae -rw-r--r-- 1 root root 11M May 30 08:18 /boot/initrd.img-3.2.0-4-686-pae2 -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-686-pae root=UUID=84e9ea7c-4cb0-4c08-a024-278c79dab426 ro nmi_watchdog=1 nouveau.nomodeset=0 vga=791 -- resume # RESUME=/dev/sda2 #RESUME='UUID=89c6c0b8-7dc5-474e-ad93-67c9fa9c1ab2' -- /proc/filesystems ext3 fuseblk -- lsmod Module Size Used by tcp_diag 12400 0 inet_diag 17001 1 tcp_diag binfmt_misc12813 1 xt_multiport 12492 2 ipt_REJECT 12454 1 ipt_LOG12533 1 nf_conntrack_ipv4 13726 2 nf_defrag_ipv4 12443 1 nf_conntrack_ipv4 xt_conntrack 12601 2 nf_conntrack 43121 2 xt_conntrack,nf_conntrack_ipv4 xt_owner 12391 3 xt_tcpudp 12506 6 iptable_filter 12488 1 ip_tables 17079 1 iptable_filter x_tables 18158 8 ip_tables,iptable_filter,xt_tcpudp,xt_owner,xt_conntrack,ipt_LOG,ipt_REJECT,xt_multiport cpufreq_stats 12762 0 cpufreq_userspace 12520 0 cpufreq_conservative12987 0 cpufreq_powersave 12422 0 nfsd 173901 2 nfs 265953 0 nfs_acl12463 2 nfs,nfsd auth_rpcgss32143 2 nfs,nfsd fscache31978 1 nfs lockd 61373 2 nfs,nfsd sunrpc148000 6 lockd,auth_rpcgss,nfs_acl,nfs,nfsd raid45647757 1 async_raid6_recov 12518 1 raid456 async_memcpy 12363 2 async_raid6_recov,raid456 async_pq 12542 2 async_raid6_recov,raid456 ves1x9312825 0 raid6_pq 86874 2 async_pq,async_raid6_recov async_xor 12390 3 async_pq,async_raid6_recov,raid456 xor21608 1 async_xor async_tx 12540 5 async_xor,async_pq,async_memcpy,async_raid6_recov,raid456 pl2303 17094 0 usbserial 27365 1 pl2303 radeon644939 0 ttm47786 1 radeon psmouse59609 0 drm_kms_helper 22738 1 radeon drm 146387 3 drm_kms_helper,ttm,radeon serio_raw 12803 0 dvb_ttpci 71302 6 stv029913144 1 pcspkr 12515 0 power_supply 13283 1 radeon i2c_i801 12670 0 i2c_algo_bit 12713 1 radeon ttpci_eeprom 12413 1 dvb_ttpci saa7146_vv 27541 1 dvb_ttpci saa714617218 2 saa7146_vv,dvb_ttpci dvb_core 68110 2 stv0299,dvb_ttpci videobuf_dma_sg13055 1 saa7146_vv videobuf_core 17561 2 videobuf_dma_sg,saa7146_vv videodev 61658 1 saa7146_vv iTCO_wdt 16945 0 media 13692 1 videodev snd_hda_codec_hdmi 26352 1 evdev 17225 3 iTCO_vendor_support12632 1 iTCO_wdt i2c_core 19116 10 videodev,ttpci_eeprom,i2c_algo_bit,i2c_i801,stv0299,drm,dvb_ttpci,drm_kms_helper,radeon,ves1x93 snd_hda_codec_via 32200 1 acpi_cpufreq 12807 0 mperf 12421 1 acpi_cpufreq snd_hda_intel 21786 0 snd_hda_codec 63477 3 snd_hda_intel,snd_hda_codec_via,snd_hda_codec_hdmi snd_hwdep 12943 1 snd_hda_codec snd_pcm53461 3 snd_hda_codec,snd_hda_intel,snd_hda_codec_hdmi snd_page_alloc 12867 2 snd_pcm,snd_hda_intel snd_timer 22356 1 snd_pcm snd42761 7 snd_timer,snd_pcm,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_via,snd_hda_codec_hdmi soundcore 12921 1 snd button 12817 0 processor 27565 1 acpi_cpufreq
Bug#787555: lvm2: Unmount of invalid (full) snapshot unmounts main device too
Package: lvm2
Version: 2.02.111-2.2
Severity: important
Last night lvm2 tried to murder my server.
OK, exaggerating a little bit, but it did something that seems not only
wrong, but quite bad.
The system was running a backup tool, using LVM snapshots to get coherent
views of the filesystem.
The snapshot for /var filled up.
LVM decided to forcibly unmount the snapshot, which I guess is OK based on
the information I've found on why this behavior was introduced, but it also
forcibly unmounted the main device, resulting in the sudden and
unceremonious loss of /var on the server, which had many unpleasant effects.
Jun 2 01:32:32 cheetah kernel: [5957103.322426] device-mapper: snapshots:
Invalidating snapshot: Unable to allocate exception.
Jun 2 01:32:33 cheetah lvm[9693]: Unmounting invalid snapshot raid5-var--snap
from /mnt/runbackup.8194.28259/var.
Jun 2 01:32:33 cheetah lvm[9693]: Unmounting invalid snapshot raid5-var--snap
from /var.
It looks like something got quite confused as to what device was backing
/var.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/12 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 lvm2 depends on:
ii dmeventd 2:1.02.90-2.2
ii dmsetup 2:1.02.90-2.2
ii init-system-helpers 1.23
ii initscripts 2.88dsf-59.2
ii libc6 2.19-18
ii libdevmapper-event1.02.1 2:1.02.90-2.2
ii libdevmapper1.02.12:1.02.90-2.2
ii libreadline5 5.2+dfsg-2
ii libudev1 215-18
ii lsb-base 4.1+Debian13+nmu1
lvm2 recommends no packages.
Versions of packages lvm2 suggests:
pn thin-provisioning-tools none
-- Configuration Files:
/etc/lvm/lvm.conf changed:
config {
# If enabled, any LVM2 configuration mismatch is reported.
# This implies checking that the configuration key is understood
# by LVM2 and that the value of the key is of a proper type.
# If disabled, any configuration mismatch is ignored and default
# value is used instead without any warning (a message about the
# configuration key not being found is issued in verbose mode only).
checks = 1
# If enabled, any configuration mismatch aborts the LVM2 process.
abort_on_errors = 0
# Directory where LVM looks for configuration profiles.
profile_dir = /etc/lvm/profile
}
devices {
# Where do you want your volume groups to appear ?
dir = /dev
# An array of directories that contain the device nodes you wish
# to use with LVM2.
scan = [ /dev ]
# If set, the cache of block device nodes with all associated symlinks
# will be constructed out of the existing udev database content.
# This avoids using and opening any inapplicable non-block devices or
# subdirectories found in the device directory. This setting is applied
# to udev-managed device directory only, other directories will be scanned
# fully. LVM2 needs to be compiled with udev support for this setting to
# take effect. N.B. Any device node or symlink not managed by udev in
# udev directory will be ignored with this setting on.
obtain_device_list_from_udev = 1
# If several entries in the scanned directories correspond to the
# same block device and the tools need to display a name for device,
# all the pathnames are matched against each item in the following
# list of regular expressions in turn and the first match is used.
# By default no preferred names are defined.
# preferred_names = [ ]
# Try to avoid using undescriptive /dev/dm-N names, if present.
# preferred_names = [ ^/dev/mpath/, ^/dev/mapper/mpath, ^/dev/[hs]d ]
# In case no prefererred name matches or if preferred_names are not
# defined at all, builtin rules are used to determine the preference.
#
# The first builtin rule checks path prefixes and it gives preference
# based on this ordering (where dev depends on devices/dev setting):
# /dev/mapper /dev/disk /dev/dm-* /dev/block
#
# If the ordering above cannot be applied, the path with fewer slashes
# gets preference then.
#
# If the number of slashes is the same, a symlink gets preference.
#
# Finally, if all the rules mentioned above are not applicable,
# lexicographical order is used over paths and the smallest one
# of all gets preference.
# A filter that tells LVM2 to only use a restricted set of devices.
# The filter consists of an array of regular expressions. These
# expressions can be delimited by a character of your choice, and
# prefixed with either an 'a' (for accept) or 'r' (for reject).
# The first expression
Bug#787201: RFP - ITP
Control: retitle -1 ITP: python-terminado -- a tornado websocket backend for the term.js javascript terminal emulator library Snark on #debian-python -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787554: initramfs-tools: failed to start /dev/mdx, Usage: readlink, Can't find /root in /etc/fstab
This is a spf/dkim authentication-failure report for an email message received from IP 82.195.75.100 on Wed, 03 Jun 2015 02:21:18 +0800. Below is some detail information about this message: 1. SPF-authenticated Identifiers: none; 2. DKIM-authenticated Identifiers: none; 3. DMARC Mechanism Check Result: Identifier non-aligned, DMARC mechanism check failures; For more information please check Aggregate Reports or mail to ab...@163.com. binYF1dSBCwbt.bin Description: message/feedback-report Received: from localhost (localhost [127.0.0.1]) by bendel.debian.org (Postfix) with QMQP id 73960106; Tue, 2 Jun 2015 18:21:15 + (UTC) Old-Return-Path: debb...@buxtehude.debian.org X-Original-To: lists-debian-bugs-d...@bendel.debian.org Delivered-To: lists-debian-bugs-d...@bendel.debian.org Received: from localhost (localhost [127.0.0.1]) by bendel.debian.org (Postfix) with ESMTP id 5C32F9E for lists-debian-bugs-d...@bendel.debian.org; Tue, 2 Jun 2015 18:21:15 + (UTC) X-Virus-Scanned: at lists.debian.org with policy bank bug X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-1 required=5.3 tests=[BAYES_00=-1.9, DKIM_ADSP_DISCARD=1.8, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from bendel.debian.org ([127.0.0.1]) by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525) with ESMTP id QEgqzA-BgGd4 for lists-debian-bugs-d...@bendel.debian.org; Tue, 2 Jun 2015 18:21:11 + (UTC) Received: from buxtehude.debian.org (buxtehude.debian.org [140.211.166.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN buxtehude.debian.org, Issuer Debian SMTP CA (not verified)) by bendel.debian.org (Postfix) with ESMTPS id B17CDE5; Tue, 2 Jun 2015 18:21:11 + (UTC) Received: from debbugs by buxtehude.debian.org with local (Exim 4.84) (envelope-from debb...@buxtehude.debian.org) id 1YzqoG-000366-FE; Tue, 02 Jun 2015 18:21:08 + X-Loop: ow...@bugs.debian.org Subject: Bug#787554: initramfs-tools: failed to start /dev/mdx, Usage: readlink, Can't find /root in /etc/fstab Reply-To: Jochen Pawletta joc...@hin.de, 787...@bugs.debian.org Resent-From: Jochen Pawletta joc...@hin.de Resent-To: debian-bugs-dist@lists.debian.org Resent-CC: Debian kernel team debian-ker...@lists.debian.org X-Loop: ow...@bugs.debian.org Resent-Date: Tue, 02 Jun 2015 18:21:06 + Resent-Message-ID: handler.787554.b787554.143326901510...@bugs.debian.org X-Debian-PR-Message: followup 787554 X-Debian-PR-Package: initramfs-tools X-Debian-PR-Keywords: X-Debian-PR-Source: initramfs-tools Received: via spool by 787554-sub...@bugs.debian.org id=B787554.143326901510652 (code B ref 787554); Tue, 02 Jun 2015 18:21:06 + Received: (at 787554) by bugs.debian.org; 2 Jun 2015 18:16:55 + X-Spam-Bayes: score:0. Tokens: new, 14; hammy, 88; neutral, 26; spammy, 0. spammytokens: hammytokens:0.000-+--H*UA:2014-03-12, 0.000-+--H*u:2014-03-12, 0.000-+--H*UA:1.5.23, 0.000-+--H*u:1.5.23, 0.000-+--Wheezy Received: from anton.hin.de ([78.138.108.14] ident=postfix) by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84) (envelope-from joc...@joshua.hin.de) id 1YzqkB-0002lc-DS for 787...@bugs.debian.org; Tue, 02 Jun 2015 18:16:55 + Received: from localhost (localhost [127.0.0.1]) by anton.hin.de (Postfix) with ESMTP id 84C814F002D for 787...@bugs.debian.org; Tue, 2 Jun 2015 20:10:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hin.de Received: from anton.hin.de ([127.0.0.1]) by localhost (anton.hin.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NariZ48hpDdx for 787...@bugs.debian.org; Tue, 2 Jun 2015 20:10:08 +0200 (CEST) Received: by anton.hin.de (Postfix, from userid 10) id 0C5D34F003D; Tue, 2 Jun 2015 20:10:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hin.de; s=anton201310; t=1433268606; bh=Z1vjceXhULlXg6GzsY6X0oZqI52AdNyzAualn9avR5c=; h=Date:From:To:Subject:References:In-Reply-To; b=OvoIU82fXgchPh191CKIYCVa/sjulUCOJID/EDaxnacynldrlFVAaPUldH42qRupe OMcIjz5TdBIYiTi2xqMHQYfxGuH4Ws6NrAiiW9VGMaKc/OB6UVVDxFZ22mGUwPCjfA OeJ5TU2cPE3m1fLgL/1OD8ZSTwiusJqFEs4UGsKQ= Received: from localhost (localhost [127.0.0.1]) by joshua.hin.de (Postfix) with ESMTP id 2B52F1C01D for 787...@bugs.debian.org; Tue, 2 Jun 2015 20:05:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at joshua.hin.de Received: from joshua.hin.de ([127.0.0.1]) by localhost (joshua.hin.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpYuChiWK7GD for 787...@bugs.debian.org; Tue, 2 Jun 2015 20:05:17 +0200 (CEST) Received: by joshua.hin.de (Postfix, from userid 1001) id 030171C0A2; Tue, 2 Jun 2015 20:05:16 +0200 (CEST) Date: Tue, 2 Jun 2015 20:05:16 +0200 From: Jochen Pawletta joc...@hin.de To: 787...@bugs.debian.org Message-ID: 20150602180516.ga14...@joshua.hin.de References:
Bug#782475: Bug#787542: libudev1-udeb depends on missing libcap2
Control: block -1 by 782475 Hi KiBi et al, Am 02.06.2015 um 18:11 schrieb Cyril Brulebois: libudev1-udeb depends on missing libcap2. I suspect the easiest would be to drop libcap2 support from the udeb build. An alternative would be to try and add a udeb in libcap2. I'd rather have the former happen, so Unfortunately, the libcap dependency is not really optional, i.e. it can not be turned off with a --disable-libcap configure switch. While we could try and hack the build system and ifdeffing this code out, I'd much prefer if we didn't have to do that and simply build a udeb for libcap Matthias already provided a patch for that [1]. @Christian, you mentioned that you were ok with this patch and wanted to include this in your next upload. Would be great if you can proceed with the upload now that v220 is in unstable which depends on it. Cheers, Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782475 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#786607: git-buildpackage: Please make gbp pull to also fetch git notes (refs/notes/commits)
On Sat, May 23, 2015 at 02:22:15PM +0200, Axel Beckert wrote: Package: git-buildpackage Version: 0.6.27 Severity: wishlist User: debian-p...@lists.debian.org Usertags: bcn2015 Control: block 636482 by -1 Control: affects -1 + pkg-perl-tools gitpkg Dear GBP Maintainer(s), it would be nice, if gbp pull would also fetch git notes. They're in no branch, you need to fetch refs/notes/commits. Background is that there's a feature request with patch by Niko Tyni open against git-debcherry (from the gitpkg package) which makes it use git notes. See https://bugs.debian.org/784159 for details about that. Another reason to support pulling git notes is https://bugs.debian.org/636482 (git-buildpackage: Please support git note for changelog generation) by Alexander Wirt which will be less useful without support for getting those notes from the remote repository. We (the Debian Perl Team) recently pushed a change to dpt push (which is in the package pkg-perl-tools and kind of the opposite of gbp pull) to support git notes when pushing: http://deb.li/3is24 The request is perfectly valid. Hope to get around to add this soonish. As usual: any patches for this are welcome! gbp pull is one of the rather undermaintained commands since I'm not using it often myself. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787558: git-dpm: --ptc flag is ignored for import-new-upstream if --rebase-patched sees merge conflicts
Package: git-dpm Version: 0.9.1-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, To update to a new upstream release, I do this: $ git-dpm import-new-upstream --ptc --rebase-patched ../foo.orig.tar.gz Normally, if the patches rebase cleanly, everything is fine. However, if there are merge conflicts during rebase, you have to of course manually resolve them, followed by git add and git rebase --continue. Once all that's done and your patched branch is looking good, a git-dpm u-p will get you back on master, but the pristine-tar commit will *not* have happened. It's as if --ptc is ignored when - --rebase-patched inflicts merge conflicts. You can fix this manually with $ pristine-tar commit ../foo.orig.tar but you have to remember to do this, and if you don't you have the potential of messing up your master branch. In my case, quilt saw fuzz in the patch and there was no way to fix it. Checking out the patched branch and re-editing the file doesn't help, and neither does quilt refresh in master, nor rebasing patched against upstream. - -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git-dpm depends on: ii dpkg-dev 1.18.1 ii git 1:2.1.4-2.1 Versions of packages git-dpm recommends: ii bzip2 1.0.6-8 ii devscripts 2.15.4 ii sensible-utils 0.0.9 ii xz-utils5.1.1alpha+20120614-2+b3 Versions of packages git-dpm suggests: ii pristine-tar 1.33 ii sharutils 1:4.15.1-1 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVbfVfAAoJEBJutWOnSwa/YZ8P/1TSTIqpbdl2G5w6FDYojwPg NABoTIkx5Itje0dASK4IguQsWkBiifShSEqvDv13XFNifaIgmK0hoHNET3tU8abu ewn2fFOCjSydXxmWf+qonE2XN0FwtR44QDDNmye+JL7vdCr44pWO57TZPKV2TWfu fEexTv9gSHOupjWRIrdJ4OQpKLuXPP/ixcB0ZZZluL/6Vu/hjmafGVmvPcf7o+fX Q277ZZT6A5+9Q/A5JfIAIU2cTuXLCJ8OQ0qCH3tldiS8TssgndUBokpQULk7q7y3 o1tQ3xRoVwavUku3FeUpBVvwZEE00RtJvYcS8gfJhUvh279pnVCdKA6oohqxz2ew vO4Vn5t6r7Br0+oMpKWoBRQDiVfIUbSiPWhgda5JeqWB0CbyMuL4dyJhoy1S3FnN LTTj6IaU3PPtMsz51YP6i8eQIXbx181M5hq/h3meuipFXliCyq5nvW3NrDpWbqF8 PAIsvPKovvQq7mKWPmNH6QO6V4fylv62KufbzPkRSu5JNR33TXqAWcm/OL39hs8F fUHbZjC8+ebClee8u527ZXJ48XMxVVeBzbHG6pU4VrMKQUEnS/H8KXL9csV2MbCa AYqgRyEkTu4EAbFYUSKd00JqYp79Dgy5Xw1/BaMYIbhzoUmN+0FXKLSvnuBxPOh7 aMA0ofW39uCIlmTfAMM4 =tae7 -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#787559: urlopen error [SSL: CERTIFICATE_VERIFY_FAILED]
Package: rawdog Version: 2.20-1 Hi, feeds are becoming unusable when they get switched from http to https. ---snip config--- feed 1h https://rss.packetstormsecurity.com/ http_proxy=http://proxy:3128/ ---snip config--- rawdog gets executed via cron: /usr/bin/rawdog -d /my/dir --update --write and producing errors like the following: ---snip cron mail body--- Feed:https://rss.packetstormsecurity.com/ Error while fetching feed: urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) ---snip cron mail body--- Am I doing something wrong? I've been using rawdog via proxy for 10 years or so, and it used to just work. Unfortunately, it's a bit of work for me to test without proxy, but if you think that I should try - just say so. Best regards Ingmar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787174: closed by Joey Hess i...@joeyh.name (Re: Bug#787174: remove unblockable new tab ads)
https://bugzilla.mozilla.org/show_bug.cgi?id=1103599 So I'm not the only one to have filed a bug about this, which was closed with no, that can't be! Also, perhaps relevant that I have DNT enabled in preferences. Some of mozilla's own documentation claims that these ads are not shown when DNT is enabled. Perhaps they got the logic totally backwards. -- see shy jo signature.asc Description: Digital signature
Bug#787560: calibre: Calibre can't communicate with file managers
Package: calibre Version: 2.24.0+dfsg-1 Severity: important Dear Maintainer, After upgrading to Debian/stretch I found that Calibre was unable to open pdf books, with errors such as Unable to find the requested file. Please check the spelling and try again. Unhandled error message: Error when getting information for file '...': No such file or directory (when my prefered file manager is Nautilus) and a nautilus window is opened. Later I found the same message when trying to open a Path. Changing my prefered file manager to thunar through exo-preferred- applications the message changes to Failed to open ... Error when getting information for file '..': No such file or directory. I noticed that the message seems to come from the file manager, not from Calibre. I also noticed that the file name passed to the file manager has spaces replaced by '%20'. The files do exist and I can open them from both file managers by clicking on them. Furthermore, I can open the same book in other formats from the same directory using Calibre. I could also open the pdf's after installing the 'Open With' plugin and configuring it for opening pdf files. So I guess the problem is related to the protocol used to communicate with the file managers. Best regards, Luis -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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 calibre depends on: ii calibre-bin2.24.0+dfsg-1 ii fonts-liberation 1.07.4-1 ii imagemagick8:6.8.9.9-5 ii libjs-mathjax 2.5.3-1 ii poppler-utils 0.26.5-2 ii python-apsw3.8.6-r1-1 ii python-beautifulsoup 3.2.1-1 ii python-chardet 2.3.0-1 ii python-cherrypy3 3.5.0-2 ii python-cssselect 0.9.1+git90c72b0-1 ii python-cssutils1.0-2 ii python-dateutil2.2-2 ii python-dbus1.2.0-2+b3 ii python-feedparser 5.1.3-3 ii python-imaging 2.6.1-2 ii python-lxml3.4.2-1 ii python-markdown2.6.2-1 ii python-mechanize 1:0.2.5-3 ii python-netifaces 0.10.4-0.1 ii python-pil 2.6.1-2 ii python-pkg-resources 16.0-2 ii python-pyparsing 2.0.3+dfsg1-1 ii python-pyqt5 5.3.2+dfsg-3 ii python-pyqt5.qtsvg 5.3.2+dfsg-3 ii python-pyqt5.qtwebkit 5.3.2+dfsg-3 ii python-routes 2.0-1 ii python2.7 2.7.10-1 ii xdg-utils 1.1.0~rc1+git20111210-7.4 Versions of packages calibre recommends: ii python-dnspython 1.12.0-1 calibre 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#787553: fails to boot with a dracut generated initramfs
Control: tags -1 = upstream patch Am 02.06.2015 um 20:07 schrieb Michael Biebl: Am 02.06.2015 um 19:43 schrieb Arto Jantunen: The new upload to unstable broke booting with dracut. The initramfs attempts to run /usr/lib/systemd/systemd-fsck to fsck the rootfs. Since on Debian (and in the initramfs) this binary is actually at /lib/systemd/systemd-fsck this fails Quick followup here. This regression is most likely caused by [1], where systemd now generates a systemd-fsck-root.service in the initramfs, which overrides the statically shipped fsck units. This generated unit uses a hard-coded path to /usr/lib/systemd/systemd-fsck. There was a followup fix [2], which replaces the hard-coded path. Arto wanted to test this patch. If successful, we will cherry-pick that commit for the next upload. [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=4dda4e637e4c [2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=77eb82f9f0f6 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#787310:
I encountered the same problem yesterday. I managed to fix it by downgrading perl-base to the version in stable (5.20.2-3) I don't know what the difference is between the versions but the older one works properly. Best Regards Magnus Jonsson
Bug#787525: upgrade-reports: hibernate-disk and Gnome
Control: tags -1 moreinfo On 2015-06-02 15:53, Lothar wrote: Package: upgrade-reports Severity: normal Dear Maintainer, since upgrading from Wheezie to Jessie, when resuming from a hibernate-disk (on a ThinkPad T60), the Gnome Desktop comes up not with a locked screen (as it still does when resuming from light sleep), but with the user session wide open, without ever prompting for a password. As the text screens behave similarly, there does not seem to be any safe way to use hibernate-disk anymore. Thank you [...] Hi, Thanks for taking your time to report an upgrade issue. Could you please describe exactly how you performed the hibernate to disk causing this issue? Thanks, ~Niels signature.asc Description: OpenPGP digital signature
Bug#787557: exo-utils: exo-open seems confused by escaped characters in URL's
Package: exo-utils Version: 0.10.6-1 Severity: normal Dear Maintainer, With exo-open I can open a file or directory with embedded spaces using a command like exo-open 'A B' exo-open 'A\ B' or exo-open 'file:/home/user/A B' but I can't open the file using URL escaped characters as in exo-open 'file:/home/user/A%20B' I found this problem while using Calibre, as it replaces spaces by %20's before opening files. I'm sorry I'm not sure if this is Calibre's fault or exo-open's fault. Thanks, Luis -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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 exo-utils depends on: ii libc6 2.19-18 ii libexo-1-0 0.10.6-1 ii libgdk-pixbuf2.0-0 2.31.4-2 ii libglib2.0-02.44.1-1 ii libgtk2.0-0 2.24.25-3 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util7 4.12.1-2 exo-utils recommends no packages. exo-utils 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#787556: wfmath: Broken watchfile
Source: wfmath Severity: normal Tags: patch Dear Maintainer, Seems that worldforge went to github... Attached is a working one. tobi -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (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) version=3 opts=dversionmangle=s/\+dfsg\d*$//,filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/wfmath-$1\.tar\.gz/ \ https://github.com/worldforge/wfmath/releases .*/v?(\d\S*)\.tar\.gz
Bug#774195: marked as done (libnss3: libpkix incorrect prefers older, weaker certs over stronger, newer certs)
On Mon, 1 Jun 2015 16:46:35 +0900 Mike Hommey m...@glandium.org wrote: It's up to Mike whether to fix that in the upcoming point release. We're not planning a DSA for this issue alone, but it can be fixed along when upstream releases changes to address the weakdh issue. ... which, afaik, is in 3.19.1 released a few days ago (and now in unstable). Indeed it is, according to the release notes [1]: The minimum strength of keys that libssl will accept for finite field algorithms (RSA, Diffie-Hellman, and DSA) have been increased to 1023 bits (bug 1138554). A DSA fixing the weakdh and chain building issues would be great! Cheers, Andrew [1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.19.1_release_notes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787562: jython FTBFS and jython is uninstallable because of unsatisfied (build-)dependency on libjnr-posix-java (= 3.0.10~)
Source: jython Version: 2.5.3-6 Severity: grave Justification: fails to build from source Hi, jython Build-Depends on libjnr-posix-java (= 3.0.10~) but the version of libjnr-posix-java in unstable is only 1.1.8-3. Here is the relevant dose3 output for the build failure: native-architecture: amd64 report: - package: src:jython version: 2.5.3-6 architecture: all essential: false source: jython (= 2.5.3-6) status: broken reasons: - missing: pkg: package: src:jython version: 2.5.3-6 architecture: all essential: false unsat-dependency: amd64:libjnr-posix-java (= 3.0.10~) and for the uninstallability of the jython binary package (thus setting severity to grave): report: - package: amd64:jython version: 2.5.3-6 architecture: all essential: false source: jython (= 2.5.3-6) status: broken reasons: - missing: pkg: package: amd64:jython version: 2.5.3-6 architecture: all essential: false unsat-dependency: amd64:libjnr-posix-java (= 3.0.10~) Here is the FTBFS on the reproducible builds platform: https://reproducible.debian.net/rbuild/unstable/amd64/jython_2.5.3-6.rbuild.log And here the output from release.d.o about this problem: https://release.debian.org/migration/testing.pl?package=jython Since jython is part of the transitive essential set, its unbuildability also currently makes Debian unbootstrappable: http://bootstrap.debian.net/essential.html Thanks! cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787562: jython FTBFS and jython is uninstallable because of unsatisfied (build-)dependency on libjnr-posix-java (= 3.0.10~)
tags 787562 + pending confirmed thanks On Tue, Jun 02, 2015 at 09:28:17PM +0200, Johannes Schauer wrote: Source: jython Version: 2.5.3-6 Severity: grave Justification: fails to build from source Hi, jython Build-Depends on libjnr-posix-java (= 3.0.10~) but the version of libjnr-posix-java in unstable is only 1.1.8-3. Here is the relevant dose3 output for the build failure: Hi Johannes, Thanks for the report, we are aware of the issue and we are waiting for FTPmaster jnr-posix approval to solve this bug and others. https://ftp-master.debian.org/new/jnr-posix_3.0.10-2.html Thanks, -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. Faith means not wanting to know what is true. -- Nietzsche -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787564: avrdude reporting timeout error
Package: avrdude Version: 6.1-2 Severity: normal Dear Maintainer, I have try to move to Jessie. My JTAG (it's clode using CH340 for serial to USB converter and ATmega8 az MCU) was working just fine in Wheezy with avrdude 5.11 but now with 6.1 it reports timeout errors on verify. I have used a very short shell script to burn to flash of mcu. I have tried several additional options for slow down communication, using larger delays, but nothing is working. I can not use new Debian version, need stay at Wheezy. Jessie now is stable for Debian, in short time Wheezy should be fully outdated. REMARKABLE: I'm not sure that this is the Debian problem. I suspected the avrdude, or may be the USB driver or susbsystem. Thanks for your hard job! -- 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/2 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 avrdude depends on: ii libc6 2.19-18 ii libelf1 0.159-4.2 ii libftdi1 0.20-2 ii libncurses5 5.9+20140913-1+b1 ii libreadline6 6.3-8+b3 ii libtinfo5 5.9+20140913-1+b1 ii libusb-0.1-4 2:0.1.12-25 avrdude recommends no packages. Versions of packages avrdude suggests: pn avrdude-doc 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#787566: shutdown-at-night: fails to shut the system down if gdm is used
Package: shutdown-at-night
Version: 0.15
Severity: important
Tags: patch
gdm-simple-greeter seems to have been replaced with a special gnome
session; so the xsession test now fails and the system keeps running.
While the greeter is running, an (empty) directory exists which goes away
after someone logged in. So this could be used instead for the test.
The patch has been tested and will be committed to git as soon as the
bug number has been obtained.
-
diff --git a/shutdown-at-night b/shutdown-at-night
index 9411014..11a7840 100755
--- a/shutdown-at-night
+++ b/shutdown-at-night
@@ -123,8 +123,9 @@ is_xsession_used() {
/var/run/xauth/* \
/run/xauth/*; do
if [ -e $s ] ; then
-if XAUTHORITY=$s DISPLAY=:0 xlsclients | egrep -q
'kdmgreet|lightdm-gtk-greeter|razor-lightdm-greeter|lightdm-kde-greeter|gdm-simple-greeter'
; then
-return 1
+if [ XAUTHORITY=$s DISPLAY=:0 xlsclients | egrep -q
'kdmgreet|lightdm-gtk-greeter|razor-lightdm-greeter|lightdm-kde-greeter' ] \
+ || [ -d /var/run/gdm3/greeter ] ; then
+ return 1
fi
fi
done
-
Wolfgang
signature.asc
Description: Digital signature
Bug#787256: marked as done (sudo.service:7 Failed to unescape command line, ignoring)
Control: found -1 220-4
Am 02.06.2015 um 08:51 schrieb Debian Bug Tracking System:
* Fix parsing of escape characters in Exec*= lines. (Closes: #787256)
Looks like this isn't properly fixed yet by
load-fragment-use-UNESCAPE_RELAX-flag-to-parse-exec-.patch
I know get the following error with 220-4
# systemctl start sudo.service
Job for sudo.service failed because the control process exited with error code.
See systemctl status sudo.service and journalctl -xe for details.
# systemctl status sudo.service
● sudo.service - Provide limited super user privileges to specific users
Loaded: loaded (/lib/systemd/system/sudo.service; enabled; vendor preset:
enabled)
Active: failed (Result: exit-code) since Di 2015-06-02 22:23:42 CEST; 4s ago
Process: 11782 ExecStart=/usr/bin/find /var/lib/sudo -exec /usr/bin/touch -d
@0 {} \073 (code=exited, status=1/FAILURE)
Main PID: 11782 (code=exited, status=1/FAILURE)
Jun 02 22:23:42 pluto systemd[1]: Starting Provide limited super user
privileges to specific users...
Jun 02 22:23:42 pluto find[11782]: /usr/bin/find: Fehlendes Argument für
-exec.
Jun 02 22:23:42 pluto systemd[1]: sudo.service: Main process exited,
code=exited, status=1/FAILURE
Jun 02 22:23:42 pluto systemd[1]: Failed to start Provide limited super user
privileges to specific users.
Jun 02 22:23:42 pluto systemd[1]: sudo.service: Unit entered failed state.
Jun 02 22:23:42 pluto systemd[1]: sudo.service: Failed with result 'exit-code'.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#787567: scanimage: stderr flooded with SNMP warnings(?)
Package: sane-utils
Version: 1.0.24-13
I get hundreds of SNMP warnings(?) on stderr:
$ scanimage --help
Usage: scanimage [OPTION]...
Start image acquisition on a scanner device and write image data to
standard output.
Parameters are separated by a blank from single-character options (e.g.
-d epson) and by a = from multi-character options (e.g. --device-name=epson).
-d, --device-name=DEVICE use a given scanner device (e.g. hp:/dev/scanner)
--format=pnm|tiff file format of output file
-i, --icc-profile=PROFILE include this ICC profile into TIFF file
-L, --list-devices show available scanner devices
-f, --formatted-device-list=FORMAT similar to -L, but the FORMAT of the output
can be specified: %d (device name), %v (vendor),
%m (model), %t (type), %i (index number), and
%n (newline)
-b, --batch[=FORMAT] working in batch mode, FORMAT is `out%d.pnm' or
`out%d.tif' by default depending on --format
--batch-start=#page number to start naming files with
--batch-count=#how many pages to scan in batch mode
--batch-increment=#increase page number in filename by #
--batch-double increment page number by two, same as
--batch-increment=2
--batch-prompt ask for pressing a key before scanning a page
--accept-md5-only only accept authorization requests using md5
-p, --progress print progress messages
-n, --dont-scanonly set options, don't actually scan
-T, --test test backend thoroughly
-A, --all-options list all available backend options
-h, --help display this help message and exit
-v, --verbose give even more status messages
-B, --buffer-size=#change input buffer size (in kB, default 32)
-V, --version print version information
MIB search path:
/home/jwilk/.snmp/mibs:/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
Cannot find module (SNMPv2-MIB): At line 1 in (none)
Cannot find module (IF-MIB): At line 1 in (none)
Cannot find module (IP-MIB): At line 1 in (none)
Cannot find module (TCP-MIB): At line 1 in (none)
Cannot find module (UDP-MIB): At line 1 in (none)
Cannot find module (HOST-RESOURCES-MIB): At line 1 in (none)
Cannot find module (NOTIFICATION-LOG-MIB): At line 1 in (none)
Cannot find module (DISMAN-EVENT-MIB): At line 1 in (none)
Cannot find module (DISMAN-SCHEDULE-MIB): At line 1 in (none)
Cannot find module (HOST-RESOURCES-TYPES): At line 1 in (none)
Cannot find module (MTA-MIB): At line 1 in (none)
Cannot find module (NETWORK-SERVICES-MIB): At line 1 in (none)
Cannot find module (SNMPv2-TC): At line 15 in
/usr/share/snmp/mibs/UCD-DISKIO-MIB.txt
Cannot find module (SNMPv2-SMI): At line 34 in
/usr/share/snmp/mibs/UCD-SNMP-MIB.txt
Cannot find module (SNMPv2-TC): At line 37 in
/usr/share/snmp/mibs/UCD-SNMP-MIB.txt
Did not find 'enterprises' in module #-1 (/usr/share/snmp/mibs/UCD-SNMP-MIB.txt)
Did not find 'DisplayString' in module #-1
(/usr/share/snmp/mibs/UCD-SNMP-MIB.txt)
Did not find 'TruthValue' in module #-1 (/usr/share/snmp/mibs/UCD-SNMP-MIB.txt)
Unlinked OID in UCD-SNMP-MIB: ucdavis ::= { enterprises 2021 }
Undefined identifier: enterprises near line 39 of
/usr/share/snmp/mibs/UCD-SNMP-MIB.txt
Did not find 'DisplayString' in module #-1
(/usr/share/snmp/mibs/UCD-DISKIO-MIB.txt)
Did not find 'ucdExperimental' in module UCD-SNMP-MIB
(/usr/share/snmp/mibs/UCD-DISKIO-MIB.txt)
Unlinked OID in UCD-DISKIO-MIB: ucdDiskIOMIB ::= { ucdExperimental 15 }
Undefined identifier: ucdExperimental near line 19 of
/usr/share/snmp/mibs/UCD-DISKIO-MIB.txt
Cannot find module (SNMPv2-TC): At line 10 in
/usr/share/snmp/mibs/UCD-DLMOD-MIB.txt
Did not find 'DisplayString' in module #-1
(/usr/share/snmp/mibs/UCD-DLMOD-MIB.txt)
Did not find 'ucdExperimental' in module UCD-SNMP-MIB
(/usr/share/snmp/mibs/UCD-DLMOD-MIB.txt)
Unlinked OID in UCD-DLMOD-MIB: ucdDlmodMIB ::= { ucdExperimental 14 }
Undefined identifier: ucdExperimental near line 13 of
/usr/share/snmp/mibs/UCD-DLMOD-MIB.txt
Cannot find module (SNMPv2-TC): At line 15 in
/usr/share/snmp/mibs/LM-SENSORS-MIB.txt
Did not find 'DisplayString' in module #-1
(/usr/share/snmp/mibs/LM-SENSORS-MIB.txt)
Did not find 'ucdExperimental' in module UCD-SNMP-MIB
(/usr/share/snmp/mibs/LM-SENSORS-MIB.txt)
Unlinked OID in LM-SENSORS-MIB: lmSensors ::= { ucdExperimental 16 }
Undefined identifier: ucdExperimental near line 32 of
/usr/share/snmp/mibs/LM-SENSORS-MIB.txt
Did not find 'ucdavis' in module UCD-SNMP-MIB
(/usr/share/snmp/mibs/UCD-DEMO-MIB.txt)
Unlinked OID in UCD-DEMO-MIB: ucdDemoMIB ::= { ucdavis 14 }
Undefined identifier: ucdavis near line 7 of
/usr/share/snmp/mibs/UCD-DEMO-MIB.txt
Cannot find module (SNMP-TARGET-MIB): At line
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
On 03/06/15 01:35, Daniel Kahn Gillmor wrote: This sounds like a feature, not a bug, because it means that users are now aware that their secure imap connections are probably not what they expect. Agreed, but the consequences for Debian end-users are that they may be forced to stop using a not-as-strong-as-it-could-be 768 bit DH key (*not* as weak as a 512 bit break-with-$75-ofAmazon-EC2 DH key). Instead Debian end-users have to switch to unencrypted IMAP. How does this improve security and protect users? In my view, a warning would be more appropriate, at least as a transitional measure. Most users would have no idea why their IMAP suddenly stopped working. At the least there should have been a warning issued when the Debian library was upgraded. Even better, icedove should detect the condition, offer a dire warning, and allow the user to give their informed consent to the situation, as is done for broken certs. In my view, the actions of the Mozilla NSS team were high-handed and inappropriate for a patch version release. Are these IMAP servers in the wild? Could you point me to them? Sure, buried in the original bug report: $ openssl s_client -connect ub007lcs04.cbr.the-server.net.au:993 I have notified the responsible hosting provider that they should upgrade their Courier IMAP DH key to 2048 bits. Given the state of their certificate chain (even their self-signed certificates are expired) I am not optimistic. Kind regards, -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787126: nis: please make the build reproducible
On Thu, May 28, 2015 at 11:09:13PM +0200, Dhole wrote: + find $(DEBDIR) -depth -newermt '$(BUILD_DATE)' -print0 | \ + xargs -0r touch --no-dereference --date='$(BUILD_DATE)' This looks very odd, why is this not part of dpkg? signature.asc Description: Digital signature
Bug#786661: apt-cacher: Does not work in inetd mode - fails to create /var/run/apt-cacher
Could you try/critique this initscript patch for me, please.
Thanks.
Mark
diff --git a/debian/apt-cacher.init b/debian/apt-cacher.init
index 2c38b7f..7ae1636 100644
--- a/debian/apt-cacher.init
+++ b/debian/apt-cacher.init
@@ -15,7 +15,8 @@
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC=Apt-Cacher
NAME=apt-cacher
DAEMON=/usr/sbin/$NAME
-PIDFILE=/var/run/$NAME/$NAME.pid
+RUNDIR=/var/run/$NAME
+PIDFILE=$RUNDIR/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Gracefully exit if the package has been removed.
@@ -40,6 +41,18 @@ d_start() {
echo $NAME.
else
echo Not started (AUTOSTART not enabled in /etc/default/$NAME);
+
+# apt-cacher needs $RUNDIR, but is not able to create it in inetd or
CGI mode
+ if test ! -d $RUNDIR; then
+ mkdir -m 755 $RUNDIR
+ CONFIG_FILES=/etc/$NAME/$NAME.conf $(run-parts --list
/etc/$NAME/conf.d)
+ RUN_AS_USER=$(sed -n 's/^ *user *= *//p' $CONFIG_FILES | tail -1)
+ RUN_AS_GROUP=$(sed -n 's/^ *group *= *//p' $CONFIG_FILES | tail -1)
+ [ $RUN_AS_USER ] chown $RUN_AS_USER $RUNDIR
+ [ $RUN_AS_GROUP ] chgrp $RUN_AS_GROUP $RUNDIR
+ fi
+
+
fi
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787528: Some sources are not included in your package
Quoting bastien ROUCARIÈS (roucaries.bastien+deb...@gmail.com): Package: src:console-setup version; 1.128 user: lintian-ma...@debian.org usertags: source-is-missing severity: serious X-Debbugs-CC: ftpmas...@debian.org Hi, Your package seems to include some files that lack sources in prefered forms of modification: Keyboard/locale/lib/common/xomGeneric.so.2 Keyboard/locale/lib/common/xlocale.so.2 Keyboard/locale/lib/common/xlibi18n.so.2 Keyboard/locale/lib/common/xlcUTF8Load.so.2 Keyboard/locale/lib/common/xlcDef.so.2 Keyboard/locale/lib/common/ximcp.so.2 Indeed, the package appears to build fine just *without* Keyboard/locale/lib I therefore suspect these files to be cruft left from unclean builds and sadly imported into git Anyone objecting to a simple drop of the said files and voilà? signature.asc Description: Digital signature
Bug#782475: libcap2 needs an udeb package for d-i, since udev depends on it
2015-06-02 21:03 GMT+02:00 Michael Biebl bi...@debian.org: On Sun, 12 Apr 2015 22:17:49 +0200 Matthias Klumpp m...@debian.org wrote: Package: libcap2 Version: 1:2.24-6 Severity: normal Tags: patch Hi! Since systemd 217[1], libudev1, and therefore libudev1-udeb, depends on libcap2. In order to still get d-i to build, libcap would need to provide a udeb for d-i. A debdiff for adding the required udeb is attached. Just a quick comment on the patch: I see you added a debian/shlibs.local file, but since the package itself doesn't build other udebs, which depend on libcap2-udeb, it looks like this shlibs.local is not needed and can be dropped. Is this maybe just CP from an existing package like udev? Yes, you told me that on IRC a while ago, and I told you I would update the patch, removing the superficial file. Looks like I forgot about it, sorry... ;-) Since there was no guide on how we create udeb packages these days, I just looked at what systemd does to create the udev-udeb packages. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782475: Bug#787542: libudev1-udeb depends on missing libcap2
On 2015-06-02 19:48, Michael Biebl wrote: Am 02.06.2015 um 18:11 schrieb Cyril Brulebois: libudev1-udeb depends on missing libcap2. I suspect the easiest would be to drop libcap2 support from the udeb build. An alternative would be to try and add a udeb in libcap2. I'd rather have the former happen, so Unfortunately, the libcap dependency is not really optional, i.e. it can not be turned off with a --disable-libcap configure switch. While we could try and hack the build system and ifdeffing this code out, I'd much prefer if we didn't have to do that and simply build a udeb for libcap Matthias already provided a patch for that [1]. @Christian, you mentioned that you were ok with this patch and wanted to include this in your next upload. Would be great if you can proceed with the upload now that v220 is in unstable which depends on it. Yeah, I dropped the ball a bit here... I'll take care of this over the weekend. Regards, Christian Cheers, Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782475 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787559: urlopen error [SSL: CERTIFICATE_VERIFY_FAILED]
Hi Adam, Since that's an https: URL rather than an http: one, you'll need to specify https_proxy rather than (or as well as) http_proxy. sorry, forgot to mention I already tried specifying https_proxy instead of http_proxy. (even tried https_proxy=https://...) No change, still getting that error. Best regards Ingmar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787462: libfile-sync-perl: FTBFS with perl 5.22
Control: tag -1 + unreproducible On Mon, 01 Jun 2015 20:45:02 +0100, Dominic Hargreaves wrote: Source: libfile-sync-perl Version: 0.11-2 Severity: important User: debian-p...@lists.debian.org Usertags: perl-5.22-transition This package FTBFS with perl 5.22: Builds for me. Also no CPAN RT ticket and nothing with perl 5.2[12] on cpantesters. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Van Morrison: Stand By Me signature.asc Description: Digital Signature
Bug#786444: laptop-mode-tools: DISABLE_ETHERNET_ON_BATTERY documentation is inconsistent
On Wed 2015-05-27 13:43:49 -0400, Ritesh Raj Sarraf wrote: On Friday 22 May 2015 12:16 AM, Daniel Kahn Gillmor wrote: In practice, it looks like the manpage is correct, and the comments in ethernet.conf are wrong. This is too bad, because it would be nice to avoid disabling the link when the carrier is still active. IIRC, the configuration comments are correct. This change was proposed by someone later, and the justification was similar. It should be in the git commit logs. Also, with this flag set (as it is by default, i think), the ethernet does not get re-enabled after moving back from Battery to AC power. By deafult, we wouldn't disable the eth device. Regarding the behavior, I'll look into this later. Meanwhile, if you root-cause it, please do comment on this bug. Perhaps there's a cleanup step that needs to happen as well here? I need to verify first. And my current laptop has no eth devices. But I'll be able to figure out. Just need some time. My gut feel is that the manpage is outdated. Ok, looking into it a bit further, it's even more complicated by a couple other options. DISABLE_ETHERNET_ON_BATTERY=1 is supposed to re-enable the ethernet when the AC is plugged back in. But if ENABLE_LAPTOP_MODE_ON_AC=0, then i think the /usr/share/laptop-mode-tools/modules/ethernet never gets run at all after the power has been plugged back in, so it doesn't know to bring the NIC back up. Also, while the test for active carrier appears to actually work (as seen by set -x within .../modules/ethernet, it avoids bringing down eth0 if there is no NO-CARRIER present from ip link show eth0), something else (also in laptop-mode-tools, because it doesn't happen when the package is purged) is bringing down the NIC. So this is still pretty confusing to me, and it looks like there is at least one bug besides the documentation. --dkg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787563: SheevaPlug and other devices not recognized
Package: libdebian-installer Version: 0.99 Severity: serious SheevaPlug and some other devices have been converted to Device Tree but libdebian-installer doesn't know about their new DT names. As a result, we end up with: $ archdetect armel/generic and then base-installer fails to install the kernel: https://lists.debian.org/debian-arm/2015/05/msg00072.html I have a fix. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787565: RM: haskell-hgettext [mips mipsel] -- ROM; Needs template haskell
Package: ftp.debian.org Severity: normal Control: tag 745899 - moreinfo -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, this package requires Template Haskell support to run, this not available on mips*. Please remove its binaries, and its reverse dependencies (in particular bustle) from mips*. Removing bustle there will unblock the removal request #745899. Greetings, Joachim -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlVuEDkACgkQ9ijrk0dDIGxq2gCg1aJN2ovIXs5ZfSIU3EOxek2M bE8AnR4N0K0pDnrgcjMoD2E0G7hvAn1m =m0sd -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#782475: libcap2 needs an udeb package for d-i, since udev depends on it
Am 02.06.2015 um 22:17 schrieb Matthias Klumpp: 2015-06-02 21:03 GMT+02:00 Michael Biebl bi...@debian.org: Is this maybe just CP from an existing package like udev? Yes, you told me that on IRC a while ago, and I told you I would Heh, obviously your memory is better then mine :-) Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#766294: virt-manager: Cannot Exit Console Fullscreen Mode
I believe I'm seeing this bug in virt-manager 1.0.1 on Jessie. My VMs are running on localhost, and I see this issue on two separate Debian 8 systems - one is running a Jessie VM under the free Nouveau video driver, and one running Windows 7 under the proprietary Catalyst driver. Hovering the mouse where the pop-up *should* appear produces the occasional flickering view of the menu, but fleetingly and inconsistently; additionally, the mouse cursor splits - the VM's mouse cursor stops moving and the host's cursor appears when (I'm guessing) the pop-up should appear. Hovering in the right place displays a tool tip Leave Fullscreen, and clicking while that is visible does the right thing; so it looks like a drawing bug, more than anything else. The problem appears to relate to using the VNC display server for accessing the VM - switching to using the Spice display server fixes the issue. Regards, John Pearson -- *email:*j...@huiac.com The greatest shortcoming of the human race is our inability to understand the exponential function. - Albert Allen Bartlett *web:* http://www.huiac.com/ *mob:* +61 407 391 169 *phone:*+61 8 7127 6275
Bug#786819: netsurf , pixbufs, implicit declarations, mismatched externs, arm64 and Debian
Recently a rc bug was filed on netsurf in the Debian bug tracking system due to a build failure. netsurf FTBFS if built against libgdk-píxbuf2.0-dev 2.31.4-1 which is currently in unstable: | COMPILE: gtk/window.c | gtk/window.c:55:14: error: unknown type name 'GdkPixdata' | extern const GdkPixdata menu_cursor_pixdata; | ^ | gtk/window.c: In function 'nsgtk_create_menu_cursor': | gtk/window.c:1057:2: warning: implicit declaration of function 'gdk_pixbuf_from_pixdata' [-Wimplicit-function-declaration] | pixbuf = gdk_pixbuf_from_pixdata(menu_cursor_pixdata, FALSE, NULL); | ^ | gtk/window.c:1057:2: warning: nested extern declaration of 'gdk_pixbuf_from_pixdata' [-Wnested-externs] | gtk/window.c:1057:9: warning: assignment makes pointer from integer without a cast | pixbuf = gdk_pixbuf_from_pixdata(menu_cursor_pixdata, FALSE, NULL); | ^ Sebastian Ramacher who filed the original patch proposed a debdiff to fix this issue. This issue is almost fixed upstream in [1]. In addition to this change, the generated file also needs another include. A debdiff fixing this bug is attached. Cheers [1]http://source.netsurf-browser.org/netsurf.git/commit/?id=a29e9589f6bd54e258805bef367528a18d7b0c2b The debdiff he proposed can be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;bug=786819;filename=netsurf.debdiff;att=1 Following a lack of maintainer response I uploaded Sebastian's debdiff as a NMU. The debdiff for my first NMU can be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=786819;msg=22;filename=netsurf.debdiff , the only difference to Sebastian's proposed debdiff was indicating myself as the uploader (and Sebastian as the change author) Unfortunately the package then failed to build on arm64 with the following error. build-Linux-gtk/gtk_window.o: In function `nsgtk_create_menu_cursor': /«BUILDDIR»/netsurf-3.2+dfsg/netsurf/gtk/window.c:1057:(.text+0x2cc): relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol `menu_cursor_pixdata' defined in .rodata section in build-Linux-gtk/build-Linux-gtk_menu_cursor.o collect2: error: ld returned 1 exit status make[3]: *** [nsgtk] Error 1 I first tried -ffunction-sections which often fixes relocation errors but made no differnce in this case so I removed it again. On closer inspection I noticed an implicit declaration warning on gdk_pixbuf_new_from_inline, further investigation showed that this was deprecated. Removing -DGDK_PIXBUF_DISABLE_DEPRECATED from Makefile.target fixed the implicit declaration (which is a good thing, implicit declarations are bad). Unfortunately it did not fix the link failure on arm64. Even closer inspection revealed that the importextern declaration of menu_cursor_pixdata in netsurf/gtk/window.c differed from the declaration in the generated file netsurf/build-Linux-gtk/menu_cursor.c . I changed the two to match and got a successful build on arm64. While I was at it I also ran into incomplete cleanup in the clean target causing an unrepresentable changes to source error and fixed that. I then did a build and basic functionality test (run netsurf-gtk and load slashdot) on amd64 and uploaded as a second NMU. I have attatched two debdiffs to this mail, one covering the second NMU only and one covering both NMUs diff -Nru netsurf-3.2+dfsg/debian/changelog netsurf-3.2+dfsg/debian/changelog --- netsurf-3.2+dfsg/debian/changelog 2014-08-29 22:59:03.0 +0100 +++ netsurf-3.2+dfsg/debian/changelog 2015-06-02 22:30:03.0 +0100 @@ -1,3 +1,24 @@ +netsurf (3.2+dfsg-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * Remove -DGDK_PIXBUF_DISABLE_DEPRECATED to avoid an implicit function +declaration issue that was thought to be the cause of an arm64 build failure. + * Make declarations match between generated file and importing file for +menu_cursor_pixdata to fix arm64 build failure. + * Remove nsgenbind/build* in clean target to avoid unrepresentable changes +to source error. + + -- Peter Michael Green plugw...@debian.org Tue, 02 Jun 2015 10:16:59 + + +netsurf (3.2+dfsg-2.1) unstable; urgency=medium + + * Non-maintainer upload. + [Sebastian Ramacher] + * debian/patches/change-how-gdk-image.patch: Fix build against +libgdk-pixbuf2.0-dev 2.31.4. (Closes: #786819) + + -- Peter Michael Green plugw...@debian.org Tue, 02 Jun 2015 01:00:37 + + netsurf (3.2+dfsg-2) unstable; urgency=medium * Do not build with javascript support on s390x diff -Nru netsurf-3.2+dfsg/debian/patches/change-how-gdk-image.patch netsurf-3.2+dfsg/debian/patches/change-how-gdk-image.patch --- netsurf-3.2+dfsg/debian/patches/change-how-gdk-image.patch 1970-01-01 01:00:00.0 +0100 +++ netsurf-3.2+dfsg/debian/patches/change-how-gdk-image.patch 2015-06-02 22:29:46.0 +0100 @@ -0,0 +1,78 @@ +Description: Change how GDK image resources are compiled in + The compiled in image resources
Bug#787576: gnucash upgrade broke ledger package compatibility!
On Tue, 2 Jun 2015 21:40:35 Anonymous wrote: The new version of gnucash breaks interoperability with ledger. This is catastrophic. Gnucash has always had a great user interface, but an atrocious backend machine interface with very poor import/export scripting and automation capability. Ledger has a rough user interface, but works brilliantly for scripting and automation. In short, Gnucash and Ledger *need each other*. Unfortunately I don't even understand the problem... How Gnucash needs Ledger and what for? Are you talking about http://ledger-cli.org ledger? I've never used this tool and I do not know what kind of interoperability was supported (if any). Please report upstream -- this is the only way to get it fixed. -- Best wishes, Dmitry Smirnov. P.S. Overly emotional language in bug report do not compensate for lack of problem description... signature.asc Description: This is a digitally signed message part.
Bug#787576: Acknowledgement (gnucash upgrade broke ledger package compatibility!)
This message is being sent to you automatically in response to an email that you sent to nob...@remailer.paranoici.org. Most likely, you tried to reply to an email that has been sent through this service. If you did not send an email to nob...@remailer.paranoici.org, please ignore this message. The Anonymous Remailer is a free service that allows individuals including crime victims, domestic violence victims, persons in recovery, and others, such as those living under oppressive regimes, to communicate confidentially in a manner that ensures their privacy under even the most adverse conditions. To block individuals using this remailer from sending email to your address in the future, please send a message to mixmas...@remailer.paranoici.org containing the line destination-block 787...@bugs.debian.org anywhere in the body text of the email. You can simply forward this entire email to mixmas...@remailer.paranoici.org using your email program for your current email address to be permanently blocked from users of the Anonymous Remailer. For more information about the Anonymous Remailer Administrator's strict anti-abuse policy, please send a blank email to ab...@remailer.paranoici.org Sincerely, -- The Anonymous Remailer Administrator -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787576: Your email to mixmas...@remailer.paranoici.org
This message is being sent to you automatically in response to an email that you sent to mixmas...@remailer.paranoici.org. If you did not send such an email, please ignore this message. This remailer is a free service that allows individuals including crime victims, domestic violence victims, persons in recovery, and others, such as those living under oppressive regimes, to communicate confidentially in a manner that ensures their privacy under even the most adverse conditions. To obtain information on how you can use this service, please send an email with subject remailer-help to mixmas...@remailer.paranoici.org. Should you have received an unwelcome message through this service or to report problems with this service, please contact the Administrator at ab...@remailer.paranoici.org. Thank you for your interest in secure and private communications, -- The Anonymous Remailer Administrator -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787561: modules virtio_net and virtio_pci are allowed to be removed but they should not be
Control: severity -1 minor Control: tag -1 upstream On Tue, 2015-06-02 at 21:04 +0200, Santiago Vila wrote: [...] I'm not using the console but ssh. So I'm using the net. However: rmmod virtio_net works and makes the ssh connection to be lost. I think this should not happen. This is correct behaviour. TCP connections are not bound to specific network interfaces (in general) and do not prevent network interfaces being removed. Then it comes the really fun part: rmmod virtio_pci also works, but the result is I/O error in the root partition, which becomes read-only and the system needs to be rebooted. See last attach screenshot.png. I think this should not happen either. This is a bug. But it's not really important as no-one would do that on a production system. I'm not going to take any action on this; you may wish to report the latter bug upstream. Ben. -- Ben Hutchings Editing code like this is akin to sticking plasters on the bleeding stump of a severed limb. - me, 29 June 1999 signature.asc Description: This is a digitally signed message part
Bug#782574: installation-reports: d-i does not boot on beaglebone black
On 2015-05-27, François-Régis wrote:
Le 27/05/2015 20:36, Vagrant Cascadian a écrit :
I don't see anything mentioned in the errata yet:
https://www.debian.org/releases/stable/debian-installer/#errata
Not sure what the process is to update that, but I'd be happy to work on
some text for it.
I was not very pushy to make this mentioned in the errata giving the
fact that the most popular way to install debian on BBB is to use
readymade disk images and not d-i. That said I'd like to help on
documenting.
Here's a stab at some text and instructions:
Booting BeagleBone Black
The u-boot version shipped with Debian Jessie does not work out of the
box with debian-installer on the BeagleBone Black. The following
workaround should enable booting by setting some environment variables
at the u-boot prompt, using the appropriate SD-card-images from Jessie
debian-installer:
Set the fdt file:
U-Boot# run findfdt
U-Boot# printenv fdtfile
fdtfile=am335x-boneblack.dtb
If it doesn't set the fdt file correctly, set it manually:
U-Boot# setenv fdtfile am335x-boneblack.dtb
Set a few compatibility variables:
U-Boot# setenv devnum 0
U-Boot# setenv bootpart 1
U-Boot# setenv devtype mmc
U-Boot# setenv boot_targets mmc0
Ensure that the console variable is set appropriately:
U-Boot# printenv console
console=ttyO0,115200n8
Load the boot script manually:
U-Boot# load ${devtype} ${devnum}:${bootpart} ${loadaddr} ${script}
U-Boot# source ${loadaddr}
If everything went well, it should load the kernel, initrd, device-tree,
and boot into debian-installer...
If there's an old u-boot version on the eMMC and these instructions
don't work, it may require pressing the boot button (near the micro-SD
slot) to load u-boot off of the micro-SD card.
live well,
vagrant
signature.asc
Description: PGP signature
Bug#785333: broken contextmenu due to jquery
The old jquery linked to in RoundCube also breaks plugins like contextmenu. The better fix for Debian's RoundCube is not to update the jquery package to its new upstream, but to include with RoundCube the appropriate version of jquery supplied from its own upstream. jquery, like tinymce, is simply not appropriate as a shared resource. Web applications of various ages depend on mutually incompatible versions. Far too much thought is being put into a very simple problem. Namely that too many of the included files from the upstream RoundCube distribution are being removed from the distribution in favour of inappropriately trying to link against a common system version. There is no advantage to the current approach and it is keeping Debian's RoundCube packages broken for far too long. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787577: produces broken documentation: Invalid namespace '' at line 3, column 1
Package: gtk-doc-tools Version: 1.23-1 Severity: grave Since upgrading to 1.23, every package which has been rebuilt with that version fails to show up in devhelp: (devhelp:31032): Devhelp-WARNING **: Failed to read '/usr/share/gtk-doc/html/libudev/libudev.devhelp2': Invalid namespace '' at line 3, column 1 (devhelp:31032): Devhelp-WARNING **: Failed to read '/usr/share/gtk-doc/html/gtkspell3/gtkspell3.devhelp2': Invalid namespace '' at line 3, column 1 (devhelp:31032): Devhelp-WARNING **: Failed to read '/usr/share/gtk-doc/html/gudev/gudev.devhelp2': Invalid namespace '' at line 3, column 1 (devhelp:31032): Devhelp-WARNING **: Failed to read '/usr/share/gtk-doc/html/gnome-desktop3/gnome-desktop3.devhelp2': Invalid namespace '' at line 3, column 1 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-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) Versions of packages gtk-doc-tools depends on: ii docbook-dsssl 1.79-7 ii docbook-to-man 1:2.0.0-32 ii docbook-xml 4.5-7.2 ii docbook-xsl 1.78.1+dfsg-1 ii gnome-common3.14.0-1 ii highlight 3.18-3 ii jade1.2.1-47.3 ii perl5.20.2-6 ii python 2.7.9-1 ii xsltproc1.1.28-2+b2 Versions of packages gtk-doc-tools recommends: ii pkg-config 0.28-1 Versions of packages gtk-doc-tools suggests: pn dblatex 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#754144: elinks: Saving base64 data URIs locally base64-encodes the content instead of base64-decoding
Trivial patch attached.
From: Yuriy M. Kaminskiy yumkam+deb...@gmail.com
Subject: [oneline] fix data:..;base64 protocol decoding
Index: elinks-0.12pre6/src/protocol/data.c
===
--- elinks-0.12pre6.orig/src/protocol/data.c
+++ elinks-0.12pre6/src/protocol/data.c
@@ -141,7 +141,7 @@ data_protocol_handler(struct connection
}
if (base64) {
- unsigned char *decoded = base64_encode(data);
+ unsigned char *decoded = base64_decode(data);
if (!decoded) {
abort_connection(conn, connection_state(S_OUT_OF_MEM));
Bug#765759: bash: exists in jessie also
Package: bash Version: 4.3-11+b1 Followup-For: Bug #765759 Dear Maintainer, The bug still exists in the latest stable (now Jessie). -- 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/2 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 bash depends on: ii base-files 8 ii dash 0.5.7-4+b1 ii debianutils 4.4+b1 ii libc62.19-18 ii libncurses5 5.9+20140913-1+b1 ii libtinfo55.9+20140913-1+b1 Versions of packages bash recommends: ii bash-completion 1:2.1-4 Versions of packages bash suggests: pn bash-doc 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#765759: Your email to mixmas...@remailer.paranoici.org
This message is being sent to you automatically in response to an email that you sent to mixmas...@remailer.paranoici.org. If you did not send such an email, please ignore this message. This remailer is a free service that allows individuals including crime victims, domestic violence victims, persons in recovery, and others, such as those living under oppressive regimes, to communicate confidentially in a manner that ensures their privacy under even the most adverse conditions. To obtain information on how you can use this service, please send an email with subject remailer-help to mixmas...@remailer.paranoici.org. Should you have received an unwelcome message through this service or to report problems with this service, please contact the Administrator at ab...@remailer.paranoici.org. Thank you for your interest in secure and private communications, -- The Anonymous Remailer Administrator -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787570: debsources: DB: change sha256 column data type from string to bytea or bit string
Package: qa.debian.org Severity: normal User: qa.debian@packages.debian.org Usertags: debsources Currently, the sha256 column of the checksum table in Debsources' Postgres DB has type character varying(64): sha256 | character varying(64) | not null Such a data type is wasteful in terms of disk space. And it shows: debsources= select count(*) from checksums; count -- 41151812 public | checksums| table| debsources | 4890 MB| We should switch to a more economic (and efficient) data type for storing sha256 checksums. Good options seem to be either bytea [1] or fixed-size bit strings [2]. Suggestions welcome! A good, concrete way to help with this bug would be providing sample SQL snippets to create temporary tables with the new data types, and convert / inject into them the content of the current checksum table. That would allow to easily benchmark disk usage and query/index efficiency. Cheers. [1]: http://www.postgresql.org/docs/9.4/static/datatype-binary.html#AEN5497 [2]: http://www.postgresql.org/docs/9.4/static/datatype-bit.html -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- 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
On Mon, 18 May 2015 16:17:34 +0200 Michal Suchanek michal.sucha...@ruk.cuni.cz wrote: 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). It also works with the (IMHO better - 3x hardware PWM for example) arduino-tiny core from https://code.google.com/p/arduino-tiny/ If you try arduino-mk 1.5-2 it adds IDE 1.6 support (you'd have to install the 1.6 IDE locally and set ARDUINO_DIR) whilst remaining backwards-compatible with 1.0.5 from Debian, and a bunch of new features of course. Here's the Makefiles I use to flash ATtiny chips: # arduino-tiny: ISP_PROG = usbasp BOARD_TAG = attiny2313at1 ALTERNATE_CORE = tiny include /usr/share/arduino/Arduino.mk # damellis (1.0): ISP_PROG = usbasp BOARD_TAG = attiny85 ALTERNATE_CORE = attiny include /usr/share/arduino/Arduino.mk # damellis (1.6): ISP_PROG = usbasp BOARD_TAG = attiny BOARD_SUB = attiny85 ALTERNATE_CORE = attiny F_CPU = 1600L ARDUINO_DIR = ($HOME)/arduino-1.6.4 include /usr/share/arduino/Arduino.mk 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. I don't really see the point in installing the core system-wide, but I'm sure it can be done by setting some of the variables documented at: https://github.com/sudar/Arduino-Makefile/blob/master/arduino-mk-vars.md Automated support for micronucleus is not available afaict. I don't know what a micronucleus is but I suspect it would work by ISP'ing as if it were a bare chip? 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. The example sketch actually mentions that you may need to change the led pin. Unfortunately, not all the files in the attiny core project have clear licensing terms so including this core in Debian would be problematic. No idea. Both of the cores seem a bit dead, so I doubt this could happen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740757: ledger: wtf?
Package: ledger Version: 3.1+dfsg1-2 Followup-For: Bug #740757 Dear Maintainer, If gc support was lost upstream, then the fix is not to march ahead and introduce a serious problem. Why have a debian stable, with testing, and diligence, the whole nine yards if they're going to wildly upgrade packages to versions that break? Not sure about others, but for me this is catastrophic. I used ledger exclusively to harvest data from gnucash. Gnucash is the best user interface, while gnucash is atrocious for scripting and automation (which ledger was good at). Gnucash and ledger need each other. I am disgusted. It's questionable that the support removal was deliberate, since there appears to be an effort to make ledger compatible with gnucash 3.0. While parsing file gnucash264.gc, line 38930: Error: Unexpected whitespace at beginning of line While parsing file gnucash264.gc, line 38942: Error: Directive '/gnc:GncTaxTable' requires an argument While parsing file gnucash264.gc, line 38944: Error: Unexpected whitespace at beginning of line While parsing file gnucash264.gc, line 38955: Error: Directive '/gnc:GncTaxTable' requires an argument Granted, it was probably not ledger maintainers who inappropriately marched forward with reckless disregard, but gnucash maintainers. However, what we need from the Ledger team is one member to infiltrate the gnucash project, and introduce an automated regression test that tests and enforces ledger compatibility. -- 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/2 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 ledger depends on: ii libboost-filesystem1.55.0 1.55.0+dfsg-3 ii libboost-iostreams1.55.0 1.55.0+dfsg-3 ii libboost-regex1.55.0 1.55.0+dfsg-3 ii libboost-system1.55.0 1.55.0+dfsg-3 ii libc6 2.19-18 ii libgcc11:4.9.2-10 ii libgmp10 2:6.0.0+dfsg-6 ii libicu52 52.1-8 ii libmpfr4 3.1.2-2 ii libstdc++6 4.9.2-10 ledger recommends no packages. ledger suggests no packages. -- Configuration Files: /etc/emacs/site-start.d/50ledger.el 0450a71ec52941dd8cdcef94e8ed2ee2 [Errno 2] No such file or directory: u'/etc/emacs/site-start.d/50ledger.el 0450a71ec52941dd8cdcef94e8ed2ee2' -- 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#786487: Fwd: jessie backport for Wordpress
Please remove CC to bugreport where I suggested having a backport as approbiate again. I just wanted to put information that Rodrigo did a backport in there as well. Hello Craig and Rodrigo, Craig, Rodrigo made a jessie-backport of Wordpress 4.2.2. And gave another good reason to have it available for Jessie users. I would really like to see it in jessie-backports after wordpress 4.2.2 entered testing. I am willing to test it on my server where I now use the unstable package. Rodrigo, how did you solve the versioned dependency php-getid3 (= 1.9.9+dfsg)? According to Craig its important to use the newer version cause it has a security fix. Thanks, Martin -- Weitergeleitete Nachricht -- Betreff: jessie backport for Wordpress Datum: Dienstag, 2. Juni 2015, 20:47:22 Von: Rodrigo Campos rodr...@sdfg.com.ar An: debian-backpo...@lists.debian.org Hi, I've uploaded to mentors a jessie backport of wordpress. It's from the version in sid (not in testing, waiting for some other package) so it should not be uploaded just yet. But the version in sid fixes some security issues, so I think it's pointless to upload an unfixed version. The wordpress support policy states that: The only current officially supported version is WordPress 4.2.2. Previous major releases from 3.7 onwards may or may not get security updates as serious exploits are discovered. See here: https://codex.wordpress.org/Supported_Versions So, it's inevitably that the release shipped with jessie will stop to be maintained by wordpress and backporting the patches will be needed, making it a difficult task. This may cause some delay to fix some issues, and wordpress has had SERIOUS security issues in the past weeks. See for example[1]. As I need the wordpress package and some updates have taken some time to come to debian, and the wordpress support policy is limited to the last release, IMHO, it makes sense to backport it to jessie. Also, I'd really like to have the current wordpress version (or pretty close), so a backport seems appropriate for me. I'm not a DD nor DM and it's my first time using mentors, so I apologize in advance if something is wrong. The link to mentors is: https://mentors.debian.net/package/wordpress I've used cowbuilder to do it and run it with the -v4.1+dfsg-1 dpkg-buildpackage option (the version in stable) as it says here[2]. Please let me know if I should fix something or if the package is accepted. Thanks a lot, Rodrigo [1]: https://wordpress.org/news/2015/04/wordpress-4-2-1/ [2]: http://backports.debian.org/Contribute/#index6h3 -- To UNSUBSCRIBE, email to debian-backports-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150602194722.ga15...@sdfg.com.ar - -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
