Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys
Hi Reinhard, I don't blame you. I think that for Debian to upgrade a package, changing a global setting, break some of its dependencies, and then kick out the resulting broken packages a month later (nearly a year before the expected release date) seems pretty harsh. In this case it took me 4.5 months to fix the issue from when you reported it to me, so unless a package has at least one full-time developer, a month simply isn't enough to fix this issue. Not even close for a hobbyist like myself. Thanks, Chris. On Sun, 9 Jun 2019 at 23:26, Reinhard Tartler wrote: > Agreed! > > In this case, the bug was reported on Aug 24 2018 by Adrian Bunk. It was > removed about a months later, namely on September 23, for failing to build > from source. Four weeks is arguably quite fast. Or quite slow, depending on > whom you talk to. > > I probably could have reacted by disabling the test suite. Or by prodding > you in those four weeks harder. Or at last have the bug fixed by end of > last year, which would have left enough time to re-migrate to testing. In > the future, I'll know better. > > Again, sorry. I'm happy to help with getting the package to > buster-backports once it opens. > > -rt > > On Sun, Jun 9, 2019 at 5:29 PM Chris Wilson > wrote: > >> Hi all, >> >> It seems a bit egregious to kick out packages that were broken by a minor >> version upgrade in one of their dependencies (which after all is not >> supposed to break anything), without any warning, let alone time to fix >> such a complex issue properly. >> >> I hope that Debian will consider carefully whether this course of action >> was really in the best interests of its users. >> >> Thanks, Chris. >> > > -- > regards, > Reinhard >
Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys
Hi all, It seems a bit egregious to kick out packages that were broken by a minor version upgrade in one of their dependencies (which after all is not supposed to break anything), without any warning, let alone time to fix such a complex issue properly. I hope that Debian will consider carefully whether this course of action was really in the best interests of its users. Thanks, Chris. Sent from my iPhone > On 7 Jun 2019, at 22:26, Reinhard Tartler wrote: > > > >> On Wed, Jun 5, 2019 at 7:46 PM Chris Wilson wrote: >> Hi Reinhard, >> >> Could you have a look at this patch (documented here) to see if it's >> something like what you were hoping for? >> > > Hi Chris, > > I've uploaded this patch now to unstable, looks good, thanks for the patch. > It is still about 80k big, thoguh :-( - quite a lot to review manually. Most > of it is actually test code though! > > Unfortunately, I have bad news. I totally missed that boxbackup has already > been removed on 23 Sep 2018: > https://tracker.debian.org/news/989096/boxbackup-removed-from-testing/ > That's a bummer, because the freeze guidelines rule out migration of packages > that aren't part of testing since beginning of February (cf. > https://release.debian.org/buster/freeze_policy.html). > > Sorry about that, that's totally on me, I should have been more vocal about > this end of last year and totally dropped the ball here. > > I guess we'll have to go the backports route then. > > Best, > -rt > -- > regards, > Reinhard
Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys
Hi Reinhard, Could you have a look at this patch <https://github.com/boxbackup/boxbackup/compare/debian_10_fix_ssl> (documented here <https://github.com/boxbackup/boxbackup/wiki/WeakSSLCertificates#workaround-2>) to see if it's something like what you were hoping for? Thanks, Chris. On Fri, 31 May 2019 at 22:55, Reinhard Tartler wrote: > > > On Fri, May 31, 2019 at 5:03 PM Chris Wilson > wrote: > >> Hi Reinhard, >> >> Presumably the many other affected packages have had similar difficulty >> in developing a comprehensive solution? I also wasn't aware of a time >> constraint. Not that it would have helped me much, as I was moving house, >> but it would have been good to know that there was a risk of not making >> Debian 10. >> > > I'm sorry, I should have communicated that point earlier. I've been bitten > by this with other packages as well. > The release schedule is documented here: > https://wiki.debian.org/DebianBuster > The most recent update from the release team is > https://lists.debian.org/debian-devel-announce/2019/04/msg3.html - > and newer updates will be linked from https://release.debian.org/. > > In short: The team is minimizing changes as much as possible, and getting > updates in becomes more and more a similar big deal as updating something > in stable. > > I could create a special branch with a cut-down version of the solution, >> e.g. forcing the SecurityLevel to -1 (compatibility and warn) for the time >> being, in order to get the fix out in time for Debian 10, and then put the >> full version into backports? >> > > That would be amazing, if the patch is easy to review, I'd be happy to > upload it as a distro patch based on the current package and try to get > this approved by the release team. It might even be accepted as a stable > update, depending on how invasive it is. > > > Thanks, > -rt > >
Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys
Hi Reinhard, Presumably the many other affected packages have had similar difficulty in developing a comprehensive solution? I also wasn't aware of a time constraint. Not that it would have helped me much, as I was moving house, but it would have been good to know that there was a risk of not making Debian 10. I could create a special branch with a cut-down version of the solution, e.g. forcing the SecurityLevel to -1 (compatibility and warn) for the time being, in order to get the fix out in time for Debian 10, and then put the full version into backports? Thanks, Chris. On Fri, 31 May 2019 at 12:16, Reinhard Tartler wrote: > Hi Chris, > > On Sun, May 19, 2019 at 12:21 PM Chris Wilson > wrote: > >> Hi Reinhard and all, >> >> Good news, I have just finished fixing this problem, and merged it into >> master with https://github.com/boxbackup/boxbackup/pull/36. Please could >> you cut a new Debian package release and see if the tests pass for you? Or >> if not, point me to the failure logs? >> >> If anyone wants to know more, the issue is quite complex, and there are >> no easy answers, which is why it took so long to fix. I've done my best to >> describe it at >> https://github.com/boxbackup/boxbackup/wiki/WeakSSLCertificates. Please >> feel free to correct any mistakes that I've made. >> > > Thanks a lot for your assistance! > > I've now (finally) uploaded the package to debian/experimental, the build > logs will be available at > https://buildd.debian.org/status/package.php?p=boxbackup=experimental > soon. > > Unfortunately, the changes are quite invasive and do not qualify for > inclusion into "Debian testing" this late in the Debian release cycle (cf. > https://salsa.debian.org/debian/boxbackup/commit/6017757bc079f4446aa77bc5c0855c52741280f4?w=1 > - all of which would need to be reviewed and approved by the Release Team). > That's very unfortunate, because it very likely means that boxbackup will > not be part of Debian 10 (buster). > > I am also sympathetic -- the nature of the issue seems to require such > invasive changes and coming up with a simple, focused and reviewable fix is > super hard. > > The best that we can do at this point is to get it included into > "buster-backports" as soon as that suite opens, probably shortly after > buster is released, which should be within (hopefully) a small number of > weeks. > > > Best, > -rt > > -- > regards, > Reinhard >
Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys
Hi Reinhard and all, Good news, I have just finished fixing this problem, and merged it into master with https://github.com/boxbackup/boxbackup/pull/36. Please could you cut a new Debian package release and see if the tests pass for you? Or if not, point me to the failure logs? If anyone wants to know more, the issue is quite complex, and there are no easy answers, which is why it took so long to fix. I've done my best to describe it at https://github.com/boxbackup/boxbackup/wiki/WeakSSLCertificates. Please feel free to correct any mistakes that I've made. Thanks, Chris. On Sun, 10 Mar 2019 at 18:23, Reinhard Tartler wrote: > On Mon, Jan 7, 2019, 16:58 Chris Wilson >> >>>> Hi Reinhard, >>>> >>>> If I make the workaround suggested on this thread >>>> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907888> (change >>>> SECLEVEL to 1 in /etc/ssl/openssl.cnf) then test/basicserver passes again. >>>> This is at least a good start, so that users who don't want to replace >>>> their certificates have a workaround. I think I'll need to modify the CA >>>> scripts that generate certificates so that they produce 2048-bit keys that >>>> do not need this workaround, and document it or catch and improve the error >>>> message. >>>> >>>> > Any progress on updating the CA scripts that generate certificates so that > they produce 2048-bit keys? > > I've updated the package to git20180819.g2f5b556, but am still > experiencing a test failure: > > make[1]: Leaving directory '/<>/test/basicserver' > TEST: test/basicserver > Killing any running daemons... > Removing old test files... > chmod: cannot access 'testfiles': No such file or directory > Copying new test files... > NOTICE: Running test basicserver in debug mode... > INFO:Starting server: ./_test --test-daemon-args= srv1 > testfiles/srv1.conf > Waiting for server to die (pid 16575): . done. > INFO:Starting server: ./_test --test-daemon-args= srv2 > testfiles/srv2.conf > Waiting for server to die (pid 16579): . done. > INFO:Starting server: ./_test --test-daemon-args= srv3 > testfiles/srv3.conf > ERROR: TEST FAILURE: Condition [ServerIsAlive(pid)] failed at > test/basicserver/testbasicserver.cpp:628 > ERROR: TEST FAILURE: Condition [HUPServer(pid)] failed at > test/basicserver/testbasicserver.cpp:631 > ERROR: TEST FAILURE: Condition [ServerIsAlive(pid)] failed at > test/basicserver/testbasicserver.cpp:633 > ERROR: SSL or crypto error: loading certificates from > testfiles/clientCerts.pem: error:140AB18F:SSL > routines:SSL_CTX_use_certificate:ee key too small > WARNING: Exception thrown: ServerException(TLSLoadCertificatesFailed) at > lib/server/TLSContext.cpp(93) > FAILED: Exception caught: TLSLoadCertificatesFailed > > > > -- > regards, > Reinhard >
Bug#825913: systemd init script integration: needs manual systemctl daemon-reload after installing initscript
Dear Michael, Thank you for the quick response and patch! It looks good to me, as a systemd novice. My only questions would be: * Whether it's possible for the services generated by systemd-sysv-generator to be masked in their initial state? If so, we might want to check for not-found before masked, to give systemd a chance to parse the file and see if it should be masked or not. * Is systemctl daemon-reload synchronous? When it returns control to the OS, has systemd run systemd-sysv-generator, has it finished, and has systemd parsed any new .service files that were generated? If not, then we might have to wait for that before asking systemd to start the service. Thanks, Chris. On 31 May 2016 at 12:41, Michael Biebl <bi...@debian.org> wrote: > Am 31.05.2016 um 12:16 schrieb Chris Wilson: > > Jessie's 40-systemd script automatically invokes "systemctl > daemon-reload" but > > only when run from a dpkg install. Even this backwards-compatibility > measure > > seems to have been removed in unstable. > > This is correct. Nowadays invoke-rc.d calls daemon-reload, so doing it > twice is a bit excessive. > > > Please consider invoking "systemctl -p LoadState show $service" from > 40-systemd, > > and if it says "not-found" then run "systemctl daemon-reload" to > generate a > > service file for it. > > I think in a case like yours, where the package manager is not involved, > doing an implicit reload for not-found in the lsb hook makes sense. > After all, we are pretty sure the sysv init script actually exists. So > the missing generated service file is indeed a pretty good indicator for > a missing daemon-reload. > > So something like the attached patch? > > Michael > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? >
Bug#825913: systemd init script integration: needs manual systemctl daemon-reload after installing initscript
Package: systemd Version: 230-1 Severity: normal Dear Maintainer, I installed Nagios from source, including an init.d script, but this script mysteriously failed to start Nagios. When installing packages from source, it is normal to install an initscript in /etc/init.d. These scripts no longer work in Debian >= Jessie because /lib/lsb/init-functions.d/40-systemd intercepts their execution and tries to make systemd start the service, but systemd-sysv-generator has not been invoked to generate a service file for it yet, so systemd cannot be used yet. The failure of traditional initscripts defies expectations of backwards compatibility by invoking magic (in 40-systemd) which does not work in this case. Workarounds are to manually execute "systemctl daemon-reload" (which runs systemd-sysv-generator in a special way) or reboot the system, which generates these service files, but it's not clear from the error that either is necessary, since it just says: [] Starting nagios (via systemctl): nagios.serviceFailed to start nagios.service: Unit nagios.service failed to load: No such file or directory. failed! Jessie's 40-systemd script automatically invokes "systemctl daemon-reload" but only when run from a dpkg install. Even this backwards-compatibility measure seems to have been removed in unstable. Please consider invoking "systemctl -p LoadState show $service" from 40-systemd, and if it says "not-found" then run "systemctl daemon-reload" to generate a service file for it. -- Package-specific info: -- System Information: Debian Release: 8.4 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 4.4.0-22-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-2 ii libapparmor12.10-4 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-6 ii libc6 2.19-18+deb8u4 ii libcap2 1:2.24-8 ii libcap2-bin 1:2.24-8 ii libcryptsetup4 2:1.6.6-5 ii libgcc1 1:4.9.2-10 ii libgcrypt20 1.7.0-2 ii libgpg-error0 1.17-3 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libmount1 2.28-5 ii libpam0g1.1.8-3.1+deb8u1+b1 ii libseccomp2 2.3.1-2 ii libselinux1 2.3-2 ii libsystemd0 230-1 ii mount 2.28-5 ii util-linux 2.28-5 Versions of packages systemd recommends: pn dbus pn libpam-systemd Versions of packages systemd suggests: pn systemd-container pn systemd-ui Versions of packages systemd is related to: ii udev 230-1 -- no debconf information [EXTENDED] /lib/systemd/system/rc-local.service -> /lib/systemd/system/rc-local.service.d/debian.conf [MASKED] /etc/systemd/system/udev.service -> /lib/systemd/system/udev.service [OVERRIDDEN] /etc/systemd/system/getty@.service -> /lib/systemd/system/getty@.service --- /lib/systemd/system/getty@.service 2016-05-23 11:33:34.0 + +++ /etc/systemd/system/getty@.service 2016-05-26 22:47:13.0 + @@ -21,7 +21,7 @@ # On systems without virtual consoles, don't start any getty. Note # that serial gettys are covered by serial-getty@.service, not this # unit. -ConditionPathExists=/dev/tty0 +# ConditionPathExists=/dev/tty0 [Service] # the VT is cleared by TTYVTDisallocate [EXTENDED] /lib/systemd/system/systemd-timesyncd.service -> /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf [REDIRECTED] /etc/systemd/system/default.target -> /lib/systemd/system/default.target [OVERRIDDEN] /etc/systemd/system/getty-static.service -> /lib/systemd/system/getty-static.service --- /lib/systemd/system/getty-static.service 2016-05-23 07:42:55.0 + +++ /etc/systemd/system/getty-static.service 2016-05-26 22:47:13.0 + @@ -1,10 +1,10 @@ [Unit] -Description=getty on tty2-tty6 if dbus and logind are not available +Description=getty on tty2-tty4 if dbus and logind are not available ConditionPathExists=/dev/tty2 ConditionPathExists=!/lib/systemd/system/dbus.service [Service] Type=oneshot -ExecStart=/bin/systemctl --no-block start getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service +ExecStart=/bin/systemctl --no-block start getty@tty2.service getty@tty3.service getty@tty4.service RemainAfterExit=true [MASKED] /etc/systemd/system/systemd-udevd.service -> /lib/systemd/system/systemd-udevd.service [REDIRECTED] /etc/systemd/system/sigpwr.target -> /lib/systemd/system/sigpwr.target [OVERRIDDEN] /etc/udev/rules.d/80-net-setup-link.rules -> /lib/udev/rules.d/80-net-setup-link.rules --- /lib/udev/rules.d/80-net-setup-link.rules 2016-05-23 11:33:34.0 + +++ /etc/udev/rules.d/80-net-setup-link.rules 2016-05-31
Bug#724944: [Intel-gfx] Patch for crashing intel server
On Sun, Nov 03, 2013 at 04:15:18PM +0100, Bas Wijnen wrote: Hi Chris, I got a black screen while using your patch. /sys/kernel/debug/dri/0/i915_gem_objects contents are shown below. The first time is while the video is running; the second after stopping it. AFAICS, there is no difference between them. Indeed, that scuppers my theory about it being an allocation failure to GEM space exhaustion. I am not sure what else to suggest to explain why it spontaneously fails to allocate that BO. You could try drm.debug=7, but searching for the failure would be like hunting for a needle in a haystack - and I'm not sure if we give any information as to how it fails, nor does libdrm_intel have any such debug. You can try disabling the uxa BO cache with Option BufferCache false and seeing if that makes any difference. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724944: [Intel-gfx] Patch for crashing intel server
On Fri, Oct 25, 2013 at 05:46:53AM +0200, Bas Wijnen wrote: On Wed, Oct 23, 2013 at 09:28:28AM +0100, Chris Wilson wrote: No worries, if you can run addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79 0xf8215 that should give me the information needed to pinpoint the crash. $ addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79 0xf8215 /build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/intel.h:138 /build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/i915_video.c:156 /build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/intel_video.c:1584 Note that I'm running the unpatched Debian version again (so not with your or my patch), which is why it was crashing. Ah. Ok, but we still don't know how we end up in this situation. If you apply the patch to prevent the crash here, can you please report what the contents of /sys/kernel/debug/dri/0/i915_gem_objects is at the time the video goes black? -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724944: [Intel-gfx] Patch for crashing intel server
On Wed, Oct 23, 2013 at 02:30:51AM +0200, Bas Wijnen wrote: On Wed, Oct 16, 2013 at 04:22:43PM +0100, Chris Wilson wrote: On Wed, Oct 16, 2013 at 04:30:57PM +0200, Bas Wijnen wrote: On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote: This does indeed stop the server from crashing, but actually makes the problem worse: it used to play video for a few minutes and then crash when trying. With my patch it would play video for a few minutes and then present black screens when trying. With your patch, it presents black screens from the start. Start of video, or beginning of X? Beginning of X. After starting and logging in, I can play them for a few minutes; afterwards it will crash. Still weird. Can you attach the Xorg.log from the black screen and/or crash. That took some time, because since I switched to xfce, it is a lot more stable. However, after running for a few days it still crashed when trying to play a video. The log is attached. I would have attached a detailed backtrace as well, but unfortunately I forgot to switch the core dump option on when switching from gdm to xdm, so I don't have a core this time. No worries, if you can run addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79 0xf8215 that should give me the information needed to pinpoint the crash. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724944: [Intel-gfx] Patch for crashing intel server
On Wed, Oct 16, 2013 at 04:30:57PM +0200, Bas Wijnen wrote: On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote: This does indeed stop the server from crashing, but actually makes the problem worse: it used to play video for a few minutes and then crash when trying. With my patch it would play video for a few minutes and then present black screens when trying. With your patch, it presents black screens from the start. Start of video, or beginning of X? Beginning of X. After starting and logging in, I can play them for a few minutes; afterwards it will crash. Still weird. Can you attach the Xorg.log from the black screen and/or crash. I must say I'm not entirely sure if the backtrace I sent you is a typical case; I managed to crash it sooner than usual, so perhaps it wasn't the bug that I triggered before. It did stop the crashing however. However, that still leaveas the question as to how you ended up being unable to allocate bo... I didn't check the backtrace myself, but when I wrote my shotgun-patch, the problem was that pixmap_private was NULL; bo is in there, right? So at least in that case, it could never have allocated it, or at least it couldn't store the pointer. I doubt we failed to malloc the intel_pixmap, so the reason why the intel_pixmap would be NULL is more likely due to failure to allocate the GPU buffer object i.e. they are semantically interchangeable, an attached intel_pixmap to a Pixmap implies we have a GPU bo. Similarly checking for the intel_pixmap should be enough to assert that the GPU bo exists. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724944: [Intel-gfx] Patch for crashing intel server
On Tue, Oct 15, 2013 at 03:46:08AM +0200, Bas Wijnen wrote: On Sun, Oct 13, 2013 at 10:43:49AM +0100, Chris Wilson wrote: My X server was crashing when playing video, and I wrote a patch to fix it. Please find the background and the patch at http://bugs.debian.org/724944 . Ok, I can see the allocation failure that leads to the crash: commit f9a18c9f38d09c145eb513ca989966dc135c1e9b Author: Chris Wilson ch...@chris-wilson.co.uk Date: Sun Oct 13 10:36:35 2013 +0100 This does indeed stop the server from crashing, but actually makes the problem worse: it used to play video for a few minutes and then crash when trying. With my patch it would play video for a few minutes and then present black screens when trying. With your patch, it presents black screens from the start. Start of video, or beginning of X? I made two changes. The first to check for a failed GPU pixmap allocation during video playback and the second to check for a failed malloc during Screen initialisation. Neither should be likely. I must say I'm not entirely sure if the backtrace I sent you is a typical case; I managed to crash it sooner than usual, so perhaps it wasn't the bug that I triggered before. It did stop the crashing however. However, that still leaveas the question as to how you ended up being unable to allocate bo... You can watch /sys/kernel/debug/dri/0/i915_gem_objects (or just use intel-gpu-overlay) and see if there is an object leak. I don't have enough knowledge about the internals to know how that works. I can see the file if I mount the debugfs, but what am I looking for? An increase in the number of total objects and allocated bytes. I don't seem to have intel-gpu-overlay on my system; does it make sense to install it? If so, where do I get it? It just presents the same information, so not really important if you are happy with catting the debugfs file. While looking for it I did find and try intel-gpu-time, and noticed that it always reports the gpu 100% busy, even when running intel-gpu-time sleep 5 from a linux virtual terminal (so not even X is displayed). Is that normal? Hmm, looks like it should report correctly on i915. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724944: [Intel-gfx] Patch for crashing intel server
On Sun, Oct 13, 2013 at 05:49:04AM +0200, Bas Wijnen wrote: On Sat, Oct 12, 2013 at 09:46:14PM +0100, Chris Wilson wrote: On Fri, Oct 11, 2013 at 09:24:54PM +0200, Bas Wijnen wrote: Hello, My X server was crashing when playing video, and I wrote a patch to fix it. Please find the background and the patch at http://bugs.debian.org/724944 . The patch is a shotgun solution, putting NULL pointer checks where the pointer is explicitly not allowed to be NULL. I need an actual stacktrace to find the root cause. -Chris Sure thing; you can find it attached. Of course it shows when the segfault is triggered, not when the data became NULL. And that should be fixed, because even though the server doesn't crash with the patch, it also doesn't play video. Ok, I can see the allocation failure that leads to the crash: commit f9a18c9f38d09c145eb513ca989966dc135c1e9b Author: Chris Wilson ch...@chris-wilson.co.uk Date: Sun Oct 13 10:36:35 2013 +0100 uxa: Check for allocation failure in i915 video For a large screen, we have to create a temporary surface for rendering the textured video. If this pixmap creation fails we may be left with a system memory only pixmap leading to a segfault. Reported-by: Bas Wijnen wij...@debian.org Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk However, that still leaveas the question as to how you ended up being unable to allocate bo... You can watch /sys/kernel/debug/dri/0/i915_gem_objects (or just use intel-gpu-overlay) and see if there is an object leak. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693342: ITP: dhrystone -- a popular benchmark for CPU/compiler performance measurement
Package: wnpp Severity: wishlist Owner: Chris Wilson chris+deb...@aptivate.org * Package name: dhrystone Version : 2.1 Upstream Author : Reinhold P. Weicker * URL : www.netlib.org/benchmark/dhry-c * License : Public Domain Programming Lang: C Description : a popular benchmark for CPU/compiler performance measurement The Dhrystone benchmark program has become a popular benchmark for CPU/compiler performance measurement, in particular in the area of minicomputers, workstations, PC's and microprocesors. It apparently satisfies a need for an easy-to-use integer benchmark; it gives a first performance indication which is more meaningful than MIPS numbers which, in their literal meaning (million instructions per second), cannot be used across different instruction sets (e.g. RISC vs. CISC). With the increasing use of the benchmark, it seems necessary to reconsider the benchmark and to check whether it can still fulfill this function. Version 2 of Dhrystone is the result of such a re-evaluation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682910: Please update e2fsprogs to silence kernel's historic error reports after fsck
Package: e2fsprogs Version: 1.41.12-4stable1 Severity: minor On an ext4 filesystem that has ever experienced an error, the kernel reports messages like this: EXT4-fs (md5): error count: 26 EXT4-fs (md5): initial error at 1295452467: ext4_lookup:1043: inode 45679232 EXT4-fs (md5): last error at 1295453545: ext4_lookup:1043: inode 61022838 Apparently the error state is stored in the filesystem, and should have been reset by e2fsck after a successful fsck, but this feature was only added in e2fsck 1.41.14, and squeeze has 1.41.12. So please could you update e2fsck in squeeze with either the patch from upstream that adds that functionality, or to 1.41.14 or higher? Cheers, Chris. -- System Information: Debian Release: 6.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.38-voyage (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages e2fsprogs depends on: ii e2fslibs1.41.12-4stable1 ext2/ext3/ext4 file system librari ii libblkid1 2.17.2-9 block device id library ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-4stable1 common error description library ii libss2 1.41.12-4stable1 command-line interface parsing lib ii libuuid12.17.2-9 Universally Unique ID library ii util-linux 2.17.2-9 Miscellaneous system utilities e2fsprogs recommends no packages. Versions of packages e2fsprogs suggests: pn e2fsck-static none (no description available) pn gpart none (no description available) pn partednone (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#642571: NFS root no longer works with oldstable DHCP server
Hi all, Bug confirmed here. vmlinuz/initramfs from linux-image-2.6.32-5-686 fails to get an IP address in ipconfig during network boot. 2.6.38-1-486 (from the GParted live CD) doesn't have this problem. I can see the DHCPACK packets being sent from the DHCP server to the client, but apparently it doesn't receive or understand them. It's a bit early in the boot process to run a packet sniffer on the client. Also I don't have physical access to this machine (it's 3000 miles away) and every attempt ends in a hang after /inet:...can't open '/tmp/net-*.conf', requiring me to request a manual reboot. Cheers, Chris. -- Aptivate | http://www.aptivate.org | Phone: +44 1223 760887 The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES Aptivate is a not-for-profit company registered in England and Wales with company number 04980791. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615197: xserver-xorg-video-intel: Screen corruptions to due insufficient clipping
On Sun, 15 May 2011 21:51:59 +0200, Julien Cristau jcris...@debian.org wrote:
On Sun, May 15, 2011 at 21:34:26 +0200, Thomas Richter wrote:
Sorry, I don't quite get the question. All what the code does is
that it checks whether the current line (fullY1) is between the top
edge of the current rectangle in the damage region (pbox-y1=
fullY1) and above
the bottom edge of the damage region (pbox-y2 fullY1). It is
probably written in a somewhat unconventional way. A nicer way to
put it is:
fullY1 = pbox-y1 fullY1 pbox-y2
Thus, line at or below the top edge, and above the bottom edge. A
rectangle doesn't have to be invalid to have fullY1 = pbox-y1 and
fullY1 pbox-y2. I'm not quite clear what the break is used for,
but
I assume that the rectangles are ordered by increasing Y coordinate, and
that the code can terminate early if it detects a rectangle in the
damage region that has a top edge below the line.
The clip rectangles are YX banded, so that if we see a rectangle which
starts below the point of interest, we know all further rectangles are
below the point.
The question that remains is then does this rectangle, which we know has
to start above (or equal to) the point extend beyond the point. So we need
to test:
diff --git a/uxa/uxa-accel.c b/uxa/uxa-accel.c
index 0650ac2..56f219c 100644
--- a/uxa/uxa-accel.c
+++ b/uxa/uxa-accel.c
@@ -178,7 +178,7 @@ uxa_fill_spans(DrawablePtr pDrawable, GCPtr pGC, int
n,
if (pbox-y1 fullY1)
break;
- if (pbox-y1 = fullY1) {
+ if (pbox-y2 fullY1) {
partX1 = pbox-x1;
if (partX1 fullX1)
partX1 = fullX1;
which is probably what you said originally. If you send a patch along
these lines, I will gladly apply it. And if you have a test case to hand,
better yet -- collecting examples of where I goofed to prevent repeating
my mistakes...
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619019: [PATCH 1/2] i915: Remove pipe A force quirk for 855GM and 845G
On Tue, 22 Mar 2011 03:05:45 +, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2011-03-21 at 07:38 +, Chris Wilson wrote: On Sun, 20 Mar 2011 23:07:04 +, Ben Hutchings b...@decadent.org.uk wrote: Applying this quirk to the 855GM in all systems causes regressions (Debian bugs #493096, #619019). Instead, apply the quirk to specific models as listed in the old X driver. I don't see any explanation for this quirk being applied to the 845G, except perhaps that VT switching used to hang if pipe A was turned off. However, that seems to be a problem only when using UMS. So remove the quirk for the 845G as well. The quirk should only be required for 830M due to the numerous instances where a unit on the second pipe is actually wired into the clock on the first pipe. (And so it is easiest to keep the first pipe active at all times.) When you say 'wired into', is this part of the chip design or something done on the board? It is mentioned as a feature in several places of the specs for the 830G chipset. Jesse, why did you add the quirk for other chips? I'd prefer the quirk table to disappear and simply be replaced by IS_830M(). However, that requires testing and so should only be done piecemeal. And leaves some doubt as to why the other machines were in the quirk table in the first place. The commit messages referring to VT switching suggest that the problems related to disabling part A may actually have been related to handover to the console driver before KMS. That sounds promising that the code was indeed papering over bugs... Doesn't sound too promising for the state of our code though. :( Can you please repost each of these removals as a separate patch and lets try and get a tested-by for each one? (Make sure the tester includes the model name for his machine so we can double check the veracity of the change.) I already have 4 regression reports for the addition of the quirk for 855GM: http://bugs.debian.org/618665 http://bugs.debian.org/618997 http://bugs.debian.org/619019 http://bugs.debian.org/619192 and one on an unidentified (as yet) chip: http://bugs.debian.org/619199 So I can just send a patch to revert 855GM. I'd still prefer a patch for each quirk removal. Along with a tested-by. ;-) The little bit of time invested now in preparing small commits with be of great benefit should anyone need to investigate later. We have to gradually wean ourselves off the quirk table and convince everybody that the code does actually know how to modeset the chip! The odd thing about these reports is that the regression is reported to occur before the system has ever been suspended, and to be fixed (or mitigated) by suspending and resuming. I don't understand why the quirk even comes into play during boot. During the switch-over from BIOS we disable all the outputs - instant bug. Many thanks for preparing these patches, -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619019: [PATCH 1/2] i915: Remove pipe A force quirk for 855GM and 845G
On Tue, 22 Mar 2011 03:05:45 +, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2011-03-21 at 07:38 +, Chris Wilson wrote: Can you please repost each of these removals as a separate patch and lets try and get a tested-by for each one? (Make sure the tester includes the model name for his machine so we can double check the veracity of the change.) I already have 4 regression reports for the addition of the quirk for 855GM: http://bugs.debian.org/618665 http://bugs.debian.org/618997 http://bugs.debian.org/619019 http://bugs.debian.org/619192 and one on an unidentified (as yet) chip: http://bugs.debian.org/619199 So I can just send a patch to revert 855GM. Yes. Having just been poked by Julien to look at the original quirk table and so seeing the generic match all 855GM, please do send that patch. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619019: [PATCH 1/2] i915: Remove pipe A force quirk for 855GM and 845G
On Sun, 20 Mar 2011 23:07:04 +, Ben Hutchings b...@decadent.org.uk wrote: Applying this quirk to the 855GM in all systems causes regressions (Debian bugs #493096, #619019). Instead, apply the quirk to specific models as listed in the old X driver. I don't see any explanation for this quirk being applied to the 845G, except perhaps that VT switching used to hang if pipe A was turned off. However, that seems to be a problem only when using UMS. So remove the quirk for the 845G as well. The quirk should only be required for 830M due to the numerous instances where a unit on the second pipe is actually wired into the clock on the first pipe. (And so it is easiest to keep the first pipe active at all times.) I'd prefer the quirk table to disappear and simply be replaced by IS_830M(). However, that requires testing and so should only be done piecemeal. And leaves some doubt as to why the other machines were in the quirk table in the first place. Can you please repost each of these removals as a separate patch and lets try and get a tested-by for each one? (Make sure the tester includes the model name for his machine so we can double check the veracity of the change.) -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611576: [pkg-cli-apps-team] Bug#611576: pinta: Package description is inacurate (patch included)
Hi Iain, Thanks for the feedback. I've always associated metadata changes with Debian, without realizing there were different way in which the metadata was implemented. I'll watch out for it in future. I'm also still getting my head round the different way in which patches are created. I'll be sure to take in the contents of the link you posted :) Chris On 31 January 2011 10:08, Iain Lane la...@ubuntu.com wrote: tags 611576 + confirmed upstream severity 611576 wishlist forwarded 611576 https://github.com/jpobst/Pinta/pull/44 thanks Hiya, On Sun, Jan 30, 2011 at 08:48:32PM +, Chris Wilson wrote: Package: pinta Version: 0.4+dfsg-2 Severity: minor Originally reported at https://bugs.launchpad.net/debian/+source/pinta/+bug/704491 The software centre teaser for Pinta is Create and edit images and photographs. This is misleading because it is not possible to create photographs using Pinta. The sentence should therefore be changed. While this is obviously only a very minor issue, the focus in the Natty cycle is quality and I think this is so easily fixable that we should do it. The patch changes the comment to 'An easy way to create and edit images, as images can cover drawings and photographs as well. Thanks for your bug and patch, which I've forwarded upstream and which we'll therefore get with the next release if it is merged. I've got a couple of pointers for your next Debian report that will make maintainers more happy. :-) Your diff contains some changes which are undesirable. If you take a look at it, there's an automated 'debian-changes' patch. You can see (by looking at the debian/source/format file) that this is a 3.0 (quilt) package. That means that the correct way to patch the /upstream/ source is by a quilt patch. Details at [0]. A direct diff of the xdg/pinta.desktop file would also have been perfectly fine. Your changelog has an Ubuntu version and distribution. This is a Debian bug report, so that is inappropriate. You should have used 0.6-2 (or not provided a changelog entry, since we tend to manage those in git semi-automatically anyway) and unstable/experimental as the distribution. In general, changes to /desktop file/, as opposed to package (debian/control) descriptions are best dealt with upstream. They are minor issues that aren't really worth a distribution patch (and all of the associated maintenance) — maintainers may not mind forwarding your patches for you, but it might be more efficient for you to just contact upstream with your suggested new wording yourself. Just some thoughts. Cheers, Iain [0] http://pkg-perl.alioth.debian.org/howto/quilt.html
Bug#611576: pinta: Package description is inacurate (patch included)
Package: pinta Version: 0.4+dfsg-2 Severity: minor Originally reported at https://bugs.launchpad.net/debian/+source/pinta/+bug/704491 The software centre teaser for Pinta is Create and edit images and photographs. This is misleading because it is not possible to create photographs using Pinta. The sentence should therefore be changed. While this is obviously only a very minor issue, the focus in the Natty cycle is quality and I think this is so easily fixable that we should do it. The patch changes the comment to 'An easy way to create and edit images, as images can cover drawings and photographs as well. -- System Information: Debian Release: squeeze/sid APT prefers maverick-updates APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 'maverick-proposed'), (500, 'maverick') Architecture: i386 (i686) Kernel: Linux 2.6.35-22-generic (SMP w/1 CPU core) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pinta depends on: ii libc6 2.12.1-0ubuntu10.2 Embedded GNU C Library: Shared lib ii libglib2.0-cil2.12.10-1 CLI binding for the GLib utility l ii libgtk2.0-cil 2.12.10-1 CLI binding for the GTK+ toolkit 2 ii libmono-cairo2.0-cil 2.6.7-3ubuntu1 Mono Cairo library (for CLI 2.0) ii libmono-corlib2.0-cil 2.6.7-3ubuntu1 Mono core library (for CLI 2.0) ii libmono-posix2.0-cil 2.6.7-3ubuntu1 Mono.Posix library (for CLI 2.0) ii libmono-sharpzip2.84- 2.6.7-3ubuntu1 Mono SharpZipLib library (for CLI ii libmono-system2.0-cil 2.6.7-3ubuntu1 Mono System libraries (for CLI 2.0 ii mono-runtime 2.6.7-3ubuntu1 Mono runtime pinta recommends no packages. pinta suggests no packages. -- no debconf information diff -Nru pinta-0.6/debian/changelog pinta-0.6/debian/changelog --- pinta-0.6/debian/changelog 2011-01-14 20:17:23.0 + +++ pinta-0.6/debian/changelog 2011-01-30 20:33:52.0 + @@ -1,3 +1,10 @@ +pinta (0.6-1ubuntu1) maverick; urgency=low + + * Rewrote 'Comment' field in xdg/pinta.desktop to be less misleading +(LP: #704491) + + -- Chris Wilson afrowi...@gmail.com Sun, 30 Jan 2011 20:29:29 + + pinta (0.6-1) experimental; urgency=low * [5cc59db] Imported Upstream version 0.6 diff -Nru pinta-0.6/debian/patches/debian-changes-0.6-1ubuntu1 pinta-0.6/debian/patches/debian-changes-0.6-1ubuntu1 --- pinta-0.6/debian/patches/debian-changes-0.6-1ubuntu1 1970-01-01 01:00:00.0 +0100 +++ pinta-0.6/debian/patches/debian-changes-0.6-1ubuntu1 2011-01-30 20:34:01.0 + @@ -0,0 +1,37 @@ +Description: Upstream changes introduced in version 0.6-1ubuntu1 + This patch has been created by dpkg-source during the package build. + Here's the last changelog entry, hopefully it gives details on why + those changes were made: + . + pinta (0.6-1ubuntu1) maverick; urgency=low + . + * Rewrote 'Comment' field in xdg/pinta.desktop to be less misleading + (LP: #704491) + . + The person named in the Author field signed this changelog entry. +Author: Chris Wilson afrowi...@gmail.com +Bug-Ubuntu: https://bugs.launchpad.net/bugs/704491 + +--- +The information above should follow the Patch Tagging Guidelines, please +checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here +are templates for supplementary fields that you might want to add: + +Origin: vendor|upstream|other, url of original patch +Bug: url in upstream bugtracker +Bug-Debian: http://bugs.debian.org/bugnumber +Bug-Ubuntu: https://launchpad.net/bugs/bugnumber +Forwarded: no|not-needed|url proving that it has been forwarded +Reviewed-By: name and email of someone who approved the patch +Last-Update: -MM-DD + +--- pinta-0.6.orig/xdg/pinta.desktop pinta-0.6/xdg/pinta.desktop +@@ -1,6 +1,6 @@ + [Desktop Entry] + Name=Pinta +-Comment=Create and edit images and photographs ++Comment=An easy way to create and edit images + GenericName=Image Editor + X-GNOME-FullName=Pinta Image Editor + Exec=pinta diff -Nru pinta-0.6/debian/patches/series pinta-0.6/debian/patches/series --- pinta-0.6/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ pinta-0.6/debian/patches/series 2011-01-30 20:32:41.0 + @@ -0,0 +1 @@ +debian-changes-0.6-1ubuntu1
Bug#611115: squeak-vm: Incorrect category (patch attached)
Package: squeak-vm Version: 1:4.0.3.2202-2 Severity: minor Package squeak is listed as an educational tool. The description reads: Programming system and content development tools. Squeak is a development environment that has been used to implement educational tools like Etoys and Scratch. Squeak itself should be classified as dev tool. -- System Information: Debian Release: squeeze/sid APT prefers maverick-updates APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 'maverick-proposed'), (500, 'maverick') Architecture: i386 (i686) Kernel: Linux 2.6.35-22-generic (SMP w/1 CPU core) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages squeak-vm depends on: ii gettext-base 0.18.1.1-1ubuntu2 GNU Internationalization utilities ii gnome-terminal [ 2.32.0-0ubuntu1 The GNOME terminal emulator applic ii libc62.12.1-0ubuntu10.2 Embedded GNU C Library: Shared lib ii libuuid1 2.17.2-0ubuntu1.10.10.1 Universally Unique ID library ii whiptail 0.52.11-1 Displays user-friendly dialog boxe ii xterm [x-termina 261-1ubuntu3X terminal emulator Versions of packages squeak-vm recommends: ii zenity 2.32.0-0ubuntu1 Display graphical dialog boxes fro Versions of packages squeak-vm suggests: pn squeak-image none (no description available) pn squeak-plugin none (no description available) pn squeak-sourcesnone (no description available) -- no debconf information === modified file 'linex/squeak.desktop' --- linex/squeak.desktop2010-04-17 20:17:57 + +++ linex/squeak.desktop2011-01-25 16:52:57 + @@ -11,5 +11,5 @@ Comment= Programming system and content development tool Comment[es_ES]=Herramienta de desarrollo de contenidos y aplicaciones Comment[de_DE]=Programmier- und Multimediaentwicklungsumgebung -Categories=Application;Education;Development; +Categories=Application;Development; MimeType=application/x-image;application/squeak-image;application/squeak-project
Bug#610432: frama-c: Wrong category set in 'debian/control'
Package: frama-c Version: 20100401+boron+dfsg-4 (frama-c) Severity: minor Originally reported at https://bugs.launchpad.net/hundredpapercuts/+bug/613853 Actually the package Frama-C is listed in 'Science/Mathematics' category, but it's a tool to help analyse C source Code. It should go instead in category: Tools for Developers. -- System Information: Debian Release: squeeze/sid APT prefers maverick-updates APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 'maverick-proposed'), (500, 'maverick') Architecture: i386 (i686) Kernel: Linux 2.6.35-22-generic (SMP w/1 CPU core) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609356: zanshin: description does not adequately convey the purpose of the app
Package: zanshin Version: 0.1+svn1006410-0ubuntu5 Severity: minor A Getting Things Done application which aims at getting your mind like water. This description is rather short and does not convey to the user the primary use-cases of the software. I propose the following alternative desctiption: Zanshin is a simple task managern and TODO list that provides the user with two way in which to view their tasks - 'project view' and 'context view'. In 'project view', the user can view tasks as they have been assigned to different projects, such as 'Mum's surprise birthday party', 'Shopping list', 'Housework' and 'School Assignments'. Context view allows the user to view their task based on a particular context. For example, they can view the tasks that involve the computer in some way, with a particular sub-context being 'online shopping', they an view tasks that require them to make a phone call, or to go into town. Originally reported: https://bugs.launchpad.net/hundredpapercuts/+bug/613306 -- System Information: Debian Release: squeeze/sid APT prefers maverick-updates APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 'maverick-proposed'), (500, 'maverick') Architecture: i386 (i686) Kernel: Linux 2.6.35-22-generic (SMP w/1 CPU core) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages zanshin depends on: ii kdebase-runtime 4:4.5.1-0ubuntu3.1 runtime components from the offici ii kdepim-runtime4:4.4.6-0ubuntu1 Runtime components for akonadi-kde ii libakonadi-kde4 4:4.5.1-0ubuntu1 library for using the Akonadi PIM ii libc6 2.12.1-0ubuntu10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.5.1-7ubuntu2 GCC support library ii libkabc4 4:4.5.1-0ubuntu1 library for handling address book ii libkcal4 4:4.5.1-0ubuntu1 library for handling calendar data ii libkdecore5 4:4.5.1-0ubuntu8 the KDE Platform Core Library ii libkdeui5 4:4.5.1-0ubuntu8 the KDE Platform User Interface Li ii libkresources44:4.5.1-0ubuntu1 the KDE Resource framework library ii libqt4-dbus 4:4.7.0-0ubuntu4.2 Qt 4 D-Bus module ii libqt4-svg4:4.7.0-0ubuntu4.2 Qt 4 SVG module ii libqtcore44:4.7.0-0ubuntu4.2 Qt 4 core module ii libqtgui4 4:4.7.0-0ubuntu4.2 Qt 4 GUI module ii libstdc++64.5.1-7ubuntu2 The GNU Standard C++ Library v3 zanshin recommends no packages. zanshin suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609261: zim: Package description is confusing to non tech-savvy users
Package: zim Version: 0.47-1 Severity: minor Zim is a WYSIWYG text editor. It aims at bringing the concept of a wiki to your desktop. For example every page is saved as a text file with wiki markup. Pages can contain links to other pages, and are saved automatically. Creating a new page is as easy as linking to a non-existing page. Pages are ordered in a hierarchical structure that gives it the look and feel of an outliner. It states it is a WYSIWYG text editor, which no one knows what that is, and it doesn't even really explain it. Even the description of It aims at bringing the concept of a wiki to your desktop is not really that helpful to an end user. Describing what it actually does before what it technically is or what it aims to do would be more helpful. The second paragraph is a much better description that would not confuse a user. -- System Information: Debian Release: squeeze/sid APT prefers maverick-updates APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 'maverick-proposed'), (500, 'maverick') Architecture: i386 (i686) Kernel: Linux 2.6.35-22-generic (SMP w/1 CPU core) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages zim depends on: ii python 2.6.6-2ubuntu2 interactive high-level object-orie ii python-gtk2 2.21.0-0ubuntu1 Python bindings for the GTK+ widge ii python-simplejson2.1.1-1 simple, fast, extensible JSON enco ii python-support 1.0.9ubuntu1automated rebuilding support for P ii python-xdg 0.19-2ubuntu1 Python library to access freedeskt Versions of packages zim recommends: ii python-gtkspell 2.25.3-5ubuntu2 Python bindings for the GtkSpell l Versions of packages zim suggests: ii bzr2.2.2-0~bazaar1~maverick1 easy to use distributed version co ii dvipng 1.13-1convert DVI files to PNG graphics pn graphviz none(no description available) ii scrot 0.8-11command line screen capture utilit -- 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#609261: Additional information
Package: zim Version: 0.47-1 Severity: normal Originally reported at https://bugs.launchpad.net/debian/+source/zim/+bug/613303 -- System Information: Debian Release: squeeze/sid APT prefers maverick-updates APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 'maverick-proposed'), (500, 'maverick') Architecture: i386 (i686) Kernel: Linux 2.6.35-22-generic (SMP w/1 CPU core) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages zim depends on: ii python 2.6.6-2ubuntu2 interactive high-level object-orie ii python-gtk2 2.21.0-0ubuntu1 Python bindings for the GTK+ widge ii python-simplejson2.1.1-1 simple, fast, extensible JSON enco ii python-support 1.0.9ubuntu1automated rebuilding support for P ii python-xdg 0.19-2ubuntu1 Python library to access freedeskt Versions of packages zim recommends: ii python-gtkspell 2.25.3-5ubuntu2 Python bindings for the GtkSpell l Versions of packages zim suggests: ii bzr2.2.2-0~bazaar1~maverick1 easy to use distributed version co ii dvipng 1.13-1convert DVI files to PNG graphics pn graphviz none(no description available) ii scrot 0.8-11command line screen capture utilit -- 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#596085: xserver-xorg-video-intel: partial display corruption / mostly text / Mobile 945GM
On Wed, 8 Sep 2010 17:34:39 +0200, Julien Cristau jcris...@debian.org wrote: Hi Chris, does the following look like a known bug with 2.12? It might be an issue with 2.6.32 between the memory corruption and 945GM low-power render failure. As it looks like uninitialised data, it could be the xserver bug where we sent damage events prior to flushing the 2D batchbuffer, so that there was an opportunity for compositing WM to grab garbage. If you can verify that it is not either of those bugs, then yeah it's an unresolved bug. There are a couple of similar bugs still in fd.o that I'm still waiting on feedback for (but I think are due to the above). -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596085: xserver-xorg-video-intel: partial display corruption / mostly text / Mobile 945GM
On Wed, 8 Sep 2010 18:38:09 +0200, Julien Cristau jcris...@debian.org wrote: On Wed, Sep 8, 2010 at 17:10:36 +0100, Chris Wilson wrote: As it looks like uninitialised data, it could be the xserver bug where we sent damage events prior to flushing the 2D batchbuffer, so that there was an opportunity for compositing WM to grab garbage. That one's plausible, thanks. Florian, are you running a compositing manager? If yes, does the corruption happen without that? Looks like the fix for that one is 8d7b7a0d71e0b89321b3341b781bc8845386def6 and c65f610e12f9df168d5639534ed3c2bd40afffc8? And 69d65f9184006eac790efcff78a0e425160e95aa for -intel. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495797: [patch] for xdmcp xwilling crash
Dear sirs,
The attached patch (fixing the double free in gdm-xdmcp-manager.c) fixes
the crash for me.
Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.diff -ru gdm-2.20.7/daemon/gdm-xdmcp-manager.c gdm-2.20.7-chris/daemon/gdm-xdmcp-manager.c
--- gdm-2.20.7/daemon/gdm-xdmcp-manager.c 2008-06-30 18:53:13.0 +0100
+++ gdm-2.20.7-chris/daemon/gdm-xdmcp-manager.c 2009-02-05 12:55:04.0 +
@@ -401,12 +401,12 @@
sock = socket (ai-ai_family, ai-ai_socktype, ai-ai_protocol);
if (sock 0) {
- gdm_debug (socket: %s, g_strerror (errno));
+ gdm_error (socket: %s, g_strerror (errno));
return sock;
}
if (bind (sock, ai-ai_addr, ai-ai_addrlen) 0) {
- gdm_debug (bind: %s, g_strerror (errno));
+ gdm_error (bind: %s, g_strerror (errno));
close (sock);
return -1;
}
@@ -728,7 +728,6 @@
s = get_willing_output (manager);
if (s != NULL) {
- g_free (last_status);
last_status = s;
} else {
last_status = g_strdup (manager-priv-sysid);
--- gdm-2.20.7/daemon/server.c 2008-06-30 18:53:13.0 +0100
+++ gdm-2.20.7-chris/daemon/server.c 2009-02-05 11:55:05.0 +
@@ -1053,9 +1053,14 @@
str = ve_sure_string (svr-command);
svr_command = NULL;
- g_shell_parse_argv (str, svr_argc, svr_command, NULL);
- g_shell_parse_argv (disp-command, argc, argv, NULL);
+ GError* error_p;
+
+ g_assert(g_shell_parse_argv (str, svr_argc,
+svr_command, error_p));
+
+ g_assert(g_shell_parse_argv (disp-command, argc,
+argv, error_p));
if (argv[0] == NULL || argv[1] == NULL) {
g_strfreev (argv);
Bug#495797: [Bug 530585] XDMCP does not work (fwd)
Please note: the double free part of the patch has been applied upstream. Please apply to Ubuntu Hardy GDM. Cheers, Chris. http://bugzilla.gnome.org/show_bug.cgi?id=530585#c13 --- Comment #13 from Brian Cameron 2009-02-05 22:27 UTC --- Thanks. I committed the patch to the 2.20 branch with a minor change. I removed the g_assert's from the calls to g_shell_parse_argv. I worry that asserting could cause the daemon to exit which would cause problems for any running displays, I'd think. I would accept any further patches to improve the error handling, but I suspect just asserting isn't the best answer here. Otherwise the patch looks correct. The double-free problem is a pretty obvious bug.. -- Aptivate | http://www.aptivate.org | Phone: +44 1223 760887 The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES Aptivate is a not-for-profit company registered in England and Wales with company number 04980791. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#479145: [Box Backup] Re: Bug#479145: boxbackup-client: Complaints about «file of unknown type» (socket)
Hi Reinhard, On Tue, 20 May 2008, Reinhard Tartler wrote: Tollef Fog Heen [EMAIL PROTECTED] writes: Hi, it seems like boxbackup-client doesn't know how to ignore sockets and so I get lines in daemon log like: May 2 23:07:44 xoog Box Backup (bbackupd)[3512]: WARNING: Ignoring file of unknown type: /var/run/postgresql/.s.PGSQL.5432 May 2 23:07:44 xoog Box Backup (bbackupd)[3512]: WARNING: Ignoring file of unknown type: /var/run/postgresql/.s.PGSQL.5433 This causes boxbackup-client to send email about «files not being backed up», which is quite annoying. ... Now, as a workaround, you could of course add an explicit ignore in your boxbackup configuration to work around this issue. I'm not sure if this is the 'correct' way to solve this problem. TBH, I'd rather expect boxbackup to 'more or less' silently ignore this. I'm therefore inclined to change that line of code from BOX_WARNING to BOX_INFO. What do the boxbackup developers think of this? I'm not sure that it's a good idea to change the warning level. Other files that people might expect to be backed up, such as device nodes in /dev, are also not supported and I think we should warn users about this. However, I see zero value in backing up sockets, and I'd be quite happy to simply ignore them. Any objections? Cheers, Chris. -- _ __ _ \ __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \ _/_/_/_//_/___/ | We are GNU : free your mind your software |
Bug#474136: [cairo] Error when creating pdf charts for new FreeSerifItalic.ttf
On Thu, 2008-04-03 at 11:09 -0700, Carl Worth wrote:
On Thu, 3 Apr 2008 17:28:37 +0200, Davide Viti wrote:
I get the following error when creating pdf (or ps) charts for
FreeSerifItalic.ttf
[EMAIL PROTECTED]:~/dejavu/freefont$ fntsample -f FreeSerifItalic.ttf -o
test.pdf
fntsample: /home/dajobe/dev/debian/cairo/cairo-1.4.14/src/cairo-array.c:301:
_cairo_array_allocate: Assertion `array-num_elements + num_elements
= array-size' failed.
Davide,
Thanks so much for the bug report, (particularly with the nice easy
recipe for replicating the bug).
My investigations suggest that the cause of the assertion failure is an
integer overflow during _cairo_array_grow_by() due to this chunk in
cairo-truetype-subset.c (line 574):
if (be16_to_cpu (header.index_to_loc_format) == 0) {
begin = be16_to_cpu (u.short_offsets[index]) * 2;
end = be16_to_cpu (u.short_offsets[index + 1]) * 2;
}
else {
begin = be32_to_cpu (u.long_offsets[index]);
end = be32_to_cpu (u.long_offsets[index + 1]);
}
size = end - begin; /* --overflow */
I've added some defensive code to treat the symptoms, but I don't know
whether the root cause is either a bad font or that we are
misinterpreting it.
--
Chris Wilson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435860: [Box Backup] Re: Bug#435860: boxbackup-client: AlwaysInclude[File|Dir] is not working as expected
Hi Andreas, On Sun, 5 Aug 2007, Andreas Putzo wrote: Ah ok. I assumed something like this. Perhaps the comments in the generated bbackupd.conf should be improved then to be more clear on this. It can be terrible if one learns the hard way, that the backup system is not backing up all the files you was thinking it would. :) Yes, but that can happen to any backup system, that's why test restores are important (nothing else will really reassure you). At the moment, the workarounds are to either (1) create a new location, or (2) exclude all files and directories under the excluded directory, except the ones on the path to the AlwaysIncluded directory, like so: I have several directives like this in my config. Since they are all subdirectories of 'home' i don't want to create different locations for each of them. Why not? Using (2) would render the config file more complicated and error-prone. Indeed. If the include/exclude logic can be improved to be aware of AlwaysIncluded subdirectories i would appreciate this. I wish it were so simple, but because AlwaysInclude*Regex can apply at any point in the tree, it would mean that we always have to scan all the way down the tree. So we'd need another directive like SkipDir(sRegex) to completely exclude descending into a directory and any possibility of files inside it being backed up. Cheers, Chris. -- _ __ _ \ __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435860: [Box Backup] Re: Bug#435860: boxbackup-client: AlwaysInclude[File|Dir] is not working as expected
Hi Andreas, On Sun, 5 Aug 2007, Andreas Putzo wrote: If the include/exclude logic can be improved to be aware of AlwaysIncluded subdirectories i would appreciate this. I wish it were so simple, but because AlwaysInclude*Regex can apply at any point in the tree, it would mean that we always have to scan all the way down the tree. So we'd need another directive like SkipDir(sRegex) to completely exclude descending into a directory and any possibility of files inside it being backed up. Mmh, true. I wasn't thinking about that because i was using a simple ExcludeDir/AlwaysIncludeDir directive without any regex in it. After all, i think the current possibilities to define backup locations are already powerful enough. Actually, I don't think they are. There is no way to exclude some files inside a location that is AlwaysIncluded. I think an Exclude/Include/Exclude/Include type of system would be much better, but I don't have time to implement it yet. It's just that i got fooled (dumb me :) by the comment # For example: # # ExcludeDir = /home/guest-user # ExcludeFilesRegex = \.(mp3|MP3)$ # AlwaysIncludeFile = /home/username/veryimportant.mp3 # # In general, Exclude excludes a file or directory, unless the # directory is explicitly mentioned in a AlwaysInclude directive. Perhaps it would be sufficient to be a little more precise on this, eg. that AlwaysIncludeFile = /home/guest-user/veryimportant.mp3 will not work in the above example. Thanks for pointing that out, I think I've fixed the script that generates the bbackupd.conf file to include more accurate comments. Cheers, Chris. -- _ __ _ \ __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435860: [Box Backup] Re: Bug#435860: boxbackup-client: AlwaysInclude[File|Dir] is not working as expected
Hi Andreas,
On Fri, 3 Aug 2007, Reinhard Tartler wrote:
Andreas Putzo [EMAIL PROTECTED] writes:
from the config file:
BackupLocations
{
home
{
Path = /home/andreas
ExcludeDir = /home/andreas/chroot
AlwaysIncludeDir = /home/andreas/chroot/sid/home/andreas
}
}
I expected that /home/andreas/chroot/sid/home/andreas would be
included in the backup but this is not the case.
boxbackup is running several days now so it should be there, even in
lazy mode.
Unfortunately not. If you Exclude a directory, then Box Backup will never
scan it or its subdirectories, and will never make it down the tree to
/home/andreas/chroot/sid/home/andreas which should be backed up.
At the moment, the workarounds are to either (1) create a new location, or
(2) exclude all files and directories under the excluded directory, except
the ones on the path to the AlwaysIncluded directory, like so:
ExcludeFilesRegex = /home/andreas/chroot/.*
ExcludeDirsRegex = /home/andreas/chroot/.*
AlwaysIncludeDir = /home/andreas/chroot/sid
AlwaysIncludeDir = /home/andreas/chroot/sid/home
AlwaysIncludeDir = /home/andreas/chroot/sid/home/andreas
AlwaysIncludeFilesRegex = /home/andreas/chroot/sid/home/andreas/.*
AlwaysIncludeDirsRegex = /home/andreas/chroot/sid/home/andreas/.*
I'm sorry that this is not very convenient. I would like to change the
include/exclude logic in a subsequent release to make it easier to specify
configurations like yours.
Cheers, Chris.
--
_ __ _
\ __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435860: [Box Backup] Re: Bug#435860: boxbackup-client: AlwaysInclude[File|Dir] is not working as expected
Hi Reinhard, On Fri, 3 Aug 2007, Reinhard Tartler wrote: Hi boxbackup developers. I tried to forwarded the following bug in the trac, but I keep on getting the error: Submission rejected as potential spam (Akismet says content is spam). I'm therefore forced to submit this bug via email. Sorry about that, it should hopefully be fixed now. Cheers, Chris. -- _ __ _ \ __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435860: [Box Backup] Re: Bug#435860: boxbackup-client: AlwaysInclude[File|Dir] is not working as expected
Hi all, especially James, On Fri, 3 Aug 2007, Reinhard Tartler wrote: I tried to forwarded the following bug in the trac, but I keep on getting the error: Submission rejected as potential spam (Akismet says content is spam). I'm therefore forced to submit this bug via email. Please could you look into this? Cheers, Chris. -- _ __ _ \ __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416605: [Box Backup] Bug#416605: ITP: boxbackup -- Server and Clients for the BoxBackup remote backup system
Hi Reinhard, On Fri, 30 Mar 2007, Reinhard Tartler wrote: That's not much of a problem, I think. I'd rather focus on released versions than contantly updating to the latest svn trunk version, unless there is a specific reason to do so. (bugs, etc.). Well, 0.10 is old and has a few known bugs, but we should have 0.11 out this summer, so that's fine by me. What I could think of was to have the latest released version in debian/unstable, and if necessary a later development version in experimental, if you think this would help. Yes, it would help a lot, thanks! Do you have experience with packaging? Whould you be comfortable with maintaining the packaging in bazaar? Yes with RPM, no with .deb. I wouldn't be comfortable yet, but I could learn. Cheers, Chris. -- _ __ _ \ __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416605: [Box Backup] Bug#416605: ITP: boxbackup -- Server and Clients for the BoxBackup remote backup system
Hi Reinhard, On Thu, 29 Mar 2007, Reinhard Tartler wrote: Chris Wilson [EMAIL PROTECTED] writes: I'm currently using boxbackup for my private use. I've crafted packages for my own used based on the ones from Jérôme Schell, I needed to apply one patch from upstream though. I'd like to see boxbackup in debian, so I'm filing this ITP. Help with this package is highly appreciated. Please could you send the patch, so that I review it for inclusion in my tree at least? Why at least? I don't have commit rights (at least, not without review) to the main Box Backup trunk, but I maintain my own tree and I'm the most active developer at the moment, so the best way (IMHO) to get this change committed to the trunk is via my working tree. If it's possible, I'd be very interested to see Box Backup packages for my working tree (as well as trunk) in Debian unstable. Well, find it attached, it was taken from upstream svn. Thanks! Will review and test. Are you interested in maintaining boxbackup in debian, then? Yes, I'm interested in supporting Box on all platforms, and I run Ubuntu on my laptop so I'm interested in Debian packages as well. Thanks for your support! Cheers, Chris. -- _ __ _ \ __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |
Bug#416605: [Box Backup] Bug#416605: ITP: boxbackup -- Server and Clients for the BoxBackup remote backup system
Hi Reinhard, On Thu, 29 Mar 2007, Reinhard Tartler wrote: Chris Wilson [EMAIL PROTECTED] writes: I'm currently using boxbackup for my private use. I've crafted packages for my own used based on the ones from Jérôme Schell, I needed to apply one patch from upstream though. I'd like to see boxbackup in debian, so I'm filing this ITP. Help with this package is highly appreciated. Please could you send the patch, so that I review it for inclusion in my tree at least? Well, find it attached, it was taken from upstream svn. Yes, it is already applied to the Box Backup trunk, it will be in the next release. Cheers, Chris. -- _ __ _ \ __/ / ,__(_)_ | Chris Wilson at qwirx.com - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |
