Bug#274747: type-handling: 274747: dpkg-dev dependency removal
Hi all, I just added Depends: linux to iotop (arch all, written in python and depends on a Linux kernel) before I realised that type-handling pulls in dpkg-dev. I would really appreciate it if the type-handling Provides were split off into a second package, or maybe dpkg is the right place for the Provides? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#274747: type-handling: 274747: dpkg-dev dependency removal
On Thu, 2011-11-17 at 03:11 +0100, Guillem Jover wrote: > dpkg is not the right place for the Provides, those are a hack, are > overstepping on the package name space, and they should really go. ... > * The second case comes from conflating the two roles of arch:all >packages, saving archive space by avoiding duplication sharing >the same files across arches and shipping truly arch independent >files/scripts. In the iotop case the scripts are not arch independent >even if they are shareable. Restricting it by uninstallability is >just another hack, the users on a package manager frontend will >wonder why they are shown a packages they cannot possibly install, >the Packages files get unneedingly bloated, etc. A possible clean >solution to this could be something like: linux-all, all-i386, etc, >for example which was discussed already during the design of the >arch wildcards. I have now switched iotop to Architecture: linux-any and dropped the Depends: linux. Unfortunately linux-all is not available yet. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
integrating Debian GNU/kFreeBSD into InstallingDebianOn?
Hi all, [Please CC me in reply, not subscribed to either list] With the upcoming Debian squeeze release, the Debian GNU/kFreeBSD port will be available in release form. As such, the installation of it on specific machines will be a candidate for documentation in the InstallingDebianOn section of the wiki. InstallingDebianOn is an effort to document how to install, configure and use Debian on some specific hardware. http://wiki.debian.org/InstallingDebianOn Until now, all the guides were written for Debian GNU/Linux, so I am wondering how to integrate kFreeBSD into the new guides that will be written for squeeze. As an example, here is my primary machine: http://wiki.debian.org/InstallingDebianOn/Dell/Inspiron6400/lenny http://wiki.debian.org/InstallingDebianOn/Dell/Inspiron6400/etch When squeeze is released I'll probably do a new install on a spare hard drive to test installation again and ensure nothing is different to lenny. I'll probably try installing Debian GNU/kFreeBSD too, to see how the hardware support is going. I'm currently thinking that a second column for kFreeBSD could be added to the Overall Status section of the template and the Configuration section split up into Debian GNU/Linux and Debian GNU/kFreeBSD sub-sections. http://wiki.debian.org/InstallingDebianOn/ComputerTemplate Also, I'm wondering if the pages for specific releases should be merged into one page? The tweeks could be marked as specific to a release. PS: promotion of and contribution to InstallingDebianOn is highly recommended. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: integrating Debian GNU/kFreeBSD into InstallingDebianOn?
On Thu, 2010-03-11 at 10:25 +0100, Alan BRASLAU wrote: > Being optimistic and naively believing that kfreebsd is near to being > released for mainstream Debian, I installed kfreebsd-i386 on an older > machine that was in need of a complete re-install from scratch. > My conclusions for the moment is that it is only marginally usable. That is a shame. Hopefully the squeeze freeze delay can give the kFreeBSD porters time to find and fix these issues. > Some applications are simply missing and compile (and run) > seemingly without problems from Debian sources. One such > example that I have found is povray. Why is this so? povray is in non-free, it may be that no autobuilders exist for non-free for kfreebsd-* yet. Someone may need to contact the non-free buildd network maintainers to get support for the new ports added. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: integrating Debian GNU/kFreeBSD into InstallingDebianOn?
On Thu, 2010-03-18 at 08:58 +0100, Alan BRASLAU wrote: > Concerning povray, I had forgotten (or did not realize) > that it is non-free. I am aware that there are some > licensing issues with the beta version, but did not > imagine that the stable version was anything other than > open source... povray releases source code, but has never been free software. There was a plan to rectify that for povray 4 by relicensing stuff where possible and rewriting the rest of the code. Last I saw the povray folks haven't released 3.7, let alone started on povray 4. > By the way, another hitch for the moment is a need to port openjdk-6. > Is anyone working on this? From Google it appears there are some people doing that, but none that I can see for Debian GNU/kFreeBSD. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part
Re: Bug#698909: installation-reports: successful install in GNOME Boxes using kFreeBSD
On Fri, 2013-01-25 at 19:47 +, Steven Chamberlain wrote: > Not a problem... I've had a read through and we can follow up on some > things in separate bug reports. Ok great. > Yes, harmless. Should be able to silence it by picking out just the > relevant bit from Jeff Epler's patch here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693510#55 Great, it was a bit scary since I never installed kFreeBSD before. > Oh. Didn't even know that existed. Do you know where specifically it's > implemented in code? I don't think it exists at all yet. Implementing it would require udebs for all the GeoIP related packages and a Debian-hosted service to provide public IP address information to the installer for folks without a public IP address. > Is this any different from GNU/Linux? AFAIK neither of those are > intended to be defaults yet, as they're 'unofficial' *.d.n services. > See also #697488... I haven't used GNU/Linux d-i since DebConf8 but I guess it is the same. Despite being unofficial services, I have been using both. First cdn.d.n and then http.d.n. http.d.n had some issues due to apt bug #616064, The apt bug is still open but Raphael added mirror checking code that drops mirrors automatically when they are problematic wrt #616064. I think it is well past time they became official services. Especially the mirror checking code on http.d.n should be replacing the existing mirror checking code. > This sounds familiar. I though maybe http.d.n offers mirrors sometimes > that don't carry wheezy/sid suites for GNU/kFreeBSD. The command was downloading a Release file and grepping it for Suite| Codename and comparing that to wheezy. That doesn't involve GNU/kFreeBSD specific files at all. The Release files are per-suite so unless the mirror chose a mirror without wheezy everything should be fine. I thought http.d.n knew about Release files and suites and stuff so I'm a bit surprised this is possible. > Ahhh this is really cool. I was already in the middle of making > something to capture and summarise this kind of thing, from syslog > during test installs. I just manually inspected the report and copied them out. > These are all used by the installation-report report-hw script, so not > really installer bugs: I guess you will file bugs in the appropriate places? > The stripped-down /etc/group in d-i doesn't have operator. We could > maybe ask for it to be added (in rootskel). Sounds like a good idea. > Were you able to check you had working display+mouse+keyboard in Xorg? It definitely worked, I was using the graphical installer at this point. > That's worrying. It should be a supported flag. I guess that is limitation with the device qemu/kvm emulated? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#730258: please add arch-specific BTS tags
On Sun, Nov 24, 2013 at 5:53 AM, Don Armstrong wrote: > These are the list of ports that I see: I would strongly suggest not hardcoding this list and instead harvesting the Architecture fields of the Release files for oldstable -> experimental on ftp.d.o, ftp.d-p.o and maybe archive.d.o. We have made this mistake and similar ones (usually hardcoding release codenames) in the QA infrastructure and it has bitten us hard in the past. Lets not make that mistake here. The release files are the closest to a canonical list of ports. There are other ports out there not maintained on d-p.o (like the Interix or Solaris ones for example) but I don't think we need to bother about those until they move closer to Debian. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6evh+_xumxvgd5w8a8kd1laxgggylnmuxstbllu4ou...@mail.gmail.com
Bug#749327: libkvm-dev: some manual pages are broken symlinks to /home/rmh/*
Package: libkvm-dev Version: 10.0-5 Severity: normal User: debian...@lists.debian.org Usertags: broken-symlink adequate Some of the manual pages are symlinks to an absolute path that would only exist on the system of the developer who uploaded the package. Please fix them to be relative links to the relevant manual page. This bug report brought to you by adequate: http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/ lrwxr-xr-x 1 root root 89 Mar 22 19:42 /usr/share/man/man3/kvm_close.3.gz -> /home/rmh/hacking/kfreebsd/trunk/freebsd-libs/debian/tmp/usr/share/man/man3/kvm_open.3.gz lrwxr-xr-x 1 root root 92 Mar 22 19:42 /usr/share/man/man3/kvm_dpcpu_setcpu.3.gz -> /home/rmh/hacking/kfreebsd/trunk/freebsd-libs/debian/tmp/usr/share/man/man3/kvm_getpcpu.3.gz lrwxr-xr-x 1 root root 93 Mar 22 19:42 /usr/share/man/man3/kvm_getargv.3.gz -> /home/rmh/hacking/kfreebsd/trunk/freebsd-libs/debian/tmp/usr/share/man/man3/kvm_getprocs.3.gz lrwxr-xr-x 1 root root 93 Mar 22 19:42 /usr/share/man/man3/kvm_getenvv.3.gz -> /home/rmh/hacking/kfreebsd/trunk/freebsd-libs/debian/tmp/usr/share/man/man3/kvm_getprocs.3.gz lrwxr-xr-x 1 root root 92 Mar 22 19:42 /usr/share/man/man3/kvm_getmaxcpu.3.gz -> /home/rmh/hacking/kfreebsd/trunk/freebsd-libs/debian/tmp/usr/share/man/man3/kvm_getpcpu.3.gz lrwxr-xr-x 1 root root 89 Mar 22 19:42 /usr/share/man/man3/kvm_openfiles.3.gz -> /home/rmh/hacking/kfreebsd/trunk/freebsd-libs/debian/tmp/usr/share/man/man3/kvm_open.3.gz lrwxr-xr-x 1 root root 89 Mar 22 19:42 /usr/share/man/man3/kvm_write.3.gz -> /home/rmh/hacking/kfreebsd/trunk/freebsd-libs/debian/tmp/usr/share/man/man3/kvm_read.3.gz -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libkvm-dev depends on: ii kfreebsd-kernel-headers 10.0~5 ii libbsd-dev 0.6.0-2 ii libc0.1-dev [libc-dev] 2.18-5 ii libkvm6 10.0-5 libkvm-dev recommends no packages. libkvm-dev suggests no packages. -- no debconf information -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#767102: munin-plugins-core: df* plugins report warnings for special filesystems on kFreeBSD
Package: munin-plugins-core Version: 2.0.6-4+deb7u2 Control: found -1 2.0.24-1 Severity: normal File: /usr/share/munin/plugins/df* User: debian-ad...@lists.debian.org Usertags: needed-by-DSA-Team Control: user debian-bsd@lists.debian.org Control: usertags -1 + kfreebsd X-Debbugs-CC: debian-ad...@lists.debian.org, debian-bsd@lists.debian.org As you can see on Debian's munin problems page, the df* plugins report warnings due to some special filesystems on kFreeBSD. Login info here: https://dsa.debian.org/ https://munin.debian.org/problems.html The workaround is to exclude these filesystem types from df output: devfs fdescfs linprocfs sysfs The fix appears to involve figuring out why munin does not use the freebsd plugins on kFreeBSD, teaching the freebsd plugins about GNU coreutils df and adding sysfs to ignored filesystem types. http://sources.debian.net/src/munin/2.0.24-1/plugins/node.d.freebsd/df.in http://sources.debian.net/src/munin/2.0.24-1/plugins/node.d.freebsd/df_inode.in -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#767102: munin-plugins-core: df* plugins report warnings for special filesystems on kFreeBSD
On Tue, 2014-10-28 at 21:28 +0800, Paul Wise wrote: > As you can see on Debian's munin problems page, the df* plugins report > warnings due to some special filesystems on kFreeBSD. ... > The workaround is to exclude these filesystem types from df output: I've now pushed this workaround to DSA's munin configs so the kFreeBSD hosts will soon disappear from the problems page. https://anonscm.debian.org/cgit/mirror/dsa-puppet.git/commit/?id=90d7596ee685a019f28e1af474c52b121ca37161 > The fix appears to involve figuring out why munin does not use the > freebsd plugins on kFreeBSD, teaching the freebsd plugins about GNU > coreutils df and adding sysfs to ignored filesystem types. Looking more closely: The FreeBSD df already supports GNU coreutils df on kFreeBSD. The FreeBSD df_abs does not exist. The FreeBSD df_inode does not support GNU coreutils df. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#767102: munin-plugins-core: df* plugins report warnings for special filesystems on kFreeBSD
On Wed, 2014-10-29 at 07:33 +0800, Paul Wise wrote: > Looking more closely: On Debian wheezy kFreeBSD /sys appears to be sysfs not linsysfs. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#767102: munin-plugins-core: df* plugins report warnings for special filesystems on kFreeBSD
On Wed, 2014-10-29 at 11:31 +, Steven Chamberlain wrote: > And I guess because /proc/mounts is trying to emulate Linux, it pretends > that /sys is sysfs - I guess some applications expect that: > http://svnweb.freebsd.org/base/releng/10.1/sys/compat/linprocfs/linprocfs.c?view=annotate&sortby=file#l365 That looks like the culprit yeah. I found this out because df -x linsysfs still has /sys and so does df -x /sys, only df -x sysfs works. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Guide to getting ported?
Hi all, Do any porters have any input on this page? https://wiki.debian.org/GettingPorted -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: kernel on buildd (Re: [Glibc-bsd-commits] r5714 - trunk/glibc-ports/kfreebsd/bits)
On Thu, 2015-05-28 at 10:07 +0200, Christoph Egger wrote: > > Petr Salinger writes: > >> what is currently used kernel on buildd for kfreebsd-* ? uname -a: GNU/kFreeBSD falla 10.1-0-amd64 #0 Tue, 07 Apr 2015 22:13:19 +0100 x86_64 amd64 QEMU Virtual CPU version 2.1.2 GNU/kFreeBSD GNU/kFreeBSD fils 9.0-2-686 #0 Sun May 17 22:06:56 UTC 2015 i386 i386 QEMU Virtual CPU version 2.1.2 GNU/kFreeBSD GNU/kFreeBSD finzi 9.0-2-686 #0 Sun May 17 22:06:56 UTC 2015 i386 i386 QEMU Virtual CPU version 2.1.2 GNU/kFreeBSD GNU/kFreeBSD asdfasdf 9.0-2-amd64 #0 Fri Nov 7 13:40:32 UTC 2014 x86_64 amd64 AMD Sempron(tm) Processor 3000+ GNU/kFreeBSD GNU/kFreeBSD fano 9.0-2-amd64 #0 Sun May 17 20:12:58 UTC 2015 x86_64 amd64 QEMU Virtual CPU version 2.1.2 GNU/kFreeBSD GNU/kFreeBSD fischer 9.0-2-686 #0 Sun May 17 22:06:56 UTC 2015 i386 i386 QEMU Virtual CPU version 2.1.2 GNU/kFreeBSD GNU/kFreeBSD fayrfax 9.0-2-amd64 #0 Sun May 17 20:12:58 UTC 2015 x86_64 amd64 QEMU Virtual CPU version 2.1.2 GNU/kFreeBSD io.debian.net appears to be down. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
On Sun, 2015-05-31 at 12:45 +0100, Steven Chamberlain wrote: > I'll keep this test system busy with package builds and other tasks, but > could use more hints on what might trigger the issue seen with > falla.debian.org. (And exactly what issue was seen there, a crash? > with or without automatic reboot?). I'm not entirely sure what causes it, but the results are that falla sort of freezes. I can ping falla but ssh just returns this: Connection closed by 128.31.0.65 The VM console looks like this afterwards: https://people.debian.org/~pabs/tmp/falla.png -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
On Mon, 2015-06-01 at 17:08 +0200, Christoph Egger wrote: > This actually sounds a lot like what I just had on my VM! It also has > stuff along the following lines in /var/log/kern.log: > > | May 31 04:41:06 localhost kernel: maxproc limit exceeded by uid 101 (pid > 1685); see tuning(7) and login.conf(5) ... > Does falla have something similar? After a forced reboot it got stuck in emergency mode due to fs errors. I did the fsck -y needed and it fixed a bunch of things. It booted up but / was mounted read-only so I logged in over ssh and rebooted. Then it got stuck somewhere in kernel USB stuff on bootup so I force-rebooted again and it came up fine this time, with a read-write / Nothing in kern.log as I don't think it could write to the disk (if=ide) when it was having issues before. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#787136: kfreebsd-10: crashes seen on KVM-based buildds
On Sun, 14 Jun 2015 15:07:01 +0100 Steven Chamberlain wrote: > I think we should rather be using if=virtio now anyway. Could we try > to switch falla to that, and hopefully the issue might go away? Switched to that: gnt-instance shutdown falla.debian.org gnt-instance modify -d -H disk_type=paravirtual falla.debian.org gnt-instance shutdown falla.debian.org > I suggest we may rather want to use diskids in /etc/fstab Could you outline how that works on kFreeBSD? Should we make that the default in stretch and or jessie? > And while here, I recommend enabling soft updates journalling It asked me to run fsck but doing that didn't help. fsck -y /dev/vtbd1s1 tunefs.ufs -j enable /dev/vtbd1s1 tunefs.ufs: soft updates journaling cannot be enabled until fsck is run tunefs.ufs: /dev/vtbd1s1: failed to write superblock > And set up as much logging as possible to the serial console (boot > with kernel flags -D -h, /etc/grub.d/10_kfreebsd), in case Ganeti can > keep logs of that, as it should help for issues like this. -D was in there already, added -h, now this command works: gnt-instance console falla.debian.org Should we make that the default in stretch and jessie? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Time to change the debian-ports "list"?
On Thu, Jul 23, 2015 at 1:21 AM, John Paul Adrian Glaubitz wrote: > I'm in favor of the old design because I think it's important to havw a list > which can be used to make announcements about important issues that all > porters should be aware of. We have debian-devel-announce for that, the existing spray list could be renamed -ports-announce if it is actually needed. > It's not really that mails going to debian-ports@ appear that often. Unfortunately, when they do, they are more often not appropriate to be posted there. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6FyRWPGP119cuFsXcjnesD=txyo+yxv22cw-1bqz9+...@mail.gmail.com
Re: [Stretch] Status for architecture qualification
On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote: > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. Marist already support Debian with an s390x buildd: ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org "(sponsor=*marist*)" https://db.debian.org/machines.cgi?host=zani Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de: ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org "(architecture=s390*)" sponsor -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Debian Buster release to partially drop non-systemd support
On Tue, Oct 16, 2018 at 12:18 AM Adam Borowski wrote: > The main problem with sysvinit is the lack of a git repository. There is an upstream git repository with commits up to September 2018: http://savannah.nongnu.org/projects/sysvinit http://git.savannah.nongnu.org/cgit/sysvinit.git -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian Buster release to partially drop non-systemd support
On Fri, Oct 19, 2018 at 7:30 PM Martin Steigerwald wrote: > As long as people choose to strip of dependencies to libsystemd from > packages like util-linux, avoiding a fork would not work with how Debian > and Debian based distributions are built. It might be feasible to introduce nosystemd build profiles to Debian source packages and then create a shed/bikeshed/PPA (once that infrastructure exists) that contains rebuilds using that build profile. That would allow Devuan's libsystemd stripping to be completely merged into Debian source packages and infrastructure. I guess Devuan have other changes that might be easier or harder to merge too though. https://wiki.debian.org/BuildProfileSpec -- bye, pabs https://wiki.debian.org/PaulWise
Bug#992746: plocate: FTBFS on Hurd/kFreeBSD: dependency "systemd" not found
Source: plocate Version: 1.1.9-2 Severity: important Tags: ftbfs User: debian-h...@lists.debian.org Usertags: hurd hurd-i386 User: debian-bsd@lists.debian.org Usertags: kfreebsd-i386 kfreebsd-amd64 X-Debbugs-CC: debian-h...@lists.debian.org, debian-bsd@lists.debian.org plocate FTBFS on Hurd/kFreeBSD due to depending on systemd's pkg-config file, which is only available on Linux platforms. Since mlocate has been removed from Debian, this leaves those platforms with only findutils locate, which is a lot slower than even mlocate was. https://buildd.debian.org/status/package.php?p=plocate It looks like plocate only uses the systemd pkg-config file to install systemd unit files and already supports building without systemd via the install_systemd option. So meson.build should detect a host arch kernel other than Linux and auto-disable install_systemd. Probably meson.build should also not fail when systemd is not present, this will make it more portable to distros that do not have systemd at all like Alpine, OpenWRT, Void Linux etc. I note that some of these distros are having to manually disable systemd instead of having that autodetected. Some of these distros are also adding portability patches for musl. https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd https://repology.org/project/plocate/packages https://raw.githubusercontent.com/void-linux/void-packages/master/srcpkgs/plocate/template -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Future of GNU/kFreeBSD in the debian-ports archive
On Mon, 2023-05-29 at 18:11 +0200, Aurelien Jarno wrote: > I would like to emphasize that packages will still be available on > snapshot.d.o for anyone interested in reviving the port. And the new port docs mention the potential procedures involved: https://wiki.debian.org/PortsDocs/New -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, 2023-06-20 at 22:46 +0200, Kurt Roeckx wrote: > Can I suggest that if you file a few bugs and add some information in > it so that maybe someone can look at it? If it only affects one > architecture, send a mail to that list asking for help. PS: when filing architecture-specific bugs, please also set the BTS usertags and XCC the ports lists for the architectures effected. https://wiki.debian.org/Teams/Debbugs/ArchitectureTags -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
