Andreas Henriksson | 2 Aug 08:47 2014

Preparing (lib)gnome-keyring for the freeze.


I wanted to discuss the (lib)gnome-keyring status and the state we
want it to be in before the freeze.

To sum up the current problem, the versions in unstable are RC-buggy
because of FTBFS. The FTBFS is caused by a newly introduced testsuite
which basically showed the package never worked on kFreeBSD.

There has been discussions about the use of mlock(all) and we have
over the past year not been able to reach a consensus. I don't
feel comfortable making the descision to rip out security features
on my own as proposed by porters and noone has been willing to take
the discussion upstream.

I don't think releasing with really old 3.4 versions is a good idea.

I seen two solutions, either ...

a/ accept that the software has never really worked on kfreebsd and remove
   the kfreebsd-any builds from testing.

b/ get back to the status quo by disabling the problematic tests on kfreebsd
   letting the package build and work equally as before.

My opinion is that because of how I interpret the part about hiding problems
in the social contract, (a) is preferrable.

If for some reason (a) is not possible, please tell me and I'll implement
(Continue reading)

Debian Bug Tracking System | 1 Aug 22:15 2014

Processed: block 756790 with 756553

Processing commands for control <at>

> block 756790 with 756553
Bug #756790 [src:tcpdump] tcpdump: FTBFS on kfreebsd-*
756790 was not blocked by any bugs.
756790 was not blocking any bugs.
Added blocking bug(s) of 756790: 756553
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian Bug Tracking System
Contact owner <at> with problems

juan luis flores reátegui | 31 Jul 18:58 2014


muy buenos días,  soy nuevo en el tema de sofware libre, actualemnte  trabajo para una institución del estado y me veo en la  necesidad  de  usar La Distribución Debian,  en dicha institución hay muchos problemas con respecto a la administración de su Red, tales como: duplicado de ip, caida de la linea de intener, lentitud de la liena de Internet, es por  eso que tengo planeado implemnatr: vpn, dhcp, subneteo,  para una mejor  administracion de mismo, Gracias por dedicarce a leer mi mensaje. 

Administrador de Servicios Generales JuanManuel S.A.C
Bach.  Juan Luis Flores Reátegui
telefono : 065351325
celular   : 951423320
rpm        :#951423320
Calle Angamos #314- Yurimaguas- Altoamazonas- loreto.

Romain Francoise | 30 Jul 22:23 2014

Bug#756553: kfreebsd-kernel-headers missing /usr/include/net/if_pflog.h

Package: kfreebsd-kernel-headers
Version: 10.0~5
Severity: serious

tcpdump fails to build on kfreebsd since kfreebsd-kernel-headers was
updated to the FreeBSD 10 headers in unstable, the package is missing
the /usr/include/net/if_pflog.h file. It was present in version 0.83.

I'm setting severity serious since this bug makes my package FTBFS in

See the following build logs:


Romain Francoise <rfrancoise <at>>

Henrique de Moraes Holschuh | 30 Jul 18:27 2014

processor microcode update support for Debian GNU/kFreeBSD

(please CC me, I am not subscribed to debian-bsd <at> l.d.o).

Hello kfreebsd-i386/kfreebsd-amd64 porters,

I am the maintainer of intel-microcode and amd64-microcode (non-free), as
well as the maintainer and upstream of iucode-tool (contrib).   Currently,
these three packages are restricted to linux-i386 and linux-amd64.

Given that we've seen several critical microcode fixes in the Intel side
lately, and that AMD's microcode updates also address some relevant errata,
I would like to ensure that Debian kFreeBSD users can receive processor
microcode updates.

How are microcode updates currently being handled in the Debian/kFreeBSD
ports?  Do you need any changes in the intel-microcode and/or
amd64-microcode packages?


  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bill Allombert | 30 Jul 11:14 2014

