Bug#1055493: [Emc-developers] Bug#1055493: linuxcnc-uspace, linuxcnc-uspace-dev: both packages ship the manpages
On Mon, 18 Dec 2023 at 18:31, Sudip Mukherjee wrote: > > However I haven't so far worked out why the man3 sections are being > > included in the main package installer. > > (the commands in man3 are only of interest to developers) > > From > https://sources.debian.org/src/linuxcnc/2.9.1-2/debian/linuxcnc-uspace.manpages/#L2 OK, so where does _that_ file come from? I don't see it in our source repository: https://github.com/LinuxCNC/linuxcnc-gbp/tree/debian/unstable/debian -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912
Bug#1055493: [Emc-developers] Bug#1055493: linuxcnc-uspace, linuxcnc-uspace-dev: both packages ship the manpages
On Tue, 7 Nov 2023 at 10:45, Andreas Beckmann wrote: > > Package: linuxcnc-uspace,linuxcnc-uspace-dev > Version: 2.9.1-2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package failed to install > because it tries to overwrite other packages files: I assume that this could be fixed by deleting the last line here: https://github.com/LinuxCNC/linuxcnc/blob/2.9/debian/linuxcnc-uspace-dev.install However I haven't so far worked out why the man3 sections are being included in the main package installer. (the commands in man3 are only of interest to developers) -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912
Bug#1049421: Still testing, but possibly fixed
I have been researching and noticed the source for dns_linode.py appears to default to API version 3 if not specified in the credentials file. I updated our credentials file to add dns_linode_version = 4 I tried that and found that apparently the version 3 API security key didn't work with the version 4 API. So I created a new key in the V4 API, updated the credentials and it looks like it is going to work. With several domains I have to wait several minutes for each domain, but the first one has updated successfully. I apologize if I have caused unnecessary work. Thanks for maintaining this very useful package. -- Andy Dorman Ironic Design, Inc.
Bug#1028346: php-horde-imap-client: fails on login: Return value of Horde_Imap_Client_Tokenize::current() must be an instance of mixed,
Package: php-horde-imap-client
Version: 2.30.6-1
Severity: grave
Tags: upstream
Justification: renders package unusable
Dear Maintainer,
With php7.4-fpm, after updating to 2.30.6-1 users are unable to login.
Login attempts generate the following error:
HORDE: [imp] TypeError: Return value of Horde_Imap_Client_Tokenize::current()
must be an instance of mixed, string returned in
/usr/share/php/Horde/Imap/Client/Tokenize.php:225
HORDE: Stack trace:
HORDE: #0 /usr/share/php/Horde/Imap/Client/Interaction/Server.php(102):
Horde_Imap_Client_Tokenize->current()
HORDE: #1 /usr/share/php/Horde/Imap/Client/Interaction/Server.php(84):
Horde_Imap_Client_Interaction_Server->__construct()
HORDE: #2 /usr/share/php/Horde/Imap/Client/Socket.php(4542):
Horde_Imap_Client_Interaction_Server::create()
HORDE: #3 /usr/share/php/Horde/Imap/Client/Socket.php(621):
Horde_Imap_Client_Socket->_getLine()
HORDE: #4 /usr/share/php/Horde/Imap/Client/Socket.php(375):
Horde_Imap_Client_Socket->_connect()
HORDE: #5 /usr/share/php/Horde/Imap/Client/Base.php(839):
Horde_Imap_Client_Socket->_login()
HORDE: #6 /usr/share/horde/imp/lib/Imap.php(718):
Horde_Imap_Client_Base->login()
HORDE: #7 /usr/share/horde/imp/lib/Auth.php(86): IMP_Imap->__call()
HORDE: #8 /usr/share/horde/imp/lib/Application.php(370):
IMP_Auth::authenticate()
HORDE: #9 /usr/share/php/Horde/Registry.php(1197):
IMP_Application->authAuthenticate()
HORDE: #10 /usr/share/php/Horde/Core/Auth/Application.php(170):
Horde_Registry->callAppMethod()
HORDE: #11 /usr/share/php/Horde/Auth/Base.php(161):
Horde_Core_Auth_Application->_authenticate()
HORDE: #12 /usr/share/php/Horde/Core/Auth/Application.php(141):
Horde_Auth_Base->authenticate()
HORDE: #13 /usr/share/php/Horde/Core/Auth/Application.php(138):
Horde_Core_Auth_Application->authenticate()
HORDE: #14 /usr/share/horde/login.php(155):
Horde_Core_Auth_Application->authenticate()
HORDE: #15 {main} [pid 1480064 on line 74 of
"/usr/share/php/Horde/ErrorHandler.php"]
I reverted php-horde-imap-client back to 2.30.1-4 and the problem went away.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages php-horde-imap-client depends on:
ii libapache2-mod-php8.1 [php-json] 8.1.12-1+b1
hi php-common2:76
ii php-horde-exception 2.0.8-9
ii php-horde-mail2.6.6-4
ii php-horde-mime2.11.2-1
ii php-horde-secret 2.0.6-9
ii php-horde-socket-client 2.1.4-1
ii php-horde-stream 1.6.3-10
ii php-horde-stream-filter 2.0.5-1
ii php-horde-translation 2.2.2-7
ii php-horde-util2.5.12-1
ii php-json 2:8.1+92+nmu1
ii php7.4-json [php-json]7.4.33-1+deb11u1
ii php8.1-cli [php-json] 8.1.12-1+b1
ii php8.1-fpm [php-json] 8.1.12-1+b1
ii php8.2-cli [php-json] 8.2.1-1
Versions of packages php-horde-imap-client recommends:
ii php-horde-cache 2.5.5-10
ii php-horde-compress-fast 1.1.1-10
ii php-horde-crypt-blowfish1.1.4-1
hi php-horde-db2.4.1-1
ii php-horde-hashtable 1.2.6-11
pn php-horde-mongo
ii php-horde-pack 1.0.7-7
pn php-horde-stringprep
ii php-horde-support 2.2.2-1
ii php-horde-test 2.6.4+debian0-7
pn php-intl
ii php-mbstring2:8.1+92+nmu1
ii php7.4-mbstring [php-mbstring] 7.4.33-1+deb11u1
ii php8.1-mbstring [php-mbstring] 8.1.12-1+b1
php-horde-imap-client suggests no packages.
-- no debconf information
Bug#1019865: Debian Bug report logs - #1019865
Package: evolution Version: 3.45.3-2 / 3.46.0-2 I have since apt upgraded to version 3.46.0-2. I confirm the workaround for this problem, with the suggested disabling of requesting read receipts: edit> preferences> composer preferences> UNTICK always request read receipt The compose window then starts as normal. It also now starts as normal from the command line.
Bug#1019865: Debian Bug report logs - #1019865
Package: Evolution *Hangs and goes to 100% CPU usage on compose* I confirm this bug. I too am running bookworm, with Evolution 3.45.3-2, and have exactly the same issue when trying to compose with new>mail message. This started happening a couple of days ago (15 Sept 2022). I apt update daily. (I've had to use a web browser to send this email.) I can confirm this also happens from the command line with evolution mailto: - CPU goes to 100% and compose does not start. There are no command line errors - I have to terminate with CTRL-C. Regards, Andy, Birmingham, UK
Bug#1015886: firewalld conflicts kodi-data on file kodi-eventserver.xml
Package: firewalld Version: 1.1.1-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: polardropbear+deb...@gmail.com Dear firewalld maintainer firewalld conflicts with kodi-data package and prevents the installation of firewalld. The system has the following packages of kodi installed. ii kodi 5:19.4-dmo5 amd64Open Source Home Theatre (executable binaries) ii kodi-data 5:19.4-dmo5 all Open Source Home Theatre (arch-independent data package) ii kodi-inputstream-adaptive 1:19.0.7-dmo1 amd64adaptive inputstream addon for Kodi. ii kodi-inputstream-rtmp 1:19.0.1-dmo1 amd64Kodi input stream addon for RTMP. ii kodi-pvr-hts 6:19.0.6-dmo1 amd64Kodi PVR Addon TvHeadend Hts ii kodi-pvr-iptvsimple 6:19.1.1-dmo1 amd64IPTV Simple Client Kodi PVR Addon The system was purged of previous firewalld install. Upon attempting to install firewalld with: andy@laptop:~$ dpkg -l | grep firewall andy@laptop:~$ sudo apt install firewalld firewall-applet firewall-config Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: ipset libipset13 python3-cap-ng python3-firewall python3-jsonschema python3-nftables python3-pyrsistent Suggested packages: python-jsonschema-doc The following NEW packages will be installed: firewall-applet firewall-config firewalld ipset libipset13 python3-cap-ng python3-firewall python3-jsonschema python3-nftables python3-pyrsistent 0 upgraded, 10 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/913 kB of archives. After this operation, 6,462 kB of additional disk space will be used. Do you want to continue? [Y/n] y Selecting previously unselected package python3-pyrsistent:amd64. (Reading database ... 562766 files and directories currently installed.) Preparing to unpack .../0-python3-pyrsistent_0.18.1-1_amd64.deb ... Unpacking python3-pyrsistent:amd64 (0.18.1-1) ... Selecting previously unselected package python3-jsonschema. Preparing to unpack .../1-python3-jsonschema_3.2.0-5_all.deb ... Unpacking python3-jsonschema (3.2.0-5) ... Selecting previously unselected package python3-nftables. Preparing to unpack .../2-python3-nftables_1.0.4-2_amd64.deb ... Unpacking python3-nftables (1.0.4-2) ... Selecting previously unselected package python3-firewall. Preparing to unpack .../3-python3-firewall_1.2.0-1_all.deb ... Unpacking python3-firewall (1.2.0-1) ... Selecting previously unselected package firewalld. Preparing to unpack .../4-firewalld_1.2.0-1_all.deb ... Unpacking firewalld (1.2.0-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-r6zmeY/4-firewalld_1.2.0-1_all.deb (--unpack): trying to overwrite '/usr/lib/firewalld/services/kodi-eventserver.xml', which is also in package kodi-data 5:19.4-dmo5 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Selecting previously unselected package firewall-config. Preparing to unpack .../5-firewall-config_1.2.0-1_all.deb ... Unpacking firewall-config (1.2.0-1) ... Selecting previously unselected package firewall-applet. Preparing to unpack .../6-firewall-applet_1.2.0-1_all.deb ... Unpacking firewall-applet (1.2.0-1) ... Selecting previously unselected package libipset13:amd64. Preparing to unpack .../7-libipset13_7.15-1_amd64.deb ... Unpacking libipset13:amd64 (7.15-1) ... Selecting previously unselected package ipset. Preparing to unpack .../8-ipset_7.15-1_amd64.deb ... Unpacking ipset (7.15-1) ... Selecting previously unselected package python3-cap-ng. Preparing to unpack .../9-python3-cap-ng_0.8.3-1_amd64.deb ... Unpacking python3-cap-ng (0.8.3-1) ... Errors were encountered while processing: /tmp/apt-dpkg-install-r6zmeY/4-firewalld_1.2.0-1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Best regards Andy -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firewalld depends on: ii dbus 1.14.0-1 ii gir1.2-glib-2.0 1.72.0-1+b1 ii gir1.2-nm-1.0 1.38.2-1 ii policykit-1 0.105-33 ii python3 3.10.4-1+b1 ii python3-dbus 1.2.18-3+b1 pn python3-firewall ii python3-gi3.42.1-1 pn python3-nftables Versions of packages
Bug#1012789: [Emc-developers] Bug#1012789: linuxcnc-uspace: Linux CNC will not start
On Tue, 14 Jun 2022 at 14:49, Vector Hasting wrote: > _tkinter.TclError: couldn't load file > "/usr/lib/tcltk/aarch64-linux-gnu/Img1.4.13/libtifftcl4.1.0.so": > /usr/lib/tcltk/aarch64-linux-gnu/Img1.4.13/libtifftcl4.1.0.so: undefined > symbol: _TIFFsetString, version LIBTIFF_4.0 This looks to be a dependency (hard coded?) on the version of libtiff that shipped with Buster (4.1). But it also seems to be in a package that LinuxCNC depends on, but doesn't control? https://sourceforge.net/projects/tkimg/files/tkimg/1.4/tkimg%201.4.13/ (From the file path being searched) For me, the trail dries up there. I guess this is due to a Tcl/Tk dependency? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912
Bug#1001714: update 1
Hi Detlev, On Thu, Dec 16, 2021 at 09:05:07AM +0100, detlev schmidtke wrote: > I read in the Debian Wiki > (https://wiki.debian.org/UEFI#RAID_for_the_EFI_System_Partition): > > "But for software RAID systems there is currently no support for > putting the ESP on two separate disks in RAID." > > I interpret that as "it cannot work", so, the Debian Installer should > refuse to install EFI on a Software RAID with an appropriate message, > instead of running into this error. It's a bit more complicated than that. By default, md uses version 1.2 superblock which lives near the start of the device. Software with no concept of md RAID will read a member device and see an MD superblock at the start instead of the filesystem format they expect. So, this will not work and I would tend to agree that the installer should not allow a device with such a superblock to be used as an ESP. Metadata versions 0.9 and 1.0 can instead be used; these have the data near the end of the device. As a consequence, the beginning of RAID-1 member devices are indistinguishable from the below filesystem being directly on the device. This trick was used to get grub to boot RAID-1 before it had support for md RAID: grub couldn't tell that it wasn't just reading a normal filesystem. An MD RAID-1 array with superblock version 0.9 or 1.0 will very likely work as an ESP and many people do this. The installer should probably not prohibit it. This strategy can still fail. It relies upon nothing except the OS itself writing to that member device. I have not seen it but some people say that there are firmwares and bootloaders that will write to the ESP. Since they would not be aware of md, they would change one member device and not another. When you booted with such a setup MD would complain and not assemble the array. You'd have to choose which member device "won" and have the other overwrite it. Due to that, some people instead have multiple ESPs and come up with elaborate schemes to sync them in user space. That was the state of things when I last asked on debian-user in November 2020: https://lists.debian.org/debian-user/2020/11/msg00455.html Here's a script I use to sync ESPs: https://gist.github.com/grifferz/f262591f59e4f8c199a8b0619bc6a667 But again, I don't think it's a good idea to ban ESP on MD array as this is a working configuration for many. Cheers, Andy
Bug#1000661: Missing b-dep on libbase64-ocaml-dev
Hi, On Fri, Nov 26, 2021 at 11:45 PM Julien Puydt wrote: > I was checking whether a recent dune would break any package, and my > test failed because Base64 was an unbound module -- it's a missing > build-dep on libbase64-ocaml-dev, so it should be pretty > straightforward to fix. I've uploaded 1:4.2.4-1, which fixed the build problem regarding base64. Best regards, Andy
Bug#969261: fixed in cyrus-imapd 3.2.3-2
On Sun, 13 Sep 2020 16:18:27 + Debian FTP Masters wrote: Source: cyrus-imapd Source-Version: 3.2.3-2 Done: Xavier Guimard We believe that the bug you reported is fixed in the latest version of cyrus-imapd, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 969...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Xavier Guimard (supplier of updated cyrus-imapd package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) Just FYI in case it might help someone. I had the same problem but simeply upgrading from 3.2.3-1 to 3.2.3-2 did not allow cyrus-imapd to run. I had to manually recreate the /run/cyrus dir and sub-directories with correct cyrus.mail ownership and permissions before cyrus-imapd would start. ~# ls -al /run/cyrus drwxr-xr-x 5 cyrus mail 100 Jan 18 2020 . drwxr-xr-x 31 root root 1140 Sep 20 13:03 .. drwx-- 5 cyrus mail 100 Jun 5 12:49 lock drwx-- 2 cyrus mail 40 Sep 20 15:15 proc drwxr-x--- 2 cyrus mail 60 Sep 20 13:03 socket
Bug#930764: 3.0.8-6+deb10u3 on Buster
Hi, I am seeing this with 3.0.8-6+deb10u3. Will an update eventually trickle through? Thanks! Best wishes, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF
Bug#878983: cduce FTBFS with OCaml 4.05.0
Hi, On Fri, Jul 26, 2019 at 8:18 PM Stéphane Glondu wrote: > > The upstream cduce-next branch can be built with Debian's OCaml 4.05. > > I've asked upstream (Giuseppe Castagna) to make a new release and I > > was told that they will do it soon. > > Any news on that? > I haven't heard anything yet. I've just send another reminder to them and I will keep you posted. Best, Andy
Bug#926603: Debian fails to start after installation into Virtualbox
Package: systemd Severity: critical I'm running Windows 10 (Home edition - up to date) on the desktop, with Virtualbox (v6.0.4). I've used both the netinst CD & the testing DVD (downloaded today - 07/Apr/2019) to install Buster. After installation the system fails to start with many errors. The first is : systemd[1]: user.slice: Failed to set inovcation ID for unit: File exists [FAILED]: Failed to start User and Session Slice. other services then fail to start : [FAILED] Failed to start Slices. [FAILED] Failed to listen on udev Kernel Socket. [FAILED] Failed to start Remote File Systems. [FAILED] Failed to listen on Syslog Socket. and many more, followed by systemd[1]: Timed out waiting for device /dev/disk/by-uuid/2cb finally [FAILED] Failed to start Network. At which point there is no more, the system just halts. Starting with "quiet" removed from linux invocation in grub, I see systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid) systemd[1]: Detected virtualization oracle. systemd[1]: Detected architecture x86-64. Welcome to Debian GNU/Linux buser/sid! -- Andy Ruddock andy.rudd...@rainydayz.org (OpenPGP Key ID 0xB0324245) signature.asc Description: OpenPGP digital signature
Bug#878983:
For the record, I've briefly looked into this. The initially reported build error can be fixed by applying https://gitlab.math.univ-paris-diderot.fr/cduce/cduce/commit/020feca404095bcc08ebfa6deebaecbbc7399852. There are, however, some other build errors due to the reference to OCaml source files in Makefile. The upstream cduce-next branch can be built with Debian's OCaml 4.05. I've asked upstream (Giuseppe Castagna) to make a new release and I was told that they will do it soon. Best, Andy
Bug#872635: Info received (util-linux: FTBFS on armel: test failure)
control: severity -1 important Downgrading to important this is not RC I should have done this on previous email. /Andy
Bug#907427: openssl 1.1.1 breaks ssl tests
control: tag -1 unreproducible control: severity -1 important A clean chroot build does not reproduce this bug pulls in: libssl1.1 (= 1.1.1b-1) current build logs suggest this also builds successfully with: openssl_1.1.1a-1 Suspect that this was a transient bug /Andy (with help from jmw)
Bug#917711: grantlee5: FTBFS: dh_auto_test: cd obj-x86_64-linux-gnu && make -j2 test ARGS\+=-j2 returned exit code 2
Bug reproduces on build tests as of 2019-03-07 Possibly a regression in whatever library this calls in, as these tests do not appear to have been touched in some time. Upsteam has sime activity - an a yearly(ish) basis. This will need more experienced C++ / QT / Archaeologist skills than we have available at Cambs BSP... Sorry /Andy
Bug#872635: util-linux: FTBFS on armel: test failure
I have had a look at this as part of the Cambridge BSP 2019-03-09 I am able to reproduce this 'bug', on multiple architectures the following is copy/paste from buster on my AMD64 laptop :-p Simply running the test by hand Assuming you have a working / reliable resolver / untainted cache then the command succeeds: ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -d root IPv6 root a.root-servers.n Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -w -d root IPv6 root a.root-servers.net Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -a -d root IPv6 root Wed Aug 28 21:30 - 21:40 (00:10) a.root-servers.net wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 causing a failure can be done simply by unplugging the machine from the network, thus... ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -d root IPv6 root dns-server Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 ../util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -w -d root IPv6 root dns-server Wed Aug 28 21:30 - 21:40 (00:10) wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 /util-linux-2.33.1/tests/ts/utmp$ last -f wtmp-ipv6.LE -a -d root IPv6 root Wed Aug 28 21:30 - 21:40 (00:10) dns-server wtmp-ipv6.LE begins Wed Aug 28 21:30:40 2013 From this I conclude that the test itself is poor - it is assuming that there is a consistently good network / resolver for the duration of the test, something that can not be assumed to always be true. Theoretically glitches can happen anywhere, at any time. Question. What is the purpose of these 3 specific tests? If we are confirming that 'last' is formatting output in the manor specified by the switches then the tests are successful: the reported output may contain EITHER a.root-servers.net XOR dns-server If we are testing that the lookup has happened then it is perfectly acceptable that it will not be possible due to a transitory network failure. this does not mean that last itself is not working correctly only that this test did not PASS (i.e. !PASS is not the same as FAIL) Maybe remove/disable the test, or add retries? Maybe add detection for a timeout failure and simply return a different value to warn about this? signature.asc Description: OpenPGP digital signature
Bug#919826: linux-image-4.19.0-1-arm64: Loading Linux 4.19.0-1-arm64 Loading initial ramdisk error: out of memory system panic
Package: linux-image-4.19.0-1-arm64 Severity: critical Justification: breaks the whole system Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? upgrading kernel in Buster from 4.18.0-3-arm64 via apt-get dist-upgrade * What exactly did you do (or not do) that was effective (or ineffective)? root@sally:~# uname -a Linux sally 4.18.0-3-arm64 #1 SMP Debian 4.18.20-2 (2018-11-23) aarch64 GNU/Linux root@sally:~# ## update apt/sources to point to a mirror (was DVD) root@sally:~# apt-get update Hit:1 http://ftp.uk.debian.org/debian buster InRelease Hit:2 http://security.debian.org/debian-security buster/updates InRelease Reading package lists... Done root@sally:~# apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: libhunspell-1.6-0 liblvm2app2.2 liblvm2cmd2.02 libpython3.6-minimal libpython3.6-stdlib python3.6 python3.6-minimal Use 'apt autoremove' to remove them. The following NEW packages will be installed: apparmor firmware-linux-free irqbalance libaio1 libdns-export1104 libhunspell-1.7-0 libisc-export1100 liblvm2cmd2.03 libnftables0 libnftnl11 libnuma1 libpython3.7-minimal libpython3.7-stdlib libuchardet0 linux-image-4.19.0-1-arm64 nftables python3.7 python3.7-minimal The following packages will be upgraded: adwaita-icon-theme apt apt-utils bash-completion bind9-host bsdutils dash dbus dbus-user-session dconf-gsettings-backend dconf-service dmeventd dmsetup e2fsprogs enchant fdisk file gcc-8-base gir1.2-atk-1.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-glib-2.0 gir1.2-gtk-3.0 gir1.2-pango-1.0 gir1.2-vte-2.91 glib-networking glib-networking-common glib-networking-services gpgv grep groff-base grub-common grub-efi-arm64 grub-efi-arm64-bin grub-efi-arm64-signed grub2-common gtk-update-icon-cache gzip init init-system-helpers iproute2 iptables isc-dhcp-client isc-dhcp-common klibc-utils krb5-locales libapparmor1 libapt-inst2.0 libapt-pkg5.0 libatk1.0-0 libatk1.0-data libbind9-161 libblkid1 libc-bin libc-l10n libc6 libcairo-gobject2 libcairo2 libcap-ng0 libcom-err2 libcroco3 libcryptsetup12 libcups2 libdbus-1-3 libdconf1 libdebconfclient0 libdevmapper-event1.02.1 libdevmapper1.02.1 libdns1104 libedit2 libefiboot1 libefivar1 libelf1 libenchant1c2a libext2fs2 libfdisk1 libfribidi0 libfstrm0 libfuse2 libgcc1 libgcrypt20 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libgirepository-1.0-1 libglib2.0-0 libglib2.0-data libgmp10 libgnutls30 libgpg-error0 libgraphite2-3 libgssapi-krb5-2 libgtk-3-0 libgtk-3-bin libgtk-3-common libharfbuzz0b libhogweed4 libicu63 libip4tc0 libip6tc0 libiptc0 libisc1100 libisccc161 libisccfg163 libjansson4 libjson-glib-1.0-0 libjson-glib-1.0-common libk5crypto3 libklibc libkrb5-3 libkrb5support0 libldap-2.4-2 libldap-common liblwres161 liblz4-1 libmagic-mgc libmagic1 libmount1 libnettle6 libnghttp2-14 libpam-modules libpam-modules-bin libpam-runtime libpam-systemd libpam0g libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpangoxft-1.0-0 libperl5.28 libpixman-1-0 libpng16-16 libproxy1v5 libpython3-stdlib libpython3.6-minimal libpython3.6-stdlib librsvg2-2 librsvg2-common libsemanage-common libsemanage1 libsmartcols1 libsoup-gnome2.4-1 libsoup2.4-1 libsqlite3-0 libss2 libstdc++6 libsystemd0 libudev1 libuuid1 libvte-2.91-0 libvte-2.91-common libxcb-render0 libxcb-shm0 libxcb1 libxml2 libxtables12 libzstd1 linux-image-arm64 locales lvm2 man-db mount openssh-client openssh-server openssh-sftp-server os-prober perl perl-base perl-modules-5.28 publicsuffix python3 python3-chardet python3-debianbts python3-gi python3-gi-cairo python3-minimal python3-pkg-resources python3-pycurl python3-pysimplesoap python3-six python3.6 python3.6-minimal rsyslog sed systemd systemd-sysv sysvinit-utils tar task-english task-ssh-server tasksel tasksel-data telnet tzdata ucf udev util-linux util-linux-locales vim-common vim-tiny wget xdg-user-dirs xxd 203 upgraded, 18 newly installed, 0 to remove and 0 not upgraded. Need to get 144 MB of archives. After this operation, 260 MB of additional disk space will be used. Do you want to continue? [Y/n] --- 8< --- Get:207 http://ftp.uk.debian.org/debian buster/main arm64 linux-image-4.19.0-1-arm64 arm64 4.19.12-1 [39.7 MB] Get:208 http://ftp.uk.debian.org/debian buster/main arm64 linux-image-arm64 arm64 4.19+101 [7,952 B] --- 8< --- Processing triggers for systemd (240-4) ... Setting up grub-efi-arm64 (2.02+dfsg1-10) ... Installing for arm64-efi platform. Installation finished. No error reported. Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.19.0-1-arm64 Found initrd
Bug#918769: ocaml-migrate-parsetree FTBFS:dh_install fails
Hi Ralf,
On Tue, Jan 8, 2019 at 11:18 PM Ralf Treinen wrote:
> ocaml-migrate-parsetree fails to build on sid using debhelper version 12
> (12 is the version of the debhelper package, I haven't touched the DH
> compat level) :
>
> dh_install: libmigrate-parsetree-ocamlbuild-ocaml missing files:
> usr/doc/ocaml-migrate-parsetree-ocamlbuild/{CHANGES.md,README.md,LICENSE.md}
> dh_install: missing files, aborting
> make: *** [debian/rules:8: binary] Error 25
I have just tried but failed to reproduce the issue with sbuild. I checked
I used debhelper 12.
My build log:
https://gist.github.com/andyli/ab6123beaf84db97756b1d137dbbb63b
Best,
Andy
Bug#917058: ocaml-migrate-parsetree FTBFS:
Hi Ralf, I've just pushed to salsa for a fix and update to the latest upstream version. I tested the update with autopkgtests against unstable-amd64 and unstable-mips, both passed. Would you review and upload? Best, Andy On Sat, Dec 22, 2018 at 9:00 AM Adrian Bunk wrote: > Source: ocaml-migrate-parsetree > Version: 1.0.10-2 > Severity: serious > Tags: ftbfs > > Some recent change in unstable makes ocaml-migrate-parsetree FTBFS: > > > https://tests.reproducible-builds.org/debian/history/ocaml-migrate-parsetree.html > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ocaml-migrate-parsetree.html > > ... > make -j1 install > DESTDIR=/build/1st/ocaml-migrate-parsetree-1.0.10/debian/tmp > AM_UPDATE_INFO_DIR=no > "INSTALL_ARGS=--destdir=/build/1st/ocaml-migrate-parsetree-1.0.10/debian/tmp > --libdir=/build/1st/ocaml-migrate-parsetree-1.0.10/debian/tmp/usr/lib/ocaml > --verbose" > make[2]: Entering directory '/build/1st/ocaml-migrate-parsetree-1.0.10' > jbuilder install > --destdir=/build/1st/ocaml-migrate-parsetree-1.0.10/debian/tmp > --libdir=/build/1st/ocaml-migrate-parsetree-1.0.10/debian/tmp/usr/lib/ocaml > --verbose > # Workspace root: /build/1st/ocaml-migrate-parsetree-1.0.10 > Running[0]: /usr/bin/nproc > /tmp/dune67e2fd.output 2> /dev/null > # # Workspace root: /build/1st/ocaml-migrate-parsetree-1.0.10 > # Auto-detected concurrency: 16 > Running[1]: /usr/bin/ocamlc.opt -config > /tmp/dune707986.output > # # # Workspace root: /build/1st/ocaml-migrate-parsetree-1.0.10 > # # Auto-detected concurrency: 16 > # Dune context: > # ((name default) > # (kind default) > # (profile release) > # (merlin true) > # (for_host ()) > # (build_dir (In_build_dir default)) > # (toplevel_path ()) > # (ocaml_bin (External /usr/bin)) > # (ocaml (External /usr/bin/ocaml)) > # (ocamlc (External /usr/bin/ocamlc.opt)) > # (ocamlopt ((External /usr/bin/ocamlopt.opt))) > # (ocamldep (External /usr/bin/ocamldep.opt)) > # (ocamlmklib (External /usr/bin/ocamlmklib.opt)) > # (env > #((CAML_LD_LIBRARY_PATH > # > /build/1st/ocaml-migrate-parsetree-1.0.10/_build/install/default/lib/stublibs) > # (DUNE_CONFIGURATOR /usr/bin/ocamlc.opt) > # (INSIDE_DUNE 1) > # (MANPATH > # > /build/1st/ocaml-migrate-parsetree-1.0.10/_build/install/default/bin) > # (OCAMLFIND_IGNORE_DUPS_IN > # > /build/1st/ocaml-migrate-parsetree-1.0.10/_build/install/default/lib) > # (OCAMLPATH > # > /build/1st/ocaml-migrate-parsetree-1.0.10/_build/install/default/lib))) > # (findlib_path ((External /usr/lib/ocaml))) > # (arch_sixtyfour true) > # (natdynlink_supported true) > # (supports_shared_libraries true) > # (opam_vars ()) > # (ocaml_config > #((version 4.05.0) > # (standard_library_default /usr/lib/ocaml) > # (standard_library /usr/lib/ocaml) > # (standard_runtime /usr/bin/ocamlrun) > # (ccomp_type cc) > # (c_compiler gcc) > # (ocamlc_cflags > # (-O2 > # -fno-strict-aliasing > # -fwrapv > # -D_FILE_OFFSET_BITS=64 > # -D_REENTRANT > # -fPIC)) > # (ocamlopt_cflags > # (-O2 -fno-strict-aliasing -fwrapv -D_FILE_OFFSET_BITS=64 > -D_REENTRANT)) > # (bytecomp_c_compiler > # (gcc > # -O2 > # -fno-strict-aliasing > # -fwrapv > # -D_FILE_OFFSET_BITS=64 > # -D_REENTRANT > # -fPIC)) > # (bytecomp_c_libraries (-lm -ldl -lcurses -lpthread)) > # (native_c_compiler > # (gcc > # -O2 > # -fno-strict-aliasing > # -fwrapv > # -D_FILE_OFFSET_BITS=64 > # -D_REENTRANT)) > # (native_c_libraries (-lm -ldl)) > # (cc_profile (-pg)) > # (architecture amd64) > # (model default) > # (int_size 63) > # (word_size 64) > # (system linux) > # (asm (as)) > # (asm_cfi_supported true) > # (with_frame_pointers false) > # (ext_exe ) > # (ext_obj .o) > # (ext_asm .s) > # (ext_lib .a) > # (ext_dll .so) > # (os_type Unix) > # (default_executable_name a.out) > # (systhread_supported true) > # (host x86_64-pc-linux-gnu) > # (target x86_64-pc-linux-gnu) > # (profiling true) > # (flambda false) > # (spacetime false) > # (safe_string false) > # (exec_magic_number Caml1999X011) > # (cmi_magic_number Caml1999I021) > # (cmo_magic_number Caml1999O011) > # (cma_magic_number Caml1999A012) > # (cmx_magic_number Caml1999Y015) > # (cmxa_magic_number Caml1999Z014) > # (ast_impl_magic_number Caml1999M020) > # (ast_intf_magic_number Caml1999N018) >
Bug#902868: linux-image-4.16.0-2-amd64 fails to boot
Package: src:linux Version: 4.16.16-2 Severity: critical Justification: breaks the whole system Dear Maintainer, * What led up to the situation? Up to date Debian testing on 2 July 2018 apt-get update apt-get upgrade linux-image-4.16.0-2-amd64 updated (I think) reboot * What was the outcome of this action? System did not boot Re-booted into previous kernel version and reviewed system logs The following seems to indicate the fault: Jul 2 09:04:31 kernel: [ 15.055880] [ cut here ] Jul 2 09:04:31 kernel: [ 15.055881] kernel BUG at /build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100! Jul 2 09:04:31 kernel: [ 15.055888] invalid opcode: [#1] SMP PTI Jul 2 09:04:31 kernel: [ 15.055890] Modules linked in: intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm snd_hda_codec_hdmi irqbypass iTCO_wdt iTCO_vendor_support crct10dif_pclmul crc32_pclmul mxm_wmi evdev ghash_clmulni_intel intel_cstate intel_uncore intel_rapl_perf pcspkr serio_raw snd_hda_codec_realtek snd_hda_codec_generic sg lpc_ich snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer ioatdma snd mei_me mei soundcore shpchp dca wmi button nvidia_drm(PO) drm_kms_helper drm nvidia_modeset(PO) nvidia(PO) ipmi_devintf ipmi_msghandler parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb sr_mod cdrom sd_mod hid_generic usbhid hid crc32c_intel ahci isci aesni_intel libahci libsas aes_x86_64 crypto_simd cryptd glue_helper psmouse Jul 2 09:04:31 kernel: [ 15.055943] sym53c8xx scsi_transport_spi xhci_pci i2c_i801 libata ehci_pci xhci_hcd ehci_hcd scsi_transport_sas e1000e usbcore scsi_mod usb_common Jul 2 09:04:31 kernel: [ 15.055954] CPU: 2 PID: 1184 Comm: Xorg Tainted: P O 4.16.0-2-amd64 #1 Debian 4.16.16-2 Jul 2 09:04:31 kernel: [ 15.055956] Hardware name: Viglen VIG430P/X9DAL, BIOS 3.0 01/02/2014 Jul 2 09:04:31 kernel: [ 15.055963] RIP: 0010:usercopy_abort+0x69/0x80 Jul 2 09:04:31 kernel: [ 15.055965] RSP: 0018:b81543c9bb50 EFLAGS: 00010282 Jul 2 09:04:31 kernel: [ 15.055967] RAX: 006f RBX: 0003 RCX: Jul 2 09:04:31 kernel: [ 15.055969] RDX: RSI: 8d90ffd16738 RDI: 8d90ffd16738 Jul 2 09:04:31 kernel: [ 15.055971] RBP: 0003 R08: 03ac R09: 0004 Jul 2 09:04:31 kernel: [ 15.055972] R10: ad877e48 R11: adfa8dcd R12: 0001 Jul 2 09:04:31 kernel: [ 15.055974] R13: 8d90d828dcb3 R14: R15: 8d90d828dcf8 Jul 2 09:04:31 kernel: [ 15.055977] FS: 7f841b5f96c0() GS:8d90ffd0() knlGS: Jul 2 09:04:31 kernel: [ 15.055979] CS: 0010 DS: ES: CR0: 80050033 Jul 2 09:04:31 kernel: [ 15.055981] CR2: 7f8413711010 CR3: 0004583c8005 CR4: 000606e0 Jul 2 09:04:31 kernel: [ 15.055982] Call Trace: Jul 2 09:04:31 kernel: [ 15.055992] __check_heap_object+0xe7/0x120 Jul 2 09:04:31 kernel: [ 15.055995] __check_object_size+0x9c/0x1a0 Jul 2 09:04:31 kernel: [ 15.056199] os_memcpy_to_user+0x21/0x40 [nvidia] Jul 2 09:04:31 kernel: [ 15.056416] _nv009377rm+0xbf/0xe0 [nvidia] Jul 2 09:04:31 kernel: [ 15.056600] ? _nv028067rm+0x79/0x90 [nvidia] Jul 2 09:04:31 kernel: [ 15.056780] ? _nv028067rm+0x55/0x90 [nvidia] Jul 2 09:04:31 kernel: [ 15.056950] ? _nv013694rm+0xee/0x100 [nvidia] Jul 2 09:04:31 kernel: [ 15.057120] ? _nv015342rm+0x154/0x270 [nvidia] Jul 2 09:04:31 kernel: [ 15.057336] ? _nv008310rm+0x134/0x1a0 [nvidia] Jul 2 09:04:31 kernel: [ 15.057548] ? _nv008289rm+0x29c/0x2b0 [nvidia] Jul 2 09:04:31 kernel: [ 15.057759] ? _nv001072rm+0xe/0x20 [nvidia] Jul 2 09:04:31 kernel: [ 15.057972] ? _nv007316rm+0xd8/0x100 [nvidia] Jul 2 09:04:31 kernel: [ 15.058181] ? _nv001171rm+0x627/0x830 [nvidia] Jul 2 09:04:31 kernel: [ 15.058389] ? rm_ioctl+0x73/0x100 [nvidia] Jul 2 09:04:31 kernel: [ 15.058507] ? nvidia_ioctl+0xf0/0x720 [nvidia] Jul 2 09:04:31 kernel: [ 15.058623] ? nvidia_ioctl+0x519/0x720 [nvidia] Jul 2 09:04:31 kernel: [ 15.058627] ? kmem_cache_free+0x19c/0x1d0 Jul 2 09:04:31 kernel: [ 15.058743] ? nvidia_frontend_unlocked_ioctl+0x3e/0x50 [nvidia] Jul 2 09:04:31 kernel: [ 15.058746] ? do_vfs_ioctl+0xa4/0x630 Jul 2 09:04:31 kernel: [ 15.058750] ? __audit_syscall_entry+0xbc/0x110 Jul 2 09:04:31 kernel: [ 15.058754] ? syscall_trace_enter+0x1df/0x2e0 Jul 2 09:04:31 kernel: [ 15.058757] ? SyS_ioctl+0x74/0x80 Jul 2 09:04:31 kernel: [ 15.058760] ? do_syscall_64+0x6c/0x130 Jul 2 09:04:31 kernel: [ 15.058764] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Jul 2 09:04:31 kernel: [ 15.058767] Code: 0f 44 d0 53 48 c7 c0 41 de 83 ad 51 48 c7 c6 dd d3 82 ad 41 53 48 89 f9 48 0f 45 f0 4c 89 d2 48 c7 c7 28 df 83 ad e8 f1 2e ea ff <0f> 0b 49 c7 c1 ac de 84 ad 4d 89 cb 4d
Bug#888095: [debian-mysql] Bug#888095:
Hi Otto, On Fri, May 11, 2018 at 9:53 AM, Andy Li wrote: > > >> > On 10/05/18 20:24, Otto Kekäläinen wrote: >> >> MariaDB 10.3 needs to be finalized and imported into Debian. After >> >> that all the mess that are a fallout of a misfortunate upload of >> >> mariadb-10.2 to Debian unstable will start to become resolved. >> > > What do you mean by finalized? Are we waiting upstream for something? > If it will still take an unknown number of months to stabilize, using > an epoch as suggested by Emilio seems to be a good immediate solution. > I'm sure you have been busy, but this issue has been there unfixed for several months. I would appreciate if you can spend a few minutes to answer our questions. If you lack the time to maintain the package, would you let the Debian MySQL Maintainers team temporally handle it? Best regards, Andy
Bug#888095: pinging again
I would like to ping again in hope that it will be fixed soon. Best regards, Andy
Bug#900018: FTBFS with latest cmdliner
Hi Mehdi, Just saw that you've fixed that in the new upload. Thanks for taking care of it! Best regards, Andy On Sun, Jun 3, 2018 at 7:08 PM, Mehdi Dogguy wrote: > Hi Andy, > > On 2018-05-25 08:40, Andy Li wrote: > >> I've a patch: >> https://github.com/ocaml/opam/compare/1.2.2...andyli:1.2.2-fix.patch >> It's based on the discussion with upstream at >> https://discuss.ocaml.org/t/the-forever-beta-issue/1779/6 >> >> > In fact, the patch introduces a bug and makes the build fail later in > the process (can't generate manpages and test-suite doesn't succeed). > > Do you confirm this on your side as well? > > -- > Mehdi >
Bug#900018: FTBFS with latest cmdliner
On Fri, May 25, 2018 at 3:02 PM, Mehdi Dogguy <me...@debian.org> wrote: > > I have the feeling that OPAM team is not willing to support OPAM 1.2.2 > for a long time. So it doesn't make sense, at least for me, to > include it in Buster. > > Yesterday, I've uploaded opam-file-format to NEW. As soon as it gets > accepted, I'll upload latest version of OPAM to Debian/Sid. > > It's based on the discussion with upstream at >> https://discuss.ocaml.org/t/the-forever-beta-issue/1779/6 > > Upstream mentioned in the linked discussion (above) that opam 1.2.2 is their LTS release. Sadly, opam 2 is not yet final, and "is still subject to backwards-incompatible changes". See https://bugzilla.redhat.com/show_bug.cgi?id=1501992#c23 I think we better stick to 1.2.2 for now. Best regards, Andy
Bug#900018: FTBFS with latest cmdliner
I've a patch: https://github.com/ocaml/opam/compare/1.2.2...andyli:1.2.2-fix.patch It's based on the discussion with upstream at https://discuss.ocaml.org/t/the-forever-beta-issue/1779/6 Best regards, Andy
Bug#888095: [debian-mysql] Bug#888095:
> > On 10/05/18 20:24, Otto Kekäläinen wrote: > >> MariaDB 10.3 needs to be finalized and imported into Debian. After > >> that all the mess that are a fallout of a misfortunate upload of > >> mariadb-10.2 to Debian unstable will start to become resolved. > What do you mean by finalized? Are we waiting upstream for something? If it will still take an unknown number of months to stabilize, using an epoch as suggested by Emilio seems to be a good immediate solution. Best regards, Andy
Bug#888095: [debian-mysql] Bug#888095:
Sorry but I would like to bring this up again. If Otto is not available for fixing this, can anyone in the Debian MySQL Maintainers team help? Best regards, Andy
Bug#888095: [debian-mysql] Bug#888095:
I'm still not sure what I can do for the neko package, which failed to be build with errors like: Dependency installability problem for neko on amd64: neko build-depends on: - libmariadb-dev-compat:amd64 libmariadb-dev-compat depends on missing: - libmariadb-dev:amd64 (= 2.3.3-1) >From the mariadb-connector-c build log page, https://buildd.debian.org/status/package.php?p=mariadb-connector-c, I can see that the builds are not installed for 2 months already. Best, Andy
Bug#888095:
This has been affecting neko (https://tracker.debian.org/pkg/neko) for a while. Would you fix it soonish? Best regards, Andy
Bug#877085: network-manager installation crashes debian buster
Package: network-manager Severity: critical Justification: breaks the whole system Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I installed network-manager and my system (dell r710 server) crashed immediately, tried to reboot, failed and tried to reboot, this cycle went on indefinitely * What exactly did you do (or not do) that was effective (or ineffective)? Removed the package with apt-get remove network-manager in recovery mode * What was the outcome of this action? System rebooted as normal and was able to login. * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-1-amd64 (SMP w/24 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager depends on: ii adduser3.116 ii dbus 1.11.16+really1.10.22-1 ii init-system-helpers1.49 ii libaudit1 1:2.7.7-1+b2 pn libbluetooth3 ii libc6 2.24-17 ii libcurl3-gnutls7.55.1-1 ii libglib2.0-0 2.54.0-1 ii libgnutls303.5.15-2 pn libjansson4 pn libmm-glib0 pn libndp0 ii libnewt0.520.52.20-1+b1 ii libnl-3-2003.2.27-2 pn libnm0 ii libpam-systemd 234-3 ii libpolkit-agent-1-00.105-18 ii libpolkit-gobject-1-0 0.105-18 ii libpsl50.18.0-4 ii libreadline7 7.0-3 ii libselinux12.7-2 ii libsystemd0234-3 pn libteamdctl0 ii libudev1 234-3 ii libuuid1 2.29.2-5 ii lsb-base 9.20170808 ii policykit-10.105-18 ii udev 234-3 pn wpasupplicant Versions of packages network-manager recommends: pn crda ii dnsmasq-base 2.77-2 ii iptables 1.6.1-2 pn iputils-arping ii isc-dhcp-client 4.3.5-3 pn modemmanager ii ppp 2.4.7-1+4 Versions of packages network-manager suggests: pn libteam-utils
Bug#876530: ocaml-gen FTBFS with OCaml 4.05.0: E: Cannot find external tool 'ocamlbuild'
I've just pushed a fix to Alioth. Stéphane: Would you help upload it? Best regards, Andy
Bug#867742: boinc-client: After installation, then trying to initiate boinc-client, segmentation violation and the program exits
Package: boinc-client Version: 7.4.23+dfsg-1 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Boinc installed fine from the kfreebsd repository. but a segmentation violation occurs (11 Frames) on starting the program * What exactly did you do (or not do) that was effective (or ineffective)? I have tried to install the experimental package as suggested by report bug and on another occasion I have tried to compile boinc from source code. Both without success * What was the outcome of this action? Both attempts did'nt work. * What outcome did you expect instead? I'm trying to get it running on esxi 6.0 so I can put it on a server to contribute to scientific research. Tahnkyou for your time. *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.0 APT prefers oldstable-kfreebsd-proposed-updates APT policy: (500, 'oldstable-kfreebsd-proposed-updates'), (500, 'oldstable-kfreebsd'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#770369: Bug#737491: eterm: Occurs on upgrade to Jessie from Wheezy
Hi, Andy, I have tested a couple of solutions and I think the easiest way for you is just to download the Eterm package for Stretch (testing) and install it in your system manually with: dpkg -i eterm_0.9.6-4_amd64.deb I have just installed the Eterm version in testing and no new packages are needed, just this one and it is working in my system. (One can use pinning in apt to install packages for several distributions, but for just one package I think it is not necessary in this case). Please, let me know if this solution is not working for you to try a more elaborate fix until Stretch is released. That works great, thanks! Thank you so much for your help; it's been really generous of you. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF
Bug#770369: Bug#737491: eterm: Occurs on upgrade to Jessie from Wheezy
Hi, Thanks for your help! I think this bug is the same than bug #770369. I tried to file this as a followup to the existing bug but must have messed up with my usage of `reportbug`; sorry! This bug is close in stretch (testing). As it is expected the release stretch occurs soon, the easiest way is: 1. To wait for the release of stretch to get this problem fixed when you upgrade from Wheezy to Stretch. 2. Downgrade the Eterm package to the version in Jessie so you can use it until the upgrade to Stretch. Do you mean wheezy? Do you have a command to hand that can do that for me or is it best to fetch the .deb out of the appropriate package pool? I am trying to maintain Eterm package, but my process of learning to do it properly is getting a little long so I have not prepared a new Eterm package. I have checked the fix proposed and my local Eterm package is working in Jessie-amd64 (thanks to Charles Gorand and Arnaud Ceyroll for the fix). Andy, if you want I can send you my local package to your e-mail, so you can use it. For Santiago Vila (or other developers) I have modified the source package in Jessie by performing the fix suggested by Arnaud and Charles to the command.c file, just recompiled in my Jessie system and the new Eterm package is working again. Maybe I can try to build my own local package? Are you able to send me the patch for the Jessie package? Maybe it is worth to propose an update for Jessie so the package will be usable again for all the users. I will have some spare time after the middle of June, so I would be able to apply the fix in the correct way (I have just edited the source to test it, I have to read deeper the maint-guide to do it in the right way). After the release of Stretch I will try to fix the UTF8 problem in Eterm to finally maintain this package. Thanks for your help and for giving the time. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF
Bug#777511: kernels tested
Ben I have tested against the following kernels on snapshot.d.o Pass 4.2.1-1 4.0.0-1 3.16.36-1 Fails 3.16.7-ckt4-3 /Andy
Bug#777511: update
Hi, it has been a while since there has been any activity against this bug. it is marked as grave, this means that it is Release Critical for Stretch. I have just run Cyril's md-mirror-resync-broken-v2.sh script on a machine running stretch rc1 (Linux debian 4.4.0-2amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux) and this reports Ok, bug not found I guess that means that the regression of this bug is now fixed... Thanks /Andy signature.asc Description: OpenPGP digital signature
Bug#790796: sensord
Hi there, Back in August *2015* there was a short discussion regarding removing sonsord from lm-sensors as a result of this bug. Because it is marked as GRAVE, this bug is release critical for Stretch. Is this really a grave bug, should it be down graded? Can Sensord be removed? Is there another option? It seams to me that if you depend on the structure of a file that changes you could simply re-initialise sensord passing it the new structure. However I suspect that I am trivialising the underlying issue... /Andy
Bug#665334: [Pkg-fonts-devel] Bug#665334: non-DFSG & Type 1 Postscript embedded fonts
On 29/01/17 13:18, Paul Wise wrote: > On Sun, Jan 29, 2017 at 7:35 PM, Andy Simpkins wrote: > >> It is our belief that this is sufficient; that the package FontForge, >> and type 1 fonts generated by this package are now DFSG compliant >> because Apache 2.0 is GPL2+ compatible. > The FSF believes that Apache 2.0 is only compatible with GPLv3+ not GPLv2. > > https://www.gnu.org/licenses/license-list.html#apache2 > https://www.apache.org/licenses/GPL-compatibility.html > Well Paul you are entirely correct. Would you believe that pretty much everyone here missed that one - despite the fact that nearly every person did proof this :-) OK so what does that mean? GPL2 stuff could be problematic but ultimately the suggested action(s) would still appear valid... Karen your thoughts on this would be greatly appreciated /Andy signature.asc Description: OpenPGP digital signature
Bug#795055: Any progress or updates?
Hi Anibal, It has been a long time since we last caught up! As part of the Cambridge BSP this weekend [1] I have been looking at lisence violations such as the one in this bug that is marked as RC. It is my understanding that there is no problems with the "All rights reserved" statement included in many of the files without then including the 3-clause BSD licence text as there is no requirement (only a recommendation) for licences to appear inside each file only an overriding external licence text. This is present. HOWEVER Dmitry also points out that there are several files with 4-Clause BSD licences explicit within them, namely: src/crypt_client.c tirpc/rpcsvc/crypt.x As Dmitry points out that this is non-DFSG compliant, so it is these two files that are the cause for concern This bug was raised August 2015, and I have not been able to find any activity since. Do you have a plan of how to deal with this issue prior to the release of Stretch? [1] https://wiki.debian.org/BSP/2017/01/gb/Cambridge signature.asc Description: OpenPGP digital signature
Bug#840733: Please remove...
Hi Ted, I am currently sat at the Cambridge BSP looking at Debian RC bugs [1]. Looking at this bug report we believe that on balance the best course of action would be to remove lib/et/test_cases/imap_err.et from e2fsprogs. As you have offered to do this in your capacity as "upstream" [2] may we please ask you to do this at your earliest opportunity. Would you mind performing this as an atomic operation as this would make the process of freeze exception straight forwards. Many thanks in advance, /Andy [1] https://wiki.debian.org/BSP/2017/01/gb/Cambridge#Attendees [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840733#10 signature.asc Description: OpenPGP digital signature
Bug#694320: non-DFSG & Type 1 Postscript embedded fonts
Hi Karen, At the Cambridge BSP (Jan 27/28 2017) we have been looking at the following bugs pertaining to non-DFSG compliance with fonts embedded with non-free code: * http://bugs.debian.org/665334 opened 23 Mar 2012, last update 01 Aug 2016 modulo spam * http://bugs.debian.org/694320 opened 25 Nov 2012, last update 30 Aug 2014 blocked by #665334 * http://bugs.debian.org/694323 opened 25 Nov 2012, last update 30 Aug 2014 blocked by #665334 Synopsis: Type 1 fonts that are made using the package FontForge include font hinting code which is marked "copyright Adobe all rights reserved". This issue logically extends to every package that contains fonts that have been made using FontForge. Current State Reading #665334 it appears that FontForge historically contained fragments of code with Adobe asserted rights. We believe that this is now resolved with "autohint code is now all open source". The github repo is top licensed Apache 2.0 [1] It is our belief that this is sufficient; that the package FontForge, and type 1 fonts generated by this package are now DFSG compliant because Apache 2.0 is GPL2+ compatible. * Is our understanding of the above correct? i.e. Does the github repository top-licensing (to Apache) of the Adobe 'hinting' properly apply? * Are the font hinting fragments, that are Adobe copyright, embedded into fonts produced in FontForge, the same code as in the above repository (we *think* that this is the case)? * Thus, are these fonts (generated by the above) now covered by Apache 2.0? * And, consequently: are the fonts in the Debian archive, produced by FontForge, now to be considered under Apache 2.0; and is this sufficient to cover the embedded fragments under Apache 2.0? Assuming the above is all correct then, in order to resolve this issue, we believe that all packages that contain fonts that are generated using FontForge should contain an appropriate licence text for the font. A Mass bug filing could then be made against these packages requesting the appropriate update to the licence file. However we see this a potential minefield, and therefore seek clarification and advice before we continue. /Andy PP Debian BSP Cambridge Jan 2017 [2] [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665334#168 [2] https://wiki.debian.org/BSP/2017/01/gb/Cambridge signature.asc Description: OpenPGP digital signature
Bug#784070: Newly-created arrays don't auto-assemble - related to hostname change?
Hi, On Wed, Nov 23, 2016 at 12:03:49PM +0300, Michael Tokarev wrote: > It was long ago when we disabled incremental assembly when > you turned it on by default, and kept old static way to > assemble arrays, because neither our initrd nor regular > userpsace weren't ready for that. Okay, so, on Debian jessie then, it is expected that md arrays on devices that are only present after the initramfs is done working will not be automatically (incrementally) started? I saw Yann mentioned that in stretch the GOTO="md_inc_end" has been removed again. Does that mean that incremental assembly on device change is expected to work again in stretch (I have not tested it, and most likely will not have time to do so with this hardware). Thanks, Andy
Bug#837065: gdal-bin: ogr2ogr Segmentation fault
On Thursday, 8 September 2016 15:24:46 BST Sebastiaan Couwenberg wrote: > On 09/08/2016 03:07 PM, Andy G Wood wrote: > >> Please provide a list of the package versions you have installed for the > >> libdal20 dependencies (apt-cache show libgdal20 | grep Depends). > > > > $ apt-cache show libgdal20 | grep Depends > > Those are only the libgdal20 dependencies, not their installed versions. Sorry I missed that bit. Slight delay to "bash" the answer, which is: libarmadillo6 1:6.700.6+dfsg-1 libc6:amd64 2.23-5 libcrypto++6 5.6.3-7 libcurl3-gnutls:amd64 7.50.1-1 libdap23:amd64 3.18.0-2 libdapclient6v5:amd64 3.18.0-2 libdapserver7v5:amd64 3.18.0-2 libepsilon1:amd64 0.9.2+dfsg-2 libexpat1:amd64 2.2.0-1 libfreexl1:amd64 1.0.2-2 libgcc1:amd64 1:6.1.1-11 libgeos-c1v5 3.5.0-4 libgeotiff2:amd64 1.4.2-2+b1 libgif7:amd64 5.1.4-0.3 libhdf4-0-alt 4.2.12-1 libhdf5-10:amd64 1.8.16+docs-8 libjpeg62-turbo:amd64 1:1.5.0-1 libjson-c3:amd64 0.12.1-1 libkmlbase1:amd64 1.3.0-3 libkmldom1:amd64 1.3.0-3 libkmlengine1:amd64 1.3.0-3 libkmlregionator1:amd64 1.3.0-3 libkmlxsd1:amd64 1.3.0-3 liblzma5:amd64 5.1.1alpha+20120614-2.1 libnetcdf11 1:4.4.1-2 libodbc1:amd64 2.3.1-4.1 libogdi3.2 3.2.0+ds-1+b1 libopenjp2-7:amd64 2.1.1-1 libpcre3:amd64 2:8.39-2 libpng16-16:amd64 1.6.24-2 libpoppler61:amd64 0.44.0-3 libpq5:amd64 9.6~rc1-1 libproj12 4.9.3-1 libqhull7:amd64 2015.2-1 libspatialite7:amd64 4.3.0a-5+b1 libstdc++6:amd64 6.1.1-11 libsz2:amd64 0.3.2-1 libtiff5:amd64 4.0.6-2 libwebp6:amd64 0.5.1-2 libxerces-c3.1:amd64 3.1.3+debian-2.1+b1 libxml2:amd64 2.9.4+dfsg1-1+b1 odbcinst1debian2:amd64 2.3.1-4.1 zlib1g:amd64 1:1.2.8.dfsg-2+b1 Andy.
Bug#837065: gdal-bin: ogr2ogr Segmentation fault
Hi Bas, > spatialite, gdal and many other packages were recently rebuilt for the > transition to proj 4.9.3. Ensure you've upgraded all package $ sudo apt-get update; sudo apt-get dist-upgrade 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > gdal 2.1.1+dfsg-1+b1 has not been rebuilt with the proj 4.9.3, you need > at least +b2 for that. It has most likely not migrated because new gdal > revisions were uploaded to unstable to deal with the libmysqlclient-dev > changes, and haven't aged sufficiently to migrate to testing. As of today (Thu 8 Sep 13:53:11 BST 2016) gdal 2.1.1+dfsg-4 in unstable is "Too young, only 0 of 5 days old" > Please provide a list of the package versions you have installed for the > libdal20 dependencies (apt-cache show libgdal20 | grep Depends). $ apt-cache show libgdal20 | grep Depends Depends: libarmadillo6, libc6 (>= 2.15), libcrypto++6, libcurl3-gnutls (>= 7.16.2), libdap23, libdapclient6v5, libdapserver7v5, libepsilon1 (>= 0.8.1), libexpat1 (>= 2.0.1), libfreexl1 (>= 0.0.2~beta20110817), libgcc1 (>= 1:3.0), libgeos-c1v5 (>= 3.4.2), libgeotiff2 (>= 1.4.1), libgif7 (>= 5.1), libhdf4-0- alt (>= 4.2r4), libhdf5-10, libjpeg62-turbo (>= 1.3.1), libjson-c3 (>= 0.11), libkmlbase1 (>= 1.3.0~r864), libkmldom1 (>= 1.3.0~rc2), libkmlengine1 (>= 1.3.0~r864), libkmlregionator1 (>= 1.3.0~r864), libkmlxsd1 (>= 1.3.0~r864), liblzma5 (>= 5.1.1alpha+20110809), libnetcdf11 (>= 4.0.1), libodbc1 (>= 2.3.1), libogdi3.2 (>= 3.2.0~beta2), libopenjp2-7 (>= 2.0.0), libpcre3, libpng16-16 (>= 1.6.2-1), libpoppler61 (>= 0.44.0), libpq5, libproj12 (>= 4.8.0), libqhull7, libspatialite7 (>= 4.2.0), libstdc++6 (>= 5.2), libsz2, libtiff5 (>= 4.0.3), libwebp6 (>= 0.5.1), libxerces-c3.1, libxml2 (>= 2.7.4), odbcinst1debian2 (>= 2.3.1), zlib1g (>= 1:1.2.0) Depends: libarmadillo6, libc6 (>= 2.15), libcrypto++6, libcurl3-gnutls (>= 7.16.2), libdap17v5, libdapclient6v5, libdapserver7v5, libepsilon1 (>= 0.8.1), libexpat1 (>= 2.0.1), libfreexl1 (>= 0.0.2~beta20110817), libgcc1 (>= 1:4.0), libgeos-c1v5 (>= 3.4.2), libgeotiff2 (>= 1.4.1), libgif7 (>= 5.1), libhdf4-0- alt (>= 4.2r4), libhdf5-10, libjpeg62-turbo (>= 1.3.1), libjson-c3 (>= 0.11), libkmlbase1 (>= 1.3.0~r864), libkmldom1 (>= 1.3.0~rc2), libkmlengine1 (>= 1.3.0~r864), libkmlregionator1 (>= 1.3.0~r864), libkmlxsd1 (>= 1.3.0~r864), liblzma5 (>= 5.1.1alpha+20110809), libmysqlclient18, libnetcdf11 (>= 4.0.1), libodbc1 (>= 2.3.1), libogdi3.2 (>= 3.2.0~beta2), libopenjp2-7 (>= 2.0.0), libpcre3, libpng16-16 (>= 1.6.2-1), libpoppler61 (>= 0.44.0), libpq5, libproj9 (>= 4.8.0), libqhull7, libspatialite7 (>= 4.2.0), libstdc++6 (>= 5.2), libsz2, libtiff5 (>= 4.0.3), libwebp6 (>= 0.5.1), libxerces-c3.1, libxml2 (>= 2.7.4), odbcinst1debian2 (>= 2.3.1), zlib1g (>= 1:1.2.0) Andy.
Bug#837065: gdal-bin: ogr2ogr Segmentation fault
Package: gdal-bin Version: 2.1.1+dfsg-1+b1 Severity: grave Justification: renders package unusable Dear Maintainer, On an up-to-date Debian testing system, the following command, which normally just works, now gives a seg fault: ogr2ogr -t_srs EPSG:3857 -f "SQLite" -dsco SPATIALITE=YES \ file.sqlite points.xml I think I noted a very recent update of spatialite in testing, so this might be related to that? Andy. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.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 gdal-bin depends on: ii libc6 2.23-5 ii libgcc1 1:6.1.1-11 ii libgdal20 [gdal-abi-2-1-1] 2.1.1+dfsg-1+b1 ii libstdc++6 6.1.1-11 gdal-bin recommends no packages. Versions of packages gdal-bin suggests: ii python-gdal 2.1.1+dfsg-1+b1 -- no debconf information
Bug#829255: oss4-dkms: Fails to build for 4.6.0-1-amd64
Package: oss4
Version: 4.2-build2010-5
Followup-For: Bug #829255
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve allow this package to build
with v4.6 based kernels:
* d/p/osspci_remove-should-return-void.patch -- correct return from
struct pci_device remove callback. (LP: #1599237)
Thanks.
-apw
-- System Information:
Debian Release: stretch/sid
APT prefers yakkety
APT policy: (500, 'yakkety')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.0-25-generic (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)
diff -Nru oss4-4.2-build2010/debian/patches/osspci_remove-should-return-void.patch oss4-4.2-build2010/debian/patches/osspci_remove-should-return-void.patch
--- oss4-4.2-build2010/debian/patches/osspci_remove-should-return-void.patch 1970-01-01 01:00:00.0 +0100
+++ oss4-4.2-build2010/debian/patches/osspci_remove-should-return-void.patch 2016-07-05 17:08:34.0 +0100
@@ -0,0 +1,36 @@
+Description: osspci_remove should return void
+ The stuct pci_device callback remove should be a void function. This
+ has been true since 2.6.12 but only recently has this become fatal.
+Author: Andy Whitcroft <a...@ubuntu.com>
+---
+
+Index: oss4-4.2-build2010/setup/Linux/oss/build/pci_wrapper.inc
+===
+--- oss4-4.2-build2010.orig/setup/Linux/oss/build/pci_wrapper.inc
oss4-4.2-build2010/setup/Linux/oss/build/pci_wrapper.inc
+@@ -70,9 +70,9 @@ osspci_probe (struct pci_dev *pcidev, co
+ }
+
+ #if LINUX_VERSION_CODE < KERNEL_VERSION(3,8,0)
+- static int __devexit
++ static void __devexit
+ #else
+- static int
++ static void
+ #endif
+ osspci_remove (struct pci_dev *pcidev)
+ {
+@@ -87,12 +87,10 @@ osspci_remove (struct pci_dev *pcidev)
+ printk (KERN_ALERT DRIVER_NICK ": Unloading busy device\n");
+ pci_disable_device (dev_map[i].pcidev);
+ osdev_delete (osdev);
+-
+- return 0;
++ return;
+ }
+
+ printk (KERN_ALERT DRIVER_NICK ": Can't find the PCI device to detach\n");
+- return -EIO;
+ }
+
+ void
diff -Nru oss4-4.2-build2010/debian/patches/series oss4-4.2-build2010/debian/patches/series
--- oss4-4.2-build2010/debian/patches/series 2015-09-26 00:31:01.0 +0100
+++ oss4-4.2-build2010/debian/patches/series 2016-07-05 17:06:41.0 +0100
@@ -19,3 +19,4 @@
#generic_srccconf.patch (seems completely broken to me)
501_linux_version.patch
502_linux_io.patch
+osspci_remove-should-return-void.patch
Bug#817146: gdal-bin: ogr2ogr segfault
Hi Bas, Reducing a much larger data set, attached argos_trip.csv which is used by attached argos.xml which generates the segfault with: ogr2ogr -a_srs WGS84 -f GeoJSON -where "ID=098530" -nln "098530" \ p098530.json argos.xml Andy. On Tuesday 08 March 2016 14:58:47 Bas Couwenberg wrote: > Control: tags -1 moreinfo > > Hi Andy, > > > Running an ogr2ogr command that had been working until the most recent > > update in testing: > > > > ogr2ogr -a_srs WGS84 -f GeoJSON -where "ID=098530" -nln "098530" > > p098530.json argos.xml > > Can you provide the data file(s) to reproduce this issue? > > Kind Regards, > > Bas argos.xml Description: XML document ID,DIST,THEGEOM 098530,32,"LINESTRING(-72.303 -69.499, -72.295 -69.506, -72.316 -69.511, -72.343 -69.513, -72.280 -69.510, -72.269 -69.497, -72.271 -69.500, -72.322 -69.490, -72.327 -69.510, -72.317 -69.515, -72.290 -69.507, -72.300 -69.504, -72.298 -69.493, -72.297 -69.498, -72.298 -69.506, -72.308 -69.508, -72.306 -69.507, -72.306 -69.506, -72.319 -69.503, -72.305 -69.506, -72.299 -69.509, -72.342 -69.501, -72.280 -69.511, -72.279 -69.527, -72.247 -69.530, -72.206 -69.528, -72.264 -69.528, -72.242 -69.520, -72.245 -69.519)"
Bug#817146: gdal-bin: ogr2ogr segfault
Package: gdal-bin Version: 2.0.2+dfsg-2 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Running an ogr2ogr command that had been working until the most recent update in testing: ogr2ogr -a_srs WGS84 -f GeoJSON -where "ID=098530" -nln "098530" p098530.json argos.xml * What was the outcome of this action? Segfault and error message. In /var/log/syslog: kernel: [1918421.641659] ogr2ogr[11691]: segfault at ceb3f0 ip 00ceb3f0 sp 7fffbd837758 error 15 At command line: ERROR 1: Type mismatch or improper type of arguments to = operator. FAILURE: SetAttributeFilter(ID=098530) on layer 'argos_trip' failed. Segmentation fault -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.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 gdal-bin depends on: ii libc6 2.21-9 ii libgcc1 1:5.3.1-10 ii libgdal20 [gdal-abi-2-0-2] 2.0.2+dfsg-2 ii libstdc++6 5.3.1-10 gdal-bin recommends no packages. Versions of packages gdal-bin suggests: ii python-gdal 2.0.2+dfsg-2 -- no debconf information
Bug#799702: ed: ships /usr/share/info/dir.gz on arm64
As part of cambridge bsp we have investigated this bug. The suggested patch does not actuly fix the bug (the -B option still includes /usr/share/info/dir.gz) // info and is not just limited to arm64 Problem was caused by build rules missing build-arch target, and therefore not applying patched during autobuilder builds. JMW has uploaded fix. /Andy signature.asc Description: OpenPGP digital signature
Bug#801781: Possibly fixed.
Hi Salvo, I am looking back though open bugs at the moment and see that the mail traffic for the bug you reported stopped back at the end of October, with people suggesting that this has now gone away. Have you seen this? Have recent updates fixed the problem for you? If so can you please respond and we can close off the bug. If not can you just let us know that you are still seeing the problem and what versions you are currently running. Many thanks /Andy signature.asc Description: OpenPGP digital signature
Bug#810070: [Pkg-xen-devel] Bug#810070: XEN Hypervisor crashes/reboots at Startup after "Scrubbing Free Ram"
If possible it might be interesting to first try the 4.6 hypervisor in Stretch, I suspect the xen-hypervisor-4.6-amd64 package will just install on Jessie with no issues since it has no dependencies and you don't need the userspace tools just to check if it boots.Hey there,I can confirm the issue with new Intel i7-6700 Quad-Core Skylake CPUs and I'm also not able to derive further details than already provided. But I can also confirm, that the issue seems to be resolved in Debian Stretch.Andy
Bug#812999: flashcache: we are not correctly recording the bio error code in 4.3
Package: flashcache Version: 3.1.3+git20150701-2 Severity: serious Tags: patch User: a...@ubuntu.com Usertags: origin-ubuntu xenial ubuntu-patch Dear Maintainer, While merging up the Ubuntu delta with the current flashcache it looks very much like we are not correctly passing over the BIO error code in the 4.3 compatibility code. We have the attached patch applied to correct this. Looking at upstream they also have fixed the 4.3 issue in the same manner. Cheers. -apw -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-5-generic (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) diff -Nru flashcache-3.1.3+git20150701/debian/patches/record-bio-error-on-linux-4.3.patch flashcache-3.1.3+git20150701/debian/patches/record-bio-error-on-linux-4.3.patch --- flashcache-3.1.3+git20150701/debian/patches/record-bio-error-on-linux-4.3.patch 1970-01-01 01:00:00.0 +0100 +++ flashcache-3.1.3+git20150701/debian/patches/record-bio-error-on-linux-4.3.patch 2016-01-28 12:20:13.0 + @@ -0,0 +1,16 @@ +Description: record bio error on linux 4.3 + Record the bio error code when ending an IO on linux 4.3 and later. +Author: Andy Whitcroft <a...@ubuntu.com> + +Index: flashcache-3.1.3+git20150701/src/flashcache_subr.c +=== +--- flashcache-3.1.3+git20150701.orig/src/flashcache_subr.c flashcache-3.1.3+git20150701/src/flashcache_subr.c +@@ -739,6 +739,7 @@ flashcache_bio_endio(struct bio *bio, in + #elif LINUX_VERSION_CODE < KERNEL_VERSION(4,3,0) + bio_endio(bio, error); + #else ++ bio->bi_error = error; + bio_endio(bio); + #endif + } diff -Nru flashcache-3.1.3+git20150701/debian/patches/series flashcache-3.1.3+git20150701/debian/patches/series --- flashcache-3.1.3+git20150701/debian/patches/series 2015-12-25 03:59:22.0 + +++ flashcache-3.1.3+git20150701/debian/patches/series 2016-01-27 16:27:07.0 + @@ -1,3 +1,4 @@ usable-makefile.patch honor-cflags-and-ldflags.patch fix-build-error-on-linux-4.3.patch +record-bio-error-on-linux-4.3.patch
Bug#812347: rsibreak: No systemtrayicon available
Package: rsibreak Version: 4:0.11-4 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Simply running the software * What was the outcome of this action? The program reported "No systemtrayicon available" thereby making it unconfigurable. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.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 rsibreak depends on: ii kde-runtime4:15.08.3-1 ii libc6 2.21-6 ii libkdecore54:4.14.14-1+b1 ii libkdeui5 4:4.14.14-1+b1 ii libkidletime4 4:4.14.14-1+b1 ii libkio54:4.14.14-1+b1 ii libknotifyconfig4 4:4.14.14-1+b1 ii libplasma3 4:4.14.14-1+b1 ii libqt4-dbus4:4.8.7+dfsg-5 ii libqtcore4 4:4.8.7+dfsg-5 ii libqtgui4 4:4.8.7+dfsg-5 ii libstdc++6 5.3.1-5 ii libx11-6 2:1.6.3-1 rsibreak recommends no packages. rsibreak suggests no packages. -- no debconf information
Bug#804457: imapfilter: Uses SSLv3 method
Package: imapfilter Version: 1:2.6.2-1 Followup-For: Bug #804457 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu xenial ubuntu-patch Dear Maintainer, We recently have disabled SSLv3 in Ubuntu as part of testing that we found that imapfilter coredumped on startup. Looking at Debian we see that it is being disabled there such that imapfilter will no longer build. For Ubuntu we are applying the attached patch which follows the recommendation in this Bug and as such should fix the issue in Debian also: * Switch to using SSLv23_client_method in all cases to avoid using now removed/nutered protocols and increasing forward compatibility. (LP: #1516585). Thanks for considering the patch. -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial-proposed'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-19-generic (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) diff -Nru imapfilter-2.6.2/debian/patches/series imapfilter-2.6.2/debian/patches/series --- imapfilter-2.6.2/debian/patches/series 2015-01-05 18:29:14.0 + +++ imapfilter-2.6.2/debian/patches/series 2015-11-16 12:53:46.0 + @@ -1 +1,2 @@ fix-makefile.diff +ubuntu-switch-to-SSLv23_client_method-and-use-CTX-options-to-select-protocol.patch diff -Nru imapfilter-2.6.2/debian/patches/ubuntu-switch-to-SSLv23_client_method-and-use-CTX-options-to-select-protocol.patch imapfilter-2.6.2/debian/patches/ubuntu-switch-to-SSLv23_client_method-and-use-CTX-options-to-select-protocol.patch --- imapfilter-2.6.2/debian/patches/ubuntu-switch-to-SSLv23_client_method-and-use-CTX-options-to-select-protocol.patch 1970-01-01 01:00:00.0 +0100 +++ imapfilter-2.6.2/debian/patches/ubuntu-switch-to-SSLv23_client_method-and-use-CTX-options-to-select-protocol.patch 2015-11-16 13:29:59.0 + @@ -0,0 +1,125 @@ +Description: switch to SSLv23_client_method() and use CTX options to select protocol + With us disabling SSLv3 we now either will not build (on Debian) or + coredump during initialisation. As per the Debian bug recommendation + switch to always using SSLv23_client_method() as that can handle the best + protocol available (including TLS etc) going forward. Where we need to + specify a specific protocol start using SSL_CTS_set_options() to limit + the negociable protocols. +Author: Andy Whitcroft <a...@ubuntu.com> +Bug-Debian: https://bugs.debian.org/804457 +Bug-Ubuntu: https://launchpad.net/bugs/1516585 + +Index: imapfilter-2.6.2/src/imapfilter.c +=== +--- imapfilter-2.6.2.orig/src/imapfilter.c imapfilter-2.6.2/src/imapfilter.c +@@ -21,10 +21,7 @@ + + extern buffer ibuf, obuf, nbuf, cbuf; + extern regexp responses[]; +-extern SSL_CTX *ssl3ctx, *ssl23ctx, *tls1ctx; +-#if OPENSSL_VERSION_NUMBER >= 0x01000100fL +-extern SSL_CTX *tls11ctx, *tls12ctx; +-#endif ++extern SSL_CTX *ssl23ctx; + + options opts; /* Program options. */ + environment env; /* Environment variables. */ +@@ -109,25 +106,13 @@ main(int argc, char *argv[]) + + SSL_library_init(); + SSL_load_error_strings(); +- ssl3ctx = SSL_CTX_new(SSLv3_client_method()); + ssl23ctx = SSL_CTX_new(SSLv23_client_method()); +- tls1ctx = SSL_CTX_new(TLSv1_client_method()); +-#if OPENSSL_VERSION_NUMBER >= 0x01000100fL +- tls11ctx = SSL_CTX_new(TLSv1_1_client_method()); +- tls12ctx = SSL_CTX_new(TLSv1_2_client_method()); +-#endif + + if (exists_dir(opts.truststore)) + capath = opts.truststore; + if (exists_file(opts.truststore)) + cafile = opts.truststore; +- SSL_CTX_load_verify_locations(ssl3ctx, cafile, capath); + SSL_CTX_load_verify_locations(ssl23ctx, cafile, capath); +- SSL_CTX_load_verify_locations(tls1ctx, cafile, capath); +-#if OPENSSL_VERSION_NUMBER >= 0x01000100fL +- SSL_CTX_load_verify_locations(tls11ctx, cafile, capath); +- SSL_CTX_load_verify_locations(tls12ctx, cafile, capath); +-#endif + + start_lua(); + #if LUA_VERSION_NUM < 502 +@@ -146,13 +131,7 @@ main(int argc, char *argv[]) + #endif + stop_lua(); + +- SSL_CTX_free(ssl3ctx); + SSL_CTX_free(ssl23ctx); +- SSL_CTX_free(tls1ctx); +-#if OPENSSL_VERSION_NUMBER >= 0x01000100fL +- SSL_CTX_free(tls11ctx); +- SSL_CTX_free(tls12ctx); +-#endif + ERR_free_strings(); + + regexp_free(responses); +Index: imapfilter-2.6.2/src/socket.c +=== +--- imapfilter-2.6.2.orig/src/socket.c imapfilter-2.6.2/src/socket.c +@@ -17,11 +17,7 @@ + #include "session.h" + + +-SSL_CTX *ssl3ctx, *ssl23ctx, *tls1ctx; +-#if OPENSSL_VERSION_NUMBER >= 0x01000100fL +-SSL_CTX *tls11ctx, *tls12ctx; +-#endif +- ++SSL_CTX *ssl23ctx; + + /* + * Connect to mai
Bug#801106: sddm-greeter fails to start
Many thanks Didi, I can confirm that workaround "adduser sddm video" fixed the problem.
Bug#801106: sddm-greeter fails to start
Package: sddm Version: 0.12.0-4 Severity: critical Justification: breaks the whole system Dear Maintainer, * What led up to the situation? Reboot after installing nvidia 340.93-3 (latest testing version). I had tried stopping sddm; rmmod nvidia; and restarting again ... got the sddm-greeter would not start error and hoped a reboot would fix. The only way I could get a working plasma5 was to install and use lightdm/lightdm-kde-greeter. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.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 sddm depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.57 ii libc6 2.19-22 ii libgcc1 1:5.2.1-17 ii libpam0g 1.1.8-3.1 ii libqt5core5a 5.4.2+dfsg-9 ii libqt5dbus5 5.4.2+dfsg-9 ii libqt5gui55.4.2+dfsg-9 ii libqt5network55.4.2+dfsg-9 ii libqt5qml55.4.2-6 ii libqt5quick5 5.4.2-6 ii libstdc++65.2.1-17 ii libsystemd0 226-3 ii libxcb-xkb1 1.10-3+b1 ii libxcb1 1.10-3+b1 ii qml-module-qtquick2 5.4.2-6 ii sddm-theme-breeze [sddm-theme]4:5.4.1-1 ii sddm-theme-circles [sddm-theme] 0.12.0-4 ii sddm-theme-elarun [sddm-theme]0.12.0-4 ii sddm-theme-maldives [sddm-theme] 0.12.0-4 ii sddm-theme-maui [sddm-theme] 0.12.0-4 sddm recommends no packages. Versions of packages sddm suggests: ii libpam-kwallet5 5.4.1-1 -- debconf information excluded
Bug#797131: udev kernel check during Wheezy-Jessie upgrade should happen earlier
Package: udev Version: 175-7.2 Severity: serious Justification: Policy 7.2 Dear Maintainer, * What led up to the situation? Upgrading my armhf system Wheezy-Jessie. Did the usual searches for dependencies and what-not. Did a pre-download, then ran the upgrade. About half the packages were churned, and then udev declares: Since release 198, udev requires support for the following features in the running kernel: - inotify(2)(CONFIG_INOTIFY_USER) - signalfd(2) (CONFIG_SIGNALFD) - accept4(2) - open_by_handle_at(2) (CONFIG_FHANDLE) - timerfd_create(2) (CONFIG_TIMERFD) - epoll_create(2) (CONFIG_EPOLL) Please upgrade your kernel before or while upgrading udev. and the upgrade fails. I'd be happy to reconfigure my kernel, but with half my files upgraded and the other half not, my system was not well enough to do anything. * What exactly did you do (or not do) that was effective (or ineffective)? I'm not an idiot; I had a full backup and restored my system. * What was the outcome of this action? Failed upgrade. New required kernel features (it'd be nice if that was listed somewhere). * What outcome did you expect instead? If the kernel is not acceptable for the upgrade, it should be detected before the upgrade starts. The kernel check should not happen after the filesystem has been modified with some upgraded content. An upgrade should never start if it can be determined that it can't complete successfully. -- System Information: Debian Release: 7.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: armhf (armv7l) Kernel: Linux 3.4.75+ (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages udev depends on: ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-38+deb7u8 ii libgcc11:4.7.2-5 ii libselinux12.1.9-5 ii libudev0 175-7.2 ii lsb-base 4.1+Debian8+deb7u1 ii procps 1:3.3.3-3 ii util-linux 2.20.1-5.3 Versions of packages udev recommends: ii pciutils 1:3.1.9-6 ii usbutils 1:005-3 udev suggests no packages. -- debconf information: udev/new_kernel_needed: false udev/title/upgrade: udev/reboot_needed: udev/sysfs_deprecated_incompatibility:
Bug#790859: avogadro: Patch for FTBFS against updated cmake
Package: avogadro
Version: 1.1.0-4
Followup-For: Bug #790859
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu wily ubuntu-patch
Dear Maintainer,
While fixing gcc-5 related fallout the following patch was needed for
avogadro to handle a semantic change in newer cmake. cmake QT search et al
no longer automatically loads X11 detection we have to probe it explicitly.
Thanks for considering the patch.
-apw
-- System Information:
Debian Release: jessie/sid
APT prefers wily-updates
APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'),
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.1.0-3-generic (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)
diff -Nru avogadro-1.1.1/debian/patches/probe-X11-paths-with-find_package.patch avogadro-1.1.1/debian/patches/probe-X11-paths-with-find_package.patch
--- avogadro-1.1.1/debian/patches/probe-X11-paths-with-find_package.patch 1970-01-01 01:00:00.0 +0100
+++ avogadro-1.1.1/debian/patches/probe-X11-paths-with-find_package.patch 2015-08-10 20:56:07.0 +0100
@@ -0,0 +1,17 @@
+Description: probe X11 paths with find_package(X11)
+ cmake no longer automatically probes for X11 when probling for QT et al.
+ We now need to manually load X11 when needed.
+Author: Andy Whitcroft a...@ubuntu.com
+
+Index: avogadro-1.1.1/avogadro/src/CMakeLists.txt
+===
+--- avogadro-1.1.1.orig/avogadro/src/CMakeLists.txt
avogadro-1.1.1/avogadro/src/CMakeLists.txt
+@@ -107,6 +107,7 @@ if(QtTesting)
+ target_link_libraries(avogadro-app QtTesting)
+ endif()
+ if(Q_WS_X11)
++ find_package(X11 REQUIRED)
+ target_link_libraries(avogadro-app ${X11_X11_LIB})
+ endif()
+
diff -Nru avogadro-1.1.1/debian/patches/series avogadro-1.1.1/debian/patches/series
--- avogadro-1.1.1/debian/patches/series 2014-02-12 11:09:50.0 +
+++ avogadro-1.1.1/debian/patches/series 2015-08-10 20:57:49.0 +0100
@@ -1,2 +1,3 @@
link_to_libgl2ps.patch
boost148.patch
+probe-X11-paths-with-find_package.patch
Bug#790012: gcalcli: Fails to run giving error report.
Package: gcalcli Version: 3.3-1 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Running `gcalcli` from the command line. * What was the outcome of this action? An error message: ERROR: Missing module - cannot import name GoogleCredentials then the program exited. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-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 gcalcli depends on: ii python2.7.9-1 ii python-dateutil 2.2-2 ii python-gflags 1.5.1-2 ii python-googleapi 1.4.0-1 Versions of packages gcalcli recommends: ii gxmessage 2.20.0-1 ii python-parsedatetime 1.4-1 ii python-simplejson 3.7.3-1 ii python-vobject0.8.1c-4 gcalcli suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785091: spatialite-bin: spatialite gives a Segmentation fault.
Sorry Bas, Version: 4.1.1-5 now in testing does not fix the problem. Segmentation fault still occurs. Andy. This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785091: spatialite-bin: spatialite gives a Segmentation fault.
Hi Sebastiaan, On Tuesday 12 May 2015 12:03:43 Sebastiaan Couwenberg wrote: Control: tags -1 confirmed Hi Andy, Thanks for reporting this issue. I can confirm the issue in unstable. A gdb run shows: Starting program: /usr/bin/spatialite [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. 0x7787fff4 in spatialite_init () from /usr/lib/x86_64-linux-gnu/libspatialite.so.5 Justification: breaks unrelated software This justification is not supported by your bugreport. Which unrelated software does this issue break? Sorry, perhaps this is not unrelated, but ogr2ogr -a_srs WGS84 -f SQLite -dsco SPATIALITE=YES \ -where 'PTT=143471' -nln 143471 -append \ wcp_2015.sqlite wcp.xml Segfaults too. Andy. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785091: spatialite-bin: spatialite gives a Segmentation fault.
Package: spatialite-bin Version: 4.1.1-4+b1 Severity: critical Justification: breaks unrelated software Dear Maintainer, * What led up to the situation? Recent testing update. * What exactly did you do (or not do) that was effective (or ineffective)? Simply type the command `spatialite` * What was the outcome of this action? Segfault -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-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 spatialite-bin depends on: ii libc6 2.19-18 ii libexpat1 2.1.0-6+b3 ii libfreexl1 1.0.1-2 ii libgeos-c1 3.4.2-7 ii libproj94.9.1-1 ii libreadline66.3-8+b3 ii libreadosm1 1.0.0d-1 ii libspatialite5 4.1.1-10+b1 ii libsqlite3-03.8.9-2 ii zlib1g 1:1.2.8.dfsg-2+b1 spatialite-bin recommends no packages. spatialite-bin suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749698: libmusicbrainz5 / bug 749698
Hi, On 11/11/2014 19:25, Daniel Pocock wrote: This is a release critical bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749698 Do you know if it is completely fixed upstream? Is this version of libmusicbrainz5 suitable for the jessie release or are you aware of any other potential RC bugs that should also be corrected at the same time? There is a pull request available for upstream. I haven't got round to adding it because it needs an SOVERSION bump, so should probably make this libmb5.1.0 to reflect this. Comments appreciated. Andy -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762638: metaconfig source control/distribution and Debian's DFSG
On Sat, Oct 04, 2014 at 05:50:51PM +0100, Dominic Hargreaves wrote: On Thu, Sep 25, 2014 at 09:07:59PM -0400, Andy Dougherty wrote: On Thu, Sep 25, 2014 at 10:16:32PM +0100, Dominic Hargreaves wrote: The way it's set up now, we encourage people to simply patch Configure. If someone wants to go the metaconfig route instead, it's a lot of extra work, but presumably the person deliberately chooses that route knowing it's extra work. Again, there is an ideological point here. It *shouldn't* be a lot of extra work to do things in the way that upstream developers would. Clearly perl isn't going to be kicked out of Debian because of this, but a less important package might well be. I think we may have confused you here such that you have it exactly backwards. It *isn't* a lot of extra work for anyone to do things in the way the upstream developers would. Everyone has access to the exact same source. What a few upstream developers do have is *experience* using the package, so that they can do that work somewhat more easily. Those few upstream developers (well, really only H.Merijn these days) have volunteered to help do that work for people who would rather spend their time fixing something else rather than learning a complete configuration system. Thus if a casual hacker wants to make a simple Configure change, they can simply make it directly to Configure. Thus it is *easier* for the casual hacker to get involved. If they want to do it the way the upstream developer would, then they have to do the same hard work that the upstream deveveloper does, and they are certainly free to do so. Both the dist subversion repository and the perl metaconfig git repository are freely available, so anyone can check out the appropriate versions to recreate Configure (subject to machine-dependent ordering). I hadn't realized that the precise versions used weren't clearly labeled because I don't recall anybody ever asking before. Encouraged by this request, I will try to remember and document that more clearly in perl's documentation. If someone else wants to do it first, the patches would certainly be welcome. Okay, so clearly from a pragmatic view we would need to ship our own version of dist along with the rest of the stuff from the metaconfig repository. Depressingly this violates another part of Debian policy relating to embedding copies of code not intended to be embedded, but the freedom to modify the code using the preferred form clearly overrides that in my mind. You could instead separately package dist-3.5.20 and depend on that, if you liked. (Presumably, that package would point to the standard 'dist' package as the recommended starting point for new projects, and would not overwrite the standard 'dist' package files.) I don't see how this situation is fundamentally any different from that of any other program built with a particular version of an external tool (such as bison, for example). Rebuilding Configure would not be easy or automatic, but all the necessary files would be available. Would that satisfy the Debian guidelines? I think it would satisfy the letter of the law, if not the full spirit. I'm sorry, but I really fail to see why, and suspect that there is a lingering misunderstanding. Rebuilding Configure is not easy or automatic for *anyone*, but that's not an issue of freedom. I want to be helpful and share what we have, but we can only share what we have. Cheers, -- Andy Dougherty dough...@lafayette.edu -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750255: lio-utils: FTBFS: chmod: cannot access '/«BUILDDIR»/lio-utils-3.1+git2.fd0b34fd/debian/lio-utils/usr/share/pyshared/*.py': No such file or directory
On 09/21/2014 12:36 AM, Ritesh Raj Sarraf wrote:
On Saturday 20 September 2014 03:23 PM, Jerome Martin wrote:
Yes, the problem is that the kernel side uses this path unfortunately.
We could relocate policy and fabric to /var/lib/target, but that would
mean keeping both /lib/target and /var/target around for now, as the
kernel will use that for storing alua metadata in /var/target/alua.
However, what about relocating now, and keeping around a symlink to
/var/target, created in post-install?
This way, as soon as Nic can push the relocation to /var/lib/alua, we
are ready and just have to remove the symlink from packaging.
I am cc'ing the ML on this one.
The manpage, written by Andy, refers to /var/lib/. Which would imply
that Fedora/RHEL and all its derivatives must be using the new path.
I don't see any mention of /var/lib. In any case, RH packaging isn't
creating /var/target/{alua,pr} directories, whose absence will cause PR
ops to fail in 3.11+-based kernels even if they don't use APTPL. I need
to fix that soon.
If I came up with a kernel patch that made the path that ALUA PR files
were written to settable via configfs, would that also be helpful to you?
Nick, thoughts?
Regards -- Andy
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754294: Kernel release
Hi, Do any of the recent 'official' kernels have the fix for this bug? I've applied all the latest security updates, but I'm still seeing a similar issue whereby I have to reduce the MTU on all my internal PCs to 1492 to get decent throughput. Thanks Andy -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733361: libsmi: FTBFS: parser-smi.c:3093:7: error: too few arguments to function 'smilex'
Package: libsmi
Version: 0.4.8+dfsg2-8
Followup-For: Bug #733361
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following to
fix an FTBFS:
* lib/parser/smi{,ng}.y: follow change from *_PARAM to %*-param.
* lib/parser/smi{,ng}.y: follow yyerror() parameterisation changes.
Thanks for considering the patch.
-apw
-- System Information:
Debian Release: jessie/sid
APT prefers trusty-updates
APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500,
'trusty'), (100, 'trusty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13.0-25-generic (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
diff -Nru libsmi-0.4.8+dfsg2/debian/changelog libsmi-0.4.8+dfsg2/debian/changelog
diff -Nru libsmi-0.4.8+dfsg2/debian/patches/bison-follow-parameter-handling-changes.patch libsmi-0.4.8+dfsg2/debian/patches/bison-follow-parameter-handling-changes.patch
--- libsmi-0.4.8+dfsg2/debian/patches/bison-follow-parameter-handling-changes.patch 1970-01-01 01:00:00.0 +0100
+++ libsmi-0.4.8+dfsg2/debian/patches/bison-follow-parameter-handling-changes.patch 2014-04-17 00:43:27.0 +0100
@@ -0,0 +1,75 @@
+Description: follow flex parameter specification change
+ Follow change from *_PARAM to %*-param after deprecation in flex.
+ Follow yyerror() parameterisation changes.
+Author: Andy Whitcroft a...@canonical.com
+
+Index: libsmi-0.4.8+dfsg2/lib/parser-smi.y
+===
+--- libsmi-0.4.8+dfsg2.orig/lib/parser-smi.y 2014-04-16 23:49:33.0 +0100
libsmi-0.4.8+dfsg2/lib/parser-smi.y 2014-04-17 00:31:50.152357333 +0100
+@@ -11,6 +11,9 @@
+ * @(#) $Id: parser-smi.y 8090 2008-04-18 12:56:29Z strauss $
+ */
+
++%parse-param { struct Parser *parserPtr }
++%lex-param { struct Parser *parserPtr }
++
+ %{
+
+ #include config.h
+@@ -43,14 +46,6 @@
+
+
+
+-/*
+- * These arguments are passed to yyparse() and yylex().
+- */
+-#define YYPARSE_PARAM parserPtr
+-#define YYLEX_PARAM parserPtr
+-
+-
+-
+ #define thisParserPtr ((Parser *)parserPtr)
+ #define thisModulePtr (((Parser *)parserPtr)-modulePtr)
+
+Index: libsmi-0.4.8+dfsg2/lib/parser-sming.y
+===
+--- libsmi-0.4.8+dfsg2.orig/lib/parser-sming.y 2014-04-16 23:49:33.0 +0100
libsmi-0.4.8+dfsg2/lib/parser-sming.y 2014-04-17 00:31:41.288357640 +0100
+@@ -11,6 +11,9 @@
+ * @(#) $Id: parser-sming.y 7966 2008-03-27 21:25:52Z schoenw $
+ */
+
++%parse-param { struct Parser *parserPtr }
++%lex-param { struct Parser *parserPtr }
++
+ %{
+
+ #include config.h
+@@ -48,13 +51,6 @@
+ #endif
+
+
+-/*
+- * These arguments are passed to yyparse() and yylex().
+- */
+-#define YYPARSE_PARAM parserPtr
+-#define YYLEX_PARAM parserPtr
+-
+-
+
+ #define thisParserPtr ((Parser *)parserPtr)
+ #define thisModulePtr (((Parser *)parserPtr)-modulePtr)
+Index: libsmi-0.4.8+dfsg2/lib/error.h
+===
+--- libsmi-0.4.8+dfsg2.orig/lib/error.h 2014-04-17 00:36:14.684348162 +0100
libsmi-0.4.8+dfsg2/lib/error.h 2014-04-17 00:36:31.740347571 +0100
+@@ -22,7 +22,7 @@
+ #ifdef yyerror
+ #undef yyerror
+ #endif
+-#define yyerror(msg) smiyyerror(msg, parserPtr)
++#define yyerror(parserPtr, msg) smiyyerror(msg, parserPtr)
+
+
+ extern int smiErrorLevel; /* Higher levels produce more warnings */
diff -Nru libsmi-0.4.8+dfsg2/debian/patches/series libsmi-0.4.8+dfsg2/debian/patches/series
--- libsmi-0.4.8+dfsg2/debian/patches/series 2013-10-27 21:27:03.0 +
+++ libsmi-0.4.8+dfsg2/debian/patches/series 2014-04-17 00:44:37.0 +0100
@@ -3,3 +3,4 @@
cve-2010-2891.patch
libsmi-format.patch
segfault-bug600076.patch
+bison-follow-parameter-handling-changes.patch
Bug#731848: CVE request for remote code execution in ack
On Dec 10, 2013, at 8:00 AM, Axel Beckert a...@debian.org wrote: It would be nice if you could add the CVE-ID to the Changes file of ack retroactively as soon as it's known so that it's part of the Changes file in further ack releases. OK. Just help me through this and I’ll do what needs to be done. I’m glad to do whatever is necessary to help y’all. xoa -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Bug#731848: CVE request for remote code execution in ack
On Dec 10, 2013, at 7:46 AM, Axel Beckert a...@debian.org wrote: Hi, as discussed with Salvatore Bonaccorso of the Debian Security Team (team cc'ed), I'm herewith requesting a CVE ID for the following security issue in ack (http://beyondgrep.com/, also known as ack-grep in multiple distributions; upstream developer cc'ed): Is there anything you need me to do? -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Bug#669878: Reproduced 669878 - Could not perform immediate configuration on 'phonon-backend-vlc'
Ran into this problem today at the cambridge BSP when performing a dist-upgrade from squeeze. again the reported problem was: E: Could not perform immediate configuration on 'phonon-backend-vlc'. Please see man 5 apt.conf under APT::Immediate-Configure for details. I performed apt-get upgrade as reccomended then tried dist-upgrade again still failing with the same error I got out of the problem by apt-get install apt initramfs-tools nfs-common where initramfs-tools nfs-common were required to be upgraded because of increased dependancy requirements. I guess this doesn't help resolve the bug, but at least shows that it is reproduceable. BR Andy NOTE: CC'd to debian-release at request of JMW as this will affect dist- upgrades for kde users -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666170: Patch for kpathsea API change
We are using the below patch in Ubuntu to handle the kpathsea5 - kpathsea6 transition. Please consider for debian. -apw diff -u ptex-bin-3.1.11+0.04b/debian/rules ptex-bin-3.1.11+0.04b/debian/rules --- ptex-bin-3.1.11+0.04b/debian/rules +++ ptex-bin-3.1.11+0.04b/debian/rules @@ -68,6 +68,12 @@ patch -p0 -d $(TETEX_SRC_DIR)/texk/web2c/$(PTEX_SRC_DIR)/$(JMPOST_SRC_DIR) $$f ; \ done) + # Apply patches to web2c source (should be named as *.patch) + # Put patches in debian/patches/web2c. + (for f in debian/patches/web2c/*.patch ; do \ + patch -p0 -d $(TETEX_SRC_DIR)/texk/web2c/ $$f ; \ + done) + # Copy texmf.cnf from your system. cp /usr/share/texmf/web2c/texmf.cnf \ $(TETEX_SRC_DIR)/texk/web2c/$(PTEX_SRC_DIR)/texmf.cnf.orig diff -u ptex-bin-3.1.11+0.04b/debian/changelog ptex-bin-3.1.11+0.04b/debian/changelog --- ptex-bin-3.1.11+0.04b/debian/changelog +++ ptex-bin-3.1.11+0.04b/debian/changelog @@ -1,3 +1,13 @@ +ptex-bin (3.1.11+0.04b-0.2ubuntu1) quantal; urgency=low + + * Track changes to libkpathsea6 API. + - program_invocation_name - kpse_invocation_name + * Fix link order for -l options on splitup. + * Add support for patches to web2c. + * Sort out now removed kpse_set_prog_name. + + -- Andy Whitcroft a...@ubuntu.com Thu, 21 Jun 2012 16:53:16 +0100 + ptex-bin (3.1.11+0.04b-0.2) unstable; urgency=low * Non-maintainer upload. diff -u ptex-bin-3.1.11+0.04b/debian/patches/teTeX/splitup.c.patch ptex-bin-3.1.11+0.04b/debian/patches/teTeX/splitup.c.patch --- ptex-bin-3.1.11+0.04b/debian/patches/teTeX/splitup.c.patch +++ ptex-bin-3.1.11+0.04b/debian/patches/teTeX/splitup.c.patch @@ -6,7 +6,7 @@ -char *program_invocation_name; +#include kpathsea/types.h -+ ++#define program_invocation_name kpse_invocation_name int filenumber = 0, ifdef_nesting = 0, lines_in_file = 0; char *output_name = NULL; boolean has_ini; only in patch2: unchanged: --- ptex-bin-3.1.11+0.04b.orig/debian/patches/pteextra.c-kpse-program-name.patch +++ ptex-bin-3.1.11+0.04b/debian/patches/pteextra.c-kpse-program-name.patch @@ -0,0 +1,11 @@ +--- ptexextra.c-orig 2012-06-22 11:18:23.626189357 -0400 ptexextra.c2012-06-22 11:18:26.586189199 -0400 +@@ -19,6 +19,8 @@ + #include kpathsea/variable.h + #include kpathsea/absolute.h + ++#define program_invocation_name kpse_invocation_name ++ + #include time.h /* For `struct tm'. */ + #if defined (HAVE_SYS_TIME_H) + #include sys/time.h only in patch2: unchanged: --- ptex-bin-3.1.11+0.04b.orig/debian/patches/jmpost/jmpextra-program-invocation-name.patch +++ ptex-bin-3.1.11+0.04b/debian/patches/jmpost/jmpextra-program-invocation-name.patch @@ -0,0 +1,10 @@ +--- jmpextra.c-orig2012-06-23 05:30:06.171064994 -0400 jmpextra.c 2012-06-23 05:33:12.679067745 -0400 +@@ -26,6 +26,7 @@ + #include kpathsea/readable.h + #include kpathsea/variable.h + #include kpathsea/absolute.h ++#define program_invocation_name kpse_invocation_name + + #include time.h /* For `struct tm'. */ + #if defined (HAVE_SYS_TIME_H) only in patch2: unchanged: --- ptex-bin-3.1.11+0.04b.orig/debian/patches/web2c/cpascal.h-kpse_set_program_name.patch +++ ptex-bin-3.1.11+0.04b/debian/patches/web2c/cpascal.h-kpse_set_program_name.patch @@ -0,0 +1,11 @@ +--- cpascal.h-orig 2012-06-22 11:38:30.326205966 -0400 cpascal.h 2012-06-22 11:46:03.626209807 -0400 +@@ -199,7 +199,7 @@ + #define kpsefindtfm kpse_find_tfm + #define kpsefindvfkpse_find_vf + #define kpseinitprog kpse_init_prog +-#define kpsesetprogname kpse_set_progname ++#define kpsesetprogname(x) kpse_set_program_name(x, nil) + #define kpsesetprogramname kpse_set_program_name + #define kpseresetprogramname kpse_reset_program_name + #define kpsegfformat kpse_gf_format only in patch2: unchanged: --- ptex-bin-3.1.11+0.04b.orig/debian/patches/teTeX/splitup-makefile.patch +++ ptex-bin-3.1.11+0.04b/debian/patches/teTeX/splitup-makefile.patch @@ -0,0 +1,11 @@ +--- texk/web2c/web2c/Makefile.in-orig 2012-06-22 10:56:39.694171478 -0400 texk/web2c/web2c/Makefile.in 2012-06-22 10:56:59.354164389 -0400 +@@ -37,7 +37,7 @@ + fixwrites: fixwrites.o kps.o + $(build_link_command) fixwrites.o kps.o + splitup: splitup.o kps.o +- $(build_link_command) -lkpathsea splitup.o kps.o ++ $(build_link_command) splitup.o kps.o -lkpathsea + regfix: regfix.o kps.o + $(build_link_command) regfix.o kps.o + -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676484: Reproducing issue
Hi, Is there any chance you can make this FLAC file available so that I can try to reproduce this? Cheers Andy -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676484: Update
Hi, Never mind, managed to reproduce it here. Working on it now. Andy -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666565: /usr/lib/libreoffice/program/soffice: Menu items are not displayed with cairo 1.12
Package: libcairo2 Version: 1.12.0-2 Followup-For: Bug #666565 Same problem here (similar to Luca Tettamanti's screenshot) with several applications. I've noticed it in Epiphany, Nautilus and gnome-terminal. It's most severe using Gmail in Epiphany, I guess because that involves a lot of text redrawing. The problem occurs with libcairo2 1.12.0-2, but not after downgrading libcairo2, libcairo2-dev, libcairo-gobject2 and libcairo-script-interpreter2 to 1.10.2-7. Using xserver-xorg-video-radeon 1:6.14.3-2. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libcairo2 depends on: ii libc6 2.13-27 ii libfontconfig1 2.8.0-3.1 ii libfreetype6 2.4.9-1 ii libpixman-1-0 0.24.4-1 ii libpng12-0 1.2.47-2 ii libx11-6 2:1.4.4-4 ii libxcb-render0 1.8.1-1 ii libxcb-shm01.8.1-1 ii libxcb11.8.1-1 ii libxrender11:0.9.6-2 ii multiarch-support 2.13-27 ii zlib1g 1:1.2.6.dfsg-2 libcairo2 recommends no packages. libcairo2 suggests no packages. -- no debconf information -- debsums errors found: debsums: package libcairo2 is not installed -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516560: freeguide in Debian
Hi Steve, On Sat, 3 Mar 2012 20:42:21 + Steve McIntyre st...@einval.com wrote: 2 years on, no sign of an upload. Should we RM this package? It has become clear to me that I don't have time to be FreeGuide's Debian maintainer. The problem is fixed in recent (last several years!) FreeGuide - we just need a new version to be uploaded. Thanks, Andy -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619423: SUPPLY Graphite from China
To Whom it may concern I am Andy from TEHNGSHENG INTERNATIONAL GROUP LIMITED. We supply many kinds of Graohite : Main:Natural flake graphite,amorphous graphite if you are interest our product, i will porvide the more details information We have the big powerful factory in China, and we cooperate with them to develop the minerals and keep long-term strategy business cooperation. We expect that our products could attract your attention. For more information, please view our website: www.tshengintl.com or view www.ec21.com search our company name Hope we can build a good business relationship in the near future. Looking forward to hearing from you soon Best Regards Andy
Bug#649459: workaround
The workaround is to add: const Shell = imports.gi.Shell; to the top of /usr/share/gnome-shell/js/ui/windowManager.js Sjoerd will have a new package out later today, hopefully. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542285: debian packages of guile 1.9/2.0
Hi, On Sat 17 Jul 2010 14:50, l...@gnu.org (Ludovic Courtès) writes: Andy Wingo wi...@pobox.com writes: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542285. Is there any chance you could prod those folks? Ludo, can we get libgc people to help? Yes, the Debian folks just need to report upstream, if that’s not already done, and they’ll probably quickly get an answer. FWIW, people have been meaning to release libgc 7.2 for a while, which may fix the problem (and optionally add other problems ;-)). Copying the Debian libgc maintainer, then. With a report upstream, hopefully the libgc people can handle the Debian FTBFS problem themselves :) Andy -- http://wingolog.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576339: libgnutls26: impacts telepathy-gabble 0.9.8-1 ssl / tls connections
Package: libgnutls26 Version: 2.9.9-1 Severity: normal i had also noticed problems in empathy with ssl tls connections after upgrading to telepathy-gabble 0.9.8-1. after downgrading these issues went away. sounds like it might already be at least partially diagnosed, but if it's helpful there is some additional information in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548280#37 thank you! -- System Information: Debian Release: squeeze/sid APT prefers experimental APT policy: (999, 'experimental'), (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-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 Versions of packages libgnutls26 depends on: ii libc6 2.11-0exp6 Embedded GNU C Library: Shared lib ii libgcrypt11 1.4.5-2 LGPL Crypto library - runtime libr ii libgpg-error0 1.6-1library for common error values an ii libtasn1-3 2.5-1Manage ASN.1 structures (runtime) ii zlib1g 1:1.2.3.5.dfsg-1 compression library - runtime libgnutls26 recommends no packages. Versions of packages libgnutls26 suggests: ii gnutls-bin2.8.6-1the GNU TLS library - commandline -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516560: freeguide in Debian
Hi Vincent, Vincent Bernat wrote: It seems that you are willing to fix #516560 affecting freeguide. Since you get no answer from Daniel, feel free to prepare an NMU. I will upload it. Do not make invasive changes in packaging since this is an NMU. Would this need to be a patch against 0.10.9 that contained only the relevant fix, or could it be a package of the latest version (0.10.11)? I am not a Debian developer. I have made deb packages, but I am a beginner and would need some help in preparing an NMU. Would you be available to answer questions for me? Thanks, Andy -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b79764b.9080...@artificialworlds.net
Bug#516560: Fixed in 0.10.11
This is fixed in 0.10.11. The latest released version is 0.10.12, which also contains the fix. Daniel, are you still maintaining this package? I know you suggested before that I might become the maintainer. Perhaps we should start that process if you don't have the time to do it. Thanks, Andy -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516560: freeguide: Contains precompiled libraries without source
at least /usr/share/freeguide/lib/retroweaver-rt-1.2.5.jar and /usr/share/freeguide/lib/tagsoup-1.0.1.jar is shipped as part of the source and installed directly without any recompilation. Both of these jars have no been removed from the install, and there are no others. This change will ship in version 0.10.11 which I hope to release in the next few days. Thanks for submitting this report. Andy -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553109: guile-gnutls: postinst-must-call-ldconfig /usr/lib/libguile-gnutls-v-1.so.0.0.0 by the dynamic library loader. Therefore, the package must call ldconfig in its postinst script.
Hi, On Fri 30 Oct 2009 22:14, Neil Jerram n...@ossau.uklinux.net writes: Is it still the case that we recommend guile extensions to be installed as normal libraries in /usr/lib, as opposed to some guile-specific place? I think you were recently discussing this, and I'm afraid I didn't pay complete attention. In the alpha 1.9 series you can install them to extensiondir. From NEWS: ** Dynamically loadable extensions may be placed in a Guile-specific path Before, Guile only searched the system library paths for extensions (e.g. /usr/lib), which meant that the names of Guile extensions had to be globally unique. Installing them to a Guile-specific extensions directory is cleaner. Use `pkg-config --variable=extensionsdir guile-2.0' to get the location of the extensions directory. (Historically this has cropped up several times. Marius favoured /usr/lib on the grounds that it could make sense for some application to use a Guile extension library just like a normal C library (i.e. application coded in C, linking at build time to the extension library and to libguile). But on the other hand the advantage of somewhere like /usr/lib/guile-1.8 is that it makes it easier to handle parallel installation, and corresponding correct version numbering, without having to have .so names that have both libguile and extension version numbers in. I think the balance goes for parallel installation -- that is, installing in guile-specific directories. However we do support dynamically loaded extensions in $libdir as well, for backwards compatibility. Also I'm not sure it's portable to have a shared module and be able to link to it. Andy -- http://wingolog.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
Or should nis say it provides nis as well as what it currently says it provides or instead of? I think using LDAP as a Network Information Service (see RFC2307) may be relevant here. I don't know whether that's possible on Linux at the moment but I would guess that if it is (or ever will be) then it may not involve ypbind. So perhaps that's pointing towards /etc/init.d/nis saying it provides nis and that /etc/init.d/autofs depends on nis if it's installed. And then ldap as a Network Information Service could say it provides nis. Just a thought. -- Andy, BlueArc Engineering -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
Having applied your patch to autofs and reenabling insserv, I had to reinstall
portmap to get its links in /etc/rc*d so that when nis started, the portmapper
was enabled.
Once I'd done that, autofs is still starting before nis:
ws-andyc-debian64:~# ls /etc/rc*d/*{nis,autofs}
/etc/rc0.d/K01autofs /etc/rc2.d/S15nis /etc/rc4.d/S15nis
/etc/rc1.d/K01autofs /etc/rc3.d/S02autofs /etc/rc5.d/S02autofs
/etc/rc1.d/K01nis /etc/rc3.d/S15nis /etc/rc5.d/S15nis
/etc/rc2.d/S02autofs /etc/rc4.d/S02autofs /etc/rc6.d/K01autofs
It's not clear to me from man insserv whether that's OK or not. It could be
that Should-Start: is taken care of when autofs is started. Having thought
about that, that would mean that whatever nis is dependent on would also need
starting before nis is started and that would lead to working out dependencies
on the fly: that seems counter to the purpose of creating the links in the
respective directories in the first place so that cannot be right. So there
must be something else awry.
I did try reinstalling nis to see whether that would help (it didn't).
--
Andy, BlueArc Engineering
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541349: insserv sets the start up link for autofs to S01autofs
having had a look at /etc/init.d/nis, I see it says:
# Provides: ypbind ypserv ypxfrd yppasswdd
So, I thought perhaps autofs shouldn't say nis in Should-Start but should say
ypbind. Having done that and rerun insserv, the start files look ok:
ws-andyc-debian64:~# ls /etc/rc*d/*{nis,autofs}
/etc/rc0.d/K01autofs /etc/rc2.d/S16autofs /etc/rc4.d/S16autofs
/etc/rc1.d/K01autofs /etc/rc3.d/S15nis /etc/rc5.d/S15nis
/etc/rc1.d/K01nis /etc/rc3.d/S16autofs /etc/rc5.d/S16autofs
/etc/rc2.d/S15nis /etc/rc4.d/S15nis /etc/rc6.d/K01autofs
So, is that the right thing to do? Or should nis say it provides nis as well as
what it currently says it provides or instead of?
--
Andy, BlueArc Engineering
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540804: kdelibs5: undefined symbol error in kio_http
Package: kdelibs5 Version: 4:4.3.0-1 Severity: grave Justification: renders package unusable When attemping to use ktorrent or konqueror, the following shows up in my ..xsession-errors log, and the io slave can't be loaded: kdeinit4: preparing to launch Could not open library '/usr/lib/kde4/kio_http.so'. Cannot load library /usr/lib/kde4/kio_http.so: (/usr/lib/kde4/kio_http.so: undefined symbol: _ZN11KGzipFilterC1Ev) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29.2 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kdelibs5 depends on: ii dbus-x11 1.2.12-1 simple interprocess messaging syst ii debconf [debconf-2.0] 1.5.26Debian configuration management sy ii kdelibs-bin4:4.3.0-1 executables for all KDE 4 core app ii kdelibs5-data 4:4.3.0-1 core shared data for all KDE 4 app ii libacl12.2.47-2 Access control list shared library ii libaspell150.60.6-1 GNU Aspell spell-checker runtime l ii libattr1 1:2.4.43-2Extended attribute shared library ii libbz2-1.0 1.0.5-1 high-quality block-sorting file co ii libc6 2.9-9 GNU C Library: Shared libraries ii libenchant1c2a 1.4.2-3.3 a wrapper library for various spel ii libfam02.7.0-13.3Client library to control the FAM ii libgcc11:4.3.3-8 GCC support library ii libgif44.1.6-6 library for GIF images (library) ii libgssapi-krb5-2 1.7dfsg~beta3-1 MIT Kerberos runtime libraries - k ii libice62:1.0.5-1 X11 Inter-Client Exchange library ii libilmbase61.0.1-3 several utility libraries from ILM ii libjasper1 1.900.1-5.1 The JasPer JPEG-2000 runtime libra ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libopenexr61.6.1-4 runtime files for the OpenEXR imag ii libpcre3 7.8-2+b1 Perl 5 Compatible Regular Expressi ii libphonon4 4:4.5.2-1 Qt 4 Phonon module ii libpng12-0 1.2.35-1 PNG library - runtime ii libqt4-dbus4:4.5.2-1 Qt 4 D-Bus module ii libqt4-designer4:4.5.2-1 Qt 4 designer module ii libqt4-network 4:4.5.2-1 Qt 4 network module ii libqt4-qt3support 4:4.5.2-1 Qt 3 compatibility library for Qt ii libqt4-script 4:4.5.2-1 Qt 4 script module ii libqt4-svg 4:4.5.2-1 Qt 4 SVG module ii libqt4-xml 4:4.5.2-1 Qt 4 XML module ii libqtcore4 4:4.5.2-1 Qt 4 core module ii libqtgui4 4:4.5.2-1 Qt 4 GUI module ii libsm6 2:1.1.0-2 X11 Session Management library ii libsoprano42.3.0+dfsg.1-2libraries for the Soprano RDF fram ii libstdc++6 4.3.3-8 The GNU Standard C++ Library v3 ii libstreamanalyzer0 0.6.5-1 streamanalyzer library for Strigi ii libx11-6 2:1.2.1-1 X11 client-side library ii libxcursor11:1.1.9-1 X cursor management library ii libxfixes3 1:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxml22.7.3.dfsg-1 GNOME XML library ii libxrender11:0.9.4-2 X Rendering Extension client libra ii libxslt1.1 1.1.24-2 XSLT processing library - runtime ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension ii shared-mime-info 0.60-2FreeDesktop.org shared MIME databa ii xauth 1:1.0.3-2 X authentication utility ii xdg-utils 1.0.2-6.1 desktop integration utilities from ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime Versions of packages kdelibs5 recommends: ii kaboom1.1.0 The Debian KDE settings migration ii kdebase-runtime 4:4.3.0-2 runtime components from the offici ii ttf-dejavu2.29-2 Metapackage to pull in ttf-dejavu- Versions of packages kdelibs5 suggests: ii hspell1.0-4 Hebrew spell checker and morpholog -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527739: 'Uncaught exception:' on aptitude startup
Package: aptitude Version: 0.5.2.1-1 Severity: normal i started receiving this error when attempting to launch aptitude: Uncaught exception: ./generic/problemresolver/choice.h:294: const typename PackageUniverse::version generic_choicePackageUniverse::get_ver() const [with PackageUniverse = aptitude_universe]: Assertion tp == install_version failed. i can toggle this behavior by adding the suggested lines from /usr/share/doc/ia32-apt-get/NEWS.Debian.gz to /etc/apt/preferences. with those lines aptitude crashes on startup. without them it will start. i have attached my /etc/apt/preferences and output from `apt-cache policy`. thank you! andy -- Package-specific info: aptitude 0.5.2.1 compiled at Apr 27 2009 11:46:07 Compiler: g++ 4.3.3 Compiled against: apt version 4.6.0 NCurses version 5.7 libsigc++ version: 2.0.18 Ept support enabled. Current library versions: NCurses version: ncurses 5.7.20090523 cwidget version: 0.5.12 Apt version: 4.6.0 linux-vdso.so.1 = (0x7fff275ff000) libapt-pkg-libc6.9-6.so.4.7 = /usr/lib/libapt-pkg-libc6.9-6.so.4.7 (0x00398e00) libncursesw.so.5 = /lib/libncursesw.so.5 (0x0038dce0) liblog4cxx.so.10 = /usr/lib/liblog4cxx.so.10 (0x0030d980) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0x00399040) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x00398d00) libept.so.0 = /usr/lib/libept.so.0 (0x0033eb20) libxapian.so.15 = /usr/lib/libxapian.so.15 (0x0033eb60) libz.so.1 = /usr/lib/libz.so.1 (0x0033eae0) libpthread.so.0 = /lib/libpthread.so.0 (0x7f4f1f02b000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f4f1ed1d000) libm.so.6 = /lib/libm.so.6 (0x7f4f1ea9a000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7f4f1e88) libc.so.6 = /lib/libc.so.6 (0x7f4f1e52f000) libutil.so.1 = /lib/libutil.so.1 (0x7f4f1e32c000) libdl.so.2 = /lib/libdl.so.2 (0x7f4f1e128000) libaprutil-1.so.0 = /usr/lib/libaprutil-1.so.0 (0x0030d900) libapr-1.so.0 = /usr/lib/libapr-1.so.0 (0x0030d940) libuuid.so.1 = /lib/libuuid.so.1 (0x003a7620) librt.so.1 = /lib/librt.so.1 (0x7f4f1df2) libcrypt.so.1 = /lib/libcrypt.so.1 (0x7f4f1dce8000) /lib64/ld-linux-x86-64.so.2 (0x7f4f1f246000) libexpat.so.1 = /usr/lib/libexpat.so.1 (0x0038d220) Terminal: xterm $DISPLAY is set. `which aptitude`: /usr/bin/aptitude aptitude version information: aptitude linkage: -- System Information: Debian Release: squeeze/sid APT prefers experimental APT policy: (999, 'experimental'), (990, 'unstable'), (400, 'unstable-i386'), (400, 'testing-i386') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-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 Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6. 0.7.21Advanced front-end for dpkg ii apt-xapian-index 0.20 maintenance tools for a Xapian ind ii libc6 2.9-18GNU C Library: Shared libraries ii libcwidget30.5.12-4 high-level terminal interface libr ii libept00.5.26+b1 High-level library for managing De ii libgcc11:4.4.0-10GCC support library ii liblog4cxx10 0.10.0-1 A logging library for C++ ii libncursesw5 5.7+20090523-1shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.2.2-1 type-safe Signal Framework for C++ ii libstdc++6 4.4.0-10 The GNU Standard C++ Library v3 ii libxapian151.0.13-3 Search engine library ii zlib1g 1:1.2.3.3.dfsg-14 compression library - runtime Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.5.2.1-1 English manual for aptitude, a ter ii libparse-debianchangelog-perl 1.1.1-2parse Debian changelogs and output Versions of packages aptitude suggests: pn debtags none (no description available) ii tasksel 2.79 Tool for selecting tasks for insta -- no debconf information Package files: 100 /var/lib/dpkg/status release a=now 990 http://ftp.debian-unofficial.org sid/non-free Packages release o=Debian Unofficial,a=unstable,l=Debian Unofficial,c=non-free origin ftp.debian-unofficial.org 990 http://ftp.debian-unofficial.org sid/contrib Packages release o=Debian Unofficial,a=unstable,l=Debian Unofficial,c=contrib origin ftp.debian-unofficial.org 990 http://ftp.debian-unofficial.org sid/main Packages release o=Debian Unofficial,a=unstable,l=Debian Unofficial,c=main origin ftp.debian-unofficial.org -1 http://security.us.debian.org testing/updates/non-free Packages
Bug#518862: vino: listening on :5900 even though /desktop/gnome/remote_access/enabled=false
Package: vino Version: 2.24.1-2 Severity: normal i can confirm this behavior. the gconf key /desktop/gnome/remote_access/enabled is set to false but a vino-server process is running and listening on port 5900. i do not have vino-server in my ~/.gnome2/session. to mitigate this i set /desktop/gnome/remote_access/local_only to true so it listens to localhost only. -- System Information: Debian Release: squeeze/sid APT prefers experimental APT policy: (999, 'experimental'), (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.29-rc6-686 (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 Versions of packages vino depends on: ii gconf2 2.24.0-7 GNOME configuration database syste ii libavahi-client3 0.6.24-2 Avahi client library ii libavahi-common3 0.6.24-2 Avahi common library ii libavahi-glib1 0.6.24-2 Avahi glib integration library ii libc6 2.9-4 GNU C Library: Shared libraries ii libdbus-1-31.2.12-1 simple interprocess messaging syst ii libdbus-glib-1-2 0.80-3simple interprocess messaging syst ii libgconf2-42.24.0-7 GNOME configuration database syste ii libgcrypt111.4.4-2 LGPL Crypto library - runtime libr ii libglade2-01:2.6.3-1 library to load .glade files at ru ii libglib2.0-0 2.19.10-1 The GLib library of C routines ii libgnome2-02.24.1-2 The GNOME 2 library - runtime file ii libgnomeui-0 2.24.1-1 The GNOME 2 libraries (User Interf ii libgnutls262.6.3-1 the GNU TLS library - runtime libr ii libgtk2.0-02.15.5-2 The GTK+ graphical user interface ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libnotify1 [libnotify1 0.4.5-1 sends desktop notifications to a n ii libunique-1.0-01.0.4-1 Library for writing single instanc ii libx11-6 2:1.1.99.2-1 X11 client-side library ii libxdamage11:1.1.1-4 X11 damaged region extension libra ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime Versions of packages vino recommends: ii gvfs 1.0.3-2userspace virtual filesystem - ser Versions of packages vino suggests: ii gnome-user-guide [gnome2-user 2.24.2-2 GNOME user's guide ii vinagre 2.24.2-2 VNC client for the GNOME Desktop -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496678: nautilus: Fails to start
Package: nautilus Version: 2.20.0-6 Severity: grave Justification: renders package unusable Clicking Home desktop icon results in 'Starting file browser..' button being displayed in bottom panel, but application window does not appear and button eventually disappears from panel. Typing 'nautilus' or 'nautilus --no-desktop' in terminal simply sits there and nothing happens at all. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nautilus depends on: ii desktop-file-utils 0.15-1 Utilities for .desktop files ii gnome-control-cente 1:2.22.2.1-1 utilities to configure the GNOME d ii libart-2.0-22.3.20-2 Library of functions for 2D graphi ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libbonobo2-02.22.0-1 Bonobo CORBA interfaces library ii libc6 2.7-13 GNU C Library: Shared libraries ii libcairo2 1.6.4-6 The Cairo 2D vector graphics libra ii libeel2-2.202.20.0-7 Eazel Extensions Library (for GNOM ii libesd0 0.2.36-3 Enlightened Sound Daemon - Shared ii libexempi3 2.0.1-1 library to parse XMP metadata (Lib ii libexif12 0.6.16-2.1 library to parse EXIF files ii libgail-common 1.22.3-1 GNOME Accessibility Implementation ii libgail18 1.22.3-1 GNOME Accessibility Implementation ii libgconf2-4 2.22.0-1 GNOME configuration database syste ii libglade2-0 1:2.6.2-1library to load .glade files at ru ii libglib2.0-02.16.4-2 The GLib library of C routines ii libgnome-desktop-2 2.22.3-1 Utility library for loading .deskt ii libgnome2-0 2.20.1.1-1 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.20.1.1-1 A powerful object-oriented display ii libgnomeui-02.20.1.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.22.0-4 GNOME Virtual File System (runtime ii libgtk2.0-0 2.12.11-3The GTK+ graphical user interface ii libnautilus-extensi 2.20.0-6 libraries for nautilus components ii liborbit2 1:2.14.13-0.1libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.20.5-1 Layout and rendering of internatio ii librsvg2-2 2.22.2-2 SAX-based renderer library for SVG ii libselinux1 2.0.65-2 SELinux shared libraries ii libstartup-notifica 0.9-1library for program launch feedbac ii libtrackerclient0 0.6.6-2 metadata database, indexer and sea ii libx11-62:1.1.4-2X11 client-side library ii libxml2 2.6.32.dfsg-2+lenny1 GNOME XML library ii nautilus-data 2.20.0-6 data files for nautilus ii shared-mime-info0.30-2 FreeDesktop.org shared MIME databa Versions of packages nautilus recommends: ii app-install-data2008.07.28 Application Installer Data Files ii desktop-base4.0.7common files for the Debian Deskto ii eject 2.1.5+deb1-1 ejects CDs and operates CD-Changer ii libgnomevfs2-extra 1:2.22.0-4 GNOME Virtual File System (extra m ii librsvg2-common 2.22.2-2 SAX-based renderer library for SVG ii nautilus-cd-burner 2.20.0-1 CD Burning front-end for Nautilus ii synaptic0.62.1 Graphical package manager Versions of packages nautilus suggests: ii eog 2.22.3-1 Eye of GNOME graphics viewer progr ii evince [pdf-viewer] 2.22.2-2 Document (postscript, pdf) viewer pn fam none (no description available) ii totem 2.22.2-3 A simple media player for the GNOM pn tracker none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473050: tkdiff: Error in startup script
Does running tkdiff with a specific version of tcl/tk help - i.e. if
you edit /usr/bin/tkdiff and change /usr/bin/wish to say
/usr/bin/wish8.4 ?
Yes, that works! Good workaround for now, thanks.
I've just tried running it here under 8.5 and it started up fine using
.tkdiff of:
set opts(textopt) {-background white -foreground gray -font 6x13 -wrap none}
Uhm, no, that doesn't work here.
condor:~head -5 /usr/bin/tkdiff.broken
#!/usr/bin/wish8.5
###
#
# TkDiff -- A graphical front-end to diff for Unix and Windows.
condor:~cat .tkdiffrc
set opts(textopt) {-background white -foreground gray -font 6x13 -wrap none}
condor:~/usr/bin/tkdiff.broken foo bar
Error in startup script: expected integer but got bold
(processing -font option)
invoked from within
.client.left.text tag configure inlinetag -background DodgerBlue -font
{TkFixedFont bold}
(eval body line 1)
invoked from within
eval $widget tag configure $tag $opts($tag)
(procedure build-client line 106)
invoked from within
build-client
(procedure create-display line 40)
invoked from within
create-display
(procedure main line 57)
invoked from within
main
(file /usr/bin/tkdiff.broken line 9519)
Thanks,
Andy.
--
Having trouble in Windows - reboot
Having trouble in linux - be root
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473050: tkdiff: Error in startup script
# Text widget options
-define textopt {-background white -foreground gray -font 6x13 -wrap none}
+define textopt {-background white -foreground gray -font {Courier -12
bold} -wrap none}
Thanks, but uhm, it doesn't help here. After patching .tkdiffrc
I still get:
Error in startup script: expected integer but got bold
(processing -font option)
invoked from within
.client.left.text tag configure inlinetag -background DodgerBlue -font
{TkFixedFont bold}
(eval body line 1)
invoked from within
eval $widget tag configure $tag $opts($tag)
(procedure build-client line 106)
invoked from within
build-client
(procedure create-display line 40)
invoked from within
create-display
(procedure main line 57)
invoked from within
main
(file /usr/bin/tkdiff line 9519)
Thanks,
Andy.
--
Absence is to love what wind is to fire.
It extinguishes the small, it enkindles the great.
signature.asc
Description: Digital signature
Bug#473050: tkdiff: Error in startup script
Package: tkdiff
Version: 1:4.1.3-1
Severity: grave
Justification: renders package unusable
tkdiff doesn't start anymore. It just throws this error:
condor:~tkdiff foo bar
Error in startup script: expected integer but got bold
(processing -font option)
invoked from within
.client.left.text tag configure inlinetag -background DodgerBlue -font
{TkFixedFont bold}
(eval body line 1)
invoked from within
eval $widget tag configure $tag $opts($tag)
(procedure build-client line 106)
invoked from within
build-client
(procedure create-display line 40)
invoked from within
create-display
(procedure main line 57)
invoked from within
main
(file /usr/bin/tkdiff line 9519)
Deleting my .tkdiffrc doesn't change this behavior either.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (900, 'unstable'), (400, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.23.1 (SMP w/2 CPU cores; PREEMPT)
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-1) (ignored:
LC_ALL set to de_DE)
Shell: /bin/sh linked to /bin/bash
Versions of packages tkdiff depends on:
ii tk8.3 8.3.5-12 Tk toolkit for Tcl and X11, v8.3 -
ii tk8.4 8.4.18-1 Tk toolkit for Tcl and X11, v8.4 -
tkdiff recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#195969: Need your help!
Hi there, my name's Alena. I'm from Russia, 29 years old. Please vote for my profile at site: http://foreigngals.info/?idAff=35 Thank You Very Much!!! Alena -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459017: Could not read file Error writing to the port. Olympus SP510-UZ
Subject: gphoto2: Olympus SP510-UZ Could not read file Error writing to the
port.
Package: gphoto2
Version: 2.2.0-3
Severity: grave
Justification: renders package unusable
*** Please type your report below this line ***
Error connecting Olympus SP510-UZ to Debian Etch KDE.
On plugging the camera in and OK-ing the connection (on the camera menu),
Konqueror attempts to initialize the camera (camera light flashing) for a
while, then stops with the error window:
Could not read file Error writing to the port.
Same problem using the 486 kernel. But Kubuntu 6.06 on the same PC still works.
env LANG=C gphoto2 --debug --auto-detect -L contains the following:
0.471941 gphoto2-port(2): Setting settings...
10.472577 gphoto2-port(0): Could not set config 0/1 (Connection timed
out)
10.472814 sierra/sierra.c(2): Operation failed (-37)!
10.472930 gphoto2-port(2): Closing port...
10.473038 gphoto2-port(0): Could not release interface 0 (Invalid
argument).
10.473206 context(0): An error occurred in the io-library ('Error
updating the port settings'): Could not release interface 0 (Invalid
argument).
*** Error ***
An error occurred in the io-library ('Error updating the port
settings'): Could not release interface 0 (Invalid argument).
*** Error (-37: 'Error updating the port settings') ***
I have found a similar error at the KDE bug site, Bug 153716: Digikam does not
work with Olympus C-170 CAMEDIA camera, but I am not using Digikam. The
diagnostic above suggests a gphoto2 problem.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Versions of packages gphoto2 depends on:
ii libc6 2.3.6.ds1-13etch4 GNU C Library: Shared libraries
ii libcdk55.0.20050424-2C-based curses widget library
ii libexif12 0.6.13-5etch1 library to parse EXIF files
ii libgphoto2-2 2.2.1-16 gphoto2 digital camera library
ii libgphoto2-port0 2.2.1-16 gphoto2 digital camera port librar
ii libjpeg62 6b-13 The Independent JPEG Group's JPEG
ii libncurses55.5-5 Shared libraries for terminal hand
ii libpopt0 1.10-3lib for parsing cmdline parameters
ii libreadline5 5.2-2 GNU readline and history libraries
gphoto2 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451297: linux-image-2.6.18-5-xen-686: kernel page allocation failure causes networking freeze
: Normal: empty Nov 14 18:57:58 corona kernel: HighMem: 1353*4kB 1691*8kB 439*16kB 129*32kB 17*64kB 8*128kB 4*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 33228kB Nov 14 18:57:58 corona kernel: Swap cache: add 23, delete 0, find 0/0, race 0+0 Nov 14 18:57:58 corona kernel: Free swap = 1975580kB Nov 14 18:57:58 corona kernel: Total swap = 1975672kB Nov 14 18:57:58 corona kernel: Free swap: 1975580kB Nov 14 18:57:58 corona kernel: 238592 pages of RAM Nov 14 18:57:58 corona kernel: 52226 pages of HIGHMEM Nov 14 18:57:58 corona kernel: 19812 reserved pages Nov 14 18:57:58 corona kernel: 146572 pages shared Nov 14 18:57:58 corona kernel: 23 pages swap cached Nov 14 18:57:58 corona kernel: 10 pages dirty Nov 14 18:57:58 corona kernel: 0 pages writeback Nov 14 18:57:58 corona kernel: 2949 pages mapped Nov 14 18:57:58 corona kernel: 19722 pages slab Nov 14 18:57:58 corona kernel: 254 pages pagetables This will scroll by for a few minutes during which time networking is completely frozen. The server is usable over serial console but no networking takes place at all. Finally after a few minutes the server comes back to life, network-wise. This will reoccur every couple of hours forcing an eventual reboot. I don't know where to start debugging this, but it only has started happening with linux-image-2.6.18-5-xen-686. I will try downgrading back to linux-image-2.6.18-4-xen-686 just to see if the problem goes away. The dom0 is using the stock debian Xen packages, and dom0_mem kernel command line was used to give dom0 1G RAM. When the above is occuring, top does not suggest that the server is running out of RAM or swap. The usual bridged networking setup is in place. If you need any more information I will be happy to provide. This was also reported in the Xen bugzilla when it last happened: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1097 but as I've had no response to that at all I figured I'd try Debian this time :) Cheers, Andy -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-xen-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-5-xen-686 depends on: ii initramfs-tools0.85h tools for generating an initramfs ii linux-modules-2.6. 2.6.18.dfsg.1-13etch4 Linux 2.6.18 modules on i686 Versions of packages linux-image-2.6.18-5-xen-686 recommends: ii libc6-xen 2.3.6.ds1-13etch2 GNU C Library: Shared libraries [X -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421534: wordpress: New 2.0.10 release claims to fix security issues, should be in stable security updates
Package: wordpress Version: 2.0.9-1 Severity: grave Tags: security Justification: user security hole The upstream 2.0.10 release notes claim that it fixes security problems, especially with the XML-RPC module. The diff applies cleanly to the packaged files, and appears to run fine on my machine. Suggest update. The diff: svn diff http://svn.automattic.com/wordpress/tags/2.0.9/ http://svn.automattic.com/wordpress/tags/2.0.10/ -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-386 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages wordpress depends on: ii apache2-mpm-prefork [htt 2.2.3-4 Traditional model for Apache HTTPD ii libapache2-mod-php4 6:4.4.4-8+etch2 server-side, HTML-embedded scripti ii mysql-client-5.0 [virtua 5.0.32-7etch1 mysql database client binaries ii php4-mysql 6:4.4.4-8+etch2 MySQL module for php4 wordpress recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
