Bug#1056193: closed by Debian FTP Masters (reply to Patrick Matthäi ) (Bug#1056193: fixed in glusterfs 11.1-2)
Thanks for the fix! It seems to me that a warning about the situation needs to be added to the bookworm release notes, and/or apt-listchanges, because people might upgrade to bookworm as I recently did and find their configuration broken. The same would need to be done for trixie since anybody successfully running the bookworm version will find their configuration broken when upgrading to trixie.
Bug#1056193: glusterfs-client: GlusterFS SSL path changed without warning in Bookworm
Package: glusterfs-client Version: 10.3-5 Severity: normal Dear Maintainer, I have a bullseye GlusterFS cluster which uses SSL/TLS. Three machines have a replica of the data, and an additional one merely mounts the cluster without local storage for purposes of backing it up. I recently upgraded the backup machine to bookworm. Suddenly I was unable to mount the cluster. The key error in the logs was: E [socket.c:4405:ssl_setup_connection_params] 0-glusterfs: could not load our cert at /usr/lib/ssl/glusterfs.pem /usr/lib/ssl/ is a strange path. As far as I can tell, the correct path is /etc/ssl/. Creating three symlinks fixed the problem and allowed the cluster to be mounted: /usr/lib/ssl/glusterfs.ca -> /etc/ssl/glusterfs.ca /usr/lib/ssl/glusterfs.pem -> /etc/ssl/glusterfs.pem /usr/lib/ssl/glusterfs.key -> /etc/ssl/glusterfs.key Taking another look at the apt-listchanges output for the upgrade, there is nothing from any gluster package. This leads me to believe that the changing of this path was unintentional and is a bug. Not sure what's the best thing to do about it at this point, since fixing it would break people's existing bookworm configurations. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 glusterfs-client depends on: ii glusterfs-common 10.3-5 ii libc6 2.36-9+deb12u3 ii python3 3.11.2-1+b1 glusterfs-client recommends no packages. glusterfs-client suggests no packages. -- no debconf information
Bug#1037063: libxml-libxml-perl: Seemingly incorrect handling of escaped characters in patterns
Thanks very much, and apologies for my flawed analysis. It's good to know this will be fixed in bookworm. We're not going to be able to upgrade immediately so it would be nice if it could be fixed in bullseye, but I understand if that isn't the decision.
Bug#1037063: libxml-libxml-perl: Seemingly incorrect handling of escaped characters in patterns
Package: libxml-libxml-perl
Version: 2.0134+dfsg-2+b1
Severity: normal
Dear Maintainer,
I use XML::LibXML::Reader to work with files that validate against the Library
of Congress's MARCXML Schema, available here:
https://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd
That schema includes a pattern:
[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}
or, with the XML escaping processed:
[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}
That regex requires a single character, any one of a long list of allowable
characters. Note how three of the characters require escaping because they
would have meaning in the regex itself: the two square brackets [ and ], and
the backslash \.
An online XML Schema validator that I found with a quick search:
https://www.liquid-technologies.com/online-xsd-validator
shows that those three characters are valid. The problem is that
XML::LibXML::Reader seems to believe that they are not.
I wrote a simple test script, validate.pl:
---
#!/usr/bin/perl
use strict;
use warnings;
use File::Slurp;
use XML::LibXML::Reader;
my ($xml_path, $xsd_path) = @ARGV;
my %parameters = (
'location'=>$xml_path,
'Schema'=>XML::LibXML::Schema->new(string=>scalar(read_file($xsd_path))),
);
my $reader = XML::LibXML::Reader->new(%parameters);
while($reader->read())
{}
print "Finished reading; document must be valid.\n";
---
Along with a basic XML Schema file, test.xsd:
---
http://www.w3.org/2001/XMLSchema";>
---
and a VERY basic XML file, test.xml:
---
---
Running:
$ perl validate.pl test.xml test.xsd
results in:
test.xml:1: Schemas validity error : Element 'root', attribute 'code': [facet
'pattern'] The value '[' is not accepted by the pattern
'[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}'.
I believe that value in fact should match that pattern. The online schema
validator from earlier validates this pair of files. If you replace the data
in the "code" attribute with any of the other characters, validation passes.
It only fails for the three characters that are escaped.
-- System Information:
Debian Release: 11.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 libxml-libxml-perl depends on:
ii libc6 2.31-13+deb11u6
ii libxml-namespacesupport-perl 1.12-1.1
ii libxml-sax-perl 1.02+dfsg-1
ii libxml2 2.9.10+dfsg-6.7+deb11u4
ii perl 5.32.1-4+deb11u2
ii perl-base [perlapi-5.32.0]5.32.1-4+deb11u2
libxml-libxml-perl recommends no packages.
libxml-libxml-perl suggests no packages.
-- no debconf information
Bug#1034770: mariadb-server-10.5: Fix for MDEV-29988 (part of 10.5.19) needs to be in stable
Package: mariadb-server-10.5 Version: 1:10.5.18-0+deb11u1 Severity: important X-Debbugs-Cc: x...@charbonnet.com, t...@security.debian.org Dear maintainer, The update in bullseye from 10.5.15 to 10.5.18 on December 4, 2022 contained a major performance problem for some workloads. It causes my DNS server running PowerDNS with a MariaDB backend to run out of memory. This was reported in Debian Bug 1027337: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027337 and fixed by putting 10.5.19 into unstable. However, I (and presumably others?) run stable for my DNS servers, and I'm still stuck on 10.5.15. If anything could be done I would appreciate it. Thanks. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-21-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-server-10.5 depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.77 ii galera-4 26.4.11-0+deb11u1 ii gawk 1:5.1.0-1 ii iproute2 5.10.0-4 ii libc6 2.31-13+deb11u5 ii libdbi-perl 1.643-3+b1 ii libpam0g 1.4.0-9+deb11u1 ii libssl1.1 1.1.1n-0+deb11u4 ii libstdc++610.2.1-6 ii lsb-base 11.1.0 ii lsof 4.93.2+dfsg-1.1 ii mariadb-client-10.5 1:10.5.18-0+deb11u1 ii mariadb-common1:10.5.18-0+deb11u1 ii mariadb-server-core-10.5 1:10.5.18-0+deb11u1 ii passwd1:4.8.1-1 ii perl 5.32.1-4+deb11u2 ii procps2:3.3.17-5 ii psmisc23.4-2 ii rsync 3.2.3-4+deb11u1 ii socat 1.7.4.1-3 ii zlib1g1:1.2.11.dfsg-2+deb11u2 Versions of packages mariadb-server-10.5 recommends: ii libhtml-template-perl 2.97-1.1 Versions of packages mariadb-server-10.5 suggests: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-2 pn mariadb-test pn netcat-openbsd -- debconf-show failed
Bug#1027337: [debian-mysql] Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18
Faustin, Thanks for looking into this, and for your work packaging MariaDB for Debian. It looks to me like https://jira.mariadb.org/browse/MDEV-29988 is very likely to be the issue we're seeing. Fortunately (if I'm interpreting upstream's JIRA correctly), it looks like a fix exists and will be included in 10.5.19. From their release history, 10.5.19 can be expected in early February. Probably what I will do is downgrade all machines to 10.5.15 and look forward to the Debian package of 10.5.19, which hopefully will not be long after the upstream release.
Bug#1027337: "Starting cleanup"
Every few seconds (at least in my configuration), PDNS runs database queries to see which domains need refreshing. After running for a while with this problem, I can "catch" those queries (at least one of them) with SHOW PROCESSLIST. Excerpt: | 117 | pdns | localhost | pdns | Execute |0 | Starting cleanup | SELECT content,ttl,prio,type,domain_id,disabled,name,auth FROM records WHERE disabled=0 and type=? and name=? |0.000 | It seems to me that the longer this problem has been going on, the longer this query takes, at least the "starting cleanup" phase of it. I think that's why CPU usage climbs: the longer it goes, the longer this query takes and the more CPU is used to execute it. Caught a different one just now, also in phase "starting cleanup": | 128 | pdns | localhost | pdns | Execute |0 | Starting cleanup | SELECT content,ttl,prio,type,domain_id,disabled,name,auth FROM records WHERE disabled=0 and name=? and domain_id=? |0.000 | Yes, I can regularly "catch" many queries and they're always in state "starting cleanup". I went over to the machine that is not having this problem (because it's still on 10.5.15) and was able to catch one such query in "starting cleanup", and another in "commit". But it took maybe 25x more attempts to catch such a query than on the one with the problem. The queries on the "good" box finish very quickly, and they're slow on the "bad" box.
Bug#1027337: Update 2
At the 96 hour mark it hit 2.5GB, 64.6%. I reverted the seven MariaDB packages back to 10.5.15, and the problem has disappeared. mariadbd is holding steady at 135MB, 3.4%. I'm happy to help participate in figuring out what's going wrong.
Bug#1027337: Update
Some memory statistics. Uptime, resident memory size, and % of memory in the system for mariadbd: 30 hours -- 1.0g -- 26.7% 36 hours -- 1.2g -- 30.3% 54 hours -- 1.6g -- 41.5% Looks like a pretty linear progression of ~33MB/hour being leaked. This is on a system that previously had 512MB of total RAM. Now with 4GB it appears it'll be able to stay up about 5 days total. There were no configuration changes other than upgrading the packages.
Bug#1027337: mariadb-server-10.5: Huge increase in memory consumption (leak?) since upgrade from 10.5.15 to 10.5.18
Package: mariadb-server-10.5 Version: 1:10.5.18-0+deb11u1 Severity: important Dear Maintainer, I run a pair of nameservers, and after a recent round of minor software updates (see below for the complete list), mariadbd was OOM'd on both machines. These machines are minimal VMs: one has 512MB RAM, the other 1GB RAM. They've been running various versions of Debian flawlessly for many years. I temporarily upgraded the hardware to 4GB RAM on both in order to remove some urgency from the situation. It does appear that mariadbd's memory consumption is far higher than it should be, and slowly growing. There isn't too much being demanded of this database. Its only client is PowerDNS which runs locally. PowerDNS was not changed in this recent update. Please let me know what additional information I can provide. Thank you! Packages updated when the problem began: base-files:amd64 from 11.1+deb11u5 to 11.1+deb11u6 nftables:amd64 from 0.9.8-3.1 to 0.9.8-3.1+deb11u1 libnftables1:amd64 from 0.9.8-3.1 to 0.9.8-3.1+deb11u1 mariadb-common:all from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 libmariadb3:amd64 from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 mariadb-client-core-10.5:amd64 from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 mariadb-client-10.5:amd64 from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 mariadb-server-core-10.5:amd64 from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 mariadb-server-10.5:amd64 from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 libtasn1-6:amd64 from 4.16.0-2 to 4.16.0-2+deb11u1 nano:amd64 from 5.4-2+deb11u1 to 5.4-2+deb11u2 distro-info-data:all from 0.51+deb11u2 to 0.51+deb11u3 grub2-common:amd64 from 2.06-3~deb11u4 to 2.06-3~deb11u5 grub-pc:amd64 from 2.06-3~deb11u4 to 2.06-3~deb11u5 grub-pc-bin:amd64 from 2.06-3~deb11u4 to 2.06-3~deb11u5 grub-common:amd64 from 2.06-3~deb11u4 to 2.06-3~deb11u5 libksba8:amd64 from 1.5.0-3+deb11u1 to 1.5.0-3+deb11u2 linux-image-amd64:amd64 from 5.10.149-2 to 5.10.158-2 linux-libc-dev:amd64 from 5.10.149-2 to 5.10.158-2 mariadb-server:all from 1:10.5.15-0+deb11u1 to 1:10.5.18-0+deb11u1 -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-20-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-server-10.5 depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.77 ii galera-4 26.4.11-0+deb11u1 ii gawk 1:5.1.0-1 ii iproute2 5.10.0-4 ii libc6 2.31-13+deb11u5 ii libdbi-perl 1.643-3+b1 ii libpam0g 1.4.0-9+deb11u1 ii libssl1.1 1.1.1n-0+deb11u3 ii libstdc++610.2.1-6 ii lsb-base 11.1.0 ii lsof 4.93.2+dfsg-1.1 ii mariadb-client-10.5 1:10.5.18-0+deb11u1 ii mariadb-common1:10.5.18-0+deb11u1 ii mariadb-server-core-10.5 1:10.5.18-0+deb11u1 ii passwd1:4.8.1-1 ii perl 5.32.1-4+deb11u2 ii procps2:3.3.17-5 ii psmisc23.4-2 ii rsync 3.2.3-4+deb11u1 ii socat 1.7.4.1-3 ii zlib1g1:1.2.11.dfsg-2+deb11u2 Versions of packages mariadb-server-10.5 recommends: ii libhtml-template-perl 2.97-1.1 Versions of packages mariadb-server-10.5 suggests: ii mailutils [mailx] 1:3.10-3+b1 pn mariadb-test pn netcat-openbsd -- debconf information excluded
Bug#1013351: apticron: Ability to put the Debian version (eg, bullseye, or 11.3) in CUSTOM_SUBJECT
Package: apticron Version: 1.2.5 Severity: wishlist Dear Maintainer, It would be really handy to be able to indicate the specific Debian version (such as "bullseye" or "11.3") in the subject line of apticron emails. Currently there's DISTRIB_ID but it only says "Debian". Could that be updated to say "Debian 11.3" or "Debian bullseye"? Or perhaps a new variable could contain the more specific information? Thank you! -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-15-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 apticron depends on: ii apt 2.2.4 ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-2 ii bzip2 1.0.8-4 ii cron [cron-daemon] 3.0pl1-137 ii dpkg1.20.10 ii ucf 3.0043 Versions of packages apticron recommends: ii apt-listchanges 3.24 ii gpg 2.2.27-2+deb11u1 ii iproute2 5.10.0-4 apticron suggests no packages. -- no debconf information
Bug#1012570: libintl-xs-perl: gettext_xs never used
Package: libintl-xs-perl Version: 1.26-3 Severity: normal Dear Maintainer, I am migrating some systems from stretch to bullseye. These systems use Locale::TextDomain (part of libintl-perl) to do some translations. On bullseye I was getting some wrong responses, and the difference turned out to be that stretch is using the XS version but bullseye is not. I determined this by modifying Locale::Messages to warn about the status of the $no_xs variable. I note that the file gettext_xs.pm was removed for all architectures except mips between buster and bullseye. I copied /usr/lib/x86_64-linux-gnu/perl5/5.24/Locale/gettext_xs.pm from a stretch system to /usr/lib/x86_64-linux-gnu/perl5/5.32/Locale/gettext_xs.pm on bullseye, and now the XS version is being loaded successfully and I'm getting the right answers. Am I missing something in how libintl-xs-perl is supposed to be used? Thanks! *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-14-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 libintl-xs-perl depends on: ii libc6 2.31-13+deb11u3 ii libintl-perl1.26-3 ii perl5.32.1-4+deb11u2 ii perl-base [perlapi-5.32.1] 5.32.1-4+deb11u2 libintl-xs-perl recommends no packages. libintl-xs-perl suggests no packages. -- no debconf information
Bug#1001467: mariadb-10.5: Backport MariaDB 10.5.13 fixes? (Particularly MDEV-26712)
Source: mariadb-10.5 Version: 10.5.12-0+deb11u1 Severity: important Dear Maintainer, I've been investigating an issue where my MariaDB server ends up running away with the RAM on the machine. I believe it may be caused by MDEV-26712 [1], which is a memory leak bug. According to the MariaDB 10.5.13 release notes [2], this was fixed in that release. I see a number of other fixes as well. Are there any plans to backport these fixes to Bullseye, or to move Bullseye to 10.5.13? I should mention that I'm not 100% sure that this is the fix to my problem: apparently this problem applies to earlier versions as well, and I don't have this issue on earlier versions. So it may be something else. Regardless of my particular situation, the MariaDB in Bullseye does contain this bug that can consume any amount of RAM. [1] https://jira.mariadb.org/browse/MDEV-26712 [2] https://mariadb.com/kb/en/mariadb-10513-release-notes/ -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#991972: More information
[Sorry, Tomas, I just realized that earlier I replied only to you rather than to the whole list.] There is some Debian blessing of backports.org. When visiting the Debian webserver over http and asking for www.backports.org, the Debian webserver redirects the visitor to https://backports.debian.org/. It doesn't seem that there should be a difference in behavior between http://www.backports.org/ and https://www.backports.org/, but as it is, one works perfectly and the other fails spectacularly. I see the options as: a) Let backports.org die, which is mostly what you suggest. Shouldn't the Debian webserver should have any backports.org configuration removed from it? I believe would mean that visitors to http://www.backports.org/ will end up getting the Debian homepage. The owner of backports.org should be contacted so the domain could be removed, which I'd be glad to attempt. b) Configure the Debian webserver to acquire a certificate from Let's Encrypt for www.backports.org and configure it to redirect visitors to backports.debian.org just as the http:// version does. c) Leave things as they are, where http:// works and https:// doesn't. I just thought this was a weird situation. If you like it the way it is, it's fine by me. Thanks for your work on the Debian website! -Xan
Bug#991972: More information
Sorry, I should have checked this on more than one browser before reporting. For some reason my ancient Firefox profile, when I browse to "backports.org", redirects to https://www.backports.org/. Perhaps this was a cached permanent redirect, or something to do with HSTS. On a naive profile (with seemingly any browser), browsing to "backports.org" fails, because backports.org has no A record. Not terribly friendly but not a problem. It sounds like your browser has some memory that points backports.org to backports.debian.org. A naive browser has no way to return anything for https://backports.org/ or http://backports.org/. www.backports.org does have a CNAME record: it points to backports.debian.org, which seems to have the same IP address as debian.org. Browsing to http://www.backports.org/ is successful: the Debian webserver redirects the request to https://backports.debian.org/, and when accessed via that name, the Debian webserver correctly serves the backports page. However, when you browse to https://www.backports.org/ (note the secure protocol), that's when it breaks. The Debian webserver defaults to serving the Debian homepage, complete with the TLS certificate for debian.org. This causes a nasty security error in the browser, and if bypassed, results in the Debian homepage loading at https://www.backports.org/ rather than the Backports page. The only remaining mystery is why my Firefox profile is handling "backports.org" the way it is. I'm trying to figure out how to diagnose that, but it doesn't seem like there's much visibility to that kind of thing. It could be something that affects everybody who visited backports.org during a particular timeframe.
Bug#991972: backports.org invalid certificate
Package: www.debian.org Some muscle memory from a long time ago kicked in, and I browsed to backports.org instead of to backports.debian.org. backports.org now seems to serve the Debian homepage, and in the process triggers the browser's invalid certificate error, because the certificate is for www.debian.org. It seems to me that backports.org should redirect to backports.debian.org. I'm not sure why the Debian homepage would greet somebody visiting backports.org, but if that's desired, it should redirect to www.debian.org rather than simply serve its content. In either case backports.org should have its own proper certificate. Or backports.org could go away.
Bug#969091: pdns-backend-mysql: Queries calling stored procedures broken with recent MariaDB/MySQL
Hi Chris, On the pdns mailing list, it's been requested I file an issue in the GitHub repository. I've done so: https://github.com/PowerDNS/pdns/issues/9421 It includes detailed steps to reproduce. It really just boils down to setting one of the queries to use a stored procedure, eg: gmysql-basic-query=CALL basic_query(?, ?) Do the Debian tests include stored procedures? Or just regular SQL queries? -Xan
Bug#969091: pdns-backend-mysql: Queries calling stored procedures broken with recent MariaDB/MySQL
Package: pdns-backend-mysql
Version: 4.3.0-4+b3
Severity: important
Tags: upstream
X-Debbugs-Cc: x...@charbonnet.com
Dear Maintainer,
PowerDNS supports using stored procedures for its backend MySQL queries.
However, it seems
that when the database is MariaDB >= 10.2 (or MySQL >= 5.7), stored procedures
fail to work.
I have tested this on Stretch, using three different PowerDNS versions: 4.0.3
(from Stretch),
4.1.6 (from Buster), and 4.3.0 (from Bullseye), all compiled on Stretch. They
all have the
same behavior: on MariaDB 10.1, stored procedures work great. On MariaDB 10.2,
calls to
procedures which return any rows give the error "Could not bind parameters to
mysql
statement". The various versions of MariaDB came from the MariaDB Debian
repositories.
I have also tried this on a clean Bullseye test system, using the versions of
PowerDNS and
MariaDB which are native to Bullseye. Same problem. This is the system where
I'm running
reportbug.
I believe this other user on the pdns mailing list encountered this problem:
https://mailman.powerdns.com/pipermail/pdns-users/2020-July/026762.html
My reply failed to actually be a reply, but I also chimed in on the list:
https://mailman.powerdns.com/pipermail/pdns-users/2020-August/026810.html
The relevant code appears to be the following section. Unfortunately I don't
know enough
about using MySQL from C++ to be able to tell what to do differently. This is
where the
"Could not bind parameters" error is coming from.
#if MYSQL_VERSION_ID >= 50500
if (d_residx >= d_resnum) {
mysql_stmt_free_result(d_stmt);
while(!mysql_stmt_next_result(d_stmt)) {
if ((err = mysql_stmt_store_result(d_stmt))) {
string error(mysql_stmt_error(d_stmt));
releaseStatement();
throw SSqlException("Could not store mysql statement while
processing additional sets: " + d_query + string(": ") + error);
}
d_resnum = mysql_stmt_num_rows(d_stmt);
// XXX: For some reason mysql_stmt_result_metadata returns
NULL here, so we cannot
// ensure row field count matches first result set.
if (d_resnum > 0) { // ignore empty result set
if (d_res_bind != nullptr && (err =
mysql_stmt_bind_result(d_stmt, d_res_bind))) {
string error(mysql_stmt_error(d_stmt));
releaseStatement();
throw SSqlException("Could not bind parameters to mysql
statement: " + d_query + string(": ") + error);
}
d_residx = 0;
break;
}
mysql_stmt_free_result(d_stmt);
}
}
#endif
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 pdns-backend-mysql depends on:
ii libc62.31-2
ii libgcc-s110.1.0-6
ii libmariadb3 1:10.3.23-1
ii libstdc++6 10.1.0-6
ii pdns-server 4.3.0-4+b3
pdns-backend-mysql recommends no packages.
Versions of packages pdns-backend-mysql suggests:
pn default-mysql-server
-- no debconf information
Bug#924956: qt3d-opensource-src: Fractional HiDPI scaling causes serious artifacts in some QT applications
I'm very sorry for the error. I am running the latest Buster for everything. The problem I'm experiencing sounds an awful lot like the description of that bug, so I assumed the fix hadn't been implemented in Debian. If it has, then it must be a different problem. (Or the fix isn't complete, or something.) I've just confirmed that when I set the scaling to 1, the problem goes away. When I set the scaling to my preferred setting, 1.1, the problem is rampant.
Bug#924956: Image example
https://imgur.com/download/Diwa8qz
Bug#924956: qt3d-opensource-src: Fractional HiDPI scaling causes serious artifacts in some QT applications
Source: qt3d-opensource-src Severity: important Tags: newcomer Dear Maintainer, QT has had a bug which caused major artifacts in QT applications, for example Kate, Kwrite, Konsole, and probably many others. It only is an issue when non-integer scaling factors for HiDPI are used. At least for me, this makes Kate very difficult to use. The bug was fixed on this page: https://bugreports.qt.io/browse/QTBUG-66036 Comment #6 contains the fix, which is quite small. You may have to click the "X older comments" link to get this comment to appear. It was too late to make it into QT 5.11, sadly, but there is (or was?) talk of cherry-picking the patch into 5.11: https://phabricator.kde.org/T9244 If this patch could make it into Buster's QT, that would be fantastic. -- 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/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#889798: (Security) bugs in pdns in stretch
I installed pdns-server_4.0.3-1+deb9u3_amd64.deb and pdns-backend-mysql_4.0.3-1+deb9u3_amd64.deb and everything worked perfectly. Thanks!
Bug#889798: pdns-backend-mysql: Queries calling stored procedures break PowerDNS in weird ways
An update: versions 4.0.6 and 4.1.5 were released a few days ago. 4.1.5 does contain this fix, so that's the good news. If 4.1.5 makes buster (which I'm assuming it would), the fix would automatically be in buster and later versions of Debian. Unfortunately the fix seems to NOT have been included in 4.0.6. I don't know why that is the case. I'm guessing that means it won't make sense to apply the patch to the Debian version in stretch. For what it's worth, I've been running such a patched version with no trouble since February, and I suppose I'll just keep doing that until buster. Thanks for your work on PowerDNS in Debian!
Bug#889798: pdns-backend-mysql: Queries calling stored procedures break PowerDNS in weird ways
That's more than fair. I can keep an eye on when this code gets into an actual release, and some time after that, comment here that things are looking good (or that they're not). The risk I was attempting to minimize was the behavioral change. If people relied on the current behavior, then applying this fix to stable would be problematic. I'm arguing that that concern doesn't apply. As far as the risk of this fix introducing some other bug or otherwise having adverse affects, I'll defer entirely to your judgment. Seeing how this plays out upstream before making any changes to stable makes perfect sense.
Bug#889798: pdns-backend-mysql: Queries calling stored procedures break PowerDNS in weird ways
Package: pdns-backend-mysql Version: 4.0.3-1+deb9u2 Severity: important Tags: patch Dear Maintainer, PowerDNS versions 4.x (the versions in Jessie, Stretch, Buster, and Sid) fails to handle stored procedures. When a stored procedure is used as one of the PowerDNS queries, it works the first time, but subsequent queries return really weird results. It appears that these results are from some kind of cache, but they're simply broken. The troubleshooting described at this link mirrors my diagnostic process: https://github.com/PowerDNS/pdns/issues/6115 The fix: https://github.com/PowerDNS/pdns/pull/6134/files was merged 5 days ago into upstream. There has not yet been an upstream release containing this fix. Because it has been accepted upstream, I don't believe anything special needs to be done for Buster or Sid, other than keeping up with upstream. I'm asking you to consider updating the version in Stretch (and possibly the one in Jessie). While I don't believe this is a security issue, PowerDNS in these distributions is plainly broken when used with stored procedures. Nobody will be inconvenienced by this change in behavior, and it will allow PowerDNS to work as documented and intended. I successfully merged this patch into the Debian version of PowerDNS from Stretch for my own local use. It worked great. It would be really nice if the official package could include this fix. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (1000, 'stable'), (900, 'stable'), (750, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pdns-backend-mysql depends on: ii dbconfig-common2.0.8 ii dbconfig-mysql 2.0.8 ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u1 ii libgcc11:6.3.0-18 ii libmariadbclient18 10.1.26-0+deb9u1 ii libstdc++6 6.3.0-18 ii pdns-server4.0.3-1+deb9u2 ii ucf3.0036 ii zlib1g 1:1.2.8.dfsg-5 pdns-backend-mysql recommends no packages. Versions of packages pdns-backend-mysql suggests: pn default-mysql-server -- debconf information excluded
Bug#812884: gscan2pdf: Changing the resolution is not persistant
Am 15.05.2016 um 12:43 schrieb Jeffrey Ratcliffe: > This is nothing to do with gimp, but a problem with the file > > ~/.gscan2pdf > > Please rename it, or delete it, and start gscan2pdf again. I reinstalled the latest gscan2pdf-version from the yakkety repository which is 1.5.0 by now, renamed ~/.gscan2pdf and the programm is running just fine. Plus: the original issue is solved in this version of gscan2pdf. Changing the scanning resolution is now persistant. Thanks a lot for the support and the great application!
Bug#812884: gscan2pdf: Changing the resolution is not persistant
(Sorry for being so slow to cooperate on this bug. I only have access to
this computer from time to time.)
I installed gscan2pdf 1.4.0 from the Ubuntu yakkety repository and it
crashes as soon as I start the application. On the command line, I get:
> gscan2pdf
> Can't use string ("gimp %i") as an ARRAY ref while "strict refs" in use at
> /usr/bin/gscan2pdf line 4160.
> Perl exited with active threads:
> 2 running and unjoined
> 0 finished and unjoined
> 0 running and detached
Gimp is installed on the computer.
Bug#812884: gscan2pdf: Changing the resolution is not persistant
Am 29.01.2016 um 21:43 schrieb Jeffrey Ratcliffe: > As it is pure Perl, that would work. You could also take the version from > Debian testing or unstable. There are a couple of additionally dependencies > to fulfil, but you can find those there too. I tried to install the latest version manually from the Debian testing package. I started to upgrade the dependencies too, but soon got entangled in a net of dependencies and decided, I’d better roll back. I would have to upgrade so many packages manually, I fear I would endanger the stability of my productive machine. Is there no other way to test the latest version? As to using the PPA: I’m not shure if this would work, since it doesn’t include the latest perl etc. packages I need to run the latest gscan2pdf. What can I do?
Bug#812884: gscan2pdf: Changing the resolution is not persistant
In fact, I was only reporting the bug from my Ubuntu machine but I use gscan2pdf on a Debian machine. I noticed now that this reporting-from-the-other-computer was not very clever. I’m sorry about that. How do I try the most recent version of gscan2pdf in Debian? Can I also use the PPA?
Bug#812884: Wrong application version
Unlike specified in the initial report, I encountered the problem using gscan2pdf 1.2.6. (Happened because I used another computer for the report)
Bug#812884: gscan2pdf: Changing the resolution is not persistant
Package: gscan2pdf Version: 1.2.3-1 Severity: normal When I start gscan2pdf, the resolution for scanning is at 50. This is very low and I increase it every time I use the application. I’d like my choice to be the default value for the next time I start the application. This would save me the extra work of changing the resolution every single time. -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-76-generic (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 Versions of packages gscan2pdf depends on: ii imagemagick 8:6.7.7.10-6ubuntu3 ii libconfig-general-perl 2.52-1 ii libgoo-canvas-perl 0.06-1build3 ii libgtk2-ex-simple-list-perl 0.50-2 ii libgtk2-imageview-perl 0.05-1build3 ii libhtml-parser-perl 3.71-1build1 ii liblist-moreutils-perl 0.33-1build3 ii liblocale-gettext-perl 1.05-7build3 ii liblog-log4perl-perl 1.41-1.1ubuntu1 ii libpdf-api2-perl 2.020-2 ii libproc-processtable-perl0.50-1 ii libreadonly-perl 1.04-1 ii librsvg2-common 2.40.2-1 ii libsane-perl 0.05-2build1 ii libset-intspan-perl 1.19-1 ii libtiff-tools4.0.3-7ubuntu0.3 ii libtry-tiny-perl 0.19-1 ii perlmagick 8:6.7.7.10-6ubuntu3 ii sane-utils 1.0.23-3ubuntu3.1 Versions of packages gscan2pdf recommends: ii cuneiform 1.1.0+dfsg-4 ii djvulibre-bin 3.5.25.4-3 ii gocr 0.49-1 ii libgtk2-ex-podviewer-perl 0.18-1 ii sane 1.0.14-9 ii unpaper0.4.2-1 ii xdg-utils 1.1.0~rc1-2ubuntu7.1 gscan2pdf suggests no packages.
Bug#733820: pound: Add libgoogle-perftools-dev to build-dependencies
Package: pound Version: 2.6-2 Severity: wishlist Is it possible to add libgoogle-perftools-dev to the build-dependencies for pound? This was briefly the case back in 2008, but was backed out because libgoogle-perftools-dev didn't look like it would be in testing. It's certainly there now, and has even been in stable for quite a long time (at least since Squeeze). Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#419209: lvm2: Hangs during snapshot creation
Package: lvm2 Version: 2.02.95-4 Followup-For: Bug #419209 Hello, It looks like this bug still exists in wheezy. I use LVM to keep snapshots of the database partitions on my backup servers. Every half hour, a new snapshot is created (and, usually, an old one destroyed). This worked perfectly in squeeze. A few days ago, I configured a new backup server with a fresh install of wheezy, and I'm seeing what I believe are the symptoms of this bug. Sometimes the snapshot creation goes just fine, but sometimes lvcreate hangs, blocked for I/O forever. I have to use sysrq to force the system to reboot. There's no RAID involved. (The system is on an md RAID1 mirror, but the LVM volume lives on /dev/sdb1, straight-up.) I've tried ext4 and ext3. I've tried creating the snapshot with the partition mounted and with the partition unmounted. I've tried a different hard drive. Whatever I try, lvcreate hangs very regularly. I can do whatever experiments on this system might be helpful. Please let me know how I can help to track this down. Thanks! -Xan -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 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 lvm2 depends on: ii dmsetup 2:1.02.74-4 ii initscripts 2.88dsf-34 ii libc6 2.13-38 ii libdevmapper-event1.02.1 2:1.02.74-4 ii libdevmapper1.02.12:1.02.74-4 ii libreadline5 5.2+dfsg-1 ii libudev0 175-7 ii lsb-base 4.1+Debian8 lvm2 recommends no packages. lvm2 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#652080: mirrors: please, provide https mirror
Package: mirrors Severity: normal I installed apt-transport-https but when I change http with https in my official sources.list, apt does not find it. I suspect that it's because no https mirror is avaliable Please, provide https mirror, like: deb https://ftp.debian.org/debian/ stable main deb-src https://ftp.debian.org/debian/ stable main deb https://security.debian.org/ stable/updates main deb-src https://security.debian.org/ stable/updates main Without such mirror, must of effort of apt-transport-https is not useful. Thanks a lot, Xan. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 2.6.32-5-ixp4xx Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to ca_ES.UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#119888: Sources....
In official changelog http://www.acme.com/software/thttpd/#releasenotes there is no notice about it. Where is the source of this change? Thanks a lot, Xan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#119888: Patch for fix that
In this reference [http://wiki.nginx.org/ThttpdRealIP] is avaliable a
patch for that thttpd respect the X-forward-for header (originaly posted
by Daniel Clemente [http://www.danielclemente.com/amarok/ip_real.txt] ).
I would like you apply this patch. I add now:
--- thttpd-2.25b/libhttpd.c 2003-12-25 20:06:05.0 +0100
+++ thttpd-2.25b-patched/libhttpd.c 2005-01-09 00:26:04.867255248 +0100
@@ -2207,6 +2207,12 @@
if ( strcasecmp( cp, "keep-alive" ) == 0 )
hc->keep_alive = 1;
}
+ else if ( strncasecmp( buf, "X-Forwarded-For:", 16 ) == 0 )
+ { // Use real IP if available
+ cp = &buf[16];
+ cp += strspn( cp, " \t" );
+ inet_aton( cp, &(hc->client_addr.sa_in.sin_addr) );
+ }
#ifdef LOG_UNKNOWN_HEADERS
else if ( strncasecmp( buf, "Accept-Charset:", 15 ) == 0 ||
strncasecmp( buf, "Accept-Language:", 16 ) == 0 ||
I CC acme labs software for confirming this bug is _not_ fixed in
version 2.22 (or any later version) of thttpd (in
http://acme.com/software/thttpd/#releasenotes it seems it's not) and
Daniel Clemente for knowing your work is helpful for others ;-) (I hope
you're not "molesto", Daniel)
Thanks a lot,
Xan.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552148: PPA avaliable in ubuntu
Hi, There is a PPA avaliable in ubuntu [see https://bugs.launchpad.net/debian/+bug/459918]. Perhaps we could do a synergy from that. Thanks, Xan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552296: acknowledged by developer (closing 552296)
En/na Vincent Danjean ha escrit: Xan wrote: Sorry. I have not enough skills for doing that. I will thank if anyone could do that. This kind of script would be very critical (can lead to unbootable system) and there are *lots* of ways users can change their /etc/fstab and /boot/grub/menu.lst It is relatively easy for a installer starting from scratch to write an initial configuration with UUID. It is very difficult to write a conversion script that will work in any case. Yes, I supose it. For that, I just think of informative dialog pointing to docs. But, perhaps, it would be possible to print a warning pointing on docs explaining how to do the transition when such a situation is detected ? [this would also apply to the /dev/hd -> /dev/sd transition] this is exactly what I said. The points of that documentation should (?) be (please add what you want): - Explain the situation: the possible trouble with path fstab when upgrading the kernel and that it does not happen if fstab entries are UUID. - Explain how to do this change: - ls /dev/disk/by-uuid/ -alh and substitute the corresponding path to UUID=[the UUID] - for swap, perhaps blkid /dev/sdX for seeing UUID. - rebooting Does anyone want to do this doc. Sorry but the english is not my native language (notice that ;-)). When this documentation is done, I'm volunteer for translating to spanish and catalan, if it applies. Regards, Xan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552296: acknowledged by developer (closing 552296)
En/na Martin Michlmayr ha escrit: * Xan [2009-10-29 19:50]: It cannot be fixed in lenny, Why? What's the technical reason? What do you think of put an optional script when updating kernel that tests if fstab has UUID and suggests, before upgrade kernel, to change fstab entries to UUID entries (it points to some documentation of how to do that)? Are you willing to implement this script? Sorry. I have not enough skills for doing that. I will thank if anyone could do that. Regards, Xan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552296: acknowledged by developer (closing 552296)
En/na Martin Michlmayr ha escrit: * Xan [2009-10-29 17:40]: Good news, Martin. So in squeeze there is no a bug. But what happens with this bug in lenny?. I don't know the debian bug policy. What do you do in that case with this bug? It's a wontfix bug, invalid? pending? I'm not enter here, because really it's a technical discussion (debian bugs policy) because in squeeze there is no such bug. It cannot be fixed in lenny, Why? What's the technical reason? What do you think of put an optional script when updating kernel that tests if fstab has UUID and suggests, before upgrade kernel, to change fstab entries to UUID entries (it points to some documentation of how to do that)? but I'll add a troubleshooting section to the NSLU2 page with information about this problem. Great for doing that, Martin. Can you put the link for informational things? Is it that: http://www.nslu2-linux.org/wiki/Debian/TroubleShooting ? Thanks, Xan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552296: acknowledged by developer (closing 552296)
En/na Martin Michlmayr ha escrit: * Xan [2009-10-29 16:05]: So, perhaps d-i should put UUID in /etc/fstab by default intead of dev path. So is it a d-i bug? d-i for squeeze will use UUIDs. Good news, Martin. So in squeeze there is no a bug. But what happens with this bug in lenny?. I don't know the debian bug policy. What do you do in that case with this bug? It's a wontfix bug, invalid? pending? I'm not enter here, because really it's a technical discussion (debian bugs policy) because in squeeze there is no such bug. Thanks a lot for triaging, Xan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552296: acknowledged by developer (closing 552296)
What do you think that "fixed lately"? Is this bug fixed? Why not change kernel as package which has a bug for d-i? It can't be fixed in the kernel; it is an inherent problem with the design of USB. Ben. So, perhaps d-i should put UUID in /etc/fstab by default intead of dev path. So is it a d-i bug? Xan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552296: acknowledged by developer (closing 552296)
En/na Bastian Blank ha escrit: On Tue, Oct 27, 2009 at 01:24:58PM +0100, Xan wrote: Ben, it's a bug. At least formally. Maybe, but not in the kernel. The kernel never documented this values to be stable. Yes, not in the kernel. I'm in agreement A capricious swap between harddrives that hangs the system it's a bug I think, overall if the debian installer assign mounts in /etc/fstab by device and not by label or UUID. So it is a bug in the installer, and fixed lately. What do you think that "fixed lately"? Is this bug fixed? Why not change kernel as package which has a bug for d-i? Regards, Xan, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552296: acknowledged by developer (closing 552296)
On Mon, 2009-10-26 at 14:40 +0100, Pierre Maziere wrote: > It seems that the update switched the /dev/sda and /dev/sdb which > explains the freeze during the boot sequence. > I switched the usb plugs and everything is now back to normal. > sorry for the noise You should not expect that USB disks will be found and assigned names in any particular order. You should specify partitions by label or UUID instead of device name. Ben. Ben, it's a bug. At least formally. A capricious swap between harddrives that hangs the system it's a bug I think, overall if the debian installer assign mounts in /etc/fstab by device and not by label or UUID. Or the d-i mounts the devices by UUID (so bug in d-i) or this is a bug in the updating the kernel (perhaps it's not the kernel bug itself but yes the process of updating) But, don't mind me. I'm just a desktop user (ironicaly) ;-) Regards, Xan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552296: Upgrading from linux-image-2.6.26-2-ixp4xx version 2.6.26-17lenny2 to version 2.6.26-19 hangs nslu2. After upgrading and rebooting the slug has only ethernet light in red (fixed, not alter
Package: linux-image-2.6.26-2-ixp4xx Version: 2.6.26-19 Severity: normal After upgrading to version 2.6.26-19 of linux-image-2.6.26-2-ixp4xx kernel and rebooting the slug hangs. It has only ethernet light in red (fixed, not alternating). I could not access via ssh The boot seems to not complete. The logs are empty I could not triage the causes of the bug because I have not serial port. I have to reinstall slug in order to restore complete debian system. Mailing list discussion: http://lists.debian.org/debian-arm/2009/10/msg00035.html -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 2.6.26-2-ixp4xx Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to ca_ES.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-2-ixp4xx depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo linux-image-2.6.26-2-ixp4xx recommends no packages. Versions of packages linux-image-2.6.26-2-ixp4xx suggests: pn fdutils(no description available) pn linux-doc-2.6.26 (no description available) -- debconf information: linux-image-2.6.26-2-ixp4xx/postinst/old-dir-initrd-link-2.6.26-2-ixp4xx: true linux-image-2.6.26-2-ixp4xx/prerm/removing-running-kernel-2.6.26-2-ixp4xx: true linux-image-2.6.26-2-ixp4xx/preinst/lilo-has-ramdisk: shared/kernel-image/really-run-bootloader: true linux-image-2.6.26-2-ixp4xx/preinst/elilo-initrd-2.6.26-2-ixp4xx: true linux-image-2.6.26-2-ixp4xx/prerm/would-invalidate-boot-loader-2.6.26-2-ixp4xx: true linux-image-2.6.26-2-ixp4xx/postinst/old-initrd-link-2.6.26-2-ixp4xx: true linux-image-2.6.26-2-ixp4xx/postinst/old-system-map-link-2.6.26-2-ixp4xx: true linux-image-2.6.26-2-ixp4xx/postinst/depmod-error-2.6.26-2-ixp4xx: false linux-image-2.6.26-2-ixp4xx/preinst/abort-overwrite-2.6.26-2-ixp4xx: linux-image-2.6.26-2-ixp4xx/postinst/create-kimage-link-2.6.26-2-ixp4xx: true linux-image-2.6.26-2-ixp4xx/preinst/abort-install-2.6.26-2-ixp4xx: linux-image-2.6.26-2-ixp4xx/preinst/initrd-2.6.26-2-ixp4xx: linux-image-2.6.26-2-ixp4xx/preinst/failed-to-move-modules-2.6.26-2-ixp4xx: linux-image-2.6.26-2-ixp4xx/postinst/bootloader-error-2.6.26-2-ixp4xx: linux-image-2.6.26-2-ixp4xx/preinst/lilo-initrd-2.6.26-2-ixp4xx: true linux-image-2.6.26-2-ixp4xx/preinst/overwriting-modules-2.6.26-2-ixp4xx: true linux-image-2.6.26-2-ixp4xx/postinst/depmod-error-initrd-2.6.26-2-ixp4xx: false linux-image-2.6.26-2-ixp4xx/preinst/already-running-this-2.6.26-2-ixp4xx: linux-image-2.6.26-2-ixp4xx/postinst/kimage-is-a-directory: linux-image-2.6.26-2-ixp4xx/preinst/bootloader-initrd-2.6.26-2-ixp4xx: true linux-image-2.6.26-2-ixp4xx/postinst/bootloader-test-error-2.6.26-2-ixp4xx: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552148: RFP: hiawatha -- A secure and advanced webserver
Package: wnpp Severity: wishlist * Package name: hiawatha Version : 6.17.1 Upstream Author : Hugo Leisink * URL : www.hiawatha-webserver.org * License : GPL Programming Lang: C Description : A secure and advanced webserver Please, put the hiawatha web server [http://www.hiawatha-webserver.org] in debian repositories. It's a good web server and secure. Thanks, Xan. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: armel (armv5tel) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516970: [pkg-wpa-devel] Bug#516970: It also behaves equal with rt73.
En/na Kel Modderman ha escrit: On Tuesday 04 August 2009 01:51:42 Xan wrote: Thanks, Kel. Now I get this error: # ifconfig wlan0 up r...@caixa:~# ifup wlan0 wpa_supplicant: /sbin/wpa_supplicant daemon failed to start run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1 What are the exactly steps I have to do with put up the wlan0? Perhaps a newbee question, but do I really duplicate steps? allow-hotplug wlan0 iface wlan0 inet static wpa-conf /path/to/conf ... That is all the wpa_supplicant related configuration required in the wlan0 stanza. See /usr/share/doc/wpasupplicant/README* Kel. Yes, This allow-hotplug wlan0 iface wlan0 inet static address 172.26.0.3 netmask 255.255.0.0 network 172.26.0.0 broadcast 172.26.255.255 gateway 172.26.0.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 80.58.61.250 80.58.61.254 dns-search example.org wpa-ssid 314159 wpa-driver wext wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf works. Thank you very much, Kel. Xan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516970: [pkg-wpa-devel] Bug#516970: It also behaves equal with rt73.
En/na Kel Modderman ha escrit:
On Monday 03 August 2009 08:51:30 Xan wrote:
So, it seems it's a confirmed bug of wpasupplicant.
Please, fix it
Xan.
PS:
The problem:
# ifconfig wlan0 up
r...@caixa:/var/log# ifup wlan0
Line 4: unknown network field 'ssid '.
Line 8: failed to parse network block.
Failed to read or parse configuration
'/etc/wpa_supplicant/wpa_supplicant.conf'.
Failed to bring up wlan0.
and
cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 172.26.0.2
netmask 255.255.0.0
network 172.26.0.0
broadcast 172.26.255.255
gateway 172.26.0.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 80.58.61.250 80.58.61.254
dns-search example.org
# 2009-07. The secondary network interface
allow-hotplug wlan0
iface wlan0 inet static
address 172.26.0.3
netmask 255.255.0.0
network 172.26.0.0
broadcast 172.26.255.255
gateway 172.26.0.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 80.58.61.250 80.58.61.254
dns-search example.org
wpa-ssid 314159
wpa-driver wext
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#pre-up wpa_supplicant -Bw -Dwext -iethX -c/etc/wpa_supplicant.conf
pre-up wpa_supplicant -D wext -B -i wlan0 -c
/etc/wpa_supplicant/wpa_supplicant.conf
post-down killall -q wpa_supplicant
and
# cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
network={
ssid = "314159"
This is wrong syntax, remove the whitespace around the = sign.
Thanks a lot.
proto=WPA
key_mgmt=WPA-PSK
psk="enunlugardelamanchadecuyonombrenopuedoacordarme"
}
Previously, I had not this problem with the same configuration files.
I doubt it, maybe lucky because you seem to configure wpa_supplicant
twice in /etc/network/interfaces (via pre-up and via wpa-* ifupdown hook).
Thanks, Kel.
Thanks, Kel.
Now I get this error:
# ifconfig wlan0 up
r...@caixa:~# ifup wlan0
wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1
What are the exactly steps I have to do with put up the wlan0? Perhaps a
newbee question, but do I really duplicate steps?
Xan.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516970: It also behaves equal with rt73.
So, it seems it's a confirmed bug of wpasupplicant.
Please, fix it
Xan.
PS:
The problem:
# ifconfig wlan0 up
r...@caixa:/var/log# ifup wlan0
Line 4: unknown network field 'ssid '.
Line 8: failed to parse network block.
Failed to read or parse configuration
'/etc/wpa_supplicant/wpa_supplicant.conf'.
Failed to bring up wlan0.
and
cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 172.26.0.2
netmask 255.255.0.0
network 172.26.0.0
broadcast 172.26.255.255
gateway 172.26.0.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 80.58.61.250 80.58.61.254
dns-search example.org
# 2009-07. The secondary network interface
allow-hotplug wlan0
iface wlan0 inet static
address 172.26.0.3
netmask 255.255.0.0
network 172.26.0.0
broadcast 172.26.255.255
gateway 172.26.0.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 80.58.61.250 80.58.61.254
dns-search example.org
wpa-ssid 314159
wpa-driver wext
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#pre-up wpa_supplicant -Bw -Dwext -iethX -c/etc/wpa_supplicant.conf
pre-up wpa_supplicant -D wext -B -i wlan0 -c
/etc/wpa_supplicant/wpa_supplicant.conf
post-down killall -q wpa_supplicant
and
# cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
network={
ssid = "314159"
proto=WPA
key_mgmt=WPA-PSK
psk="enunlugardelamanchadecuyonombrenopuedoacordarme"
}
Previously, I had not this problem with the same configuration files.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509719: nslu2: After fresh installation I get FATAL: Module rtc_dev not found.
En/na James Berry ha escrit: oops forgot ccs - Original Message From: James Berry To: 509...@bugs.debian.org Sent: Monday, 29 December, 2008 4:10:08 PM Subject: nslu2: After fresh installation I get FATAL: Module rtc_dev not found. Hi, I can confirm the bug and believe that it is low severity, as the script doing the modprobe rtc-dev is no longer necessary. This is based on Martin Michelmyr's reply to "Bug#449116: linux-image-2.6.22-2-ixp4xx: The module rtc-dev is not included" http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg528980.html Sorry for not responding earlier. These modules are now built into the kernel. If the rtc modules are built into the kernel from a particular version, then at least the following is redundant for all future kernels: pkg://nslu2-utils_20080403-1.tar.gz:44501/nslu2-utils/debian/nslu2-rtc.init downloads #!/bin/sh modprobe rtc-dev Can it be removed - or made dependent on older kernels? Cheers, James Linux energia 2.6.26-1-ixp4xx #1 Tue Dec 16 06:16:11 UTC 2008 armv5tel GNU/Linux Thanks a lot, James. Hope for soon fix ;-) Happy new year, Xan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509719: nslu2: After dist-upgrade I get "FATAL: Module rtc_dev not found"
Package: nslu2-utils Version: 20080403-3 Severity: normal File: nslu2 When I boot my NSLU2 device I got an error related to rtc device. The. exact error is: "FATAL: Module rtc_dev not found" After having researched with the help of the people at #debian-es, we. got to the conclusion that rtc-dev module is no longer present, but the init. script nslu2-utils contents just loads this module, and hence the error,. as we suppose. I hadn't this bug before the dist-upgrade. I did today which move my. system from. linux-image-2.6-ixp4xx (2.6.26+15 => 2.6.26+17) and. linux-image-2.6.26-1-ixp4xx (2.6.26-3 => 2.6.26-12) Also nslu2-utils were upgraded (from 20080403-2 => 20080403-3). The whole output of apt-get dist-upgrade -V is in Annex I I have also checked rtc devices at /dev: ls -l /dev lrwxrwxrwx 1 root root 4 24 des 19:48 /dev/rtc -> rtc0 crw-rw 1 root audio 254, 0 24 des 19:48 /dev/rtc0 I also have rtc references: grep -ri rtc /etc/modprobe.d/ /etc/modprobe.d/local:options rtc-x1205 probe=0,0x6f No rtc references at /etc/modules Please let me know if you need further information. I'm a novice user. A person who helps me detecting this possible bug is. rasas...@gmail.com. He offered for answering you about technical details. and he write me the draft of this bug report. Please, CC him. Regards, Xavi PS: reportbug nslu2-utils did not send this report because I remove exim4. Annex I (apt-get dist-upgrade -V) apt-get dist-upgrade -V Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: lzma (4.43-14) The following packages will be upgraded: apt (0.7.14 => 0.7.19) apt-utils (0.7.14 => 0.7.19) aptitude (0.4.11.9-1 => 0.4.11.11-1~lenny1) base-files (4.0.5 => 5) base-passwd (3.5.18 => 3.5.19) busybox (1.10.2-1 => 1.10.2-2) cron (3.0pl1-104 => 3.0pl1-105) debconf (1.5.23 => 1.5.24) debconf-i18n (1.5.23 => 1.5.24) dhcp-client (3.1.1-3 => 3.1.1-5) dhcp3-client (3.1.1-3 => 3.1.1-5) dhcp3-common (3.1.1-3 => 3.1.1-5) doc-linux-text (2008.06-1 => 2008.08-1) dpkg (1.14.20 => 1.14.23) e2fslibs (1.41.0-3 => 1.41.3-1) e2fsprogs (1.41.0-3 => 1.41.3-1) file (4.25-1 => 4.26-1) flash-kernel (2.6 => 2.11) gcc-4.2-base (4.2.4-3 => 4.2.4-4) gcc-4.3-base (4.3.1-9 => 4.3.2-1) gettext-base (0.17-3 => 0.17-4) grep (2.5.3~dfsg-5 => 2.5.3~dfsg-6) groff-base (1.18.1.1-20 => 1.18.1.1-21) initramfs-tools (0.92f => 0.92m) installation-report (2.36 => 2.38) iptables (1.4.1.1-2 => 1.4.1.1-3) libblkid1 (1.41.0-3 => 1.41.3-1) libc6 (2.7-13 => 2.7-16) libcomerr2 (1.41.0-3 => 1.41.3-1) libcwidget3 (0.5.12-1 => 0.5.12-3) libdb4.5 (4.5.20-12 => 4.5.20-13) libdb4.6 (4.6.21-10 => 4.6.21-11) libdevmapper1.02.1 (1.02.27-3 => 1.02.27-4) libdns43 (9.5.0.dfsg.P2-1 => 9.5.0.dfsg.P2-4) libgcc1 (4.3.1-9 => 4.3.2-1) libgnutls26 (2.4.1-1 => 2.4.2-4) libgpm2 (1.20.4-2 => 1.20.4-3.1) libisc44 (9.5.0.dfsg.P2-1 => 9.5.0.dfsg.P2-4) libiw29 (29-1 => 29-1.1) libkeyutils1 (1.2-7 => 1.2-9) libldap-2.4-2 (2.4.10-3 => 2.4.11-1) liblockfile1 (1.08-2 => 1.08-3) liblwres40 (9.5.0.dfsg.P2-1 => 9.5.0.dfsg.P2-4) libmagic1 (4.25-1 => 4.26-1) libncurses5 (5.6+20080804-1 => 5.6+20080830-2) libncursesw5 (5.6+20080804-1 => 5.6+20080830-2) libpam-modules (1.0.1-3 => 1.0.1-4) libpam-runtime (1.0.1-3 => 1.0.1-4) libpam0g (1.0.1-3 => 1.0.1-4) libpci3 (3.0.0-4 => 3.0.0-6) libsasl2-2 (2.1.22.dfsg1-22 => 2.1.22.dfsg1-23) libselinux1 (2.0.65-4 => 2.0.65-5) libsemanage1 (2.0.25-1 => 2.0.25-2) libsqlite3-0 (3.5.9-3 => 3.5.9-5) libss2 (1.41.0-3 => 1.41.3-1) libssl0.9.8 (0.9.8g-13 => 0.9.8g-14) libstdc++6 (4.3.1-9 => 4.3.2-1) libusb-0.1-4 (0.1.12-12 => 0.1.12-13) libuuid1 (1.41.0-3 => 1.41.3-1) libvolume-id0 (0.125-5 => 0.125-7) libxapian15 (1.0.7-3 => 1.0.7-4) libxml2 (2.6.32.dfsg-3 => 2.6.32.dfsg-5) linux-image-2.6-ixp4xx (2.6.26+15 => 2.6.26+17) linux-image-2.6.26-1-ixp4xx (2.6.26-3 => 2.6.26-12) locales (2.7-13 => 2.7-16) login (4.1.1-4 => 4.1.1-6) logrotate (3.7.1-3 => 3.7.1-5) man-db (2.5.2-2 => 2.5.2-3) mlocate (0.21-1 => 0.21.1-1) ncurses-base (5.6+20080804-1 => 5.6+20080830-2) ncurses-bin (5.6+20080804-1 => 5.6+20080830-2) ncurses-term (5.6+20080804-1 => 5.6+20080830-2) net-tools (1.60-19 => 1.60-22) netbase (4.33 => 4.34) nslu2-utils (20080403-2 => 20080403-3) openbsd-inetd (0.20080125-1 => 0.20080125-2) passwd (4.1.1-4 => 4.1.1-6) pciutils (3.0.0-4 => 3.0.0-6) perl (5.10.0-13 => 5.10.0-18) perl-base (5.10.0-13 => 5.10.0-18) perl-doc (5.10.0-13 => 5.10.0-18) perl-modules (5.10.0-13 => 5.10.0-18) policycoreutils (2.0.49-5 => 2.0.49-6) popularity-contest (1.45 => 1.46) python (2.5.2-2 => 2.5.2-3) python-minimal (2.5.2-2 => 2.5.2-3) python-selinux (2.0.65-4 => 2.0.65-5) python-semanage (2.0.25-1 => 2.0.25-2) python-sepolgen (1.0.11-4 => 1.0.11-5) python2.5 (2.5.2-11 =>
Bug#492060: Is pidentd installed by default?
En/na Teodor ha escrit: On Wed, Aug 27, 2008 at 2:56 AM, Aníbal Monsalve Salazar <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED]:~$ apt-cache policy pidentd pidentd: Installed: (none) Candidate: 3.0.19.ds1-4 Version table: 3.0.19.ds1-4 0 500 http://ftp.us.debian.org sid/main Packages 500 http://ftp.ro.debian.org sid/main Packages 990 http://ftp.ro.debian.org lenny/main Packages 990 http://ftp.de.debian.org lenny/main Packages 990 http://ftp.fr.debian.org lenny/main Packages 3.0.19.ds1-1 0 500 http://ftp.ro.debian.org etch/main Packages Thanks Wow!!. How could be happen that different mirrors have different policies? Regards, Xan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414786: Information
Hi, I only want to put information about this bug: * Just for information, in this thread [http://lists.debian.org/debian-arm/2008/08/msg00133.html] it was commented and a solution was commented. * I think this depends on beep. Can you reflect this dependency? * The code is simply putting in /etc/rc.local beep -f 22 -l 100 -r 5 (this is the solution provided in thread above) or some more "fun" code: beep -f 11 -l 100 -r 1 beep -f 15 -l 100 -r 1 beep -f 20 -l 150 -r 1 -D 100 beep -f 11 -l 100 -r 1 beep -f 15 -l 100 -r 1 beep -f 5 -l 200 -r 1 Not of all, Xan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#129161: very beginning of
ErectileorganExtensiveCarlos http://www.Twalveen.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447186: uhci_hcd unload hangs on suspend
Package: linux-image-2.6.18-5-686 Version: 2.6.18.dfsg.1-13etch4 Up until this latest version of 2.6.18-5, on my Inspiron 8600 I have been able to right-click on the "kpowersave" icon in the KDE system tray and select "Suspend to Disk". It would very quickly prepare the system to suspend, and then the screen would switch to text mode and count the percentages as it wrote the memory to the hard drive. Now, the preparation hangs when it tries to unload module uhci_hcd. The keyboard and mouse quit responding, and I have to power down. I'm working around this by booting to 2.6.18-4, where it works fine. It also worked on the earlier version of 2.6.18-5, but that was blasted by the update. This is pretty much a standard, non-tricked-out, etch install. I have just a few things from debian-multimedia.org, plus Opera, all installed via dpkg. Everything else is plain etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421402: It's installed by default but not activated and configured by default!
En/na Geert Stappers ha escrit: severity 421402 wishlist reassign 421402 libselinux tags 421402 d-i thanks Op 30-04-2007 om 12:13 schreef Xan: I only wanted to help detecting some bugs or wishes (if you tag this bug as it) for improve debian. If you closed the bug, the bug is alive yet. Bug triaged. Thank you very much, Xan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421402: It's installed by default but not activated and configured by default!
En/na Geert Stappers ha escrit: Op 29-04-2007 om 10:26 schreef Xan: En/na Frans Pop ha escrit: On Saturday 28 April 2007 22:38, Xan wrote: Yes the packages of selinux are installed by default but not activated and configured by default (parameter "selinux=1" in kernel, politics file, etc) and there is no possibility of doing it in the d-i I think that the bug should be marked as open for these reasons Not really. The selinux people in Debian will make that decision when the time is ripe. There is absolutely no "bug" that needs to be tracked, especially not in the installation system. So, is there planned option for activated and configured in future releases? If yes, will you provide options to debian-installer for not activate it, for those who don't want it? Questions like those, steady usual unanswered. Because the (unwritten) answer is a mix of: * Yes * You are welcome to do so * Check the release goals of this project * Are you asking for permission? Or are you hiring people to do so? I only bug it because I think: - it's at least an incongruency that we have a selinux kernel capable and in installation we have not the possibility of activate/desactivate it installation - it's a "interface bug" of installation process. I think that in expert mode it should be present - it's a recordatory for that: people working in d-i/selinux have present and if anyone wants to contribute in d-i/selinux, know what fails I don't want contribute in code (I'm not a programmer). I only wanted to help detecting some bugs or wishes (if you tag this bug as it) for improve debian. If you closed the bug, the bug is alive yet. Regards, Xan. Hope this Helps Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421402: It's installed by default but not activated and configured by default!
En/na Frans Pop ha escrit: On Saturday 28 April 2007 22:38, Xan wrote: Yes the packages of selinux are installed by default but not activated and configured by default (parameter "selinux=1" in kernel, politics file, etc) and there is no possibility of doing it in the d-i I think that the bug should be marked as open for these reasons Not really. The selinux people in Debian will make that decision when the time is ripe. There is absolutely no "bug" that needs to be tracked, especially not in the installation system. So, is there planned option for activated and configured in future releases? If yes, will you provide options to debian-installer for not activate it (for those who don't want it)? Thanks, Xan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421402: It's installed by default but not activated and configured by default!
Hi, Yes the packages of selinux are installed by default but not activated and configured by default (parameter "selinux=1" in kernel, politics file, etc) and there is no possibility of doing it in the d-i The user only have the possibility of activated after installation (follow the link you appointed) I think that the bug should be marked as open for these reasons Xan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421402: Possibility of installing selinux in d-i
Package: hello Version: etch The latest version of debian include a selinux capable kernel. Consider to put the possibility of installing selinux in system by debian-installer I bug it as a formal bug Thanks in advance, Xan. PS: Another bug could include the possibility of installing rsbac, grsecurity, etc but it were more difficult -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281268: About your bug: "kdm: don't show the name of the mouse selected user" on the Debian BTS
Now I don't use kde nop debian. So I can't test if there is the bug already. So, close the bug. Xan. En/na Ana Guerrero ha escrit: Hi, We (the Debian Qt/KDE team) are trying to update the bug status of some old bugs in the BTS. You filed the bug #281268 "kdm: don't show the name of the mouse selected user" some time ago, you can read the bug report at: http://bugs.debian.org/281268 We are sorry if nobody responded when you filed the bug, KDE has gotten more bugs in the past years than the maintainers could handle. We are trying to fix this now, but we need your help. So please respond to this mail and tell us if: - you are still experiencing this bug (adding in what version) - the bug was already fixed, - or if you have extra information on how reproduce this bug. --- Thanks in advance, Ana Guerrero, on behalf of the Debian Qt/KDE team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