[dan-greene <at> Bug#756464: upgrade-reports: [kfreebsd] dist-upgrade to jessie removes the kernel]

Dear Debian  BSD maintainers,

We received the following report.

----- Forwarded message from Dan Greene <dan-greene <at>> -----

Date: Tue, 29 Jul 2014 23:28:57 -0500
From: Dan Greene <dan-greene <at>>
To: Debian Bug Tracking System <submit <at>>
Subject: Bug#756464: upgrade-reports: [kfreebsd] dist-upgrade to jessie removes the kernel
X-Mailer: reportbug 6.5.0

Package: upgrade-reports
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

When dist-upgrading a system to jessie, or running dist-upgrade on a freshly
installed system (using the alpha 1 release of the installer), apt-get
removes the kernel. This results in there being no kernel installed, and
you can't exactly boot the system without a kernel, hence the severity.

Using aptitude reveals that freebsd-net-tools Breaks: kfreebsd-image-9

To reproduce:
Install Debian GNU/kFreeBSD jessie from tha alpha 1 netinstall cd.
Run apt-get dist-upgrade

and you will be stuck with a grub prompt.

In case it matters, this bug was found running under a virtual machine (KVM).

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 9.2-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

----- End forwarded message -----


Bill. <ballombe <at>>

Imagine a large red swirl here. 

Debian testing watch | 27 Jul 18:39 2014

partman-zfs 35 MIGRATED to testing

FYI: The status of the partman-zfs source package
in Debian's testing distribution has changed.

  Previous version: 34
  Current version:  35


This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See for more information.

Debian Bug Tracking System | 27 Jul 05:45 2014

Processed: unblock 734328 with 751285

Processing commands for control <at>

> unblock 734328 with 751285
Bug #734328 [kfreebsd-kernel-headers] kfreebsd-kernel-headers: Don't ship <sys/sdt.h> here
734328 was blocked by: 751285
734328 was blocking: 726248
Removed blocking bug(s) of 734328: 751285
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian Bug Tracking System
Contact owner <at> with problems

Steven Chamberlain | 26 Jul 20:02 2014

Please update gcc-4.9 on buildds


GCC PR 61801 describes a compiler bug with wrong code being generated
for kernel mode or syscalls:

I don't know if it has caused any issues yet on kfreebsd - our kernels
are built with Clang - but this might potentially affect glibc builds.
The minimal testcase from the GCC PR can reproduce it on kfreebsd, and
seems to show that is is fixed in 4.9.1-2 in sid/jessie.

Please could the kfreebsd-* buildd chroots be updated to gcc-4.9 4.9.1-2
as a precaution?


Steven Chamberlain
steven <at>

Jan Henke | 23 Jul 13:34 2014

Bug#755739: (no subject)

I have been pointed to

As described in the other bug report, adding this line to the GRUB
config indeed fixed the problem for me:

set kFreeBSD.hw.vga.textmode=1

So I can confirm the cause seems to be the newcons you mentioned. I
would appreciate if the boot loader would provide a standard entry with
this setting. Without kFreeBSD is completely unusable for me right now.

Best regards

Jan Henke | 22 Jul 20:58 2014

Extremely slow text mode on Hyper-V

Hi folks,

I am experiencing a strange problem with the current kFreeBSD weekly
image. Whenever the system is writing to the screen in text mode (e.g.
directly after selecting one entry in GRUB: "Copyright....") you can
literally watch every single character printed to the screen one after
the other. So it takes ages before you even get into the Debian
installer. I am running inside a Hyper-V VM. I have double checked
against FreeBSD (the upstream one), which does not show this behaviour.

It did not occur in the past, I think it started after an upgrade of
several packages some month ago. I can only remember that the kernel was
also upgraded to version 10-5 (if I remember correctly).

I am wondering what I can do to isolate the problem and against which
packet I could file a bug report. Any debugging is sadly incredibly
painful, as the boot messages alone can take about an hour to roll
through. Does anybody have an idea?

Best Regards
Jan Henke