Bug#823026: exmh: default configuration wants to play sounds through mailcap -- which often fails
Package: exmh Version: 1:2.8.0-5 Severity: normal I've run into this problem numerous times when setting up a new computer, and usually I'm in such a hurry to get my email working that I just hackishly work around it and don't investigate what's going on. This time I had some energy/time, so here goes: On my latest attempt at setting up exmh on a computer, I had the "sox" package installed, which sets up "/usr/bin/play -t au %s" as the default mailcap that exmh wants to use to play "drip.au" 12 times (for 12 folders with unseen messages, IIUC). However, that hangs on the first "drip" if exmh is run in the background because the "play" command wants stdin/stdout. Maybe a separate bug is in order to "sox" to fix their /usr/lib/mime/packages/ file. However, when I deleted sox , and removed all mention of it from /etc/mailcap, the problem got worse, as exmh then tries to start up my video player app (!) 12 times to play drip.au . In that case, exmh isn't usable until I close the video-player app 12 times. My thinking is that /usr/bin/run-mailcap can't really be relied on to play audiofiles in a way that makes sense for what exmh wants to do here, and that exmh's default behavior should be to not attempt this (or find a different way). (It seems like what exmh wants here is something like "audio/basic/no-interface" in mailcap -- does mailcap have something like that"?) -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (990, 'stable'), (990, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages exmh depends on: ii mime-support3.59 ii nmh [mh]1.5-release-0.2 ii tcl8.4 [tclsh] 8.4.19-5 ii tcl8.5 [tclsh] 8.5.11-2 ii tk8.4 [wish]8.4.19-5 ii xterm 278-4 Versions of packages exmh recommends: pn recode Versions of packages exmh suggests: pn compface pn expect ii file 1:5.22+15-2+deb8u1 ii gnupg 1.4.12-7+deb7u6 pn mh-book -- no debconf information
Bug#775369: e17: Upstream version
Package: e17 Version: 0.17.6-1 Followup-For: Bug #775369 Dear Maintainer, I'd like to enqueue in that a new Enlightenment version should be made avaiable to the Debian users. There is already Enlightenment version 0.20 avaiable and it would be very nice to have that avaiable from Debian repositories. I'm using Enlightenment version 0.17 since it is avaiable within Debian and like to note what usable and great window manager it became. For all those of us for those GNOME does not offer enough features and options one has to reach for an alternative such as Enlightenment. Thank you very much for your efforts! With many greetings, Adrian Immanuel Kieß http://www.immanuelK.net -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages e17 depends on: ii dbus-x11 1.10.8-1 ii e17-data 0.17.6-1 ii libasound2 1.1.0-1 ii libc6 2.22-7 ii libdbus-1-31.10.8-1 ii libecore-con1 1.8.6-2.5+b1 ii libecore-evas1 1.8.6-2.5+b1 ii libecore-file1 1.8.6-2.5+b1 ii libecore-imf1 1.8.6-2.5+b1 ii libecore-input11.8.6-2.5+b1 ii libecore-ipc1 1.8.6-2.5+b1 ii libecore-x11.8.6-2.5+b1 ii libecore1 1.8.6-2.5+b1 ii libedbus1 1.7.10-1 ii libedje-bin1.8.6-2.5+b1 ii libedje1 1.8.6-2.5+b1 ii libeet11.8.6-2.5+b1 ii libeeze1 1.8.6-2.5+b1 ii libefreet-bin 1.8.6-2.5+b1 ii libefreet1a1.8.6-2.5+b1 ii libeina1 1.8.6-2.5+b1 ii libeio11.8.6-2.5+b1 ii libevas1 1.8.6-2.5+b1 ii libevas1-engines-x [libevas1-engine-software-x11] 1.8.6-2.5+b1 ii libpam0g 1.1.8-3.2 ii libxcb-keysyms10.4.0-1 ii libxcb-shape0 1.11.1-1 ii libxcb11.11.1-1 Versions of packages e17 recommends: ii pm-utils 1.4.1-16 e17 suggests no packages. -- no debconf information
Bug#801226: duck: add support for reporting redirects to other domains
skainz wrote on IRC: > hi. i am currently working on #801226. As i am not a native speaker, > i have a hard time handling https->http redirects within the same > domain. What should the information text be? "https->http redirects > are insecure?" this does not seem to get the grip of it Probably something like this: O: debian/control: Homepage: https://example.org: Secure URL redirects to an insecure URL (Certainty:certain) -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#823025: libqtpropertybrowser4-dev: missing Breaks+Replaces: libqtpropertybrowser3-dev (<< 4)
Package: libqtpropertybrowser4-dev Version: 4.0.0~beta-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'jessie'. It installed fine in 'jessie', then the upgrade to 'stretch' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces >From the attached log (scroll to the bottom...): Selecting previously unselected package libqtpropertybrowser4-dev. Preparing to unpack .../libqtpropertybrowser4-dev_4.0.0~beta-1_amd64.deb ... Unpacking libqtpropertybrowser4-dev (4.0.0~beta-1) ... dpkg: error processing archive /var/cache/apt/archives/libqtpropertybrowser4-dev_4.0.0~beta-1_amd64.deb (--unpack): trying to overwrite '/usr/include/qtpropertybrowser/QtDatePropertyManager', which is also in package libqtpropertybrowser3-dev 3.3.2-2 cheers, Andreas libqtpropertybrowser3-dev=3.3.2-2_libqtpropertybrowser4-dev=4.0.0~beta-1.log.gz Description: application/gzip
Bug#822866: new vips lets nip2 fail to build
Control: tags -1 + confirmed pending Hi Matthias, On Thu, Apr 28, 2016 at 4:30 PM, Matthias Klose wrote: > 8.2-1 breaks the nip2 build, apparently not having a new dependency in the > -dev package: Thanks for watching over my shoulders. Upstream is going to release VIPS 8.3.1 with bugfixes in the next few days. I'll update the dependencies with that upload. Regards, Laszlo/GCS
Bug#822976: gtk3-engines-unico: Package broken by GTK 3.16
Hi, Since newer GTK versions have already made it into the archive, does that mean that this package no longer serves any purpose? From what I can tell, GTK3 engines for Breeze and Xfce still exist elsewhere in the archive: https://packages.debian.org/search?keywords=gtk3-engines- If this inevitably ends with Unico being removed, I guess I'm okay with that too. What might be the best course of action here? Best, James signature.asc Description: OpenPGP digital signature
Bug#821463: NOT fixed in chromium-browser 50.0.2661.75-2
This bug is not the same as bug 821154 and is not yet fixed. Still "Aw snap " when using gmail. The bug does not appear on chromium (50.0.2661.75-1~deb8u1) [security].
Bug#340531: need guidance
I choose this as my first bug , now I am confused where to start debugging it
Bug#822188: Thanks
Thank you very much. Best regards
Bug#823024: ntp: add AppArmor support
Package: ntp
Severity: wishlist
Tags: patch
Hi,
Picking up from downstream, please consider to add AppArmor support.
Patch attached, thanks.
--
Regards,
Hideki Yamane henrich @ debian.or.jp/org
http://wiki.debian.org/HidekiYamane
diff -Nru ntp-4.2.8p7+dfsg/debian/README.Debian ntp-4.2.8p7+dfsg/debian/README.Debian
--- ntp-4.2.8p7+dfsg/debian/README.Debian 2016-04-29 02:53:23.0 +0900
+++ ntp-4.2.8p7+dfsg/debian/README.Debian 2016-04-30 13:14:46.0 +0900
@@ -110,3 +110,12 @@
of these keys has not yet been tested; please report success or
failure in using them to the maintainer.
+
+Apparmor Profile
+
+
+If your system uses AppArmor, please note that the shipped enforcing profile
+works with the default installation, and changes in your configuration may
+require changes to the installed apparmor profile. Please see
+https://wiki.ubuntu.com/DebuggingApparmor before filing a bug against this
+software.
diff -Nru ntp-4.2.8p7+dfsg/debian/apparmor-profile ntp-4.2.8p7+dfsg/debian/apparmor-profile
--- ntp-4.2.8p7+dfsg/debian/apparmor-profile 1970-01-01 09:00:00.0 +0900
+++ ntp-4.2.8p7+dfsg/debian/apparmor-profile 2016-04-08 05:12:38.0 +0900
@@ -0,0 +1,82 @@
+# vim:syntax=apparmor
+# Updated for Ubuntu by: Jamie Strandboge
+# --
+#
+#Copyright (C) 2002-2005 Novell/SUSE
+#Copyright (C) 2009-2012 Canonical Ltd.
+#
+#This program is free software; you can redistribute it and/or
+#modify it under the terms of version 2 of the GNU General Public
+#License published by the Free Software Foundation.
+#
+# --
+
+#include
+#include
+/usr/sbin/ntpd {
+ #include
+ #include
+ #include
+
+ capability ipc_lock,
+ capability net_bind_service,
+ capability setgid,
+ capability setuid,
+ capability sys_chroot,
+ capability sys_resource,
+ capability sys_time,
+ capability sys_nice,
+
+ # ntp uses AF_INET, AF_INET6 and AF_UNSPEC
+ network dgram,
+ network stream,
+
+ @{PROC}/net/if_inet6 r,
+ @{PROC}/*/net/if_inet6 r,
+ @{NTPD_DEVICE} rw,
+ # pps devices are almost exclusively used with NTP
+ /dev/pps[0-9]* rw,
+
+ /{,s}bin/ r,
+ /usr/{,s}bin/ r,
+ /usr/sbin/ntpd rmix,
+
+ /etc/ntp.conf r,
+ /etc/ntp.conf.dhcp r,
+ /etc/ntpd.conf r,
+ /etc/ntpd.conf.tmp r,
+ /var/lib/ntp/ntp.conf.dhcp r,
+
+ /etc/ntp.keys r,
+ /etc/ntp/** r,
+
+ /etc/ntp.drift rwl,
+ /etc/ntp.drift.TEMP rwl,
+ /etc/ntp/drift* rwl,
+ /var/lib/ntp/*drift rw,
+ /var/lib/ntp/*drift.TEMP rw,
+
+ /var/log/ntp w,
+ /var/log/ntp.log w,
+ /var/log/ntpd w,
+ /var/log/ntpstats/clockstats* rwl,
+ /var/log/ntpstats/loopstats* rwl,
+ /var/log/ntpstats/peerstats* rwl,
+ /var/log/ntpstats/protostats* rwl,
+ /var/log/ntpstats/rawstats* rwl,
+ /var/log/ntpstats/sysstats* rwl,
+
+ /{,var/}run/ntpd.pid w,
+
+ # samba4 ntp signing socket
+ /{,var/}run/samba/ntp_signd/socket rw,
+
+ # For use with clocks that report via shared memory (e.g. gpsd),
+ # you may need to give ntpd access to all of shared memory, though
+ # this can be considered dangerous. See https://launchpad.net/bugs/722815
+ # for details. To enable, add this to local/usr.sbin.ntpd:
+ # capability ipc_owner,
+
+ # Site-specific additions and overrides. See local/README for details.
+ #include
+}
diff -Nru ntp-4.2.8p7+dfsg/debian/apparmor-profile.tunable ntp-4.2.8p7+dfsg/debian/apparmor-profile.tunable
--- ntp-4.2.8p7+dfsg/debian/apparmor-profile.tunable 1970-01-01 09:00:00.0 +0900
+++ ntp-4.2.8p7+dfsg/debian/apparmor-profile.tunable 2016-02-11 20:09:07.0 +0900
@@ -0,0 +1,15 @@
+# vim:syntax=apparmor
+# --
+#
+#Copyright (C) 2002-2005 Novell/SUSE
+#Copyright (C) 2011 Canonical, Ltd.
+#
+#This program is free software; you can redistribute it and/or
+#modify it under the terms of version 2 of the GNU General Public
+#License published by the Free Software Foundation.
+#
+# --
+
+#Add your ntpd devices here eg. if you have a DCF clock
+# @{NTPD_DEVICE}="/dev/ttyS1"
+@{NTPD_DEVICE}="/dev/null"
diff -Nru ntp-4.2.8p7+dfsg/debian/changelog ntp-4.2.8p7+dfsg/debian/changelog
--- ntp-4.2.8p7+dfsg/debian/changelog 2016-04-30 01:32:55.0 +0900
+++ ntp-4.2.8p7+dfsg/debian/changelog 2016-04-30 13:15:09.0 +0900
@@ -1,3 +1,10 @@
+ntp (1:4.2.8p7+dfsg-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * enable Apparmor profile from Ubuntu
+
+ -- Hideki Yamane Sat, 30 Apr 2016 13:14:50 +0900
+
ntp (1:4.2.8p7+dfsg-2) unstable; urgency=medium
* Only build-depend on pps-tools on Linux
diff -Nru ntp-4.2.8p7+dfsg/debian/rules ntp-4.2.8p7+dfsg/debian/rules
--- ntp-4.2.8p7+dfsg/debian/rules 2016-04-29 04:49:02.0 +0900
+++ ntp-4.2.8p7+dfsg/debian/rules 2016-04-
Bug#823023: ITP: codequery -- code-understanding, code-browsing or code-search tool.
Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: codequery Version : 0.16.0 Upstream Author : opyright (C) 2013 ruben2020 https://github.com/ruben2020/ * URL : https://github.com/ruben2020/codequery * License : GPL-3 Programming Lang: C++ Description : code-understanding, code-browsing or code-search tool. This is a tool to index, then query or search C, C++, Java, Python, Ruby, Go and Javascript source code. . It builds upon the databases of cscope and Exuberant ctags. . The databases of cscope and ctags would be processed by the cqmakedb tool to generate the CodeQuery database file. . The CodeQuery database file can be viewed and queried using the codequery GUI tool. -- ChangZhuo Chen (陳昌倬) Debian Developer (https://nm.debian.org/public/person/czchen) Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B signature.asc Description: PGP signature
Bug#823022: linux-image-4.5.0-1-amd64: Asus MyCinema U3100 Mini Plus V2 USB DVB-T Stick won't be recognised any longer
Package: src:linux Version: 4.5.1-1 Severity: normal Dear Maintainer, * What led up to the situation? Upgrading to newer 4.x kernel versions * What exactly did you do (or not do) that was effective (or ineffective)? "" * What was the outcome of this action? Asus MyCinema U3100 Mini Plus V2 USB DVB-T Stick won't work any longer. It is recognised by the kernel, but Me-TV won't recognise it. * What outcome did you expect instead? Working DVB-T stick since newer kernel versions (actually using linux kernel v4.5) my Asus MyCinema U3100 Mini Plus V2 USB DVB-T Stick won't work any longer. Here is the output of syslog: Apr 30 05:34:14 g6 kernel: [ 6036.453857] usb 2-2.3: USB disconnect, device number 5 Apr 30 05:34:15 g6 kernel: [ 6037.615546] usb 2-2.3: new high-speed USB device number 11 using xhci_hcd Apr 30 05:34:15 g6 kernel: [ 6037.718847] usb 2-2.3: New USB device found, idVendor=1b80, idProduct=d3a8 Apr 30 05:34:15 g6 kernel: [ 6037.718853] usb 2-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Apr 30 05:34:15 g6 kernel: [ 6037.718855] usb 2-2.3: Product: Rtl2832UDVB Apr 30 05:34:15 g6 kernel: [ 6037.718857] usb 2-2.3: Manufacturer: Realtek Apr 30 05:34:15 g6 mtp-probe: checking bus 2, device 11: "/sys/devices/pci:00/:00:1c.0/:10:00.0/usb2/2-2/2-2.3" Apr 30 05:34:15 g6 mtp-probe: bus: 2, device: 11 was not an MTP device The USB DVB-T stick is recognised but Me-TV shows no tuner found. Worked fine before on older kernel versions. Thank you very much for your kind reply. With many freetings, Adrian Immanuel Kieß http://www.immanuelK.net -- Package-specific info: ** Version: Linux version 4.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 20160409 (Debian 5.3.1-14) ) #1 SMP Debian 4.5.1-1 (2016-04-14) ** Command line: BOOT_IMAGE=/vmlinuz-4.5.0-1-amd64 root=UUID=96d5fdb9-5d4e-46f2-89e3-34fcfc7bfe14 ro splash vga=795 splash vga=775 resume=/dev/sdc2 ** Tainted: E (8192) * Unsigned module has been loaded (currently expected). ** Kernel log: [ 16.174129] bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0a5c-21e8.hcd failed with error -2 [ 16.174131] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0a5c-21e8.hcd not found [ 16.281385] usbcore: registered new interface driver snd-usb-audio [ 16.325945] iTCO_vendor_support: vendor-support=0 [ 16.326633] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 16.326664] iTCO_wdt: Found a 3420 TCO device (Version=2, TCOBASE=0x1060) [ 16.326686] watchdog: iTCO_wdt: cannot register miscdev on minor=130 (err=-16). [ 16.326686] watchdog: iTCO_wdt: a legacy watchdog module is probably present. [ 16.326734] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 16.788687] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: user_xattr [ 16.940535] Adding 34814972k swap on /dev/sdd2. Priority:100 extents:1 across:34814972k FS [ 16.983627] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: user_xattr [ 34.930411] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: user_xattr [ 38.474404] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: user_xattr,usrquota [ 39.014054] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 39.534567] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 39.542180] Bluetooth: BNEP filters: protocol multicast [ 39.549881] Bluetooth: BNEP socket layer initialized [ 40.550931] tg3 :1e:00.0 eth0: Link is up at 100 Mbps, full duplex [ 40.558823] tg3 :1e:00.0 eth0: Flow control is on for TX and on for RX [ 40.558842] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 40.610426] traps: atop[1476] trap divide error ip:4073c2 sp:7fff5b974970 error:0 in atop[40+26000] [ 44.727068] usblp1: removed [ 44.728722] usblp 1-1.5:1.0: usblp1: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04E8 pid 0x3268 [ 49.383902] RPC: Registered named UNIX socket transport module. [ 49.383906] RPC: Registered udp transport module. [ 49.383908] RPC: Registered tcp transport module. [ 49.383909] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 49.398337] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 49.412465] audit: netlink_unicast sending to audit_pid=0 returned error: -111 [ 49.412471] audit: type=1302 audit(1461981267.051:64661): item=0 name="/usr/lib/pymodules/python2.7/apport_python_hook.pyc" nametype=UNKNOWN [ 49.412473] audit: type=1327 audit(1461981267.051:64661): proctitle=2F62696E2F7368002F6574632F696E69742E642F73616D62612D61642D6463007374617274 [ 49.412475] audit: type=1300 audit(1461981267.051:64662): arch=c03e syscall=2 success=no exit=-2 a0=205f770 a1=0 a2=1b6 a3=0 items=1 ppid=2172 pid=2177 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="samba-tool" exe="/usr/bin/python2.7" key=(null) [ 49.412476] audit: type=1307 audit(1461981267
Bug#823021: RM: cableswig -- ROM; Obsolete; superceeded by CastXML
Package: ftp.debian.org Severity: normal Please remove. Nothing depends on it anymore. Thanks, -Steve
Bug#823020: installation-reports: problems with u-boot and ext4
Package: installation-reports
Severity: important
X-Debbugs-Cc: ma...@denx.de
I've done several installs now on both a Wandboard Solo and an Novena
board, and u-boot has problems reading the the dtbs subdirectory needed
to load the device-trees, and fails to boot after an otherwise
successful install.
The problem seems to *mostly* be with subdirectories, and since the
device-tree files in stored in /boot/dtbs/${version}/${device}.dtb.
Installs done with jessie and the same u-boot version work fine. Also,
recreating the ext4 filesystem with mkfs.ext4 works fine, even with,
as far as I can tell, identical filesytem flags.
I suspect other boards using u-boot and ext4 filesystem will also have
similar problems.
live well,
vagrant
-- Package-specific info:
Boot method: network
Image version: https://d-i.debian.org/daily-images/armhf/20160426-00:33/netboot/
Date: 20160426
Machine: Wandboard Solo
Partitions:
sfdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcd2ecfc6
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 2048 976895 974848 476M 83 Linux
/dev/mmcblk0p2 976896 4882431 3905536 1.9G 83 Linux
/dev/mmcblk0p3 4882432 5859327 976896 477M 82 Linux swap / Solaris
/dev/mmcblk0p4 5859328 6883327 1024000 500M 83 Linux
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot: [E]
Detect network card:[O]
Configure network: [O]
Detect CD: [ ]
Load installer modules: [O]
Clock/timezone setup: [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives: [O]
Install base system:[O]
Install tasks: [O]
Install boot loader:[O]
Overall install:[ ]
Comments/Problems:
Network boot and SD card boot worked fine, but initial boot failed due to
issues with u-boot being unable to consistantly read the ext4 filesystem.
--
Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.
Once you have filled out this report, mail it to sub...@bugs.debian.org.
==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20160426-00:13"
X_INSTALLATION_MEDIUM=netboot
==
Installer hardware-summary:
==
uname -a: Linux wbs20160426-18 4.5.0-1-armmp #1 SMP Debian 4.5.1-1 (2016-04-14)
armv7l GNU/Linux
usb-list:
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 4.5.0-1-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub
lsmod: Module Size Used by
lsmod: dm_mod 98863 0
lsmod: md_mod118279 0
lsmod: jfs 174600 0
lsmod: btrfs1091195 0
lsmod: xor 4782 1 btrfs
lsmod: zlib_deflate 20354 1 btrfs
lsmod: raid6_pq 87885 1 btrfs
lsmod: vfat 10249 0
lsmod: fat56693 1 vfat
lsmod: ext4 559642 2
lsmod: crc16 1274 1 ext4
lsmod: mbcache 9488 1 ext4
lsmod: jbd2 95959 1 ext4
lsmod: crc32c_generic 1862 5
lsmod: usb_storage45523 0
lsmod: scsi_mod 188696 1 usb_storage
lsmod: ci_hdrc_imx 6936 0
lsmod: ci_hdrc34941 1 ci_hdrc_imx
lsmod: ehci_hcd 64352 1 ci_hdrc
lsmod: extcon 10462 1 ci_hdrc
lsmod: udc_core9769 1 ci_hdrc
lsmod: imx_ipu_v3 59444 0
lsmod: sdhci_esdhc_imx11634 0
lsmod: sdhci_pltfm 3722 1 sdhci_esdhc_imx
lsmod: sdhci 39207 2 sdhci_pltfm,sdhci_esdhc_imx
lsmod: usbcore 190774 3 usb_storage,ehci_hcd,ci_hdrc
lsmod: usbmisc_imx 5814 1 ci_hdrc_imx
lsmod: usb_common 3659 3 udc_core,usbcore,ci_hdrc
lsmod: phy_mxs_usb 5810 2
lsmod: anatop_regulator4584 1
lsmod: dw_hdmi_imx 3234 0
lsmod: dw_hdmi14484 1 dw_hdmi_imx
lsmod: imxdrm 6334 1 dw_hdmi_imx
lsmod: drm_kms_helper105048 2 dw_hdmi,imxdrm
lsmod: drm 277626 4 dw_hdmi,drm_kms_helper,dw_hdmi_imx,imxdrm
lsmod: at803x 3887 0
df: Filesystem 1K-blocks Used Available Use% Mounted on
Bug#822228: proposed NMU
Raphaël Halimi wrote:
> The first report dates back from more than two years ago. Maybe this
> should be NMU'd ?
Right. Here's a proposed NMU diff (as a commit against your repository).
If you're unhappy with this in any way, please say so, otherwise I'll upload
in a few days.
--
A tit a day keeps the vet away.
>From a536721253a64eaca4821a64e06dfb81ce727e3b Mon Sep 17 00:00:00 2001
From: Adam Borowski
Date: Sat, 30 Apr 2016 04:22:01 +0200
Subject: [PATCH] NMU: switch to fonts-dejavu-core.
---
debian/changelog | 7 +++
debian/control | 2 +-
debian/rules | 4 ++--
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 33fc871..5eb91c3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+projectm (2.1.0+dfsg-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Use fonts-dejavu-core instead of ttf-dejavu-core (Closes: #733957)
+
+ -- Adam Borowski Sat, 30 Apr 2016 04:19:39 +0200
+
projectm (2.1.0+dfsg-3) unstable; urgency=medium
* Team upload.
diff --git a/debian/control b/debian/control
index b06ba41..89020c0 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,7 @@ Homepage: http://projectm.sf.net
Package: libprojectm2v5
Architecture: any
Section: libs
-Depends: projectm-data, ttf-dejavu-core, ${misc:Depends}, ${shlibs:Depends}
+Depends: projectm-data, fonts-dejavu-core, ${misc:Depends}, ${shlibs:Depends}
Breaks: libprojectm2
Replaces: libprojectm2, libprojectm-data (<< 2.0.1)
Description: Advanced Milkdrop-compatible music visualization library
diff --git a/debian/rules b/debian/rules
index 25c4d3a..2ac9dff 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,8 +2,8 @@
# Use this variable to pass configure options for projectM to cmake
PROJECTM_CMAKE_FLAGS = \
- -DprojectM_FONT_TITLE="/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" \
- -DprojectM_FONT_MENU="/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf" \
+ -DprojectM_FONT_TITLE="/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf" \
+ -DprojectM_FONT_MENU="/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf" \
-DINCLUDE-PROJECTM-TEST=OFF \
-DINCLUDE-PROJECTM-JACK=ON
--
2.8.1
Bug#823019: RFS: gap-openmath/11.3.1+ds-2 - OpenMath phrasebook for GAP
Package: sponsorship-requests Severity: normal Dear Sponsors, I am looking for a sponsor for the package gap-openmath, a package for the Computer Algebra System (CAS) GAP. This package corrects some dependency issues and introduces Debian Continuous Integration. Thanks in advance, Jerome [1] https://anonscm.debian.org/git/debian-science/packages/gap-openmath.git -- System Information: Debian Release: Jessie* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.7-ckt20-0001-mbp62 (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 Init: sysvinit (via /sbin/init)
Bug#818925: Wine's forked version of fontforge
[CC to Huw Davies because I have a question about one of his changes]
On 04/22/2016 12:54 PM, Alexandre Julliard wrote:
> Jens Reyer writes:
>
>> Wine and Debian are both using the quite old fontforge version
>> 20120731-b, the patches apply cleanly in Debian.
>> But upstream is actively developing and in Debian someone is working on
>> packaging a recent version (not sure with what outcome, e.g. afaik there
>> is at least one upstream regression blocking an update).
>> Are there any plans in Wine to update to a newer version?
>
> No plans currently, but I can certainly look into it if it helps.
Thanks. First off, I successfully tested the current fontforge
20160404. I built Wine and the .ttf files with it, and verified in one
app that relies on them that they are working. So no immediate need to
update, but it might be a good idea generally.
After looking into your patches and explanation my understanding is
that we may regenerate the .ttf files in Debian without having to
worry about the results. However for contributing to Wine the current
Debian fontforge is not suitable. So I started trying to get your
changes applied upstream:
>> 1. Various hacks to avoid putting timestamps in generated files (AJ).
Created issue https://github.com/fontforge/fontforge/issues/2711
The timestamps are also a hindrance for reproducible builds, and need
to be tackled somehow in fontforge anyway.
>> 2. - Avoid outputting trailing spaces in sfd files (AJ).
Created pull request https://github.com/fontforge/fontforge/pull/2713
for hopefully all remaining changes.
>> 3. Enable the width of individual bitmap strikes to be altered (Huw Davies).
>>
>> Since the import of upstream version 20120731-b this patch only has a
>> third of its original size. Are the remaining Wine changes still
>> necessary, or are they cruft? If still needed, I guess they should be
>> pushed upstream.
>>
>> In 20160404 not much seems to have changed, but the containing file
>> bitmapview.c was moved ("splitting ui code from fontforge/ to
>> fontforgeexe/").
>>
>> Same as above: is this only needed when creating fonts? Looks like a
>> candidate for upstream.
>
> I believe it's still needed, I'm not sure why that part didn't get
> upstream.
See below for the remaining changes. I didn't bring that to upstream,
because I don't know how to test this. Instructions, or a review of
the patch and whether its still needed in 20160404, would be welcome.
Alternatively, if you update to a newer fontforge I'd filter out the
remaining diff and just go with that.
>> 4. Don't save the selected state. (Huw Davies)
Created issue https://github.com/fontforge/fontforge/issues/2715 for
this and other local information saved in sfds.
Greets
jre
---
fontforgeexe/bitmapview.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fontforgeexe/bitmapview.c b/fontforgeexe/bitmapview.c
index 7cee735..749123d 100644
--- a/fontforgeexe/bitmapview.c
+++ b/fontforgeexe/bitmapview.c
@@ -1758,8 +1758,6 @@ static void BVMenuSetWidth(GWindow gw,struct gmenuitem
*mi,GEvent *g) {
SplineChar *sc;
int val;
-if ( !bv->bdf->sf->onlybitmaps )
-return;
if ( mi->mid==MID_SetWidth ) {
sprintf( buffer,"%d",bv->bc->width);
ret = gwwv_ask_string(_("Set Width..."),buffer,_("Set Width..."));
@@ -1778,6 +1776,10 @@ return;
else
bv->bc->vwidth = val;
BCCharChangedUpdate(bv->bc);
+
+if ( !bv->bdf->sf->onlybitmaps )
+return;
+
for ( bdf=bv->bdf->sf->bitmaps; bdf!=NULL; bdf=bdf->next )
if ( bdf->pixelsize > mysize )
return;
@@ -2065,10 +2067,10 @@ static void mtlistcheck(GWindow gw,struct gmenuitem
*mi,GEvent *e) {
for ( mi = mi->sub; mi->ti.text!=NULL || mi->ti.line ; ++mi ) {
switch ( mi->mid ) {
case MID_SetWidth:
- mi->ti.disabled = !bv->bdf->sf->onlybitmaps;
+ mi->ti.disabled = 0;
break;
case MID_SetVWidth:
- mi->ti.disabled = !bv->bdf->sf->onlybitmaps ||
!bv->bdf->sf->hasvmetrics;
+ mi->ti.disabled = !bv->bdf->sf->hasvmetrics;
break;
}
}
--
2.8.1
Bug#821934: Need libwxgtk-webview3.0-dev as build-dep
On Thu, 28 Apr 2016, Olly Betts wrote: This is probably why this is currently commented out - things need sorting out such that only python-wxgtk-webview3.0 pulls in libwxgtk-webview3.0-0v5 (like how only python-wxgtk-media3.0 pulls in libwxgtk-media3.0-0v5, though the mechanism to achieve this might not be the same). Right. I'll see if I can figure out the best way to do this. Cool - debian/patches/wxpython-media-optional.patch is how we do it for the media stuff, which might be a good place to start. This seems to do the trick. Scott[The following lists of changes regard files as different if they have different names, permissions or owners.] Files in second .changes but not in first - -rw-r--r-- root/root /usr/lib/debug/.build-id/06/175a06ea0787f6fd475df2483f48d846610092.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/10/4f8cd6e54f7a4c5734c4e12d66385365ac538e.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/2d/a797b59f373a61db8b2f8ceb07f69c8c3dd788.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/2e/850c796746a9efff8cb5c27332f7328daae14d.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/55/42a0a547bd06f6e76c06910d18983ca2ef5d9b.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/55/8c2fe970183847601ef133a8f4baa43cdfcc64.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/56/5a5d9864e7a03e50be97abf330e55a98b4d99e.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/5e/a85614a5527b3a46db7a6615b8c65ade8a0894.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/65/db1f018f5fec27688348babaf6ada0fc569e25.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/68/6f46f2de709f457119de3ad84fb5b83cf39c5f.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/6a/f5979bce13bdc806946ef001d08be0615d4fdb.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/6e/f9f062550ba7b418eb04f53d560391fa1c8ea8.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/74/bac403217bb94961ae51f60d5fcdcab8254705.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/90/38be6e4f74291e277b2850a5719638e3b619f6.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/91/9d0ccd91be9968b9b697fd45a7cf589d130b4e.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/95/0daf23b9d3449134063ff508591e438686e228.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/b0/9c144598c6ff15c56dd2085b4ff9c7403175b1.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/c2/b0e0fec86f9bd82f1d49a0a4899d68f88c1cc3.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/c4/940a5fc3e710aa56fbda3e2bbd39d05d965cf2.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/e1/72844c1c259da9b6ae56c93036cec52bb9e2d1.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/fb/6ca15e77f835158b91bda39082cd31c2265ea4.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/fe/c429e919ee65ae2fef3058cbfba8486ebe7a13.debug -rw-r--r-- root/root /usr/share/doc/python-wxgtk-webview3.0/changelog.Debian.gz -rw-r--r-- root/root /usr/share/doc/python-wxgtk-webview3.0/changelog.gz -rw-r--r-- root/root /usr/share/doc/python-wxgtk-webview3.0/copyright lrwxrwxrwx root/root /usr/share/doc/python-wxgtk-webview3.0-dbgsym -> python-wxgtk-webview3.0 Files in first .changes but not in second - -rw-r--r-- root/root /usr/lib/debug/.build-id/01/528711e5588a3d6c4324ded008aa2100653872.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/0b/5b69cd3b75266f9496b257c96158bacb869505.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/0e/a41709fee19426e38b1da18f5aa6185a29634c.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/0f/613acb33098bbad1238e94ab35bf2e502053ac.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/15/04d232a6b640a8ee97f079b411e53ff8b18766.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/23/d06e2f0b90451820314d0e721af46411abd1bc.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/47/2fb74eebacd1382f719bc3bb8720cb52364d0d.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/4d/1bc3db0cd776c1ad7eb93080978cf5253f95d5.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/56/1c0133eba8ced4dd79c0a7c6f69cfeb7bb0fe9.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/59/08384906a65fbe5b5d704e58239a119366c325.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/5c/7e5b3c0a55055a16ead43df6d352d8a1920fe3.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/5f/10b378e4f7bb870a7433267b0207c7c0bb2309.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/6d/cadd7339a2560e88ccd3d6ae8627d9fc3a04fc.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/75/3ee5e6d97ecd8cc6e92e5a613a555bed8cfe22.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/78/e0338784c0d9f47ba9882172cb160afe95d43a.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/7d/64ec6e7f706ddf38dec649468f6659cda9629c.debug -rw-r--r-- root/root /usr/lib/debug/.build-id/90/601d15d86e6de830f7de5ca2129bbea5242284.debug -rw-r--r--
Bug#822941: debian-installer: cannot boot installed on VirtualBox with EFI-enabled
On Sat, 30 Apr 2016 00:16:23 +0100 Steve McIntyre wrote: > Do we know what version of Virtualbox? That could be a major factor > here. I've just a test installation using the UEFI support in the > virtualbox package in Jessie (4.3.36), which is labelled as > "experimental support". VirtualBox version is 5.0.18, from contrib sid. 5.0.20 was released yesterday but it seems to not be changed for UEFI. https://www.virtualbox.org/wiki/Changelog#v20 > It shows the same behaviour as described, but > that's a limitation of the virtualbox UEFI support rather than a > problem in Debian - the underlying virtualbox isn't saving EFI > variables persistently. Probably it caused by limitation of virtualbox UEFI support but users want just work and other distros avoid its limitation, so we can improve it as expected :) And, it maybe not relate to this issue, I wonder why my debian box's disk says "Partition type: Linux filesystem" for /boot/efi │ Partition UUID: 752C9D2E-C84E-4395-A566-DE05E519212B │ Partition type: Linux filesystem (0FC63DAF-8483-4772-8E79-3D69D8477DE4) │ Filesystem: vfat │Filesystem UUID: 57BC-3C6C │ Mountpoint: /boot/efi (mounted) Fedora on VirtualBox says its Partition type is "Partition type: EFI System". -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane
Bug#822210: sdl2-config.cmake: extra leading / trailing whitespace
Hi (removed the SDL maintainers/developers from this email, don't want
to spam..)
On 04/29/2016 06:44 AM, Manuel A. Fernandez Montecelo wrote:
... [snip] ...
>
> At a first glance, it looks very odd for cmake to be so fussy about
> whitespace, but I guess that they have a good reason.
>
> I've been looking into it and a more definitive/robust fix could be to
> trim the strings coming from configure, so the same problem is avoided
> in other systems or in future changes to other variables. (Patch
> attached).
>
> Since "string(STRIP input output)" does not return the stripped
> string, instead of using the string() function in the same spot where
> the original variable is used, one has to use an "output variable" and
> then use the variable as substitute in the original command.
>
> So the result looks a bit ugly and duplicates the number of lines, and
> everything is a bit cumbersome, but I think that it works.
>
> Jason, if you want to test it to see if it works fine, then I can
> submit both to upstream's bug report for them to decide.
It looks like ${prefix} is not set when defining ${stripped_prefix}. So
for example SDL2_INCLUDE_DIRS is set to /include/SDL2.
I got it to work with the following:
# sdl2 cmake project-config input for ./configure scripts
string(STRIP "@prefix@" prefix)
string(STRIP "@exec_prefix@" stripped_exec_prefix)
string(STRIP "@libdir@" stripped_libdir)
string(STRIP "@includedir@" stripped_includedir)
string(STRIP "-L${SDL2_LIBDIR} @SDL_RLD_FLAGS@ @SDL_LIBS@"
stripped_SDL2_LIBRARIES)
set(exec_prefix "${stripped_exec_prefix}")
set(libdir "${stripped_libdir}")
set(SDL2_PREFIX "${stripped_prefix}")
set(SDL2_EXEC_PREFIX "${stripped_prefix}")
set(SDL2_LIBDIR "${stripped_libdir}")
set(SDL2_INCLUDE_DIRS "${stripped_includedir}/SDL2")
set(SDL2_LIBRARIES "${stripped_SDL2_LIBRARIES}")
(patch format attached)
>
> (If anybody wants to use the attached patch as a basis for better
> patches, feel free to do it. Also anybody feel free to submit the
> patches upstream, but better if tested first).
>
>
> Cheers.
>
Thanks !
--
Jason Pleau
--- a/sdl2-config.cmake.in
+++ b/sdl2-config.cmake.in
@@ -1,10 +1,15 @@
# sdl2 cmake project-config input for ./configure scripts
-set(prefix "@prefix@")
-set(exec_prefix "@exec_prefix@")
-set(libdir "@libdir@")
-set(SDL2_PREFIX "@prefix@")
-set(SDL2_EXEC_PREFIX "@prefix@")
-set(SDL2_LIBDIR "@libdir@")
-set(SDL2_INCLUDE_DIRS "@includedir@/SDL2")
-set(SDL2_LIBRARIES "-L${SDL2_LIBDIR} @SDL_RLD_FLAGS@ @SDL_LIBS@")
+string(STRIP "@prefix@" prefix)
+string(STRIP "@exec_prefix@" stripped_exec_prefix)
+string(STRIP "@libdir@" stripped_libdir)
+string(STRIP "@includedir@" stripped_includedir)
+string(STRIP "-L${SDL2_LIBDIR} @SDL_RLD_FLAGS@ @SDL_LIBS@" stripped_SDL2_LIBRARIES)
+
+set(exec_prefix "${stripped_exec_prefix}")
+set(libdir "${stripped_libdir}")
+set(SDL2_PREFIX "${stripped_prefix}")
+set(SDL2_EXEC_PREFIX "${stripped_prefix}")
+set(SDL2_LIBDIR "${stripped_libdir}")
+set(SDL2_INCLUDE_DIRS "${stripped_includedir}/SDL2")
+set(SDL2_LIBRARIES "${stripped_SDL2_LIBRARIES}")
Bug#823018: claws-mail: Icon really blurry in gnome-shell
tag 823018 + patch thanks Hi, The following patch is doing the trick: diff -Nru claws-mail-3.13.2/debian/claws-mail.install claws-mail-3.13.2/debian/claws-mail.install --- claws-mail-3.13.2/debian/claws-mail.install2016-01-26 12:01:39.0 +0100 +++ claws-mail-3.13.2/debian/claws-mail.install2016-04-30 02:44:16.0 +0200 @@ -1,5 +1,5 @@ usr/bin/claws-mail -claws-mail.desktop usr/share/applications +usr/share/applications usr/share/man -claws-mail*.png usr/share/pixmaps/ +usr/share/icons/ debian/claws-mail-32x32.xpm usr/share/pixmaps/
Bug#817005: RFS: aseqjoy/0.0.1-1 [ITP]
On Fri, Apr 29, 2016 at 09:31:50PM -0300, Fernando Toledo wrote: > El 29/04/16 a las 18:31, Adam Borowski escribió: > > On Fri, Apr 29, 2016 at 08:45:27PM +, Gianfranco Costamagna wrote: > >> licensecheck * > >> shows the license of some files as GPL-2+ not GPL-2 > > > > It looks like there's a mismatch: > > > > README says: > > # Copyright 2003 by Alexander K.nig - a...@lisas.de > > # License: GPL V2 - see the file COPYING > > (COPYING is the text of GPL-2) > > > > but, aseqjoy.c says: > > # or (at your option) any later version. > > > > Too bad, while it's the only C source, there's one more copyrightable file, > > aseqjoy.1.in, which doesn't embed a license statement and thus is covered by > > the README. > > > > So unless you contact the author or rewrite the manpage, the effective > > license is GPL-2 only. > > > > if i understand, if i change the debian/* to GPL-2+ will solved only the > patches issues? and still have problem with the upstream man file? > my own patch just is trivial and solve spell lintian warning only. GPL-2 is compatible with GPL-2+, so that's enough. > i just send a email to the upstream author with this comments also. > will need to release a new tarball with this changes? Clarifying the license would be nice, but is not required: while it's not sure what the author meant, there is one safe option: assuming GPL-2. Of course, that means you can't combine it with GPL-3 patches or packaging. Unless you hear back from the author soon, I'd recommend using GPL-2+ for the packaging. That's compatible with GPL-2, GPL-3, GPL-3+, or even future GPL-4 or GPL-65535. -- A tit a day keeps the vet away.
Bug#823014: golang: Package compiled stdlib for PIE build mode
On Fri, Apr 29, 2016 at 08:18:14PM -0400, Peter Colberg wrote:
> Please consider adding the following patch, which builds an optional
> package containing the compiled standard library for PIE build mode.
I revised the patch to tighten the versioned dependency on golang-go.
Peter
>From dda0f9d4aa29ec177da681605b521c313340504b Mon Sep 17 00:00:00 2001
From: Peter Colberg
Date: Fri, 29 Apr 2016 08:01:02 -0400
Subject: [PATCH v2] Package compiled stdlib for PIE build mode
---
debian/control| 17 +
debian/golang-std-pie.install | 1 +
debian/rules | 3 +++
3 files changed, 21 insertions(+)
create mode 100644 debian/golang-std-pie.install
diff --git a/debian/control b/debian/control
index d08c525..0198fe3 100644
--- a/debian/control
+++ b/debian/control
@@ -86,6 +86,23 @@ Description: Go programming language - source files
This package provides the Go programming language source files needed for
cross-compilation.
+Package: golang-std-pie
+Depends: golang-go (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
+Architecture: amd64 arm64 armel armhf i386 ppc64 ppc64el
+Build-Profiles:
+Description: Go programming language - compiled stdlib for PIE build mode
+ The Go programming language is an open source project to make programmers more
+ productive. Go is expressive, concise, clean, and efficient. Its concurrency
+ mechanisms make it easy to write programs that get the most out of multicore
+ and networked machines, while its novel type system enables flexible and
+ modular program construction. Go compiles quickly to machine code yet has the
+ convenience of garbage collection and the power of run-time reflection. It's a
+ fast, statically typed, compiled language that feels like a dynamically typed,
+ interpreted language.
+ .
+ This package provides the compiled standard library for the Go programming
+ language for the purpose of building position-independent executables (PIE).
+
Package: golang-doc
Depends: golang-go, ${misc:Depends}
Architecture: all
diff --git a/debian/golang-std-pie.install b/debian/golang-std-pie.install
new file mode 100644
index 000..ef62e13
--- /dev/null
+++ b/debian/golang-std-pie.install
@@ -0,0 +1 @@
+pkg/*_*_shared /usr/lib/go/pkg/
diff --git a/debian/rules b/debian/rules
index cb30d52..1e17ee1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -76,6 +76,9 @@ override_dh_auto_build-arch:
&& cd src \
&& $(CURDIR)/debian/helpers/goenv.sh \
bash ./make.bash --no-banner
+ifeq (,$(filter cross,$(DEB_BUILD_PROFILES)))
+ $(GOROOT)/bin/go install -v -buildmode=pie std
+endif
opt_no_act :=
ifneq (,$(findstring n,$(MAKEFLAGS)))
--
2.8.1
Bug#823018: claws-mail: Icon really blurry in gnome-shell
Package: claws-mail Version: 3.13.2-1 Severity: normal Hi, In the gnome-shell dash, the icon of claws-mail is really blurry. It seems that the icons are not installed as expected, the build log shows: /usr/bin/install -c -m 644 claws-mail-128x128.png '/«PKGBUILDDIR»/debian/tmp/usr/share/icons/hicolor/128x128/apps' /usr/bin/install -c -m 644 claws-mail-64x64.png '/«PKGBUILDDIR»/debian/tmp/usr/share/icons/hicolor/64x64/apps' /usr/bin/install -c -m 644 claws-mail.desktop '/«PKGBUILDDIR»/debian/tmp/usr/share/applications' /usr/bin/install -c -m 644 claws-mail.png '/«PKGBUILDDIR»/debian/tmp/usr/share/icons/hicolor/48x48/apps' But once installed: $ dpkg -L claws-mail|grep png /usr/share/pixmaps/claws-mail-64x64.png /usr/share/pixmaps/claws-mail-128x128.png /usr/share/pixmaps/claws-mail.png This should be fixed I guess? Cheers, Laurent Bigonville -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages claws-mail depends on: ii libatk1.0-0 2.20.0-1 ii libc62.22-7 ii libcairo21.14.6-1+b1 ii libcompfaceg11:1.5.2-5 ii libdb5.3 5.3.28-11 ii libdbus-1-3 1.10.8-1 ii libdbus-glib-1-2 0.106-1 ii libenchant1c2a 1.6.0-10.1 ii libetpan17 1.6-1+b1 ii libfontconfig1 2.11.0-6.4 ii libfreetype6 2.6.3-3+b1 ii libgdk-pixbuf2.0-0 2.34.0-1 ii libglib2.0-0 2.48.0-1 ii libgnutls30 3.4.11-4 ii libgtk2.0-0 2.24.30-1.1 ii libice6 2:1.0.9-1+b1 ii libldap-2.4-22.4.42+dfsg-2+b2 ii liblockfile1 1.09-6 ii libpango-1.0-0 1.40.1-1 ii libpangocairo-1.0-0 1.40.1-1 ii libpangoft2-1.0-01.40.1-1 ii libpisock9 0.12.5-dfsg-2+b1 ii libsasl2-2 2.1.26.dfsg1-15 ii libsm6 2:1.2.2-1+b1 ii xdg-utils1.1.1-1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages claws-mail recommends: ii aspell-fr [aspell-dictionary] 0.50-3-7 ii claws-mail-i18n3.13.2-1 ii xfonts-100dpi 1:1.0.4+nmu1 ii xfonts-75dpi 1:1.0.4+nmu1 Versions of packages claws-mail suggests: pn claws-mail-doc pn claws-mail-tools ii epiphany-browser [www-browser] 3.20.1-2 ii firefox [www-browser] 46.0-1 ii gedit 3.20.1-1 ii w3m [www-browser] 0.5.3-27 -- no debconf information
Bug#823017: linux-image-4.5.0-1-amd64: can't read some files of a DVD+R: udf_read_inode: ... failed !bh
Package: src:linux Version: 4.5.1-1 Severity: important Trying to copy some files of a DVD+R yields errors: cp: cannot stat '...': Input/output error In the logs: Apr 30 01:52:28 zira kernel: UDF-fs: error (device sr0): udf_read_inode: (ino 453) failed !bh Apr 30 01:52:28 zira kernel: UDF-fs: error (device sr0): udf_read_inode: (ino 454) failed !bh Apr 30 01:52:28 zira kernel: UDF-fs: error (device sr0): udf_read_inode: (ino 455) failed !bh Apr 30 01:52:28 zira kernel: UDF-fs: error (device sr0): udf_read_inode: (ino 456) failed !bh Apr 30 01:52:28 zira kernel: UDF-fs: error (device sr0): udf_read_inode: (ino 457) failed !bh Apr 30 01:52:28 zira kernel: UDF-fs: error (device sr0): udf_read_inode: (ino 458) failed !bh Reading most of the DVD+R is OK, though. And I don't get any error on two other Debian/unstable machines (I can copy the whole DVD+R). The DVD+R was burnt with growisofs. Note: I had exactly the same problem on this machine in December with another DVD. At that time, I thought that the DVD was faulty. -- Package-specific info: ** Version: Linux version 4.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 20160409 (Debian 5.3.1-14) ) #1 SMP Debian 4.5.1-1 (2016-04-14) ** Command line: BOOT_IMAGE=/vmlinuz-4.5.0-1-amd64 root=/dev/mapper/zira--vg-root ro quiet ** Tainted: POE (12289) * Proprietary module has been loaded. * Out-of-tree module has been loaded. * Unsigned module has been loaded (currently expected). ** Kernel log: [692811.106153] CPU2: Package temperature above threshold, cpu clock throttled (total events = 3583) [692811.106154] mce: [Hardware Error]: Machine check events logged [692811.107149] CPU2: Core temperature/speed normal [692811.107150] CPU3: Core temperature/speed normal [692811.107150] CPU4: Package temperature/speed normal [692811.107151] CPU7: Package temperature/speed normal [692811.107152] CPU5: Package temperature/speed normal [692811.107153] CPU1: Package temperature/speed normal [692811.107153] CPU0: Package temperature/speed normal [692811.107154] CPU6: Package temperature/speed normal [692811.107154] CPU3: Package temperature/speed normal [692811.107160] CPU2: Package temperature/speed normal [767674.823244] Process accounting resumed [776697.327002] CPU3: Core temperature above threshold, cpu clock throttled (total events = 17) [776697.327003] CPU2: Core temperature above threshold, cpu clock throttled (total events = 17) [776697.327004] CPU5: Package temperature above threshold, cpu clock throttled (total events = 3584) [776697.327005] CPU1: Package temperature above threshold, cpu clock throttled (total events = 3584) [776697.327006] CPU4: Package temperature above threshold, cpu clock throttled (total events = 3584) [776697.327007] CPU0: Package temperature above threshold, cpu clock throttled (total events = 3584) [776697.327008] CPU2: Package temperature above threshold, cpu clock throttled (total events = 3584) [776697.327010] CPU6: Package temperature above threshold, cpu clock throttled (total events = 3584) [776697.327011] CPU7: Package temperature above threshold, cpu clock throttled (total events = 3584) [776697.327013] mce_notify_irq: 2 callbacks suppressed [776697.327013] mce: [Hardware Error]: Machine check events logged [776697.327019] CPU3: Package temperature above threshold, cpu clock throttled (total events = 3584) [776697.327020] mce: [Hardware Error]: Machine check events logged [776697.327989] CPU2: Core temperature/speed normal [776697.327990] CPU3: Core temperature/speed normal [776697.327991] CPU1: Package temperature/speed normal [776697.327991] CPU4: Package temperature/speed normal [776697.327992] CPU5: Package temperature/speed normal [776697.327993] CPU7: Package temperature/speed normal [776697.327993] CPU0: Package temperature/speed normal [776697.327994] CPU6: Package temperature/speed normal [776697.327994] CPU3: Package temperature/speed normal [776697.328000] CPU2: Package temperature/speed normal [854071.639604] Process accounting resumed [940468.459799] Process accounting resumed [943903.535040] CPU5: Core temperature above threshold, cpu clock throttled (total events = 3573) [943903.535042] CPU7: Package temperature above threshold, cpu clock throttled (total events = 3602) [943903.535053] CPU4: Core temperature above threshold, cpu clock throttled (total events = 3573) [943903.535054] CPU6: Package temperature above threshold, cpu clock throttled (total events = 3602) [943903.535056] CPU4: Package temperature above threshold, cpu clock throttled (total events = 3602) [943903.535057] CPU2: Package temperature above threshold, cpu clock throttled (total events = 3602) [943903.535058] CPU3: Package temperature above threshold, cpu clock throttled (total events = 3602) [943903.535059] CPU1: Package temperature above threshold, cpu clock throttled (total events = 3602) [943903.535060] CPU0: Package temperature above threshold, cpu clock throttled (total events = 3602) [943903
Bug#817005: RFS: aseqjoy/0.0.1-1 [ITP]
El 29/04/16 a las 18:31, Adam Borowski escribió: > On Fri, Apr 29, 2016 at 08:45:27PM +, Gianfranco Costamagna wrote: >>> Fixed. Is possible to have upstream => gpl2 and debian/* => gpl3, true? >> >> this means that it will be impossible to forward patches upstream without >> manually >> relicensing them. >> >> I personally don't prefer, because only the author of each patch will be >> able to forward >> it upstream. > > It's worse: as the package is built from sources under mutually conflicting > licenses, it is indistributable. > > As both the packaging and the only patch come exclusively from you, I'd > simply change the license for debian/* to GPL-2+ (but, see below). > >> licensecheck * >> shows the license of some files as GPL-2+ not GPL-2 > > It looks like there's a mismatch: > > README says: > # Copyright 2003 by Alexander K.nig - a...@lisas.de > # License: GPL V2 - see the file COPYING > (COPYING is the text of GPL-2) > > but, aseqjoy.c says: > # or (at your option) any later version. > > Too bad, while it's the only C source, there's one more copyrightable file, > aseqjoy.1.in, which doesn't embed a license statement and thus is covered by > the README. > > So unless you contact the author or rewrite the manpage, the effective > license is GPL-2 only. > hi both, thanks to help me. if i understand, if i change the debian/* to GPL-2+ will solved only the patches issues? and still have problem with the upstream man file? my own patch just is trivial and solve spell lintian warning only. i just send a email to the upstream author with this comments also. will need to release a new tarball with this changes? Thanks. -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar
Bug#823016: RFS: gap-grape/4r7+ds-3 - GRaph Algorithms using PErmutation groups for GAP
Package: sponsorship-requests Severity: normal Dear Sponsors, I am looking for a sponsor for the Debian package gap-grape. This version mainly harden the Debian Continuous Integration (DCI) material. GAP is a Computer Algebra System (CAS). Thanks in advance, Jerome [1] https://anonscm.debian.org/git/debian-science/packages/gap-grape.git -- System Information: Debian Release: Jessie* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.7-ckt20-0001-mbp62 (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 Init: sysvinit (via /sbin/init)
Bug#823014: golang: Package compiled stdlib for PIE build mode
Package: golang
Version: 2:1.6.1-2
Severity: normal
Tags: patch
Dear Maintainer,
Please consider adding the following patch, which builds an optional
package containing the compiled standard library for PIE build mode.
This is a prerequisite for building position-independent executables
for the purpose of hardening Go binaries against memory corruption
vulnerabilities [1].
[1] https://bugs.debian.org/821454
A package maintainer who wishes to ship hardened binaries shall add
a Build-Depends: golang-std-pie, and a debian/rules stanza such as
override_dh_auto_build:
dh_auto_build -O--buildsystem=golang -- -buildmode=pie -ldflags
-extldflags=-Wl,-z,now,-z,relro
In the future dh-golang could be extended to pass the above flags.
Regards,
Peter
>From 8622c71c744b7099d1a8b5ddd553cdb736351dcc Mon Sep 17 00:00:00 2001
From: Peter Colberg
Date: Fri, 29 Apr 2016 08:01:02 -0400
Subject: [PATCH] Package compiled stdlib for PIE build mode
---
debian/control| 17 +
debian/golang-std-pie.install | 1 +
debian/rules | 3 +++
3 files changed, 21 insertions(+)
create mode 100644 debian/golang-std-pie.install
diff --git a/debian/control b/debian/control
index d08c525..c51864b 100644
--- a/debian/control
+++ b/debian/control
@@ -86,6 +86,23 @@ Description: Go programming language - source files
This package provides the Go programming language source files needed for
cross-compilation.
+Package: golang-std-pie
+Depends: golang-go (>= ${source:Version}), ${misc:Depends}, ${shlibs:Depends}
+Architecture: amd64 arm64 armel armhf i386 ppc64 ppc64el
+Build-Profiles:
+Description: Go programming language - compiled stdlib for PIE build mode
+ The Go programming language is an open source project to make programmers more
+ productive. Go is expressive, concise, clean, and efficient. Its concurrency
+ mechanisms make it easy to write programs that get the most out of multicore
+ and networked machines, while its novel type system enables flexible and
+ modular program construction. Go compiles quickly to machine code yet has the
+ convenience of garbage collection and the power of run-time reflection. It's a
+ fast, statically typed, compiled language that feels like a dynamically typed,
+ interpreted language.
+ .
+ This package provides the compiled standard library for the Go programming
+ language for the purpose of building position-independent executables (PIE).
+
Package: golang-doc
Depends: golang-go, ${misc:Depends}
Architecture: all
diff --git a/debian/golang-std-pie.install b/debian/golang-std-pie.install
new file mode 100644
index 000..ef62e13
--- /dev/null
+++ b/debian/golang-std-pie.install
@@ -0,0 +1 @@
+pkg/*_*_shared /usr/lib/go/pkg/
diff --git a/debian/rules b/debian/rules
index cb30d52..1e17ee1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -76,6 +76,9 @@ override_dh_auto_build-arch:
&& cd src \
&& $(CURDIR)/debian/helpers/goenv.sh \
bash ./make.bash --no-banner
+ifeq (,$(filter cross,$(DEB_BUILD_PROFILES)))
+ $(GOROOT)/bin/go install -v -buildmode=pie std
+endif
opt_no_act :=
ifneq (,$(findstring n,$(MAKEFLAGS)))
--
2.8.1
Bug#823015: bitcoin-qt: Icon installed in wrong directory?
Package: bitcoin-qt Version: 0.11.2-1 Severity: normal Hi, Apparently the bitcoin.png is installed by the package in /usr/share/pixmaps/hicolor/ This package is the only one to do so: $ apt-file search /usr/share/pixmaps/hicolor/ bitcoin-qt: /usr/share/pixmaps/hicolor/128x128/apps/bitcoin.png bitcoin-qt: /usr/share/pixmaps/hicolor/16x16/apps/bitcoin.png bitcoin-qt: /usr/share/pixmaps/hicolor/256x256/apps/bitcoin.png bitcoin-qt: /usr/share/pixmaps/hicolor/32x32/apps/bitcoin.png bitcoin-qt: /usr/share/pixmaps/hicolor/64x64/apps/bitcoin.png Shouldn't this be /usr/share/icons/hicolor/ instead? Cheers, Laurent Bigonville -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bitcoin-qt depends on: ii libboost-chrono1.58.0 1.58.0+dfsg-5+b1 ii libboost-filesystem1.58.0 1.58.0+dfsg-5+b1 ii libboost-program-options1.58.0 1.58.0+dfsg-5+b1 ii libboost-system1.58.0 1.58.0+dfsg-5+b1 ii libboost-thread1.58.0 1.58.0+dfsg-5+b1 ii libc6 2.22-7 ii libdb5.3++ 5.3.28-11 ii libgcc1 1:6.0.1-2 ii libminiupnpc10 1.9.20140610-2.1 ii libprotobuf9v5 2.6.1-1.3 ii libqrencode33.4.4-1+b1 ii libqt4-dbus 4:4.8.7+dfsg-6+b1 ii libqt4-network 4:4.8.7+dfsg-6+b1 ii libqt4-xml 4:4.8.7+dfsg-6+b1 ii libqtcore4 4:4.8.7+dfsg-6+b1 ii libqtgui4 4:4.8.7+dfsg-6+b1 ii libssl1.0.2 1.0.2g-2 ii libstdc++6 6.0.1-2 bitcoin-qt recommends no packages. bitcoin-qt suggests no packages. -- no debconf information
Bug#823013: ITP: librttopo -- Tuscany Region topology library
Package: wnpp Severity: wishlist Owner: Bas Couwenberg * Package name: librttopo Version : 1.0.0~rc2 Upstream Author : Sandro Santilli * URL : https://git.osgeo.org/gogs/rttopo/librttopo * License : GPL-2+ Programming Lang: C Description : Tuscany Region topology library The RT Topology Library exposes an API to create and manage standard (ISO 13249 aka SQL/MM) topologies using user-provided data stores. The code is derived from PostGIS liblwgeom library enhanced to provide thread-safety, have less dependencies and be independent from PostGIS release cycles. The librttopo package will be maintained within the Debian GIS team along with postgis and spatialite.
Bug#823011: libhinawa: avoid build non-linux arch
On Apr 30 2016 08:22, Hideki Yamane wrote: > non-linux arch build was failed with >>> internal.h:8:33: fatal error: linux/firewire-cdev.h: No such file or >>> directory > > debian/control says "arch: any" but it seems that it should be linux-any Indeed. Libhinawa is an application of Linux FireWire subsystem and Linux sound subsystem, therefore it's unavailable for non-linux kernel such as kfreebsd. I'll make new maintenance release in upstream side, then go back to Debian project. Thanks for your cooperation. Takashi Sakamoto
Bug#822923: Fwd: Bug#822923: Acknowledgement (base: Lenovo ThinkPad x220 tablet built in camera failes to work as expected.)
Could you please close this ticket. The issue resolved as of right now. This malfunction occurred due to the hardware failure and NOT due to the any sort of OS related issues. I'm sorry for taking your time. Damien. --- Begin Message --- Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to skyguide.b...@icloud.com (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Base Maintainers If you wish to submit further information on this problem, please send it to 822...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 822923: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822923 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- End Message ---
Bug#823012: Transition to librrd8: collectd fails to detect thread safety
Source: collectd Version: 5.5.1-2 Severity: normal Tags: upstream Dear maintainer As of version 1.6 of rrdtool, librrd is thread safe without using the special librrd_th.so. Actually, that file no longer exists. As a consequence, collectd's configure outputs: librrd . . . . . . . yes (warning: librrd is not thread-safe) I haven't tested, but I believe HAVE_THREADSAFE_LIBRRD will be false. This will trigger a new set of code being compiled. Please ensure collectd is still working correctly. Hopefuly this will only trigger extra mutex locking for nothing. I'm not sure how to properly fix that. Maybe if pkg-config --atleast-version=1.6 librrd then HAVE_THREADSAFE_LIBRRD should be true while linking with basic -lrrd.
Bug#823011: libhinawa: avoid build non-linux arch
package: libhinawa
severity: normal
tags: patch
Hi,
non-linux arch build was failed with
>> internal.h:8:33: fatal error: linux/firewire-cdev.h: No such file or
>> directory
debian/control says "arch: any" but it seems that it should be linux-any
--
Regards,
Hideki Yamane henrich @ debian.or.jp/org
http://wiki.debian.org/HidekiYamane
diff -Nru libhinawa-0.7.0/debian/changelog libhinawa-0.7.0/debian/changelog
--- libhinawa-0.7.0/debian/changelog 2016-02-05 22:10:34.0 +0900
+++ libhinawa-0.7.0/debian/changelog 2016-04-30 08:17:30.0 +0900
@@ -1,3 +1,12 @@
+libhinawa (0.7.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/control
+- set Architecture: linux-any for all package to avoid build with non-linux
+ arch.
+
+ -- Hideki Yamane Sat, 30 Apr 2016 08:16:37 +0900
+
libhinawa (0.7.0-1) unstable; urgency=medium
* New upstream release 0.7.0
diff -Nru libhinawa-0.7.0/debian/control libhinawa-0.7.0/debian/control
--- libhinawa-0.7.0/debian/control 2016-02-05 22:07:56.0 +0900
+++ libhinawa-0.7.0/debian/control 2016-04-30 08:12:57.0 +0900
@@ -14,7 +14,7 @@
Vcs-Browser: https://github.com/takaswie/libhinawa.git
Package: libhinawa0
-Architecture: any
+Architecture: linux-any
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends},
libglib2.0-0 (>= 2.32.0)
@@ -38,7 +38,7 @@
Package: libhinawa-dev
Section: libdevel
-Architecture: any
+Architecture: linux-any
Depends: ${misc:Depends},
libhinawa0 (= ${binary:Version}),
libglib2.0-dev (>= 2.32.0),
Bug#822941: debian-installer: cannot boot installed on VirtualBox with EFI-enabled
Control: tag -1 moreinfo On Fri, Apr 29, 2016 at 05:33:47PM +0900, Hideki Yamane wrote: >Package: debian-installer >Severity: important > >Dear Maintainer, > > I found user notes Debian on VBox with EFI enabled environment cannot > boot, see http://qiita.com/zakuro9715/items/45e82473ce39914e04ed (in Japanese) > > I've confirmed it with d-i9 alpha5. > And, it doesn't happen with Fedora 24 alpha and Ubuntu 16.04. > > >Step to reproduce: > > 1. setup Virtualbox VM with EFI enabled > 2. install Debian > 3. after installation, turn of VM > 4. turn on VM again > 5. not bootable, startup EFI shell Do we know what version of Virtualbox? That could be a major factor here. I've just a test installation using the UEFI support in the virtualbox package in Jessie (4.3.36), which is labelled as "experimental support". It shows the same behaviour as described, but that's a limitation of the virtualbox UEFI support rather than a problem in Debian - the underlying virtualbox isn't saving EFI variables persistently. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Bug#805183: ntp: bump Breaks+Replaces against apparmor-profiles-extra
Followup-For: Bug #805183 Control: found -1 1:4.2.8p7+dfsg-2 Control: block -1 with 768415 Control: severity -1 serious Hi, there has been a new upload of apparmor-profiles-extra which still ships the ntp profile, so the Breaks+Replaces version in ntp needs to be bumped. Andreas
Bug#768415: apparmor-profiles-extra: drop ntpd profile
Followup-For: Bug #768415 Control: tag -1 sid stretch Control: severity -1 serious Control: found -1 1.7 ntp now ships the apparmor profile, so apparmor-profiles-extra needs to stop doing this, too. Andreas
Bug#823010: RFS: gap-float/0.6.3+ds-3 [DCI] - multi-precision floating-point computation for GAP
Package: sponsorship-requests Severity: normal Dear Sponsors, I am looginh for a Sponsor for the Debian pacakge gap-float [1], a GAP package allowing multi-precision floating-point computation. This very version mainly introduces Debian Continuous Integration (DCI) to the package. Thanks in advance, Jerome [1] https://anonscm.debian.org/git/debian-science/packages/gap-float.git -- System Information: Debian Release: Jessie* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.7-ckt20-0001-mbp62 (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 Init: sysvinit (via /sbin/init)
Bug#823002: transition: nvidia-cuda-toolkit 7.5
On 2016-04-30 00:06, Mattia Rizzolo wrote: > [ off-list, as I'd kinda prefer avoid disturbing the RT with this ] > > On Fri, Apr 29, 2016 at 10:43:36PM +0200, Andreas Beckmann wrote: >> eztrace-contrib, hwloc-contrib and pycuda are fine and just need a >> binNMU (maintainer-uploaded since this involves non-free). > > Is somebody planning to do these? > I know pochu doesn't do them, and I know you did some manual binNMU in > the past (so did I), also, I noticed all of them saw a recent maintainer > upload. > > Is the plan poking the maintainers and have them make a regular upload > of them (2 out of 3 being from sthibaut should make this easy), or > should somebody build a manual binNMU? Samuel or I will take care of these. Andreas
Bug#819390: linux-image-4.5.0-trunk-armmp-lpae: Ethernet on Firefly-RK3288
On Sun, 27 Mar 2016 15:13:16 -0700 Vagrant Cascadian wrote: > When upgrading to linux 4.5-1~exp1, the ethernet no longer responds > correctly. Downgrading back to 4.4.6-1 from sid/stretch fixes the issue. I just want to add I still see this problem on a Cubietruck with linux-image-4.5.0-1-armmp-lpae 4.5.1-1. Only way to get the network back is to downgrade to 4.4.6-1. Related LKML thread: https://lkml.org/lkml/2016/3/15/63 Grüße, Sven.
Bug#821442: regression between linux-image linux-image-4.4.0-1-amd64 and linux-image-4.5.0-1-amd64
I just booted using linux-image-4.5.0-2-amd64 and this solves my docker problem. Thanks a lot for taking care of this! On Fri, Apr 22, 2016 at 11:05 AM, Norbert Kiesel wrote: > This problem does not happen when I boot the 4.4.0 kernel, but > consistently happens with the 4.5.0 kernel. > > How to reproduce: > > >1. start docker daemon >2. start docker container `docker start ` >3. switch to shell inside the docker container `docker exec -it >bash` >4. create a file `touch a` >5. try to read it `cat a` => this fails with "Operation not >permitted". In fact, any file read operation fails > > "journalcrl -f" on the host shows "EXT4-fs warning (device sdb1): > ext4_file_open:387: Inconsistent encryption contexts: 1379030/12058997". > > I'm using overlayfs for docker on top of ext4. Googling for "Inconsistent > encryption contexts" leads to https://lkml.org/lkml/2016/3/10/713, which > leads to https://lkml.org/lkml/2016/3/14/274. That patch mentioned there > never made it into the kernel, but the patch I referenced seems to be the > logical successor (renamed some things, and also fixes nfs). >
Bug#818502: backport to jessie?
Hello, Are there plans to backport this to the standard Jessie kernel? Thanks!
Bug#822974: [pkg-gnupg-maint] Bug#822974: backport for jessie
On Fri, 29 Apr 2016 16:36, rc...@drexel.edu said: > format. Every time you import or sign a new key, you will have to > remember to do the operation with both gpg and gpg2. For me, I have > been able to live with 2.1 only, but others may not be able to. If you already have keys in a pubring.gpg, gpg 2.1 will continue to use it. It should also be possible to patch gpg 2.1 to create the old style pubring.gpg by default. This the remaining problem is the secring.gpg which is indeed not used by gpg 2.1. So changing a passphrase, creating, or importing a secret key needs to be re-done with gpg1. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Bug#819859: fixed in sawfish 1:1.11.90-1
Dave's suggestions seem to have cleared up most of my problems with version 1:1.11.90-1. I did have (require 'sawfish.wm.ext.edge-flip) in my .sawfishrc, and changing that to (require 'edge-flip) allowed sawfish to start normally. I do not use a custom theme, just Strap, but I do use sawfish-merlin-ugliness (version 1.3.1-1), and /usr/share/sawfish/site-lisp/merlin/uglicon.jl has some ":user-level expert" lines in it. When I commented out those lines, the "Unbound variable: expert" errors went away (and merlin-ugliness reappeard in my sawfish customization menus). This problem seems to be as old as 2011 (see https://listengine.tuxfamily.org/lists.tuxfamily.org/sawfish/2011/07/msg00012.html ), so I'm not sure why I didn't encounter it before. I notice that several of the themes in sawfish-themes still have the "user-level: xx" lines in them as of version 0.13 (Empire, FinalStep, Greene2.0, SawthenaForever, Titanium). So presumably users of these themes will still have problems --- I tried switching to one and was unable to do so because of the "unbound variable" error. The "No such file or directory, gnome" pop-up on start is still present, but I don't see any actual problems. The installation complaint about the emacs sawfish mode is also still there, but I don't use emacs, so I can't really evaluate it. After I got past all that and got sawfish running, I also discovered that edge-flipping between viewports had stopped working --- it seems to have some-how gotten de-activated because of alterations made to the options for edge actions? This was briefly disturbing until I figured it out, but easily fixable. :) So I'm up and running now, but it seems like there may still be a few small items in sawfish and related packages which will require cleanup for other users? Just for completeness, I've included my updated system information for the working configuration below. - Anne -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sawfish depends on: ii libatk1.0-0 2.20.0-1 ii libc62.22-7 ii libcairo21.14.6-1+b1 ii libfontconfig1 2.11.0-6.4 ii libfreetype6 2.6.3-3+b1 ii libgdk-pixbuf2.0-0 2.34.0-1 ii libglib2.0-0 2.48.0-1 ii libgmp10 2:6.1.0+dfsg-2 ii libgtk2.0-0 2.24.30-1.1 ii libice6 2:1.0.9-1+b1 ii libpango-1.0-0 1.40.1-1 ii libpangocairo-1.0-0 1.40.1-1 ii libpangoft2-1.0-01.40.1-1 ii libpangoxft-1.0-01.40.1-1 ii librep16 0.92.5-3 ii libsm6 2:1.2.2-1+b1 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxft2 2.3.2-1 ii libxinerama1 2:1.1.3-1+b1 ii libxrandr2 2:1.5.0-1 ii libxrender1 1:0.9.9-2 ii libxtst6 2:1.2.2-1+b1 ii rep 0.92.5-3 ii rep-gtk 1:0.90.8.2-3 ii sawfish-data 1:1.11.90-1 ii xterm [x-terminal-emulator] 324-1 sawfish recommends no packages. Versions of packages sawfish suggests: ii gnome-control-center 1:3.20.1-1 ii menu 2.1.47 ii yelp 3.20.1-1 -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#823009: pysycache: FTBFS: dh_install: Cannot find (any matches for) "usr/share/games/pysycache/themes-dblclick/butterfly/pysycache/themes-dblclick/butterfly/*.dfg" (tried in ".")
Source: pysycache Version: 3.1-3.1 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, pysycache fails to build from source in unstable/amd64: [..] dh_testdir dh_testroot dh_prep dh_testdir dh_testroot dh_install dh_installdocs dh_installchangelogs dh_compress dh_fixperms dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'pysycache-build-deps' in '../pysycache-build-deps_3.1-3.1_all.deb'. The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the message above! Selecting previously unselected package pysycache-build-deps. (Reading database ... 23035 files and directories currently installed.) Preparing to unpack pysycache-build-deps_3.1-3.1_all.deb ... Unpacking pysycache-build-deps (3.1-3.1) ... Reading package lists... Building dependency tree... Reading state information... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up pysycache-build-deps (3.1-3.1) ... dpkg-buildpackage -rfakeroot -D -us -uc -b dpkg-buildpackage: source package pysycache dpkg-buildpackage: source version 3.1-3.1 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Andrey Rahmatullin dpkg-source --before-build pysycache-3.1 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp /usr/bin/make -f debian/rules unpatch make[1]: Entering directory '/home/lamby/temp/cdt.20160429224554.0u9nin5sfG.pysycache/pysycache-3.1' QUILT_PATCHES=debian/patches \ quilt --quiltrc /dev/null pop -a -R || test $? = 2 Removing patch console_encoding.patch Restoring pysycache/pysycache.py Removing patch spanish_translation.patch Restoring linux/usr/share/applications/pysycache-admin.desktop Restoring linux/usr/share/applications/pysycache.desktop Restoring pysycache/lang/es_ES/menu18.txt Restoring pysycache/lang/es_ES/menu7.txt Restoring pysycache/lang/es_ES/menu10.txt Restoring pysycache/lang/es_ES/menu14.txt Restoring pysycache/lang/es_ES/menu19.txt Removing patch fast_quitting.patch Restoring pysycache/pysycache.py No patches applied rm -rf .pc debian/stamp-patched make[1]: Leaving directory '/home/lamby/temp/cdt.20160429224554.0u9nin5sfG.pysycache/pysycache-3.1' dh_clean debian/rules build QUILT_PATCHES=debian/patches \ quilt --quiltrc /dev/null push -a || test $? = 2 Applying patch fast_quitting.patch patching file pysycache/pysycache.py Applying patch spanish_translation.patch patching file pysycache/lang/es_ES/menu10.txt patching file pysycache/lang/es_ES/menu14.txt patching file pysycache/lang/es_ES/menu18.txt patching file pysycache/lang/es_ES/menu19.txt patching file pysycache/lang/es_ES/menu7.txt patching file linux/usr/share/applications/pysycache.desktop patching file linux/usr/share/applications/pysycache-admin.desktop Applying patch console_encoding.patch patching file pysycache/pysycache.py Now at patch console_encoding.patch touch debian/stamp-patched dh_testdir touch configure-stamp dh_testdir touch build-stamp fakeroot debian/rules binary dh_testdir touch configure-stamp dh_testdir touch build-stamp dh_testdir dh_testroot dh_clean -k dh_clean: dh_clean -k is deprecated; use dh_prep instead chmod +x debian/game.sh dh_installdirs cp /home/lamby/temp/cdt.20160429224554.0u9nin5sfG.pysycache/pysycache-3.1/debian/pysycache.lintian-overrides /home/lamby/temp/cdt.20160429224554.0u9nin5sfG.pysycache/pysycache-3.1/debian/pysycache/usr/share/lintian/overrides/pysycache dh_testdir dh_testroot dh_installchangelogs dh_installdocs dh_installexamples dh_install dh_install: Cannot find (any matches for) "usr/share/games/pysycache/themes-dblclick/butterfly/pysycache/themes-dblclick/butterfly/*.dfg" (tried in ".") dh_install: missing files, aborting debian/rules:36: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 255 [..] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- pysycache.3.1-3.1.unstable.amd64.log.txt.gz Description: Binary data
Bug#823008: ITP: wait-for-it -- script that will wait on the availability of a host and TCP port
Package: wnpp Severity: wishlist Owner: Alexandre Viau * Package name: wait-for-it Version : TBD Upstream Author : Giles Hall * URL : https://github.com/vishnubob/wait-for-it * License : Expat Programming Lang: Shell Description : script that will wait on the availability of a host and TCP port I keep having to bake in similar functionnality in my debian-based docker containers. This script is simple and works well. Lets put an end to all the duplication. -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#817005: RFS: aseqjoy/0.0.1-1 [ITP]
On Fri, Apr 29, 2016 at 08:45:27PM +, Gianfranco Costamagna wrote: > >Fixed. Is possible to have upstream => gpl2 and debian/* => gpl3, true? > > this means that it will be impossible to forward patches upstream without > manually > relicensing them. > > I personally don't prefer, because only the author of each patch will be able > to forward > it upstream. It's worse: as the package is built from sources under mutually conflicting licenses, it is indistributable. As both the packaging and the only patch come exclusively from you, I'd simply change the license for debian/* to GPL-2+ (but, see below). > licensecheck * > shows the license of some files as GPL-2+ not GPL-2 It looks like there's a mismatch: README says: # Copyright 2003 by Alexander K.nig - a...@lisas.de # License: GPL V2 - see the file COPYING (COPYING is the text of GPL-2) but, aseqjoy.c says: # or (at your option) any later version. Too bad, while it's the only C source, there's one more copyrightable file, aseqjoy.1.in, which doesn't embed a license statement and thus is covered by the README. So unless you contact the author or rewrite the manpage, the effective license is GPL-2 only. -- A tit a day keeps the vet away.
Bug#823007: icedove: stderr noise: *** BUG *** In pixman_region32_reset: Malformed region region
Package: icedove Version: 38.7.2-1 Severity: minor icedove's stderr regularly shows the following errors for me: - *** BUG *** In pixman_region32_reset: Malformed region region Set a breakpoint on '_pixman_log_error' to debug - This is additional noise that is distracting from what might be more useful feedback on stderr. It would be great to sort out and fix the cause of it, so that icedove stderr has a higher signal-to-noise ratio. --dkg -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages icedove depends on: ii debianutils 4.7 ii fontconfig2.11.0-6.4 ii libasound21.1.0-1 ii libatk1.0-0 2.20.0-1 ii libc6 2.22-7 ii libcairo2 1.14.6-1+b1 ii libdbus-1-3 1.10.8-1 ii libdbus-glib-1-2 0.106-1 ii libevent-2.0-52.0.21-stable-2+b1 ii libffi6 3.2.1-4 ii libfontconfig12.11.0-6.4 ii libfreetype6 2.6.3-3+b1 ii libgcc1 1:5.3.1-14 ii libgdk-pixbuf2.0-02.34.0-1 ii libglib2.0-0 2.48.0-1 ii libgtk2.0-0 2.24.30-1.1 ii libhunspell-1.3-0 1.3.4-2 ii libnspr4 2:4.12-2 ii libnss3 2:3.23-2 ii libpango-1.0-01.40.1-1 ii libpangocairo-1.0-0 1.40.1-1 ii libpangoft2-1.0-0 1.40.1-1 ii libpixman-1-0 0.33.6-1 ii libsqlite3-0 3.12.1-1 ii libstartup-notification0 0.12-4 ii libstdc++65.3.1-14 ii libvpx3 1.5.0-2 ii libx11-6 2:1.6.3-1 ii libxcomposite11:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.1-2+b2 ii libxrender1 1:0.9.9-2 ii libxt61:1.1.5-1 ii psmisc22.21-2.1+b1 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages icedove recommends: ii iceowl-extension 38.7.2-1 pn myspell-en-us | hunspell-dictionary | myspell-dictionary Versions of packages icedove suggests: ii fonts-lyx 2.1.4-2 ii libgssapi-krb5-2 1.13.2+dfsg-5 -- debconf-show failed
Bug#823006: license issue in hyperic-sigar
Package: hyperic-sigar
Version: 1.6.4+dfsg-2.1
Severity: serious
This package contains the file
bindings/java/src/org/hyperic/sigar/util/PrintfFormat.java with the
license attached.
The addition to the license:
You acknowledge that Software is not designed, licensed or intended
for use in the design, construction, operation or maintenance of any
nuclear facility ("High Risk Activities").
seems to make it free-open source (restricts the licensing to one
domain --nuclear facilities).
// Permission to use, copy, modify, and distribute this Software and its
// documentation for NON-COMMERCIAL or COMMERCIAL purposes and without fee
is
// hereby granted.
//
// This Software is provided "AS IS". All express warranties, including any
// implied warranty of merchantability, satisfactory quality, fitness for a
// particular purpose, or non-infringement, are disclaimed, except to the
extent
// that such disclaimers are held to be legally invalid.
//
// You acknowledge that Software is not designed, licensed or intended for
use in
// the design, construction, operation or maintenance of any nuclear
facility
// ("High Risk Activities"). Sun disclaims any express or implied warranty
of
// fitness for such uses.
//
--
Daniel M. German "That the only purpose for
which power can be rightfully exercised
over any member of a civilized
community, against his will,
is to prevent harm to others.
His own good, either physical
John Stuart Mill -> or moral, is not a sufficient warrant."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
Bug#823005: pepperflashplugin-nonfree: Missing PGP key
Package: pepperflashplugin-nonfree Version: 1.8.1 Severity: grave Justification: renders package unusable Hi, Google apparently started using a new PGP key, which leads to: # update-pepperflashplugin-nonfree --install ERROR: failed to retrieve status information from google : W: There is no public key available for the following key IDs: A040830F7FAC5991 More information might be available at: http://wiki.debian.org/PepperFlashPlayer I tried updating to 1.8.2, no change. Appending the new key to /usr/lib/pepperflashplugin-nonfree/pubkey-google.txt solves the problem for me. The old key seems to still be needed, since with only the new key ih pubkey-google.txt I'm getting the same error with a different key id. Regards, Andreas -- System Information: Debian Release: 8.4 APT prefers stable Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages pepperflashplugin-nonfree depends on: ii binutils2.25-5 ii ca-certificates 20141019+deb8u1 ii cdebconf [debconf-2.0] 0.192 ii debconf [debconf-2.0] 1.5.56 ii gnupg 1.4.18-7+deb8u1 ii libatk1.0-0 2.14.0-1 ii libcairo2 1.14.0-2.1+deb8u1 ii libcurl3-gnutls 7.38.0-4+deb8u3 ii libfontconfig1 2.11.0-6.3 ii libfreetype62.5.2-3+deb8u1 ii libgcc1 1:4.9.2-10 ii libglib2.0-02.42.1-1+b1 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libnspr42:4.10.7-1+deb8u1 ii libnss3 2:3.17.2-1.1+deb8u2 ii libpango-1.0-0 1.36.8-3 ii libpango1.0-0 1.36.8-3 ii libstdc++6 4.9.2-10 ii libx11-62:1.6.2-3 ii libxext62:1.3.3-1 ii libxt6 1:1.1.4-1+b1 ii wget1.16-1 pepperflashplugin-nonfree recommends no packages. Versions of packages pepperflashplugin-nonfree suggests: ii chromium 50.0.2661.75-1~deb8u1 pn hal ii ttf-dejavu 2.34-1 ii ttf-mscorefonts-installer 3.6 ii ttf-xfree86-nonfree4.2.1-4 -- no debconf information
Bug#822861: killall: option --older-than breaks with german locale
tag 822861 unreproducible thankyou Works ok here: $ sleep 5 & LC_ALL=de_DE.UTF-8 killall --older-than 1h sleep [1] 20927 sleep: Kein Prozess gefunden Normally a locale problem would be a strtol related issue and those options use that function, but its often related to decimal point versus comma. It's also strange its not even throwing an error if it didn't understand the parsing. Does it do that for other units such as minute? On Thu, Apr 28, 2016 at 11:03 PM Jörg Ludwig wrote: > Package: psmisc > Version: 22.21-2 > Severity: normal > > Dear Maintainer, > > we wanted to kill stale programs with "killall --older-than". > > This works just fine with locale "C": > > # sleep 5 & LC_ALL=C killall --older-than 1h sleep > [1] 10858 > sleep: no process found > > But with our locale "de_DE.UTF-8" it also kills newly created processes: > > # sleep 5 & LC_ALL=de_DE.UTF-8 killall --older-than 1h sleep > [1] 10711 > [1]+ Beendet sleep 5 > > We would expect killall to work regardless of the used locale. > > -- System Information: > Debian Release: 8.4 >APT prefers stable-updates >APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: i386 (x86_64) > Foreign Architectures: amd64 > > Kernel: Linux 3.14-0.bpo.2-amd64 (SMP w/8 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: unable to detect > > Versions of packages psmisc depends on: > ii libc6 2.19-18+deb8u4 > ii libtinfo5 5.9+20140913-1+b1 > > psmisc recommends no packages. > > psmisc suggests no packages. > > -- no debconf information > > -- > Mit freundlichen Grüßen, > > Jörg Ludwig > > IServ GmbH > Bültenweg 73 > 38106 Braunschweig > > Telefon: 0531-2243666-0 > Fax: 0531-2243666-9 > Mobil: 0179-9101055 > E-Mail: joerg.lud...@iserv.eu > Internet:www.iserv.eu > USt.-IdNr.: DE265149425 > -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Bug#822993: meld: In directory comparison, drop-down menu for file filters is not positioned correctly
Control: tags -1 confirmed upstream fixed-upstream Hi Kyanos, 2016-04-29 21:00 GMT+02:00 Kyanos : > Package: meld > Version: 3.14.2-1 > Severity: minor > > Dear Maintainer, > > When running a directory comparison, there is a "Filters" button to set > file filters (for example, to ignore backup files in the diff). > > When I click that button, the drop-down box does not appear under the > button as expected. Instead, it appears at the top-left corner of the > desktop. Also, the following error message appears on standard output > every time I click it: > >> TypeError: position_menu_under_widget() takes exactly 2 arguments (4 > given) > > Thank you for your consideration. Upstream already fixed the issue in 3.15.3 or in an earlier release. Since this is a minor issue I plan fixing it in the next stable release after 3.15.3. Thank you for the bug report. Cheers, Balint
Bug#823004: gplaycli: sensitive information in config file
Package: gplaycli Version: 0.1.2+git15~g20f65ca-1 Severity: normal Dear Maintainer, you ship your gmail credentials in the configuration file. Please ask the user to enter his own credentials during package installation. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gplaycli depends on: ii androguard 2.0-1 ii python-clint0.5.1-1 ii python-ndg-httpsclient 0.4.0-3 ii python-protobuf 2.6.1-1.3 ii python-pyasn1 0.1.9-1 ii python-requests 2.9.1-3 pn python:any Versions of packages gplaycli recommends: ii fdroidserver 0.6.0-2 gplaycli suggests no packages. -- Configuration Files: /etc/gplaycli/credentials.conf changed [not included] -- no debconf information
Bug#823003: makedumpfile: kdump support for UEFI Secure Boot
Package: makedumpfile
Version: 1:1.5.9-5
Severity: wishlist
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In support of UEFI Secure Boot in Debian stretch (#820036), update
kdump-tools to use kexec_file_load when in secure mode.
Specifically, kdump-config needs to query the state of UEFI Secure Boot in
order to use the kexec_file_load system call boot the crash kernel when
Secure Boot is enabled.
I have attached a patch to kdump-config with this change.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBAgAGBQJXI8hXAAoJEF/3aG7d/FTW2LEP/1JpPODXgt4Tp/3El5FgFQGX
56Ls6f34oH2tfmWCYZJrCkb2D1XN13hpQ3VcICXgwMD1ECLiCvirywHCW7bCUn+J
B0jbYyt5eeL3/CEJgVTh6yN/E9vvPUS5QA5pr7cUdMqsTBq7yOoy3YeSv95Ft0W2
xSBmq5JmULyO7orexKPAMnd6S24efur3L+4KCj43DtZLvb4YKzZFelETTU6DT7V8
8+KVDpcDJ8+FGhCWK9HtI7oUj6fdsYAueutD+Z+Cjj6iOaGoyYGfoo7uaYqQxJf6
pFhJ1kWZfc0ChXNZ1hCo3jWNF9EPgrx0QAjjv1jNMTQomb0CivoQrT0GBh8XNp/H
vIDQL839L15oo+6MUgv4fdR8Q48GBwxn2/8hYuE1KLoBNtyGgagJ+re+b1Wh3K57
wQfeGJfFME30lSSvDR9JvXIcUwijVO7fIDODNAHX4Eq/+zeSIqBcw4WfDV3wWGHU
dRRkY1AyIogO3MNgvgK/UUjnDrP8B+D9lsv2eDy4q3dFZWYaNip2yA4P+Kt3eOTB
n/bB+HgnR8VSsNrh4AmzJfw2vDyE9tz709vTkWePdnaY5dzW74Ihl9Qwe/H9CWlX
D5wDI8cGnk7r0iwycrYt42/i3T2huoX85pKl5iVptpwSMx1qnR0KUtTyiSU9q609
t/krosiT/MQZ6+9zNpYn
=4XBN
-END PGP SIGNATURE-
>From 8457b1664a1fbb287dbc3eed26fa204c647acf32 Mon Sep 17 00:00:00 2001
From: Linn Crosetto
Date: Fri, 29 Apr 2016 14:26:11 -0600
Subject: [PATCH] kdump-tools: add support for UEFI Secure Boot
kdump-config needs to query the state of UEFI Secure Boot in order to correctly
use kexec to boot the crash kernel. Specifically, kexec needs the "-s" option
to use the kexec_file_load system call to validate the image before loading it.
Signed-off-by: Linn Crosetto
---
debian/kdump-config | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/debian/kdump-config b/debian/kdump-config
index 0ff0e6f..9fb00ac 100755
--- a/debian/kdump-config
+++ b/debian/kdump-config
@@ -318,6 +318,40 @@ function check_relocatable()
fi
}
+function check_securelevel()
+{
+ local sl_path="/sys/kernel/security/securelevel"
+ if [ ! -f "$sl_path" ]; then
+ return 1
+ fi
+
+ if [ "$(cat "$sl_path")" = "1" ]; then
+ return 0
+ fi
+
+ return 1
+}
+
+
+function check_secure_boot()
+{
+ local sb_path sm_file sb sm
+
+ sb_path=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null)
+ sm_path=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null)
+
+ if [ -f "$sb_path" ] && [ -f "$sm_path" ]; then
+ sb=$(hexdump -v -e '/1 "%d\ "' $sb_path|cut -d' ' -f 5)
+ sm=$(hexdump -v -e '/1 "%d\ "' $sm_path|cut -d' ' -f 5)
+
+ if [ "$sb" = "1" ] && [ "$sm" = "0" ]; then
+ return 0
+ fi
+ fi
+
+ return 1
+}
+
# Find the kexec/kdump kernel and possibly a corresponding initrd.
# A kdump kernel does not need to match the `uname -r` of the booted kernel.
#
@@ -466,6 +500,10 @@ function kdump_load()
# assemble the kexec command used to load the kdump kernel
KEXEC_CMD="$KEXEC -p"
+ if check_secure_boot || check_securelevel; then
+ KEXEC_CMD="$KEXEC_CMD -s"
+ fi
+
# Different kernel types allow/require different options:
# The only special case here is that x86, x86_64 elf style
# binaries require the --args-linux argument.
@@ -524,7 +562,12 @@ function kdump_load()
# Returns: none. prints warnings or exit
function kdump_unload()
{
- $KEXEC -p -u
+ if check_secure_boot || check_securelevel; then
+ $KEXEC -s -p -u
+ else
+ $KEXEC -p -u
+ fi
+
if [ $? == 0 ]; then
log_success_msg "unloaded kdump kernel"
logger -t $NAME "unloaded kdump kernel"
--
2.8.0.rc3
Bug#817005: RFS: aseqjoy/0.0.1-1 [ITP]
Hi, sorry for the lag >Fixed. Is possible to have upstream => gpl2 and debian/* => gpl3, true? this means that it will be impossible to forward patches upstream without manually relicensing them. I personally don't prefer, because only the author of each patch will be able to forward it upstream. >> Standards-Version: 3.9.6 --> 3.9.7 now > >Fixed. sorry, 3.9.8 now :) >Thanks for your review, i just upload to mentors with these fixes. licensecheck * shows the license of some files as GPL-2+ not GPL-2 please check licenses carefully, otherwise the package will be rejected by ftpmasters. cheers, G.
Bug#823002: transition: nvidia-cuda-toolkit 7.5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Forwarded: https://release.debian.org/transitions/html/auto-nvidia-cuda-toolkit.html Hi, the next release of nvidia-cuda-toolkit/non-free has arrived in experimental and is ready for upload to unstable. eztrace-contrib, hwloc-contrib and pycuda are fine and just need a binNMU (maintainer-uploaded since this involves non-free). starpu-contrib needs a sourceful upload to switch from gcc-4.9 to gcc-5 (the previous toolkit version didn't support gcc-5). Samuel will do this quickly. Andreas
Bug#746005: guile-2.0 migration
On Fri, 29 Apr 2016, Emilio Pozuelo Monfort wrote: > We talked about this on the RT meeting yesterday and agreed to bump > this to RC again. We wouldn't like to release Stretch with guile-1.8 > just for lilypond's sake, and it is better to act now that there's > plenty of time before the freeze so that a new version can be uploaded > (possibly to experimental for the time being) and fixes can be > applied. OK. Basically, there's no way that 2.18 will be fixed to work with Guile 2.0, but assuming that 2.20 gets released before stretch, this will be workable. > We can discuss this again later in the cycle if necessary, though > hopefully lilypond can get in shape and we won't need to do that :) Well, the shape that will be required is the release of a stable lilypond release which supports guile. Hopefully soon. > There have been plenty of 'unstable' releases (last one was 2.19.40 > just a few days ago) and those have a --with-guile2 configure switch. > It may be a good idea to upload that to experimental with guile 2.0 > support? Sure, but this won't fix the version of lilypond in unstable. [I at least do not have the time to support a development release of lilypond through the lifetime of a stable release.] Are auto-removals from testing currently off? [Basically, I'd like to avoid having lilypond removed from testing until we're closer to the release if that's at all possible.] -- Don Armstrong https://www.donarmstrong.com A Bill of Rights that means what the majority wants it to mean is worthless. -- U.S. Supreme Court Justice Antonin Scalia
Bug#712841: A bit late, but still an issue...
Hi all, I've just upgraded my trusty and apparently indestructable TS-119 to Jessie and stumbled over this bug. I've simply commented-out the line that increases the fan error count and the beeping has stopped but I see log entries which show qcontrol trying to set fan speeds due to temperature measurements. Long story cut short: if there is a way to identify TS-119 vs. TS-219 hardware, a fix would be very welcome. If not, I guess an option in /etc/default/qcontrol to simply disable any kind of thermal management involving fans would be nice, too (overtemp handling excluded, of course) Thanks, --Christian
Bug#823001: ITP: dfdatetime -- Digital Forensics date and time library
Package: wnpp Owner: Hilko Bengen Severity: wishlist * Package name: dfdatetime Version : 20160323 Upstream Author : Google Inc., Kristinn Gudjonsson, Joachim Metz, Daniel White * URL or Web page : https://github.com/log2timeline/dfdatetime * License : Apache 2.0 Description : Digital Forensics date and time library dfdatetime (python-dfdatetime) is a dependency for newer version of dfvfs which is needed for Plaso.
Bug#823000: borgbackup: Always backs up the newest file in repository
Package: borgbackup Version: 1.0.2-1 Severity: normal Dear Maintainer, borgbackup seems to always back up the newest file in the repository, even if it remains unmodified. Usually this is unnoticeable, but introduces a considerable delay when it's a large file. Here A is a 6.3GB sized file that remains unchanged during the whole test process and is B an empty file created just before the second backup takes place. Day Newest file Newest backed file backup time -- -- --- 2016-04-27 AA 1 minute 48.69 seconds 2016-04-28 BA 1 minute 53.15 seconds 2016-04-29 BB 1.62 seconds The output of those backups: - Archive name: 2016-04-27 Archive fingerprint: 4d8599b40d331b19aa1615a87a507eca225a85a35886ce9f3468ac6097ad75e4 Time (start): Wed, 2016-04-27 08:42:06 Time (end): Wed, 2016-04-27 08:43:54 Duration: 1 minutes 48.69 seconds Number of files: 272 -- Original size Compressed sizeDeduplicated size This archive: 587.54 GB587.54 GB 9.32 kB All archives:6.46 TB 6.46 TB591.39 GB Unique chunks Total chunks Chunk index: 110990 1210483 -- -- Archive name: 2016-04-28 Archive fingerprint: feaab28f518d62a9bb9d0a0362c217c46e676c046a55d74f827f5c2cb4886431 Time (start): Thu, 2016-04-28 11:54:26 Time (end): Thu, 2016-04-28 11:56:19 Duration: 1 minutes 53.15 seconds Number of files: 273 -- Original size Compressed sizeDeduplicated size This archive: 587.54 GB587.54 GB 69.48 kB All archives:6.46 TB 6.46 TB591.39 GB Unique chunks Total chunks Chunk index: 110993 1210484 -- -- Archive name: 2016-04-29 Archive fingerprint: 26fa3e49300b6c0d7bfb2da62e215b2ad3ef5e7feaa60f88bed914f06657fd88 Time (start): Fri, 2016-04-29 11:46:34 Time (end): Fri, 2016-04-29 11:46:36 Duration: 1.62 seconds Number of files: 273 -- Original size Compressed sizeDeduplicated size This archive: 587.54 GB587.54 GB 9.35 kB All archives:6.46 TB 6.46 TB591.39 GB Unique chunks Total chunks Chunk index: 110993 1210485 -- -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.1 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages borgbackup depends on: ii libacl12.2.52-3 ii libc6 2.22-7 ii liblz4-1 0.0~r131-2 ii libssl1.0.21.0.2g-1 ii python33.5.1-3 ii python3-msgpack0.4.6-1+b2 ii python3-pkg-resources 20.7.0-1 Versions of packages borgbackup recommends: ii python3-llfuse 1.0+dfsg-2 Versions of packages borgbackup suggests: ii borgbackup-doc 1.0.2-1 -- no debconf information Kind regards, -- Manolo Díaz
Bug#822999: ITP: libfwnt -- a library for Windows NT data types
Package: wnpp Owner: Hilko Bengen Severity: wishlist * Package name: libfwnt Version : 20160418 Upstream Author : Joachim Metz * URL or Web page : https://github.com/libyal/libfwnt * License : LGPL-3.0+ Description : a library for Windows NT data types libfwnt is a dependency for newer versions of dfvfs which is needed for Plaso.
Bug#822443: Acknowledgement (linux-image-4.4.0-1-amd64: Dell XPS-13 9350 (DE) backlight not detected)
I have since discovered that: * On this machine the i915 driver is responsible for the backlight control too. * The i915 driver registers the backlight device in the modesetting path (!) * Although "nomodeset" was required to get the kernel from stretch Alpha 5 to not produce a black screen shortly after booting into the installed system, linux-image-4.4.0-1-amd64 4.4.6-1 works fine without "nomodeset" (and seems to set the mode during boot as expected). There seems little point in reporting any bug against the stretch alpha 5 kernel as I'm sure it will be updated in due course. * Booting linux-image-4.4.0-1-amd64 4.4.6-1 without "nomodeset" - produces /sys/class/backlight/intel_backlight and working backlight control buttons - seems to suspend and resume fine (4 trials so far) I will close this bug. Sorry for the noise. Ian.
Bug#822998: squid3: warning: package could avoid a useless dependency [...]
Source: squid3
Version: 3.5.17-1
Severity: minor
Tags: patch
Dear Maintainer,
While rebuilding squid package, I noticed some warnings:
...
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/squidclient/usr/bin/squidclient was not linked against
libnettle.so.* (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/squidclient/usr/bin/squidclient was not linked against
libnetfilter_conntrack.so.* (it uses none of the library's symbols)
...
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/squid-cgi/usr/lib/cgi-bin/cachemgr.cgi was not linked against
libnetfilter_conntrack.so.* (it uses none of the library's symbols)
...
Attached patch fixes them (however, obviously, overall positive effect
is very minor; squid{client,-cgi} are likely only installed together
with main squid package, and its dependencies remains mostly unchanged).
-- System Information:
Debian Release: 8.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (100,
'proposed-updates')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-- no debconf information
diff -Nru squid3-3.5.17/debian/rules squid3-3.5.17/debian/rules
--- squid3-3.5.17/debian/rules 2016-04-03 20:57:40.0 +0300
+++ squid3-3.5.17/debian/rules 2016-04-15 21:47:32.0 +0300
@@ -2,6 +2,7 @@
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_CFLAGS_MAINT_APPEND = -Wall
+export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
include /usr/share/dpkg/buildflags.mk
include /usr/share/cdbs/1/rules/debhelper.mk
Bug#822997: Fix debian/watch for openssh
Package: openssh Version: 1:7.2p2-4 Tags: patch The watch file for openssh has recently stop working possibly due to a change in the upstream site. Switching from ftp to http solves this issue. Output from uscan is below and patch is attached. Uscan with current watchfile: /openssh-7.2p2$ uscan --report --verbose -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: opts=pgpsigurlmangle=s/$/.asc/ ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-(.*)\.tar\.gz uscan warning: In watchfile debian/watch, reading FTP directory ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ failed: 503 Service Unavailable -- Scan finished Uscan with change: /openssh-7.2p2$ uscan --report --verbose -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: opts=pgpsigurlmangle=s/$/.asc/ http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-(.*)\.tar\.gz -- Found the following matching hrefs: openssh-2.1.1p4.tar.gz (2.1.1p4) openssh-2.2.0p1.tar.gz (2.2.0p1) openssh-2.3.0p1.tar.gz (2.3.0p1) openssh-2.5.1p1.tar.gz (2.5.1p1) openssh-2.5.1p2.tar.gz (2.5.1p2) openssh-2.5.2p1.tar.gz (2.5.2p1) openssh-2.5.2p2.tar.gz (2.5.2p2) openssh-2.9.9p1.tar.gz (2.9.9p1) ... openssh-7.0p1.tar.gz (7.0p1) openssh-7.1p1.tar.gz (7.1p1) openssh-7.1p2.tar.gz (7.1p2) openssh-7.2p1.tar.gz (7.2p1) openssh-7.2p2.tar.gz (7.2p2) Newest version on remote site is 7.2p2, local version is 7.2p2 => Package is up to date -- Scan finished -- Nicholas Luedtke HPE Linux, Hewlett-Packard Enterprise diff -urN openssh-7.2p2/debian/watch openssh-7.2p2/debian/watch --- openssh-7.2p2/debian/watch 2016-04-29 13:29:14.907535336 -0600 +++ openssh-7.2p2/debian/watch 2016-04-29 13:29:48.131535091 -0600 @@ -1,3 +1,3 @@ version=3 opts=pgpsigurlmangle=s/$/.asc/ \ -ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-(.*)\.tar\.gz +http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-(.*)\.tar\.gz signature.asc Description: OpenPGP digital signature
Bug#822964: Have to click connect twice before login dialogue opens
On Fri, Apr 29, 2016 at 11:23:52 -0500, Brent S. Elmer Ph.D. wrote: > gnome-shell current stretch version 3.18.1-1 Do you have another desktop environment (e.g. xfce) you can try? > yes, nmcli has the same behavior: > > $ nmcli con up 'IBM openconnect' > Error: Connection activation failed: no valid VPN secrets. Since gnome-shell is the registered "secret agent" for NetworkManager when working in a Gnome desktop environment, this still sounds like a gnome-shell bug. In fact it sounds like https://bugzilla.gnome.org/show_bug.cgi?id=760999 If you don't have a different desktop environment, can you try upgrading to gnome-shell 3.20 from unstable? That may be what fixed the issue for me, and I am unable to downgrade to verify that now. -- mike
Bug#822994: RM: libgdcm-cil [powerpc] -- ROM; mono is not available anymore on powerpc
package: ftp.debian.org control: clone -1 -2 control: retitle -2 RM: libvtkgdcm-cil [powerpc] -- ROM; mono is not available anymore on powerpc gdcm removed the building of the mono binding from ppc, following mono's moving away from pcc. Please remove this outdated binaries. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#822993: meld: In directory comparison, drop-down menu for file filters is not positioned correctly
Package: meld Version: 3.14.2-1 Severity: minor Dear Maintainer, When running a directory comparison, there is a "Filters" button to set file filters (for example, to ignore backup files in the diff). When I click that button, the drop-down box does not appear under the button as expected. Instead, it appears at the top-left corner of the desktop. Also, the following error message appears on standard output every time I click it: > TypeError: position_menu_under_widget() takes exactly 2 arguments (4 given) Thank you for your consideration. Kyanos -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (300, 'oldstable-updates'), (300, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages meld depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.0-1 ii gir1.2-gtksource-3.0 3.18.2-1 ii libcanberra-gtk3-module 0.30-3 ii libgtk-3-0 3.18.9-1 ii libgtksourceview-3.0-1 3.18.2-1 ii patch2.7.5-1 ii python 2.7.11-1 ii python-gi3.20.0-2 ii python-gi-cairo 3.20.0-2 pn python:any Versions of packages meld recommends: pn yelp meld suggests no packages. -- no debconf information
Bug#822992: squid3: please avoid installing pinger with suid-root when possible
Package: squid3
Version: 3.5.16-1
Severity: normal
Tags: patch
Dear Maintainer,
Since squid 3.5.16, squid properly handles when pinger helper is
installed with raised capabilities instead of setuid-root. Please avoid
installing pinger as suid root when possible, patch attached.
diff -Nru squid3-3.5.16/debian/control squid3-3.5.16/debian/control
--- squid3-3.5.16/debian/control 2016-04-03 20:57:40.0 +0300
+++ squid3-3.5.16/debian/control 2016-04-13 23:02:24.0 +0300
@@ -23,6 +23,7 @@
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, netbase, adduser, logrotate (>= 3.5.4-1), squid-common (= ${source:Version}), lsb-base, libdbi-perl
Suggests: squidclient, squid-cgi, squid-purge, resolvconf (>= 0.40), smbclient, ufw, winbindd
+Recommends: libcap2-bin [linux-any]
Conflicts: squid3 (<< ${binary:Version})
Replaces: squid3
Description: Full featured Web Proxy cache (HTTP proxy)
diff -Nru squid3-3.5.16/debian/rules squid3-3.5.16/debian/rules
--- squid3-3.5.16/debian/rules 2016-04-03 20:57:40.0 +0300
+++ squid3-3.5.16/debian/rules 2016-04-15 21:47:32.0 +0300
@@ -62,8 +62,6 @@
DEB_MAKE_CLEAN_TARGET = distclean
-DEB_FIXPERMS_EXCLUDE = /usr/lib/squid/pinger
-
install/squid::
install -m 755 -g root -d $(INSTALLDIR)/usr/lib/cgi-bin
mv $(INSTALLDIR)/etc/squid/squid.conf.documented $(INSTALLDIR)/etc/squid/squid.conf
@@ -85,7 +84,6 @@
install -m 755 -g root -d $(INSTALLDIR)/usr/share/man/man1
mv $(INSTALLDIR)/usr/bin/purge $(INSTALLDIR)/usr/bin/squid-purge
install -m 644 -g root debian/squid-purge.8 $(INSTALLDIR)/usr/share/man/man8
- chmod 4755 $(INSTALLDIR)/usr/lib/squid/pinger
clean::
# nothing to do
diff -Nru squid3-3.5.16/debian/squid.postinst squid3-3.5.16/debian/squid.postinst
--- squid3-3.5.16/debian/squid.postinst 2016-04-03 20:57:40.0 +0300
+++ squid3-3.5.16/debian/squid.postinst 2016-04-13 23:13:13.0 +0300
@@ -73,6 +73,22 @@
chown -R $usr:$grp $log_dir
fi
fi
+
+ # If we have setcap is installed, try setting cap_net_raw+ep,
+ # which allows us to install our binaries without the setuid
+ # bit.
+ PINGER=/usr/lib/squid/pinger
+ if command -v setcap > /dev/null; then
+ if setcap cap_net_raw+ep $PINGER; then
+echo "Setcap worked! $PINGER is not suid!"
+ else
+echo "Setcap failed on $PINGER, falling back to setuid" >&2
+chmod u+s $PINGER
+ fi
+ else
+ echo "Setcap is not installed, falling back to setuid" >&2
+ chmod u+s $PINGER
+ fi
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
Bug#822991: ITP: osm2pgrouting -- Tool to import OpenStreetMap data into a pgRouting database
Package: wnpp Severity: wishlist Owner: Bas Couwenberg * Package name: osm2pgrouting Version : 2.1.0 Upstream Author : Daniel Kastl * URL : https://github.com/pgRouting/osm2pgrouting * License : GPL-2+ Programming Lang: C++ Description : Tool to import OpenStreetMap data into a pgRouting database osm2pgrouting is a command line tool that makes it easy to import OpenStreetMap data into a pgRouting database. It builds the routing network topology automatically and creates tables for feature types and road classes. pgRouting has to be installed to be able to run osm2pgrouting. The osm2pgrouting package originates from OSGeo-Live, and will be maintained within the Debian GIS team along with pgrouting.
Bug#816679: icedove: Please rename icedove to thunderbird
Thunderbird 45.0 has been released (see: https://www.mozilla.org/en-US/thunderbird/45.0/releasenotes/ )... Perhaps now could be a good time to move it to sid.
Bug#822914: dpkg: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
2016-04-29 12:43 Guillem Jover:
Hi!
On Thu, 2016-04-28 at 22:30:13 +0100, Manuel A. Fernandez Montecelo wrote:
Package: dpkg
Version: 1.18.4
Severity: wishlist
Tags: patch
Control: user debian-ri...@lists.debian.org
Control: usertag -1 + riscv64
What ${subject} says. Patch attached with the line that needs to be
added to cputable.
I think that it's all what's needed, if not please tell me what else
is missing.
Does the new arch satisfy:
Sorry, I forgot to comment on that (although I knew about it):
- there is support in config for quite a while:
http://git.savannah.gnu.org/cgit/config.git/commit/?id=576c839acca0e082e536fd27568b90a446ce5b96
http://git.savannah.gnu.org/cgit/config.git/commit/?id=b576fa87c140b824466ef1638e945e87dc5c0343
If you think that this can be improved, I can communicate this to the
relevant parties.
- the support in the toolchain projects has not been merged yet,
althought it's been planned for some time and can start at any moment
I understand if you don't want to enable support yet for this reason,
I can ping the bug when that happens.
- it can work with both endianness, but so far the expectations is that
everybody will use little-endian, thus the proposed name without -el
suffix. I wouldn't oppose to add -el explicitly.
- anything missing?
Cheers.
--
Manuel A. Fernandez Montecelo
Bug#822990: RFS: hashcat/2.00-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "hashcat" * Package name: hashcat * Version : 2.00-1 * Upstream Author : Jens Steube * URL : http://hashcat.net/hashcat/ * License : Expat * Section : net It builds those binary packages: hashcat- Advanced CPU-based password recovery utility hashcat-data - Data files for hashcat Advanced CPU-based password recovery utili To access further information about this package, please visit the following URL: http://mentors.debian.net/package/hashcat Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/h/hashcat/hashcat_2.00-1.dsc More information about hello can be obtained from http://hashcat.net/hashcat/ Regards, Daniel Echeverry -- Daniel Echeverry http://wiki.debian.org/DanielEcheverry http://rinconinformatico.net Linux user: #477840 Debian user
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
Am 29.04.2016 um 18:47 schrieb Peter Spiess-Knafl: > Hi Markus! > > On 04/29/2016 04:34 PM, Markus Koschany wrote: >> >> Hi, >> >> the answer is pretty simple. Someone needs to do the work because >> Eclipse won't package itself. > > I did not mean to offend anybody, just wanted to know if its just lack > of time or if there are other already known problems for not packaging it. No worries. Valid questions won't offend me but I couldn't resist to do some straight talking here. >> A lot of time has passed between the >> current version in Debian and the most recent version. The new build >> system Tycho is completely different and is now Maven based. It must be >> packaged first. Several modules must be updated as well. And most >> importantly Eclipse must be maintained for the future. It's not about >> getting a new version into Debian and then you can stop working on it >> and everything will be fine. That's a constant process of repeating tasks. >> > > Of course, its not solely packaging and than you are fine but currently > that would be the first required action I guess. First of all, thanks for your interest in Eclipse. You're right that packaging a newer release is the first step. However you're not the first one who tried it and many people underestimate the importance or difference between packaging something and maintaining it. Maintaining is a recurring activity and by packaging something you automatically opt-in for keeping a package in good shape, not forever, but at least for the foreseeable future. Otherwise you would simply shift the responsibility to another team member and that's not fair in my opinion. We are not looking for the fire-and-forget maintainer but for someone who responds to bug reports, fixes bugs in his packages, forwards patches upstream etc. Then it is completely fine if you only want to maintain one or two packages and you are here at the right place. >> In my opinion it should be obvious that Eclipse needs help. So an RFH >> bug won't change much. > > Maybe not, but it will certainly not do any harm and maybe draw > attention to more developers, maintainers or people who might want to help. Granted, it won't hurt and I wouldn't object if somebody filed one. In my opinion RFH bug reports are often not very useful. People who really care about a package get involved with the packaging anyway, or they send patches, contact us on IRC or the mailing list. Those guys are promising because they show autonomy. RFH bugs often attract people who have never done any packaging work before. I definitely would want that those people get more involved with Debian but they should show at least some will to overcome obstacles. People who need too much hand-holding will quickly give up when they face something unexpected or complicated and Eclipse is one of the most complex pieces of Java software in the universe. If you aren't scared yet, read on... >> Eclipse requires at least one dedicated >> maintainer but the more the merrier. So if you want to help us >> to_maintain_ the packages, be more than welcome. I would help you to get >> the packages into Debian. >> > > That is good to know. So currently nobody is working on it? I saw you > made some commits on an experimental branch regarding 4.5.1. > > I will take a deeper look and try to check which steps are required to > make an upgrade possible. > > You already mentioned packaging the new build-system (tycho). That seems > a logical step to start with. > > If any of the current maintainers could provide additional information > to whats required, I would appreciate it very much. Luca Vercelli worked on Tycho before but he just wanted to get the package into Debian and didn't really want to maintain it. You could search for "debian java list tycho" to find some correspondence on our mailing list. e.g. https://lists.debian.org/debian-java/2016/01/msg00015.html He also uploaded an unfinished package of Tycho to mentors.debian.net. It is not perfect but a first start. https://mentors.debian.net/package/tycho If we want to get Eclipse 4.x into Stretch, Tycho should be the first goal. After that we should focus on updating src:eclipse and after that all other plugins/modules but those are rather optional depending on how many people intend to help. My advise is to copy Fedora's approach in packaging Eclipse and Tycho or at least to learn from them. http://pkgs.fedoraproject.org/cgit/rpms/tycho.git/ http://pkgs.fedoraproject.org/cgit/rpms/eclipse.git/ https://fedoraproject.org/wiki/Eclipse We should find a way to make packaging Eclipse plugins and the base IDE much simpler in the long run. If you have questions, or would like to request reviews and sponsorship, please feel free to ask on debian-j...@list.debian.org or on IRC at irc.debian.org, #debian-java. Cheers, Markus signature.asc Description: OpenPGP digital signature
Bug#822989: sso.debian.org: Can't login using Alioth account
Package: sso.debian.org Severity: grave Justification: renders package unusable Hi, I can't login to sso.debian.org using my Alioth account "onovy-guest". Error message: Authentication failed Invalid authenticating information I can login directly to Alioth fine. Thanks for fixing. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#822988: linux-atm: a newer upstream version exists (2.5.2)
Source: linux-atm Version: 1:2.5.1-1.5 Severity: wishlist Dear Maintainer, linux-atm 2.5.1 dates back to 2009: https://sourceforge.net/projects/linux-atm/files/linux-atm/2.5.1/ and there is a newer version, 2.5.2 from 2010: https://sourceforge.net/projects/linux-atm/files/linux-atm/2.5.2/ -- Best wishes, Bob
Bug#822987: seinfo: no types and attributes treated as types
Package: setools Version: 3.3.8+20151215-3 Severity: normal After the recent upgrades of the selinux userland libraries i noticed a bug in the seinfo tool. Example output: christian@debianSE:~$ seinfo Statistics for policy file: /etc/selinux/default/policy/policy.30 Policy Version & Type: v.30 (binary, mls) Classes:93Permissions: 254 Sensitivities: 1Categories: 1024 Types: 0Attributes: Users: 6Roles: 14 Booleans: 234Cond. Expr.: 265 Allow: 107477Neverallow: 0 Auditallow: 26Dontaudit: 17448 Type_trans: 8930Type_change:72 Type_member:16Role allow: 28 Role_trans:454Range_trans:38 Constraints: 161Validatetrans: 0 Initial SIDs: 27Fs_use: 26 Genfscon: 89Portcon: 458 Netifcon:0Nodecon: 0 Permissives: 0Polcap: 2 # notice 0 types christian@debianSE:~$ seinfo -tinit_t -x christian@debianSE:~$ seinfo -ainit_t -x init_t init_t dbusd_unconfined dbusd_system_bus_client sepgsql_unconfined_type x_domain xserver_unconfined_type christian@debianSE:~$ seinfo -t Types: 0 christian@debianSE:~$ seinfo -a ... # lists hundreds of types ... samba_log_t services_munin_plugin_tmpfs_t spamd_port_t transproxy_initrc_exec_t tripwire_report_t wireshark_input_xevent_t Maybe this https://bugzilla.redhat.com/show_bug.cgi?id=1291336 bugreport is related? -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.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 setools depends on: ii libbz2-1.01.0.6-8 ii libc6 2.22-7 ii libgcc1 1:6.0.1-2 ii libqpol1 3.3.8+20151215-3 ii libselinux1 2.5-1 ii libsqlite3-0 3.12.2-1 ii libstdc++66.0.1-2 ii libxml2 2.9.3+dfsg1-1 setools recommends no packages. Versions of packages setools suggests: pn setools-gui -- no debconf information
Bug#822724: Bug#822725: Bug#822724: efitools: FTBFS on i386: efibind.h: No such file or directory
On Fri, Apr 29, 2016 at 07:31:11PM +0200, pollux wrote: >On 04/29/2016 06:58 PM, Steve McIntyre wrote: >> On Fri, Apr 29, 2016 at 06:20:55PM +0200, pollux wrote: >>> Indeed, on PC architectures, EFI executables are 64-bits EXE files. >> >> Ummm, what? 32-bit i386 (ia32) should be supported just fine. If it's >> not working, that's just a bug. > >I'm talking about .efi files. If your firmware (BIOS) is 64-bits, then >your executables can only use a 64-bits ABI for boot/runtime services. >IA32 EFI firmwares are only used by some low-end platforms, or some >embedded platforms (Intel Atom SoCs) Right, but they're still valid platforms that exist in the wild. We already support (for example) installation on Bay Trail based machines that use ia32 UEFI. >Not sure for ARM, but it may have the same problems. UEFI is more common on arm64, but there are some 32-bit ARM machines that will boot with UEFI, and probably more coming. We've just turned on more UEFI support in the armmp kernels for this reason. >See also http://mjg59.dreamwidth.org/26734.html for more problems with >IA32 on x86 It's problematic, but it exists and is growing in usage - we can't just ignore it. >> Please don't do that. There are *4* Debian Linux architectures that >> should be able to work here: amd64, i386, arm64 and armhf. > >I would like to, I'm just trying to find a solution that does not >involved cross-compilation :/ The source package builds both native >files, and .efi files. >If you have any ideas they are welcome. I don't see the problem - just build the appropriate binaries for each of the architectures natively. Am I missing something? -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Bug#822910: mutt-patched: silently dropped the sidebar-dotpathsep patch in favor of sidebar-dotted
Hi Gian Piero, On Thu, Apr 28, 2016 at 10:32:17PM +0200, Gian Piero Carrubba wrote: > Mutt 1.6.0-1 is using the sidebar-dotted patch that was abandoned in > 1.5.22-2 in favor of Gentoo's sidebar-dotpathsep. Partially, it is an upstream feature now. > I personally prefer the sidebar-dotpathsep patch because: > > - has a summary listing # of unread/flagged/total messages instead of only > unread/total Flagged should be supported according to docs, I never tried that, though. > - has configurable mailboxes separator (in my case, the newly reintroduced > patch does not correctly display maildirs containing a dot in the name) Did you try setting sidebar_folderindent? That worked fine here with dotted maildirs. > Anyway, if even the reintroduction of the old patch was intentional, please > document it in the NEWS.Debian file, noting that 'sidebar_delim_chars' is > not valid anymore and 'sidebar_shortpath' can be used instead (sort of). I've added some details in https://anonscm.debian.org/cgit/pkg-mutt/mutt.git/commit/?id=00fe2d19fa615e25e10f9976a937358a42cd1be7 Could you have a look if that makes sense to you? Greets Evgeni
Bug#822724: Bug#822725: Bug#822724: efitools: FTBFS on i386: efibind.h: No such file or directory
On 04/29/2016 06:58 PM, Steve McIntyre wrote: > On Fri, Apr 29, 2016 at 06:20:55PM +0200, pollux wrote: >> Indeed, on PC architectures, EFI executables are 64-bits EXE files. > > Ummm, what? 32-bit i386 (ia32) should be supported just fine. If it's > not working, that's just a bug. I'm talking about .efi files. If your firmware (BIOS) is 64-bits, then your executables can only use a 64-bits ABI for boot/runtime services. IA32 EFI firmwares are only used by some low-end platforms, or some embedded platforms (Intel Atom SoCs) Not sure for ARM, but it may have the same problems. See also http://mjg59.dreamwidth.org/26734.html for more problems with IA32 on x86 > >> I think the solution is to restrict the build to linux-amd64, and mark >> the package as Multi-arch: foreign, however that would cover only the >> embedded EFI files, not the tools to access UEFI variables. >> That said, these tools use the efivars pseudo-filesystem and will only >> work on Linux. >> >> So, I think the next upload will restrict the package to linux-amd64 only. > > Please don't do that. There are *4* Debian Linux architectures that > should be able to work here: amd64, i386, arm64 and armhf. > I would like to, I'm just trying to find a solution that does not involved cross-compilation :/ The source package builds both native files, and .efi files. If you have any ideas they are welcome. Regards, Pierre
Bug#822893: mutt-patched: nntp no longer working
On Fri, Apr 29, 2016 at 06:38:43PM +0200, Evgeni Golov wrote: > Reiner, can you test a build from git for us? I've uploaded amd64 packages to > https://people.debian.org/~evgeni/tmp/mutt/ I just tested it, and NNTP works fine again. Thanks a lot James and Evgeni! signature.asc Description: PGP signature
Bug#822724: efitools: FTBFS on i386: efibind.h: No such file or directory
On Fri, Apr 29, 2016 at 06:20:55PM +0200, pollux wrote: >On 04/26/2016 09:29 PM, Aaron M. Ucko wrote: >> Source: efitools >> Version: 1.4.2-2 >> Severity: important >> Justification: fails to build from source >> >> Thanks for fixing efitools's Build-Depends setting! Automated builds >> now get further, but still fail on i386, with >> >> In file included from simple_file.c:7:0: >> /usr/include/efi/efi.h:35:21: fatal error: efibind.h: No such file or >> irectory >> >> (kfreebsd-amd64 builds also still fail, but with a different error >> I'll report separately.) >> >> The i386 version of this header turns out to be in >> /usr/include/efi/ia32, not /usr/include/efi/i686. I see no sign of a >> config script that would report this location, so I suppose efitools >> will need to hardcode the mapping. >> >> I also noticed two further complications that will affect linking on >> i386: the crt0 file is likewise named crt0-efi-ia32.o, and 32-bit >> gnu-efi libraries are in /usr/lib32, which isn't in the default search >> path. >> >> Could you please take a look? > >Hi, > >This specific bug is fixed in the upcoming upload (new upstream release >1.7.0) >However, a new problem appears: >ld: i386 architecture of input file `HelloWorld.o' is incompatible with >i386:x86-64 output > >Indeed, on PC architectures, EFI executables are 64-bits EXE files. Ummm, what? 32-bit i386 (ia32) should be supported just fine. If it's not working, that's just a bug. >I think the solution is to restrict the build to linux-amd64, and mark >the package as Multi-arch: foreign, however that would cover only the >embedded EFI files, not the tools to access UEFI variables. >That said, these tools use the efivars pseudo-filesystem and will only >work on Linux. > >So, I think the next upload will restrict the package to linux-amd64 only. Please don't do that. There are *4* Debian Linux architectures that should be able to work here: amd64, i386, arm64 and armhf. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Bug#814390: ITP: vor -- A quick action game of dodging rocks in space
retitle 814390 ITP: vor -- A quick action game of dodging rocks in space owner 814390 ! thanks Hello, I am working on packaging this within the debian-games team. Regards, Ana
Bug#681726: eclipse: Upgrade Eclipse to Juno 4.2
Hi Markus! On 04/29/2016 04:34 PM, Markus Koschany wrote: > > Hi, > > the answer is pretty simple. Someone needs to do the work because > Eclipse won't package itself. I did not mean to offend anybody, just wanted to know if its just lack of time or if there are other already known problems for not packaging it. > A lot of time has passed between the > current version in Debian and the most recent version. The new build > system Tycho is completely different and is now Maven based. It must be > packaged first. Several modules must be updated as well. And most > importantly Eclipse must be maintained for the future. It's not about > getting a new version into Debian and then you can stop working on it > and everything will be fine. That's a constant process of repeating tasks. > Of course, its not solely packaging and than you are fine but currently that would be the first required action I guess. > In my opinion it should be obvious that Eclipse needs help. So an RFH > bug won't change much. Maybe not, but it will certainly not do any harm and maybe draw attention to more developers, maintainers or people who might want to help. > Eclipse requires at least one dedicated > maintainer but the more the merrier. So if you want to help us > to_maintain_ the packages, be more than welcome. I would help you to get > the packages into Debian. > That is good to know. So currently nobody is working on it? I saw you made some commits on an experimental branch regarding 4.5.1. I will take a deeper look and try to check which steps are required to make an upgrade possible. You already mentioned packaging the new build-system (tycho). That seems a logical step to start with. If any of the current maintainers could provide additional information to whats required, I would appreciate it very much. > Regards, > > Markus > Thanks for your reply. Greetings Peter signature.asc Description: OpenPGP digital signature
Bug#822893: mutt-patched: nntp no longer working
Hi, On Fri, Apr 29, 2016 at 09:36:25AM -0400, James McCoy wrote: > > But I also just saw in git that it has been disabled, because it > > doesn't build. :( > > It would be awesome if you could get it running again! :) > > Agreed. I took a quick look and the attached patch fixes the build. I > haven't had a chance to do any testing yet, but thought I'd send this in > case it helps. Thanks. Applied in Git. Building works fine, but I've not used NNTP in ages. Reiner, can you test a build from git for us? I've uploaded amd64 packages to https://people.debian.org/~evgeni/tmp/mutt/ Greets Evgeni
Bug#822986: RFS: singular/4.0.3-p1+ds-2 [FTBFS] - Computer Algebra System for Polynomial Computations
Package: sponsorship-requests Severity: important Justification: FTBFS Dear Sponsors, I am looking for a Sponsor for the package singular/4.0.3-p1+ds-2 [1], this package fixes FTBS #806108 . Thanks in advance, Jerome [1] https://anonscm.debian.org/cgit/debian-science/packages/singular.git -- System Information: Debian Release: Jessie* APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.7-ckt20-0001-mbp62 (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 Init: sysvinit (via /sbin/init)
Bug#822985: RM: gstreamer0.10 -- ROM; dead upstream, replaced by gst1.0
Package: ftp.debian.org Severity: normal Hi, Could you please RM gstreamer0.10? There is nothing left in the archive using it: $ dak rm -nR gstreamer0.10 Will remove the following packages from unstable: gir1.2-gstreamer-0.10 | 0.10.36-1.5 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x gstreamer-tools | 0.10.36-1.5 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x gstreamer0.10 | 0.10.36-1.5 | source gstreamer0.10-doc | 0.10.36-1.5 | all gstreamer0.10-tools | 0.10.36-1.5 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libgstreamer0.10-0 | 0.10.36-1.5 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libgstreamer0.10-0-dbg | 0.10.36-1.5 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libgstreamer0.10-dev | 0.10.36-1.5 | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x Maintainer: Maintainers of GStreamer packages --- Reason --- -- Checking reverse dependencies... # Broken Depends: cutter-testing-framework: gstreamer0.10-plugins-cutter [hurd-i386] Dependency problem found. Cheers, Laurent Bigonville
Bug#822974: backport for jessie
On 29/04/16 16:36, Robert Lange wrote: > I have made such a backport in my personal Jessie backports repo. I > used the source packages from testing (and maybe unstable, if a > package was not in testing, but I think all relevant packages are in > testing now). The process was complicated b/c I needed to backport > dpkg and debhelpers and a bunch of others in order to satisfy the > dependency chain and build dependency chain. However, after compiling > around 10ish source packages, everything worked. I've been tracking > and keeping up w/ changes, and so far I have not had any problems, > with the following caveats. > > One major issue with an official backport is that GnuPG 2.1 breaks > backward compatibility with the key format of previous versions. This > is not a problem if you can use gpg2 for everything, but if you still > need gpg1 for some things, then you will have to manually keep 2 > copies of your keychain in sync; the old 1.x format and the 2.1 > format. Every time you import or sign a new key, you will have to > remember to do the operation with both gpg and gpg2. For me, I have > been able to live with 2.1 only, but others may not be able to. > > This is made somewhat more complicated by the fact that many Debian > admin and build scripts currently still default to invoke gpg instead > of gpg2. I had to set some environment variables to get some scripts > to use gpg2, and I think I had to set up a diversion for some other > scripts that are currently hard-coded to use gpg instead of gpg2. (I > am not at home currently, so I can't be more exact.) There were some > warnings about gpg2 having possibly incompatible command line > arguments and maybe some scripts breaking as a result of this, but so > far I have not noticed any problems from this. > > Anyway, upgrading my personal machines to GnuPG 2.1 was interesting > and rewarding, but given the above, I would say that doing this in the > official backports repo would cause a lot of problems, especially with > that special breed of user who upgrades first and reads the notes later. Thanks for this feedback My reason for this is the PGP Clean Room Live CD: https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment and users of the CD would not necessarily be impacted by the dependency issues or the backwards compatibility issues. However, I agree that regular users of backports could be surprised by these compatibility issues. I wonder if we need a jessie-backports-experimental for things that could be troublesome like this. Regards, Daniel
Bug#822961: [pkg-ntp-maintainers] Bug#822961: ntp logging (?again?) in a way to be catched by logcheck
On Fri, Apr 29, 2016 at 02:00:36PM +0200, Christian Ehrhardt wrote: > Package: ntp > Version: 1:4.2.8p4+dfsg-3+b1 > > Hi, > debugging a rather old issue I realized that the changes made back when > uploading 4.2.6+dfsg-1 might no more completely apply. > > I quote from the changelog in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498992: > "* Remove ntp.logcheck.ignore.server, none of those messages are send to > syslog now. (Closes: #498992)" > > But I had to find that this today still (?again?) happens. > So much could have been changed on how the log data flows. > > But testing is rather easy: > apt-get install logcheck > apt-get install ntp > service ntp restart > > Then logcheck will report about everything from ntp: > sudo -u logcheck logcheck -s -o -t | grep ntp | wc -l > 41 It seems to generate other messages now too than it used to. Kurt
Bug#822964: Have to click connect twice before login dialogue opens
On Fri, 2016-04-29 at 11:37 -0400, Mike Miller wrote: > > Can you say which graphical tool you are using to connect to the VPN? > If > gnome-shell or gnome-control-center network, which version? Does the > same behavior occur with "nmcli con up VPN-NAME"? When it does occur, > do > you see a stray nm-openconnect-service process running after the > failure? > > This sounds like a symptom I used to see with both OpenConnect and > OpenVPN connections, but has recently disappeared since upgrading to > Gnome 3.20 and NetworkManager 1.2.0. > gnome-shell current stretch version 3.18.1-1 yes, nmcli has the same behavior: $ nmcli con up 'IBM openconnect' Error: Connection activation failed: no valid VPN secrets. brente@brente:~$ nmcli con up 'IBM openconnect' A password is required to connect to 'IBM openconnect'. Warning: password for 'vpn.secrets.gateway' not given in 'passwd-file' and nmcli cannot ask without '--ask' option. The first time I run nmlci I get an immediate prompt back after the Error. The second time I get the Warning but the login dialog shows and I can click login. Here is what ps shows after the failure: root 3394 1 0 10:46 ?00:00:00 /usr/lib/NetworkManager/nm-openconnect-service --bus-name org.freedesktop.NetworkManager.openconnect.Connection_2 When the "connect to VPN" dialog shows up for me to login, I have "Automatically start connecting next time" checked and "Save passwords" checked and the password is there. However, it has never automatically connected. I have always had to click "Login" to be connected. It seems like with those two boxes checked and a password in the field, it should just connect automatically. Shouldn't it? What is vpn.secrets.gateway and passwd-file? I did some experimenting and found that if I disconnect from the vpn that reconnecting always brings up the connect dialog box. Also, if I log out and back in the first time clicking on connect to vpn always brings up the connect dialog box. I also tried waiting 5 or 10 minutes after I log in to gnome to see if that makes any difference. It appears that no matter how long I wait, the first attempt after a boot fails. I hope this helps to figure out what the problem is.
Bug#822984: ITP: libtest-requires-git-perl -- module to check the available version of Git
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libtest-requires-git-perl Version : 1.005 Upstream Author : Philippe Bruhat (BooK) * URL : https://metacpan.org/release/Test-Requires-Git * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to check the available version of Git Test::Requires::Git checks if the version of Git available for testing meets the given requirements. The "current git" is obtained by running "git --version" (so the first "git" binary found in the "PATH" will be tested). If the checks fail, then all tests will be skipped. The package will be maintained under the umbrella of the Debian Perl Group. signature.asc Description: Digital Signature
Bug#822724: efitools: FTBFS on i386: efibind.h: No such file or directory
On 04/26/2016 09:29 PM, Aaron M. Ucko wrote: > Source: efitools > Version: 1.4.2-2 > Severity: important > Justification: fails to build from source > > Thanks for fixing efitools's Build-Depends setting! Automated builds > now get further, but still fail on i386, with > > In file included from simple_file.c:7:0: > /usr/include/efi/efi.h:35:21: fatal error: efibind.h: No such file or > irectory > > (kfreebsd-amd64 builds also still fail, but with a different error > I'll report separately.) > > The i386 version of this header turns out to be in > /usr/include/efi/ia32, not /usr/include/efi/i686. I see no sign of a > config script that would report this location, so I suppose efitools > will need to hardcode the mapping. > > I also noticed two further complications that will affect linking on > i386: the crt0 file is likewise named crt0-efi-ia32.o, and 32-bit > gnu-efi libraries are in /usr/lib32, which isn't in the default search > path. > > Could you please take a look? > Hi, This specific bug is fixed in the upcoming upload (new upstream release 1.7.0) However, a new problem appears: ld: i386 architecture of input file `HelloWorld.o' is incompatible with i386:x86-64 output Indeed, on PC architectures, EFI executables are 64-bits EXE files. I think the solution is to restrict the build to linux-amd64, and mark the package as Multi-arch: foreign, however that would cover only the embedded EFI files, not the tools to access UEFI variables. That said, these tools use the efivars pseudo-filesystem and will only work on Linux. So, I think the next upload will restrict the package to linux-amd64 only. Regards, Pierre
Bug#822983: zlibc: [PATCH] convert package to 3.0 (quilt)
Package: zlibc Version: 0.9k-4.3 Severity: normal Please, consider the attached tar for convert the package to format 3.0 (quilt). zlibc_0.9k-4.4.debian.tar.xz Description: application/xz
Bug#822982: ITP: libgit-version-compare-perl -- module to compare Git versions
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libgit-version-compare-perl Version : 1.002 Upstream Author : Philippe Bruhat (BooK) * URL : https://metacpan.org/release/Git-Version-Compare * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to compare Git versions Git::Version::Compare contains a selection of subroutines that make dealing with Git-related things (like versions) a little bit easier. The strings to compare can be version numbers, tags from git.git or the output of git version or git describe. These routines collect the knowledge about Git versions that was accumulated while developing Git::Repository. The package will be maintained under the umbrella of the Debian Perl Group. signature.asc Description: Digital Signature
Bug#822963: htop: please make the build reproducible (timestamps)
Hi Daniel. Le 29/04/2016 15:56, Daniel Lange a écrit : > that patch is from Graham (CC) and we have it both already in > https://anonscm.debian.org/cgit/collab-maint/htop.git/commit/?id=cef9e7933e5c9704eaa5a6330067967f32e52798 > and sent upstream (https://github.com/hishamhm/htop/pull/476). Excellent. Sorry I did not look at git and upstream before… If I understood correctly, the --date @epoch is GNU-date specific, and BSD-date has another syntax, that's why I took the code from [1]. Regards, Alexis. [1]: https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Examples
Bug#822964: Have to click connect twice before login dialogue opens
Control: tags -1 + moreinfo unreproducible On Fri, Apr 29, 2016 at 08:15:30 -0500, Brent S. Elmer wrote: > I just upgraded network-manager-openconnect and network-manager-openconnect- > gnome with version 1.2.0-1 that just hit stretch on 4-28-2016 from version > 1.0.2-1 that was in stretch. This was the only upgrade that I did at the > time. > What I see after the upgrade is that the first time I click on connect to vpn, > the login dialogue does not appear. I waited for a while. When I click on it > a second time, it does appear and I can log in and connect to the vpn as > usual. > I have rebooted my machine twice I tried connecting to the vpn and the same > behavior happens(i.e. the login dialogue does not open until after the 2nd > time > clicked) > This behavior never happened until I upgraded to 1.2.0-1. Can you say which graphical tool you are using to connect to the VPN? If gnome-shell or gnome-control-center network, which version? Does the same behavior occur with "nmcli con up VPN-NAME"? When it does occur, do you see a stray nm-openconnect-service process running after the failure? This sounds like a symptom I used to see with both OpenConnect and OpenVPN connections, but has recently disappeared since upgrading to Gnome 3.20 and NetworkManager 1.2.0. -- mike
Bug#807208: Various bugs in /etc/init.d/tahoe-lafs
Sébastien Béhuret writes: > Package: tahoe-lafs > Version: 1.10.2-2 > Tags: patch > > > Dear Maintainer, > > There are a couple of bugs in /etc/init.d/tahoe-lafs: > > - When AUTOSTART is set to "none", the initscript attempts to start the > node “/var/lib/tahoe-lafs/none”. > - When AUTOSTART lists a non-existing node, the initscript attempts to > start it. > - When a node is not owned by any existing user (node with an uid but > without an username), stat -c %U returns "UNKNOWN". > > The attached patch resolves these issues. However, for the third issue, it > may be a good idea to allow starting nodes that are not owned by a regular > user, perhaps by using sudo -u '#uid' -g '#uid' instead of su. Dear Sebastien, Sorry for a very late response to this bug. Thanks a lot for the report. For the first two points, I tried to solve the issue by exiting immediately. Do you think that will work? diff --git a/debian/tahoe-lafs.init b/debian/tahoe-lafs.init index 27a614b..548d77a 100755 --- a/debian/tahoe-lafs.init +++ b/debian/tahoe-lafs.init @@ -77,6 +77,7 @@ start|stop|restart) if [ $# -eq 0 ]; then if [ "$AUTOSTART" = "none" ] || [ -z "$AUTOSTART" ]; then log_warning_msg " Autostart disabled." +exit 0 fi if [ "$AUTOSTART" = "all" ]; then # all nodes shall be taken care of automatically Thanks Ramakrishnan signature.asc Description: PGP signature
Bug#822981: tomcat-maven-plugin: FTBFS: [..] org.codehaus.plexus:plexus-component-metadata:jar:1.0-beta-3.0.7 has not been downloaded
Source: tomcat-maven-plugin Version: 1.1-2.4 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, tomcat-maven-plugin fails to build from source in unstable/amd64: [..] Adding debian:Actalis_Authentication_Root_CA.pem Adding debian:AddTrust_External_Root.pem Adding debian:AddTrust_Low-Value_Services_Root.pem Adding debian:AddTrust_Public_Services_Root.pem Adding debian:AddTrust_Qualified_Certificates_Root.pem Adding debian:AffirmTrust_Commercial.pem Adding debian:AffirmTrust_Networking.pem Adding debian:AffirmTrust_Premium.pem Adding debian:AffirmTrust_Premium_ECC.pem Adding debian:ApplicationCA_-_Japanese_Government.pem Adding debian:Atos_TrustedRoot_2011.pem Adding debian:Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem Adding debian:Baltimore_CyberTrust_Root.pem Adding debian:Buypass_Class_2_CA_1.pem Adding debian:Buypass_Class_2_Root_CA.pem Adding debian:Buypass_Class_3_Root_CA.pem Adding debian:CA_Disig.pem Adding debian:CA_Disig_Root_R1.pem Adding debian:CA_Disig_Root_R2.pem Adding debian:CA_WoSign_ECC_Root.pem Adding debian:CFCA_EV_ROOT.pem Adding debian:CNNIC_ROOT.pem Adding debian:COMODO_Certification_Authority.pem Adding debian:COMODO_ECC_Certification_Authority.pem Adding debian:COMODO_RSA_Certification_Authority.pem Adding debian:Camerfirma_Chambers_of_Commerce_Root.pem Adding debian:Camerfirma_Global_Chambersign_Root.pem Adding debian:Certification_Authority_of_WoSign_G2.pem Adding debian:Certigna.pem Adding debian:Certinomis_-_Autorité_Racine.pem Adding debian:Certinomis_-_Root_CA.pem Adding debian:Certplus_Class_2_Primary_CA.pem Adding debian:Certum_Root_CA.pem Adding debian:Certum_Trusted_Network_CA.pem Adding debian:Chambers_of_Commerce_Root_-_2008.pem Adding debian:China_Internet_Network_Information_Center_EV_Certificates_Root.pem Adding debian:ComSign_CA.pem Adding debian:Comodo_AAA_Services_root.pem Adding debian:Comodo_Secure_Services_root.pem Adding debian:Comodo_Trusted_Services_root.pem Adding debian:Cybertrust_Global_Root.pem Adding debian:D-TRUST_Root_Class_3_CA_2_2009.pem Adding debian:D-TRUST_Root_Class_3_CA_2_EV_2009.pem Adding debian:DST_ACES_CA_X6.pem Adding debian:DST_Root_CA_X3.pem Adding debian:Deutsche_Telekom_Root_CA_2.pem Adding debian:DigiCert_Assured_ID_Root_CA.pem Adding debian:DigiCert_Assured_ID_Root_G2.pem Adding debian:DigiCert_Assured_ID_Root_G3.pem Adding debian:DigiCert_Global_Root_CA.pem Adding debian:DigiCert_Global_Root_G2.pem Adding debian:DigiCert_Global_Root_G3.pem Adding debian:DigiCert_High_Assurance_EV_Root_CA.pem Adding debian:DigiCert_Trusted_Root_G4.pem Adding debian:E-Tugra_Certification_Authority.pem Adding debian:EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.pem Adding debian:EC-ACC.pem Adding debian:EE_Certification_Centre_Root_CA.pem Adding debian:Entrust.net_Premium_2048_Secure_Server_CA.pem Adding debian:Entrust_Root_Certification_Authority.pem Adding debian:Entrust_Root_Certification_Authority_-_EC1.pem Adding debian:Entrust_Root_Certification_Authority_-_G2.pem Adding debian:Equifax_Secure_CA.pem Adding debian:Equifax_Secure_Global_eBusiness_CA.pem Adding debian:Equifax_Secure_eBusiness_CA_1.pem Adding debian:GeoTrust_Global_CA.pem Adding debian:GeoTrust_Global_CA_2.pem Adding debian:GeoTrust_Primary_Certification_Authority.pem Adding debian:GeoTrust_Primary_Certification_Authority_-_G2.pem Adding debian:GeoTrust_Primary_Certification_Authority_-_G3.pem Adding debian:GeoTrust_Universal_CA.pem Adding debian:GeoTrust_Universal_CA_2.pem Adding debian:GlobalSign_ECC_Root_CA_-_R4.pem Adding debian:GlobalSign_ECC_Root_CA_-_R5.pem Adding debian:GlobalSign_Root_CA.pem Adding debian:GlobalSign_Root_CA_-_R2.pem Adding debian:GlobalSign_Root_CA_-_R3.pem Adding debian:Global_Chambersign_Root_-_2008.pem Adding debian:Go_Daddy_Class_2_CA.pem Adding debian:Go_Daddy_Root_Certificate_Authority_-_G2.pem Adding debian:Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem Adding debian:Hongkong_Post_Root_CA_1.pem Adding debian:IGC_A.pem Adding debian:IdenTrust_Commercial_Root_CA_1.pem Adding debian:IdenTrust_Public_Sector_Root_CA_1.pem Adding debian:Izenpe.com.pem Adding debian:Juur-SK.pem Adding debian:Microsec_e-Szigno_Root_CA.pem Adding debian:Microsec_e-Szigno_Root_CA_2009.pem Adding debian:NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem Adding debian:NetLock_Business_=Class_B=_Root.pem Adding debian:NetLock_Express_=Class_C=_Root.pem Adding debian:NetLock_Notary_=Class_A=_Root.pem Adding debian:NetLock_Qualified_=Class_QA=_Root.pem Adding debian:Network_Solutions_Certificate_Authority.pem Adding debian:OISTE_WISeKey_Global_Root_GA_CA.pem Adding debian:OISTE_WISeKey_Global_Root_GB_CA.pem Adding de
Bug#822980: ruby-email-reply-parser: FTBFS: test_runner.rb:126:in `exit': no implicit conversion from nil to integer (TypeError)
Source: ruby-email-reply-parser Version: 0.5.8-1 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, ruby-email-reply-parser fails to build from source in unstable/amd64: [..] dh_testdir dh_testroot dh_prep dh_testdir dh_testroot dh_install dh_installdocs dh_installchangelogs dh_compress dh_fixperms dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'ruby-email-reply-parser-build-deps' in '../ruby-email-reply-parser-build-deps_0.5.8-1_all.deb'. The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the message above! Selecting previously unselected package ruby-email-reply-parser-build-deps. (Reading database ... 23035 files and directories currently installed.) Preparing to unpack ruby-email-reply-parser-build-deps_0.5.8-1_all.deb ... Unpacking ruby-email-reply-parser-build-deps (0.5.8-1) ... Reading package lists... Building dependency tree... Reading state information... Correcting dependencies... Done The following additional packages will be installed: ca-certificates gem2deb gem2deb-test-runner libgmp-dev libgmpxx4ldbl libre2-1v5 libruby2.3 libyaml-0-2 openssl python3-chardet python3-debian python3-pkg-resources python3-six rake ruby ruby-all-dev ruby-did-you-mean ruby-minitest ruby-net-telnet ruby-power-assert ruby-re2 ruby-setup ruby-test-unit ruby2.3 ruby2.3-dev rubygems-integration Suggested packages: gmp-doc libgmp10-doc libmpfr-dev python3-setuptools ri ruby-dev bundler Recommended packages: apt-file python3-apt zip fonts-lato libjs-jquery The following NEW packages will be installed: ca-certificates gem2deb gem2deb-test-runner libgmp-dev libgmpxx4ldbl libre2-1v5 libruby2.3 libyaml-0-2 openssl python3-chardet python3-debian python3-pkg-resources python3-six rake ruby ruby-all-dev ruby-did-you-mean ruby-minitest ruby-net-telnet ruby-power-assert ruby-re2 ruby-setup ruby-test-unit ruby2.3 ruby2.3-dev rubygems-integration 0 upgraded, 26 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 6830 kB of archives. After this operation, 26.1 MB of additional disk space will be used. Get:1 http://httpredir.debian.org/debian sid/main amd64 openssl amd64 1.0.2g-2 [679 kB] Get:2 http://httpredir.debian.org/debian sid/main amd64 ca-certificates all 20160104 [200 kB] Get:3 http://httpredir.debian.org/debian sid/main amd64 rubygems-integration all 1.10 [4882 B] Get:4 http://httpredir.debian.org/debian sid/main amd64 ruby-did-you-mean all 1.0.0-2 [11.2 kB] Get:5 http://httpredir.debian.org/debian sid/main amd64 ruby-minitest all 5.8.4-2 [50.3 kB] Get:6 http://httpredir.debian.org/debian sid/main amd64 ruby-net-telnet all 0.1.1-2 [12.5 kB] Get:7 http://httpredir.debian.org/debian sid/main amd64 ruby-power-assert all 0.2.7-1 [7578 B] Get:8 http://httpredir.debian.org/debian sid/main amd64 ruby-test-unit all 3.1.7-2 [69.6 kB] Get:9 http://httpredir.debian.org/debian sid/main amd64 libyaml-0-2 amd64 0.1.6-3 [50.4 kB] Get:10 http://httpredir.debian.org/debian sid/main amd64 libruby2.3 amd64 2.3.1-1 [3098 kB] Get:11 http://httpredir.debian.org/debian sid/main amd64 ruby2.3 amd64 2.3.1-1 [177 kB] Get:12 http://httpredir.debian.org/debian sid/main amd64 ruby amd64 1:2.3.0+4 [10.5 kB] Get:13 http://httpredir.debian.org/debian sid/main amd64 rake all 10.5.0-2 [49.4 kB] Get:14 http://httpredir.debian.org/debian sid/main amd64 gem2deb-test-runner all 0.30.1 [19.4 kB] Get:15 http://httpredir.debian.org/debian sid/main amd64 python3-pkg-resources all 20.10.1-1 [112 kB] Get:16 http://httpredir.debian.org/debian sid/main amd64 python3-chardet all 2.3.0-2 [96.0 kB] Get:17 http://httpredir.debian.org/debian sid/main amd64 python3-six all 1.10.0-3 [14.4 kB] Get:18 http://httpredir.debian.org/debian sid/main amd64 python3-debian all 0.1.27 [50.9 kB] Get:19 http://httpredir.debian.org/debian sid/main amd64 libgmpxx4ldbl amd64 2:6.1.0+dfsg-2 [22.2 kB] Get:20 http://httpredir.debian.org/debian sid/main amd64 libgmp-dev amd64 2:6.1.0+dfsg-2 [628 kB] Get:21 http://httpredir.debian.org/debian sid/main amd64 ruby2.3-dev amd64 2.3.1-1 [1169 kB] Get:22 http://httpredir.debian.org/debian sid/main amd64 ruby-all-dev amd64 1:2.3.0+4 [9996 B] Get:23 http://httpredir.debian.org/debian sid/main amd64 ruby-setup all 3.4.1-9 [34.2 kB] Get:24 http://httpredir.debian.org/debian sid/main amd64 gem2deb all 0.30.1 [55.3 kB] Get:25 http://httpredir.debian.org/debian sid/main amd64 libre2-1v5 amd64 20160401+dfsg-1 [178 kB] Get:26 http://httpredir.debian.org/debian sid/main amd64 ruby-re2 amd64 0.7.0-1+b5 [21.2 kB] Fetched 6830 kB in 0s (89.0 MB/s) Selecting previously
Bug#806108: singular: FTBFS due to indep build failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, I upgraded (again) because the then last package (4.0.3-p1+ds-1) was non-usable: working on this issue was then my highest priority. I thought that I could postpone this issue, but I was wrong (obviously). Whatever, I fixed by forcing a complete build. I am on my way to submit the new package *4.0.3-p1+ds-2). Cheers, Jerome On 29/04/16 10:36, Santiago Vila wrote: > severity 806108 important > thanks > > Hi. I *really* appreciate that you consider this has a greater severity > than "important", but I prefer to keep it important for two reasons: > > * I don't have the "blessing" (so to speak) from the release managers > to make these bugs RC yet. > > * If this is serious, all the other similar bugs should be serious too. > Here is the complete list of similar bugs: > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=binary-indep;users=sanv...@debian.org > > > Well, those are my reasons, but of course if you insist that this must > be serious, go ahead. I promise that I will not downgrade it again, > otherwise it would be a very odd severity war indeed: Maintainer > raises severity and reporter downgrades it :-) > > Thanks. > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXI3s2AAoJEIC/w4IMSybj4FEIALt14ADF/mlQyyBashkqeRi+ DANq2IiGX98MkbXpZiZI6EJG1GBZJcifx+1Pqfk8ht8Vk+ZYqreCCymzR4ukw2dY 4Mia1+CqtrhgnQ3z3nbm5kmTXN13jDwinK9mawycvWYVOW6hlbaYw1XHqWO4WAfr a42bhLhqXVrIVN2OBe3NZfl/QImzRb1+H3B3ydyr71V1A7O0VLUC74qA4kvr81d2 +EJfkaHvzSgk7RYPqjuba5YgQzWMW7zMafOy1DMOqpWECcjoSwr8mXMkk1Q2qmno uAPriagKIpV+M2zBJN9XxReQlnTqjjP0Ni2Emdwk0PK2w2bTHKVVER9au5/x0Gc= =rWFS -END PGP SIGNATURE-
Bug#796633: nbd-client: Has init script in runlevel S but no matching service file
On Thu, Apr 28, 2016 at 10:13:52AM -0300, Felipe Sateler wrote: > On 28 April 2016 at 09:26, Alkis Georgopoulos wrote: > Wouter wrote: > > The reason nbd is in runlevel S is because it needs to run before > > mountnfs.sh, otherwise filesystems won't be mounted properly. > > What does this mean? Will nfs filesystems not be mounted, or > nbd-backed filesystems not be mounted properly? It means nbd-backed filesystems won't be mounted when not using systemd and not using the proper dependency headers, because insserv places the init script either too early (when there is no network) or too late (when the mountnfs.sh init script has already tried and failed to mount nbd-backed filesystems, which are marked with _netdev in fstab). > > The init > > script has a line "X-Start-Before: mountnfs" to enforce that. It could > > work if either Ubuntu doesn't support non-systemd installs anymore, or > > if mountnfs (or its systemd equivalent) has been moved out of S as well. > > Systemd provides a symlink from mountnfs to /dev/null, thus it no > longer exists. So this invariant is broken anyway. However, systemd > mounts asynchronously as devices appear, so maybe the broken invariant > is not problematic when running under systemd. Possibly, but the dependency on $network is still required, and the X-Start-Before line and (thus) the S runlevel specification is still required for non-systemd installs, too. If ubuntu no longer supports non-systemd installs (I don't know whether that's the case), then given all the above, dropping the S runlevel and removing the X-Start-Before header *should* work. However, the dependency on $network must remain (otherwise the script will be started before the server is accessible). Ideally, the patches that are referred to in Debian #812485 and #812487 are applied to ubuntu's udev and kernel, although this is not crucial (udev already manages to discover when an nbd device is connected, so boot will work, it's just that discovery of disconnects is broken). With these changes, booting the system *should* work (although I haven't tested any of the above, so please do). Shutdown might be a different matter. Doing all this *will* break non-systemd installs, however. If that's okay as a tradeoff, then you could do that. Also, I don't know what the policy is on updates to a just-released LTS Ubuntu, so maybe that's a blocker? If not, it's my hope to get a properly working systemd boot by the end of debcamp at the latest, so maybe you can fix it by updating to the then-current version of nbd in Debian unstable if no issues are found in Debian after a while. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
