Bug#1055814: man-db: Garbled display (escape sequences displayed) when using custom $LESS in lesskey
Package: man-db Version: 2.12.0-1 Severity: normal Dear Maintainer, Since it seems my last man-db update, I get a garbled display for every manpage: all escape sequences appear as-is. I traced it back to my lesskey settings: I use the following in ~/.lesskey: #env LESS = -j 5 I have been using it for ages without problem, but today this makes the man pages unusable. I do not know if this bug comes from man or less, but when trying to understand where it comes from, it seems that the $LESS env var that man passes to less to tell it to interpret escape sequences is overridden by my custom lesskey setting. Removing my custom setting makes man work properly. It used to work nicely before my upgrade, i.e. I had correct man page display, and the 5 lines offset from my setting. Attached is the result from running "man --debug man"; the debug output does not change whatever my less setting is. The more I dig into this, the more I think this is a less problem, but my last less upgrade dates from long ago, long before I witnessed this problem. I really do not understand where this could come from, but would be happy to provide more detail and try more advanced debugging. Regards, -- Benjamin -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-8-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages man-db depends on: ii bsdextrautils 2.39.2-5 ii debconf [debconf-2.0] 1.5.82 ii groff-base 1.23.0-3 ii libc6 2.37-12 ii libgdbm6 1.23-3 ii libpipeline1 1.5.7-1 ii libseccomp22.5.4-2 ii zlib1g 1:1.2.13.dfsg-3 man-db recommends no packages. Versions of packages man-db suggests: ii apparmor 3.0.12-1 ii elinks [www-browser] 0.16.1.1-4 ii firefox [www-browser] 119.0-1 pn groff ii less 590-2 ii lynx [www-browser] 2.9.0dev.12-1 ii netsurf-gtk [www-browser] 3.10-3.1 ii w3m [www-browser] 0.5.3+git20230121-2 -- debconf information: man-db/install-setuid: false man-db/auto-update: true ruid=1000, euid=1000 rgid=1000, egid=1000 From the config file /etc/manpath.config: Mandatory mandir `/usr/man'. Mandatory mandir `/usr/share/man'. Mandatory mandir `/usr/local/share/man'. Path `/bin' mapped to mandir `/usr/share/man'. Path `/usr/bin' mapped to mandir `/usr/share/man'. Path `/sbin' mapped to mandir `/usr/share/man'. Path `/usr/sbin' mapped to mandir `/usr/share/man'. Path `/usr/local/bin' mapped to mandir `/usr/local/man'. Path `/usr/local/bin' mapped to mandir `/usr/local/share/man'. Path `/usr/local/sbin' mapped to mandir `/usr/local/man'. Path `/usr/local/sbin' mapped to mandir `/usr/local/share/man'. Path `/usr/X11R6/bin' mapped to mandir `/usr/X11R6/man'. Path `/usr/bin/X11' mapped to mandir `/usr/X11R6/man'. Path `/usr/games' mapped to mandir `/usr/share/man'. Path `/opt/bin' mapped to mandir `/opt/man'. Path `/opt/sbin' mapped to mandir `/opt/man'. Global mandir `/usr/man', catdir `/var/cache/man/fsstnd'. Global mandir `/usr/share/man', catdir `/var/cache/man'. Global mandir `/usr/local/man', catdir `/var/cache/man/oldlocal'. Global mandir `/usr/local/share/man', catdir `/var/cache/man/local'. Global mandir `/usr/X11R6/man', catdir `/var/cache/man/X11R6'. Global mandir `/opt/man', catdir `/var/cache/man/opt'. Global mandir `/snap/man', catdir `/var/cache/man/snap'. Added sections: `1', `n', `l', `8', `3', `0', `2', `3type', `3posix', `3pm', `3perl', `3am', `5', `4', `9', `6', `7'. is a tty using pager as pager path directory /home/benoar/bin is not in the config file path directory /usr/local/bin is in the config file adding /usr/local/man to manpath adding /usr/local/share/man to manpath path directory /usr/bin is in the config file adding /usr/share/man to manpath path directory /bin is in the config file path directory /usr/games is in the config file adding mandatory man directories attention : /usr/man: Aucun fichier ou dossier de ce type add_nls_manpaths(): processing /usr/local/man:/usr/local/share/man:/usr/share/man checking for locale fr_FR.UTF-8 adding /usr/share/man/fr to manpathlist adding /usr/local/man to manpathlist adding /usr/share/man to manpathlist final search path = /usr/share/man/fr:/usr/local/man:/usr/share/man searching in /usr/share/man/fr, section 1 trying section 1 with globbing Layout is GNU (1) update_directory_cache /usr/share/man/fr: miss matching wildcard in /usr/share/man/fr: man1* matched: /usr/share/man/fr/man1 update_directory_cache /usr/share/man/fr/man1: miss matching wildcard in /usr/share/man/fr/man1:
Bug#955825: isc-dhcp-client: wrong ipv6 prefix length set automatically
Hello Adrian, [CC'ing the maintainers for the suggestion at the end] I hope you don't mind me commenting on this issue, that I stumbled upon by chance; I do not use isc-dhcp with IPv6, but spotted a misunderstanding. On Sun, 05 Apr 2020 13:20:14 +0200 Adrian Zaugg wrote: > I would expect dhclient to set the prefix lenght, if the dhcp6 server sends > one. The DHCPv6 protocol does not take care of prefix length. This is a property of the routing infrastructure, not the addressing infrastructure, and is thus not conveyed by the DHCPv6 server but by the router(s) advertising the prefix through Neighbour Discovery's Router Advertisements. The “issue” you see —I imagine— is that matching what prefix advertisement correspond to what address, in the traditional IPv4 sense, is hard when done this way. And indeed, there is no formal relation possible in IPv6, and often you will see a node address prefix (/128) alongside the network prefix (/64 or whatever), but this does not affect the correct functionning of the routing or addressing in any way. This is on purpose in the IPv6 design, and it is a common mistake to translate some IPv4 knowledge to IPv6 and ask this kind of question. If there really is an issue with your setup, I think you should try to describe it more precisely, and state what you expect exactly. […] > What really confuses me, is that ISC did change the IPv6 handling in the > dhclient-script, but it is not > brought to Debian. In the upstream version they call a function > "add_ipv6_addr_with_DAD". So I guess, the > bug is not present there. If I watch at the source package of 4.4.1-2.1, I do > see the upstream changes, but > they are not present in the script that the binary package of 4.4.1-2.1+b2 > delivers. Sorry, I don't > understand what's going on here. I looked and your are actually right that the function was not updated in Debian's script. But your guess is wrong, even if the prefix length mention suprised me at first: the new add_ipv6_addr_with_DAD does a bit more with DAD (Duplicate Address Detection) validation before returning, but this issue (DAD conflict) almost never happen and its absence will not usually hinder you. The part about the prefix length surprised me, but by looking at client/dhclient.c, we can see that this parameter is the one provided *by the user* launching dhclient (--address-prefix-len parameter). So I think this is kind of a “workaround” for administrator really wanting to hardcode the prefix length somewhere, and avoiding the /128 I mentionned above. But this does not come at all from the DHCPv6 server, as this concept does not exist in the protocol. In the end, I think that appart from the script update which could use the DAD helper, this bug is indeed not a bug. Hope this helps. Regards, -- Benjamin
Bug#568204: #568204 hwclock should not try to calculate the drift if rtc time is invalid
Hi Chris, Le dimanche 03 mai 2020 à 20:42 +0200, Chris Hofstaedtler a écrit : > the supplied patch does not apply anymore; actually I can't find the > code that it tries to patch. It's still there in sys-utils/hwclock*.c. > Maybe this is just obsolete after 10 > years in the Debian BTS; if this is still a problem please try > upstream, as they can be more helpful. Thanks for the follow-up! Actually, it made me dig if it's still accurate; I saw that the other RTC in the kernel I mentionned (pcf8563) that specifically ignored returning an error when failing to read the RTC has been fixed in 2015 to return EINVAL because “at least the current version [of hwclock] do set the time as expected”: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=538330ccb93849530f5617d1fa870237496caa60 Still, looking at the latest hwclock code, the parts I fixed did not change much: it still propagated an error on synchronization. Going up to sys-utils/hwclock.c:manipulate_clock() cleared the mistery: there is now a mention of “enabl[ing] setting a corrupted RTC without reading it first”. The full explanation is in ee723d23524d8e170aae030bb7579b4fae5599df from J William Piggott in 2017, two years later, explaining very thoroughly that the problem was partially fixed throughout the years in hwclock, hence the fix from 2015 for some platforms, and its final fix solving the problem once and for all. I do not own the hardware anymore so I cannot really test it, but I think that today my patch is indeed not needed anymore and has been fixed in another way. Thanks for bringing me some memories and your clean-up work of the BTS! Regards, -- benjamin
Bug#842242: Missing $LINENO support is intentional
Hi, I wondered too about the problem highlighted in #766048 pointed by this bug, and did not understand why $LINENO support was kept disabled. I found an answer in #582952 which is, from what I understand, similar to #766048: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582952 So, keeping $LINENO support disable is *intentional* so as configure *does not* catch dash as the default shell, because it breaks a lot of packages with bashisms. The bug highlights the reason of this deactivation, even if “long term” solution is to fix all the bashisms. So, as long as we have bashisms, we must have slow configure for everyone… So maybe this bug could be merged/closed? -- Benjamin Cama - Tél : 258
Bug#861710: libmaven-enforcer-plugin-java: Dependency on libmaven-dependency-tree-java should require newer version
Package: libmaven-enforcer-plugin-java Version: 1.4.1-2 Severity: normal Hi, On a Jessie with manually cherry-picked newer maven versions, I found that current maven-enforcer version 1.4.1 does not work with libmaven-dependency-tree-java version 1.2 (something about missing org.apache.maven.shared.dependency.graph.DependencyGraphBuilder), the current one in stable, although it is not stated in the dependencies. Installing the newer 2.1 version makes it work. Could you add the version requirement to the dependencies, please? Thanks. -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libmaven-enforcer-plugin-java depends on: ii libbsh-java2.0b4-15+deb8u1 ii libcommons-lang-java 2.6-4 ii libmaven-common-artifact-filters-java 1.4-1 ii libmaven-dependency-tree-java 2.1-1 ii libmaven2-core-java2.2.1-17 ii libplexus-container-default-java 1.0-alpha-9-stable-1-7 ii libplexus-i18n-java1.0-beta-10-3 ii libplexus-utils-java 1:1.5.15-4 libmaven-enforcer-plugin-java recommends no packages. libmaven-enforcer-plugin-java suggests no packages. -- no debconf information
Bug#857142: lvm2: cache-pool un-checkable after crash because cache_check is not present
Hi, Le mercredi 08 mars 2017 à 16:57 +0100, Benjamin Cama a écrit : > Le mercredi 08 mars 2017 à 16:26 +0100, Bastian Blank a écrit : > > On Wed, Mar 08, 2017 at 01:02:08PM +0100, Benjamin Cama wrote: > > > Could you try to include this tool in Debian, or at least give a big > > > warning that cache-pools are dangerous without it? Thanks. > > > > | Package: lvm2 > > | Version: 2.02.168-1 > > | Suggests: thin-provisioning-tools > > > > | Package: thin-provisioning-tools > > | Version: 0.6.1-4 > > > > We have everything available. > > Ooops, didn't see that… Sorry for the noise about that. Still, even if > it is suggested, it didn't get installed here. It's a quite fresh Jessie > install from two monthes ago, with lvm disk layout chosen from d-i, what > could have made it skipped? OK, I just mixed “suggests” with “recommends” in my head again, and of course it wasn't installed as suggests are not by default. Maybe thin-provisioning-tools should be a recommends, if cached volumes are really a supported feature of Debian? -- Benjamin Cama - Tél : 227
Bug#857142: lvm2: cache-pool un-checkable after crash because cache_check is not present
Le mercredi 08 mars 2017 à 16:26 +0100, Bastian Blank a écrit : > On Wed, Mar 08, 2017 at 01:02:08PM +0100, Benjamin Cama wrote: > > Could you try to include this tool in Debian, or at least give a big > > warning that cache-pools are dangerous without it? Thanks. > > | Package: lvm2 > | Version: 2.02.168-1 > | Suggests: thin-provisioning-tools > > | Package: thin-provisioning-tools > | Version: 0.6.1-4 > > We have everything available. Ooops, didn't see that… Sorry for the noise about that. Still, even if it is suggested, it didn't get installed here. It's a quite fresh Jessie install from two monthes ago, with lvm disk layout chosen from d-i, what could have made it skipped? Thanks for your help, -- Benjamin Cama - Tél : 227
Bug#857142: lvm2: cache-pool un-checkable after crash because cache_check is not present
Package: lvm2 Version: 2.02.111-2.2+deb8u1 Severity: important Dear Maintainer, I recently added a cache LV to cache my home LV, and had not rebooted much since. After a kernel crash, I hard-rebooted but the system led me into a recovery shell because my home LV could not be activated. When trying to activate it, it gave: /usr/sbin/cache_check: execvp failed: Aucun fichier ou dossier de ce type Check of pool main/ssd-cache failed (status:2). Manual repair required! (first message is “no such file or directory” in french). The cache seemed corrupt, and indeed, cache_check is not present, and AFAIK not present anywhere in the Debian repository (I searched in latest sid packages). LVM sources tell me that it comes from https://github.com/jthornber/thin-provisioning-tools and I was able to check the cache and activate my home LV after compiling and running this tool. Still, as cache LVs seem activated and “supported” by Debian since 111, it seems difficult not to distribute this tool. The configuration example even says that it is executed each time a cached volume is activated (I think I never rebooted normally once since activating it, so I cannot confirm), but it looks quite necessary to make this feature usable. Could you try to include this tool in Debian, or at least give a big warning that cache-pools are dangerous without it? Thanks. -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lvm2 depends on: ii dmeventd 2:1.02.90-2.2+deb8u1 ii dmsetup 2:1.02.90-2.2+deb8u1 ii init-system-helpers 1.22 ii initscripts 2.88dsf-59 ii libc6 2.19-18+deb8u7 ii libdevmapper-event1.02.1 2:1.02.90-2.2+deb8u1 ii libdevmapper1.02.12:1.02.90-2.2+deb8u1 ii libreadline5 5.2+dfsg-2 ii libudev1 215-17+deb8u6 ii lsb-base 4.1+Debian13+nmu1 lvm2 recommends no packages. Versions of packages lvm2 suggests: pn thin-provisioning-tools -- no debconf information
Bug#743641: Freetype not handling fontconfig's idea of legacy lcd filter well
[Sorry, forgot to Cc the bug once modified] Hi, Hi am reassigning this old bug as I found the origin of it, but it is a bit entangled. My explanations follow. In the end, this is really a bug in libXft which does not translate the lcd filter index from fontconfig to freetype, as should be done according to the API, which has been poorly defined until now. But after reporting the bug to fontconfig, which I thought was the culprit at first <https://bugs.freedesktop.org/show_bug.cgi?id=92981>, the freetype maintainer decided to add a workaround in latest freetype to allow for this API misuse. What I am asking with this bug report is for Jessie's freetype to include this fix (commit b96af12eb646534ab4d112e25210bd88812ee420), see <http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b96af12eb646534ab4d112e25210bd88812ee420>. It applies modulo the ftlcdfil.h directory change (from include/ to include/freetype/) and the Changelog message. This way, it would fix every application that uses Xft (or other freetype clients which do the “wrong” thing, which does not include cairo) for users that use the legacy lcd filter (which used to be the system-wide default in old Debians and which is gorgeous, but this is another debate). I could of course try to fix libXft, but it seems not a very active project, and furthermore the fontconfig API looks like bound to change, so this looks like a lot of work for nothing. Thanks for what you can do about it. -- Benjamin Cama <benjamin.c...@telecom-bretagne.eu>
Bug#803240: libvirt-clients: Cannot run virsh as user, polkit permission problem
Package: libvirt-clients Version: 1.2.9-9+deb8u1 Severity: important Dear Maintainer, Since my upgrade to jessie, I can not use "virsh" anymore for the system instance (the session one works well). As a simple user, I get: % virsh -c qemu:///system error: failed to connect to the hypervisor error: error from service: CheckAuthorization: Action org.libvirt.unix.manage is not registered I am into the "libvirt" group, and frankly I do not understand well all the polkit permission stuff. It used to work well on wheezy. Running as root, it works correctly, but I would prefer not to. I did not change anything related to polkit or libvirt to fix this problem. There used to be some issues with the systemd transition when upgrading to jessie, but I do not remember changing anything fundamental. I can provide excerpts from /etc where needed if you ask. Thanks. -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libvirt-clients depends on: ii libapparmor12.9.0-3 ii libaudit1 1:2.4-1+b1 ii libavahi-client30.6.31-5 ii libavahi-common30.6.31-5 ii libc6 2.19-18+deb8u1 ii libcap-ng0 0.7.4-2 ii libdbus-1-3 1.8.20-0+deb8u1 ii libdevmapper1.02.1 2:1.02.90-2.2 ii libgnutls-deb0-28 3.3.8-6+deb8u3 ii libnl-3-200 3.2.24-2 ii libnl-route-3-200 3.2.24-2 ii libnuma12.0.10-1 ii libreadline66.3-8+b3 ii libsasl2-2 2.1.26.dfsg1-13+deb8u1 ii libselinux1 2.3-2 ii libssh2-1 1.4.3-4.1 ii libsystemd0 215-17+deb8u2 ii libvirt01.2.9-9+deb8u1 ii libxml2 2.9.1+dfsg1-5 ii libyajl22.1.0-2 libvirt-clients recommends no packages. Versions of packages libvirt-clients suggests: ii libvirt-daemon 1.2.9-9+deb8u1 -- no debconf information
Bug#776801: fontconfig: wheezy->jessie: broke 70-no-bitmaps.conf symlink
Package: fontconfig-config Version: 2.11.0-6.3 Followup-For: Bug #776801 Hi, Also affected by this bug. It was a bit hard to debug, as it is not immediatly obvious that the 70-no-bitmaps.conf link is broken if you look too quickly, not counting finding the right place to look at first. This bug could have been prevented if #758973 had not introduced a strange hack for what is to me *not* a problem: it is very strange that now the configuration of the package is not idempotent. For me, re-creating the config from the debconf questions should be harmless, and thus activatable whenever the configuration is asked on postinst: in our case, on upgrade. For me, the patch from this bug that made it to version 2.11.0-6.3 should be reverted. Or maybe, the attached crude hack applied, but it really looks ugly. Thanks, benjamin -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fontconfig-config depends on: ii debconf [debconf-2.0] 1.5.56 ii fonts-dejavu-core 2.34-1 ii fonts-liberation 1.07.4-1 ii ucf3.0030 fontconfig-config recommends no packages. fontconfig-config suggests no packages. -- debconf information: * fontconfig/hinting_type: Native * fontconfig/subpixel_rendering: Automatic * fontconfig/enable_bitmaps: false >From b7419008ae1a6d4c3d4f36062fe5b44bdd87ddb7 Mon Sep 17 00:00:00 2001 From: Benjamin Cama <benjamin.c...@telecom-bretagne.eu> Date: Mon, 21 Sep 2015 14:10:35 +0200 Subject: [PATCH] Fix wrong 70-no-bitmaps.conf link from older version --- debian/changelog | 7 +++ debian/fontconfig-config.postinst | 2 ++ 2 files changed, 9 insertions(+) diff --git a/debian/changelog b/debian/changelog index dea52c1..bcaf363 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +fontconfig (2.11.0-6.4) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix wrong 70-no-bitmaps.conf link from older version. Closes: #776801. + + -- Benjamin Cama <benjamin.c...@telecom-bretagne.eu> Mon, 21 Sep 2015 14:11:35 +0200 + fontconfig (2.11.0-6.3) unstable; urgency=medium * Non-maintainer upload. diff --git a/debian/fontconfig-config.postinst b/debian/fontconfig-config.postinst index 2a4d04e..44ef4cf 100644 --- a/debian/fontconfig-config.postinst +++ b/debian/fontconfig-config.postinst @@ -72,8 +72,10 @@ if is_initial_configuration "$@"; then ln -s $CONFAVAIL/$no_subpixel $CONFDIR/$no_subpixel ;; esac +fi +if is_initial_configuration "$@" || [ $(readlink $CONFDIR/70-no-bitmaps.conf) = "/etc/fonts/conf.avail/70-no-bitmaps.conf" ]; then db_get fontconfig/enable_bitmaps enable_bitmaps="$RET" -- 2.1.4
Bug#798967: [Pkg-xfce-devel] Bug#798967: lightdm: Does not source /etc/environment through pam_env
Hi Yves-Alexis, Le lundi 14 septembre 2015 à 21:42 +0200, Yves-Alexis Perez a écrit : > I don't remember exactly from where I picked the change (I think it was > from gdm), but indeed, there's definitely a mistake. > /etc/default/locale should be only added, not replace completely the > thing. As far as I can tell, other pam config file use something like: > > session required pam_env.so readenv=1 > session required pam_env.so readenv=1 envfile=/etc/default/locale > > Can you check that it works for you and report back? I tested your change, without the "readenv=1" that seems useless according to pam_env(8) (even if it is indeed used by a lot of services in /etc/pam.d), and it works (logout + "invoke-rc.d lightdm restart" at each try, to be sure). The "auth" to "session" change looks right, too, now that you point it out. Also, please note that even without the second line, my locale get set correctly… but every other service seems to do it, so… Thanks for your time looking into this problem and fixing it! Regards, -- Benjamin Cama <benjamin.c...@telecom-bretagne.eu>
Bug#798967: lightdm: Does not source /etc/environment through pam_env
Package: lightdm Version: 1.10.3-3 Severity: important Dear Maintainer, Since jessie, lightdm has broken my setup (breaking network printing, authorized with Kerberos in my case) because it does not source /etc/environment when starting a session, as any DM should. My setup did work correctly previously with wheezy (its lightdm version correctly sourced this file). For me, the fix was to remove the "envfile=/etc/default/locale" argument to pam_env.so in /etc/pam.d/lightdm. This change is Debian-specific, and comes from this patch version: http://anonscm.debian.org/viewvc/pkg-xfce/goodies/trunk/lightdm/debian/patches/05_debianize-pam-files.patch?revision=7308=markup Furthermore, the comment above is inconsistent with the line described. I really do not know what /etc/default/locale has to do with the whole environment: it is just a small part of it (I do not even know where this is sourced; still, I get the correct locale even with my fix). This bug and its solution look quite like the fix proposed in #784158 (apart from the user environment sourcing; I have no opinion on this) but it has been dismissed has "fixed-upstream" (which is strange as it seems Debian-specific) and "wontfix" which is really a big mistake, thus the severity "important" here, as it is *really* breaking a rather fundamental function, to me. Please explain the rationale behind the /etc/default/locale thing or please fix it for jessie (I lost *a lot* of time on this). Thanks, -- benjamin -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lightdm depends on: ii adduser3.113+nmu3 ii consolekit 0.4.6-5 ii dbus 1.8.20-0+deb8u1 ii debconf [debconf-2.0] 1.5.56 ii libc6 2.19-18+deb8u1 ii libgcrypt201.6.3-2 ii libglib2.0-0 2.42.1-1 ii libpam-systemd 215-17+deb8u2 ii libpam0g 1.1.8-3.1 ii libxcb11.10-3+b1 ii libxdmcp6 1:1.1.1-1+b1 ii lightdm-gtk-greeter [lightdm-greeter] 1.8.5-2 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+7 Versions of packages lightdm suggests: pn accountsservice ii upower 0.99.1-3.2 -- Configuration Files: /etc/apparmor.d/lightdm-guest-session 9d3af5806375ac868fcaf5aaf3d56a00 [Errno 2] Aucun fichier ou dossier de ce type: u'/etc/apparmor.d/lightdm-guest-session 9d3af5806375ac868fcaf5aaf3d56a00' /etc/pam.d/lightdm changed: auth requisite pam_nologin.so auth required pam_env.so @include common-auth -auth optional pam_gnome_keyring.so @include common-account session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close session requiredpam_limits.so session requiredpam_loginuid.so @include common-session session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open -session optionalpam_gnome_keyring.so auto_start @include common-password -- debconf information: * shared/default-x-display-manager: lightdm lightdm/daemon_name: /usr/sbin/lightdm
Bug#798967: lightdm: Does not source /etc/environment through pam_env
On Mon, 14 Sep 2015 16:31:57 +0200 Benjamin Cama <benjamin.c...@telecom-bretagne.eu> wrote: > Since jessie, lightdm has broken my setup (breaking network printing, > authorized with Kerberos in my case) because it does not source > /etc/environment when starting a session, as any DM should. See also this thread on debian-user where another guy got this problem: https://lists.debian.org/debian-user/2015/05/msg00191.html Regards, -- Benjamin Cama <benjamin.c...@telecom-bretagne.eu>
Bug#754402: dnsmasq: Ignore files which do not match *.conf in /etc/dnsmasq.d
Hi, Le mercredi 13 août 2014 à 12:10 +0100, Simon Kelley a écrit : I worry that it's an unfriendly thing to do to make a upgrade break any existing installation that uses a file in /etc/dnsmasq.d that doesn't end in .conf. I guess that the postinst script could check for this, and generate a warning, or configure differently if such files already exist. It is indeed not very friendly, but if correctly advertised, it should be OK. That is what module-init-tools did (also renaming conffiles installed by itself, I think). My though for config-dir would be to allow something like --config-dir=/etc/dnsmasq.d,\*.conf BTW, do you intend to change it to --config-dir or is it a typo? ie the arguments are the directory (as now) followed by one or more file-endings to exclude (as now) and one or more file endings to include, marked by preceding them with *. * is a problem on the command line, because it's a shell metacharacter, but it make the meaning very obvious. Well, this wouldn't look so obvious to a newcomer, I think (just prepending a * to mean the opposite?…) but I can't find a better idea while keeping the same option (and keeping it backward compatible, as switching to --conf-dir suffix list to mean “include” instead of exclude would be easier, and having to exclude by prepending e.g. “!”). Regards, -- Benjamin Cama benjamin.c...@telecom-bretagne.eu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754402: dnsmasq: Ignore files which do not match *.conf in /etc/dnsmasq.d
Hi Simon, Le samedi 19 juillet 2014 à 22:01 +0100, Simon Kelley a écrit : It would be fairly simple to support this upstream, and with hindsight it's a better way to do things. My main concern is that to make the change now introduces a behavior change with the potential to break existing installations. Yes, I understand. There may be a way around this, since the directive which tells dnsmasq to load the contents of /etc/dnsmasq.d is in /etc/default/dnsmasq # By default search this drop directory for configuration options. # Libvirt leaves a file here to make the system dnsmasq play nice. # Comment out this line if you don't want this. The dpkg-* are file # endings which cause dnsmasq to skip that file. This avoids pulling # in backups made by dpkg. CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new Since /etc/default/dnsmasq is a conffile, that could be left alone for existing installations which are upgrading, but new semantics introduced for new installations, ie delete the line above and add CONFIG_DIR_FILE=etc/dnsmasq.d,.conf with suitable scripting in the init script and an extension of the --conf-dir dnsmasq flag. Opinions? Well, frankly, making this configurable seems overkill to me. On my current setup, I see no other software having a configurable configuration dir in /etc/default. Better behave the standard way by default (hardcode /etc/dnsmasq.d in the init script), without setting any CONFIG_DIR* in /etc/default/dnsmasq. This way, the libvirt trick is still taken into account; we *may* need a way to disable it, but it seems so badly needed that I won't cry if it's not possible to do without manual tweaking. Then we have no more dpkg-* exceptions, as only *.conf are included. That with a warning on the next upgrade (it seems I already saw such warning elsewhere for this kind of transition some times ago; same thing, to only choose *.conf and not others), so as not to break too much. It's only a renaming issue, if correctly advertised. The most ugly part (to me) would be to extend the --config-dir flag in a not-too-ugly way, which I can't think of right now. Thanks for investigating this! (and I didn't know you where the maintainer too: thanks for all this work) -- Benjamin Cama benjamin.c...@telecom-bretagne.eu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754402: dnsmasq: Ignore files which do not match *.conf in /etc/dnsmasq.d
Package: dnsmasq Version: 2.62-3+deb7u1 Severity: wishlist Hi, While configuring dnsmasq today, I stumbled upon a very annoying behavior: dnsmasq doesn't ignore files not ending in .conf in its /etc/dnsmasq.d/ configuration directory. I had copied the current config alongside the original file renaming it with .old and it took me some time to realize that the error message I got when restarting dnsmasq from now on were because dnsmasq read the two files and found duplicate configuration options. The usual way of handling .d configuration directories in Debian (to me, at least) is to only take into account files ending in .conf, so that you can have “backup” files or easily ignore some config files. The current behavior is a bit disturbing when trying to configure dnsmasq. I realize that dnsmasq has no easy way of achieving this (it can only ignore some patterns, not restrict to some pattern), so this may be difficult to implement, but I'd be glad if someone found a way to “fix” this. Thanks, Benjamin -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dnsmasq depends on: ii adduser 3.113+nmu3 ii dnsmasq-base 2.62-3+deb7u1 ii netbase 5.0 dnsmasq recommends no packages. Versions of packages dnsmasq suggests: pn resolvconf 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#743641: rxvt-unicode: color fringes appearing when using sub-pixel antialiased hinted fonts
Package: rxvt-unicode Version: 9.15-2 Severity: normal Hi, On my system, I used to have urxvt with a special font rendering of mine which worked correctly with squeeze: I use DejaVu sans at 11pt, with hintstyle=hintfull and lcdfilter=lcdlegacy, using RVB sub-pixel rendering. This worked nicely, and seems to continue to work correctly on wheezy with gnome-terminal and xfce4-terminal, but not with urxvt; the the attached screenshot as an example. What I see are sligthly exagerated color fringe, that are typically associated with sub-pixel rendering, but which are here very noticable. It looks like blending is made incorrectly. This is a bit annoying to the eye. You can see it very well with w for example. BTW, I see that colord is running, but I don't know if this has some influence; I didn't calibrate my screens at all with it. I'm also running XFCE4 as desktop environment, if this is relevant; but I also whitnessed it under Gnome at home. I would be interested if some other people saw that too. Regards, benjamin -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rxvt-unicode depends on: ii base-passwd 3.5.26 ii libc6 2.13-38+deb7u1 ii libfontconfig12.9.0-7.1 ii libgcc1 1:4.7.2-5 ii libgdk-pixbuf2.0-02.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libperl5.14 5.14.2-21+deb7u1 ii libstartup-notification0 0.12-1 ii libx11-6 2:1.5.0-1+deb7u1 ii libxft2 2.3.1-1 ii libxrender1 1:0.9.7-1+deb7u1 ii ncurses-base 5.9-10 Versions of packages rxvt-unicode recommends: ii fonts-vlgothic [fonts-japanese-gothic] 20120629-2 ii ttf-dejavu 2.33-3 rxvt-unicode suggests no packages. -- no debconf information attachment: terminals-font-rendering-comparison.png
Bug#699804: [PATCH] Include dm_raid in initramfs for LVM2
[sorry for forgetting to Cc the bug while modifying it]
Hi,
I stumbled upon the same bug: converted my root LV to raid1, and
couldn't boot anymore. Furthermore, on a headless system, it was a bit
painful to get it back running. I tested adding only dm_raid to the
list of modules, and this should suffice as raid1 is in its
dependencies. The attached patch (for package lvm2, the initramfs hook
being included in it, not in initramfs-tools) will do it.
Regards,
--
benjamin
From 3365e98b9e26d0c71464632de7d09bbe8af5d63e Mon Sep 17 00:00:00 2001
From: Benjamin Cama ben...@dolka.fr
Date: Fri, 22 Nov 2013 03:54:01 +0100
Subject: [PATCH] Include dm_raid in initramfs for LVM2
Now that LVM2 can include RAID personallities, the needed module(s)
ought to be included.
---
debian/tree/lvm2/usr/share/initramfs-tools/hooks/lvm2 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/tree/lvm2/usr/share/initramfs-tools/hooks/lvm2 b/debian/tree/lvm2/usr/share/initramfs-tools/hooks/lvm2
index 79ee48e..04f6798 100755
--- a/debian/tree/lvm2/usr/share/initramfs-tools/hooks/lvm2
+++ b/debian/tree/lvm2/usr/share/initramfs-tools/hooks/lvm2
@@ -38,6 +38,6 @@ copy_exec /sbin/dmsetup
copy_exec /sbin/lvm
ln -s lvm ${DESTDIR}/sbin/vgchange
-for x in dm_mod dm_snapshot dm_mirror; do
+for x in dm_mod dm_snapshot dm_mirror dm_raid; do
manual_add_modules ${x}
done
--
1.8.4.2
Bug#680705: [PATCH] Do not include patches from packaging branch when exporting the pq
Hi everyone,
I had this issue for some times with gbp-pq (what a hard command to
type…). For me, the problem is that the branch...patch-queue/branch
commit range is silly: gitrevisions(7) tells that it includes both
commits reachable from either branch, but not both. I don't know why
this was chosen, it doesn't correspond to what I thought this command
did. Incidentally, the branch..patch-queue/branch syntax seems to do
exactly what we want: start from the merge base, only walking along the
second branch.
I'm still not at ease with gbp-pq and not very good at Debian packaging,
so maybe this is wrong, but the attached patch may fix this problem.
Regards,
--
Benjamin Cama benjamin.c...@telecom-bretagne.eu
From ee025290021367f8b9cbff6bff2b88c56d401e45 Mon Sep 17 00:00:00 2001
From: Benjamin Cama benjamin.c...@telecom-bretagne.eu
Date: Fri, 23 Aug 2013 19:03:12 +0200
Subject: [PATCH] Do not include patches from packaging branch when exporting the pq
---
gbp/git/repository.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gbp/git/repository.py b/gbp/git/repository.py
index 502a391..69f7e8a 100644
--- a/gbp/git/repository.py
+++ b/gbp/git/repository.py
@@ -1450,7 +1450,7 @@ class GitRepository(object):
options = GitArgs('-N', '-k',
'-o', output_dir)
options.add_cond(not signature, '--no-signature')
-options.add('%s...%s' % (start, end))
+options.add('%s..%s' % (start, end))
options.add_cond(thread, '--thread=%s' % thread, '--no-thread')
output, ret = self._git_getoutput('format-patch', options.args)
--
1.7.2.5
Bug#637340: Thanks for applying, but still needs some work
Hi, Thanks Christian for applying this. Still, it needs some more work, as I tested it yesterday, and the Mini doesn't like the RAID1 format used by recent mdadm. It basically only recognize “raw” RAID1, where one can read either volume directly as a normal ext2/3 partition. See #504397 (the check.d/ext2_or_ext3 file references #509799 but this ought to be this other one). I'll submit another patch report if I find some solution. For now, if one doesn't use RAID, the current check *should* work. Regards, -- benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693839: debian-installer fails on linkstation mini because of missing u-boot-tools
Hi, Could this patch be backported to wheezy? As wheezy uses version 3.3, it basically renders it uninstallable on _all_ those armel platforms (which, if I understand well, all require u-boot-tools). I just tested the very nice installer on a new Linkstation Mini, and I had to apt-get install u-boot-tools by hand to make it pass the “make bootable” step (or whatever is the english for « Rendre le système amorçable » is). Thanks, -- benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693839: debian-installer fails on linkstation mini because of missing u-boot-tools
Coucou Cyril, Le jeudi 25 juillet 2013 à 02:20 +0200, Cyril Brulebois a écrit : Benjamin Cama ben...@dolka.fr (2013-07-25): Could this patch be backported to wheezy? As wheezy uses version 3.3, it basically renders it uninstallable on _all_ those armel platforms (which, if I understand well, all require u-boot-tools). it's already queued for stable: http://release.debian.org/proposed-updates/stable.html OK, thanks, I didn't know where to look for this! The “Closes: #693839” doesn't appear because I didn't upload the package a second time with the proper flag. But you can see the full debdiff here: http://release.debian.org/proposed-updates/stable_diffs/flash-kernel_3.3+deb7u2.debdiff This bug report will be marked as fixed in said version once the point release happens. OK, thanks for the details on the release cycle. And anyway, I rendered my Mini unbootable because of the RAID1 /boot _with_ metadata that I supposed uBoot would not like; and indeed it doesn't boot anymore. I will get back to it with my serial cable later (you have to do some soldering on this thing to get it… what a PITA). Regards, (and don't forget to sleep!) -- benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704613: cdebootstrap: signature verification bypass with manipulated InRelease file
Hi, Same thing happened with debootstrap recently, see #703146 InRelease support was disabled because we can't get a proper cleartext out of this file, and modifying gpgv to get it is too much work. Regards, -- Benjamin Cama benjamin.c...@telecom-bretagne.eu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704162: Wrong sum for GTK installer initrd.gz inside netboot.tar.gz
Package: mirrors Hi, I don't really know where to file that; please reassign if I'm wrong. I recently downloaded the debian-installer netboot archive at http://debian.univ-nantes.fr/debian/dists/wheezy/main/installer-amd64/current/images/netboot/gtk/netboot.tar.gz which is the GTK version of the netboot installer (this bug doesn't affect the text version). I noticed, after unpacking it and checking for the sums, hoping that they will be the same as if I downloaded all the files individually, that they all validate except one: the initrd.gz for this installer. (I checked the sum of the .tar.gz itself, and it's OK). The sums are, e.g., here: http://debian.univ-nantes.fr/debian/dists/wheezy/main/installer-amd64/current/images/SHA256SUMS When getting directly the initrd.gz from http://debian.univ-nantes.fr/debian/dists/wheezy/main/installer-amd64/current/images/netboot/gtk/debian-installer/amd64/initrd.gz I correctly get f8971317915ed2ce8358b24ca88ea95c75ebe97a1e0a95f60c7977da368b3352 But when extracting it from the archive, I get c2103b9533baa88814e770b493e5ba93f3043f3d73ce6e018addcd7c84b22cd4 By looking closer, the uncompressed initrd from both files is the same. Only the date (from the gzip header) differs by a couple of seconds. And this only happens for the GTK installer, not the text one, once again… Furthermore, I also realized that Ubuntu is affected, too (!); the sum for the GTK installer of Precise Pangolin has the same problem. There must be a small packaging bug somewhere… Regards, -- Benjamin Cama benjamin.c...@telecom-bretagne.eu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703146: Better debootstrap InRelease handling fix
Hi,
Le mercredi 27 mars 2013 à 00:53 +0100, Bernhard R. Link a écrit :
* Benjamin Cama benjamin.c...@telecom-bretagne.eu [130326 18:33]:
index 1dc0f87..f44 100644
--- a/functions
+++ b/functions
@@ -530,8 +530,13 @@ download_release_sig () {
warning KEYRING Cannot check Release signature; keyring file
not available %s $KEYRING_WANTED
fi
if [ $release_file_variant = IN ]; then
- rm -f $reldest
-gpg --output $reldest --decrypt --keyring $KEYRING
--ignore-time-conflict $relsigdest
+ sed -n '/^-BEGIN PGP SIGNED MESSAGE-$/ { \
+ n \
+ : check_hash /^Hash:/ { n b check_hash } \
+ n # blank line \
+ } \
+ /^-BEGIN PGP SIGNATURE-$/ q \
+ p' $relsigdest $reldest
fi
}
Sorry, but this is not enough to properly extract the contents of a
inline signed message. You still need to do possible unescaping between
those lines.
You are right. Furthermore, my version didn't work with GNU sed;
attached version fix both problems (and is based on latest master, after
Julien disabled InRelease support). Please not that it will still print
what's _before_ the BEGIN header, if present (there shouldn't be
anything, but if you really want to be picky…)
Regards,
--
Benjamin Cama benjamin.c...@telecom-bretagne.eu
From 38cc6948ad7caff1df5df17cf3a21eb4228e2eda Mon Sep 17 00:00:00 2001
From: Benjamin Cama benjamin.c...@telecom-bretagne.eu
Date: Wed, 27 Mar 2013 12:51:56 +0100
Subject: [PATCH] Get back InRelease support
We can extract the cleartext with sed. Should be compatible with
RFC 4880 format.
Signed-off-by: Benjamin Cama benjamin.c...@telecom-bretagne.eu
---
functions | 50 ++
1 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/functions b/functions
index 2dc777d..7c7f84a 100644
--- a/functions
+++ b/functions
@@ -503,38 +503,64 @@ download_release_sig () {
local m1=$1
local reldest=$2
local relsigdest=$3
+ local release_file_variant=$4
if [ -n $KEYRING ] [ -z $DISABLE_KEYRING ]; then
- progress 0 100 DOWNRELSIG Downloading Release file signature
- progress_next 50
- get $m1/dists/$SUITE/Release.gpg $relsigdest nocache ||
- error 1 NOGETRELSIG Failed getting release signature file %s \
- $m1/dists/$SUITE/Release.gpg
- progress 50 100 DOWNRELSIG Downloading Release file signature
+ if [ $release_file_variant != IN ]; then
+ progress 0 100 DOWNRELSIG Downloading Release file signature
+ progress_next 50
+ get $m1/dists/$SUITE/Release.gpg $relsigdest nocache ||
+error 1 NOGETRELSIG Failed getting release signature file %s \
+$m1/dists/$SUITE/Release.gpg
+ progress 50 100 DOWNRELSIG Downloading Release file signature
+ fi
info RELEASESIG Checking Release signature
# Don't worry about the exit status from gpgv; parsing the output will
# take care of that.
- (gpgv --status-fd 1 --keyring $KEYRING --ignore-time-conflict \
- $relsigdest $reldest || true) | read_gpg_status
+ if [ $release_file_variant = IN ]; then
+ (gpgv --status-fd 1 --keyring $KEYRING --ignore-time-conflict \
+ $relsigdest || true) | read_gpg_status
+ else
+ (gpgv --status-fd 1 --keyring $KEYRING --ignore-time-conflict \
+ $relsigdest $reldest || true) | read_gpg_status
+ fi
progress 100 100 DOWNRELSIG Downloading Release file signature
elif [ -z $DISABLE_KEYRING ] [ -n $KEYRING_WANTED ]; then
warning KEYRING Cannot check Release signature; keyring file not available %s $KEYRING_WANTED
fi
+ if [ $release_file_variant = IN ]; then
+ sed -n '/^-BEGIN PGP SIGNED MESSAGE-$/ {
+n
+: check_hash /^Hash:/ { n ; b check_hash }
+n # blank line
+ }
+ s/^- //
+ /^-BEGIN PGP SIGNATURE-$/ q
+ p' $relsigdest $reldest
+ fi
}
download_release_indices () {
local m1=${MIRRORS%% *}
local reldest=$TARGET/$($DLDEST rel $SUITE $m1 dists/$SUITE/Release)
+ local inreldest=$TARGET/$($DLDEST rel $SUITE $m1 dists/$SUITE/InRelease)
local relsigdest
+ local release_file_variant=IN
progress 0 100 DOWNREL Downloading Release file
progress_next 100
- get $m1/dists/$SUITE/Release $reldest nocache ||
- error 1 NOGETREL Failed getting release file %s $m1/dists/$SUITE/Release
- relsigdest=$TARGET/$($DLDEST rel $SUITE $m1 dists/$SUITE/Release.gpg)
+ if get $m1/dists/$SUITE/InRelease $inreldest nocache; then
+ relsigdest=$inreldest
+ else
+ info RETRIEVING Failed to retrieve InRelease
+ get $m1/dists/$SUITE/Release $reldest nocache ||
+ error 1 NOGETREL Failed getting release file %s $m1/dists/$SUITE/Release
+ release_file_variant=GPG
+ relsigdest=$TARGET/$($DLDEST rel $SUITE $m1 dists/$SUITE/Release.gpg)
+ fi
progress 100 100 DOWNREL Downloading Release file
- download_release_sig $m1 $reldest $relsigdest
+ download_release_sig $m1 $reldest
Bug#703146: Better debootstrap InRelease handling fix
Le mercredi 27 mars 2013 à 13:32 +0100, Didier 'OdyX' Raboud a écrit : Le mercredi, 27 mars 2013 12.59:15, Benjamin Cama a écrit : attached version fix both problems (and is based on latest master, after Julien disabled InRelease support). Please not that it will still print what's _before_ the BEGIN header, if present (there shouldn't be anything, but if you really want to be picky…) Well, yes, we want to be picky: the whole point of checking the signature is to avoid letting unsigned content be considered valid by debootstrap / apt / etc. See CVE-2013-1051. OK, I understand. With my patch, someone could sneak in an unsigned Release before the signed one, right? I don't know if apt would parse it, but it's a problem. That said, I think I would prefer a gpgv patch to only output verified content than such sed hackery (although nice). Yes, this would be a far better solution. But a quick look at gnupg doesn't make that look easy. I'll give up on this solution for now, and let InRelease files unhandled. Thanks for the comments, -- Benjamin Cama benjamin.c...@telecom-bretagne.eu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703146: Better debootstrap InRelease handling fix
Hi,
Pulling gnupg just to extract the cleartext of a PGP signed message
seems a bit too much for me. I stumbled upon this while in
debian-installer, which didn't depend on gnupg, only pgpv, until now.
This looks really overkill. Please find attached a better fix, to me,
only using sed (and compatible with the minimal busybox sed found in
d-i). It should extract anything according to RFC 4880 cleartext signed
message format, according to my reading of it.
I don't reopen this bug as I don't know what is the policy about it
currently, but really consider my solution, please.
Regards,
--
Benjamin Cama benjamin.c...@telecom-bretagne.eu
From 169cffe3c20f36947a1604a6e1151d0f31e18de2 Mon Sep 17 00:00:00 2001
From: Benjamin Cama benjamin.c...@telecom-bretagne.eu
Date: Tue, 26 Mar 2013 18:08:32 +0100
Subject: [PATCH] Remove dependency on gnupg, extract Release with sed
Get back gnupg to Recommends, as it is only used to extract the clear
text. We can rather do that with sed, furthermore in constrained
environments like in d-i. Should be compatible with RFC 4880 format.
Signed-off-by: Benjamin Cama benjamin.c...@telecom-bretagne.eu
---
debian/control |4 ++--
functions |9 +++--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/debian/control b/debian/control
index 41af2df..0894e08 100644
--- a/debian/control
+++ b/debian/control
@@ -10,8 +10,8 @@ Vcs-Git: git://git.debian.org/d-i/debootstrap.git
Package: debootstrap
Architecture: all
-Depends: ${misc:Depends}, wget, gnupg
-Recommends: ${keyring}
+Depends: ${misc:Depends}, wget
+Recommends: gnupg, ${keyring}
Description: Bootstrap a basic Debian system
debootstrap is used to create a Debian base system from scratch,
without requiring the availability of dpkg or apt. It does this by
diff --git a/functions b/functions
index 1dc0f87..f44 100644
--- a/functions
+++ b/functions
@@ -530,8 +530,13 @@ download_release_sig () {
warning KEYRING Cannot check Release signature; keyring file not available %s $KEYRING_WANTED
fi
if [ $release_file_variant = IN ]; then
- rm -f $reldest
-gpg --output $reldest --decrypt --keyring $KEYRING --ignore-time-conflict $relsigdest
+ sed -n '/^-BEGIN PGP SIGNED MESSAGE-$/ { \
+n \
+: check_hash /^Hash:/ { n b check_hash } \
+n # blank line \
+ } \
+ /^-BEGIN PGP SIGNATURE-$/ q \
+ p' $relsigdest $reldest
fi
}
--
1.7.2.5
Bug#664219: l2tpns working nicely on squeeze here
Hi, I just wanted to say that l2tpns is working fine here on squeeze, with hundreds of users. We are using a quite modified version, though. I submitted it upstream, but there doesn't seem to be much activity. My repository is here, if you're interested: http://dolka.fr/code/l2tpns.git I /may/ think of taking over maintenance one day, as I know quite well the code now, but I am quite busy right now for that. Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680392: avahi-daemon: Name resolution not working on dual-stack setup on wheezy
, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages avahi-daemon depends on: ii adduser3.113+nmu3 ii bind9-host [host] 1:9.8.1.dfsg.P1-4.1 ii dbus 1.6.0-1 ii host 1:9.8.1.dfsg.P1-4.1 ii libavahi-common3 0.6.31-1 ii libavahi-core7 0.6.31-1 ii libc6 2.13-33 ii libcap21:2.22-1 ii libdaemon0 0.14-2 ii libdbus-1-31.6.0-1 ii libexpat1 2.1.0-1 ii lsb-base 4.1+Debian7 Versions of packages avahi-daemon recommends: ii libnss-mdns 0.10-3.2 Versions of packages avahi-daemon suggests: pn avahi-autoipd none -- no debconf information -- Benjamin Cama benjamin.c...@telecom-bretagne.eu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679011: [PATCH] Fix wrong NFS umount path
Package: klibc
Version: 2.0-2
Hi, [filing a bug report after having posted to kl...@zytor.com ]
When mounting a NFS share and an error occurs for some reason, the NFS
share is not unmounted correctly: the local path is used instead of the
remote path in the umount_v[23]() call. This patch fixes this.
I found this while debugging some problems mounting the root file system
on NFS in a test system; I saw this in the logs (/mnt/duplicated is the
legitimate remote path):
Jun 21 21:52:35 pangolin-test rpc.mountd[11155]: authenticated mount
request from 192.168.42.2:984 for /mnt/duplicated (/mnt/duplicated)
Jun 21 21:52:35 pangolin-test rpc.mountd[11155]: refused unmount
request from 192.168.42.2 for /root (/): no export entry
I didn't understand why the hell it was trying to umount /root. You can
look at google for this and you'll find a lot of people wondering what
this is. I think that the big issue with this is that _a lot_ of
problems appearing _after_ not unmounting correctly the share the first
time are caused by this: I used to get mounting errors with “Stale NFS
file handle” that would never go away (NFS is so much a PITA for this
statefull behavior). You'll find a lot of people on the net trying to
reboot their NFS server and the like, in hope this errors goes away.
It was also quite misleading that the mount point for the root FS in the
initramfs is called /root. Anyway, a lot of these problems go away with
this patch.
BTW, this bug is more than 9 years old, since the inception of nfsmount!
Signed-off-by: Benjamin Cama benjamin.c...@telecom-bretagne.eu
---
usr/kinit/nfsmount/mount.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/usr/kinit/nfsmount/mount.c b/usr/kinit/nfsmount/mount.c
index e3838f4..e0687a6 100644
--- a/usr/kinit/nfsmount/mount.c
+++ b/usr/kinit/nfsmount/mount.c
@@ -329,9 +329,9 @@ int nfs_mount(const char *pathname, const char *hostname,
bail:
if (mounted) {
if (data-flags NFS_MOUNT_VER3)
- umount_v3(path, clnt);
+ umount_v3(rem_path, clnt);
else
- umount_v2(path, clnt);
+ umount_v2(rem_path, clnt);
}
ret = -1;
--
Benjamin Cama benjamin.c...@telecom-bretagne.eu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638177: locales-all: 2.13-14 breaks locale generation
Package: locales-all Version: 2.13-14 Severity: important Hi, Short report, reportbug once again lost my report. Upgrading locales-all to 2.13-14 broke locale generation. dpkg-reconfigure locales gives: Error: invalid locale settings: LANG=fr_FR.UTF-8 History log: Start-Date: 2011-08-06 16:55:14 Commandline: apt-get dist-upgrade Upgrade: texlive-common:amd64 (2009-12, 2009-13), python-coherence:amd64 (0.6.6.2-5, 0.6.6.2-6), parcellite:amd64 (0.9.3-1, 1.0.2~rc2-1), python-notify:amd64 (0.1.1-2+b3, 0.1.1-3), update-notifier-common:amd64 (0.99.3debian9, 0.99.3debian10), libc-bin:amd64 (2.13-13, 2.13-14), python-debian:amd64 (0.1.20, 0.1.21), libcupsppdc1:amd64 (1.4.7-1, 1.4.8-2), libv4l-0:amd64 (0.8.5-1, 0.8.5-2), libmount1:amd64 (2.19.1-4, 2.19.1-5), update-notifier:amd64 (0.99.3debian9, 0.99.3debian10), libblkid1:amd64 (2.19.1-4, 2.19.1-5), foomatic-db-engine:amd64 (4.0.7-2, 4.0.8-1), libcupsimage2:amd64 (1.4.7-1, 1.4.8-2), libgtk-vnc-1.0-0:amd64 (0.4.3-4, 0.4.3-4.1), gir1.2-peas-1.0:amd64 (1.1.0-1, 1.1.1-1), libcupscgi1:amd64 (1.4.7-1, 1.4.8-2), python3.2-minimal:amd64 (3.2.1-1, 3.2.1-2), libcupsdriver1:amd64 (1.4.7-1, 1.4.8-2), iso-codes:amd64 (3.27-1, 3.27.1-1), cupsddk:amd64 (1.4.7-1, 1.4.8-2), locales-all:amd64 (2.13-13, 2.13-14), util-linux:amd64 (2.19.1-4, 2.19.1-5), libpython2.6:amd64 (2.6.7-3, 2.6.7-4), foomatic-filters:amd64 (4.0.7-1, 4.0.9-1), cups-client:amd64 (1.4.7-1, 1.4.8-2), transmission-gtk:amd64 (2.03-2, 2.03-2.1), texlive-latex-base:amd64 (2009-12, 2009-13), texlive-metapost-doc:amd64 (2009-12, 2009-13), texlive-fonts-recommended:amd64 (2009-12, 2009-13), libpcre3:amd64 (8.12-3, 8.12-4), libcpufreq0:amd64 (007-1, 007-2), gettext-base:amd64 (0.18.1.1-3, 0.18.1.1-4), libass4:amd64 (0.9.12-1, 0.9.13-1), qt3-assistant:amd64 (3.3.8b-8, 3.3.8b-10), ioquake3-server:amd64 (1.36 +svn1946-4, 1.36+svn1946-5), python2.6:amd64 (2.6.7-3, 2.6.7-4), python2.7:amd64 (2.7.2-3, 2.7.2-4), libfreetype6:amd64 (2.4.4-2, 2.4.6-1), python3.2:amd64 (3.2.1-1, 3.2.1-2), texlive-generic-recommended:amd64 (2009-12, 2009-13), gcc-4.5:amd64 (4.5.3-4, 4.5.3-5), autopoint:amd64 (0.18.1.1-3, 0.18.1.1-4), texlive-latex-recommended:amd64 (2009-12, 2009-13), libc6-i386:amd64 (2.13-13, 2.13-14), libgtk-vnc-2.0-0:amd64 (0.4.3-4, 0.4.3-4.1), cups-ppdc:amd64 (1.4.7-1, 1.4.8-2), transmission-common:amd64 (2.03-2, 2.03-2.1), libpcrecpp0:amd64 (8.12-3, 8.12-4), texlive-latex-recommended-doc:amd64 (2009-12, 2009-13), python2.6-minimal:amd64 (2.6.7-3, 2.6.7-4), p7zip:amd64 (9.20.1~dfsg.1-2, 9.20.1~dfsg.1-3), lib32asound2:amd64 (1.0.24.1-2, 1.0.24.1-3), gettext:amd64 (0.18.1.1-3, 0.18.1.1-4), texlive-latex-base-doc:amd64 (2009-12, 2009-13), locales:amd64 (2.13-13, 2.13-14), cups-common:amd64 (1.4.7-1, 1.4.8-2), openarena-server:amd64 (0.8.5-9, 0.8.5-10), openarena:amd64 (0.8.5-9, 0.8.5-10), libcups2:amd64 (1.4.7-1, 1.4.8-2), libpeas-common:amd64 (1.1.0-1, 1.1.1-1), cpufrequtils:amd64 (007-1, 007-2), libmikmod2:amd64 (3.1.11-a-6.3, 3.1.11-a-6.4), bsdutils:amd64 (2.19.1-4, 2.19.1-5), multiarch-support:amd64 (2.13-13, 2.13-14), texlive-luatex:amd64 (2009-12, 2009-13), texlive-metapost:amd64 (2009-12, 2009-13), python2.6-dev:amd64 (2.6.7-3, 2.6.7-4), manpages:amd64 (3.28-1, 3.32-0.1), cups:amd64 (1.4.7-1, 1.4.8-2), texlive-fonts-recommended-doc:amd64 (2009-12, 2009-13), libcups2-dev:amd64 (1.4.7-1, 1.4.8-2), libasound2:amd64 (1.0.24.1-2, 1.0.24.1-3), libfreetype6-dev:amd64 (2.4.4-2, 2.4.6-1), libmx-1.0-2:amd64 (1.2.0-1, 1.3.0-1), cups-bsd:amd64 (1.4.7-1, 1.4.8-2), libasm3-java:amd64 (3.2-4, 3.3.1-1), qt3-doc:amd64 (3.3.8b-8, 3.3.8b-10), uuid-dev:amd64 (2.19.1-4, 2.19.1-5), texlive-base:amd64 (2009-12, 2009-13), python-minimock:amd64 (1.2.6-1, 1.2.6-2), libc6-dbg:amd64 (2.13-13, 2.13-14), libuuid1:amd64 (2.19.1-4, 2.19.1-5), gcc-4.5-base:amd64 (4.5.3-4, 4.5.3-5), libc6-dev:amd64 (2.13-13, 2.13-14), xpdf:amd64 (3.02-20, 3.02-21), python2.7-minimal:amd64 (2.7.2-3, 2.7.2-4), libpeas-1.0-0:amd64 (1.1.0-1, 1.1.1-1), foomatic-db:amd64 (20110617-1, 20110803-1), libgvnc-1.0-0:amd64 (0.4.3-4, 0.4.3-4.1), libpcre3-dev:amd64 (8.12-3, 8.12-4), cpp-4.5:amd64 (4.5.3-4, 4.5.3-5), mount:amd64 (2.19.1-4, 2.19.1-5), texlive-pictures:amd64 (2009-12, 2009-13), libqt3-mt:amd64 (3.3.8b-8, 3.3.8b-10), manpages-dev:amd64 (3.28-1, 3.32-0.1), ioquake3:amd64 (1.36 +svn1946-4, 1.36+svn1946-5), xmame-x:amd64 (0.143-2, 0.143-3), lib32v4l-0:amd64 (0.8.5-1, 0.8.5-2), libcupsmime1:amd64 (1.4.7-1, 1.4.8-2), libc-dev-bin:amd64 (2.13-13, 2.13-14), libvigraimpex3:amd64 (1.7.1+dfsg1-1, 1.7.1+dfsg1-2), libc6:amd64 (2.13-13, 2.13-14), binutils:amd64 (2.21.53.20110729-1, 2.21.53.20110805-1), texlive-pictures-doc:amd64 (2009-12, 2009-13), p7zip-full:amd64 (9.20.1~dfsg.1-2, 9.20.1~dfsg.1-3), mame:amd64 (0.143-2, 0.143-3) End-Date: 2011-08-06 16:58:41 Uninstalling it solves the problem. I wondered why this package was installed anyway and found that: Start-Date: 2011-04-25 12:33:45 Commandline: apt-get dist-upgrade Install: locales-all:amd64 (2.11.2-13, automatic),
Bug#638177: locales-all: 2.13-14 breaks locale generation
Le mercredi 17 août 2011 à 14:42 +0200, Aurelien Jarno a écrit : On Wed, Aug 17, 2011 at 01:05:58PM +0200, Benjamin Cama wrote: Package: locales-all Version: 2.13-14 Severity: important Hi, Short report, reportbug once again lost my report. Not it didn't. Closing the duplicate one. Could you give me the bug number then, please? Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638173: locales-all 2.13-14 breaks locale generation
Le mercredi 17 août 2011 à 14:48 +0200, Aurelien Jarno a écrit : On Wed, Aug 17, 2011 at 12:46:25PM +0200, Benjamin wrote: Package: locales-all Version: 2.13-14 Severity: important Tags: sid Hi, Some days ago, locales-all got upgraded on my system during a dist-upgrade, and I didn't notice it. After a reboot some time later, I lost my locale What do you mean by I lost my locale? Did you do something special? I mean that after I rebooted, the current locale was now C and I couldn't change for another one. Accents and others non-ASCII stuff got screwed up in many applications. The only action I took was rebooting some days after upgrading to 2.13-14 (I don't reboot very often), and that caused this “lost” locale. (fr_FR.UTF-8) and dpkg-reconfigure could not generate it back with this With locales-all, locales are not generated, that's actually the goal of locales-all. Which command did you run? dpkg-reconfigure locales, choose fr_FR.UTF-8, select it as default for the system. I never meant to install locales-all at first, I don't know how it stepped in some months ago. The strange thing is that this problem only happened when upgrading locales-all to 2.13-14: it didn't cause any problem before. Anyway, with locales-all (2.13-14) installed, I _couldn't_ get any other locale than C to work. message: Error: invalid locale settings: LANG=fr_FR.UTF-8 It means that this locale was not installed on the system. Well, the purpose of dpkg-reconfigure locales is to generate the local so that it's “installed” on the system, isn't it? Still, I'm wondering why this package was installed, as I don't seem to need it. I found that: Start-Date: 2011-04-25 12:33:45 Commandline: apt-get dist-upgrade Install: locales-all:amd64 (2.11.2-13, automatic), lzma:amd64 (4.43-14, automatic) Upgrade: ca-certificates-java:amd64 (20100412, 20110421~nmu1) End-Date: 2011-04-25 12:34:03 So, maybe this is rather a bug from ca-certificates-java? I don't really know. Well I don't get it. As fard as I can see nor ca-certificates-java nor its dependencies depends on locales-all. Me neither. After a bit of research: #623672 led to version 20110421~nmu1 as a “fix” which depends on locales-all. On my machine, ca-certificates-java was upgraded to version 20110426 the day after 20110421~nmu1 was installed. But locales-all resisted apt-get autoremove, I suppose. I don't why. Anyway, this seems to be a transitional problem only, maybe you can close it. Thanks for your time, though, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637339: debian-installer: Adapt the script to run d-i to the Linkstation Mini.
Package: debian-installer
Version: 20110106+squeeze3
Severity: wishlist
Tags: patch
X-Debbugs-CC: Martin Michlmayr t...@cyrius.com
Hi,
Attached is a patch to add support for the Buffalo Linkstation Mini into
the script used to run d-i. Reviewed by Martin Michlmayr, I included his
suggestions.
Regards,
benjamin
diff --git a/build/boot/arm/lspro-config-debian b/build/boot/arm/lspro-config-debian
index 05e979e..95be499 100644
--- a/build/boot/arm/lspro-config-debian
+++ b/build/boot/arm/lspro-config-debian
@@ -5,19 +5,19 @@
NVRAM=$(which nvram)
FW_PRINTENV=$(which fw_printenv)
-path=$(mount | grep ext[23] | sed -n '/sda1/ {s/\/dev\/sda1 on \(.*\) type.*/\1/; p}')
+path=$(mount | grep ext[23] | sed -n '/sda1\|md0/ {s/\/dev\/\(sda1\|md0\) on \(.*\) type.*/\2/; p}')
if [ -z $path ]; then
- echo You have to create an ext2 filesystem on /dev/sda1
+ echo You have to create an ext2 filesystem on /dev/sda1 or /dev/md0
exit 1
fi
if [ ! -e $path/uImage.buffalo ]; then
- echo You have to download the uImage.buffalo file from the debian-installer for Linkstation Pro/Live, and put it in $path
+ echo You have to download the uImage.buffalo file from the debian-installer for Linkstation, and put it in $path
exit 1
fi
if [ ! -e $path/initrd.buffalo ]; then
- echo You have to download the initrd.buffalo file from the debian-installer for Linkstation Pro/Live, and put it in $path
+ echo You have to download the initrd.buffalo file from the debian-installer for Linkstation, and put it in $path
exit 1
fi
diff --git a/build/config/armel/orion5x/network-console.cfg b/build/config/armel/orion5x/network-console.cfg
index 61efb6e..7e86100 100644
--- a/build/config/armel/orion5x/network-console.cfg
+++ b/build/config/armel/orion5x/network-console.cfg
@@ -60,6 +60,8 @@ lsmini:
cp $(TEMP)/ls-wsgl/kernel.uboot $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/uImage.buffalo
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0200 -e 0x0200 -n debian-installer ramdisk -d $(TEMP_INITRD) $(TEMP)/ls-wsgl/initrd.uboot
cp $(TEMP)/ls-wsgl/initrd.uboot $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/initrd.buffalo
+ install -m 744 boot/arm/lspro-config-debian $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/config-debian
+ update-manifest $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/config-debian Script to run debian-installer
update-manifest $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/uImage.buffalo Linux kernel for Linkstation Mini
update-manifest $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/initrd.buffalo initrd for Linkstation Mini
Bug#637340: partman-ext3: check for ext[23] /boot on Linkstation Mini too
Package: partman-ext3 Version: 65 Severity: wishlist Tags: patch X-Debbugs-CC: Martin Michlmayr t...@cyrius.com Hi, Attached is a patch to add a check for the Buffalo Linkstation Mini as it's being supported by d-i. Linkstation LiveV3 might also be included one day, but I can't test this as I don't have the hardware. Regards, benjamin diff --git a/check.d/ext2_or_ext3_boot b/check.d/ext2_or_ext3_boot index cde0de0..e32d795 100755 --- a/check.d/ext2_or_ext3_boot +++ b/check.d/ext2_or_ext3_boot @@ -8,7 +8,8 @@ case $ARCH in arm*) machine=$(grep ^Hardware /proc/cpuinfo | sed 's/Hardware\s*:\s*//') || true case $machine in - Buffalo Linkstation Pro/Live | Buffalo/Revogear Kurobox Pro) + Buffalo Linkstation Pro/Live | Buffalo/Revogear Kurobox Pro \ + | Buffalo Linkstation Mini) ;; GLAN Tank) ;;
Bug#637339: Debian installer for Buffalo LS Live (LS-CHL) and Mini (LS-WSGL)
Hi Hector, Le mercredi 10 août 2011 à 16:27 +0100, Hector Oron a écrit : 2011/8/10 Martin Michlmayr t...@cyrius.com: * Benjamin Cama ben...@free.fr [2011-08-04 18:20]: Thanks. I will submit this patch if you think it's ok. Sure. Presumably Hector Oron will apply the patch for you when you file a bug. Sure, but I'll need Benjamin to test it, as I do not own such device. As I said some time ago in this thread, I don't have the original system on my Mini anymore, and it's too much burden for me to install it back just to test that, sorry. Still, I “tested” this script by running it on my lsmini with Debian, with busybox applets for mount/grep/sed, and it worked OK. I know this isn't really a true /real/ conditions testing, but it looks “right enough” to me. Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579996: BIRD really needs a manpage
Hi, I second this request. The bird binary doesn't even have an extended help where command line options are explained. There isn't even a readme. The only way to know more about how to use it is the web documentation. Quite bad. Thanks, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636214: u-boot-tools: /etc/fw_env.config for Buffalo Linkstation Mini
Package: u-boot-tools Version: 2011.03-6 Severity: wishlist Tags: patch Hi, I don't know exactly where this belongs, but here is the fw_env.config needed for the Buffalo Linkstation Mini (as such in /proc/cpuinfo). I see there are no other config in this package except in bug reports, so I'm not sure this is the right place, but it would be nice if some tool could detect the current platform and use the proper values for fw_printenv/saveenv. Regards, benjamin # Configuration file for fw_(printenv/saveenv) utility. # Up to two entries are valid, in this case the redundand # environment sector is assumed present. # for Buffalo Linkstation Mini # MTD device name Device offset Env. size Flash sector size /dev/mtd0 0x3f000 0x01000 0x01000
Bug#620082: pulseaudio: Spams the system log when out of disk space, making the problem worse
Package: pulseaudio Version: 0.9.21-4 Severity: normal Hi, Today I was hit by a full up disk problem that caused the bug I am talking about; pulseaudio then fills up /var/log/syslog with the following messages, every 5 seconds (yes, these are localized): Mar 29 22:59:21 nsk pulseaudio[18495]: pid.c: Failed to write PID file. Mar 29 22:59:21 nsk pulseaudio[18495]: main.c: Échec de pa_pid_file_create(). Mar 29 22:59:21 nsk pulseaudio[18493]: main.c: Échec lors du démarrage du démon. I think it cannot write the PID file because the disk is full, but spaming the log like that worsen the problem, as /var is not on a separate partition here. BTW, I found out about this problem because pulseaudio was also stuck at 100% CPU (don't know if it's related; it's not like it's the first time I see that…) I don't know exactly what it should do, but I see a lot of problem with pulseaudio trying harder when things fail: sometime, it's better to just give up. Regards, benjamin PS: my changed config file is just some lines I commented; no actual change -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pulseaudio depends on: ii adduser 3.112+nmu2 add and remove users and groups ii consolekit0.4.4-1framework for defining and trackin ii libasound21.0.23-2.1 shared library for ALSA applicatio ii libc6 2.11.2-13 Embedded GNU C Library: Shared lib ii libcap2 1:2.20-1 support for getting/setting POSIX. ii libdbus-1-3 1.4.6-1simple interprocess messaging syst ii libgdbm3 1.8.3-9GNU dbm database routines (runtime ii libice6 2:1.0.7-1 X11 Inter-Client Exchange library ii libltdl7 2.2.6b-2 A system independent dlopen wrappe ii libpulse0 0.9.21-4 PulseAudio client libraries ii libsamplerate00.1.7-3Audio sample rate conversion libra ii libsm62:1.2.0-1 X11 Session Management library ii libsndfile1 1.0.24-1 Library for reading/writing audio ii libspeexdsp1 1.2~rc1-1 The Speex extended runtime library ii libudev0 166-1 libudev shared library ii libx11-6 2:1.4.2-1 X11 client-side library ii libxtst6 2:1.2.0-1 X11 Testing -- Record extension li ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip ii udev 166-1 /dev/ and hotplug management daemo Versions of packages pulseaudio recommends: ii gstreamer0.10-pulseaudio 0.10.28-2 GStreamer plugin for PulseAudio ii libasound2-plugins 1.0.23-1+b1 ALSA library additional plugins ii pulseaudio-esound-compat 0.9.21-4PulseAudio ESD compatibility layer ii pulseaudio-module-x110.9.21-4X11 module for PulseAudio sound se Versions of packages pulseaudio suggests: ii paman 0.9.4-1PulseAudio Manager ii paprefs 0.9.9-2PulseAudio Preferences ii pavucontrol 0.9.9-1PulseAudio Volume Control ii pavumeter 0.9.3-1PulseAudio Volume Meter ii pulseaudio-utils 0.9.21-4 Command line tools for the PulseAu -- Configuration Files: /etc/pulse/daemon.conf changed [not included] -- 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#616326: oldsys-preseed support for LS-WSGL
Package: oldsys-preseed Version: 3.11 Severity: wishlist X-Debbugs-CC: Martin Michlmayr t...@cyrius.com Here is a first try at supporting the Buffalo Linkstation Mini (aka LS-WSGL) for d-i, in response to advices from Martin Michlmayr. Le mardi 01 mars 2011 à 18:33 +, Martin Michlmayr a écrit : Can you please file a wishlist bug on oldsys-preseed to support this device? Right here. It would also be great if you could check out oldsys-preseed from git: git://git.debian.org/git/d-i/oldsys-preseed and send a patch. Here is a first try; I don't know what other file to modify. Is there something to do in tests/arm/? diff --git a/oldsys-preseed b/oldsys-preseed index ac97cd3..9a64f50 100755 --- a/oldsys-preseed +++ b/oldsys-preseed @@ -153,14 +153,15 @@ case `archdetect` in fi umount $path/rootfs || true rmdir $path/rootfs $path || true - elif echo $machine | grep -q ^Buffalo Linkstation Pro/Live; then + elif echo $machine | grep -q ^Buffalo Linkstation Pro/Live || + echo $machine | grep -q ^Buffalo Linkstation Mini; then # the default filesystem for the system partition is XFS, which isn't included # in our startup environment. However, customized boxes might have ext3 # instead, so try to mount anyway. - rootdev=/dev/sda2 path=/tmp/oldsys-preseed mkdir -p $path/rootfs - mount -o ro $rootdev $path/rootfs || true + mount -o ro /dev/sda2 $path/rootfs || + mount -o ro /dev/md1 $path/rootfs || true INTERFACE=eth0 parse_unix_tree $path/rootfs info=$path/rootfs/etc/melco/info Furthermore, I don't really see the point with what unset_matching_var does, but the naming scheme for the Mini is indeed the same (i.e. MAC appended to the hostname). Please note that I didn't actually tested this code on the device; I don't know how to test all this d-i stuff. Looks at the code that is there for the LS Pro already. Can this be adapted for the Mini? Does the Mini use ext2/3 of XFS by default? (The LS Pro uses XFS, which we cannot read in Debian.) The Mini use XFS as rootfs too, but /boot is ext3 (which is not of interest here for oldsys-preseed, but may help for further support of the Mini). So, I don't really see a point in preseeding it too, as people having enough skill customizing their box would rather use some other parameters, IMHO (I didn't even use the original system on this device, I directly installed Debian; which means that I may not be able to test all that backward checking stuff) BTW, the uboot command-line tell the kernel the root is on /dev/sda2, but I'm quite sure the real root is /dev/md1 which is the software RAID1 device formed by /dev/sda2 and /dev/sdb2. All the informations found on http://buffalo.nas-central.org/wiki/LS_Mini:_Serial_Port_Output_-_Boot-Log made me realize that the root fs is /dev/root on the original firmware, which doesn't help here, but I think the initrd may indeed use /dev/sda2 as a single FS (is it even possible if the device is used as a part of a md array?) before pivot/switching root to the md1 array. Hope this helps. Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590105: Same problem on LS-WSGL
Le lundi 28 février 2011 à 18:50 +, Martin Michlmayr a écrit : Fortunately, LS Mini support is in the kernel in Debian, so I just gave you a kernel image that loads Mini support. OK, thanks. I just checked out the mach-type setting for kernel images here http://buffalo.nas-central.org/wiki/Buffalo_ARM9_Kernel_Port It's sad it isn't autodetected. Still, I managed to install Debian via the installer with your image, and these tweaks. Anyway, in order to support the LS Mini in Debian and the installer, we need to add support in flash-kernel, oldsys-preseed, libdebian-installer and the installer build script. I'll look into adding that. I can help for that. I have serial console access and I'm ready to try different builds. BTW, there's nothing to flash (appart from kernel boot prameters) on the Mini as the kernel is loaded directly from the disk (images must be present on both sda1 and sdb1, on an ext2/3 FS). I'm still trying to figure out the correct uboot-envtools (fw_setenv) parameters to change the bootargs from Debian. Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590105: #590105
Hi Antonios, Le dimanche 27 février 2011 à 14:54 +, Antonios Galanopoulos a écrit : The problem persists with the new 2.6.37 based installer although the dmesg output from Benjamin is much different from mine and the original bug reporter. The relevant dmesg output: [ 29.436956] libata version 3.00 loaded. [ 29.507060] sata_mv sata_mv.0: version 1.28 [ 29.512272] sata_mv sata_mv.0: slots 32 ports 2 [ 29.523390] scsi0 : sata_mv [ 29.528183] scsi1 : sata_mv [ 29.533771] ata1: SATA max UDMA/133 irq 29 [ 29.537947] ata2: SATA max UDMA/133 irq 29 [ 29.886113] ata1: SATA link down (SStatus 0 SControl 300) [ 30.236116] ata2: SATA link down (SStatus 0 SControl 300) So, 2.6.37 is the same as 2.6.32 for you too, right? My NAS hasnt't got a serial and is not a wsgl so I thought it will not work. I am more than happy to do so if it helps. Actually, looking at what /proc/cpuinfo gave me with Martin's version, i.e. a correct Linkstation Mini machine type, the fix might just be that my machine type was not enabled in the lspro kernel. I tried looking for your machine type in upstream sources, but didn't even found it in the latest kernel; are you sure your NAS is even supported upstream? Does Buffalo give kernel sources for your NAS version? BTW, I don't even know if machine type can be autodetected? As making separate images for each NAS would be quite cumbersome. Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590105: Same problem on LS-WSGL
reopen 590105
thanks
Hi,
Contrary to what the bug title says, Sébastien didn't really want
support for LS-CHL at first, but rather fix its disks not being
recognized. As Antonios says, this disk controller problem also happen
on LS-WTGL, and I confirm it on LS-WSGL too (with the latest installer
from
http://people.debian.org/~joeyh/d-i/armel/images/daily/orion5x/network-console/buffalo/lspro/
with 2.6.37-1), both of which are supported by current (2.6.32) kernel, at
least. So I am reopening this bug. If someone think a new bug should be opened,
please tell me.
The relevant logs are (same on both .32 and .37):
[ 29.544309] sata_mv sata_mv.0: version 1.28
[ 29.549592] sata_mv sata_mv.0: slots 32 ports 2
[ 29.560892] scsi0 : sata_mv
[ 29.566986] scsi1 : sata_mv
[ 29.571302] ata1: SATA max UDMA/133 irq 29
[ 29.575414] ata2: SATA max UDMA/133 irq 29
[ 29.926337] ata1: SATA link down (SStatus 0 SControl 300)
[ 30.436355] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 30.476402] ata2.00: ATA-8: SAMSUNG HM500LI, 2TF00_00, max UDMA7
[ 30.482417] ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth
31/32)
[ 30.526422] ata2.00: configured for UDMA/133
[ 30.531398] scsi 1:0:0:0: Direct-Access ATA SAMSUNG HM500LI
2TF0 PQ: 0 ANSI: 5
[ 30.690100] sd 1:0:0:0: [sda] 976773168 512-byte logical blocks: (500
GB/465 GiB)
[ 30.702478] sd 1:0:0:0: [sda] Write Protect is off
[ 30.707342] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 30.707664] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 31.218218] sda: sda1 sda2 sda4 sda5 sda6
[ 31.229352] sd 1:0:0:0: [sda] Attached SCSI disk
[ 41.447884] ata2: exception Emask 0x10 SAct 0x0 SErr 0x18 action
0x6 frozen
[ 41.447925] ata2: edma_err_cause=0020 pp_flags=0003,
SError=0018
[ 41.447971] ata2: SError: { 10B8B Dispar }
[ 41.448031] ata2: hard resetting link
[ 41.796329] ata2: SATA link down (SStatus 0 SControl 300)
[ 46.796286] ata2: hard resetting link
[ 47.146330] ata2: SATA link down (SStatus 0 SControl 300)
[ 47.146389] ata2: limiting SATA link speed to 1.5 Gbps
[ 52.145849] ata2: hard resetting link
[ 52.496081] ata2: SATA link down (SStatus 0 SControl 310)
[ 52.496139] ata2.00: disabled
[ 52.496208] ata2: EH complete
[ 52.496270] ata2.00: detaching (SCSI 1:0:0:0)
[ 52.501243] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[ 52.519709] sd 1:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK
[ 52.519765] sd 1:0:0:0: [sda] Stopping disk
[ 52.519905] sd 1:0:0:0: [sda] START_STOP FAILED
[ 52.519934] sd 1:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK
I read here http://marc.info/?l=linux-idem=129113801605282w=3 that it
may be a timing issue. This is only a workaround I think, and this bug
should be properly fixed, but I think it may help for now. But I don't
know how to test that fix…
Regards,
benjamin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590105: Same problem on LS-WSGL
Le vendredi 25 février 2011 à 10:41 +0100, Benjamin Cama a écrit : The relevant logs are (same on both .32 and .37): And the result of hw-report for my NAS: uname -a: Linux debian 2.6.37-1-orion5x #1 Thu Feb 17 07:03:57 UTC 2011 armv5tel GNU/Linux lsmod: Module Size Used by lsmod: sd_mod 30360 0 lsmod: crc_t10dif 1134 1 sd_mod lsmod: sata_mv23263 0 lsmod: libata145360 1 sata_mv lsmod: scsi_mod 145935 2 sd_mod,libata lsmod: mv643xx_eth22590 0 lsmod: inet_lro4980 1 mv643xx_eth df: Filesystem 1K-blocks Used Available Use% Mounted on df: tmpfs62912 4 62908 0% /dev free: total used free shared buffers free: Mem: 12582822956 1028720 0 free: Swap:000 free: Total: 12582822956 102872 /proc/cmdline: console=ttyS0,115200 root=/dev/sda2=rw panic=5 BOOTVER=1.23 tftpboot=yes /proc/cpuinfo: Processor: Feroceon rev 0 (v5l) /proc/cpuinfo: BogoMIPS : 266.24 /proc/cpuinfo: Features : swp half thumb fastmult edsp /proc/cpuinfo: CPU implementer : 0x41 /proc/cpuinfo: CPU architecture: 5TEJ /proc/cpuinfo: CPU variant : 0x0 /proc/cpuinfo: CPU part : 0x926 /proc/cpuinfo: CPU revision : 0 /proc/cpuinfo: /proc/cpuinfo: Hardware : Buffalo Linkstation Pro/Live /proc/cpuinfo: Revision : /proc/cpuinfo: Serial : /proc/iomem: -07ff : System RAM /proc/iomem: 00029000-00389c5f : Kernel text /proc/iomem: 0038a000-0041ca07 : Kernel data /proc/iomem: f1011000-f101101f : mv64xxx_i2c.0 /proc/iomem: f1011000-f101101f : mv64xxx_i2c adapter /proc/iomem: f1012000-f10120ff : serial8250.0 /proc/iomem: f1012000-f101201f : serial /proc/iomem: f1012100-f10121ff : serial8250.1 /proc/iomem: f1012100-f101211f : serial /proc/iomem: f105-f1050fff : orion-ehci.0 /proc/iomem: f1060900-f10609ff : xor low /proc/iomem: f1060b00-f1060bff : xor high /proc/iomem: f1072000-f1073fff : mv643xx_eth.0 /proc/iomem: f108-f1084fff : sata base /proc/iomem: f109-f109 : regs /proc/iomem: f10a-f10a0fff : orion-ehci.1 /proc/iomem: f220-f2201fff : sram /proc/iomem: f400-f403 : physmap-flash.0 /proc/iomem: f400-f403 : physmap-flash.0 /proc/interrupts:CPU0 /proc/interrupts: 0: 7853 orion_irq orion_tick /proc/interrupts: 3:280 orion_irq serial /proc/interrupts: 4:273 orion_irq serial /proc/interrupts: 5: 57 orion_irq mv64xxx_i2c /proc/interrupts: 21:239 orion_irq eth0 /proc/interrupts: 22: 37 orion_irq mv643xx_eth /proc/interrupts: 29: 46 orion_irq sata_mv /proc/interrupts: 30: 2 orion_irq mv_xor.0 /proc/interrupts: 31: 2 orion_irq mv_xor.1 /proc/interrupts: Err: 0 /proc/meminfo: MemTotal: 125828 kB /proc/meminfo: MemFree: 102872 kB /proc/meminfo: Buffers: 0 kB /proc/meminfo: Cached:10536 kB /proc/meminfo: SwapCached:0 kB /proc/meminfo: Active:13872 kB /proc/meminfo: Inactive: 4052 kB /proc/meminfo: Active(anon): 7392 kB /proc/meminfo: Inactive(anon):0 kB /proc/meminfo: Active(file): 6480 kB /proc/meminfo: Inactive(file): 4052 kB /proc/meminfo: Unevictable: 0 kB /proc/meminfo: Mlocked: 0 kB /proc/meminfo: SwapTotal: 0 kB /proc/meminfo: SwapFree: 0 kB /proc/meminfo: Dirty: 0 kB /proc/meminfo: Writeback: 0 kB /proc/meminfo: AnonPages: 7412 kB /proc/meminfo: Mapped: 2632 kB /proc/meminfo: Shmem: 4 kB /proc/meminfo: Slab: 2764 kB /proc/meminfo: SReclaimable: 1076 kB /proc/meminfo: SUnreclaim: 1688 kB /proc/meminfo: KernelStack: 432 kB /proc/meminfo: PageTables: 508 kB /proc/meminfo: NFS_Unstable: 0 kB /proc/meminfo: Bounce:0 kB /proc/meminfo: WritebackTmp: 0 kB /proc/meminfo: CommitLimit: 62912 kB /proc/meminfo: Committed_AS: 15216 kB /proc/meminfo: VmallocTotal: 868352 kB /proc/meminfo: VmallocUsed: 260 kB /proc/meminfo: VmallocChunk: 867580 kB -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590105: Same problem on LS-WSGL
Le vendredi 25 février 2011 à 12:35 +, Martin Michlmayr a écrit : LS-WSGL is the LS mini, right? Yes. I'm using the lspro image thinking it also supports the mini. Then I'm wondering: does it really support it? benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590105: Same problem on LS-WSGL
Le vendredi 25 février 2011 à 15:22 +, Martin Michlmayr a écrit : Can you boot the following installer image and see if it boots and finds your disk properly? (The installer itself won't work; I just want to know if it boots). It boots and find my disks properly, thanks! I just tried to mount a partition and ls from it, and it works. BTW, you did not preseed the image with any parameters, but luckilly I have a serial console access to the NAS. Please send me the complete boot log. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-orion5x (Debian 2.6.32-29) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Sat Dec 11 09:47:14 UTC 2010 [0.00] CPU: Feroceon [41069260] revision 0 (ARMv5TEJ), cr=a0053177 [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: Buffalo Linkstation Mini [0.00] Clearing invalid memory bank 0KB@0x [0.00] Clearing invalid memory bank 0KB@0x [0.00] Clearing invalid memory bank 0KB@0x [0.00] Ignoring unrecognised tag 0x [0.00] Ignoring unrecognised tag 0x [0.00] Ignoring unrecognised tag 0x [0.00] Ignoring unrecognised tag 0x41000403 [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 32768 [0.00] free_area_init_node: node 0, pgdat c038a228, node_mem_map c03f3000 [0.00] Normal zone: 256 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 32512 pages, LIFO batch:7 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: console=ttyS0,115200 root=/dev/sda2 panic=5 rw BOOTVER=1.23 tftpboot=yes [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 128MB = 128MB total [0.00] Memory: 121768KB available (3224K code, 573K data, 128K init, 0K highmem) [0.00] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:64 [0.00] Console: colour dummy device 80x30 [ 25.770122] Calibrating delay loop... 265.42 BogoMIPS (lpj=1327104) [ 26.009972] Security Framework initialized [ 26.010018] SELinux: Disabled at boot. [ 26.010078] Mount-cache hash table entries: 512 [ 26.010801] Initializing cgroup subsys ns [ 26.010835] Initializing cgroup subsys cpuacct [ 26.010864] Initializing cgroup subsys devices [ 26.010892] Initializing cgroup subsys freezer [ 26.010920] Initializing cgroup subsys net_cls [ 26.011043] CPU: Testing write buffer coherency: ok [ 26.012717] devtmpfs: initialized [ 26.016110] regulator: core version 0.5 [ 26.016592] NET: Registered protocol family 16 [ 26.017736] Orion ID: MV88F5182-A2. TCLK=16667. [ 26.019474] lsmini_init: finished [ 26.023239] bio: create slab bio-0 at 0 [ 26.024044] vgaarb: loaded [ 26.025684] Switching to clocksource orion_clocksource [ 26.037944] NET: Registered protocol family 2 [ 26.038584] IP route cache hash table entries: 1024 (order: 0, 4096 bytes) [ 26.040712] TCP established hash table entries: 4096 (order: 3, 32768 bytes) [ 26.041015] TCP bind hash table entries: 4096 (order: 2, 16384 bytes) [ 26.041179] TCP: Hash tables configured (established 4096 bind 4096) [ 26.041210] TCP reno registered [ 26.041647] NET: Registered protocol family 1 [ 26.042123] Unpacking initramfs... [ 26.926166] Freeing initrd memory: 3972K [ 26.926353] NetWinder Floating Point Emulator V0.97 (double precision) [ 26.927131] audit: initializing netlink socket (disabled) [ 26.927219] type=2000 audit(1.150:1): initialized [ 26.947341] VFS: Disk quotas dquot_6.5.2 [ 26.948120] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 26.948477] msgmni has been set to 245 [ 26.950344] alg: No test for stdrng (krng) [ 26.950691] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 26.950732] io scheduler noop registered [ 26.950757] io scheduler anticipatory registered [ 26.950784] io scheduler deadline registered [ 26.951390] io scheduler cfq registered (default) [ 26.968170] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled [ 26.969378] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 3) is a 16550A [ 27.308977] console [ttyS0] enabled [ 27.313477] physmap platform flash device: 0004 at f400 [ 27.319669] Found: SST 39LF020 [ 27.322751] physmap-flash.0: Found 1 x8 devices at 0x0 in 8-bit bank [ 27.329188] number of JEDEC chips: 1 [ 27.332769] cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. [ 27.353177] RedBoot
Bug#613381: Workaround ?
Hi, Could we _at least_ have a workaround for that? As it seems the change is not going to happen soon. Chromium fucked-up my default browser choice, and now I've no easy way to change that, and I don't even know where to look to fix that by hand. What's the workaround ? Regards, Benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613381: Workaround
Ok, actually, the workaround is here : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612985#31 Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612985: Partially bad workaround
Hi, Modifying ~/.local/share/applications/defaults.list doesn't work here (and I don't see any other place where it could be overridden). But changing /etc/gnome/defaults.list works; even if I find it not optimal as I would like to only change the default browser for me, not system-wide. Regards, Benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589701: ofpath is not compatible with non-builtin disk controllers
Hi Rick, Le vendredi 24 septembre 2010 à 15:53 -0400, Rick Thomas a écrit : First, let me apologize for the confusing non-specificity of my bug reports to you and everyone else who is following this (and related) bug(s). The only excuse I can offer is that at the time I was submitting them, I wasn't sure what was causing the symptoms I was seeing. All I knew was that I couldn't do a squeeze install or an upgrade from lenny to squeeze. And I was frustrated by the total lack of response. Well, even if you didn't mention it explicitly, it was listed in the lspci dump since the beginning and nobody saw it until now. And one may also find it disturbing that a piece of software doesn't work with an addon card on a machine that has free slots to add such cards ! But bootstrapping an OS on non-original hardware modification is always a bit hard. That said, and trying to go forward, the question now is Where do we stand on getting this fixed? If you are talking about this specific bug, the answer is fix ofpath. But actually, a more efficient thing to do would be to use ofpathname, or rather ofpathname + ofpath/yaboot fixes. Which was to be done by Aurélien more than 3 years ago, see #405337 … Anyway, grub2 uses ofpathname, so I think we should try to use it. Or, first, upgrade it, as it lacks a bit behind upstream (1.2.1 vs 1.1.0). Again, the maintainer is Aurélien, who didn't give signs of life since his email 2 weeks ago, so he may be MIA and the upgrade a bit harder than we can hope. Can we come up with a list of specific problems -- and a 'todo' list of release-critical things that need to be fixed for PowerPC Debian Squeeze? I see #587290 (merged with #580455) and #572869. I think the last one is no more related to yours, even if a patch to use ofpathname would easily fix it, I think. The first one should be fixed by your patch. In that line, we need a list of individual folks who are interested in contributing to this effort. Is this bug report (589701) a good one to encourage all these folks to subscribe to in the interest of centralized record-keeping? I am not sure that polluting this report is a good idea. I would prefer opening another one if there is a clearly defined point of view on that. Which we don't have for now, I fear, because of a lack of concrete result. Which may be partially solved with my next email… benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589701: ofpath is not compatible with non-builtin disk controllers
Hi Rick, I am a bit disappointed about how this is ending, but I just realized you are using an addon Promise card as disk controller. This is not supported by ofpath, which just handle IDE controllers using the old ATA stack or true SCSI controllers. In short, it is hardwired for a list of disk controllers. Your bug is a bit different from #572869, even if he's also using a SATA (so, new ATA stack) controller, but this is the Apple provided one, and yaboot has a special case for it (even if it seems not to work so well for now). I don't really know what to do about that. From what I read (#372186), ofpathname is better for recent controllers using the new ATA stack, and it's what grub2 is using. Still, it may lack proper handling of old controllers, even if we can see (again) people willing to bring that from ofpath, without much result. Furthermore, since 2.6.34, benh wrote a new driver (macio) for newworld Macs (I don't know if it supports /all/ machines) that is based on the new ATA stack, so ofpath will need to support it soon (well, it's for after squeeze at least), or we'll need to switch to ofpathname (or grub2 alltogether). Anyway, thanks for your perseverance, but try to be more specific on your problems next time ;-) Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580455: #580455 yabootconfig does the correct thing, your yaboot.conf must be modified by something else
merge 580455 587290 Hi, Le dimanche 19 septembre 2010 à 03:59 -0400, Rick Thomas a écrit : Sep 19 06:49:56 main-menu[223]: (process:7376): ofpath: /proc/scsi/scsi does not exist Sep 19 06:49:56 main-menu[223]: (process:7376): ofpath: Make sure you compiled your kernel with CONFIG_SCSI_PROC_FS=y I'll upload the full install logs (and /target/etc/fstab and /target/etc/yaboot.conf) to this bugreport #580455. But I won't fill up your mailbox by attaching it here. I suspect that Joseph's Jezak's re-write of ofpath will fix this... Please, don't mix up bugs, it's already hard enough to follow; this problem (ofpath not finding /proc/scsi/scsi) has nothing to do with this bug (#580455). It's about #589701. BTW, I'm merging this bug with #587290, agreeing with Ben Hutchings. Regards, benjamin Rick [1] http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/arch-latest/powerpc/iso-cd/debian-testing-powerpc-businesscard.iso The boiler-plate declares This build finished at Sun Sep 19 03:26:28 UTC 2010. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589701: #589701 not reproducible
unmerge 589701 Hi, Le dimanche 19 septembre 2010 à 03:42 -0400, Rick Thomas a écrit : Synopsis: I tried an install. It failed. But the /target/etc/yaboot.conf is correct in that it does not contain spaces in the wrong places or use /dev/disk/by-uuid to identify partitions. So this is definitely not the same as #580455. I'm unmerging it (even if #580455 should IMHO be a RC bug too for squeeze; this one is, isn't it ?). The problem that caused the failure is that ofpath can't handle the lack of /proc/scsi/scsi and fails. Joseph Jezak has a re-written ofpath that may solve this problem. I /think/ that Joseph's patch (or some equivalent) is already in the latest yaboot version (1.3.15). So, if Aurélien is updating yaboot next week, this bug /should/ be fixed. I'll check further when I'll have time, tomorrow. Bottom line: The version of yabootconfig used by the Debian Installer is not creating mangled yaboot.conf files. The mangled yaboot.conf that I reported in bug report #580455 must be coming from somewhere else. Note that yabootconfig is _not_ used in the debian-installer, it's a custom script made for yaboot-installer that is run (and which says, BTW, in essence, that yabootconfig is crap…) The mangled yaboot comes from linux-base, as I discovored in #587290 (which should definitely be merged with #580455; I'm doing it right away). Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587290: [Debootloaders-yaboot] Bug#587290: How does linux-base modify /etc/yaboot.conf ?
Hi Ben, Le samedi 18 septembre 2010 à 22:11 +0100, Ben Hutchings a écrit : The value of the kernel (or rather initramfs) root parameter generally does need to include an '=' character and linux-base.postinst is correct to use it. It must then double-quote the value in yaboot.conf so that it is handled correctly by the main configuration parser in cfg.c. Therefore, ybin also needs to accept this format. Thanks for the check in cfg.c, I didn't have the idea to go there. I think most people relied on what ybin told them (i.e. I don't grok this). The problem being that ybin never ever understood this syntax, and the stricter simple one was the de-facto standard. This is why your change hurt so much (#580455 lists now at least 5 persons affected), and I'm generally reluctant to ancient file format change. But you're right in that ybin is buggy. I could change linux-base.postinst to avoid adding space between name, '=' and value when updating the configuration but it seems simple enough to make ybin accept that too. Yes, it's simple. And I think you can't avoid the quotes, because of spaces ? (I bet some people put spaces in FS labels ?). So yes, ybin needs fixing, I'll try having a look at that (and Rick's code). BTW, I'm very curious why we didn't get hit by that earlier. It seems your code affected yaboot around the time Debian switched to mandatory UUID/labels, right ? Is your script only triggered for that ? Is it only done once during the transition (as seems to imply the function's name from where it's called in your perl code) or on every kernel upgrade ? Yes, all parts of yaboot should really be using the same configuration parser. Reimplementing it is crazy. Well, I'm not sure anyone is able/willing to do that here… Let's just fix the most obvious bug for now, right ? By the way, I think this bug should be merged with #580455. Tried doing it, but didn't work; should I rather forcemerge or try setting both to the same severity first ? (I don't like messing with so high severity when it's not my bugs) Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589701: #589701 not reproducible
Hi Rick, I tried reproducing this bug, but couldn't manage to : a clean install from the Squeeze installer (netbooting the netinstall image from http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-powerpc/current/images/powerpc/netboot/ ) did install Debian correctly on a PowerBook6,8. Furthermore, the yaboot.conf you brought shows no signs of UUID or LABEL used (as in the other bug you encountered #587290 and #580455) and looks correct. Could you verify this is the one you really get ? Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580455: #580455 yabootconfig does the correct thing, your yaboot.conf must be modified by something else
Hi, I just found by looking around that yabootconfig, the script used by the yaboot package (very important distinction) to generate /etc/yaboot.conf actually _knows_ how to handle LABEL and UUID; see http://svn.debian.org/wsvn/debootloaders/trunk/yaboot/ybin/yabootconfig . Furthermore, the yaboot package didn't change in 4 years, so everything is correct in yaboot ! But, as we recently saw again on the debian-ppc ML (see http://lists.debian.org/debian-powerpc/2010/09/msg00013.html ) _some_ script from _some other_ package does modify /etc/yaboot.conf ! And add spaces (very wrong) and does not interpret labels/uuids. The only other script I know that generates yaboot.conf is the postinst one in the yaboot-installer udeb (from the debian-installer) but I don't see how it could add spaces, looking at its code. So, that's now 3 people including you that stumble upon this, but this doesn't come from yaboot. So, could you please join the _full_ yaboot te see if the program that generates it leaves some traces, and please tell if you think you have any particular package installed that could affect that. I Cc the list, too, in case someone could look at that. Thanks, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587290: How does linux-base modify /etc/yaboot.conf ?
Hi, I'm trying to solve #587290, i.e. yaboot.conf being generated with strange values. You advised that yabootconfig be fixed, but actually I discovered that it's not its fault : it correctly handles labels/uuids, see my last answer at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580455 You mentioned that linux-base may modify /etc/yaboot.conf. I think it might be the culprit for this bug, but I would first like to know how and why it does that ? I am investigating linux-base right away and will report any clue on this problem. Thanks, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587290: How does linux-base modify /etc/yaboot.conf ?
Le jeudi 16 septembre 2010 à 15:12 +0200, Benjamin Cama a écrit : You mentioned that linux-base may modify /etc/yaboot.conf. I think it might be the culprit for this bug, but I would first like to know how and why it does that ? OK, I was right, thanks to your hint: see http://svn.debian.org/wsvn/kernel/dists/sid/linux-2.6/debian/linux-base.postinst The yaboot.conf is taken as if it has the lilo syntax. And this script adds spaces and quotes around key/value pairs and let /dev/disk/by-* names. This is not compatible with yaboot. I also saw that you filled this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581173 which make me think that your approach is to adapt every bootloader to this syntax. The problem is, not every bootloader maintainers or volunteer contributors have the resources to do so. Yaboot has not changed in 4 years, and even if Rick Thomas submitted a patch to handle that, I am not sure anything will be eventually integrated (I sent an email earlier on debian-ppc list to ask if someone would volunteer to take over yaboot maintenance, as the maintainers are unresponsive for so long). Furthermore, this change affected a lot of users since at least last may, and I just found it now ! In between, this was a major disruption for Debian on PPC (3 persons reported being affected by this bug, which is quite a lot for our architecture). Could you tell us (I Cc'ed debian-ppc) your view on this problem ? Is the workaround for 581173 I see in the code (removing spaces) a good idea to apply quickly to fix this bug too ? Thanks, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543448: ia32-libs: Missing library dependencies
Package: ia32-libs Version: 20090808 Severity: important Hi, I'd like to join everyone else in requesting these libs to be included in ia32-libs. For me it breaks the game Aquaria [http://www.bit-blot.com/aquaria/]. This is because of pulseaudio's lib present in this package, which depends on 32 bits libwrap and libgdbm. Could I also point out this : $ dpkg -L ia32-libs|grep \.so|xargs ldd|grep 'not found'|sort -u libavahi-client.so.3 = not found libavahi-common.so.3 = not found libdb-4.7.so = not found libdrm_intel.so.1 = not found libffado.so.1 = not found libfreebob.so.0 = not found libgdbm.so.3 = not found libgdk_pixbuf-2.0.so.0 = not found libglib-2.0.so.0 = not found libgmodule-2.0.so.0 = not found libgobject-2.0.so.0 = not found libpixman-1.so.0 = not found libsamplerate.so.0 = not found libsysfs.so.2 = not found libts-0.0.so.0 = not found libv4l1.so.0 = not found libwrap.so.0 = not found Which make me think this bug should rather be of severity 'grave' than 'wishlist' (seriously, WTF ?) i.e. it ships with quite a bit of unresolved dependencies. Tell me if I can be of any help. Thanks, benjamin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ia32-libs depends on: ii dpkg1.15.7.1 Debian package management system ii lib32asound21.0.22-2 shared library for ALSA applicatio ii lib32gcc1 1:4.4.4-1GCC support library (32 bit Versio ii lib32ncurses5 5.7+20100313-2 shared libraries for terminal hand ii lib32stdc++64.4.4-1 The GNU Standard C++ Library v3 (3 ii lib32z1 1:1.2.3.4.dfsg-3 compression library - 32 bit runti ii libc6-i386 2.10.2-7 GNU C Library: 32-bit shared libra ii lsb-release 3.2-23.1 Linux Standard Base version report ia32-libs recommends no packages. Versions of packages ia32-libs suggests: pn ia32-libs-gtk none (no description available) -- 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#521816: Thanks for the new icon
Thanks everyone for this new icon, it's very nice and easy to understand. Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575137: /usr/bin/aptitude missing
Hi, First, thanks for caring about this bug. Le samedi 03 avril 2010 à 08:54 +0200, Sven Joachim a écrit : On 2010-04-03 06:34 +0200, Daniel Burrows wrote: So, I haven't had time to do actual work on this bug yet, but I've mulled it over a bit. Here's what I think we know for sure: 1) On some people's systems, /usr/bin/aptitude isn't being restored after the upgrade. 2) On other people's systems, it is. 3) I don't know why. I have some ideas about that: - People who had used an early 0.5 version, reverted to 0.4.11, and still use dpkg 1.14.x with its somewhat buggy update-alternatives implementation could be hit by it. That's not something I would worry much about. - The submitter of #575137 uses btrfs which reportedly may cause severe corruption of dpkg's database and other data: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891 http://kitenet.net/~joey/blog/entry/aloha_btrfs/ This may indeed be that kind of problem. But to confirm this bug, I first would like to try reproducing it, but I can't find 0.4.11.11-1+b2 anywhere. Do you have an idea where I can find it ? Thanks, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575137: /usr/bin/aptitude missing
Le samedi 03 avril 2010 à 08:13 -0700, Daniel Burrows a écrit : I can't find it anywhere on the Web. But since it's just a bin-NMU of the lenny aptitude, you can reproduce it by downloading that aptitude's source and building it. Well, I happen not to find any source for it too ... The hg repository doesn't have such a tag too. Any pointers ? Another question: does /var/lib/dpkg/alternatives/aptitude exist, and what's in it? On my system it contains: auto /usr/bin/aptitude /usr/bin/aptitude-curses 30 /usr/bin/aptitude-gtk 60 This file doesn't exist on my system. (hint : I didn't recreate any alternative for now) I'd also be curious if any of those orphaned files look like that, obviously. I don't know btrfs internals very well too, but I can't find any orphans directory anywhere (lost+found is empty). Furthermore, the message said that it /deleted/ the orphans, so they may be definitly lost. Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575137: /usr/bin/aptitude missing
Le samedi 03 avril 2010 à 18:02 +0200, Sven Joachim a écrit : On 2010-04-03 17:53 +0200, Benjamin Cama wrote: Le samedi 03 avril 2010 à 08:13 -0700, Daniel Burrows a écrit : I can't find it anywhere on the Web. But since it's just a bin-NMU of the lenny aptitude, you can reproduce it by downloading that aptitude's source and building it. Well, I happen not to find any source for it too ... The hg repository doesn't have such a tag too. Any pointers ? I think you can use the version in lenny: http://packages.debian.org/source/lenny/aptitude OK. So, first, I tried installing it via dpkg but it had dependencies on an older apt (actually, libapt-pkg-something, provided by apt). So I installed it too, so that I have my old setup. But it was not such a good idea : aptitude now couldn't load some shared libraries (by strace'ing it, it first loaded the good (old apt) one, but then tried the new one ... that was no more here) and won't run at all. Furthermore, I realized that when this bug happened, I already had the newer apt. So I decided to go back by upgrading my system with apt-get. I got back all the newer version (apt 0.7.25.3 and aptitude 0.6.1.5), and the correct /usr/bin/aptitude alternative with it ! Still, I want to know why the problem happened, so I try to compile the old aptitude as you advised me Sven, but then I stumble upon #560517 which is only solved in a 0.6.something aptitude release. I could try to find and backport the patch, but I must admit I don't feel it so well ... Oh, and one more thing : just got back to this machine (it's not my main one) after writing the first part of this email, and realized that aptitude has actually not been updated and still fails loading a shared library ... did I dream of it ?! So I apt-get -f install again, this time aptitude is upgraded correctly, even if updates-alternatives tells me it forced the link ... And then everything is _really_ fine. This but drives me crazy and the behavior is so undeterministic I really wonder if there isn't a problem with the FS. So, if you have an idea to test this 0.4.11.11-1+b2 I'd be happy, but for now I don't know what to think about it. Thanks for the effort, though. benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548047: Patch for fstype to support btrfs
Hi, I just submitted a patch upstream : http://www.zytor.com/pipermail/klibc/2010-April/002596.html Don't hesitate to test it and report any result. Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548047: Patch for fstype to support btrfs
Le samedi 03 avril 2010 à 22:21 +0200, maximilian attems a écrit : On Sat, Apr 03, 2010 at 09:59:02PM +0200, Benjamin Cama wrote: I just submitted a patch upstream : http://www.zytor.com/pipermail/klibc/2010-April/002596.html Don't hesitate to test it and report any result. why do you think that bug was marked pending ;-) Well, I didn't see the flag. When I found it, I already had the idea to implement it in mind, and so did I ... Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575137: /usr/bin/aptitude missing
Hi Daniel, Le jeudi 25 mars 2010 à 07:19 -0700, Daniel Burrows a écrit : On Tue, Mar 23, 2010 at 07:33:53PM +0100, Benjamin Cama ben...@free.fr was heard to say: I just updated from aptitude 0.4.11.11-1+b2 to version 0.6.1.5-3 and lost the 'aptitude' command. It is no more listed in 'dpkg -L aptitude' too. Have you ever had aptitude version 0.5+ installed on this system before? There were some bugs earlier with downgrading, particularly from some of the first versions that used alternatives. No, I don't think so. My setup is squeeze + unstable pinned at lower priority. The version numbers cited earlier are the ones I saw by looking back in my terminal while the fatidic safe-upgrade was done. First, I thought that the pinning from unstable had a bug, because I didn't thought such a change (0.4 to 0.6 for an essential package) would occur in testing near a stable release. But I checked on packages.debian.org and it seemed legit. Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575137: Info received (Bug#575137: /usr/bin/aptitude missing)
Hi, I just upgraded my system and did *not* see that behaviour. I use the testing repositories and today's upgrade installed 0.6.1.5-3, replacing 0.4.11.11-1+b2. /usr/bin/aptitude exists and points to /etc/alternatives/aptitude, which in turn points to /usr/bin/aptitude-curses. Thanks for this report. I must admit I had some installation problems a while back with this machine, but everything was fine since then. Today, I see that my root FS (I use btrfs on an IDE SSD, not the original setup of my laptop) has unlinked 6 orphans on reboot, so this may be a cause for problems ... I don't know if this report may still be considered valid, but I'd appreciate if anyone else saw this problem too (still, it seems strange to me that it lost only those files, and not others ... I'll investigate and report if I find anything). Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572605: still present -- installation-reports: Sid d-i on PowerPC can not find driver for network interface
Hi, I don't know the exact cause of this bug, but there is not enough informations (for me) to try to understand this bug. Could you give at least a dmesg result when in the installer ? And what exact message does it outputs when looking for the adapter ? Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572869: Information request for #572869
Hi, I would like investigating this bug, even if for now I don't have this problem. But I need some more details on this : - first, on a up-to-date squeeze with 2.6.32, but still using the old ata stack (CONFIG_BLK_DEV_IDE_PMAC=y), I don't have any problem with ofpath even if /proc/scsi/scsi is missing. So, the title of this bug is wrong : ofpath seems to work correctly without /proc/scsi/scsi. - second, is your problem that ofpath doesn't work on disks using the libata stack ? If I am correct, I will try to reproduce it on 2.6.33 with the macio driver (it's the only way for me to test a libata driver). Thanks for any information, like the output of ofpath failing when on the installer, and the like ... Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572605: still present -- installation-reports: Sid d-i on PowerPC can not find driver for network interface
Hi Frans, Le mercredi 24 mars 2010 à 14:53 +0100, Frans Pop a écrit : There is no real bug. The only problem is that the images that are currently available are outdated. OK. So, if it has not already been told (I didn't see much details about that in this BR) what steps should be taken for powerpc volunteers ? Take care of the buildd ? Who is in charge of it at the moment ? How can one have access to it ? Thanks for any pointer on this. (I am not very aware of all the details ; I am only a small part-time contributor to Debian) If you should build an image yourself, I expect it will work fine. OK. So the problem lies only in the buildd, right ? I am willing to take care of it if a volunteer is needed. Thanks for any help, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572605: still present -- installation-reports: Sid d-i on PowerPC can not find driver for network interface
Le mercredi 24 mars 2010 à 15:56 +0100, Frans Pop a écrit : On Wednesday 24 March 2010, Benjamin Cama wrote: OK. So, if it has not already been told (I didn't see much details about that in this BR) what steps should be taken for powerpc volunteers ? If you are not a Debian Developer I'm afraid you cannot help with this issue. Indeed, I am not a DD. I have been thinking for a long time becoming a DM, and I know someone who could mentor me, but becoming a DD would be one (long !) more step. However, there is plenty of other work that could be done to improve powerpc support in Debian Installer. Feel free to check the BTS for any open issues and work on them and submit patches. Well, I try to help when I can, following the debian-powerpc ML. I must admit I don't look much to d-i bugs, as I don't use it very often, even if it's a key part for newcomers ... And the reactivity of people concerning PPC bugs don't help too (for example I'm trying to push #568204 without much success ...) Thanks anyway, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575137: /usr/bin/aptitude missing
Package: aptitude Version: 0.6.1.5-3 Severity: grave Justification: renders package unusable I just updated from aptitude 0.4.11.11-1+b2 to version 0.6.1.5-3 and lost the 'aptitude' command. It is no more listed in 'dpkg -L aptitude' too. Apparently, the alternative for aptitude has been lost. I can get back aptitude by typing 'aptitude-curses', which seems to be the default alternative (has seen on another system with unstable), but update-alternatives says there is no more alternative for aptitude ... I think I will will add it back by hand, but this bug is highly confusing at first when one is no more able to aptitude anything. Regards, benjamin -- Package-specific info: Terminal: xterm $DISPLAY is set. `which aptitude`: aptitude version information: aptitude linkage: -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.32-3-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.9 0.7.25.3 Advanced front-end for dpkg ii libboost-iostreams1.40. 1.40.0-6+b1 Boost.Iostreams Library ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libcwidget3 0.5.16-3 high-level terminal interface libr ii libept0 0.5.30 High-level library for managing De ii libgcc1 1:4.4.2-9GCC support library ii liblog4cxx100.10.0-1.1 A logging library for C++ ii libncursesw55.7+20090803-2 shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.2.4.2-1type-safe Signal Framework for C++ ii libsqlite3-03.6.22-1 SQLite 3 shared library ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 ii libxapian15 1.0.18-1 Search engine library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages aptitude recommends: ii apt-xapian-index 0.25 maintenance tools for a Xapian ind pn aptitude-doc-en | aptitude-do none (no description available) ii libparse-debianchangelog-perl 1.1.1-2parse Debian changelogs and output ii sensible-utils0.0.2 Utilities for sensible alternative Versions of packages aptitude suggests: pn debtags none (no description available) ii tasksel 2.81 Tool for selecting tasks for insta -- 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#568204: hwclock: Please apply my patch to fix rtc date setting with incorrect hwclock
Hi, It's been more than two weeks since I submitted my patch and got no feedback on it. I am Cc'ing some people who may be related to this. To sum up : since kernel commit bcd68a70cb0eee556d86d93133aa150319bd9f53 by Geert Uytterhoeven (see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bcd68a70cb0eee556d86d93133aa150319bd9f53 ) hwclock can't write the date to the RTC on non-interrupt based computers (like newworld PPCs) which have a wrong date set (like after their battery is dead). This is because to synchronize to a full second, hwclock actually reads the date from the RTC and fails as, since the change to rtc-generic, the kernel returns -1 on a wrong date. As I pointed out earlier, it seems that a lot of RTC drivers explicitly avoid returning -1 because of this bug : they should be fixed some time in the future, but hwclock should be fixed first. My Powerbook, as a lot of others Mac, used to recover from their wrong date easily before this switch (which also caused #535354). Now, this is only possible by manual intervention, like I said earlier in this bug report. On others architectures with interrupt based RTCs, this works OK as the synchronization loop is not triggered and hwclock handle this case properly. This patch only add another source to this case (erroring on the synchronization loop). I tested it on my machine and it works OK. I may also send it to debian-powe...@lists.debian.org if you want more feedback. But please, it will be very usefull for powerpc users if this patch is applied. Thanks, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568204: [PATCH] ignore invalid hw clock for non-interupt-based RTCs
Hi,
My previous comments for this bug report were not accurate : invalid
hardware clock (e.g. reset ones after battery ran out) are already
handled in hwclock, BUT _not_ for non-interrupt based RTCs, like the
ones on newworld PPCs, at least. It reads the clock in
synchronize_to_clock_tick_rtc() for the rtc-generic driver and errors
out from here (the usual invalid clock case is handled in
read_hardware_clock() later, but too late).
Before, hwclock ignored the error returned by the kernel for an invalid
hw clock (if returning EINVAL is the correct error code for an invalid
time -- I am not 100% sure of that, but Ben Hutchings' comment in
#542275 and looking at kernel drivers seem to imply that). It only used
the result from mktime() to check the date. But the kernel also has its
own routine. And this bug is also what cause a lot of drivers _not_ to
report any error when there is one, like I said in my previous comment.
I think this is quite serious.
The following patch fixes this bug (also including some error code enums
to be clearer) while trying not to be too intrusive.
This bug was introduced on powerpc when the default ppc RTC driver for
2.6.30 was changed to rtc-generic. Before that, RTC had been broken for
quite some time on PPC. And continues for people which have flacky
hardware (powerpc is mainly used on old machines today). This is why I
am CCing debian-powerpc : I think this is an important problem that
should really be fixed.
Regards,
benjamin
Signed-off-by: Benjamin Cama ben...@free.fr
---
diff --git a/hwclock/clock.h b/hwclock/clock.h
index e4eb7eb..a1d1bc9 100644
--- a/hwclock/clock.h
+++ b/hwclock/clock.h
@@ -23,6 +23,14 @@ extern struct clock_ops *probe_for_kd_clock(void);
typedef int bool;
+enum {
+ HWCLOCK_OK = 0,
+ HWCLOCK_ERROR,
+ HWCLOCK_SYNC_TIMEOUT,
+ HWCLOCK_KDGHWCLK_ERROR,
+ HWCLOCK_INVALID_TIME
+};
+
/* hwclock.c */
extern char *progname;
extern int debug;
diff --git a/hwclock/cmos.c b/hwclock/cmos.c
index 8b3495b..ecfdd53 100644
--- a/hwclock/cmos.c
+++ b/hwclock/cmos.c
@@ -431,13 +431,13 @@ synchronize_to_clock_tick_cmos(void) {
*/
for (i = 0; !cmos_clock_busy(); i++)
if (i = 1000)
- return 1;
+ return HWCLOCK_SYNC_TIMEOUT;
/* Wait for fall. Should be within 2.228 ms. */
for (i = 0; cmos_clock_busy(); i++)
if (i = 100)
- return 1;
- return 0;
+ return HWCLOCK_SYNC_TIMEOUT;
+ return HWCLOCK_OK;
}
diff --git a/hwclock/hwclock.c b/hwclock/hwclock.c
index ac1f7c8..aa6d6ee 100644
--- a/hwclock/hwclock.c
+++ b/hwclock/hwclock.c
@@ -440,8 +440,11 @@ read_hardware_clock(const bool universal, bool *valid_p,
time_t *systime_p){
int err;
err = ur-read_hardware_clock(tm);
- if (err)
- return err;
+ if (err) {
+if (err == HWCLOCK_INVALID_TIME)
+ *valid_p = FALSE;
+return err;
+ }
if (badyear)
read_date_from_file(tm);
@@ -1190,12 +1193,12 @@ manipulate_clock(const bool show, const bool adjust,
const bool noadjfile,
if (show || adjust || hctosys || (!noadjfile !systz)) {
/* data from HW-clock are required */
rc = synchronize_to_clock_tick();
- if (rc rc != 2) /* 2= synchronization timeout */
+ if (rc rc != HWCLOCK_SYNC_TIMEOUT rc != HWCLOCK_INVALID_TIME)
return EX_IOERR;
gettimeofday(read_time, NULL);
rc = read_hardware_clock(universal, hclock_valid, hclocktime);
- if (rc)
- return EX_IOERR;
+ if (rc rc != HWCLOCK_INVALID_TIME)
+return EX_IOERR;
}
if (show) {
diff --git a/hwclock/kd.c b/hwclock/kd.c
index 3da87ca..9071843 100644
--- a/hwclock/kd.c
+++ b/hwclock/kd.c
@@ -55,7 +55,7 @@ synchronize_to_clock_tick_kd(void) {
if (ioctl(con_fd, KDGHWCLK, start_time) == -1) {
outsyserr(_(KDGHWCLK ioctl to read time failed));
-return 3;
+return HWCLOCK_KDGHWCLK_ERROR;
}
/* Wait for change. Should be within a second, but in case something
@@ -73,18 +73,18 @@ synchronize_to_clock_tick_kd(void) {
if (ioctl(con_fd, KDGHWCLK, nowtime) == -1) {
outsyserr(_(KDGHWCLK ioctl to read time failed in loop));
- return 3;
+ return HWCLOCK_KDGHWCLK_ERROR;
}
if (start_time.tm_sec != nowtime.tm_sec)
break;
gettimeofday(now, NULL);
if (time_diff(now, begin) 1.5) {
fprintf(stderr, _(Timed out waiting for time change.\n));
- return 2;
+ return HWCLOCK_SYNC_TIMEOUT;
}
} while(1);
- return 0;
+ return HWCLOCK_OK;
}
diff --git a/hwclock/rtc.c b/hwclock/rtc.c
index 2e05385..84d85aa 100644
--- a/hwclock/rtc.c
+++ b/hwclock/rtc.c
@@ -177,10 +177,14 @@ do_rtc_read_ioctl(int rtc_fd, struct tm *tm) {
rc = ioctl(rtc_fd, RTC_RD_TIME, tm);
}
if (rc == -1) {
+ int err = -1;
+ /* special error case
Bug#542275: kernel error message for #542275 + patch
Hi, I tested Ben Hutchings' patch and got this result (on a PowerBook6,8) : rtc-generic rtc-generic: hctosys: unable to read the hardware clock (-22) Hope this can help solve this bug. benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542275: kernel error message for #542275 + patch
Le mercredi 03 février 2010 à 02:02 +, Ben Hutchings a écrit :
Error 22 is EINVAL and actually indicates an invalid time.
OK. I actually wanted to solve this bug to also help a bug somewhat
related to #535354, which prevent hwclock to write the hardware clock.
Actually, hwclock first read the hardware clock before writing to it,
and stops if reading fails, which causes my problem (yes, i know, not
this bug).
If you don't mind applying another patch, this would help debug this
further:
No problem. But by just reading it, I felt the problem : an invalid date
is stored in the RTC.
What's in my logs (I may have missed the SMU stuff as it seems make
didn't feel like recompiling it):
[ 20.172405] rtc-generic rtc-generic: rtc core: registered rtc-generic
as rtc0
[ 20.186144] pmu_get_time: now = 2454713
[ 20.187340] rtc_valid_tm: invalid time { 70, 0, -24077, -14, -8, -7 }
[ 20.188559] rtc-generic rtc-generic: hctosys: unable to read the
hardware clock (-22)
So, actually the bug here may be that Jordi simply had his RTC not
correctly set. This often happens with old computers like G3/G4 because
they have worn out batteries and forget the date.
But still, it would be usefull to be able to set the RTC for those with
still a bit of juice in their battery. So, this is not this bug but
another one (related to hwclock), if you agree with my analysis. I'll
fill another one soon, if so.
benjamin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542275: hwclock should not try to calculate the drift if rtc time is invalid [was: Re: Bug#542275: kernel error message for #542275 + patch]
Package: util-linux Version: 2.16.2-0 Le mercredi 03 février 2010 à 03:49 +, Ben Hutchings a écrit : On Wed, 2010-02-03 at 03:42 +0100, Benjamin Cama wrote: But still, it would be usefull to be able to set the RTC for those with still a bit of juice in their battery. So, this is not this bug but another one (related to hwclock), if you agree with my analysis. I'll fill another one soon, if so. Right, the bug is in hwclock. Actually, it may not be a bug ... I similar bug was fixed in #478663. After a small gdb session, I saw that the rtc is read because hwclock maintains /etc/adjtime each time you set your rtc (either with --set or --systohc). To do so, it first needs to read the rtc and compare the result to the system time to calculate the drift. But it fails because of an invalid time. So, the correct command in this context would be (see #478663) : # hwclock --systohc --noadjfile --utc But it took me some hard time to find it ... So, i am submitting a new bug report to util-linux asking for a check if the rtc is set to some valid time before calculating the drift, and so ignoring invalid reads (but still not ignoring the timezone in /etc/adjtime). It would be fabulous for people having flaky rtc battery and fighting their hardware clock ... Thanks Ben for investigating this, and thanks to anyone who can help, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568204: Some more information about kernel RTC drivers
BTW, I was looking at some kernel RTC drivers, and I saw that some of them explicitly return 0 instead of -EINVAL (if it's the correct error code to say that the clock is set to an invalid time ; before the switch to rtc-generic, rtc-ppc did no consistency check and hwclock worked happily ...) _because_ of this bug. See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/rtc/rtc-pcf8563.c;hb=b5a82d628d4491558c109fbeabc2993d6686e89c#l106 for example. Regards, benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542819: Quick workaround
Hi, The above package having disappeared, for those who still just want to use btrfs with current kernel (as, apparently, 2.6.31 won't ever reach unstable, and there's quite some time left before 2.6.32), just use Daniel's git branch for btrfs-tools 0.18-4 here : http://git.debian-maintainers.org/?p=daniel/btrfs-tools.git;a=tree;h=d74fc1d85dbc7f0696d7e19c5c5d54b4f23d873f;hb=b0209500f811d153fb071373b8e36b4e5a19acef Choose snapshot, and you'll get an archive ready for a dpkg-buildpackage. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537843: tftpd-hpa: Initscript broken because inetd already bound UDP port
Package: tftpd-hpa Version: 5.0-3 Severity: normal Hi, The postinst script fails because tftpd won't start. This is because UDP port 69 is already bound by inetd, which is the way I chose tftpd to run. Something should be done to detect that, or continue the postinst script even if tftpd doesn't want to start by its own init script. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tftpd-hpa depends on: ii adduser 3.110 add and remove users and groups ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy ii libc6 2.9-21 GNU C Library: Shared libraries ii libwrap0 7.6.q-18 Wietse Venema's TCP wrappers libra tftpd-hpa recommends no packages. Versions of packages tftpd-hpa suggests: pn syslinux-common none (no description available) -- debconf information: tftpd-hpa/directory: /srv/tftp tftpd-hpa/username: tftp tftpd-hpa/use_inetd: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523557: mplayer: Subtitles no more working
Package: mplayer Version: 1.0~rc3+svn20090405-1 Severity: normal Since a recent update, subtitles in mplayer do not work anymore. When I try to play a movie with subtitles (wether with autodetected subtitles or explicitly set with -sub), they don't show up anymore, with the following message : New_Face failed. Maybe the font path is wrong. Please supply the text font file (~/.mplayer/subfont.ttf). subtitle font: load_sub_face failed. Furthermore, their are no more time or any text displayed when asking for playing time progress for example (with the 'o' key). Searching on the web, a lot of people suggest providing a font with the above name, but mplayer used to work for a long time without this. It should use the 'default' font of the system, or anything that suits it. benjamin -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mplayer depends on: ii debconf [debconf-2.0] 1.5.26Debian configuration management sy ii libasound2 1.0.19-1 shared library for ALSA applicatio ii libatk1.0-01.24.0-2 The ATK accessibility toolkit ii libaudio2 1.9.1-5 Network Audio System - shared libr ii libavcodec52 3:0.svn20090303-1 ffmpeg codec library ii libavformat52 3:0.svn20090303-1 ffmpeg file format library ii libavutil493:0.svn20090303-1 ffmpeg utility library ii libc6 2.9-7 GNU C Library: Shared libraries ii libcaca0 0.99.beta16-1 colour ASCII art library ii libcairo2 1.8.6-2+b1The Cairo 2D vector graphics libra ii libcdparanoia0 3.10.2+debian-5 audio extraction tool for sampling ii libdirectfb-1.2-0 1.2.7-2 direct frame buffer graphics - sha ii libesd00.2.41-3 Enlightened Sound Daemon - Shared ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype6 2.3.9-4 FreeType 2 font engine, shared lib ii libfribidi00.10.9-1 Free Implementation of the Unicode ii libgcc11:4.3.3-5 GCC support library ii libgif44.1.6-6 library for GIF images (library) ii libgl1-mesa-glx [libgl 7.4-2 A free implementation of the OpenG ii libglib2.0-0 2.20.0-3 The GLib library of C routines ii libgtk2.0-02.14.7-5 The GTK+ graphical user interface ii libjack0 0.116.1-4 JACK Audio Connection Kit (librari ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii liblircclient0 0.8.3-3 infra-red remote control support - ii liblzo2-2 2.03-1data compression library ii libncurses55.7+20090404-1shared libraries for terminal hand ii libogg01.1.3-5 Ogg Bitstream Library ii libopenal1 1:1.4.272-2 Software implementation of the Ope ii libpango1.0-0 1.24.0-3 Layout and rendering of internatio ii libpng12-0 1.2.35-1 PNG library - runtime ii libpostproc51 3:0.svn20090303-1 ffmpeg video postprocessing librar ii libpulse0 0.9.14-2 PulseAudio client libraries ii libsdl1.2debian1.2.13-4+b1 Simple DirectMedia Layer ii libsmbclient 2:3.3.2-2 shared library for communication w ii libspeex1 1.2~rc1-1 The Speex codec runtime library ii libstdc++6 4.3.3-5 The GNU Standard C++ Library v3 ii libsvga1 1:1.4.3-27console SVGA display libraries ii libswscale03:0.svn20090303-1 ffmpeg video scaling library ii libtheora0 1.0-2 The Theora Video Compression Codec ii libx11-6 2:1.2.1-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii libxv1 2:1.0.4-1 X11 Video extension library ii libxvmc1 1:1.0.4-2 X11 Video extension library ii libxxf86dga1 2:1.0.2-1 X11 Direct Graphics Access extensi ii libxxf86vm11:1.0.2-1 X11 XFree86 video mode extension l ii mplayer-skin-blue [mpl 1.6-2 blue skin for mplayer ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime mplayer recommends no packages. Versions of packages mplayer suggests: ii bzip2 1.0.5-1high-quality block-sorting
Bug#521816: [Pkg-utopia-maintainers] Bug#521816: network-manager-gnome: NM shows confusing icon when cable is plugged
Hi, I find it very confisuing too; the first time I saw it I thought my connection had a problem ... To which package could I send a bug report about this ? benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507382: python-pysqlite2 is the culprit
Rolf, Thanks for this information, as removing python-pysqlite2 solved this issue. Gourmet says it depends on (among others) : python-pysqlite2 | python (= 2.5) | python-sqlite3 python-pysqlite2 was installed on my system (using unstable, I must admit, not lenny) by miro, but 'apt-cache rdepends python-pysqlite2' shows quite a lot of packages depending on it. As a matter of fact, pysqlite has been included in python 2.5 ... To me, it seems redundant tu offer python-pysqlite2 as an alternative, but I think it would be too much fuss for lenny to try to correct that now on all the other packages. Any thought on this ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507382: python-pysqlite2 is the culprit
Le lundi 12 janvier 2009 à 22:54 +0100, Rolf Leggewie a écrit : great! Thank you. That was good progress. Even after installing I'm glad it helps ! python-pysqlite2 from testing (version 2.4.1-1), gourmet continued to work as expected. But after installing 2.5.0-2 from unstable, I can now successfully reproduce the crash. As a stop-gap measure, I'll send a There must be a strange mix between python 2.5 and pysqlite2 when they're both installed, as both provide the same functionnality. Mattia (the original reporter) had pysqlite 2.5, so this is the problem. 0.14.3-2 package to my sponsor which conflicts with python-pysqlite2 = 2.5. I'll talk to upstream about a proper fix for inclusion in CVS. Basically, I think that all packages requiring python = 2.5 should conflict with pysqlite = 2.5, as it is redundant ... Thanks for your work, too. -- Benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#362569: Some precision
Happens here too, latest etch at this time. I noted that the problem doesn't occur if the unicode character of the ligature is directly inserted (for example #xFB03; for ffi). Disabling pango leads to correct font displaying, but without the ligature. By the way, the MOZ_DISABLE_PANGO env var disable pango if it is just set, not if it set to 0 (which doesn't enable pango). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
