Bug#997256: rdfind: FTBFS: rdfind.cc:225:30: error: ‘numeric_limits’ is not a member of ‘std’
This is fixed by commit https://github.com/pauldreik/rdfind/commit/61877de88d782b63b17458a61fcc078391499b29 which is on branch devel but not yet master. Paul Dreik Den 2021-10-23 kl. 21:24, skrev Lucas Nussbaum: Source: rdfind Version: 1.5.0-1 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): g++ -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o Rdutil.o Rdutil.cc rdfind.cc: In function ‘Options parseOptions(Parser&)’: rdfind.cc:225:30: error: ‘numeric_limits’ is not a member of ‘std’ 225 | o.maximumfilesize = std::numeric_limits::max(); | ^~ rdfind.cc:225:45: error: expected primary-expression before ‘decltype’ 225 | o.maximumfilesize = std::numeric_limits::max(); | ^~~ make[2]: *** [Makefile:662: rdfind.o] Error 1 The full build log is available from: http://qa-logs.debian.net/2021/10/23/rdfind_1.5.0-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with mine so that we can identify if something relevant changed in the meantime.
Bug#987821: libvirt-daemon-system: in/out error during rapid graphics changes in guest closes virt-manager windows
Package: libvirt-daemon-system Version: 7.0.0-3 Severity: normal X-Debbugs-Cc: debianb...@pauldreik.se Dear Maintainer, I use Debian Buster as guest, but the problem also happens for Ubuntu 20.04 as well as Debian Bullseye/testing so I think the problem lies in the host (running Debian Bullseye/current testing). I use the guest through virt-manager, running Gnome both in the host and guest. When there is a large change in the graphics in the guest, such as scrolling fast on a web page, virt-manager and it's windows (also for other guests) disappear. In /var/log/syslog, the following message appears: Apr 30 08:53:48 flygfisken libvirtd[876]: End of file while reading data: In/ut-fel (sorry for the localized message, In/ut-fel is In/out error in English) I can open virt-manager again, the machines still run, but it's a bit annoying since one has to be careful with using the guest. I tried using another video model such as Virtio but it does not help. With virtio, disabling or disabling 3d acceleration does not affect the behaviour. Thanks, Paul -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt-daemon-system depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.75 ii gettext-base0.21-4 ii iptables1.8.7-1 ii libvirt-clients 7.0.0-3 ii libvirt-daemon 7.0.0-3 ii libvirt-daemon-config-network 7.0.0-3 ii libvirt-daemon-config-nwfilter 7.0.0-3 ii libvirt-daemon-system-systemd 7.0.0-3 ii logrotate 3.18.0-2 ii policykit-1 0.105-30 Versions of packages libvirt-daemon-system recommends: ii dmidecode3.3-1 ii dnsmasq-base [dnsmasq-base] 2.85-1 ii iproute2 5.10.0-4 ii mdevctl 0.78-1 ii parted 3.4-1 Versions of packages libvirt-daemon-system suggests: ii apparmor2.13.6-10 pn auditd pn nfs-common pn open-iscsi pn pm-utils pn radvd ii systemd 247.3-5 pn systemtap pn zfsutils -- Configuration Files: /etc/libvirt/qemu.conf [Errno 13] Åtkomst nekas: '/etc/libvirt/qemu.conf' -- debconf information: libvirt-daemon-system/id_warning: true
Bug#987702: virt-manager: Resolution 5120x1440 wrongly snaps to 5120x2160 in the guest
Package: virt-manager Version: 1:3.2.0-3 Severity: normal X-Debbugs-Cc: debianb...@pauldreik.se Dear Maintainer, I run Debian bullseye in both the host and guest. I have a 5120x1440 screen which works perfectly fine in the host. When using the guest in fullscreen mode, I want it to use 5120x1440 as well. It is however not available in the gnome screen resolution menu, instead 5120x2160 shows up which is a bit awkward to use because it crops the bottom. Using Debian Buster instead of Bullseye in the guest works as expected. Ubuntu 20.04 as a guest has the same problem as Debian Bullseye. I have tried changing the video model in virt-manager to see if it helps, it doesn't. An observation is that both Ubuntu 20.04 and Debian Bullseye, when run as guests, report the screen as "Red Hat, 53 inch''". Debian Bullseye reports it as "Unknown display". Thanks, Paul -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virt-manager depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii gir1.2-gtk-3.0 3.24.24-3 ii gir1.2-gtk-vnc-2.0 1.0.0-1 ii gir1.2-gtksource-4 4.8.0-1 ii gir1.2-libosinfo-1.0 1.8.0-1 ii gir1.2-libvirt-glib-1.0 3.0.0-1 ii gir1.2-vte-2.91 0.62.3-1 ii python3 3.9.2-3 ii python3-dbus 1.2.16-5 ii python3-gi 3.38.0-2 ii python3-gi-cairo 3.38.0-2 ii python3-libvirt 7.0.0-2 ii virtinst 1:3.2.0-3 Versions of packages virt-manager recommends: ii gir1.2-ayatanaappindicator3-0.1 0.5.5-2 ii gir1.2-spiceclientglib-2.0 0.39-1 ii gir1.2-spiceclientgtk-3.00.39-1 ii libvirt-daemon-system7.0.0-3 Versions of packages virt-manager suggests: ii gir1.2-secret-1 0.20.4-2 ii gnome-keyring3.36.0-1 pn python3-guestfs pn ssh-askpass ii virt-viewer 7.0-2 Versions of packages virt-manager is related to: ii libvirt-clients 7.0.0-3 ii libvirt-daemon 7.0.0-3 ii libvirt0 7.0.0-3 ii osinfo-db0.20210215-1 -- no debconf information
Bug#942631: nftables: Failed start results in all traffic allowed
Source: nftables
Version: 0.7-1
Severity: wishlist
In case nftables has trouble starting, the result is a system with no rules at
all, resulting in everything allowed. This is surprising (for me), since the
entire point of having a firewall (for me) is to restrict access.
This is how I setup my system (following https://wiki.debian.org/nftables):
- new installed of stretch system
- install nftables
- modify /etc/nftables.conf
- enable and start the nftables service
- verify that network traffic is blocked correctly
- fine, all good!
The surprise came after the next reboot. I found entries in my mail log
indicating people trying to connect, which were supposed to be blocked. I found
that the service was not running, because of trouble starting. The problem was
that I used a host name instead of ip address, and name resolution had a
temporary failure so the service failed. I suspect it runs early in the boot,
while the network is not fully configured yet. But my exact cause of the
problem is unimportant - I believe there are other reasons nftables could
refuse to start.
I wonder if it would be possible to have some kind of fallback for this kind of
situation.
- the service retries again, if it fails to start the first time
- default "block all" rules are applied
The first option would potentially leave the network open for some time.
The second option would potentially lock people out from administration/updates
causing the system to be unreachable.
I "solved it" by adding a crontab job checking if the service was not running
("service nftables status") and started it.
This bug report is a request for comments - could something be written on the
Debian wiki? What is the recommended way of handling the situation? Could the
Debian systemd service file be modified such that it retries by default?
Note: I report this system on Debian Buster, so the auto attached system
information is irrelevant because it happened on another system running Debian
Stretch.
-- System Information:
Debian Release: 10.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8),
LANGUAGE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#939969: dpkg-buildflags sets C++ incompatible warning implicit-function-declaration if qa=+all is used
Package: dpkg Version: 1.19.7 Severity: normal Dear Maintainer, I use dpkg-buildflags in my continuous integration script, to make sure my software (rdfind, available in debian) will build ok when the official rdfind package is built. I count the warnings during build, and error out if it is nonzero. This works fine in buster. This will however fail with g++-9, which warns when using -Werror=implicit-function-declaration on C++ programs. To reproduce: export DEB_BUILD_MAINT_OPTIONS="qa=+all" touch empty.cpp g++-9 $(dpkg-buildflags --get CXXFLAGS) -c empty.cpp # outputs a warning from g++ Reading the manpage for dpkg-buildflags, it says CXXFLAGS is the same as CFLAGS. I think that is unfortunate. I would expect CXXFLAGS to be C++ specific. Thanks, Paul -- Package-specific info: System tainted due to merged-usr-via-symlinks. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-9.2 ii libc62.28-10 ii liblzma5 5.2.4-1+b1 ii libselinux1 2.9-2+b2 ii tar 1.30+dfsg-6+b1 ii zlib1g 1:1.2.11.dfsg-1+b1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt1.8.3 pn debsig-verify -- no debconf information
Bug#926218: its gcc, not ranges. dropping -Werror makes the build pass
Hi, this seems to be caused by /usr/bin/c++ accepting flags during cmake configuration, but not later during compilation. ranges uses the check_cxx_compiler_flag in order to set a lot of flags, including the ones mentioned by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926218#5 Using the c++98-compat as an example: cmake executes /usr/bin/c++ -Wno-c++98-compat /range-v3/build/CMakeFiles/CMakeTmp/src.cxx -o to see if no-c++98-compat is supported. But c++ accepts even nonexistant warnings: touch empty.cpp /usr/bin/c++ -Wno-iamsurethisonedoesnotexist -c empty.cpp -o /dev/null works fine, even if the following gives (as expected) an error: /usr/bin/c++ -Wiamsurethisonedoesnotexist -c empty.cpp -o /dev/null c++: error: unrecognized command line option ‘-Wiamsurethisonedoesnotexist’ so I would say this it not ranges that is broken, it's gcc. I would say that the proper action (for the ranges package) is to drop the Werror from line 34 in cmake/ranges_flags.cmake makes the build pass. Paul -- Paul Dreik Web: https://www.pauldreik.se/ Phone: +46 (0)73 99 26 333 Alt. voice channels: Signal, Whatsapp signature.asc Description: OpenPGP digital signature
Bug#924813: the error is in the libmpich-dev package
Hi, It bugs out on the following file /usr/include/x86_64-linux-gnu/mpich/mpicxx.h which is supplied by the libmpich-dev package. // Check for incompatible GCC versions // GCC (specifically) g++ changed the calling convention // between 3.2.3 and 3.4.3 (!!) Normally such changes // should only occur at major releases (e.g., version 3 to 4) #ifdef __GNUC__ # if __GNUC__ >= 8 # if __GNUC_MINOR__ > 2 && 2 == 2 # error 'Please use the same version of GCC and g++ for compiling MPICH and user MPI programs' # endif # endif #endif I believe this bug should be moved to that package instead. Is the error perhaps because gcc was bumped to 8.3? I wonder if it's still relevant, gcc 3.4.3 was released around 2004(?) or so. Commenting out the line in the above file gets bagel to build again. Paul
Bug#925326: source-highlight: FTBFS on clang
Source: source-highlight
Version: 3.1.8-1.2
Severity: minor
Dear Maintainer,
source-highlight won't build with clang. Please consider applying
the patches I submitted upstream a moment ago.
https://savannah.gnu.org/bugs/?func=detailitem_id=49327
I tested them with
export CXX=clang++-7
dpkg-buildpackage -b -uc
on this Debian Buster system and the package builds now both with clang and gcc.
Thanks, Paul
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-2-amd64 (SMP w/16 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8),
LANGUAGE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- source-highlight-3.1.8_orig/lib/tests/test_wordtokenizer_main.cpp
2012-04-14 19:29:40.0 +0200
+++ source-highlight-3.1.8/lib/tests/test_wordtokenizer_main.cpp
2019-03-23 07:30:31.268065859 +0100
@@ -6,12 +6,13 @@
#include "asserttestexit.h"
#include "srchilite/wordtokenizer.h"
-#include "srchilite/tostringcollection.h"
+
using namespace std;
using namespace srchilite;
static ostream <<(ostream , const
WordTokenizer::WordTokenizerResults::value_type &);
+#include "srchilite/tostringcollection.h"
ostream <<(ostream , const
WordTokenizer::WordTokenizerResults::value_type ) {
if (token.first.size()) {
--- source-highlight-3.1.8/lib/tests/stdboosterror.h2010-05-06
10:32:57.0 +0200
+++ source-highlight-3.1.8_patched/lib/tests/stdboosterror.h2019-03-23
06:56:52.111635097 +0100
@@ -3,8 +3,7 @@
#include
-static boost::regex_error
-
std_boost_exception(boost::regex_error(boost::regex_constants::error_bad_pattern));
+static boost::regex_error
std_boost_exception(boost::regex_constants::error_bad_pattern);
/**
* returns the string representing a standard exception (which
Bug#815120: hash support in rdfind
Hi! I fixed this in 1.4.0-alpha0, could you please have a look? https://github.com/pauldreik/rdfind/releases/tag/releases%2F1.4.0-alpha0 see also https://github.com/pauldreik/rdfind/issues/7 Thanks, Paul
Bug#754663: fixed in 1.4.0-alpha0
Hi! I fixed this in 1.4.0-alpha0, could you please have a look? https://github.com/pauldreik/rdfind/releases/tag/releases%2F1.4.0-alpha0 see also https://github.com/pauldreik/rdfind/issues/8 Thanks, Paul
Bug#648671: fixed in 1.4.0-alpha0
Hi! I fixed this in 1.4.0-alpha0, could you please have a look? https://github.com/pauldreik/rdfind/releases/tag/releases%2F1.4.0-alpha0 see also https://github.com/pauldreik/rdfind/issues/11 Thanks, Paul
Bug#901423: fixed in 1.4.0-alpha0
Hi! I fixed this in 1.4.0-alpha0, could you please have a look? https://github.com/pauldreik/rdfind/releases/tag/releases%2F1.4.0-alpha0 see also https://github.com/pauldreik/rdfind/issues/12 Thanks, Paul
Bug#860604: here is a patch that makes it build
Hi, here is a patch that makes it build again. Paul -- Paul Dreik URL: https://www.pauldreik.se/ Phone: +46 (0)73 99 26 333 skype: paul.dreik fixes ftbfs #860604 --- a/escriptcore/src/BinaryDataReadyOps.cpp +++ b/escriptcore/src/BinaryDataReadyOps.cpp @@ -312,6 +312,7 @@ LSCALAR dummyl=0; RSCALAR dummyr=0; DataTypes::RealVectorType::size_type valcount=res.getNumDPPSample()*DataTypes::noValues(res.getShape()); + (void)valcount; escript::binaryOpVectorTagged(res.getTypedVectorRW(resdummy), res.getNumSamples(),res.getNumDPPSample(), DataTypes::noValues(res.getShape()), @@ -370,7 +371,7 @@ LSCALAR dummyl=0; RSCALAR dummyr=0; DataTypes::RealVectorType::size_type valcount=res.getNumDPPSample()*DataTypes::noValues(res.getShape()); - + (void)valcount; escript::binaryOpVectorTagged(res.getTypedVectorRW(resdummy), res.getNumSamples(),res.getNumDPPSample(), DataTypes::noValues(res.getShape()), left.getTypedVectorRO(dummyl), left.getRank()==0, signature.asc Description: OpenPGP digital signature
Bug#786504: xorg-server: Assertion `temp_priv-type != GLAMOR_TEXTURE_LARGE' failed.
Source: xorg-server Version: 2:1.16.4-1 Severity: normal Dear Maintainer, using iceweasel, going to http://lcamtuf.coredump.cx/afl/demo/ then pressing the first click here link which points to: http://lcamtuf.coredump.cx/afl/demo/jpeg/full/ these are some example inputs from the afl fuzzer. instead of displaying, the screen went black and i was logged out. the gdm login screen was shown. ~/.xsession-errors contains nothing particular. however, /var/log messages contains these interesting lines: (snip. lots of these similar jpeg error messages) May 22 12:35:14 tonfisk iceweasel.desktop[28508]: Corrupt JPEG data: 5 extraneous bytes before marker 0xa1 May 22 12:35:14 tonfisk iceweasel.desktop[28508]: Corrupt JPEG data: 8 extraneous bytes before marker 0xc4 May 22 12:35:14 tonfisk iceweasel.desktop[28508]: Corrupt JPEG data: 1 extraneous bytes before marker 0xe0 May 22 12:35:14 tonfisk iceweasel.desktop[28508]: Corrupt JPEG data: 4 extraneous bytes before marker 0xc4 May 22 12:35:14 tonfisk iceweasel.desktop[28508]: Corrupt JPEG data: 8 extraneous bytes before marker 0xc4 May 22 12:35:14 tonfisk iceweasel.desktop[28508]: Corrupt JPEG data: 16 extraneous bytes before marker 0xc4 May 22 12:35:14 tonfisk iceweasel.desktop[28508]: Invalid SOS parameters for sequential JPEG May 22 12:35:14 tonfisk iceweasel.desktop[28508]: Corrupt JPEG data: 16 extraneous bytes before marker 0xc4 May 22 12:35:14 tonfisk iceweasel.desktop[28508]: Corrupt JPEG data: bad Huffman code May 22 12:35:14 tonfisk gdm-Xorg-:1[27988]: Xorg: .../../glamor/glamor_largepixmap.c:787: glamor_merge_clipped_regions: Assertion `temp_priv-type != GLAMOR_TEXTURE_LARGE' failed. May 22 12:35:14 tonfisk kernel: [60039.502124] switching from power state: May 22 12:35:14 tonfisk kernel: [60039.502126] ui class: performance May 22 12:35:14 tonfisk kernel: [60039.502127] internal class: none (snip. gdm-Xorg restarts) I do not know if this may be related: https://bugs.freedesktop.org/show_bug.cgi?id=87866 -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=sv_SE.utf8, LC_CTYPE=sv_SE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682751: patch confirmed to work
Thanks Jon! I just wanted to say that I successfully used this patch to get a multidrive jessie system working. My system: /dev/sda1 contains btrfs for /boot /dev/sda5 is a luks container /dev/sdb2 -''- /dev/sdc2 -''- / is a btrfs filesystem using the three encrypted containers. It was created with the jessie installer using sda5_crypt, then after a successful boot in the newly installed system manually extended to a multidevice btrfs using cryptsetup luksFormat /dev/sdb2 cryptsetup luksFormat /dev/sdc2 then editing /etc/crypttab, followed by btrfs device add /dev/mapper/sdb2_crypt /dev/mapper/sdc2_crypt / now a update-initramfs with the patch applied resulted in a successfully booting system. The default jessie version did not. Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736066: multiple security issues discovered in encfs
Package: encfs Version: 1.7.4-2.4+b2 A recent report discusses some issues with encfs. I do not have the competence to judge it, but it is a good idea it at lease comes to the users and package maintainers knowledge. See https://defuse.ca/audits/encfs.htm Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713947: updated broke squeeze installation
2013-07-03 22:58, Yves-Alexis Perez skrev:
On mer., 2013-07-03 at 10:25 +0200, Paul Dreik wrote:
Notice: add_option was called with an argument that
is strongdeprecated/strong
since version 2.3 with no alternative available. in
/usr/share/wordpress/wp-includes/functions.php on line 2927
(repeated three times)
My guess would be a plugin/theme not compatible with recent (post 2.3)
wordpress. Do you have something like that installed?
No plugins but a theme that was modified from the earlier Debian
version. I am not sure that was the problem. I now have the site up
again. This is how I did it:
I switched to an unmodified upstream release (3.5.2, same as the current
Debian squeeze version). The same problem as earlier persisted. I turned
on mysql debugging and it looked like wordpress tried to prepare or try
to update the databases. I then tried logging in through $URL/wp-admin/
and I finally got some output. It told me it needed to upgrade the
database, which I was able to do without problems. Then things started
working as expected, and the story could have been over.
However, I prefer to run the debian package rather than upstream sources
(to get security updates etc. although I may have second thoughts about
that right now). Therefore I switched back to the debian packages
version using a separate configuration in apache. As part of the earlier
trouble shooting, I had removed the themes folder. So now when I used
the Debian version, on the database that had been updated by the
upstream package, the page showed up, although without a theme. (This
was not the case earlier, so the removed themes folder was NOT the
solution.)
So, it seems like upgrading to a new version requires logging in to the
admin section to get it working properly. I assume this is also thye
case for the debian packaged version. I think it is really unfriendly of
wordpress to not give any output at all in this situation, not even when
enabling debugging. Maybe most people update through the web interface
rather than the distributions package updates and never get such problems.
According to the documentation at
http://codex.wordpress.org/Updating_WordPress#Step_2:_Update_your_installation
updating the database through the web interface is the right thing to
do. I do not think it would hurt to mention it among the other news
displayed when updating the package. People run debian stable for a
reason, and security updates that bump the version should in my opinion
be careful about breaking existing installations. I hope I contributed
instead of only complaining by troubleshooting and reporting my findings.
Notice: Undefined index: HTTP_X_FORWARDED_PROTO in
/usr/share/wordpress/wp-config.php on line 56
For this one I'm not so sure, but double checking the previous item
should at least help.
This problem is unrelated to the problems I had and persists also in the
new version (upstream or not). It is solved by the attached patch.
thanks for your work with packaging wordpress!
paul
--- wp-config.php.orig 2013-07-04 12:45:14.026201299 +0200
+++ wp-config.php 2013-07-04 12:46:00.043700665 +0200
@@ -53,8 +53,10 @@
$table_prefix = 'wp_';
}
-if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
-$_SERVER['HTTPS'] = 'on';
+if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
+$_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
+ $_SERVER['HTTPS'] = 'on';
+}
require_once(ABSPATH . 'wp-settings.php');
?
Bug#713947: updated broke squeeze installation
Hi,
I run wordpress on squeeze and it unfortunately stopped working with
this update. Reading the changelog I expected having to fix possible
theme problems, but did not expect that it stopped working without any
ouput at all.
I now get blank output when I read the site in a web browser. The
(apache) server logs are also blank, even at (apache) log level debug.
I then tried to enable debug in wordpress with define('WP_DEBUG', true);
at the top of /etc/wordpress/config-(sitename).php. That gives me the
following output both in the apache log and web page output:
Notice: add_option was called with an argument that
is strongdeprecated/strong
since version 2.3 with no alternative available. in
/usr/share/wordpress/wp-includes/functions.php on line 2927
(repeated three times)
Notice: Undefined index: HTTP_X_FORWARDED_PROTO in
/usr/share/wordpress/wp-config.php on line 56
I tried to search for these errors but gave up quickly, as they do not
seem to be very important to explain what is wrong.
Can you please give me some advice on how to trouble shoot? I suspect
there are more squeeze wordpress users out there and it would be nice to
identify what is wrong and fix it.
paul
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711793: rdfind: FTBFS on hurd-i386
2013-06-18 22:39, Samuel Thibault skrev: Paul Dreik, le Tue 18 Jun 2013 22:34:26 +0200, a écrit : 2013-06-18 22:14, Samuel Thibault skrev: Paul Dreik, le Tue 18 Jun 2013 21:45:49 +0200, a écrit : To save space I use dd to create a sparse file. Is that not supported on hurd, or what? It is supported, but large file support is still sketchy for now. Ok, I guess it is the 2GiB size that is problematic and not the sparseness. Yes. I assume that problem is unlikely to change in the near future, Yes. so what about modifying the unit test to test if it runs on hurd and just exit with success in that case? Or a special non-failing skipped value. Samuel Hi, I just released 1.3.4 which has a generic workaround in the unit test script which makes the test pass also on Hurd, without having to disable it. I tested it with kvm as adviced on http://ftp.debian-ports.org/debian-cd/hurd-i386/current/YES_REALLY_README.txt and it worked as expected. We will se what the build daemons say :-) Is there of any help to file a bug on dd? paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711793: rdfind: FTBFS on hurd-i386
2013-06-17 13:50, Samuel Thibault skrev: Hello, Paul Dreik, le Mon 10 Jun 2013 20:02:53 +0200, a écrit : As soon as I release the next version 1.3.3, this bug can be closed. Do you have an ETA for this? Not having rdfind on hurd-i386 is a blocker for being able to build the libc, which is kind of problematic :) Otherwise, Takaki, maybe we could include the upstream patch already without waiting for the upstream release? Samuel I have something better than an ETA, namely a release :-) Here is the link: http://rdfind.pauldreik.se/rdfind-1.3.3.tar.gz Please let me hear if there are any problems. Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711793: rdfind: FTBFS on hurd-i386
2013-06-17 13:50, Samuel Thibault skrev: Hello, Paul Dreik, le Mon 10 Jun 2013 20:02:53 +0200, a écrit : As soon as I release the next version 1.3.3, this bug can be closed. Do you have an ETA for this? Not having rdfind on hurd-i386 is a blocker for being able to build the libc, which is kind of problematic :) Otherwise, Takaki, maybe we could include the upstream patch already without waiting for the upstream release? Samuel Hi, thanks Takaki for being so quick with updating the .deb. The build seems to be fine now but the unit test fails! Seems like dd does not like the arguments. From https://buildd.debian.org/status/fetch.php?pkg=rdfindarch=hurd-i386ver=1.3.3-1stamp=1371583441 checking for mktemp /testcases/largefilesupport.sh debug: temp dir is /tmp/rdfindtestcases.d.SHgr6q4TaPO2 dd: failed to truncate to 2147483648 bytes in output file `sparse-file1': Invalid argument The same thing works as expected on the other architectures listed on https://buildd.debian.org/status/package.php?p=rdfind I do not know why or how to trouble shoot it. Never Hurd of it :-). What the test tries to do is to create a file which is slightly bigger than what caused trouble on x86 earlier. To save space I use dd to create a sparse file. Is that not supported on hurd, or what? I guess one possibility is to just disable the unit test for hurd but it seems like a better idea to understand why dd fails instead. paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711793: rdfind: FTBFS on hurd-i386
2013-06-18 22:14, Samuel Thibault skrev: Paul Dreik, le Tue 18 Jun 2013 21:45:49 +0200, a écrit : To save space I use dd to create a sparse file. Is that not supported on hurd, or what? It is supported, but large file support is still sketchy for now. Samuel Ok, I guess it is the 2GiB size that is problematic and not the sparseness. I assume that problem is unlikely to change in the near future, so what about modifying the unit test to test if it runs on hurd and just exit with success in that case? something like switching on the output from uname or so. or possibly disabling the unit test on hurd-i386? I do not know what you think is the easiest way forward. It would be nice to see this bug 711973 go away so libc can be built. paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711793: rdfind: FTBFS on hurd-i386
Hi, this is already solved in the (yet not released) next version. I received a patch from another user (I prefer not to name people publicly before having asked them first), renaming the offending structure members. While your suggested patch is shorter, I prefer to use preprocessor macros as little as possible. As soon as I release the next version 1.3.3, this bug can be closed. (Does it close automagically because it is a FTBFS which can be automatically detected?) Thanks anyway! Paul 2013-06-09 23:19, Svante Signell skrev: Source: rdfind Version: 1.3.2-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, Currently [1], rdfind fails to compile on GNU/Hurd. (rdfind is a build-dependency of glibc since 2.17-4.) The build failure is due to that st_dev is used in struct Fileinfostat in Fileinfo.cc, as defined in Fileinfo.hh. On GNU/Hurd st_dev is defined as st_fsid which is reflected by inclusion of sys/stat.h. That file is included in Fileinfo.cc but not in Fileinfo.hh. By simply defining st_dev as st_fsid in Fileinfo.hh the problem is resolved, see the attached patch. Thanks! [1]https://buildd.debian.org/status/fetch.php?pkg=rdfindarch=hurd-i386ver=1.3.2-1stamp=1367901858 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687135: omake has no man page
Package: omake Version: 0.9.8.5-3-8 Severity: minor man omake does not show a man page, not even one which points to some other source of documentation. I guess this violates the debian policy, section 12.1. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=sv_SE.utf8, LC_CTYPE=sv_SE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages omake depends on: ii libc6 2.13-35 ii libfam0 2.7.0-17 ii libncurses5 5.9-10 ii libreadline6 6.2-8 Versions of packages omake recommends: ii omake-doc 0.9.8.5-3-8 omake 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#667350: give-back for rdfind on s390
Hi, 1) I do not understand what the problem is. the build log I can find, on https://buildd.debian.org/status/fetch.php?pkg=rdfindarch=s390ver=1.3.1-1stamp=1336438441 shows a cryptic error. 2) is this related to gcc 4.7? the link in 1) says something about illegal seek and perl. 3) what does give-back mean? does it mean the package will be removed from all archs unless s390 starts working? paul On 2012-07-07 22:31, Salvatore Bonaccorso wrote: Looking at some RC bugs for wheezy I have noticed that rdfind did not migrated to testing for s390. I have asked for a give-back on it. Regards, Salvaotre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671454: bug not present anymore
The gnome-panel package has been updated, and the bug is not present anymore. This bug can be closed. Thank you, Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667350: rdfind 1.3.1 released - now builds with gcc 4.7
Hi, I have now also tested the patch on Wheezy and Mac OS X. It works fine. I released version 1.3.1 with the patch included (the only change). See http://rdfind.pauldreik.se/ to get the new version. Thanks, Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671456: kde-plasma-desktop: Can not move windows between screens in dual monitor setup
Package: kde-plasma-desktop Version: 5:74 Severity: normal Dear Maintainer, * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? Standard install of kde-plasma-desktop. I have two screens of equal size configured with aticonfig --initial=dual-head which works as expected (can move the mouse between the screens). * What was the outcome of this action? I can not move windows between the two screens. Starting an application puts the window in the left screen, and I can not drag it to the right screen. I turned off the maximize/alignment magic that happens when you come close to a screen border while dragging windows. * What outcome did you expect instead? The window to be moved. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kde-plasma-desktop depends on: ii kde-baseapps4:4.7.4-2 ii kde-runtime 4:4.7.4-2 ii kde-workspace 4:4.7.4-2 ii plasma-desktop 4:4.7.4-2+b1 ii udisks 1.0.4-5 ii upower 0.9.15-3 Versions of packages kde-plasma-desktop recommends: ii kdm 4:4.7.4-2+b1 ii xserver-xorg 1:7.6+12 Versions of packages kde-plasma-desktop suggests: pn kde-l10n none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671458: kde-plasma-desktop: bouncing cursor displays on the wrong screen in dual screen setup
Package: kde-plasma-desktop Version: 5:74 Severity: minor Dear Maintainer, I have a dual screen setup, set up with aticonfig --initial=dual-head. When opening an application, the cursor shows an animation of a bouncing to signal that it is busy. This is expected. However, the animation shows up on the wrong screen. If my screen is X pixels wide, the animation shows up displaced X pixels offset in horizontal direction. I expect the animation to be shown directly by the cursor. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kde-plasma-desktop depends on: ii kde-baseapps4:4.7.4-2 ii kde-runtime 4:4.7.4-2 ii kde-workspace 4:4.7.4-2 ii plasma-desktop 4:4.7.4-2+b1 ii udisks 1.0.4-5 ii upower 0.9.15-3 Versions of packages kde-plasma-desktop recommends: ii kdm 4:4.7.4-2+b1 ii xserver-xorg 1:7.6+12 Versions of packages kde-plasma-desktop suggests: pn kde-l10n none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667350: suggested patch for debian/ubuntu, should work for other systems too
Hi,
please try the suggested patch. The change is minimal so it should work
for macports and cygwin too, but I have not tried the patch on those
systems.
I verified that the patch worked on the following configurations:
*ubuntu 11.10, using the 1.3.0 debian package and gcc-snapshot package
which reports as
$gcc --version
(Ubuntu/Linaro 20111010-0ubuntu1) 4.7.0 20111010 (experimental) [trunk
revision 179769]
*same setup as above, with the default gcc (gcc (Ubuntu/Linaro
4.6.1-9ubuntu3) 4.6.1)
*debian squeeze (gcc 4.4.5), using the original source.
Please give me feedback that it works for you too, and I will release a
new version of rdfind with the change.
Thanks,
Paul (the rdfind author)
Index: Fileinfo.hh
===
--- Fileinfo.hh (revision 762)
+++ Fileinfo.hh (arbetskopia)
@@ -11,10 +11,13 @@
#define Fileinfo_hh
-
+//c++ headers
#include iostream //for cout etc.
#include cstring
+//os specific headers
+#include sys/types.h //for off_t and others.
+
using std::cout;
using std::endl;
@@ -62,7 +65,7 @@
};
//to store info about the file
- typedef off_t filesizetype;
+ typedef off_t filesizetype; //defined in sys/types.h
struct Fileinfostat {
filesizetype st_size;//size
unsigned long st_ino;//inode
Index: Fileinfo.cc
===
--- Fileinfo.cc (revision 762)
+++ Fileinfo.cc (arbetskopia)
@@ -14,6 +14,7 @@
#include iostream//for cout etc
#include sys/stat.h//for file info
#include errno.h//for errno
+#include unistd.h//for unlink etc.
#include Checksum.hh //checksum calculation
Bug#667350: work is in progress
Hi, thanks for finding this upcoming error. I have a working patch (using package gcc-snapshot on ubuntu 11.10, reports as gcc version 4.7.0 20111010 (experimental) [trunk revision 179769] (Ubuntu/Linaro 20111010-0ubuntu1) Hopefully I will apply the changes tonight or in a few days, I just want to check them properly first to avoid creating trouble on other systems/compilers. Paul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
