Bug#778287: passwd: "userdel -f" doesn't delete logged in users
Package: passwd Version: 1:4.2-3 Severity: important Dear Maintainer, "userdel -f" doesn't delete logged in users as stated in the manual pages and as it did in previous Debian versions. Steps to reproduce the problem: # useradd test # su test & [1] 10526 # userdel -f test userdel: user test is currently used by process 10527 userdel: cannot open /etc/subuid [1]+ Stopped su test # id test uid=3000(test) gid=3000(test) groups=3000(test) I guess it's related to the subuid feature. However the file exists on this system: # ls -l /etc/subuid -rw-r--r-- 1 root root 285 Feb 13 08:50 /etc/subuid Best regards, Thomas Kähn -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages passwd depends on: ii debianutils 4.4+b1 ii libaudit1 1:2.4-1+b1 ii libc6 2.19-13 ii libpam-modules 1.1.8-3.1 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsemanage12.3-1+b1 passwd recommends no packages. passwd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777735: systemd: Disk corruption on reboot initiated through systemd
On Fri, Feb 13, 2015 at 08:02:09AM +0100, Michael Biebl wrote: > Am 13.02.2015 um 07:44 schrieb Michael Biebl: > > I went on and looked what the watchdog package does. Interestingly, it > > clamps any timeout value to 254s, thus not hitting this issue. > > Apparently, i6300esb is able to deal with such a timeout. > > > > Peter, I therefore recommend you set > > > > ShutdownWatchdogSec=254s > > > > in /etc/systemd/system.conf as well for the time being. This should be > > sufficient to workaround this issue for this buggy driver. > > Setting 256s, does indeed trigger the issue, which leads to the > > conclusion, that the driver is using a char to hold a time value (0-255). > > Actually, after a few more experiments, it turns out that for i6300esb, > the safe max value in my qemu VM is 549s. Setting it to 550s triggers > the reset. In the linux-3.16.7-ckt4 source the range of the timeout value for the i6300esb is 1s < timeout < 2*1023s. In theory it should work with the default shutdown timeout of 10min. For the ib700 the range is 0s <= timeout <= 30s, hence the error. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778286: slcfitsio: failed to build on install with parallel
Package: slcfitsio Version: 0.3.8+nosvn-4.1 When build with dpkg-buildpackage -B -j4, it failed to build. -- YunQiang Su Index: slcfitsio-0.3.8+nosvn/src/Makefile.in === --- slcfitsio-0.3.8+nosvn.orig/src/Makefile.in 2005-10-28 04:28:47.0 +0800 +++ slcfitsio-0.3.8+nosvn/src/Makefile.in 2015-02-13 15:42:59.421656474 +0800 @@ -79,7 +79,7 @@ $(MKINSDIR) $(DEST_SL_FILES_INSTALL_DIR) $(MKINSDIR) $(DEST_HLP_FILES_INSTALL_DIR) -install_modules: +install_modules: install_directories @for X in $(MODULES); \ do \ Y=$$X.$(MODULE_VERSION); \ @@ -93,7 +93,7 @@ $(LN) $$Y $(DEST_MODULE_INSTALL_DIR)/$$X; \ done -install_slfiles: +install_slfiles: install_directories @for X in $(SL_FILES); \ do \ echo $(INSTALL_DATA) $$X $(DEST_SL_FILES_INSTALL_DIR); \ @@ -103,7 +103,7 @@ fi; \ done -install_hlpfiles: +install_hlpfiles: install_directories @for X in $(HLP_FILES); \ do \ echo $(INSTALL_DATA) $$X $(DEST_HLP_FILES_INSTALL_DIR); \
Bug#777713: unblock: xorg-server/2:1.16.4-1
Control: tags -1 d-i
On 2015-02-11 20:12, Julien Cristau wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-debbugs-cc: k...@debian.org
>
> Please unblock package xorg-server. New upstream stable release with a
> few bugfixes including a CVE and a regression from the last batch of
> CVEs. Nothing udeb-relevant in these changes.
>
> unblock xorg-server/2:1.16.4-1
> unblock-udeb xorg-server/2:1.16.4-1
>
> Thanks,
> Julien
>
Ack from me, under the assumption that OsBlockSignals() and
OsRelaseSignals() stack[1].
CC'ing KiBi for the d-i ack (out of principle).
Thanks,
~Niels
[1] With 2:1.1.16.4.1, we get:
"""
OsBlockSignals();
while (timers && (int) (timers->expires - now) <= 0)
DoTimer(timers, now, &timers);
OsReleaseSignals();
"""
Plus
"""
DoTimer(OsTimerPtr timer, CARD32 now, volatile OsTimerPtr *prev)
{
CARD32 newTime;
OsBlockSignals();
[...]
OsReleaseSignals();
}
"""
This works only if the signal handling stacks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755722: systemd must sync systemclock to RTC on shutdown
Control: reassign -1 systemd 215-11 Martin Pitt [2015-02-13 7:54 +0100]: > Also, under sysvinit and upstart it is util-linux which does the > hwclock <-> sysclock dance, thus reassigning this. We shouldn't > put this logic into different packages for different init systems. Michael just pointed out that systemd masks /etc/init.d/hwclock.sh. We indeed don't want to run this during startup, but that's why it doesn't run on shutdown. So reassigning back, sorry for the noise. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#778285: conky-all: graphs use outdated values after wakup from hibernation
Package: conky-all Version: 1.9.0-6 Severity: minor Dear Maintainer, * While conky is running, hibernate your machine. * Wake it up again. * All graphs (cpugraph, memgraph, diskiograph*, *speedgraph) show outdated values. The networking graphs, up- and downspeed, only reappear after a connection is established again ( using if_gw; wlan0) * I would prefer if the graphs start fresh, i.e. with old values flushed, especially the network graphs, as they are only shown after a connection is established again. Regards, Andreas -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages conky-all depends on: ii libaudclient2 3.5~rc2-dmo1 ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libcurl3-gnutls 7.38.0-4 ii libdbus-glib-1-2 0.102-1 ii libglib2.0-0 2.42.1-1 ii libimlib2 1.4.6-2+b3 ii libiw30 30~pre9-8 ii liblua5.1-0 5.1.5-7.1 ii libncurses5 5.9+20140913-1+b1 ii libtinfo5 5.9+20140913-1+b1 ii libx11-6 2:1.6.2-3 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.1-2+b2 ii libxft2 2.3.2-1 ii libxml2 2.9.1+dfsg1-4 ii libxmmsclient60.8+dfsg-12 ii libxnvctrl0 340.46-2 conky-all recommends no packages. Versions of packages conky-all suggests: pn apcupsd pn audacious pn moc pn mpd pn xmms2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777735: systemd: Disk corruption on reboot initiated through systemd
Am 13.02.2015 um 07:44 schrieb Michael Biebl: > I went on and looked what the watchdog package does. Interestingly, it > clamps any timeout value to 254s, thus not hitting this issue. > Apparently, i6300esb is able to deal with such a timeout. > > Peter, I therefore recommend you set > > ShutdownWatchdogSec=254s > > in /etc/systemd/system.conf as well for the time being. This should be > sufficient to workaround this issue for this buggy driver. > Setting 256s, does indeed trigger the issue, which leads to the > conclusion, that the driver is using a char to hold a time value (0-255). Actually, after a few more experiments, it turns out that for i6300esb, the safe max value in my qemu VM is 549s. Setting it to 550s triggers the reset. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#778283: systemd-fsck mis-detects rotating disks and ignores passno
Control: reassign -1 util-linux Control: forcemerge 776034 -1 Stefan Fritsch [2015-02-13 7:05 +0100]: > According to the systemd-fsck man page, it should not start multiple > fscks on the same rotating disk in parallel but that does not seem to > work on LVM. The fstab has the passno field to configure the fsck order > manuall but systemd-fsck ignores its value. This is a big problem > because it greatly increases the time required for fsck. Indeed, and it also causes much bigger wearout. Merging with existing bug report. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#755722: systemd must sync systemclock to RTC on shutdown
Control: reassign -1 util-linux 2.25.2-5 Control: severity -1 normal I still disagree with critical: - If the hardware clock is so broken that at the next boot it has an earlier time than on the previous boot/ntpdate, then writing it once more at shutdown isn't going to entirely fix this problem, as it will again go sufficiently wrong if you don't reboot immediately but after some time. - Second, this doesn't "break" fsck: fsck already correctly notices that the last write time is in the future and handles that appropriately; at least that's what the original reporter mentioned. Also, under sysvinit and upstart it is util-linux which does the hwclock <-> sysclock dance, thus reassigning this. We shouldn't put this logic into different packages for different init systems. I also disagree this should be done in the first place. But I don't want to put myself into eternal wars and "who shouds the loudest wins", so I'll keep this bug open and won't make any further Severity: adjustments. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#778284: cgdb: Pacakge new upstream release 0.6.8 (2014-11-14)
Package: cgdb Version: 0.6.7-2 Severity: wishlist Please package new upstream release available at: http://cgdb.me/files/ Jari -- System Information Debian Release: jessie/sid APT Prefers testing APT policy: (990, testing) (500, unstable) Architecture: amd64 Kernel: Linux picasso 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux Locale: LANG=en_DK.UTF-8 -- Versions of packages `cgdb depends on'. Depends: libc6 2.19-15 GNU C Library: Shared libraries libncurses5 5.9+20140913-1+b1 shared libraries for terminal handling libreadline66.3-8+b3GNU readline and history libraries, run-time libtinfo5 5.9+20140913-1+b1 shared low-level terminfo library for termina gdb 7.7.1+dfsg-5GNU Debugger dpkg1.17.23 Debian package management system install-info5.2.0.dfsg.1-6 Manage installed documentation in info format -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777735: systemd: Disk corruption on reboot initiated through systemd
Am 12.02.2015 um 09:54 schrieb Peter Colberg: > [ 11.473895] systemd[1]: Failed to set timeout to 600s: Invalid argument > [ 11.474649] ib700wdt: WDT device closed unexpectedly. WDT will not stop! > > Both watchdogs close unexpectedly, but i6300esb immediately resets the > machine, while ib700wdt allows the machine to continue the shutdown. So, I think there are two bugs here: a/ the watchdog driver(s) not accepting timeouts of 600s (or rather anything > 255s) b/ the i6300esb watchdog driver resetting the machine if such a timeout is set. Arguably, b/ is the more nasty one. After discussion witch upstream, we came to the conclusion that both issues should be fixed in the driver/kernel. I went on and looked what the watchdog package does. Interestingly, it clamps any timeout value to 254s, thus not hitting this issue. Apparently, i6300esb is able to deal with such a timeout. Peter, I therefore recommend you set ShutdownWatchdogSec=254s in /etc/systemd/system.conf as well for the time being. This should be sufficient to workaround this issue for this buggy driver. Setting 256s, does indeed trigger the issue, which leads to the conclusion, that the driver is using a char to hold a time value (0-255). I wonder, if we should workaround this issue by clamping the timeout to 254s as well in systemd. Upstream was strictly against this though, as he doesn't want to paper over such issues but rather prefers to see the issue fixed at its source. So we'd have to carry a downstream patch for this. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#755722: systemd must sync systemclock to RTC on shutdown
severity 755722 grave thanks The attached service file (from [1]) seems to work if put into /etc/systemd/system/hwclock.service and enabled with systemctl enable hwclock Please include it in the package. Note that I will escalate this to the TC if you downgrade the severity of this bug again without very good reason. And repeating some old statement from upstream is NOT a good reason. [1] https://bugs.archlinux.org/task/31674[Unit] Description=Synchronise Hardware Clock to System Clock DefaultDependencies=no Before=shutdown.target [Service] Type=oneshot ExecStart=/sbin/hwclock --systohc [Install] WantedBy=reboot.target halt.target poweroff.target
Bug#778283: systemd-fsck mis-detects rotating disks and ignores passno
Package: systemd Version: 215-11 Severity: normal According to the systemd-fsck man page, it should not start multiple fscks on the same rotating disk in parallel but that does not seem to work on LVM. The fstab has the passno field to configure the fsck order manuall but systemd-fsck ignores its value. This is a big problem because it greatly increases the time required for fsck. And systems with systemd tend to do a lot of unneccessary fscks because of #755722. systemd-fsck should - correctly detect rotating disks with LVM - provide a way to override the detection manually - if it cannot detect what disks the filesystems are on (possibly because the stacking with md/lvm/crypto/iscsi/... is too complex), it should NOT start fscks in parallel. -- Package-specific info: -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-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: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-58 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-5 ii libc6 2.19-15 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.2-4+b1 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-11 ii mount 2.25.2-5 ii sysv-rc 2.88dsf-58 ii udev215-11 ii util-linux 2.25.2-5 Versions of packages systemd recommends: ii dbus1.8.16-1 ii libpam-systemd 215-11 Versions of packages systemd suggests: pn systemd-ui -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776599: python-watchdog: please provide Python3 package
On 02/13/2015 08:01 AM, Brian May wrote: Hello, If you provide me an updated version of python-watchdog, I will upload that for you too. cool, i will work on that next week thanks -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778282: bash-completion has syntax errors in the _parse_usage and _longopt functions
Package: bash-completion
Version: 1:2.1-4
Severity: important
bash-completion contains syntax errors in two functions. Executing
bash /usr/share/bash-completion/bash_completion
Output:
bash: _parse_usage: line 16: syntax error near unexpected token `('
bash: _parse_usage: line 16: ` -?(\[)+([a-zA-Z0-9?]))'
bash: error importing function definition for `_parse_usage'
bash: _longopt: line 14: syntax error near unexpected token `('
bash: _longopt: line 14: ` --+([-a-z0-9_]))'
bash: error importing function definition for `_longopt'
This bug is important because it makes various packages fail. The
desktop-base package fails because of _parse_usage failing. desktop-base
is called by tasksel in a debian installation.
Changing roots shell to dash does not help.
-- System Information:
Debian Release: 8.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bash-completion depends on:
ii bash 4.3-11+b1
ii dpkg 1.17.23
bash-completion recommends no packages.
bash-completion suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755722: systemd must sync systemclock to RTC on shutdown
On Friday 13 February 2015 00:09:00, Stefan Fritsch wrote: > > IMHO the only proper time to write the hardware clock is when we > > know the system time is correct, i. e. after an NTP sync or when > > the user sets it manually. Even if it is decided that this is right, this would require fixing in quite a lot of packages. From a quick search, at least these alevt (alevt-date) dvb-apps (dvbdate) netdate tlsdate htpdate ntpdate seem to be affected. Therefore, changing systemd's behavior at least for jessiee makes sense in any case. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778269: ITP: python-mkdocs -- Static site generator geared towards building project documentation
Yuck.
pkg_resources.VersionConflict: (Markdown 2.5.1
(/usr/lib/python2.7/dist-packages),
Requirement.parse('Markdown>=2.3.1,<2.5'))
It looks like mkdocs doesn't Markdown 2.5.1, which is the version in Debian
:-(
--
Brian May
Bug#778281: unblock (pre-approval): freerdp/1.1.0~git20140921.1.440916e+dfsg1-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please consider unblocking planned upload of package freerdp.
+ [ Bernhard Miklautz ]
+ * debian/patches:
++ Add patch 0001_fix-cmdline-parser.patch (picked from upstream).
+ Fix and improve command line parser. (Closes: #759361).
-> Bernhard Miklautz (upstream freerdp) was so kind to provide a patch for
getting
the reported Segfault behaviour (#759361) resolved for Debian jessie. I
hope for acceptance of this patch.
+ [ Mike Gabriel ]
+ * debian/copyright:
++ Mention new file client/common/test/TestClientCmdLine.c.
+
The patch adds a new test file, that I added to the file lists in
debian/changelog.
light+love,
Mike
unblock freerdp/1.1.0~git20140921.1.440916e+dfsg1-3
-- System Information:
Debian Release: 8.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'testing-updates'), (500,
'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/changelog freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/changelog
--- freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/changelog 2014-10-07 22:43:05.0 +0200
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/changelog 2015-02-13 06:02:21.0 +0100
@@ -1,3 +1,16 @@
+freerdp (1.1.0~git20140921.1.440916e+dfsg1-3) unstable; urgency=medium
+
+ [ Bernhard Miklautz ]
+ * debian/patches:
++ Add patch 0001_fix-cmdline-parser.patch (picked from upstream).
+ Fix and improve command line parser. (Closes: #759361).
+
+ [ Mike Gabriel ]
+ * debian/copyright:
++ Mention new file client/common/test/TestClientCmdLine.c.
+
+ -- Mike Gabriel Fri, 13 Feb 2015 05:30:13 +0100
+
freerdp (1.1.0~git20140921.1.440916e+dfsg1-2) unstable; urgency=medium
* debian/control:
diff -Nru freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/copyright freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/copyright
--- freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/copyright 2014-09-22 21:58:42.0 +0200
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/copyright 2015-02-13 05:28:29.0 +0100
@@ -836,6 +836,7 @@
channels/sample/client/server_chan_test.cpp
client/X11/generate_argument_docbook.c
client/common/test/TestClientChannels.c
+ client/common/test/TestClientCmdLine.c
client/common/test/TestClientRdpFile.c
libfreerdp/dummy.c
libfreerdp/gdi/test/TestGdiRop3.c
diff -Nru freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/0001_fix-cmdline-parser.patch freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/0001_fix-cmdline-parser.patch
--- freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/0001_fix-cmdline-parser.patch 1970-01-01 01:00:00.0 +0100
+++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/0001_fix-cmdline-parser.patch 2015-02-13 05:23:40.0 +0100
@@ -0,0 +1,360 @@
+Description: Command line parser fixes.
+Author: Bernhard Miklautz
+Abstract:
+ The command line parser had serveral problems when old style syntax
+ was used.
+
+diff --git a/client/common/cmdline.c b/client/common/cmdline.c
+index 3d0cc2d..34064ea 100644
+--- a/client/common/cmdline.c
b/client/common/cmdline.c
+@@ -421,7 +421,7 @@ char** freerdp_command_line_parse_comma_separated_values(char* list, int* count)
+ int index;
+ int nCommas;
+
+- nArgs = nCommas = 0;
++ nCommas = 0;
+
+ for (index = 0; list[index]; index++)
+ nCommas += (list[index] == ',') ? 1 : 0;
+@@ -915,8 +915,13 @@ BOOL freerdp_client_detect_command_line(int argc, char** argv, DWORD* flags)
+ *flags |= COMMAND_LINE_SIGIL_DASH | COMMAND_LINE_SIGIL_DOUBLE_DASH;
+ *flags |= COMMAND_LINE_SIGIL_ENABLE_DISABLE;
+
+- if (windows_cli_count > posix_cli_count)
++ if (posix_cli_status <= COMMAND_LINE_STATUS_PRINT)
++ return compatibility;
++
++ /* Check, if this may be windows style syntax... */
++ if ((windows_cli_count && (windows_cli_count >= posix_cli_count)) || (windows_cli_status <= COMMAND_LINE_STATUS_PRINT))
+ {
++ windows_cli_count = 1;
+ *flags = COMMAND_LINE_SEPARATOR_COLON;
+ *flags |= COMMAND_LINE_SIGIL_SLASH | COMMAND_LINE_SIGIL_PLUS_MINUS;
+ }
+@@ -1020,8 +1025,7 @@ int freerdp_client_parse_command_line_arguments(int argc, char** argv, rdpSettin
+ freerdp_client_command_line_pre_filter, freerdp_client_command_line_post_filter);
+ }
+
+-
+- arg = CommandLineFindArgumentA(args, "v");
++ CommandLineFindArgumentA(args, "v");
+
+ arg = args;
+
+diff --git a/client/common/compatibility.c b/client/common/compatibility.c
+index 788b413..c7177c2 100644
+--- a/client/common/compatibility.c
b/client/common/compatibility.c
+@@ -118,18 +118,25 @@ void freerdp_client_old_parse_hostname(char* str, char** ServerHostname
Bug#778269: ITP: python-mkdocs -- Static site generator geared towards building project documentation
On 13 February 2015 at 13:31, Brian May wrote: > What is the cleanest way of resolving these numerous Lintian errors? > Never mind, I have included one copy of the file in debian/missing-sources, and copy it as required in debian/rules. Now down to three lintian warnings: W: python-mkdocs: image-file-in-usr-lib usr/lib/python2.7/dist-packages/mkdocs/themes/mkdocs/img/grid.png W: python-mkdocs: binary-without-manpage usr/bin/mkdocs W: python-mkdocs-doc: extra-license-file usr/share/doc/python-mkdocs-doc/html/license/highlight.js/LICENSE Also worth noting I can't build python3-mkdocs just yet, it depends on python3-watchdog - see #776599 -- Brian May
Bug#778280: missing kompozer/nvu wysiwyg web editor
Package: kompozer Severity: important hi, i am missing kompozer or nvu. please add this again to debian. Even if it is possible sometimes unstable and possible discontinued it is still the best wysiwyg web editor that is opensource and known by me. thanks a lot and keep up the good work. treaki -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777649: cgmanager security update for jessie
Quoting Niels Thykier (ni...@thykier.net): > Control: tags -1 confirmed moreinfo > > On 2015-02-12 05:32, Serge Hallyn wrote: > > Here is a new debdiff. (tested in its original upstream version > > in v0.36) Maybe it would've been easier to squash the two patches, > > but this way it's easier to tell whether the patches match what is > > upstream. > > > > [...] > > Ack, looks better. :) Please add the (missing parts of this) patch to > unstable first That is now in sid, > and then upload the target fixes into testing with > version 0.33-2+deb8u1. Sorry, I'm not sure what you mean. I don't actually have upload rights. Should I ask someone to sponsor such a package, or just post the debdiff here? (It could be the same as the last debdiff I posted, with the version number changed, or I could squash the two patches as I mentioned before) > Please remove the moreinfo tag once the above have been done. thanks, -serge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778279: python-softlayer: prerm/postinst for update-alternatives won't work
Package: python-softlayer Version: 3.2.0-1 Severity: important The postinst and prerm for python-softlayer are misnamed as python2-softlayer. As a result, update alternatives for python-softlayer doesn't get called. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778269: ITP: python-mkdocs -- Static site generator geared towards building project documentation
What is the cleanest way of resolving these numerous Lintian errors? E: python-mkdocs-doc: privacy-breach-may-use-debian-package usr/share/doc/python-mkdocs-doc/html/404.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) E: python-mkdocs-doc: privacy-breach-may-use-debian-package usr/share/doc/python-mkdocs-doc/html/about/license/index.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) E: python-mkdocs-doc: privacy-breach-may-use-debian-package usr/share/doc/python-mkdocs-doc/html/about/release-notes/index.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) E: python-mkdocs-doc: privacy-breach-may-use-debian-package usr/share/doc/python-mkdocs-doc/html/index.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) E: python-mkdocs-doc: privacy-breach-may-use-debian-package usr/share/doc/python-mkdocs-doc/html/user-guide/configuration/index.html You may use libjs-jquery package. ( https://code.jquery.com/jquery-1.10.2.min.js) E: python-mkdocs-doc: privacy-breach-may-use-debian-package usr/share/doc/python-mkdocs-doc/html/user-guide/styling-your-docs/index.html You may use libjs-jquery package. ( https://code.jquery.com/jquery-1.10.2.min.js) E: python-mkdocs-doc: privacy-breach-may-use-debian-package usr/share/doc/python-mkdocs-doc/html/user-guide/writing-your-docs/index.html You may use libjs-jquery package. ( https://code.jquery.com/jquery-1.10.2.min.js) E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/amelia/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/amelia/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/bootstrap/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/bootstrap/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/cerulean/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/cerulean/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/cosmo/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/cosmo/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/cyborg/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/cyborg/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/flatly/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/flatly/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/journal/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/journal/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/mkdocs/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/mkdocs/fonts/fontawesome-webfont.ttf also in fonts-font-awesome W: python-mkdocs: image-file-in-usr-lib usr/lib/python2.7/dist-packages/mkdocs/themes/mkdocs/img/grid.png E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-packages/mkdocs/themes/readable/base.html You may use libjs-jquery package. (https://code.jquery.com/jquery-1.10.2.min.js) W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/readable/fonts/fontawesome-webfont.ttf also in fonts-font-awesome W: python-mkdocs: duplicate-font-file usr/lib/python2.7/dist-packages/mkdocs/themes/readthedocs/fonts/fontawesome-webfont.ttf also in fonts-font-awesome E: python-mkdocs: privacy-breach-may-use-debian-package usr/lib/python2.7/dist-pack
Bug#778278: mate-settings-daemon: very bad condition (99% cpu load and more) after high system load
Package: mate-settings-daemon Version: 1.8.1-1~bpo70+1 Severity: important hi, that problem befall/occured after a porblem with wgets mirror mode, i have discribed that in Bug#778277, thees problem lead into a process (wget) that used up all memory and swap it could resoulded in very high system load and after that kernel killed that process. ive got some messages about kernel modules which had problems that way but nothing about what i have discovered after that. shortly after my system recovered from this odd situation the numlock led on my keyboard started to go on and of rapidly in a very fast and but not stedy frequency. first i took another look into dmesg but i couldnt find anything new there. after that i saw that my cpu load were up by nearly 100%. I started my system process manager (htop) and found out that the process called mate-settings-daemon were using up that cpu cycles. I took out my phone started the camara software and documented that in a video. After that i killed that thread of mate-settings-daemon using htop but after some time my system cpu io and after that my system cpu user value began to raise again and my numlock lead did the same stuff. another look into htop revealed that another thread of that mate-settings-daemon was doing the same shit. this time i typed in $ killall mate-settings-daemon into another terminal emulator... and guess what, afer some time the same shit happened again... now i got a little bit more rude: $ killall -v mate-settings-daemon mate-settings-daemon(6023) mit Signal 15 beendet $ killall -v mate-settings-daemon mate-settings-daemon(6053) mit Signal 15 beendet $ killall -v mate-settings-daemon mate-settings-daemon(6080) mit Signal 15 beendet $ killall -v mate-settings-daemon mate-settings-daemon(6080) mit Signal 15 beendet $ killall -v mate-settings-daemon mate-settings-daemon(6080) mit Signal 15 beendet $ killall -v mate-settings-daemon mate-settings-daemon(6080) mit Signal 15 beendet $ killall -v mate-settings-daemon ^[[Amate-settings-daemon(6080) mit Signal 15 beendet $ killall -v mate-settings-daemon and after i waited some time the problem with the numlock led didnt happened again. But i still got some problems with high cpu load. after another look into htop i found out that the process dconf-service had a high persentage of that load. i tryed to kill, first using htop after that using killall, but it resisted. After that i got again a bit more rude and used the sigkill (9) signal and killed mate-settings-daemon again after that.: $ killall -v dconf-service dconf-service(4353) mit Signal 15 beendet $ killall -v dconf-service dconf-service(4353) mit Signal 15 beendet $ killall -v dconf-service dconf-service(4353) mit Signal 15 beendet $ killall -v dconf-service dconf-service(4353) mit Signal 15 beendet $ killall -v dconf-service dconf-service(4353) mit Signal 15 beendet $ killall -v -9 dconf-service dconf-service(4353) mit Signal 9 beendet $ killall -v mate-settings-daemon mate-settings-daemon(6100) mit Signal 15 beendet i guess i will now have a uncomplete mate session and the need to log off and on again :( (not as bad as rebooting the whole system but still not good, need to invent an uptime counter for the mate session uptume to show off...). i am sorry that i havent got the necessary knowledge to debug that, that had been a better solution then just killing that thread, but i hope you will be able to reproduce that problem with that information. I guess the videos taken dosnt contain more relevant information, just some funny reactions to this situation, but if you thing different i am willing to share the relevant frames and samples of that video. Just ask... i hope this information are hapefull and you will be able to put yourself into my position and reproduce that situation to debugg that pice of software. And if you like to smile you will have a little smile to ;). please keep me up and running on this issue to let me smile to. there is nothing better then funny behavior of data processing systems (EDP-Systems) and that situations around that and all that stuff... thanks a lot and keep up the good work!! greetings treaki -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mate-settings-daemon depends on: ii mate-settings-daemon-gstreamer 1.8.1-1~bpo70+1 mate-settings-daemon recommends no packages. mate-settings-daemon suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778212: closed by Ben Hutchings
On Thu, 2015-02-12 at 22:08 +0100, Adam Borowski wrote: > On Thu, Feb 12, 2015 at 05:21:14PM +, Debian Bug Tracking System wrote: > > This is an automatic notification regarding your Bug report > > which was filed against the src:linux package: > > > > #778212: linux: please build the kernel and udebs on x32 > > > > It has been closed by Ben Hutchings . > > > No, you need to make the installer use the amd64 packages for this. > > 1. d-i cannot currently use packages from a foreign architecture (same > applies for example to i386 on non-ancient hardware) > > 2. neither can it use udebs (needed to boot d-i itself) We have multiarch now and I have no intention of adding more fake-architecture packages as a workaround for non-multiarch-aware tools (in fact I'd like to remove those that we have now, wherever the real architecture is a release architecture). > 3. amd64 kernels currently have x32 syscalls disabled unless a special > argument is passed on the command line. This is fragile, especially if > fancy combinations of bootloader with preseeding are involved. Right, so you'll want to add that parameter to the initial configuration in grub-installer. > I'm not going to force reopen this, as you know more about Debian kernel > packaging than me (duh), but at least in my unofficial x32 release I'm going > to use kernel+udebs with this patch, unless you can enlighten me. Would you > please elaborate a bit about what do I understand wrong? And what the plans > for foreign kernels in d-i are? My plan is that you implement this since you're adding the first architecture that needs it. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Bug#737750: debian-installer: Netboot initrd does not download ata-modules or sata-modules udebs
Greg Bell (2015-02-12): > I would like to mention that I've just hit this bug. > > I've got a handful of dell laptops here that will install perfectly via DVD, > but the netboot image fails to load the drivers for the sata controller. > > I've confirmed that the network is functional, and watched a tcpdump of the > installer downloading the installer components from three different mirrors. Great, please attach /var/log/syslog from both a DVD-based install and from a netboot-based install. Please mention the netboot files you're serving as well (even if the relevant information should be in syslog already, that wouldn't hurt). Mraw, KiBi. signature.asc Description: Digital signature
Bug#778277: wget memory problem in mirror mode, possible memory leak
Package: wget Version: 1.13.4-3+deb7u2 Severity: important hi, i have tryed to use wgets mirror mode to mirror a webserver with a lot of content. it seams to work grate at first, downloaded robots.txt at first and done its job. some time later i realised that my box started to swap, nothing unusual... After that i got some serius performace problems and i realiced that ram and swap were full. That was the last thing i could do after my system frezzed entirely... After some time my box became usable again and the dmesg reported a lot of problems related to a high system load. At last there was a statement about that the kernel killed wget because of to much memory consumtion. here is extract: [269277.634832] Out of memory: Kill process 4049 (wget) score 780 or sacrifice child [269277.634843] Killed process 4049 (wget) total-vm:5596716kB, anon-rss:4111532kB, file-rss:56kB i have just a command lige this: $ wget -a wgetlog -m http://domain.tld/path/ and let it run and this is the resould please fix that. After my system recovered from that odd situation i discovered another odd bug which occoured with my mate desktop enviorment. mate-settings-daemon got 99% cpu load and the numlock led on my keyboard was switching on and of rapidly. ill report that bug next. thanks in advance and keep up the good work greetings treaki -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wget depends on: ii dpkg 1.16.15 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38+deb7u6 ii libgcrypt111.5.0-5+deb7u2 ii libgnutls262.12.20-8+deb7u2 ii libgpg-error0 1.10-3.1 ii libidn11 1.25-2 ii zlib1g 1:1.2.7.dfsg-13 wget recommends no packages. wget suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778276: jnr-posix: Please update it to 3.0.9 or a more recent release
Package: src:jnr-posix Version: 1.1.8-2 Severity: wishlist As title says. -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-0.bpo.1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche signature.asc Description: Digital signature
Bug#737750: debian-installer: Netboot initrd does not download ata-modules or sata-modules udebs
I would like to mention that I've just hit this bug. I've got a handful of dell laptops here that will install perfectly via DVD, but the netboot image fails to load the drivers for the sata controller. I've confirmed that the network is functional, and watched a tcpdump of the installer downloading the installer components from three different mirrors. The netboot images are completely missing a handful of drivers according to this link: http://stackoverflow.com/questions/26524888/debian-missing-firmware-with-pxe-installation And it appears that the drivers are not being downloaded from the mirror for some reason. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778275: miro: please make the build reproducible
Source: miro
Version: 6.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi,
While working on the "reproducible builds" effort [1], we have noticed
that miro could not be built reproducibly.
The attached patch removes timestamps from the build system. Once
applied, miro can be built reproducibly in our current reproducible
toolchain.
[1]: https://wiki.debian.org/ReproducibleBuilds
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff -urNad miro.orig/miro-6.0/debian/patches/180_reproducible_build
miro/miro-6.0/debian/patches/180_reproducible_build
--- miro.orig/miro-6.0/debian/patches/180_reproducible_build1970-01-01
01:00:00.0 +0100
+++ miro/miro-6.0/debian/patches/180_reproducible_build 2015-02-12
23:59:27.917458326 +
@@ -0,0 +1,37 @@
+--- miro-6.0.orig/linux/setup.py
miro-6.0/linux/setup.py
+@@ -62,6 +62,7 @@ import platform
+ import pwd
+ import subprocess
+ import time
++import email.utils
+ import shutil
+
+ from Pyrex.Distutils import build_ext
+@@ -360,7 +361,7 @@ data_files += [
+ # of things that have file-related side-effects
+ if not "clean" in sys.argv:
+ # gzip the man page
+-os.system("gzip -9 < %s > %s" % (
++os.system("gzip -9n < %s > %s" % (
+ os.path.join(platform_dir, 'miro.1'),
+ os.path.join(platform_dir, 'miro.1.gz')))
+ # copy miro.1.gz to miro.real.1.gz so that lintian complains less
+@@ -403,13 +404,16 @@ class miro_install_data(install_data):
+ # We don't use the dist utils copy_file() because it only copies
+ # the file if the timestamp is newer
+ shutil.copyfile(source, dest)
++changelog = subprocess.check_output(('dpkg-parsechangelog',
++ '--show-field', 'Date'))
++buildtime = str(time.mktime(email.utils.parsedate(changelog)))
+ expand_file_contents(dest, APP_REVISION=revision,
+ APP_REVISION_NUM=revisionnum,
+ APP_REVISION_URL=revisionurl,
+ APP_PLATFORM='linux',
+ BUILD_MACHINE="%s@%s" % (getlogin(),
+ os.uname()[1]),
+- BUILD_TIME=str(time.time()),
++ BUILD_TIME=buildtime,
+ MOZILLA_LIB_PATH="")
+ self.outfiles.append(dest)
+
diff -urNad miro.orig/miro-6.0/debian/patches/series
miro/miro-6.0/debian/patches/series
--- miro.orig/miro-6.0/debian/patches/series2015-02-12 22:30:21.383101937
+
+++ miro/miro-6.0/debian/patches/series 2015-02-12 23:58:15.154246077 +
@@ -5,3 +5,4 @@
150_codec_id.patch
160_fixyoutubedl.patch
170_no_enfmp.patch
+180_reproducible_build
Bug#776599: python-watchdog: please provide Python3 package
Hello, I require python3-watchdog, because it is required by python-mkdocs, which is required by the latest version of djangorestframework. I am about to upload your python-pathtools_0.1.2-2.dsc to unstable; I imagine it will get stuck in new for a while. If you provide me an updated version of python-watchdog, I will upload that for you too. Thanks. -- Brian May
Bug#778274: mauve: please make the build reproducible
Source: mauve Version: 20140821-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi, While working on the "reproducible builds" effort [1], we have noticed that mauve could not be built reproducibly. The attached patch removes timestamps from the build system. Once applied, mauve can be built reproducibly in our current reproducible toolchain. [1]: https://wiki.debian.org/ReproducibleBuilds Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff -urNad mauve.orig/mauve-20140821/debian/rules mauve/mauve-20140821/debian/rules --- mauve.orig/mauve-20140821/debian/rules 2015-02-12 23:49:53.696111641 + +++ mauve/mauve-20140821/debian/rules 2015-02-12 23:54:10.779458633 + @@ -4,6 +4,7 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +BUILD_DATE := $(shell dpkg-parsechangelog --show-field Date) build: build-stamp build-arch: build-stamp @@ -29,8 +30,8 @@ mkdir -p debian/mauve/usr/src/mauve cp -a $(filter-out debian, $(wildcard .??* *)) \ debian/mauve/usr/src/mauve/ - tar -c --gzip -f $(CURDIR)/debian/mauve/usr/src/mauve.tar.gz \ - -C debian/mauve/usr/src mauve + GZIP="-9n" tar -c --gzip -f $(CURDIR)/debian/mauve/usr/src/mauve.tar.gz \ + -C debian/mauve/usr/src --mtime="$(BUILD_DATE)" mauve rm -rf debian/mauve/usr/src/mauve # Build architecture-independent files here.
Bug#743310: rsnapshot: Program calls with arguments containing quotations mark don't work anymore
Le lundi 09 février 2015 à 23:07 +, Christoph Egger a écrit : > Package: rsnapshot > Version: 1.3.1-4 > Followup-For: Bug #743310 > > Hi! Hi, > > Guess it has something to do with additional quoting. Makes rsnapshot mostly > useless for me. I'm sorry to have introduced such a problem by cherry-picked the upstream patch; the last known author is about to abandon the maintenance of rsnapshot (due to inactivity) to other users to fix some old code base of the software (https://github.com/bebehei/rsnapshot/issues/1). I've missed the freeze deadline by trying to update rsnapshot to the last upstream git repo (there was lots of changes and improvements i wanted to be done and the project start to be inactive) and it is too late for this important fix. I'll try to look further on the take over to see what happen. > > /etc/rsnapshot.conf > # ssh has no args passed by default, but you can specify some here. > # > ssh_args-i /root/.ssh/id_rsa_backup > > > /bin/cp -al /srv/rsnapshot/daily.0 /srv/rsnapshot/daily.1 > /usr/bin/rsync -ax --delete --numeric-ids --relative --delete-excluded \ > --rsh="/usr/bin/ssh -i /root/.ssh/id_rsa_backup" \ > user@host:path \ > /srv/rsnapshot/daily.0/entry/ > rsync: Failed to exec /usr/bin/ssh -i /root/.ssh/id_rsa_backup: No such file > or directory (2) > rsync error: error in IPC code (code 14) at pipe.c(85) [Receiver=3.1.1] > rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] > rsync error: error in IPC code (code 14) at io.c(226) [Receiver=3.1.1] > > > -- System Information: > Debian Release: 8.0 > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages rsnapshot depends on: > ii liblchown-perl 1.01-2+b1 > ii logrotate 3.8.7-1+b1 > ii perl5.20.1-5 > ii rsync 3.1.1-2+b1 > > Versions of packages rsnapshot recommends: > ii openssh-client [ssh-client] 1:6.7p1-3 > > rsnapshot suggests no packages. > > -- Configuration Files: > /etc/cron.d/rsnapshot changed [not included] > /etc/rsnapshot.conf changed [not included] > > -- no debconf information > signature.asc Description: This is a digitally signed message part
Bug#777706: A couple of patches
I've attached here two debdiffs for a couple of options which may be helpful. It looks like the underlying bug has been fixed between versions 1.1 and 1.2 of NUT-Monitor, as the configuration directory is now being created with a sensible mode (0700). The attached patch `fix-permissions-on-start.debdiff' causes NUT-Monitor to detect and correct unsafe permissions on ~/.nut-monitor automatically when it is started. It also includes a NEWS item explaining this. The second patch, `just-warn.debdiff' merely includes a NEWS item explaining the problem and suggesting a fix. Hopefully one of these approaches may be sufficient. -- Michael Fincham Catalyst fix-permissions-on-start.debdiff Description: Binary data just-warn.debdiff Description: Binary data pgpKU9VLZRsEZ.pgp Description: PGP signature
Bug#778273: simplepie: please make the build reproducible
Source: simplepie
Version: 1.3.1+dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi,
While working on the "reproducible builds" effort [1], we have noticed
that simplepie could not be built reproducibly.
The attached patch removes timestamps from the build system. Once
applied, simplepie can be built reproducibly in our current reproducible
toolchain.
[1]: https://wiki.debian.org/ReproducibleBuilds
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff -urNad
simplepie.orig/simplepie-1.3.1+dfsg/debian/patches/reproducible_build.patch
simplepie/simplepie-1.3.1+dfsg/debian/patches/reproducible_build.patch
--- simplepie.orig/simplepie-1.3.1+dfsg/debian/patches/reproducible_build.patch
1970-01-01 01:00:00.0 +0100
+++ simplepie/simplepie-1.3.1+dfsg/debian/patches/reproducible_build.patch
2015-02-12 23:36:57.665902167 +
@@ -0,0 +1,11 @@
+--- simplepie-1.3.1+dfsg.orig/build/compile.php
simplepie-1.3.1+dfsg/build/compile.php
+@@ -67,7 +67,7 @@ $compiled = preg_replace("#\n\n\n+#", "\
+ // Hardcode the build
+ $compiled = str_replace(
+ "define('SIMPLEPIE_BUILD', gmdate('YmdHis',
SimplePie_Misc::get_build()))",
+- "define('SIMPLEPIE_BUILD', '" . gmdate('YmdHis', time()) . "')",
++ "define('SIMPLEPIE_BUILD', '" . gmdate('YmdHis',
strtotime(`dpkg-parsechangelog --show-field Date`)) . "')",
+ $compiled
+ );
+
diff -urNad simplepie.orig/simplepie-1.3.1+dfsg/debian/patches/series
simplepie/simplepie-1.3.1+dfsg/debian/patches/series
--- simplepie.orig/simplepie-1.3.1+dfsg/debian/patches/series 2015-02-12
23:35:00.124727344 +
+++ simplepie/simplepie-1.3.1+dfsg/debian/patches/series2015-02-12
23:36:54.613767783 +
@@ -1,3 +1,4 @@
include_idn.patch
cache_directory.patch
fix_compile_file.patch
+reproducible_build.patch
Bug#778261: Buffer overflow in GIF encoder
Control: tags -1 moreinfo On Thu, 12. Feb 23:13 Moritz Muehlenhoff wrote: > Package: byzanz > Severity: important > Tags: security > > Hi, > this was reported by Red Hat: > https://bugzilla.redhat.com/show_bug.cgi?id=852481 > > I'm afraid there are no further details, but maybe you can > get in touch with upstream; I suppose Red Hat had contacted > them and it might already be fixed by now? Hi Moritz, I have been trying to find out more about this security issue but so far without having any luck. Apparently the bug was reported 2,5 years ago but there are no hints at redhat's bug tracker which could help us or would at least point us to the affected code in question. Why did they escalate this to seclists.org just now? http://seclists.org/oss-sec/2015/q1/447 I checked upstream's git repository but I could not find any commits related to some kind of security issue with the GIF encoder or the playback tool. https://git.gnome.org/browse/byzanz/ However I know for sure, if upstream released a fix it would be included in Debian. The package is up to date and only some minor language updates from November 2014 are currently missing. I couldn't find anything useful at Fedora either. http://pkgs.fedoraproject.org/cgit/byzanz.git/ I will keep an eye on this Red Hat bug report but at the moment I just have not enough information to work on something. Regards, Markus signature.asc Description: Digital signature
Bug#778253: Library version
Control: notfound -1 3.1.2-11ghigo Control: found -1 3.1.2-10 On Thu, Feb 12, 2015 at 09:04:44PM +0100, Goffredo Baroncelli wrote: > I noticed only now that the library version reported is the 3.1.2-11ghigo. > This > is a my mistake. 3.1.2-11ghigo is the library which I rebuild with the patch. > The problem is related to the 3.1.2-10. > > BR > G.Baroncelli > Adding the above control messages updates the version number tracked in the bug tracking system. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778272: magic: please make the build reproducible
Source: magic
Version: 7.5.241-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi,
While working on the "reproducible builds" effort [1], we have noticed
that magic could not be built reproducibly.
The attached patch removes timestamps from the build system. Once
applied, magic can be built reproducibly in our current reproducible
toolchain.
[1]: https://wiki.debian.org/ReproducibleBuilds
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff -urNad magic.orig/magic-7.5.241/debian/patches/07-reproducible-build.patch
magic/magic-7.5.241/debian/patches/07-reproducible-build.patch
--- magic.orig/magic-7.5.241/debian/patches/07-reproducible-build.patch
1970-01-01 01:00:00.0 +0100
+++ magic/magic-7.5.241/debian/patches/07-reproducible-build.patch
2015-02-12 23:12:09.332451746 +
@@ -0,0 +1,11 @@
+--- magic-7.5.241.orig/tcltk/Makefile
magic-7.5.241/tcltk/Makefile
+@@ -8,7 +8,7 @@ SRCS = tclmagic.c
+
+ include ${MAGICDIR}/defs.mak
+
+-DFLAGS += -DMAGIC_DATE="\"`date`\""
++DFLAGS += -DMAGIC_DATE="\"`dpkg-parsechangelog -l../debian/changelog
--show-field Date`\""
+ CLEANS += magic.sh magic.tcl magicexec magicdnull
+
+ TCL_FILES = \
diff -urNad magic.orig/magic-7.5.241/debian/patches/series
magic/magic-7.5.241/debian/patches/series
--- magic.orig/magic-7.5.241/debian/patches/series 2015-02-12
22:30:06.606443393 +
+++ magic/magic-7.5.241/debian/patches/series 2015-02-12 23:12:06.200314190
+
@@ -4,3 +4,4 @@
04-fhs-images.patch
05-readline-reference-removal.patch
06-script-adjustments.patch
+07-reproducible-build.patch
Bug#777635: [Python-modules-team] Bug#777635: python-odf: please make the build reproducible
On 2015-02-12 17:44, Chris Lamb wrote: > > How about changing doxygen to default to HTML_TIMESTAMP=NO in Debian? > > Whilst this would benefit the reproducible project, I worry this would > be a little too invasive and unexpected as a general default. I don't think so, but let us ask the maintainer: Matthias, to make builds reproducible, we need to eliminate timestamps and such stuff from build results. Do you think, not having timestamps in HTML generated by doxygen would be a useful default? Maybe even acceptable by upstream? Otherwise, all Debian packages that use doxygen need to be changed to use HTML_TIMESTAMP=NO. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777038: gnome-icon-theme-symbolic: description's URL broken (404) debdiff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 diff -Nru gnome-icon-theme-symbolic-3.12.0/debian/changelog gnome-icon-theme-symbolic-3.12.0/debian/changelog - --- gnome-icon-theme-symbolic-3.12.0/debian/changelog 2014-03-25 22:20:54.0 +1300 +++ gnome-icon-theme-symbolic-3.12.0/debian/changelog 2015-02-13 05:26:44.0 +1300 @@ -1,3 +1,9 @@ +gnome-icon-theme-symbolic (3.12.0-2) unstable; urgency=medium + + * Fix broken link in package description + + -- John Billings Fri, 13 Feb 2015 04:59:07 +1300 + gnome-icon-theme-symbolic (3.12.0-1) unstable; urgency=medium [ Jackson Doak ] diff -Nru gnome-icon-theme-symbolic-3.12.0/debian/control gnome-icon-theme-symbolic-3.12.0/debian/control - --- gnome-icon-theme-symbolic-3.12.0/debian/control 2014-03-25 22:27:08.0 +1300 +++ gnome-icon-theme-symbolic-3.12.0/debian/control 2015-02-13 05:32:42.0 +1300 @@ -2,12 +2,11 @@ # # Modifications should be made to debian/control.in instead. # This file is regenerated automatically in the clean target. - - Source: gnome-icon-theme-symbolic Section: gnome Priority: optional Maintainer: Debian GNOME Maintainers - -Uploaders: Andreas Henriksson , Michael Biebl , Simon McVittie , Sjoerd Simons +Uploaders: Andreas Henriksson , John Billings , Michael Biebl , Simon McVittie , Sjoerd Simons Build-Depends: debhelper (>= 9), dh-autoreconf, gnome-pkg-tools (>= 0.10) @@ -16,7 +15,7 @@ pkg-config, libgtk2.0-bin, icon-naming-utils (>= 0.8.7) - -Standards-Version: 3.9.5 +Standards-Version: 3.9.6 Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-icon-theme-symbolic Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/gnome-icon-theme-symbolic @@ -37,4 +36,4 @@ directories, and devices. . These stylised icons are symbolic variations on the standard - - theme (see http://www.freedesktop.org/wiki/SymbolicIcons). + theme (see https://wiki.gnome.org/Design/OS/SymbolicIcons). diff -Nru gnome-icon-theme-symbolic-3.12.0/debian/control.in gnome-icon-theme-symbolic-3.12.0/debian/control.in - --- gnome-icon-theme-symbolic-3.12.0/debian/control.in2014-03-08 14:58:23.0 +1300 +++ gnome-icon-theme-symbolic-3.12.0/debian/control.in 2015-02-13 05:31:58.0 +1300 @@ -11,7 +11,7 @@ pkg-config, libgtk2.0-bin, icon-naming-utils (>= 0.8.7) - -Standards-Version: 3.9.5 +Standards-Version: 3.9.6 Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-icon-theme-symbolic Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/gnome-icon-theme-symbolic @@ -32,4 +32,4 @@ directories, and devices. . These stylised icons are symbolic variations on the standard - - theme (see http://www.freedesktop.org/wiki/SymbolicIcons). + theme (see https://wiki.gnome.org/Design/OS/SymbolicIcons). -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU3TPvAAoJEIh2j3pq1+LIT/cP/AlMZGbbg1oz7wVg4LlPQdLq RHe2CEH77I+/iGVemQf0MNrSuZW7FgvzxiXiyM+fpeyoB5QxQyOEpT919H/J6l/T CWao9NvAfYebTYBzabv075Qzfj+CGdJ9O9s12ju6++epDhuaCYefAByIAF0Znjl1 f/F/zm5zGhf7pxCFTlkRhdz9zOl7LVReVv5YHxmWQGg05JWm/Zu4ABwXEzk3OHF4 zNVRi0iOzwCMMa1nJt7cIzE8YTH7VfT38BxSCgbRMGlGPj+pXgsAW+qEAnIfvjY/ NfhQC6IefEoYVfN/n7i8YQY4XFua4uD0dOrrDF3DFoTXYBLnKZJ55HmhyBJNmk6x Q86FqfzR/xhNST+OqiyyKOxdmksSs9dmrKfj9wLoUfVoMqKMFc43Jlt/NGXf4vux T0JdHvLd9sd3JjOe4hpFcW7usry2Xu2qagmU8aloKcjaC1pphVja87pjENwuFlW1 ZqpZMbmnrEXwNxGXzjidjpFg4ZyG4rFMwbSZTuor3c7Jb2y5qoZXIFqu2dekoKnv 0sZbBe4Njd+I088bhiJou324k4iChnVt3d+TX5gA3SmPHPCB+ojxH1LFRKZECTUJ RkNMQESlxB7Oc7uNaNQCdo6xB8j0YQn+sqb+/+e98XLyDbQOAEujH1n3x1mzb5Fp 94/6XX4NqeOAot2PEF+R =PZah -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778271: debian-maintainers: Annual ping for Hugo Lefeuvre (DM)
Package: debian-maintainers Severity: normal Hi, Here is my annual ping (sorry, a bit late maybe...). I'm still interested in maintaining my packages. Best regards, Hugo -- Hugo Lefeuvre (hugo6390)|www.hugo6390.org 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E signature.asc Description: Digital signature
Bug#755722: systemd must sync systemclock to RTC on shutdown
You really should CC the the submitter when responing. On Tuesday 10 February 2015 09:56:28, Martin Pitt wrote: > Control: severity -1 normal > > Stefan Fritsch [2015-01-31 10:19 +0100]: > > severity 755722 serious > > retitle 755722 systemd must sync systemclock to RTC on shutdown > This is severity inflation according to > https://www.debian.org/Bugs/Developer#severities ; adjusting back to > original severity. No. It breaks other software, like fsck and make. I would call make an unrelated package which would make severity critical appropriate. > I also disagree with the retitling, FTR. > > > Systemd must make sure that the system clock does not go > > backwards, > > which causes all kinds of problems, with file systems and with > > other software. To achieve that, systemd has to sync the system > > time to RTC on shutdown. > > I disagree. As the discussion showed, it is in no way clear why the > system time should be more accurate than the hardware clock; on most > hardware it will be the other way around. I don't deny that. But monotonic time is more important than accurate time. You have not commented on that in any way. On long running systems, even if nothing modifies the system clock the normal drift between system time and RTC can cause the system time to go backwards when the system is rebooted. Therefore the system time must be synced to the RTC on shutdown. > IMHO the only proper time to write the hardware clock is when we > know the system time is correct, i. e. after an NTP sync or when > the user sets it manually. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
On Tue, 20 Jan 2015 12:42:05 +0100 Miguel wrote: > I'm running Debian testing (jessie) on an HP EliteBook 840 G1 laptop. > Everything goes reasonably well, even very well, except that after > running apt-get update/upgrade on Monday (15 December) I cannot halt > (poweroff) the computer. When I try to switch it off it just reboots. I > manage to get it in sleep mode by pressing the the physical start button > and this is what I'm doing since then. No previous problems in this > sense before that upgrade. I have 'intel-microcode' and > 'firmware-linux-free' installed from the beginning. I can confirm this problem on exactly the same notebook and with 'intel-microcode' installed as well. > After that report I was able to sometimes halt the computer correctly either > from the gnome interface or from the console. I would like to add that I also didn't succeed in halting the notebook by using the GRUB command 'halt', it just rebooted after entering this command. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778270: libterm-size-perl-perl: please make the build reproducible
Source: libterm-size-perl-perl Version: 0.029-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi, While working on the "reproducible builds" effort [1], we have noticed that libterm-size-perl-perl could not be built reproducibly. The attached patch removes timestamps from the build system. Once applied, libterm-size-perl-perl can be built reproducibly in our current reproducible toolchain. [1]: https://wiki.debian.org/ReproducibleBuilds Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff -urNad libterm-size-perl-perl.orig/libterm-size-perl-perl-0.029/debian/patches/reproducible_build.patch libterm-size-perl-perl/libterm-size-perl-perl-0.029/debian/patches/reproducible_build.patch --- libterm-size-perl-perl.orig/libterm-size-perl-perl-0.029/debian/patches/reproducible_build.patch 1970-01-01 01:00:00.0 +0100 +++ libterm-size-perl-perl/libterm-size-perl-perl-0.029/debian/patches/reproducible_build.patch 2015-02-12 22:54:21.273756396 + @@ -0,0 +1,11 @@ +--- libterm-size-perl-perl-0.029.orig/inc/Probe.pm libterm-size-perl-perl-0.029/inc/Probe.pm +@@ -105,7 +105,7 @@ my $PARAMS_TEMPLATE =
Bug#778269: ITP: python-mkdocs -- Static site generator geared towards building project documentation
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-mkdocs Version : 0.11.1 Upstream Author : Tom Christie * URL : http://www.mkdocs.org/ * License : BSD Programming Lang: Python Description : Static site generator geared towards building project documentation MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file. This package is required to build the documentation in the latest upstream version of python-djangorestframework. I plan to maintain this as part of the python modules team. The intention appears to be that mkdocs is used as a standalone application, although it supplies a mkdocs python package which could in theory be called directly. Given the above paragraph, is it still appropriate to build both a python-mkdocs and a python3-mkdocs package? Unless I hear otherwise, this will be my plan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778268: 'Alias=saned' line causes problematic running of saned@.service
Package: sane-utils Version: 1.0.24-8 Severity: important Dear Maintainer, After upgrading my Pi 2 Debian install from wheezy to jessie, I was running into systemd chewing up as much CPU power as it could get its hands on. Running 'journalctl -f' showed it printing "Looping too fast. Throttling execution a little." approximately every 2 seconds for quite a while after system boot. Although this stopped after some uptime, the high CPU usage remained. Running "systemctl --failed" showed that "saned.service" had failed. This causes other issues, such as a lack of any VTs and an inability to normally reboot (although a shutdown can be forced by killing PID 1, but that's hardly ideal!). A quick trip to the #debian-systemd channel on OFTC seems to have established that this is because of the "Alias=saned" line at the end of the /lib/systemd/system/saned@.service file, which is packaged with sane-utils. Apparently, "when /etc/init.d/sane goes up, systemd hits up saned@.service, which it should not" because "saned@.service should only go up with saned.socket". Two people on the channel recommended dropping the "Alias=saned" line, and one also suggested that a /dev/null symlink should be packaged for /lib/systemd/system/saned.service. In theory, any program attempting to access a scanner will just be poking [::]6566 anyways, which then will prompt systemd to run saned@.service. Although I think I understand that, I won't claim to be sure; what I am sure of is that removing the "Alias=saned" line does indeed solve the problem for me. (Apologies if anything is incomplete or mistaken in this bug report, after many years using Debian and derivatives this is actually my first time directly submitting a bug here. Cheers!) -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 8.0 (jessie) Release: 8.0 Codename: jessie Architecture: armv7l Kernel: Linux 3.18.5-v7+ (SMP w/4 CPU cores; PREEMPT) 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 sane-utils depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.55 ii init-system-helpers1.22 ii libavahi-client3 0.6.31-4 ii libavahi-common3 0.6.31-4 ii libc6 2.19-13 ii libieee1284-3 0.2.11-12 ii libsane1.0.24-8 ii libsystemd0215-11 ii libusb-1.0-0 2:1.0.19-1 ii update-inetd 4.43 sane-utils recommends no packages. Versions of packages sane-utils suggests: pn avahi-daemon pn unpaper -- debconf information: sane-utils/saned_run: false sane-utils/saned_scanner_group: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778267: irsim: please make the build reproducible
Source: irsim
Version: 9.7.87-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi,
While working on the "reproducible builds" effort [1], we have noticed
that irsim could not be built reproducibly.
The attached patch removes timestamps from the build system. Once
applied, irsim can be built reproducibly in our current reproducible
toolchain.
[1]: https://wiki.debian.org/ReproducibleBuilds
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff -urNad irsim.orig/irsim-9.7.87/debian/patches/05-reproducible-build.patch
irsim/irsim-9.7.87/debian/patches/05-reproducible-build.patch
--- irsim.orig/irsim-9.7.87/debian/patches/05-reproducible-build.patch
1970-01-01 01:00:00.0 +0100
+++ irsim/irsim-9.7.87/debian/patches/05-reproducible-build.patch
2015-02-12 22:28:33.474293551 +
@@ -0,0 +1,11 @@
+--- irsim-9.7.87.orig/irsim/Makefile
irsim-9.7.87/irsim/Makefile
+@@ -8,7 +8,7 @@ EXTRA_LIBS = ${IRSIMDIR}/analyzer/libana
+${IRSIMDIR}/base/libbase.o \
+${MAIN_EXTRA_LIBS}
+
+-DFLAGS += -DIRSIM_DATE="\"`date`\""
++DFLAGS += -DIRSIM_DATE="\"`dpkg-parsechangelog -l../debian/changelog
--show-field Date`\""
+
+ CFLAGS += -I${IRSIMDIR}/base
+ LIBS += ${GR_LIBS} -lm
diff -urNad irsim.orig/irsim-9.7.87/debian/patches/series
irsim/irsim-9.7.87/debian/patches/series
--- irsim.orig/irsim-9.7.87/debian/patches/series 2015-02-12
22:22:00.272787116 +
+++ irsim/irsim-9.7.87/debian/patches/series2015-02-12 22:31:18.457645814
+
@@ -2,3 +2,4 @@
02-manpages.patch
03-fhs-images.patch
04-makefile-fix-hardening-ldflags.patch
+05-reproducible-build.patch
Bug#689083: libgphoto2-2-dev is not Multi-Arch compatible
Package: libgphoto2-dev
Version: 2.5.4-1.1+b2
Followup-For: Bug #689083
Dear Maintainer,
Here is a proposed patch to make it possible to make libgphoto2-dev as
Multi-Arch: same.
The trick is that on Debian it's not necessary to use -L to link with libraries
that
are in /usr/lib/. This means it should be ok to remove this option
from the
xxx-config scripts which in turn solves the conflict for libgphoto2-dev.
Is that approach ok?
diff -ur a/debian/control b/debian/control
--- a/debian/control2014-08-25 21:47:22.0 +0200
+++ b/debian/control2015-02-12 23:10:00.414367888 +0100
@@ -30,6 +30,7 @@
Package: libgphoto2-dev
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends:
libgphoto2-6 (= ${binary:Version})
, libexif-dev
diff -ur a/debian/patches/series b/debian/patches/series
--- a/debian/patches/series 2014-01-06 01:37:00.0 +0100
+++ b/debian/patches/series 2015-02-12 23:23:08.251291406 +0100
@@ -1,3 +1,4 @@
#10_disable_cache
#11_hurd_no_path_max_bsdsource
+30_multiarch.patch
kFreeBSD-ENODATA.patch
--- /dev/null 2015-01-27 12:27:17.181130653 +0100
+++ b/debian/patches/30_multiarch.patch 2015-02-12 23:22:24.959450232 +0100
@@ -0,0 +1,40 @@
+--- a/gphoto2-config.in
b/gphoto2-config.in
+@@ -2,7 +2,7 @@
+
+ # leave these definitions here
+ # they are required for correct interpolation of
+-# @libdir@ and @includedir@ later on
++# libdir and includedir later on
+ prefix="@prefix@"
+ exec_prefix="@exec_prefix@"
+
+@@ -59,7 +59,7 @@
+ ;;
+
+ --libs)
+-echo "-L@libdir@" -lgphoto2 -lgphoto2_port -lm
++echo -lgphoto2 -lgphoto2_port -lm
+ ;;
+
+ *)
+--- a/libgphoto2_port/gphoto2-port-config.in
b/libgphoto2_port/gphoto2-port-config.in
+@@ -2,7 +2,7 @@
+
+ # leave these definitions here
+ # they are required for correct interpolation of
+-# @libdir@ and @includedir@ later on
++# libdir and includedir later on
+ prefix="@prefix@"
+ exec_prefix="@exec_prefix@"
+
+@@ -59,7 +59,7 @@
+ ;;
+
+ --libs)
+- echo "-L@libdir@" -lgphoto2_port
++ echo -lgphoto2_port
+ ;;
+
+ *)
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libgphoto2-dev depends on:
ii libexif-dev 0.6.21-2
ii libgphoto2-6 2.5.4-1.1+b2
ii pkg-config0.28-1
libgphoto2-dev recommends no packages.
libgphoto2-dev suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777170: [pkg-wpa-devel] Bug#777170: wpasupplicant: lots of CTRL-EVENT-SIGNAL-CHANGE messages in syslog and couldn't connect to wireless network
On Thu, Feb 05, 2015 at 11:04:30PM +0100, Stefan Lippers-Hollmann wrote: > tags -1 moreinfo > > Hi Hiya! > On 2015-02-05, Julian Gilbey wrote: > > Package: wpasupplicant > > Version: 2.3-1 > > Severity: normal > > > > I was trying to connect to a wireless network from my MacBook Pro > > running testing today, and it connected only intermittently. I'm > > using network-manager, if that makes any difference. It may be the > > network involved, as I can connect to my home network with no > > difficulties. > > What wireless card are you using in your system/ which kernel driver > is in use? Overcrowded and noisy environments can certainly make the > situation worse, especially when you're almost out of reach of your > AP and may even hop between different, equally bad APs. I guess this > part of the issue is more of kernel issue though. I've just found out that there were general problems with the wireless in the building which may be part of the cause of this problem, so I will check next week to see if things have improved (they've replaced the wireless network hardware). In the meantime, for the record, here is the wireless card info from hwinfo: 31: PCI 200.0: 0282 WLAN controller [Created at pci.328] Unique ID: y9sn._jDsMEPhrB9 Parent ID: qTvu.mgUbsEukkq3 SysFS ID: /devices/pci:00/:00:1c.1/:02:00.0 SysFS BusID: :02:00.0 Hardware Class: network Model: "Broadcom BCM4331 802.11a/b/g/n" Vendor: pci 0x14e4 "Broadcom" Device: pci 0x4331 "BCM4331 802.11a/b/g/n" SubVendor: pci 0x106b "Apple Inc." SubDevice: pci 0x00f5 Revision: 0x02 Driver: "bcma-pci-bridge" Driver Modules: "bcma" Device File: wlan0 Features: WLAN Memory Range: 0xa060-0xa0603fff (rw,non-prefetchable) IRQ: 17 (329374 events) HW Address: a8:86:dd:98:d7:12 Link detected: yes WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472 2.484 WLAN encryption modes: WEP40 WEP104 TKIP CCMP WLAN authentication modes: open sharedkey wpa-psk wpa-eap Module Alias: "pci:v14E4d4331sv106Bsd00F5bc02sc80i00" Driver Info #0: Driver Status: bcma is active Driver Activation Cmd: "modprobe bcma" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #23 (PCI bridge) > > The log file was filled with thousands of lines of the form: > > > > Feb 5 16:54:18 redfield wpa_supplicant[2925]: wlan0: > > CTRL-EVENT-SIGNAL-CHANGE above=1 signal=0 noise=0 txrate=48000 > > > > which were appearing at the rate of about 10 per second. > > CTRL-EVENT-SIGNAL-CHANGE is emitted at the MSG_INFO (default) logging > level - you can tune wpa_supplicant's logging level to reduce (and > subsequently hide) these messages. If you start wpa_supplicant by hand, > the parameters are -d, -dd, ... (to increase the logging level) or -q, > -qq, ... (to reduce the logging level. ifupdown's wpa_supplicant > integration allows you to set a debugging level via > "wpa-debug-level %d" (where %d stands for positive or negative numbers, > e.g. -3, ..., 0, ..., 3). I do not know how (or if) networkmanager > exposes access to these settings. > > As long as your kernel driver/ module is working fine, you're usually > not supposed to get bothered by this event - it may be emitted > occassionally, but rarely enough not to be noticed. So clearly something is amiss, but it might be network-related. I'll update next week when I'm able to check again with the new network setup. Many thanks! Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764799: update to the bug
After some analysis the issues turned out to be related to missing ed25519 host key. Once it was created the sshd had no issues with running. My custom sshd_config has only specific HostKeys defined and for some reason not having there ed25519 cause this crash. Running: ssh-keygen -A and adding to /etc/ssh/sshd_config line: HostKey /etc/ssh/ssh_host_ed25519_key solved this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778266: Directory traversal
Source: libarchive Severity: grave Tags: security Hi, please see http://www.openwall.com/lists/oss-security/2015/01/16/7 for details. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778265: CVE-2015-1426
Package: facter Severity: important Tags: security Please see http://puppetlabs.com/security/cve/cve-2015-1426 Fix: https://github.com/puppetlabs/facter/commit/e546bc546e7fb23ad6b68fcf2059452df4d320dd Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#611505: icewm does not unblock signals for reboot and shutdown command
Hallo, * Jörg Sommer [Sat, Jan 29 2011, 11:40:26PM]: > Package: icewm > Version: 1.3.7~pre2-1 > Severity: normal > > Icewm does not unblock the signals, especially SIGCHLD, for the reboot > and shutdown command, what confuses some of these commands. And it seams > icewm also does not unblock the signals for itself on restart. > > % grep \^SigBlk /proc/1862/status > SigBlk: > > After restart (menu, logout, restart) of icewm: > > % grep \^SigBlk /proc/1862/status > SigBlk: 00014007 Please elaborate, I don't see a practical problem as outcome of this behaviour yet. Regards, Eduard. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778264: mailfilter: please make the build reproducible
Source: mailfilter Version: 0.8.3-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi, While working on the "reproducible builds" effort [1], we have noticed that mailfilter could not be built reproducibly. The attached patch removes timestamps from the build system. Once applied, mailfilter can be built reproducibly in our current reproducible toolchain. [1]: https://wiki.debian.org/ReproducibleBuilds Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff -urNad mailfilter.orig/mailfilter-0.8.3/debian/rules mailfilter/mailfilter-0.8.3/debian/rules --- mailfilter.orig/mailfilter-0.8.3/debian/rules 2015-02-12 22:05:39.709241365 + +++ mailfilter/mailfilter-0.8.3/debian/rules2015-02-12 22:19:23.497813728 + @@ -1,11 +1,13 @@ #!/usr/bin/make -f +BUILD_DATE := $(shell dpkg-parsechangelog --show-field Date) + %: dh $@ --with autotools_dev override_dh_auto_install: dh_auto_install - tar -czf ./debian/mailfilter/usr/share/doc/mailfilter/contrib.tar.gz ./contrib + GZIP="-9n" tar -czf ./debian/mailfilter/usr/share/doc/mailfilter/contrib.tar.gz --mtime="$(BUILD_DATE)" ./contrib override_dh_auto_clean: dh_auto_clean
Bug#778261: Buffer overflow in GIF encoder
Package: byzanz Severity: important Tags: security Hi, this was reported by Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=852481 I'm afraid there are no further details, but maybe you can get in touch with upstream; I suppose Red Hat had contacted them and it might already be fixed by now? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778258: myspell.pt: please make the build reproducible
Source: myspell.pt Version: 20091013-7 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi, While working on the "reproducible builds" effort [1], we have noticed that myspell.pt could not be built reproducibly. The attached patch removes timestamps from the build system. Once applied, myspell.pt can be built reproducibly in our current reproducible toolchain. [1]: https://wiki.debian.org/ReproducibleBuilds Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff -urNad myspell.pt.orig/myspell.pt-20091013/debian/rules myspell.pt/myspell.pt-20091013/debian/rules --- myspell.pt.orig/myspell.pt-20091013/debian/rules2015-02-12 22:06:44.220100771 + +++ myspell.pt/myspell.pt-20091013/debian/rules 2015-02-12 22:08:36.101061782 + @@ -28,7 +28,7 @@ build-stamp: configure-stamp #patch-stamp dh_testdir # -- aspell - sed -e '1d' -e '/[\. ]/d' pt_PT.dic | prezip -s -c | gzip -9 -c > debian/aspell-files/pt_PT.cwl.gz + sed -e '1d' -e '/[\. ]/d' pt_PT.dic | prezip -s -c | gzip -9n -c > debian/aspell-files/pt_PT.cwl.gz install -m 0644 pt_PT.aff debian/aspell-files/pt_PT_affix.dat # -- myspell mkdir -p $(OOOTMP)
Bug#778259: myspell-pt-br: please make the build reproducible
Source: myspell-pt-br Version: 20131030-4 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi, While working on the "reproducible builds" effort [1], we have noticed that myspell-pt-br could not be built reproducibly. The attached patch removes timestamps from the build system. Once applied, myspell-pt-br can be built reproducibly in our current reproducible toolchain. [1]: https://wiki.debian.org/ReproducibleBuilds Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff -urNad myspell-pt-br.orig/myspell-pt-br-20131030/debian/rules myspell-pt-br/myspell-pt-br-20131030/debian/rules --- myspell-pt-br.orig/myspell-pt-br-20131030/debian/rules 2015-02-12 22:06:36.219746124 + +++ myspell-pt-br/myspell-pt-br-20131030/debian/rules 2015-02-12 22:08:26.956656225 + @@ -22,7 +22,7 @@ dh_testdir sed -e '1d' -e '/[\. ]/d' pt_BR.dic | fromdos | \ grep -v -f debian/exclude-patterns.grep | \ - prezip -s | gzip -9 -c > debian/aspell-files/pt_BR.cwl.gz + prezip -s | gzip -9n -c > debian/aspell-files/pt_BR.cwl.gz install -m 644 pt_BR.aff debian/aspell-files/pt_BR_affix.dat fromdos debian/aspell-files/pt_BR_affix.dat
Bug#775643: pymvpa: FTBFS in jessie: tests failed
Hi guys, sorry for not chiming in timely and wasting your time trying to reproduce it David. This FTBFS is due to a non-robust unittest which fails at times on some data (which is randomly generated). Since that line of mvpa is out of development for a while (we have python-mvpa2) the best would be just to remove this one from both jessie and sid archives. snapshots.d.n will have it for those who might need it to reproduce previous results. Cheers! On Thu, 12 Feb 2015, David Prévot wrote: > Control: tags -1 + unreproducible > Hi, > On Sun, Jan 18, 2015 at 02:11:38AM +0100, Lucas Nussbaum wrote: > > Source: pymvpa > > Version: 0.4.8-3 > > Severity: seriousd > > Tags: jessie sid > > User: debian...@lists.debian.org > > Usertags: qa-ftbfs-20150118 qa-ftbfs > > Justification: FTBFS in jessie on i386 > I’ve not managed to reproduce this issue today (build it four time in a > row in jessie on i386, as well as in sid and amd64 too). > > The full build log is available from: > > > > http://aws-logs.debian.net/ftbfs-logs/2015/01/18/pymvpa_0.4.8-3_jessie-i386.log > Please find attached my latest build log as well as a diff against the > above failing one, maybe the version changes in the build-dependencies > during the last month are the culprit. > Regards > David -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778257: src:qtdeclarative-opensource-src: FTBFS on x32: JIT, symbols
Package: src:qtdeclarative-opensource-src
Version: 5.3.2-4
Severity: normal
Tags: patch
Hi!
This package fails to build on the x32 second-class architecture. This is
bad as it has a massive amount of reverse [build-]dependencies, both direct
and transitive.
The fix needs two parts:
* applying the attached patch: fixing misdetection of x32 as i386/amd64
(a proper port of the JIT would be of course better, but take a good deal
more work)
* updating the symbols file. s/!sparc64/!sparc64 !x32/ worked for me, as
symbols you skip on every architecture need to be skipped on x32 too
(how surprising...)
Meow!
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (600, 'unstable'), (500, 'unreleased'), (50, 'experimental')
Architecture: x32 (x86_64)
Kernel: Linux 3.19.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- qtdeclarative-opensource-src-5.3.2.orig/src/qml/jsruntime/qv4global_p.h
+++ qtdeclarative-opensource-src-5.3.2/src/qml/jsruntime/qv4global_p.h
@@ -75,9 +75,9 @@ inline double trunc(double d) { return d
// White list architectures
-#if defined(Q_PROCESSOR_X86)
+#if defined(Q_PROCESSOR_X86) && !defined(__ILP32__)
#define V4_ENABLE_JIT
-#elif defined(Q_PROCESSOR_X86_64)
+#elif defined(Q_PROCESSOR_X86_64) && !defined(__ILP32__)
#define V4_ENABLE_JIT
#elif defined(Q_PROCESSOR_ARM_32)
Bug#689097: libgtk2.0-dev is not Multi-Arch compatible
Package: libgtk2.0-dev
Version: 2.24.25-1
Tags: patch
Followup-For: Bug #689097
Dear Maintainer,
I'm attaching a patch to make some gtk+ packages multiarch-compatible and get
closer to
being able to make libgtk2.0-dev itself Multi-Arch: same.
* Mark the gtk2.0-examples package as Multi-Arch: foreign.
* Now that the GObject introspection files can be put in
/usr/lib//girepository-1.0, do so in the gir1.2-gtk-2.0 package and
mark it
as Multi-Arch: same.
What will be left then is:
* In libgtk2.0-devi: /usr/bin/dh_gtkmodules contains some /usr/lib/
paths.
* In libgtk2.0-0-dbg: /usr/lib/debug/usr/bin/gtk-demo contains the debug
information for
this binary of the gtk2.0-examples package.
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libgtk2.0-dev depends on:
ii gir1.2-gtk-2.02.24.25-1
ii libatk1.0-dev 2.14.0-1
ii libcairo2-dev 1.14.0-2.1
ii libgdk-pixbuf2.0-dev 2.31.1-2+b1
ii libglib2.0-dev2.42.1-1
ii libgtk2.0-0 2.24.25-1
ii libgtk2.0-common 2.24.25-1
ii libpango1.0-dev 1.36.8-3
ii libx11-dev2:1.6.2-3
ii libxcomposite-dev 1:0.4.4-1
ii libxcursor-dev1:1.1.14-1+b1
ii libxdamage-dev1:1.1.4-2+b1
ii libxext-dev 2:1.3.3-1
ii libxfixes-dev 1:5.0.1-2+b2
ii libxi-dev 2:1.7.4-1+b2
ii libxinerama-dev 2:1.1.3-1+b1
ii libxml2-utils 2.9.1+dfsg1-4
ii libxrandr-dev 2:1.4.2-1+b1
ii pkg-config0.28-1
Versions of packages libgtk2.0-dev recommends:
ii debhelper 9.20141022
ii python 2.7.8-3
Versions of packages libgtk2.0-dev suggests:
pn libgtk2.0-doc
-- no debconf information
diff -ur gtk+-2.24.25.orig/debian/control.in gtk+-2.24.25/debian/control.in
--- gtk+-2.24.25.orig/debian/control.in 2015-02-12 16:05:57.0 +0100
+++ gtk+-2.24.25/debian/control.in 2015-02-12 19:30:24.018571814 +0100
@@ -49,6 +49,8 @@
Package: @SHARED_PKG@
Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
Depends: @COMMON_PKG@,
${misc:Depends},
${shlibs:Depends},
@@ -58,8 +60,6 @@
@BIN_PKG@
Suggests: librsvg2-common,
gvfs
-Multi-Arch: same
-Pre-Depends: ${misc:Pre-Depends}
Description: GTK+ graphical user interface library
GTK+ is a multi-platform toolkit for creating graphical user
interfaces. Offering a complete set of widgets, GTK+ is suitable
@@ -90,11 +90,11 @@
Package: @COMMON_PKG@
Section: misc
Architecture: all
+Multi-Arch: foreign
Depends: ${misc:Depends}
Recommends: @SHARED_PKG@
Replaces: @SHARED_PKG@ (<< 2.24.8-2)
Breaks: @SHARED_PKG@ (<< 2.24.8-2)
-Multi-Arch: foreign
Description: common files for the GTK+ graphical user interface library
GTK+ is a multi-platform toolkit for creating graphical user
interfaces. Offering a complete set of widgets, GTK+ is suitable
@@ -106,10 +106,10 @@
Package: @BIN_PKG@
Section: misc
Architecture: any
+Multi-Arch: foreign
Depends: ${misc:Depends},
@SHARED_PKG@ (= ${binary:Version}),
@COMMON_PKG@
-Multi-Arch: foreign
Description: programs for the GTK+ graphical user interface library
GTK+ is a multi-platform toolkit for creating graphical user
interfaces. Offering a complete set of widgets, GTK+ is suitable
@@ -176,12 +176,12 @@
Package: @DOC_PKG@
Section: doc
Architecture: all
+Multi-Arch: foreign
Depends: ${misc:Depends}
Recommends: libglib2.0-doc,
libatk1.0-doc,
libpango1.0-doc
Suggests: devhelp
-Multi-Arch: foreign
Description: documentation for the GTK+ graphical user interface library
GTK+ is a multi-platform toolkit for creating graphical user
interfaces. Offering a complete set of widgets, GTK+ is suitable
@@ -195,6 +195,7 @@
Section: x11
Priority: extra
Architecture: any
+Multi-Arch: foreign
Depends: ${shlibs:Depends},
${misc:Depends},
@SHARED_PKG@ (= ${binary:Version})
@@ -226,6 +227,7 @@
Package: gir1.2-gtk-2.0
Section: introspection
Architecture: any
+Multi-Arch: same
Depends: @COMMON_PKG@,
${misc:Depends},
${shlibs:Depends},
@@ -244,11 +246,11 @@
Package: libgail18
Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends},
${shlibs:Depends},
@SHARED_PKG@ (= ${binary:Version})
-Multi-Arch: same
-Pre-Depends: ${misc:Pre-Depends}
Description: GNOME Accessibility Implementation Library -- shared libraries
Gail implements ATK interfaces for GTK+ widgets which are dynamically
loadable at runtime by a GTK+ application. Once loaded, those parts of
@@ -259,11 +261,11 @@
Package: libgail-common
Architecture: any
+Mult
Bug#776995: snd-usb-audio: micrphone "Unlikely big volume range"
Please close this bug, I found a workaround. It is just because the webcam's microphone was not set to default in pulseaudio configuration. Executing: pactl "set-default-source alsa_input.usb-046d_09a4_F89C6650-02-U0x46d0x9a4.analog-mono" resolves the issue. Can be made persistent in /etc/pulse/default.pa. (Command not documented in 'man pactl') The message "Unlikely big volume range" in syslog is just cosmetic. Ingo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777694: icu maintenance
László, I would be in strong support of your taking over icu. Feel free to do it in conjunction with uploading security fixes that are pending. Right now, last time I looked, there were not yet public patches for all the issues, but I may be wrong. A general tip for ICU security patches: Red Hat has to do them too. I have generally tried to make sure that the version of ICU in a debian release corresponds with a version present in at least one Red Hat release, but I hadn't planned for the 52 to be in jessie; I just didn't have a way to get it updated. But you can often grab security patches from other distributions. Also, upstream has generally been pretty helpful with backporting patches when necessary. Mostly I have found the patches backport pretty easily. Regardless, we will also get stuck in a situation where upstream doesn't support some version we have in a security supported version, which is one of the main challenges of maintaining icu. -- Jay Berkenbilt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778212: closed by Ben Hutchings
On Thu, Feb 12, 2015 at 05:21:14PM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the src:linux package: > > #778212: linux: please build the kernel and udebs on x32 > > It has been closed by Ben Hutchings . > No, you need to make the installer use the amd64 packages for this. 1. d-i cannot currently use packages from a foreign architecture (same applies for example to i386 on non-ancient hardware) 2. neither can it use udebs (needed to boot d-i itself) 3. amd64 kernels currently have x32 syscalls disabled unless a special argument is passed on the command line. This is fragile, especially if fancy combinations of bootloader with preseeding are involved. I'm not going to force reopen this, as you know more about Debian kernel packaging than me (duh), but at least in my unofficial x32 release I'm going to use kernel+udebs with this patch, unless you can enlighten me. Would you please elaborate a bit about what do I understand wrong? And what the plans for foreign kernels in d-i are? -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777583: Incorrect debian/copyright for smartmontools
retitle -1 debian/copyright for smartmontools is too restrictive severity -1 wishlist On Tue, Feb 10, 2015 at 01:30:33AM -0500, Mark H Weaver wrote: > Package: smartmontools > debian/copyright claims that smartmontools is distributed under GPLv2, > but the copyright notices in its source files include the "or (at your > option) any later version" language. In that case, the Debian package “just” claims a more restrictive term of use than it actually is, but it is not wrong either (GPL-2 is included in GPL-2+, it’s as if the maintainer decided on the option). Regards David signature.asc Description: Digital signature
Bug#775527: live-images: upgrade splash to Jessie theme
On 12/02/2015 04:27, Daniel Baumann wrote: > On 02/11/15 20:19, jnqnfe wrote: >> Why are we now using the simple black syslinux theme instead of the >> official install disc theme? > it's the one Juliette provided in her tarball. Right, but Juliette is only going by the stated requirements at [1] to determine what images to create and supply in her archive. These requirements simply list, under the boot screen heading: - GRUB 2: 640x480, 24bit, file PNG. - Isolinux: 640x300px, 4bit color depth (means: 16 colors). View Make Sys Image. - Syslinux: 640x300px, 16bit color depth (means: 65,536 colors), in PNG format. - Plymouth: a SVG file (or at the very least a collection of PNGs for the different elements of scene and background). There is no implication anywhere that Juliette means for any of the images she has produced for the above to be used for install/live boot menus, nor by the Debian artwork proposal outlines that any of these would be used for that, and no-one so far has properly communicated to her than an image for such use is needed. If we look at the Wheezy 'joy' theme archive [2] this also only contains boot images per the above requirements. It does not contain a copy of the image actually used by the debian d-i/cd teams as a boot menu splash for the official install media. I would assume that they took the base theme assets and produced that image themselves. Furthermore at [3] and [4] you'll see that again with Jessie they are doing the very same thing. I am supportive of a notion that this image should actually be being produced by the theme artist as part of the artwork proposal, thus allowing correct and proper copyright attribution (perhaps we can have the requirements amended to list it). I am against use of the syslinux image currently selected for live-images though, I think it's completely the wrong one to be using. If the issue with the image I supplied myself was down to copyright attribution, I am perfectly happy to give up any claim of ownership/copyright I may have on it to Juliette, and for Juliette to adopt it as her own, or equally happy for her to produce her own copy. I had no intention of wanting any credit/claim over this, after all, all I did was take her individual asset components and place them on top of each other in a particular layout, then add the text 'GNU/Linux', hardly something I can or would want to claim as mine. :) I'm writing a separate email to Juliette at the same time as this to explain things. [1] https://wiki.debian.org/DebianDesktop/Artwork/Requirements [2] https://wiki.debian.org/DebianArt/Themes/Joy [3] http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/boot/x86/pics/ [4] http://ftp.debian.org/debian/dists/sid/main/installer-amd64/current/images/cdrom/debian-cd_info.tar.gz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778256: clang: fail to use the wrong gnu libstdc++ include directory this directory is one digit only (here 5)
Package: clang Version: 1:3.5-26 Severity: normal Dear Maintainer, I tried to compile a c++ with clang (3.5, 3.7) which worked before I installed libstdc++ libstdc++-5-dev:amd64 5-20150205-1 libstdc++6:amd645-20150205-1 from experimental (thus the normal severity as the tool the package ship is broken, higher would be expected when 5 enters unstable). The verbose output of clang++ (3.5 here) follows. What helper me was: ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/x86_64-linux-gnu/c++/5.0.0" that is there is an /usr/include/x86_64-linux-gnu/c++/5 but no /usr/include/x86_64-linux-gnu/c++/5.0.0 which is fine and was same scheme with 4.X serie. But the initial guess is wrong: Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.0.0 as with 4.9 , 4.9 is sorted before 4.9.2 thus include/c++/4.9 is used instead of non existent include/c++/4.9.2 ... but 5.0.0 is sorted before 5 , or 5 is bypassed altogether ! My guess is this is the root of bug. Debian clang version 3.5.0-9 (tags/RELEASE_350/final) (based on LLVM 3.5.0) Target: x86_64-pc-linux-gnu Thread model: posix Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.9 Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/4.9.2 Found candidate GCC installation: /usr/bin/../lib/gcc/i586-linux-gnu/5.0.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7.4 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.4 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0 Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/i586-linux-gnu/5.0.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.0.0 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 "/usr/lib/llvm-3.5/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.24.90 -v -dwarf-column-info -coverage-file /home/prahal/SandBoxes/uva.onlinejudge.org/429_wordtransformation-build2/CMakeFiles/429_wordtransformation.dir/main.cpp.o -resource-dir /usr/lib/llvm-3.5/bin/../lib/clang/3.5.0 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/c++/5.0.0 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/x86_64-linux-gnu/c++/5.0.0 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/x86_64-linux-gnu/c++/5.0.0 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/c++/5.0.0/backward -internal-isystem /usr/include/clang/3.5.0/include/ - internal-isystem /usr/local/include -internal-isystem /usr/lib/llvm-3.5/bin/../lib/clang/3.5.0/include -internal-externc-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/prahal/SandBoxes/uva.onlinejudge.org/429_wordtransformation-build2 -ferror-limit 19 -fmessage-length 212 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o CMakeFiles/429_wordtransformation.dir/main.cpp.o -x c++ /home/prahal/SandBoxes/uva.onlinejudge.org/429_wordtransformation/main.cpp clang -cc1 version 3.5.0 based upon LLVM 3.5.0 default target x86_64-pc-linux-gnu ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/x86_64-linux-gnu/c++/5.0.0" ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/5.0.0/../../../../include/x86_64-linux-gnu/c++/5.0.0" ignoring nonexistent directory "/include" ignoring duplicate directory "/usr/include/cla
Bug#778070: [Pkg-postgresql-public] Bug#778070: postgresql-9.1: ftbfs with GCC-5
Control: tag -1 +confirmed -stretch Re: Matthias Klose 2015-02-12 > Package: src:postgresql-9.1 > Version: 9.1.15-0+deb8u1 > Severity: normal > Tags: sid stretch > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-5 > The package fails to build in a test rebuild on at least amd64 with > gcc-5/g++-5, but succeeds to build with gcc-4.9/g++-4.9. The > severity of this report may be raised before the stretch release. Hi, thanks for the report, confirmed here. Looks like initdb is filling up the disk until it panics because there's no space left. It affects PostgreSQL 9.5devel as well. Fwiw, postgresql-9.1 won't be part of stretch, it is a perl- compatibility package for upgrades from wheezy to jessie and will be removed as soon as jessie is released. Christoph -- c...@df7cb.de | http://www.df7cb.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755437: leocad suggests ldraw-parts since 0.80.3-1
Nicolas, the leocad package suggests ldraw-parts since 0.80.3-1 which should fix the issue about the minimal parts set (apt-get install leocad --install-suggests). Concerning the parts not being visible, I cannot reproduce that error. Is it still a problem? Best regards Nicolas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777866: gcl: ftbfs with GCC-5
Is there a way to install gcc-5 into an experimental schroot on a porterbox? Take care, Matthias Klose writes: > Package: src:gcl > Version: 2.6.12-1 > Severity: normal > Tags: sid stretch > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-5 > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-5/g++-5, but succeeds to build with gcc-4.9/g++-4.9. The > severity of this report may be raised before the stretch release. > > The full build log can be found at: > http://people.debian.org/~doko/logs/gcc5-20150205/gcl_2.6.12-1_unstable_gcc5.log > The last lines of the build log are at the end of this report. > > To build with GCC 5, either set CC=gcc-5 CXX=g++-5 explicitly, > or install the gcc, g++, gfortran, ... packages from experimental. > > apt-get -t experimental install g++ > > Common build failures are C11 as the default C mode, new warnings > resulting in build failures with -Werror turned on, or new/dropped > symbols in Debian symbols files. For other C/C++ related build failures > see the porting guide at http://gcc.gnu.org/gcc-5/porting_to.html > > [...] > num_sfun.c:(.text+0x9ffd): undefined reference to `number_fix_iexpt' > num_sfun.c:(.text+0xa0c1): undefined reference to `number_ui_expt' > num_sfun.c:(.text+0xa0d1): undefined reference to `number_ui_expt' > num_sfun.c:(.text+0xa1ae): undefined reference to `number_fix_iexpt' > num_sfun.c:(.text+0xa237): undefined reference to `number_ui_expt' > num_sfun.c:(.text+0xa247): undefined reference to `number_ui_expt' > num_sfun.c:(.text+0xab17): undefined reference to `number_zero_expt' > num_sfun.c:(.text+0xab8e): undefined reference to `number_zero_expt' > num_sfun.c:(.text+0xad19): undefined reference to `number_zero_expt' > num_sfun.c:(.text+0xb399): undefined reference to `number_zero_expt' > num_sfun.c:(.text+0xb461): undefined reference to `number_zero_expt' > ./libpre_gcl.a(num_sfun.o):num_sfun.c:(.text+0xb52a): more undefined > references to `number_zero_expt' follow > ./libpre_gcl.a(gbc.o): In function `sgc_start': > gbc.c:(.text+0x7583): undefined reference to `add_page_to_freelist' > gbc.c:(.text+0x7650): undefined reference to `set_tm_maxpage' > gbc.c:(.text+0x780e): undefined reference to `add_pages' > gbc.c:(.text+0x8393): undefined reference to `set_tm_maxpage' > ./libpre_gcl.a(gbc.o): In function `GBC': > gbc.c:(.text+0x9ad5): undefined reference to `opt_maxpage' > ./libpre_gcl.a(alloc.o): In function `alloc_object': > alloc.c:(.text+0x8074): undefined reference to `alloc_after_turning_off_sgc' > alloc.c:(.text+0x8f7c): undefined reference to `maybe_reallocate_page' > alloc.c:(.text+0x94d0): undefined reference to `maybe_reallocate_page' > alloc.c:(.text+0x99f9): undefined reference to `maybe_reallocate_page' > ./libpre_gcl.a(alloc.o): In function `alloc_contblock': > alloc.c:(.text+0xb93e): undefined reference to `alloc_after_turning_off_sgc' > alloc.c:(.text+0xc162): undefined reference to `maybe_reallocate_page' > alloc.c:(.text+0xcbcf): undefined reference to `maybe_reallocate_page' > alloc.c:(.text+0xd79c): undefined reference to `maybe_reallocate_page' > ./libpre_gcl.a(alloc.o): In function `alloc_relblock': > alloc.c:(.text+0xefce): undefined reference to `alloc_after_turning_off_sgc' > alloc.c:(.text+0xf7f2): undefined reference to `maybe_reallocate_page' > alloc.c:(.text+0x1025f): undefined reference to `maybe_reallocate_page' > alloc.c:(.text+0x10e2c): undefined reference to `maybe_reallocate_page' > ./libpre_gcl.a(alloc.o): In function `make_cons': > alloc.c:(.text+0x124c4): undefined reference to `alloc_after_turning_off_sgc' > alloc.c:(.text+0x12c3d): undefined reference to `maybe_reallocate_page' > alloc.c:(.text+0x14089): undefined reference to `maybe_reallocate_page' > alloc.c:(.text+0x145b3): undefined reference to `maybe_reallocate_page' > collect2: error: ld returned 1 exit status > make[2]: *** [raw_pre_gcl_map] Error 1 > makefile:171: recipe for target 'raw_pre_gcl_map' failed > make[2]: Leaving directory '/«PKGBUILDDIR»/unixport' > make[1]: *** [unixport/saved_pre_gcl] Error 2 > makefile:71: recipe for target 'unixport/saved_pre_gcl' failed > rm h/mcompdefs.h > make[1]: Leaving directory '/«PKGBUILDDIR»' > make: *** [build-gprof-stamp] Error 2 > debian/rules:109: recipe for target 'build-gprof-stamp' failed > dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 > > > > -- Camm Maguirec...@maguirefamily.org == "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@l
Bug#778253: Library version
I noticed only now that the library version reported is the 3.1.2-11ghigo. This is a my mistake. 3.1.2-11ghigo is the library which I rebuild with the patch. The problem is related to the 3.1.2-10. BR G.Baroncelli -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778255: clang-3.6: Error message in man pages
Package: clang-3.6 Version: 1:3.6~+rc2-2 Severity: normal The man page for clang-tblgen-3.6 starts with an error message: NAME clang-tblgen - manual page for clang-tblgen 3.6 DESCRIPTION ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.USAGE: clang-tblgen [options] Several other manpages from this package have the same problem. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages clang-3.6 depends on: ii binutils 2.25-4 ii libc62.19-14 ii libc6-dev2.19-14 ii libclang-common-3.6-dev 1:3.6~+rc2-2 ii libclang1-3.61:3.6~+rc2-2 ii libedit2 3.1-20140620-2 ii libffi6 3.1-2+b2 ii libgcc-4.9-dev 4.9.2-10 ii libgcc1 1:4.9.2-10 ii libllvm3.6 1:3.6~+rc2-2 ii libobjc-4.9-dev 4.9.2-10 ii libstdc++-4.9-dev4.9.2-10 ii libstdc++6 4.9.2-10 ii libtinfo55.9+20140913-1+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages clang-3.6 recommends: pn llvm-3.6-dev ii python2.7.8-3 Versions of packages clang-3.6 suggests: pn clang-3.6-doc pn gnustep pn gnustep-devel -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778254: release.debian.org: jessie's new kernel breaks openafs-modules-dkms
Package: release.debian.org Severity: normal Bug #778196 was filed against openafs-modules-dkms to note that the latest kernel to hit jessie (which was the unblock request in #776899) causes the DKMS module to fail to build. The new kernel introduced a KPI change for accesses to the d_alias field of struct dentry, which must now be made through the d_u union. I updated openafs in sid to include upstream's patches for new linux support (including the d_u change) when the new kernel hit sid, but that update also included a new translation and several bugfixes of various severity. Additionally, openafs in sid has a newer upstream version than openafs in jessie, due to excessive optimism on my part in the lead up to freeze. (It is also the case that nearly every upstream update for openafs includes support for new linux versions, since the KPI is a moving target, so I am used to having to pull in new upstream versions regularly.) The version in jessie also does not have native systemd support, and it remains unclear whether the systemd sysv compat is causing problems for jessie users that native unit files could resolve (#760063) -- for at least some users, the issue seems to have mysteriously gone away but there is no openafs or systemd change which obviously should have resolved things. The question is, how should we resolve the situation for jessie? It seems like the most likely answer is a minimal patch uploaded to testing-proposed-updates, but I wanted to ask the release team whether there were other options, such as unblocking the openafs currently in sid (even though it is a new upstream version). It is probably worth noting that openafs is a leaf package. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778253: libarchive13: archive_read_disk_entry_from_file() and archive_write_disk_set_acls() don't preserv ACL.
Package: libarchive13
Version: 3.1.2-11ghigo
Severity: normal
Tags: patch
libarchive in linux doesn't support properly the ACL. This is a bug alredy
solved in upstream [1][2].
The problem is that the code which handles ACLs depend by the definition
of the macro ACL_TYPE_NFS4. However in linux this macro is not defined.
During the packaging build, dpkg-shlibdeps warns abou the fact the the "acl"
library is unused:
---
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libarchive13/usr/lib/x86_64-linux-gnu/libarchive.so.13.1.2 was not
linked against libacl.so.1 (it uses none of the library's symbols)
---
In upstream the problem is solved by the patch [2]. Fedora
solved this issue cherry-picking the same patch [4].
I made a new version the libarchive package: I put the commit [2] in
debian/patches/, I update debian/patches/series adding the new patch,
and finally I updated the debian/changelog file. The package compiled and
now my tests showed ACL seems supported.
BR
G.Baroncelli
[1] https://code.google.com/p/libarchive/issues/detail?id=329
[2] See commit b45c3ae1825c8cedc7cde2972a04974f73b08315
[3] https://bugzilla.redhat.com/show_bug.cgi?id=993048
[4]
http://pkgs.fedoraproject.org/cgit/libarchive.git/commit/?id=da58d4e8afce6acca54475be528f6b948aa2951a
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 3.18.5 (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 libarchive13 depends on:
ii libacl12.2.52-2
ii libattr1 1:2.4.47-2
ii libbz2-1.0 1.0.6-7+b2
ii libc6 2.19-15
ii liblzma5 5.1.1alpha+20120614-2+b3
ii liblzo2-2 2.08-1.2
ii libnettle4 2.7.1-5
ii libxml22.9.2+dfsg1-3
ii multiarch-support 2.19-15
ii zlib1g 1:1.2.8.dfsg-2+b1
libarchive13 recommends no packages.
Versions of packages libarchive13 suggests:
pn lrzip
-- no debconf information
commit b45c3ae1825c8cedc7cde2972a04974f73b08315
Author: Tim Kientzle
Date: Sat Jan 4 21:46:57 2014 -0800
Issue #329: https://code.google.com/p/libarchive/issues/detail?id=329
Fix POSIX.1e draft ACL handling on Linux systems that lack NFSv4 ACL libraries.
diff --git a/libarchive/archive_read_disk_entry_from_file.c b/libarchive/archive_read_disk_entry_from_file.c
index e984aaa..e81cbec 100644
--- a/libarchive/archive_read_disk_entry_from_file.c
+++ b/libarchive/archive_read_disk_entry_from_file.c
@@ -399,7 +399,7 @@ setup_mac_metadata(struct archive_read_disk *a,
#endif
-#if defined(HAVE_POSIX_ACL) && defined(ACL_TYPE_NFS4)
+#ifdef HAVE_POSIX_ACL
static int translate_acl(struct archive_read_disk *a,
struct archive_entry *entry, acl_t acl, int archive_entry_acl_type);
@@ -419,6 +419,7 @@ setup_acls(struct archive_read_disk *a,
archive_entry_acl_clear(entry);
+#ifdef ACL_TYPE_NFS4
/* Try NFS4 ACL first. */
if (*fd >= 0)
acl = acl_get_fd(*fd);
@@ -447,6 +448,7 @@ setup_acls(struct archive_read_disk *a,
acl_free(acl);
return (ARCHIVE_OK);
}
+#endif
/* Retrieve access ACL from file. */
if (*fd >= 0)
@@ -492,6 +494,7 @@ static struct {
{ARCHIVE_ENTRY_ACL_EXECUTE, ACL_EXECUTE},
{ARCHIVE_ENTRY_ACL_WRITE, ACL_WRITE},
{ARCHIVE_ENTRY_ACL_READ, ACL_READ},
+#ifdef ACL_TYPE_NFS4
{ARCHIVE_ENTRY_ACL_READ_DATA, ACL_READ_DATA},
{ARCHIVE_ENTRY_ACL_LIST_DIRECTORY, ACL_LIST_DIRECTORY},
{ARCHIVE_ENTRY_ACL_WRITE_DATA, ACL_WRITE_DATA},
@@ -508,8 +511,10 @@ static struct {
{ARCHIVE_ENTRY_ACL_WRITE_ACL, ACL_WRITE_ACL},
{ARCHIVE_ENTRY_ACL_WRITE_OWNER, ACL_WRITE_OWNER},
{ARCHIVE_ENTRY_ACL_SYNCHRONIZE, ACL_SYNCHRONIZE}
+#endif
};
+#ifdef ACL_TYPE_NFS4
static struct {
int archive_inherit;
int platform_inherit;
@@ -519,21 +524,25 @@ static struct {
{ARCHIVE_ENTRY_ACL_ENTRY_NO_PROPAGATE_INHERIT, ACL_ENTRY_NO_PROPAGATE_INHERIT},
{ARCHIVE_ENTRY_ACL_ENTRY_INHERIT_ONLY, ACL_ENTRY_INHERIT_ONLY}
};
-
+#endif
static int
translate_acl(struct archive_read_disk *a,
struct archive_entry *entry, acl_t acl, int default_entry_acl_type)
{
acl_tag_t acl_tag;
+#ifdef ACL_TYPE_NFS4
acl_entry_type_t acl_type;
acl_flagset_t acl_flagset;
+ int brand, r;
+#endif
acl_entry_t acl_entry;
acl_permset_t acl_permset;
- int brand, i, r, entry_acl_type;
+ int i, entry_acl_type;
int s, ae_id, ae_tag, ae_perm;
const char *ae_name;
+#ifdef ACL_TYPE_NFS4
// FreeBSD "brands" ACLs as POSIX.1e or NFSv4
// Make sure the "brand" on this ACL is consistent
// with the default_entry_acl_type bits provided.
@@ -560,6 +569,7 @@ translate_acl(struct archive_read_disk *a,
return ARCHIVE_FAILED;
break;
}
+#endif
s = acl_get_entry(acl, ACL_FIRST_E
Bug#777743: ITP: wallpaperd -- X wallpaper changing daemon
* Gunnar Wolf [2015-02-12 12:23:29-0600] > Dmitry Bogatov dijo [Thu, Feb 12, 2015 at 10:43:17AM +0300]: > > - why is this package useful/relevant? > > > > It follows unix way and manages wallpapers without connection to > > your DE, WM or anything. > > (...) > > if there are other packages providing similar functionality, how does it > > compare? > > > > Such functionality exists in GNOME and KDE, at least. But I know nothing > > similar > > for bare WM. > > I guess I do this the ugliest possible way, but my .xsession has: > > BGDIR=/home/gwolf/.backgrounds > while /bin/true > do > feh --bg-max $BGDIR/$(xscreensaver-getimage-file $BGDIR) > sleep 60 > done & Yes, it is more. Like per-workspace wallpapers and random change every X seconds. -- Best regards, Dmitry Bogatov , Free Software supporter, esperantisto and netiquette guardian. GPG: 54B7F00D pgpgfjS0XnwdJ.pgp Description: PGP signature
Bug#778252: RFS: pyoperators/0.13.5-1 -- Operators and solvers for high-performance computing.
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pyoperators": * Package name: pyoperators Version : 0.13.5-1 Upstream Author : Pierre Chanial * URL :http://pchanial.github.io/pyoperators/ * License : CeCILL-B Programming Lang: Python Description : Operators and solvers for high-performance computing. It builds the following binary packages: python-pyoperators -- Python 2 version of the module python3-pyoperators -- Python 3 version of the module Changes since last upload: * New upstream release * d/copyright: cme fixed * d/control: cme fixed This package is currently maintained by the Debian Science Team and will be sponsored via the Sponsorship of Blends initiative [1]. The source package can be checked out at [2]. Cheers, Ghislain [1] https://wiki.debian.org/DebianPureBlends/SoB [2] https://anonscm.debian.org/cgit/debian-science/packages/pyoperators.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777080: crashed when trying to load plugins
Package: gwenview Version: 4:4.8.4-2 Severity: normal Dear Maintainer, I tried various different permutations of packages installed. Gwenview still crashes as before, but only on the one computer, which is a "Time" computer. Gwenview works on an old "Packard Bell" "EasyNote". I have obtained a backtrace from my "Time" computer. I attach a copy. The following system information applies to the latest run. with best regards from Richard Betham -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i586) Kernel: Linux 3.2.0-4-486 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gwenview depends on: ii kde-runtime4:4.8.4-2 ii libc6 2.13-38+deb7u7 ii libexiv2-120.23-1 ii libgcc11:4.7.2-5 ii libjpeg8 8d-1+deb7u1 ii libkdecore54:4.8.4-4+deb7u1 ii libkdeui5 4:4.8.4-4+deb7u1 ii libkfile4 4:4.8.4-4+deb7u1 ii libkio54:4.8.4-4+deb7u1 ii libkipi8 4:4.8.4-1 ii libkonq5abi1 4:4.8.4-2 ii libkparts4 4:4.8.4-4+deb7u1 ii libnepomuk44:4.8.4-4+deb7u1 ii libphonon4 4:4.6.0.0-3 ii libqt4-opengl 4:4.8.2+dfsg-11 ii libqt4-svg 4:4.8.2+dfsg-11 ii libqtcore4 4:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libstdc++6 4.7.2-5 ii phonon 4:4.6.0.0-3 Versions of packages gwenview recommends: ii kamera 4:4.8.4-2 Versions of packages gwenview suggests: pn svgpart -- no debconf information Versions of packages kipi-plugins depends on: ii digikam 4:2.6.0-1+deb7u1 ii kde-runtime 4:4.8.4-2 ii kipi-plugins-common 4:2.6.0-1+deb7u1 ii libc6 2.13-38+deb7u7 ii libexpat1 2.1.0-1+deb7u1 ii libgcc1 1:4.7.2-5 ii libgl1-mesa-glx [libgl1] 8.0.5-4+deb7u2 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgomp1 4.7.2-5 ii libgpod4-nogtk0.8.2-7 ii libjpeg8 8d-1+deb7u1 ii libkcalcore4 4:4.8.4-2 ii libkdcraw20 4:4.8.4-1 ii libkdecore5 4:4.8.4-4+deb7u1 ii libkdeui5 4:4.8.4-4+deb7u1 ii libkexiv2-10 4:4.8.4-1 ii libkio5 4:4.8.4-4+deb7u1 ii libkipi8 4:4.8.4-1 ii libksane0 4:4.8.4-1 ii libopencv-core2.3 2.3.1-11 ii libopencv-highgui2.3 2.3.1-11 ii libopencv-imgproc2.3 2.3.1-11 ii libopencv-legacy2.3 2.3.1-11 ii libopencv-objdetect2.32.3.1-11 ii libphonon44:4.6.0.0-3 ii libpng12-01.2.49-1 ii libqca2 2.0.3-4 ii libqjson0 0.7.1-7 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-network4:4.8.2+dfsg-11 ii libqt4-opengl 4:4.8.2+dfsg-11 ii libqt4-svg4:4.8.2+dfsg-11 ii libqt4-xml4:4.8.2+dfsg-11 ii libqt4-xmlpatterns4:4.8.2+dfsg-11 ii libqtcore44:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libsolid4 4:4.8.4-4+deb7u1 ii libstdc++64.7.2-5 ii libthreadweaver4 4:4.8.4-4+deb7u1 ii libtiff4 3.9.6-11 ii libxml2 2.8.0+dfsg1-7+wheezy3 ii libxrandr22:1.3.2-2+deb7u1 ii libxslt1.11.1.26-14.1 ii phonon4:4.6.0.0-3 Versions of packages kipi-plugins recommends: ii enblend 4.0+dfsg-4+b3 ii enfuse 4.0+dfsg-4+b3 ii hugin2011.4.0+dfsg-5 ii imagemagick 8:6.7.7.10-5+deb7u3 ii konqueror4:4.8.4-2 Versions of packages kipi-plugins suggests: pn gallery pn gimp ii kmail 4:4.4.11.1+l10n-3+b1 pn vorbis-tools -- no debconf information On Thursday 05 February 2015 12:39:22 Debian Bug Tracking System wrote: > Thank you for the additional information you have supplied > regarding this Bug report. Application: Gwenview (gwenview), signal: Illegal instruction Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0xb4463720 (LWP 6341))] Thread 3 (Thread 0xb1f14b70 (LWP 6343)): #0 0xb5108edf in pthread_mutex_lock () from /lib/i386-linux-gnu/libpthread.so.0 #1 0xb5b7ec76 in pthread_mutex_lock () from /lib/i386-linux-gnu/libc.so.6 #2 0xb507f940 in g_mutex_lock () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0xb503f8c5 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0xb503fb51 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0xb71ab84f in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #6 0xb717801c in QEventLoop::processEvents(QFlags) () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #7 0xb7178311 in QEventLoop::exec(QFlags) () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #8 0xb7064b3c in
Bug#778251: linux-image-3.16.0-4-amd64: x86_energy_perf_policy of cpu0 switches to performance after suspend to ram
Package: src:linux Version: 3.16.7-ckt4-3 Severity: normal Hi, I was playing with the x86_energy_perf_policy tool to change the energy performance policy of the CPU. When the system boots, it indicates it has switched the CPU to the 'normal' perf_policy (from 'performance'). [0.011281] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) When checked with the x86_energy_perf_policy tools, this looks OK: rik@earth:~/bin$ sudo ./x86_energy_perf_policy -v -r CPUID.06H.ECX: 0x9 cpu0: 0x0006 cpu1: 0x0006 cpu2: 0x0006 cpu3: 0x0006 6 seems to indicate 'normal' on my CPU. To check the values, I configured the CPU to enter 'normal': rik@earth:~/bin$ sudo ./x86_energy_perf_policy -v normal CPUID.06H.ECX: 0x9 cpu0 msr0x1b0 0x0006 -> 0x0006 cpu1 msr0x1b0 0x0006 -> 0x0006 cpu2 msr0x1b0 0x0006 -> 0x0006 cpu3 msr0x1b0 0x0006 -> 0x0006 For 'performance', the tool sets the msr to 0 at the end: rik@earth:~/bin$ sudo ./x86_energy_perf_policy -v performance CPUID.06H.ECX: 0x9 cpu0 msr0x1b0 0x0006 -> 0x cpu1 msr0x1b0 0x0006 -> 0x cpu2 msr0x1b0 0x0006 -> 0x cpu3 msr0x1b0 0x0006 -> 0x Now, when the system boots, all cpu's are correctly set to 'normal'. But when I suspend to RAM and wake the system again, cpu0's perf_policy is set to performance again. The other cpu's remain at the normal policy: rik@earth:~/bin$ sudo ./x86_energy_perf_policy -v -r CPUID.06H.ECX: 0x9 cpu0: 0x cpu1: 0x0006 cpu2: 0x0006 cpu3: 0x0006 It seems the perf_policy is not restored on resume for cpu0. My system has the following cpu: rik@earth:~/bin$ lscpu Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):4 On-line CPU(s) list: 0-3 Thread(s) per core:2 Core(s) per socket:2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family:6 Model: 58 Model name:Intel(R) Core(TM) i5-3360M CPU @ 2.80GHz Stepping: 9 CPU MHz: 3433.390 CPU max MHz: 3500. CPU min MHz: 1200. BogoMIPS: 5581.57 Virtualization:VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 3072K NUMA node0 CPU(s): 0-3 Regards, Rik -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) ** Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/vg_earth-root ro elevator=deadline quiet systemd.show_status=1 splash ** Not tainted ** Kernel log: [ 401.220242] pci :00:1f.3: using default PCI settings [ 401.220384] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [ 401.220402] ivb_uncore :00:00.0: no hotplug settings from platform [ 401.220407] ivb_uncore :00:00.0: using default PCI settings [ 401.220422] i915 :00:02.0: no hotplug settings from platform [ 401.220427] i915 :00:02.0: using default PCI settings [ 401.220442] xhci_hcd :00:14.0: no hotplug settings from platform [ 401.220447] xhci_hcd :00:14.0: using default PCI settings [ 401.220467] mei_me :00:16.0: no hotplug settings from platform [ 401.220472] mei_me :00:16.0: using default PCI settings [ 401.220489] e1000e :00:19.0: no hotplug settings from platform [ 401.220494] e1000e :00:19.0: using default PCI settings [ 401.220513] ehci-pci :00:1a.0: no hotplug settings from platform [ 401.220518] ehci-pci :00:1a.0: using default PCI settings [ 401.220537] snd_hda_intel :00:1b.0: no hotplug settings from platform [ 401.220548] pcieport :00:1c.0: no hotplug settings from platform [ 401.220559] pcieport :00:1c.1: no hotplug settings from platform [ 401.220600] pcieport :00:1c.2: no hotplug settings from platform [ 401.220610] pcieport :00:1c.3: no hotplug settings from platform [ 401.220620] pcieport :00:1c.5: no hotplug settings from platform [ 401.220668] ehci-pci :00:1d.0: no hotplug settings from platform [ 401.220673] ehci-pci :00:1d.0: using default PCI settings [ 401.220693] lpc_ich :00:1f.0: no hotplug settings from platform [ 401.220698] lpc_ich :00:1f.0: using default PCI settings [ 401.220717] ahci :00:1f.2: no hotplug settings from platform [ 401.220723] ahci :00:1f.2: using default PCI settings [ 401.220740] pci :00:1f.3: no hotplug settings from platform [ 401.220745] pci :00:1f.3: using default PCI settings [ 401.220790] i915 :00:02.0: BAR 6: [??
Bug#778250: powerline: leaks environment into build (makes unreproducible and possible privacy breach)
Source: powerline Version: 1.2-2 Severity: normal User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps fileordering Hello, While working on the “reproducible builds” effort [1], we have noticed that powerline could not be built reproducibly and it leaks the users environment into the resulting binary package when building. The environment appears in the file ../usr/share/doc/python-powerline-doc/html/develop/extensions.html which is generated from powerline/renderer.py line 47. Since the environment is different between different users this makes the package unreproducible. It might also leak sensitive data the user happens to have in their environment into the package build. Maybe the environment dump should be filtered? What is the reason for it being stored in segment_info in the first place? What is the purpose of storing the value of $HOME during the package build in the member 'home'? If these values are important for the operation of the package then they have to be kept but they should not be included with their values during the package build in the sphinx documentation. Cheers, akira [1]: https://wiki.debian.org/ReproducibleBuilds -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776637: pulseaudio: resets the volume to 100% everytime I connect my bluetooth speakers
Am Donnerstag, den 12.02.2015, 10:30 -0300 schrieb Felipe Sateler: > >> Does this problem occur after disconnecting and reconnecting the > >> speakers? If so, please provide a verbose log of pulseaudio[1] where > >> you connect the bluetooth speakers. > > > > This problem occurs every time I connect my speakers. I'll attach a > > pulseaudio log file I already posted with report #776632. > > > > I started pulseaudio, entered GNOME bluetooth settings, connected to my > > bluetooth speakers and then entered GNOME audio settings. In this case I > > was not affected by bug #776632, so the speakers were addded as audio > > output device. > > Thanks for this log. I'm currrently a bit busy to investigate this, > but in the meantime please check this askubuntu post to see if > anything applies to you: > > http://askubuntu.com/questions/396841/how-can-i-save-my-bluetooth-headset-volume-settings Thanks for your speedy answer and the link! I didn't edit my /etc/pulse/default.pa but I'll attach this file anyway. I'll also attach the output of 'pacmd list-modules'. Modules module-device-restore and module-card-restore are both loaded. I deleted ~/.config/pulse/ which contains the database with device volumes several times before and tried it again now – but without any luck. Since it is mentioned that applications can override the default settings I didn't use Rhythmbox this time but tried out Totem, VLC and Iceweasel after connecting the speakers instead – also without any luck. I had these speakers for some months now and connected them several times every day. Every single time I connected them volume was set to 100%. Please tell me if I can provide any more useful information. #!/usr/bin/pulseaudio -nF # # This file is part of PulseAudio. # # PulseAudio is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # PulseAudio is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU Lesser General Public License # along with PulseAudio; if not, write to the Free Software Foundation, # Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. # This startup script is used only if PulseAudio is started per-user # (i.e. not in system mode) .nofail ### Load something into the sample cache #load-sample-lazy x11-bell /usr/share/sounds/gtk-events/activate.wav #load-sample-lazy pulse-hotplug /usr/share/sounds/startup3.wav #load-sample-lazy pulse-coldplug /usr/share/sounds/startup3.wav #load-sample-lazy pulse-access /usr/share/sounds/generic.wav .fail ### Automatically restore the volume of streams and devices load-module module-device-restore load-module module-stream-restore load-module module-card-restore ### Automatically augment property information from .desktop files ### stored in /usr/share/application load-module module-augment-properties ### Should be after module-*-restore but before module-*-detect load-module module-switch-on-port-available ### Load audio drivers statically ### (it's probably better to not load these drivers manually, but instead ### use module-udev-detect -- see below -- for doing this automatically) #load-module module-alsa-sink #load-module module-alsa-source device=hw:1,0 #load-module module-oss device="/dev/dsp" sink_name=output source_name=input #load-module module-oss-mmap device="/dev/dsp" sink_name=output source_name=input #load-module module-null-sink #load-module module-pipe-sink ### Automatically load driver modules depending on the hardware available .ifexists module-udev-detect.so load-module module-udev-detect .else ### Use the static hardware detection module (for systems that lack udev support) load-module module-detect .endif ### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect channels=2 .fail .endif ### Automatically load driver modules for Bluetooth hardware .ifexists module-bluetooth-policy.so load-module module-bluetooth-policy .endif .ifexists module-bluetooth-discover.so load-module module-bluetooth-discover .endif ### Load several protocols .ifexists module-esound-protocol-unix.so load-module module-esound-protocol-unix .endif load-module module-native-protocol-unix ### Network access (may be configured with paprefs, so leave this commented ### here if you plan to use paprefs) #load-module module-esound-protocol-tcp #load-module module-native-protocol-tcp #load-module module-zeroconf-publish ### Load the RTP receiver module (also configured via paprefs, see above) #load-module module-rtp-recv ### Load the RTP sender module (also configured via paprefs, see abo
Bug#778249: linux-tools-3.16: Please include the x86_energy_perf_policy and turbostat tool on x86
Package: linux-tools-3.16 Version: 3.16-3 Severity: wishlist Hi, Would it be possible to include the x86_energy_perf_policy and turbostat tool on x86 builds of linux-tools? It allows you to set the x86 performance policy of the CPU, and a tool to monitor the CPU states of recent intel processors. Regards, Rik -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/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 linux-tools-3.16 depends on: ii libaudit1 1:2.4-1+b1 ii libc6 2.19-13 ii libdw10.159-4 ii libelf1 0.159-4 ii libnuma1 2.0.10-1 ii libperl5.20 5.20.1-5 ii libpython2.7 2.7.8-11 ii libslang2 2.3.0-2 ii libunwind81.1-3.2 ii perl 5.20.1-5 pn python:any Versions of packages linux-tools-3.16 recommends: ii linux-base 3.5 Versions of packages linux-tools-3.16 suggests: pn linux-doc-3.16 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778248: libnewlib-dev: newlib-nano has a different newlib.h
Package: libnewlib-dev
Version: 2.1.0+git20141201.db59ff3-1
Severity: normal
Tags: patch
Dear Maintainer,
Code built against newlib-nano needs to use newlib-nano's version of
newlib.h, because things like the size and layout of struct _reent
are different.
There are two patches attached:
- The first copies newlib.h from the -nano build to
/usr/include/newlib/nano/newlib.h in the installed package, so that
it's available for use.
- The second adjusts the nano.specs file to add the appropriate
include path, so that "#include " pulls in the
correct file for both cases (with/without "-specs=nano.specs").
This is so that the user does not need to manually specify
the include path in their build.
I'm not very familiar with specs files, so there may be a better
way to handle that second case that avoids having to hardcode the
path.
The first patch is more important and only affects the debian/ dir,
the other might be better coordinated with upstream?
Jim
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (250, 'testing'), (200, 'stable'), (50, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-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
libnewlib-dev depends on no packages.
libnewlib-dev recommends no packages.
Versions of packages libnewlib-dev suggests:
ii gcc-arm-none-eabi4.8.3-9+11
ii libnewlib-arm-none-eabi 2.1.0+git20141201.db59ff3-1
-- no debconf information
>From 235fd4040650b5a3cdca018b089f63f5e34a87f5 Mon Sep 17 00:00:00 2001
From: Jim Paris
Date: Thu, 12 Feb 2015 12:30:44 -0500
Subject: [PATCH 1/2] Ship nano/newlib.h
---
debian/rules | 5 +
1 file changed, 5 insertions(+)
diff --git a/debian/rules b/debian/rules
index b234fe72be86..a0f2330ee4e3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -100,6 +100,11 @@ override_dh_auto_install:
find $(TMP_NANO_DIR) -regex ".*/lib\(c\|g\|rdimon\)\.a" \
-exec rename 's@$(TMP_NANO_DIR)/(.*).a@$(TMP_DIR)/$$1_nano.a@' \{\} \+
#
+ # Move nano's version of newlib.h to nano/newlib.h
+ mkdir -p $(TMP_DIR)/usr/lib/$(TARGET)/include/nano
+ mv $(TMP_NANO_DIR)/usr/lib/$(TARGET)/include/newlib.h \
+ $(TMP_DIR)/usr/lib/$(TARGET)/include/nano/newlib.h
+ #
# Build newlib-source package
mkdir -p $(P_SRC)/usr/src/newlib
cp ../newlib_$(UVERSION).orig.tar.xz $(P_SRC)/usr/src/newlib/newlib-$(UVERSION).tar.xz
--
2.1.3
>From bd495d655003eb97f143bb7bb19d05333046b7fb Mon Sep 17 00:00:00 2001
From: Jim Paris
Date: Thu, 12 Feb 2015 12:54:40 -0500
Subject: [PATCH 2/2] Add /usr/include/newlib/nano to search path in nano.specs
---
libgloss/arm/elf-nano.specs | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libgloss/arm/elf-nano.specs b/libgloss/arm/elf-nano.specs
index 60dc407c678b..c96c57aee50b 100644
--- a/libgloss/arm/elf-nano.specs
+++ b/libgloss/arm/elf-nano.specs
@@ -1,5 +1,6 @@
%rename linknano_link
%rename link_gcc_c_sequencenano_link_gcc_c_sequence
+%rename cpp nano_cpp
*nano_libc:
-lc_nano
@@ -16,3 +17,5 @@
*lib:
%{!shared:%{g*:-lg_nano} %{!p:%{!pg:-lc_nano}}%{p:-lc_p}%{pg:-lc_p}}
+*cpp:
+-I/usr/include/newlib/nano %(nano_cpp)
--
2.1.3
Bug#777743: ITP: wallpaperd -- X wallpaper changing daemon
Dmitry Bogatov dijo [Thu, Feb 12, 2015 at 10:43:17AM +0300]: > - why is this package useful/relevant? > > It follows unix way and manages wallpapers without connection to > your DE, WM or anything. > (...) > if there are other packages providing similar functionality, how does it > compare? > > Such functionality exists in GNOME and KDE, at least. But I know nothing > similar > for bare WM. I guess I do this the ugliest possible way, but my .xsession has: BGDIR=/home/gwolf/.backgrounds while /bin/true do feh --bg-max $BGDIR/$(xscreensaver-getimage-file $BGDIR) sleep 60 done & I guess there's more to wallpaperd than this, right? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777694: ITA: icu -- Development utilities for International Components for Unicode
On Thu, Feb 12, 2015 at 4:50 PM, wrote: > It would be great if you (or any co-maintainer) would initially > take care of the open icu security issues in jessie/sid (with > a minimal upload to sid + unblock request to the release team): That's what I'd like to do. The problem is that upstream doesn't support the version in Jessie anymore and thus I'll have to backport all those security fixes. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776636: pulseaudio: uses bluetooth speakers for audio output immediately after connection - but I can't control the volume
I found a workaround for this bug: When I load the pulseaudio module module-switch-on-connect by adding this entry to /etc/pulse/default.pa load-module module-switch-on-connect I can control the volume of my bluetooth speakers immediately when they are connected. I don't understand why the speakers are even used for audio output when this module is not loaded… But there's no entry for example about module-switch-on-port-available in the PulseAudio documentation [1]. [1] http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777664: [Pkg-salt-team] Bug#777664: salt-minion: Make log file readable by adm group
Am Mittwoch, den 11.02.2015, 23:28 +1100 schrieb Joe Healy: > > > On Wed, Feb 11, 2015 at 8:43 PM, Benjamin Drung > wrote: > > A patch against your master branch is attached. > debian/patches/make-log-file-group-readable.patch is a > backport of the patch > that was accepted upstream (in their develop branch). > > Should this also be done in the salt-master? Yes, maybe. The master log was created with mode 644. So I assume that chmod is not run on that files. = # ls /var/log/salt/ -al total 0 drwxr-s--- 2 root adm 60 Feb 12 18:10 . drwxr-xr-x 1 root root 120 Feb 12 18:10 .. -rw-r--r-- 1 root adm0 Feb 12 18:10 master = -- Benjamin Drung System Developer ProfitBricks GmbH - The IaaS-Company Greifswalder Str. 207 D - 10405 Berlin Mail: benjamin.dr...@profitbricks.com Fax: +49 30 577 008 598 URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506 B. Geschäftsführer: Andreas Gauger, Achim Weiss. signature.asc Description: This is a digitally signed message part
Bug#778247: Please create debconf-in...@list.debian.org
Package: lists.debian.org Severity: wishlist X-Debbugs-Cc: debconf-t...@lists.debconf.org Name: debconf-in...@lists.debian.org Rationale: The DebConf infrastructure team has requested a new pseudo-package in the BTS for tracking issues related to summit.debconf.org, our conference management system. See bug #776982. As discussed there this list will serve as the maintainer address required to receive BTS mail. It will also be useful for team discussions that aren't appropriate for the debconf-team or debconf-video lists. Short Description: DebConf Infrastructure team. Long Description: DebConf Infrastructure team discussions and bug report handling. Category: DebConf Subscription Policy: Open Post Policy: Open Web Archive: Yes Thank you, Eric Rzewnicki (on behalf of DebConf Infrastructure team) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778246: ITP: prokka -- rapid annotation of prokaryotic genomes
Package: wnpp Severity: wishlist Owner: Debian Med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org * Package name: prokka Version : 1.10 Upstream Author : Torsten Seemann * URL : http://www.vicbioinformatics.com/software.prokka.shtml * License : GPL-3+, CC0-1, CC-BY-ND-3 Programming Lang: Perl Description : rapid annotation of prokaryotic genomes A typical 4 Mbp genome can be fully annotated in less than 10 minutes on a quad-core computer, and scales well to 32 core SMP systems. It produces GFF3, GBK and SQN files that are ready for editing in Sequin and ultimately submitted to Genbank/DDJB/ENA. Prokka is a popular bioinformatics program. It will be team maintained by the Debian Med team.
Bug#778235: [Pkg-libvirt-maintainers] Bug#778235: libvirt0: Migration drops elements from XML
On Thu, Feb 12, 2015 at 04:34:35PM +0100, Martin Sofaru wrote: > On 12/02/15 16:02, Guido Günther wrote: > > On Thu, Feb 12, 2015 at 02:54:20PM +0100, Martin Sofaru wrote: > >> Package: libvirt0 > >> Version: 1.2.9-9 > >> Severity: important > >> Tags: patch > >> > >> Dear Maintainer, > >> > >> > >> when migrating a VM the actual XML "virsh dumpxml " is copied to the > >> target host. This drops important elements like portgroups out of a > >> network configuration. > > > > You don't provide much information. Which elemnts are wrong for you > > (e.g. provide a diff and the original configuration). > > The origin XML (--inactive) looks like this: > > > > > > > >function='0x0'/> > > > After migration the origin XML (--inactive) becomes the same as the > actual XML (without --inactive): > > > > > > > > > > >function='0x0'/> > > > The information about the portgroup is lost after migration! > > > Did you check that the patch fixes your problem? > > No. I originally reported the issue to libvirt upstream and was told the > issue was fixed with that commit. > > I am trying to verify if this single commit is enough to fix the issue. You can also try the version from experimental and see if it helps. If so we can try to isolate the fix for jessie (I'm currently lacking the time for any serious libvirt or Debian work though). Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778245: iceweasel: please have iceweasel Recommend: xul-ext-https-everywhere
Package: iceweasel
Version: 35.0.1-1
Severity: wishlist
I think most people browsing the web today should prefer https where
it's available, so default installations of iceweasel should have
https-everywhere included.
It would be great to add:
Recommends: xul-ext-https-everywhere
to the iceweasel package. If this is too strong for some reason,
please at least add it as a Suggests (it's more important than
mozplugger, which is already Suggests).
Regards,
--dkg
-- Package-specific info:
-- Extensions information
Name: Custom Tab Width
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/tab-wi...@design-noir.de
Package: xul-ext-custom-tab-width
Status: enabled
Name: Default theme
Location:
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled
Name: HTTPS-Everywhere
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/https-everywh...@eff.org
Package: xul-ext-https-everywhere
Status: enabled
Name: Monkeysphere
Location: ${PROFILE_EXTENSIONS}/tls-xul-...@monkeysphere.info.xpi
Status: enabled
Name: NoScript
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{73a6fe31-595d-460b-a920-fcc0f8843232}
Package: xul-ext-noscript
Status: enabled
Name: RequestPolicy
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/requestpol...@requestpolicy.com
Package: xul-ext-requestpolicy
Status: enabled
Name: Web Developer
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{c45c406e-ab73-11d8-be73-000a95be3b12}
Package: xul-ext-webdeveloper
Status: enabled
-- Plugins information
-- Addons package information
ii iceweasel 35.0.1-1 amd64Web browser based on Firefox
ii xul-ext-custom 1.0.1-2 all Iceweasel/Firefox extension for s
ii xul-ext-https- 4.0.2-1 all extension to force the use of HTT
ii xul-ext-noscri 2.6.9.3-1all permissions manager for Iceweasel
ii xul-ext-reques 0.5.28-1 all improve your browsing: more priva
ii xul-ext-webdev 1.2.5+repack all web developer extension
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages iceweasel depends on:
ii debianutils 4.4+b1
ii fontconfig2.11.0-6.3
ii libasound21.0.28-1
ii libatk1.0-0 2.14.0-1
ii libc6 2.19-13
ii libcairo2 1.14.0-2.1
ii libdbus-1-3 1.8.12-3
ii libdbus-glib-1-2 0.102-1
ii libevent-2.0-52.0.21-stable-2
ii libffi6 3.1-2+b2
ii libfontconfig12.11.0-6.3
ii libfreetype6 2.5.2-2
ii libgcc1 1:4.9.1-19
ii libgdk-pixbuf2.0-02.31.1-2+b1
ii libglib2.0-0 2.42.1-1
ii libgtk2.0-0 2.24.25-1
ii libhunspell-1.3-0 1.3.3-3
ii libnspr4 2:4.10.7-1
ii libnss3 2:3.17.2-1.1
ii libpango-1.0-01.36.8-3
ii libsqlite3-0 3.8.7.1-1
ii libstartup-notification0 0.12-4
ii libstdc++64.9.1-19
ii libvpx1 1.3.0-3
ii libx11-6 2:1.6.2-3
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.8-1+b1
ii libxt61:1.1.4-1+b1
ii procps2:3.3.9-8
ii zlib1g1:1.2.8.dfsg-2+b1
Versions of packages iceweasel recommends:
pn gstreamer1.0-libav
ii gstreamer1.0-plugins-good 1.4.4-2
Versions of packages iceweasel suggests:
ii fonts-mathjax 2.4-2
ii fonts-oflb-asana-math 000.907-6
ii fonts-stix [otf-stix] 1.1.1-1
ii libcanberra0 0.30-2.1
ii libgnomeui-0 2.24.5-3
ii libgssapi-krb5-2 1.12.1+dfsg-17
pn mozplugger
-- debconf-show failed
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777635: [Python-modules-team] Bug#777635: python-odf: please make the build reproducible
> How about changing doxygen to default to HTML_TIMESTAMP=NO in Debian? Whilst this would benefit the reproducible project, I worry this would be a little too invasive and unexpected as a general default. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777583: Incorrect debian/copyright for smartmontools
Package: smartmontools Version: 6.3+svn4002-2+b2 Followup-For: Bug #777583 Attached find a debdiff and a git-diff to add the "or (at your option) any later version" clause to debian/copyright. The debdiff is created using HEAD in git as the original package (so probably NOT the version that is currently in testing) -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=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 smartmontools depends on: ii debianutils 4.4+b1 ii init-system-helpers 1.22 ii libc62.19-13 ii libcap-ng0 0.7.4-2 ii libgcc1 1:4.9.2-10 ii libselinux1 2.3-2 ii libstdc++6 4.9.2-10 ii lsb-base 4.1+Debian13+nmu1 Versions of packages smartmontools recommends: ii bsd-mailx [mailx] 8.1.2-0.20141216cvs-1 Versions of packages smartmontools suggests: pn gsmartcontrol pn smart-notifier -- no debconf information diff -Nru smartmontools-6.3+svn4002/debian/changelog smartmontools-6.3+svn4002/debian/changelog --- smartmontools-6.3+svn4002/debian/changelog 2015-02-12 17:12:37.0 +0100 +++ smartmontools-6.3+svn4002/debian/changelog 2015-02-12 17:52:38.0 +0100 @@ -1,3 +1,13 @@ +smartmontools (6.3+svn4002-2) UNRELEASED; urgency=medium + + [ Giuseppe Iuculano ] + * Correct maintscript syntax (Closes: #766178) + + [ IOhannes m zmölnig ] + * Fix license: it's really GPL-2+ (Closes: #777583) + + -- Giuseppe Iuculano Thu, 12 Feb 2015 17:52:25 +0100 + smartmontools (6.3+svn4002-1) unstable; urgency=low * [03a62f0] Set EnvironmentFile=-/etc/default/smartmontools in smartd.service diff -Nru smartmontools-6.3+svn4002/debian/copyright smartmontools-6.3+svn4002/debian/copyright --- smartmontools-6.3+svn4002/debian/copyright 2015-02-12 17:48:31.0 +0100 +++ smartmontools-6.3+svn4002/debian/copyright 2015-02-12 17:50:15.0 +0100 @@ -14,5 +14,5 @@ License: You are free to distribute this software under the terms of the GNU General -Public License Version 2. The full text of this license can be found in the -file /usr/share/common-licenses/GPL-2 +Public License Version 2, or (at your option) any later version. The full text +of this license can be found in the file /usr/share/common-licenses/GPL-2 >From 40173c4dde3bf76e5bf801c9df1c8cffea11d9a2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?IOhannes=20m=20zm=C3=B6lnig?= Date: Thu, 12 Feb 2015 17:15:57 +0100 Subject: [PATCH] Fix license: it's really GPL-2+ (Closes: #777583) --- debian/copyright | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/copyright b/debian/copyright index 0803ab3..22d8118 100644 --- a/debian/copyright +++ b/debian/copyright @@ -14,5 +14,5 @@ Copyright: License: You are free to distribute this software under the terms of the GNU General -Public License Version 2. The full text of this license can be found in the -file /usr/share/common-licenses/GPL-2 +Public License Version 2, or (at your option) any later version. The full text +of this license can be found in the file /usr/share/common-licenses/GPL-2 -- 2.1.4
Bug#777668: [debian-mysql] [PATCH] Fix for bug #777668
Indeed.. I fell asleep before remembering to send a message to the bug. I also reassigned it to mysql-server-5.6, since we're not going to fix this in 5.5. Excerpts from Bjoern Boschman's message of 2015-02-12 04:48:53 -0800: > fyi - clint was so kind to push this also into mysql-5.6 > I'll build exp packages and place then in my wheezy repo > http://www.boschman.de/debian/ > > 2015-02-11 12:31 GMT+01:00 Akhil Mohan : > > Hi, > > > > This patch fixes minor bug #777668 to replace an option in my.cnf. I am > > sending this patch for review before pusing it to the Debian VCS. > > > > Akhil Mohan (1): > > Updated d/additions/my.cnf to replace deprecated option key_buffer > > with new option key_buffer_size (Closes: #777668) > > > > debian/additions/my.cnf | 4 ++-- > > debian/changelog| 5 - > > 2 files changed, 6 insertions(+), 3 deletions(-) > > > > -- > > 2.1.0 > > > > > > ___ > > pkg-mysql-maint mailing list > > pkg-mysql-ma...@lists.alioth.debian.org > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778244: tomboy: Please add evolution add on
Package: tomboy Version: 1.14.1-3 Severity: normal Dear Maintainer, The Evolution add on is missing from jessie packages on some architectures (including amd64 and i386). It was included in prior debian versions, and evolution is still listed as a suggested package. Missing file: /usr/lib/tomboy/addins/Evolution.dll -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tomboy depends on: ii gconf2 3.2.6-3 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libdbus-glib2.0-cil 0.6.0-1 ii libdbus2.0-cil 0.8.1-1 ii libfontconfig1 2.11.0-6.3 ii libfreetype62.5.2-2 ii libgconf2.0-cil 2.24.2-3 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-02.42.1-1 ii libglib2.0-cil 2.12.10-5 ii libgtk2.0-0 2.24.25-1 ii libgtk2.0-cil 2.12.10-5 ii libgtkspell02.0.16-1.1 ii libice6 2:1.0.9-1+b1 ii libmono-addins-gui0.2-cil 1.0+git20130406.adcd75b-3 ii libmono-addins0.2-cil 1.0+git20130406.adcd75b-3 ii libmono-cairo4.0-cil3.2.8+dfsg-9 ii libmono-corlib4.5-cil 3.2.8+dfsg-9 ii libmono-posix4.0-cil3.2.8+dfsg-9 ii libmono-system-core4.0-cil 3.2.8+dfsg-9 ii libmono-system-xml4.0-cil 3.2.8+dfsg-9 ii libmono-system4.0-cil 3.2.8+dfsg-9 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libproxy1 0.4.11-4+b2 ii libsm6 2:1.2.2-1+b1 ii libx11-62:1.6.2-3 ii mono-runtime3.2.8+dfsg-9 tomboy recommends no packages. Versions of packages tomboy suggests: ii evolution 3.12.9~git20141130.241663-1+b1 ii tasque 0.1.12-4 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776086: vorbis-tools: CVE-2014-9638 CVE-2014-9639 CVE-2014-9640
Moritz Muehlenhoff wrote: Did you contact upstream, are fixes available for these? There are bug tracker items available for the two remaining issues [1] [2], but there has been no movement so far. I've looked into it and the security aspect is fairly easy to fix by just adding an additional sanity check that allows only positive numbers of channels (rule out 0 to avoid CVE-2014-9638 and negative values to avoid CVE-2014-9639). For the case CVE-2014-9638, I even consider this the proper and complete fix. In CVE-2014-9639, however, the deeper reason for the appearance of a negative number of channels is an overflow because of several unsuitable data types used in the reading of the wav headers. The proper fix would be to change those data types - which has to be done with great care, in order to avoid shifting the overflow from its current place to a place that might be even less guarded. I haven't gotten around to reviewing the code and fixing this. But maybe for now we can just stick with the sanity check? It fixes the security aspect and doesn't break any case that wasn't broken already - it however doesn't fix the problem that oggenc refuses to process some theoretically valid (although very uncommon, if existent at all) WAV files with very extreme parameters. Cheers, Martin [1] https://trac.xiph.org/ticket/2137 [2] https://trac.xiph.org/ticket/2136 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778243: "pg_conftool remove" is broken
Package: postgresql-common
Version: 155
Severity: important
Tags: patch pending
"pg_conftool remove" is broken. The command requires one argument
(the setting to remove/disable), but the parser wants two arguments.
This trivial patch fixes this:
=== modified file 'debian/changelog'
--- debian/changelog2015-02-05 21:19:24 +
+++ debian/changelog2015-02-12 16:22:17 +
@@ -1,3 +1,9 @@
+postgresql-common (167) UNRELEASED; urgency=medium
+
+ * pg_conftool: Fix 'remove' operation. Spotted by François Henry, merci!
+
+ -- Christoph Berg Thu, 12 Feb 2015 17:21:25 +0100
+
postgresql-common (166) unstable; urgency=medium
* postgresql-common: Breaks: systemd (<< 204). postgresql@.service uses
=== modified file 'pg_conftool'
--- pg_conftool 2015-02-03 14:52:23 +
+++ pg_conftool 2015-02-12 16:22:17 +
@@ -84,7 +84,7 @@
if ($ARGV[0] =~ /^(edit)$/) {
help(1, "$ARGV[0] takes no argument") unless (@ARGV == 1);
($cmd) = @ARGV;
-} elsif ($ARGV[0] =~ /^(show|disable)$/) {
+} elsif ($ARGV[0] =~ /^(show|remove)$/) {
help(1, "$ARGV[0] needs exactly one argument") unless (@ARGV == 2);
($cmd, $key) = @ARGV;
} else {
Christoph
--
c...@df7cb.de | http://www.df7cb.de/
signature.asc
Description: Digital signature
Bug#778242: libnewlib-arm-none-eabi: mismatched version between libnewlib-arm-none-eabi and libnewlib-dev
Package: libnewlib-arm-none-eabi Version: 2.1.0+git20141201.db59ff3-1 Severity: normal Dear Maintainer, Currently it's possible to have mismatched versions of libnewlib-arm-none-eabi and libnewlib-dev installed (as is the case on my system right now, see version above & below). That seems non-ideal: definitions that change in newlib.h can affect the size of struct _reent, for example, leading to problems. Should libnewlib-arm-none-eabi's dependency on libnewlib-dev be strictly versioned? Jim -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (250, 'testing'), (200, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-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 Versions of packages libnewlib-arm-none-eabi depends on: ii libnewlib-dev 2.1.0+git20140818.1a8323b-2 Versions of packages libnewlib-arm-none-eabi recommends: ii gcc-arm-none-eabi 4.8.3-9+11 ii libstdc++-arm-none-eabi-newlib 4.8.3-9+4 Versions of packages libnewlib-arm-none-eabi suggests: pn libnewlib-doc -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777601: systemd: Loosing LXC memory cgroups after service install
Control: tag -1 -moreinfo Pierre Mavro [2015-02-12 16:11 +0100]: > I think this may not be a critical bug, however as this is the only way > (as far as I know) to know/monitor the used resources of a container, I > think it's important. Not just a cosmetical problem. Ah, ok. The patch is simple enough (well, at least for me..) so I backported it to master for jessie: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=255ae60 We'll upload 215-12 in the next days, would be nice if you could confirm that this fixes things! Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#777727: authbind: please make the build reproducible
Chris Lamb writes ("Bug#27: authbind: please make the build reproducible"):
> Source: authbind
> Version: 2.1.1
> Severity: wishlist
> Tags: patch
...
> - gzip -9 debian/tmp/usr/share/man/man*/* $(udp)/*
> + gzip -9n debian/tmp/usr/share/man/man*/* $(udp)/*
Thanks.
I will try to remember to look for this kind of thing in all my
packages.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778241: RM: python-django-lint; ROM; RC-buggy; not in testing; abandoned upstream
Package: ftp.debian.org Severity: normal Hi, Please remove python-django-lint (ROM; RC-buggy; not in testing; abandoned upstream). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777635: [Python-modules-team] Bug#777635: python-odf: please make the build reproducible
On 2015-02-10 23:33, Chris Lamb wrote: How about changing doxygen to default to HTML_TIMESTAMP=NO in Debian? This way many package would benefit at once. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
