Re: Architecture qualification for GNU/kFreeBSD

[Cyril Brulebois]

Steven Chamberlain  (05/05/2012):
> I noticed on "the table" that no porter box is listed for kfreebsd-i386:
> http://release.debian.org/wheezy/arch_qualify.html
> 
> Is that because io.debian.net is/was not working?  Or is it?

FWIW from a previous IRC discussion, we have no DSA-admin'd porterboxes
but DSA is happy to do the setup. The release team (at least its members
who voiced an opinion at the time) seemed happy with the current state
of affairs (i.e. half a porterbox) for the time being, since it's going
to be fixed soonish.

> Apart from that, the biggest outstanding issue might be to get daily d-i
> images built again?

Speaking of which, I just sent:
  https://lists.debian.org/debian-boot/2012/05/msg00045.html

Mraw,
KiBi.


signature.asc
Description: Digital signature

Anyone had any luck with the X input synaptics driver?

[Cyril Brulebois]

Hi,

if you're a synaptics user, please report back to us (debian-x@). With
the recent switch to X server 1.12, synaptics detects that XI2.2 is
available, and enables multitouch supports. That explains why
libmtdev-dev was added as a build dependency, and why it's in
BD-Uninstallable right now for kfreebsd-*:
  
https://buildd.debian.org/status/package.php?p=xserver-xorg-input-synaptics&suite=sid

I guess we could try to make that detection a bit cleverer, but another
option could be to remove synaptics from kfreebsd-* entirely. That's why
I'm asking: if somebody got it to work, we might try and keep that
alive. Otherwise, getting rid of the old binaries would make it possible
for everyone to migrate to testing soon.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#671884: kfreebsd "panic: page fault" on installer image

[Cyril Brulebois]

Hi Steven,

Steven Chamberlain  (13/05/2012):
> Hi Miguel,
> 
> Which kernel did you choose?  Do both kfreebsd-8 and kfreebsd-9 have
> this problem?
> 
> And which version of VirtualBox was this?  I believe a bug in vbox 3.2
> leads to regular panics of kfreebsd-9.  vbox 4.x or kfreebsd-8 are okay.
> 
> 
> Also please note, the d-i images from 20120405 did not work when I tried
> them (missing libraries;  unable to detect/manage disk partitions as a
> result).  The 20120404 images should be better choice.  At least until
> new daily images are being built again.

thanks for the details on the Release Announce page. I've removed this
issue from there since it looks like gone for me too with alpha1.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: kfreebsd-i386 qualification for Wheezy

[Cyril Brulebois]

Robert Millan  (16/05/2012):
> Does asdfasdf have i386 chroots?  If not, is it feasible to add them?
> Would then asdfasdf qualify as porter box for kfreebsd-i386?

AFAICT: no, yes, no.

DSA said they were willing to set up porterboxes “in time” though, so
I wouldn't worry too much about it if I were you.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#673530: libcommoncpp2: FTBFS on kfreebsd-*: sys/kern/types.h:87:17: error: expected unqualified-id before 'char'

[Cyril Brulebois]

Source: libcommoncpp2
Version: 1.8.1-3
Severity: serious
Justification: FTBFS
User: debian-bsd@lists.debian.org
Usertags: kfreebsd

Hi,

that might just be some “fun” with the kfreebsd headers, but your
package FTBFS in sid (1.8.1-3) on kfreebsd-* while I was building fine
in experimental (1.8.1-1):
| libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I../inc -I../src 
-DCCXX_EXPORT_LIBRARY -D_GNU_SOURCE -I../inc -g -O2 -c file.cpp  -fPIC -DPIC -o 
.libs/file.o
| In file included from /usr/include/sys/kern/param.h:67:0,
|  from /usr/include/osreldate.h:1,
|  from /usr/include/x86_64-kfreebsd-gnu/sys/param.h:39,
|  from file.cpp:75:
| /usr/include/sys/kern/types.h:87:17: error: expected unqualified-id before 
'char'
| /usr/include/sys/kern/types.h:87:17: error: expected initializer before 'char'
| make[3]: *** [file.lo] Error 1

Full build logs:
  https://buildd.debian.org/status/package.php?p=libcommoncpp2&suite=sid

I'm putting debian-bsd@ in X-Debbugs-Cc so that they can look at it
ASAP. Indeed, that FTBFS is blocking the libcommoncpp2 transition:
  http://release.debian.org/transitions/html/libcommoncpp2.html

Mraw,
KiBi.



-- 
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/20120519122805.29116.64895.report...@kashyyyk.rennes.ariadnext.com

Anyone got ruby-1.8 to build on kfreebsd-amd64?

[Cyril Brulebois]

Hi,

lately, ruby-1.8 failed twice on fasch, twice on fano, delaying the
ruby-gnome2 transition. I'd be happy if somebody could look into it and
see whether there's something wrong on the buildd side, or whether a
porter binary upload could happen. It should help get more packages
installable on s390x in testing at least.

  
https://buildd.debian.org/status/logs.php?arch=kfreebsd-amd64&pkg=ruby1.8&ver=1.8.7.358-2

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#673165: mapserver: FTBFS with multiarch-ready libgd2

[Cyril Brulebois]

tag 673165 patch pending
thanks

Steven Chamberlain  (18/05/2012):
> This FTBFS (actually on all arches now?) because libgd2 since
> 2.0.36~rc1~dfsg-6.1 uses a multiarch path, where it is not seen by
> these checks in configure.in: […]

That's correct, all archs are affected now.

> The path can't be specified from debian/rules via --with-gd because
> the includes and libraries must all be there.  So the configure.in
> must be modified in some way to look for the static+shared libs in the
> appropriate (multiarch) path...

… or to stop trying to do that entirely.

I've just uploaded a fixed package with the attached source debdiff.
Maintainers, that's a very short notice, but we haven't heard from you
on the bug log, and we badly need fixed packages for gdal. Thanks for
your understanding.

Mraw,
KiBi.
diff -Nru mapserver-6.0.1/debian/changelog mapserver-6.0.1/debian/changelog
--- mapserver-6.0.1/debian/changelog	2012-03-05 16:09:41.0 +0100
+++ mapserver-6.0.1/debian/changelog	2012-05-22 01:31:07.0 +0200
@@ -1,3 +1,12 @@
+mapserver (6.0.1-3.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix FTBFS with multiarch libgd by just using -lgd instead of trying to
+locate libgd.{a,so}, new patch: multiarch-libgd (Closes: #673165).
+  * Set urgency to “high” for the RC bug fix, needed for the gdal transition.
+
+ -- Cyril Brulebois   Tue, 22 May 2012 01:28:15 +0200
+
 mapserver (6.0.1-3) unstable; urgency=low
 
   * Let the configure script search in the system directory for jpeg stuff.
diff -Nru mapserver-6.0.1/debian/patches/multiarch-libgd mapserver-6.0.1/debian/patches/multiarch-libgd
--- mapserver-6.0.1/debian/patches/multiarch-libgd	1970-01-01 01:00:00.0 +0100
+++ mapserver-6.0.1/debian/patches/multiarch-libgd	2012-05-22 01:31:07.0 +0200
@@ -0,0 +1,71 @@
+Description: Fix FTBFS with multiarch libgd.
+ The linker knows where to find libgd when one uses -lgd, so stop
+ worrying where libgd.{a,so} are.
+Bug: http://bugs.debian.org/673165
+Author: Cyril Brulebois 
+--- a/configure
 b/configure
+@@ -7649,17 +7649,7 @@ elif test -n "$with_gd" -a "$with_gd" !=
+   test -f $GD_DIR/include/gd/gd.h && GD_INCLUDE="$GD_DIR/include/gd"
+   test -f $GD_DIR/gd.h && GD_INCLUDE="$GD_DIR"
+ 
+-  test -f $GD_DIR/lib/libgd.a && GD_LIBDIR="$GD_DIR/lib"
+-  test -f $GD_DIR/lib64/libgd.a && GD_LIBDIR="$GD_DIR/lib64"
+-  test -f $GD_DIR/.libs/libgd.a && GD_LIBDIR="$GD_DIR/.libs"
+-  test -f $GD_DIR/_libs/libgd.a && GD_LIBDIR="$GD_DIR/_libs"
+-  test -f $GD_DIR/libgd.a && GD_LIBDIR="$GD_DIR"
+-
+-  test -f $GD_DIR/lib/libgd.so -o -f $GD_DIR/lib/libgd.sl -o -f $GD_DIR/lib/libgd.dylib && GD_LIBDIR="$GD_DIR/lib"
+-  test -f $GD_DIR/lib64/libgd.so -o -f $GD_DIR/lib/libgd.sl && GD_LIBDIR="$GD_DIR/lib64"
+-  test -f $GD_DIR/.libs/libgd.so -o -f $GD_DIR/.libs/libgd.sl -o -f $GD_DIR/.libs/libgd.dylib && GD_LIBDIR="$GD_DIR/.libs"
+-  test -f $GD_DIR/_libs/libgd.so -o -f $GD_DIR/_libs/libgd.sl -o -f $GD_DIR/_libs/libgd.dylib && GD_LIBDIR="$GD_DIR/_libs"
+-  test -f $GD_DIR/libgd.so -o -f $GD_DIR/libgd.sl -o -f $GD_DIR/libgd.dylib && GD_LIBDIR="$GD_DIR"
++  # Let the linker do its job, we really don't need to pass -L$GD_LIBDIR
+ 
+ echo "$as_me:$LINENO: checking for gdImageCreatePaletteFromTrueColor in -lgd" >&5
+ echo $ECHO_N "checking for gdImageCreatePaletteFromTrueColor in -lgd... $ECHO_C" >&6
+@@ -7805,9 +7795,9 @@ fi
+ GD_NEED_ICONV_LIB="$ICONV_LIB"
+   fi
+ 
+-  if test -n "$GD_INCLUDE" -a -n "$GD_LIBDIR" -a "$IS_GD2" = "true"; then
++  if test -n "$GD_INCLUDE" -a "$IS_GD2" = "true"; then
+   GD_INC=-I$GD_INCLUDE
+-  GD_LIB="-L$GD_LIBDIR -lgd"
++  GD_LIB="-lgd"
+   GD_XTRA_LIBS="$GD_XTRA_LIBS $GD_NEED_ICONV_LIB"
+   echo "$as_me:$LINENO: result: using libgd 2.0.28 (or higher) from $GD_LIB $GD_XTRA_LIBS" >&5
+ echo "${ECHO_T}using libgd 2.0.28 (or higher) from $GD_LIB $GD_XTRA_LIBS" >&6
+--- a/configure.in
 b/configure.in
+@@ -636,17 +636,7 @@ elif test -n "$with_gd" -a "$with_gd" !=
+   test -f $GD_DIR/include/gd/gd.h && GD_INCLUDE="$GD_DIR/include/gd"
+   test -f $GD_DIR/gd.h && GD_INCLUDE="$GD_DIR"
+ 
+-  test -f $GD_DIR/lib/libgd.a && GD_LIBDIR="$GD_DIR/lib"
+-  test -f $GD_DIR/lib64/libgd.a && GD_LIBDIR="$GD_DIR/lib64"
+-  test -f $GD_DIR/.libs/libgd.a && GD_LIBDIR="$GD_DIR/.libs"
+-  test -f $GD_DIR/_libs/libgd.a && GD_LIBDIR="$GD_DIR/_libs&qu

Bug#674803: freebsd-libs: FTBFS on linux: sys/_types.h: No such file or directory

[Cyril Brulebois]

Source: freebsd-libs
Version: 9.0+ds1-3
Severity: serious
Justification: FTBFS

Hi,

on all linux archs it was tried on, freebsd-libs failed with:
| […]
| In file included from /usr/include/i386-linux-gnu/sys/param.h:53:0,
|  from /usr/include/freebsd/sys/param.h:1,
|  from 
/build/buildd-freebsd-libs_9.0+ds1-3-i386-CFFhOp/freebsd-libs-9.0+ds1/debian/local/include/sys/param.h:3,
|  from 
/build/buildd-freebsd-libs_9.0+ds1-3-i386-CFFhOp/freebsd-libs-9.0+ds1/lib/libsbuf/../../sys/kern/subr_sbuf.c:32:
| /usr/include/freebsd/sys/types.h:14:26: fatal error: sys/_types.h: No such 
file or directory

Full build logs:
  https://buildd.debian.org/status/package.php?p=freebsd-libs&suite=sid

Mraw,
KiBi.



-- 
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/20120527202743.16870.26925.report...@kashyyyk.rennes.ariadnext.com

Re: Bug#671064: nmap: FTBFS[kfreebsd]: error: 'CLOCK_MONOTONIC' undeclared

[Cyril Brulebois]

Hello Hilko,

you NMU'd nmap to introduce a new upstream version. It generated an
FTBFS on kfreebsd-*, which has been unanswered for a whole month. Can
you please fix the RC bugginess you introduced? That should be
especially easy since GNU/kFreeBSD porters already supplied a patch?


Steven Chamberlain  (01/05/2012):
> tags 671064 + patch
> thanks

Thanks Steven for the patch.

> On 01/05/12 17:23, Christoph Egger wrote:
> > gcc -O2 -Wall -D_GNU_SOURCE -O2 -O2 -Wall -D_GNU_SOURCE -I.  
> > -DHAVE_CONFIG_H  -D_U_="__attribute__((unused))" -c ./pcap-bpf.c
> > ./pcap-bpf.c: In function 'pcap_next_zbuf':
> > ./pcap-bpf.c:334:3: warning: implicit declaration of function 
> > 'clock_gettime' [-Wimplicit-function-declaration]
> > ./pcap-bpf.c:334:24: error: 'CLOCK_MONOTONIC' undeclared (first use in this 
> > function)
> > ./pcap-bpf.c:334:24: note: each undeclared identifier is reported only once 
> > for each function it appears in
> > make[2]: *** [pcap-bpf.o] Error 1

Thanks Christoph for the report.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#674803: freebsd-libs: FTBFS on linux: sys/_types.h: No such file or directory

[Cyril Brulebois]

Robert Millan  (28/05/2012):
> This was actually a bug in freebsd-glue (bug reassigned, and fixed in
> 0.0.3).
> 
> Please could you schedule a rebuild of freebsd-libs?

1. That's not a rebuild, that's a give back (or retry). “rebuild”
   implies it built successfully and it's about binNMUs, which it is not.

2. #674806 means it's going to be stuck in BD-Uninstallable state, which
   is already the case on all archs where it's not Build-attempted.

Given back where it failed.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#671064: nmap: FTBFS[kfreebsd]: error: 'CLOCK_MONOTONIC' undeclared

[Cyril Brulebois]

reopen   671064
notfixed 671064 5.51.6-0.2
thanks

Hilko Bengen  (28/05/2012):
> Two days ago, I actually NMU'd a 5.51.6-0.2 that hopefully fixes the
> problem. It will hit unstable in 3 days.

Unfortunately, it doesn't:
| g++   -o nping ArgParser.o NetworkLayerElement.o PacketElement.o common.o 
common_modified.o nping.o RawData.o UDPHeader.o  NpingOps.o TCPHeader.o utils.o 
utils_net.o IPv4Header.o ICMPv4Header.o IPv6Header.o output.o 
TransportLayerElement.o stats.o NpingTargets.o NpingTarget.o EthernetHeader.o 
ARPHeader.o EchoHeader.o EchoServer.o EchoClient.o ProbeMode.o NEPContext.o 
Crypto.o PacketDiff.o  ../nbase/libnbase.a ../nsock/src/libnsock.a 
../libnetutil/libnetutil.a -lssl -lcrypto ../libpcap/libpcap.a 
../libdnet-stripped/src/.libs/libdnet.a -ldl  -lpthread
| g++: error: ../libpcap/libpcap.a: No such file or directory

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#674942: ruby blocks buildd for a day (or more)

[Cyril Brulebois]

Steven Chamberlain  (03/06/2012):
> In past build logs it has always been the ERB tests that hang on the
> kfreebsd-* buildds, and the same has happened again with the latest
> upload.
> 
> But I wouldn't worry about it;  I think it might be fixed by the next
> eglibc upload (I can't reproduce the hangs in those tests any more)
> and so only a give back to kfreebsd-* buildds would be needed then.

Some do. See dependency graph for testing migration, attached.

(sudo apt-get install graphviz && dot -Tpng 1.png 1.dot)

eglibc upload, eglibc build, chroot upgrades, give backs is going to
take time, even if the eglibc upload happens “soon”.

Mraw,
KiBi.


1.dot
Description: MS-Word document


signature.asc
Description: Digital signature

Re: Bug#673167: ecore: FTBFS[kfreebsd] testsuite failure

[Cyril Brulebois]

Version: 1.2.0-2

Christoph Egger  (16/05/2012):
> Package: src:ecore
> Version: 1.2.0-1
> Severity: serious
> Tags: sid wheezy
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd
> X-Debbugs-Cc: debian-bsd@lists.debian.org
> Justification: fails to build from source (but built successfully in the past)

Fixed with a typo in the changelog (see below). I'm Cc-ing the other bug
(that got closed) for information, letting Albin or the chromium
maintainers do the actual work. ;p

That should help get ecore and friends into testing (graphviz dependency
graph attached).

Extract from :
| Closes: 673176
| Changes: 
|  ecore (1.2.0-2) unstable; urgency=low
|  .
|* Use the new '-indep' targets of dh and update Build-Deps
|* accordingly
|* Move to dh compat level 9
|* debian/control: bump Standards-Version to 3.9.3
|* Disable the testsuite for now, it has too many issues (Closes:
|* #673176)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#673167: ecore: FTBFS[kfreebsd] testsuite failure

[Cyril Brulebois]

Cyril Brulebois  (05/06/2012):
> That should help get ecore and friends into testing (graphviz dependency
> graph attached).

For real now.

Mraw,
KiBi.


15.dot
Description: MS-Word document


signature.asc
Description: Digital signature

Preparation for d-i beta 1

[Cyril Brulebois]

Hi folks,

as you may know, nobody else stepped up, so I'm volunteering again to
try and get a new debian-installer release out, codenamed « beta 1 ».

I have looked at the packages mentioned on the udeb testing summary
page[1] and I have “urgented” many of them, so that they reach testing
sooner than the required 10 days. My hints file[2] list those, which I
tried to keep under two categories: l10n-only, and other changes
(code/packaging), so that one can easily determine guilty packages if
regressions are found.

 1. http://d-i.debian.org/testing-summary.html
 2. http://release.debian.org/britney/hints/kibi

After tonight's britney run (22:00 UTC), the remaining packages should
be:
 - those who are RC-buggy (e.g. libusb);
 - those with missing builds; mostly because they were uploaded lately,
   and they are not built everywhere yet (e.g. recent l10n updates);
 - a special case for that last category: the linux kernel, with its
   bumped ABI.

Questions:
 A. if we build a debian-installer package against the old linux kernel
ABI, and then images with that debian-installer, will the installer
be able to install a kernel with the old ABI to begin with, *and* a
kernel with the new ABI in a few days when it reaches testing? Or
will the images be broken when that happens? (added debian-kernel to
Cc accordingly).

 B. I'm pondering asking the release team to put back into place the
“block-udeb” hints, so that one can make sure candidates for testing
are only allowed into testing after review. The wheezy freeze is
going to start with a freeze exception for what's in unstable at
this point, so it looks like retaining some bits of control would be
nice. Any drawback?

 C. debian-live: do you need to be in the loop for debian-installer
alpha/beta/rc releases?

If the answer to (A) is OK with old/new kernel, I think I'll prepare a
debian-installer package in the upcoming hours (or days, depending on
the remaining migrations), and perform some tests, then probably ask
debian-cd to prepare some prospective images.

If there's any volunteer which would be kind enough to start building a
wiki page with the changes between alpha 1 and beta 1, that would be
super nice. I'm not sure whether we have nice tools for this, I guess
we would need to find changes involving the initramfs, but also major
changes outside. Pointers welcome.

If you have any comment on the process, any pending changes (you would
like to have in beta 1) left, I'm all ears, but the clock's ticking.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: which list to ask users question about debian kfreebsd

[Cyril Brulebois]

Cru Summers  (08/07/2012):
> I am bit confused which mailing list to ask user questions about
> Debian kfreebsd.

This list works fine for both developer and user stuff.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: xserver-xorg-video-nv driver for GNU/kFreeBSD

[Cyril Brulebois]

Please mail debian-x@ directly next time.

Petr Salinger  (13/07/2012):
> xserver-xorg-video-nv driver have been removed from unstable. It is
> replaced by xserver-xorg-video-nouveau driver, but only under Linux,
> as it requires KMS.
> 
> I dist-upgraded to wheezy today. My graphics card works with vesa
> driver, but only with 4:3 aspect, which is really bad for 16:9 LCD
> :-(.
> 
> I have been able to mix
> git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-nv
> git clone git://git.debian.org/pkg-xorg/attic/driver/xserver-xorg-video-nv.git
> and build some working version.
> 
> Would be possible to restore building of video-nv driver under
> GNU/kFreeBSD only ?

I won't do that.

> Would be possible to get it into wheezy ?

I don't think so.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#681506: xserver-xorg-input-mouse: crash on kfreebsd-*

[Cyril Brulebois]

Steven Chamberlain  (13/07/2012):
> Yep!  Fixes the crash I was seeing, and the pointer is functional again
> now on kfreebsd-amd64.  Thanks a lot.

It'd be great if somebody could check the status of the gcc bug
(reported against gcc-4.6: http://bugs.debian.org/668949).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: xserver-xorg-video-nv driver for GNU/kFreeBSD

[Cyril Brulebois]

Robert Millan  (20/07/2012):
> 2012/7/17 Petr Salinger :
> > I cooked with today tagged release and made it available on
> >
> > http://asdfasdf.debian.net/~salinger/xserver-xorg-video-nv/
> 
> Should this be uploaded to sid?

Please make sure to reopen #383465 if you do that.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: d-i failing to build on fils

[Cyril Brulebois]

Hi all,

Aurelien Jarno  (31/08/2012):
> This was a configuration issue, /etc/apt/sources.list was using the
> ubece mirror while the correct mirrors where listed in
> /etc/apt/sources.list.d/*. It seems debian-installer is only looking
> up in the former file, not in the laters.

thanks for the fix/give-back.

If buildd maintainers feel they shouldn't have to have stuff in
sources.list, I guess d-i could be made to look into more files under
sources.list.d; in which case, please file a bug report.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Descriptive changelogs (Bug#683739: unblock: kfreebsd-9/9.0-5)

[Cyril Brulebois]

Robert Millan  (03/08/2012):
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package kfreebsd-9
> 
> It fixes a Policy violation (#672255) and a bug in linprocfs (#682291 / 
> #681594)
> which is holding off fix for an RC bug in another package (haxe FTBFS,
> see #621890).
> 
> An ABI bump was triggered by the second fix.

It would have been nice to include that line in the changelog itself.

Having to resort to debsnap/snapshot.debian.org to check when the ABI
bump happened isn't exactly nice. (9.0-4 was the version in beta1, and
the changelog didn't look like the ABI was bumped.)

> kfreebsd-9 (9.0-5) unstable; urgency=low
> 
>* Remove /boot symlink kludge.  (Closes: #672255)
>* fix_VOP_VPTOCNP_bypass_for_nullfs.diff: Fix /proc/self/exe in
>  nullfs. (Closes: #682291, #681594)
> 
>  -- Robert Millan   Sat, 21 Jul 2012 16:07:17 +0200 
> 
> unblock kfreebsd-9/9.0-5

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Continuous Integration of the Debian Installer?

[Cyril Brulebois]

Dmitrijs Ledkovs  (13/10/2012):
> There is no gui testing: e.g. actually simulating clicks, tabs &
> enters. But it's in the works with general automated GUI testing.

I've started working on this, but preparing d-i wheezy beta 3 took the
lead in the “eating KiBi time” category.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#686861: debian-installer: kfreebsd requires larger MFS_ROOT

[Cyril Brulebois]

Hi,

Steven Chamberlain  (16/10/2012):
> reopen 686861
> notfixed 686861 20120930
> found 686861 20120930
> severity 686861 wishlist
> thanks

next time, please open a new bug, and reference the old one in the new
one… what you asked for was implemented, and if you changed your mind,
that's another story, and another bug.

> I'm sorry to be a nuisance, but could the MFSROOT_LIMIT perhaps be
> lowered just slightly, to 80 MiB?
> 
> The increase above 64 MiB was necessary because the installer (only
> momentarily) seems to need a little more space for some processing
> of debconf templates during a GUI install.  The jump up to 128 MiB
> was a sure way to fix that, but now it seems a bit excessive.
> 
> If MFSROOT_LIMIT can be lowered to 80 MiB on kfreebsd-amd64, that
> should lower the minimum memory requirement to 128 MiB for text
> installs and 192 MiB for GUI installs.  That would surely then
> satisfy the smallest likely x86_64 systems or virtual machines.
> qemu-system-x86_64 has a default of 128 MiB RAM.
> 
> The install guide probably needs adjusting too; the figures quoted
> for squeeze don't sound realistic.  The available memory has to be
> at least the size of an uncompressed kernel image, plus the value
> set for MFSROOT_LIMIT, and still leave enough for the d-i userland.

Please come up with definitive numbers, for MFS_ROOT, lowmem, and the
installation guide. And we'll see what to do for beta 4 / rc 1.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Fwd: Bug#693510: installation report

[Cyril Brulebois]

Hello folks,

any insight for this kfreebsd installation report?

Mraw,
KiBi.
--- Begin Message ---
Package: installation-reports

Boot method: default text mode installer
Image version: 
http://hammurabi.acc.umu.se/cdimage/wheezy_di_beta3/kfreebsd-amd64/iso-cd/debian-wheezy-DI-b3-kfreebsd-amd64-xfce-CD-1.iso
Date: 17/11/2012 dd/mm/yyy

Machine: Virtual box amd 64
Processor:
Memory:
Partitions: Virtual box ide disk

Output of lspci -knn (or lspci -nn):

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O ]
Detect network card:[O ]
Configure network:  [ O]
Detect CD:  [O ]
Load installer modules: [O ]
Detect hard drives: [E ]

Could not get identity of device /dev/ada0 - Inappropriate ioctl for device

Partition hard drives:  [E ]

All default settings selected, such as guided, ufs ...

update-dev: warning: unable to find udevadm; skipping
partman: mkfs.ufs: /dev/ada0s1: failed to open disk for writing

Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cag3tgcozxpgot8mujbb0arf9hworrg2nehk1te7vs807hjq...@mail.gmail.com


--- End Message ---


signature.asc
Description: Digital signature

Re: Bug#677861: lftp: FTBFS[kfreebsd-i386]: error: conflicting declaration 'typedef __int32_t gl_intptr_t'

[Cyril Brulebois]

Hello,

Michael Stapelberg  (26/11/2012):
> Andreas Henriksson  writes:
> > Hopefully the explanation of this mail makes more sense.
> > Anyone with a kFreeBSD installation are welcome to try to build
> > lftp with any of the solutions discussed to see how much further
> > this gets us.
> This is slightly off-topic, but aren’t porter boxes supposed to help
> with that? I fail to see how I can use them (e.g. fischer.debian.org) in
> this very case: I don’t have root access, so I cannot install the
> build-deps of lftp. Do I really have to send a request and wait for some
> human to install the deps before I can do any work on this?

yes: http://dsa.debian.org/doc/install-req/

Installed in fischer's sid chroot.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#695500: debian-installer-7.0-netboot-kfreebsd-amd64: does not boot from pxe

[Cyril Brulebois]

Control: found -1 20120828

Michael Tsang  (09/12/2012):
> Package: debian-installer-7.0-netboot-kfreebsd-amd64
> Severity: important
> 
> Dear Maintainer,
> 
> I cannot boot the installer from pxe. GRUB says prefix is not set
> and dies. It seems to be a configuration bug.
> 
> Michael Tsang

Hi BSD folks,

from a quick look at the wheezy beta[1-4] release announces, I didn't
see any mention of “prefix” so I'm not sure it's fixed already. Any
insight?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#696901: chroot-setup.sh: [kfreebsd-*] procfs mounted instead of linprocfs in target

[Cyril Brulebois]

Control: tag -1 pending
Control: found -1 1.92

Steven Chamberlain  (29/12/2012):
> Package: debian-installer-utils
> Version: 1.94
> Severity: important
> Tags: d-i patch
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd
> X-Debbugs-Cc: debian-bsd@lists.debian.org
> 
> Hi,
> 
> I noticed that the wrong type of proc filesystem, procfs (meant for
> native FreeBSD) gets mounted in a kfreebsd-amd64 target during install.
> 
> The correct proc filesystem for GNU/kFreeBSD is linprocfs.  This
> contains among other things, /proc/cmdline (which is what
> chroot-setup.sh actually looks for to decide if proc needs mounting).
> 
> Later, when grub-installer runs, it would have tried to mount
> /target/proc correctly (as linprocfs) thanks to the fix for #613430, but
> only if that directory is empty, which procfs will not be.
> 
> As a result, the grub-common postinst complains about being unable to
> find /proc/mounts, with unknown consequences.  (grub-mkdevicemap and
> grub-probe still seem to work;  the GRUB install step fails currently
> for a different reason).
> 
> A patch fixing this is attached.  Thanks.

Thank you, applied in the wheezy branch; a tpu upload is awaiting
Christian's decision WRT cherry-picking l10n updates:
  http://lists.debian.org/20130102200430.gg24...@mraw.org

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#699704: partman: Please don't load_extra on non-Linux

[Cyril Brulebois]

Hi Steven,

Steven Chamberlain  (03/02/2013):
> On GNU/kFreeBSD, space on the d-i ramdisk (rootfs) is scarce because
> it cannot dynamically resize.  With certain preseeding options the
> installation of these packages can exhaust available space and
> break/abort the install process.

yeah, I know the rootfs size limitation is a bit of pain.

> GNU/Hurd doesn't have lvm2-udeb so can't use partman-lvm either.

Feel free to propose a tested (on kfreebsd-*) patch, to be considered
for inclusion between rc1 and rc2.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#699704: partman: Please don't load_extra on non-Linux

[Cyril Brulebois]

Steven Chamberlain  (04/02/2013):
> I've now tested the attached patch on kfreebsd-amd64, and it does fix
> the problem, which I could reproduce before only in these specific
> circumstances: […]
> 
> * only in the GTK installer (netboot-9/gtk or cdrom/gtk;  kfreebsd-i386
> doesn't have this)
> * >=256 MiB RAM (not lowmem mode)
> * language other than US English
> * a preseed.cfg that uses partman-auto
> 
> d-i built with either sid or wheezy udebs made no difference;  it always
> ran out of ramdisk space at the same point in partman.

Want me to commit your patch to git, and upload that?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#699704: partman: Please don't load_extra on non-Linux

[Cyril Brulebois]

Control: tag -1 pending

Steven Chamberlain  (05/03/2013):
> On 05/03/13 20:31, Cyril Brulebois wrote:
> > Want me to commit your patch to git, and upload that?
> 
> Yes, please!  I almost forgot about this...

No worries. Lagging behind, but trying to read all bug mail…

If the changelog message looks OK to you, I'll upload that later
tonight.

Mraw,
KiBi.
commit 24c76fe8cb7cc85475dd85825455624c147c3630
Author: Cyril Brulebois 
Date:   Tue Mar 5 21:48:28 2013 +0100

Skip load_extra on GNU/kFreeBSD and GNU/Hurd (Closes: #699704).

Let's avoid loading extra components which cannot work due to missing
dependencies (notably partman-*lvm is missing lvm2-udeb on non-Linux
architectures); this should avoid running out of space on the
(non-resizable) rootfs on GNU/kFreeBSD (Closes: #699704). Thanks, Steven
Chamberlain!

diff --git a/debian/changelog b/debian/changelog
index 52db215..d30cd14 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+partman-base (164) UNRELEASED; urgency=low
+
+  * Skip load_extra on GNU/kFreeBSD and GNU/Hurd to avoid loading extra
+components which cannot work due to missing dependencies (notably
+partman-*lvm is missing lvm2-udeb on non-Linux architectures); this
+should avoid running out of space on the (non-resizable) rootfs on
+GNU/kFreeBSD (Closes: #699704). Thanks, Steven Chamberlain!
+
+ -- Cyril Brulebois   Tue, 05 Mar 2013 21:39:39 +0100
+
 partman-base (163) unstable; urgency=low
 
   * Revert "add debhelper token to postinst"
diff --git a/partman b/partman
index c993b94..c1ff4ad 100755
--- a/partman
+++ b/partman
@@ -15,6 +15,14 @@ abort () {
 load_extra () {
 	local auto memreq_lvm memreq_crypto
 
+	# These packages currently are of no use on GNU/kFreeBSD or GNU/Hurd,
+	# but do waste a lot of space, so skip installing them here
+	case "$(udpkg --print-os)" in
+	kfreebsd|hurd)
+		return 0
+		;;
+	esac
+
 	if [ -f /var/lib/partman/loaded-extra ]; then
 		return 0
 	fi


signature.asc
Description: Digital signature

Gnome installability vs. GNU/kFreeBSD (was: "tasksel arch any" vs. "keeping track of n-m in debian-cd"?)

[Cyril Brulebois]

Cyril Brulebois  (09/04/2013):
> Then I think I'd rather ask you to keep doing so for wheezy's
> lifetime, than trying to fiddle with tasksel at this very late point
> of the freeze.

To clarify as I did on IRC:
 1. I thought both the addition of iw and network-manager-gnome as
Depends or Recommends in tasksel was depending on that "arch: all"
vs. "arch: any" discussion.
 2. However, the current tasksel package in wheezy and sid already
implements the Depends: on network-manager-gnome, for all archs.

Since we just agreed with Steve to keep the NM-related dependencies on
the debian-cd side (iw was already taken care of in src:netcfg), we
could think of uploading tasksel with just that network-manager-gnome
dependency dropped, which would fix installability issues on kfreebsd-*.

I'm not exactly sure how well Gnome is supported on GNU/kFreeBSD
anyway, so that might not be a huge practical issue. But if -bsd@
people want that fixed, they can still chime in *right now*, so that
we can patch tasksel while src:debian-installer is getting built,
before we prepare d-i wheezy rc2 images.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#704748: Not a practical issue (could even be considered a feature...:-))

[Cyril Brulebois]

Steven Chamberlain  (15/04/2013):
> For all the problems OdyX mentioned from testing, I've found a single
> cause and filed bug #705435.  I've updated this page to demonstrate a
> functioning GNOME desktop on GNU/kFreeBSD:
> https://wiki.debian.org/Debian_GNU/kFreeBSD_Desktop#Wheezy_GNOME
> 
> On 15/04/13 05:53, Christian PERRIER wrote:
> > I was balanced about working in tasksel to upload with the simple
> > "move to Recommends" fix but a brief discussion on IRC discouraged me.
> 
> For something as important as dropping a desktop environment from the
> release, I'd like to have seen discussion take place with debian-bsd@
> copied in;  this came as just a bit of a surprise.

The feedback I got to my mail to -bsd@ didn't sound like Gnome was
actually usable, and that Xfce was a bad choice. And last I checked,
not touching things when unsure is what we do at this very late stage
of the freeze.

> > And, well, doesn't this issue really fit the definition of
> > "important"?
> 
> If the severity of this is downgraded, that as an incentive for this to
> be missed out of any NMU or refused an unblock.
> 
> I felt certain this was an RC bug and/or policy violation.  A package, a
> task, a whole desktop environment became uninstallable on two release
> architectures.  We still have a tasksel option for GNOME (fails with apt
> error 100 due to this) and CD's are being built with its packages.

If you GNU/kFreeBSD folks want Gnome to be installable again, then fine.

But you should have made it clear when I asked. I thought I made it
clear I needed feedback, and I wrote “*right now*”.

For unrelated reasons, d-i will need a new upload, so I can update
tasksel today as well, before rc2 images get built again.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#704748: Not a practical issue (could even be considered a feature...:-))

[Cyril Brulebois]

Steven Chamberlain  (15/04/2013):
> I replied to your mail same day and used the words 'should work'...

Well, maybe that's just me, but that “should work” is no certainty at
all, nobody says “works for me” (quite the contrary, given Didier's
feedback after that). This “should work” was also drown in a big “it's
better to use xfce on kbsd at the moment” mail. That's why I initially
suggested Christian not to touch tasksel at all, and why he downgraded
the bug report the way he did.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Buildd fasch not building?

[Cyril Brulebois]

Steven Chamberlain  (30/05/2013):
> I don't see that buildd fasch has built anything in the past couple of
> days, and the build queue is getting quite big.  Did you know of this?

From lurking on #-buildd, things are happening on the buildd land, and
fasch is going to go away, replaced with fayrfax, just set up. Things
should go back to normal once the software config is up and running,
as far as I understand it.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: HAL and *BSD

[Cyril Brulebois]

If you want to contact X maintainers, please use the maintainer
address, which is the debian-x@ list… Quoting the full mail below
accordingly.

KiBi.

Michael Biebl  (05/06/2013):
> Hi BSD porters,
> 
> as you may know, hal hasn't seen any upstream development for years and
> is dead. For that matter I've filed bug reports some time ago [1].
> The only real blocker atm that I can see is Xorg using hal on kfreebsd.
> 
> There has been some discussion about this topic over two years ago [2],
> to get Xorg ported to devd on *BSD but I don't know what the current
> state of that effort is.
> 
> Afaics, there are basically 3 options:
> 
> 1/ We drop hal and Xorg is ported to something like devd on *BSD
> 
> 2/ We drop hal and hal support is simply disabled on non-Linux, which
> means, Xorg needs to be configured manually? Maybe Julien or KiBi can
> provide more info on this.
> 
> 3/ we keep hal, but only for the non-Linux architectures and I'd need
> someone (from the kfreebsd porters team) to take over maintenance.
> 
> While I personally would prefer 1/, I don't know if there has been
> progress on this, so I'd like some input from the kfreebsd porters on
> this matter and what their preference is.
> 
> Cheers,
> Michael
> 
> 
> [1]
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=halectomy;users=pkg-utopia-maintain...@lists.alioth.debian.org
> [2] http://lists.freebsd.org/pipermail/freebsd-x11/2011-February/010474.html
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?


signature.asc
Description: Digital signature

Re: patches for d-i/debian-installer.git

[Cyril Brulebois]

Hi Steven+Robert,

Steven Chamberlain  (2013-07-22):
> Hi Robert,
> 
> Please could you commit these two patches to d-i/debian-installer.git
> for me sometime.  Perhaps if you already have some changes to make for
> the 9.1 kernel entering unstable.
> 
> The first patch will fix building the sid netboot images.  The second
> is just code cleanup.  The resulting images are still broken due to
> #711799, but having them built would be a good start.

please make sure to include descriptive changelog entries while you're
at it…

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: patches for d-i/debian-installer.git

[Cyril Brulebois]

Robert Millan  (2013-07-22):
> 2013/7/22 Steven Chamberlain :
> > Please could you commit these two patches to d-i/debian-installer.git
> > for me sometime.
> 
> You forgot to attach them :-)

No, he replied to them…
| References: <1374526642-95217-1-git-send-email-ste...@pyro.eu.org> 
<1374526642-95217-2-git-send-email-ste...@pyro.eu.org>
| In-Reply-To: <1374526642-95217-2-git-send-email-ste...@pyro.eu.org>   
   

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [PATCH 2/2] Remove gPXE workaround (fixed in grub2 as #635877)

[Cyril Brulebois]

Steven Chamberlain  (2013-07-22):
>[ Steven Chamberlain ]
>* Drop GRUB module pxecmd, which was merged into pxe
> +  * Remove gPXE workaround (fixed in grub2 as #635877)

Thanks. Might be worth mentioning both target hurd/kfreebsd, so that later
readers don't have to figure out whether they're affected by those changes.
Also, I think it could be nice to have grub2's fix into testing before
pushing that to git? (grub2's migration is a story in itself, see another
list these days…)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [PATCH 2/2] Remove gPXE workaround (fixed in grub2 as #635877)

[Cyril Brulebois]

Hi again.

(Adding -boot@ for information, that happened to catch my eye
on -bsd@; and it's about commit bits for Steven below, too.)

Steven Chamberlain  (2013-07-22):
> On 22/07/13 22:48, Cyril Brulebois wrote:
> > Steven Chamberlain  (2013-07-22):
> >>[ Steven Chamberlain ]
> >>* Drop GRUB module pxecmd, which was merged into pxe
> >> +  * Remove gPXE workaround (fixed in grub2 as #635877)
> > 
> > Thanks. Might be worth mentioning both target hurd/kfreebsd, so that later
> > readers don't have to figure out whether they're affected by those changes.
> 
> I didn't think of that, yes maybe, but those two are the only arches
> using grub2pxe;  others use pxelinux.

That you know. Others reading the changelog, not necessarily. You'd
be amazed to see how many people actually test dailies/weeklies and
then try to figure out where regressions come from. (#debian-boot
regularly hosts such questions. Being able to answer swiftly is
nice.)

> > Also, I think it could be nice to have grub2's fix into testing [...]
> 
> Do you mean the #635877 fix making the gPXE workaround redundant?
> (Specifically, it was disabling of the multiboot header in the
> i386-pc-pxe target, by upstream 2.00).  I thought that was already in
> testing...
> 
> > (grub2's migration is a story in itself, see another
> > list these days…)
> 
> OK I will look into that.  But already this has me puzzled:
> packages.d.o and the PTS suggest grub2 2.00-14 in jessie, but bug
> #635877's version graph seems confused...
> 
> http://bugs.debian.org/cgi-bin/version.cgi?info=1;absolute=0;fixed=grub2%2F2.00-1;fixed=grub2%2F2.00-4;collapse=1;found=grub2%2F1.99-9;package=grub-pc
> 
> I think this should wait until I'm thinking coherently in any case.

The situation is confusing indeed, bottom line(s):
  http://lists.debian.org/debian-devel/2013/07/msg00690.html
  http://lists.debian.org/debian-devel/2013/07/msg00695.html

> Would it be appropriate for me to ask for commit access to d-i Git,
> perhaps for this, or likely for small d-i bits in future?

Certainly. Letting -boot@ know through this mail. For things you
feel sufficiently comfy with, getting stuff reviewed on -bsd@ is
probably sufficient, but don't be afraid to ask/cc -boot@ for
(possibly…) more eyes.

> On 22/07/13 22:36, Robert Millan wrote:
> > [...] I'm not sure how this works. Am I supposed to
> > just apply them, or do you expect your name to show up in the git log?
> > I'm afraid I don't know how to do the later [...]
> 
> I'm not sure how the committer does this, but yes it's supposed to work
> something like that if I send patches in that form;  I suspect git-am(1)
> is used.

Yes, git-am means we know that author = Steven, committer = Robert.
One needs to look slightly deeper (git log --format=fuller or gitk)
to see the committer, so one might like to add a signed-off-by line
when signing off on somebody else's changes. That's also what I do
when I cherry-pick things from a branch to another. See for example
95280b9c403adf747f860406b899bbee794ad097 in the installer.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: D-I build failures for kfreebsd-amd64....

[Cyril Brulebois]

Christian PERRIER  (2013-08-03):
> Quoting Steven Chamberlain (ste...@pyro.eu.org):
> > Yes, for grub2 >> 2.0 we just need to drop pxecmd.  Sort of related to
> 
> So, you mean drop it from there?
> installer/build/config/hurd.cfg:GRUB_MODULES_PXE=pxe pxecmd

The patches were posted/discussed in the thread started here:
  http://lists.debian.org/1374526642-95217-1-git-send-email-ste...@pyro.eu.org

Mraw,
KiBi.


-- 
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/20130804103428.ga23...@mraw.org

broken kfreebsd cdimage building

[Cyril Brulebois]

Hi Robert,

so you broke cdimage building for kfreebsd-*:
  
http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=commitdiff;h=c5a8de108e7828cc3e2694309cbb045eb8db521c
  
http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=commitdiff;h=c5a8de108e7828cc3e2694309cbb045eb8db521c

When do we get fixes for that?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: broken kfreebsd cdimage building

[Cyril Brulebois]

Robert Millan  (2013-09-26):
> > so you broke cdimage building for kfreebsd-*: 
> > http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=commitdiff;h=c5a8de108e7828cc3e2694309cbb045eb8db521c
> >
> > 
> http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=commitdiff;h=c5a8de108e7828cc3e2694309cbb045eb8db521c
> 
> No, this is correct. kfreebsd-8 is considered obsolete and won't be
> included in Jessie. See:
> 
> https://lists.debian.org/debian-bsd/2013/08/msg00175.html

You're missing the point. I'm not saying the changes are incorrect. I'm
saying they broke cdimage building, which you get to fix by sending
patches.

That's called coordinating changes. You really should have done that…

> Btw, are you still following debian-bsd?

Don't expect me to read every mail in there, but I'm still subscribed.
If changes impact the debian installer, -boot@ should now. If changes
impact cdimage, -boot@ and -cd@ should now.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: broken kfreebsd cdimage building

[Cyril Brulebois]

Robert Millan  (2013-09-28):
> Here, attached patch should get jessie builds working again. Would you
> be kind enough to commit it?

Steve (from debian-cd@) is likely the one who's going to check it. I
wonder, however, if the -boot/-cd changes are actually correct.

When removing kfreebsd 8 support, supported cdrom settings went from
kfreebsd + kfreebsd-9 to kfreebsd-9 only; when adding kfreebsd-10
support, the cdrom settings weren't added kfreebsd-10, and the patch
below isn't adding it either (so the build should be OK since that part
would be missing from the d-i build).

Is that expected though? No kfreebsd-10 in there?

(I didn't check the bootloader configuration part at all, BTW.)

> --- tools/boot/jessie/boot-kfreebsd   (revision 2572)
> +++ tools/boot/jessie/boot-kfreebsd   (working copy)
> @@ -40,7 +40,7 @@
>  fi
>  
>  # Download boot images.
> -BOOT_IMAGES="cdrom/debian-cd_info.tar.gz cdrom/kfreebsd.gz 
> cdrom/kfreebsd-9.gz cdrom/initrd.gz"
> +BOOT_IMAGES="cdrom/debian-cd_info.tar.gz cdrom/kfreebsd-9.gz cdrom/initrd.gz"
>  
>  if [ "$ARCH" = kfreebsd-amd64 ]; then
>   BOOT_IMAGES="$BOOT_IMAGES cdrom/gtk/initrd.gz"
> @@ -63,10 +63,7 @@
>  
>  # Install kernel and initrd
>  mkdir -p $CDDIR/boot/kernel/
> -cp "cdrom/kfreebsd.gz" "$CDDIR/boot/kernel/kfreebsd.gz"
> -if [ -f cdrom/kfreebsd-9.gz ] ; then
> -   cp "cdrom/kfreebsd-9.gz" "$CDDIR/boot/kernel/kfreebsd-9.gz"
> -fi
> +cp "cdrom/kfreebsd-9.gz" "$CDDIR/boot/kernel/kfreebsd-9.gz"
>  cp "cdrom/initrd.gz" "$CDDIR/boot/mfsroot.gz"
>  
>  if [ "$ARCH" = kfreebsd-amd64 ] && [ -f cdrom/gtk/initrd.gz ] ; then

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Cyril Brulebois]

Robert Millan  (2013-10-03):
> Niels Thykier:
> > Arch   || DDs || NMs/DMs || Other || Total
> > ---++-++-++---++--
> > [...]
> > kfreebsd-amd64 ||  4  ||   0 || 2 ||6
> > kfreebsd-i386  ||  4  ||   0 || 2 ||6
> >
> > [...]
> > 
> > The current policy says that we require "5 developers" (i.e. DDs) for
> > release architectures[AP],
> 
> So it would seem that we're missing one more DD. Since we had 4
> contributors in the past which were/are DDs, I figure perhaps they will
> want to step in.
> 
> Please, if you intend to get involved again with kfreebsd-* during
> Jessie life cycle, consider sending the pledge to -release by replying
> to initial mail from Niels.

No more time or interest, sorry.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Please give back vice on kfreebsd-amd64

[Cyril Brulebois]

Steven Chamberlain  (2013-10-06):
> Hi,
> 
> Please could we give back vice for build on kfreebsd-amd64;  I cannot
> reproduce the issue locally in sid:
> 
> https://buildd.debian.org/status/fetch.php?pkg=vice&arch=kfreebsd-amd64&ver=2.4.dfsg-1&stamp=1377367654
> > PATH=../src:$PATH /usr/bin/xgettext --default-domain=vice --directory=.. 
> > --directory=.. \
> >   --add-comments --keyword=_ --keyword=N_ \
> >   --files-from=./POTFILES.in \
> >   -o ./vice.pot
> > /usr/bin/xgettext: error while opening "src/arch/win32/res.rc.po.c" for 
> > reading: No such file or directory

Done so on both kfreebsd-amd64 and s390, just in case.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#725616: hplip: no longer buildable on kfreebsd-*

[Cyril Brulebois]

Source: hplip
Version: 3.13.9-1
Severity: serious
Justification: FTBFS

Hi,

your package can no longer be autobuilt on kfreebsd-*:
| hplip build-depends on:
| - libsane-dev
| libsane-dev depends on:
| - libusb-1.0-0-dev | --virtual-libusb-1.0-0-dev
| hplip build-depends on:
| - libusb-dev
| libusb2-dev conflicts with:
| - libusb-dev

as seen on:
  https://buildd.debian.org/status/package.php?p=hplip&suite=sid

Feel free to ping debian-bsd@ (cc-d) to get some help.

Mraw,
KiBi.


-- 
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/20131006210655.31746.65590.report...@bowmore.home.mraw.org

Bug#725627: pcp: FTBFS on kfreebsd-*: trace.c:19:20: fatal error: probes.h: No such file or directory

[Cyril Brulebois]

Source: pcp
Version: 3.8.4
Severity: serious
Justification: FTBFS

Hi,

your package no longer builds on kfreebsd-*:
| gcc  -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all 
-D_FORTIFY_SOURCE=2 -I../../../src/pmcd/src -I../../../src/libpcp/src 
-DPMCD_INTERNAL -I/usr/include/nss -I/usr/include/nspr -Wall -O2 -g -DPCP_DEBUG 
-DPCP_VERSION=\"3.8.4\" -I../../../src/include -I../../../src/include/pcp   -c 
-o trace.o trace.c
| trace.c:19:20: fatal error: probes.h: No such file or directory
|  #include "probes.h"
| ^
| compilation terminated.

Full build logs:
  https://buildd.debian.org/status/package.php?p=pcp&suite=sid

Feel free to contact debian-bsd@ (cc'd) if you need help.

Mraw,
KiBi.


-- 
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/20131006220536.3962.18425.report...@bowmore.home.mraw.org

Bug#725639: citadel: FTBFS on kfreebsd-*: error: 'struct dirent' has no member named 'd_namelen'

[Cyril Brulebois]

Source: citadel
Version: 8.20-1
Severity: serious
Justification: FTBFS

Hi,

your package no longer builds on kfreebsd-*:
| CC modules/bio/serv_bio.c
| modules/bio/serv_bio.c: In function 'cmd_lbio':
| modules/bio/serv_bio.c:116:28: error: 'struct dirent' has no member named 
'd_namelen'
|d_namelen = filedir_entry->d_namelen;
| ^
| make[1]: *** [modules/bio/serv_bio.o] Error 1

Full build logs:
  https://buildd.debian.org/status/package.php?p=citadel&suite=sid

If you need help, please contact debian-bsd@.

Mraw,
KiBi.


-- 
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/20131006225137.gm2...@mraw.org

BD-Uninstallable packages: ruby2.0

[Cyril Brulebois]

Hi,

I'm not sure that's a known/tracked issue, so here's what I saw: a bunch
of ruby packages are currently BD-Uninstallable due to the following
dependency chain:
| XXX build-depends on:
| - gem2deb (>= 0.3.0~)
| gem2deb depends on missing:
| - ruby2.0

It would be nice if somebody could make sure this is known and/or
getting fixed.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#725641: webcit: FTBFS on kfreebsd-*: error: 'struct dirent' has no member named 'd_namelen'

[Cyril Brulebois]

Source: webcit
Version: 8.20-dfsg-1
Severity: serious
Justification: FTBFS

(I see a pattern here. ;-))

Same story as with src:citadel, FTBFS on kfreebsd-*:
| CC subst.c
| subst.c: In function 'LoadTemplateDir':
| subst.c:1529:28: error: 'struct dirent' has no member named 'd_namelen'
|d_namelen = filedir_entry->d_namelen;
| ^
| make[1]: *** [subst.o] Error 1

Full build logs:
  https://buildd.debian.org/status/package.php?p=webcit&suite=sid

Help: debian-bsd@.

Mraw,
KiBi.


-- 
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/20131006230227.gp2...@mraw.org

Bug#725643: zfsutils-udeb: uninstallable, due to the libjail1 depends

[Cyril Brulebois]

Package: zfsutils-udeb
Version: 9.2-1
Severity: grave
Tags: d-i
Justification: renders package unusable

Hi,

your package is no longer installable, since it gained a dependency on
libjail1, which isn't an udeb. This was caught by our edos4udeb script,
but that can easily be deduced from the changelog:
| - Add libjail-dev to B-D.

Debdiffing udeb-producing packages before uploading them would be nice.

Mraw,
KiBi.


-- 
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/20131006230928.9550.39129.report...@bowmore.home.mraw.org

Accepted partman-zfs 29 (source kfreebsd-i386)

[Cyril Brulebois]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 07 Oct 2013 02:20:54 +0200
Source: partman-zfs
Binary: partman-zfs
Architecture: source kfreebsd-i386
Version: 29
Distribution: unstable
Urgency: low
Maintainer: Debian Install System Team 
Changed-By: Cyril Brulebois 
Description: 
 partman-zfs - Add to partman support for ZFS (udeb)
Changes: 
 partman-zfs (29) unstable; urgency=low
 .
   * Revert the following changes, since there's nothing ready for it on
 the Linux kernel side, and we just end up shipping uninstallable linux
 binaries:
 - Support arch linux-any.
 .
   [ Updated translations ]
   * Updated po files: el, eo, ga, gu, kk, mr, pl, tr.
Checksums-Sha1: 
 349e6d586305fd5f3d815d9bedc6635ef0d5b466 1015 partman-zfs_29.dsc
 598ea5e71d8977e360cb6a0ea5a993c6175d863a 369825 partman-zfs_29.tar.gz
 a69410d1774b4a6d1d1be9173dd190540ec38f4e 279742 
partman-zfs_29_kfreebsd-i386.udeb
Checksums-Sha256: 
 75ac0b535632edda4166abc1d0038fd6aa333967125daa31df9f30c3f37fc0ea 1015 
partman-zfs_29.dsc
 1a6ff11436e2df00113f80d911429638856ce18829d707339a0b34154b45240f 369825 
partman-zfs_29.tar.gz
 19875a78c710bc21263f9ca335db2f4314787ae6649e250b2d8754ea4b00998b 279742 
partman-zfs_29_kfreebsd-i386.udeb
Files: 
 0503f73a81edc44ec6579850a132a6f6 1015 debian-installer standard 
partman-zfs_29.dsc
 822e2253b1b5e3e7a7d77a6d2843a024 369825 debian-installer standard 
partman-zfs_29.tar.gz
 9c10c1fa158265a46bba6ab8a97ae712 279742 debian-installer standard 
partman-zfs_29_kfreebsd-i386.udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEARECAAYFAlJSACIACgkQeGfVPHR5Nd1IkgCgoW32R58O/6rlJ+37HuwtQVcs
g0YAoJdyRxt5Z+UyXy6Sr2EIbh+pWFw8
=E6aH
-END PGP SIGNATURE-



-- 
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/e1vsyl4-00032f...@franck.debian.org

Re: ufsutils experiment (please comment/test)

[Cyril Brulebois]

Robert Millan  (2013-10-09):
> I'm not specially fond of this kind of proposals coming from people who
> are not actively involved with the port, but if it's useful in general
> and it doesn't prevent me from using SVN I have no objection with it.
> 
> I suggest we wait a few days to see if everyone else is okay with this.

I'm not sure why you think it could *not* be OK. Having to git svn clone
a repository usually takes forever, so sharing that part is a big if not
huge win for anyone not wanting to deal with svn directly.

And since that doesn't interfere with people wanting to keep on using
svn directly, why would that matter at all?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bits from the Release Team (Jessie freeze info)

[Cyril Brulebois]

Johannes Schauer  (2013-10-26):
> (I was not able to find the debian-ports list on lists.debian.org (so I
> subscribed via email) did I just miss it?)

Dead list: http://lists.debian.org/debian-ports/

AFAICT it's now an alias for all debian-$port lists.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#727829: FTBFS on mipsel

[Cyril Brulebois]

Robert Millan  (2013-10-27):
> It seems kfreebsd-10 FTBFS on mipsel due to compiler issues (missing
> -lgcc maybe?):
> 
> https://buildd.debian.org/status/fetch.php?pkg=kfreebsd-10&arch=mipsel&ver=10.0~svn257123-1&stamp=1382831349
> 
> As compiler support for kernel is becoming increasingly troublesome
> because of the gcc version divergence (upstream uses gcc-4.2 for mips,
> not clang), unless somebody steps in I will disable mipsel support until
> a simpler (i.e. requiring less manpower) solution is available (such as,
> upstream moving mips toolchain to clang).
> 
> FTR, even former versions which built succesfully are not bootable under
> QEMU/MALTA, unlike those built on FreeBSD (e.g. the one in
> http://people.debian.org/~rmh/kfreebsd-mipsel/)

A slightly different question would be: why should we care about mipsel
at all?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#649038: elfutils FTBFS on kfreebsd

[Cyril Brulebois]

Steven Chamberlain  (2013-11-10):
> We could work around that by a porter building it outside of sbuild
> and doing a binNMU.  It's not a permanent solution, but it would at
> least allow elfutils' other RC bug fixes to migrate meanwhile.

As a mere spectator, it looks like porter uploads happened a few times
already, so one might want to get the issue fixed once and for all.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: kfreebsd givebacks for openjdk-7

[Cyril Brulebois]

Steven Chamberlain  (2013-11-23):
> We now have openjdk-7 as the default java on kfreebsd-* in sid [0].
> 
> Please could you give back:
> * gluegen2
> * eclipse
> for kfreebsd-amd64 and kfreebsd-i386.

Done for both.

(Randomly passing by…)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#731258: libfreebsd-glue-0-udeb: uninstallable (depends on libdb5.1)

[Cyril Brulebois]

Package: libfreebsd-glue-0-udeb
Version: 0.2.4
Severity: grave
Tags: d-i
Justification: renders package unusable

Hi,

again an uninstallable package breaking d-i builds…

KiBi.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20131203174204.19405.4676.reportbug@localhost

kfreebsd-10 in d-i (was: kfreebsd-10)

[Cyril Brulebois]

Steven Chamberlain  (2013-12-08):
> I would have said that I prefer we wait for RC1 (in case of security
> bugs, and having to fix them quickly if it migrated to testing already).
>  Now that RC1 has been tagged in releng branch, I'm all in favour of
> this going into sid/testing.  With Robert's patch implementing the
> radeonkms sysctl (which doesn't affect anything yet, but we may need it
> later).
> 
> I think enabling kfreebsd-10 for d-i is okay too;  might as well make it
> available right away for people to start testing.

I'm slightly sad to learn about this so incidentally, just because I
happen to still be subscribed to -bsd@.

Anyway, not a good idea until kfreebsd-10 is available in testing.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: kfreebsd-10 in d-i

[Cyril Brulebois]

Steven Chamberlain  (2013-12-08):
> Yes, please.  And now for the record, kfreebsd-10 is being uploaded to
> sid;  we'd like to enable it in d-i if there are no other objections.

I'll try and get d-i uploaded in december. Depend how it goes on the
buildds, I might perform another upload to get it into testing. Whatever
happens, I'll let you know when it's OK to push things to master. In the
meanwhile, feel free to push what you need in a branch, and it'll be
merged when it's ready™. ;)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

[Cyril Brulebois]

Steven Chamberlain  (2013-12-14):
> On 14/12/13 01:08, Henrique de Moraes Holschuh wrote:
> > Yeah, I think Linux went through similar blindness braindamage sometime ago,
> > but blind trust on rdrand has been fixed for a long time now, and it never
> > trusted any of the other HRNGs (or used them for anything at all without a
> > trip through "rng-tools" userspace until v3.12).
> 
> I seem to remember that Ted T'so's committed the fix for this only after
> the release of Linux 3.2, so I assuemd wheezy's kernels might be still
> affected?

If you're talking about this:
| commit c2557a303ab6712bb6e09447df828c557c710ac9
| Author: Theodore Ts'o 
| Date:   Thu Jul 5 10:35:23 2012 -0400
| 
| random: add new get_random_bytes_arch() function
| […]

it was backported into 3.2.y, that would be 
7f5d5266f8a1f7f54707c15e028f220d329726f4
also known as v3.2.27~51.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#732514: [PATCH] fixes for Radeon KMS on kFreeBSD

[Cyril Brulebois]

Robert Millan  (2013-12-24):
> Upstream part is merged in their repository now. I'm attaching an update for 
> the
> Debian part (regarding kfreebsd-downloader).
> 
> -- 
> Robert Millan

> diff -ur xserver-xorg-video-ati-7.2.0/debian/control 
> xserver-xorg-video-ati-7.2.0.new/debian/control
> --- xserver-xorg-video-ati-7.2.0/debian/control   2013-12-16 
> 22:40:22.0 +0100
> +++ xserver-xorg-video-ati-7.2.0.new/debian/control   2013-12-16 
> 22:54:49.294891823 +0100
> @@ -79,7 +79,7 @@
>   ${misc:Depends},
>   ${xviddriver:Depends}
>  Provides: ${xviddriver:Provides}
> -Suggests: firmware-linux
> +Suggests: firmware-linux [linux-any], kfreebsd-downloader (> 11~) 
> [kfreebsd-any] | kfreebsd-downloader-10 [kfreebsd-any]

foo (> bar) is antique dpkg syntax.

and:
| kibi@arya:~$ rmadison kfreebsd-downloader
| kfreebsd-downloader | 9.0-3+deb70.1 |   stable/contrib | source, 
kfreebsd-amd64, kfreebsd-i386
| kfreebsd-downloader | 9.2-1 |  testing/contrib | source, 
kfreebsd-amd64, kfreebsd-i386
| kfreebsd-downloader | 9.2-1 | unstable/contrib | source, 
kfreebsd-amd64, kfreebsd-i386

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Release sprint results - team changes, auto-rm and arch status

[Cyril Brulebois]

brunomaxi...@openmailbox.org  (2014-01-05):
> So, gnome-shell is working for you?

Can you please stop breaking threads? That's very annoying.

KiBi.


signature.asc
Description: Digital signature

Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64

[Cyril Brulebois]

Michael Vogt  (2014-01-16):
> On Sun, Jan 12, 2014 at 08:05:06PM +, Steven Chamberlain wrote:
> > Control: tags -1 found apt/0.9.14.2
> > 
> > Indeed upgrading only libapt-pkg4.12 is enough to trigger this.
> [..]
> 
> Thanks a bunch for your bugreport and sorry for my slow reply. Its
> likely that this is fallout from some fairly big changes in the
> handling of dpkg.
> 
> What is the best way for me to reproduce this? I don't have a kfreebsd
> system right now - is installing one from a current installer image in
> kvm the quickest way (I assume so)?

This might be slightly quicker:
  http://blog.aurel32.net/153
  http://people.debian.org/~aurel32/qemu/

But otherwise, that's what I'd do.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: RFC: Debian GNU/kFreeBSD and Jessie

[Cyril Brulebois]

Robert Millan  (2014-01-31):
> -release asked us to discuss a possible solution among ourselves so we can
> propose it to them. But the problem is not clearly defined yet. So I thought
> maybe we can do some progress by discussing what the problem is.
> 
> Here's what I think of as a problems that may need to be fixed by reaching
> an agreement with -release:
> 
> 1. Some application-level software is growing hard dependencies on SystemD
> or other Linux-specific components (e.g. X->udev, gdm3->systemd).

X->udev is utterly wrong. HAL isn't maintained, true. But I proposed a
plan to migrate away from HAL to another system allowing for hotplug[1],
and nobody picked it up. That doesn't mean that X is moving to udev-only.

 1. https://lists.debian.org/20110213124019.gh7...@debian.org
https://lists.debian.org/debian-bsd/2011/02/msg00173.html
[ Yes, that was 3 (three) years ago. ]

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: kfreebsd-10 in D-I

[Cyril Brulebois]

Robert Millan  (2014-02-01):
> kfreebsd-10 seems to work fine to boot and load D-I. Shall we enable
> it in the builds already? (alongside kfreebsd-9)

I'd like to upload d-i as soon as linux is ready to migrate to testing,
so I'd love if you could push the needed changes to a say 'kfreebsd-10'
branch for the time being.

(As far I can tell, linux svn has a fix for the RC bug and another one
for the FTBFS on sparc, so hopefully that shouldn't take too long.)

Would that be OK with you?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#737460: freebsd-glue: BD-Uninstallable: b-d on missing kfreebsd-kernel-headers (>= 10.0~3)

[Cyril Brulebois]

Source: freebsd-glue
Version: 0.2.17
Severity: serious
Justification: FTBFS

Hi,

2 issues in one:
 - the package can't be autobuilt on kfreebsd-i386 due to the missing
   kfreebsd-kernel-headers[1];
 - the kfreebsd-amd64 packages that were uploaded were built against
   stuff that aren't in sid.

 1. https://buildd.debian.org/status/package.php?p=freebsd-glue&suite=sid
Dependency installability problem for freebsd-glue on kfreebsd-i386:
  freebsd-glue build-depends on missing:
  - kfreebsd-kernel-headers (>= 10.0~3)

Mraw,
KiBi.


-- 
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/20140202203320.25034.98934.reportbug@arya

Bug#737465: wpa: FTBFS on kfreebsd-*: src/eap_peer/tncc.o: undefined reference to symbol 'dlsym@@GLIBC_2.3'

[Cyril Brulebois]

Source: wpa
Version: 1.0-3.1
Severity: serious
Justification: FTBFS

Hi,

the 1.0-3.1 NMU introduces an FTBFS on kfreebsd-*:
| /usr/bin/ld: ../src/eap_peer/tncc.o: undefined reference to symbol 
'dlsym@@GLIBC_2.3'
| /lib/x86_64-kfreebsd-gnu/libdl.so.2: error adding symbols: DSO missing from 
command line

Full build logs:
  
https://buildd.debian.org/status/fetch.php?pkg=wpa&arch=kfreebsd-amd64&ver=1.0-3.1&stamp=1386714948
  
https://buildd.debian.org/status/fetch.php?pkg=wpa&arch=kfreebsd-i386&ver=1.0-3.1&stamp=1386713443

BTW, you were already notified in [1] about it (even if an FTBFS bug
report would have been slightly better), so I wouldn't have expected the
FTBFS to still be unfixed by now. Especially since the fix is likely a
one-liner or even one-worder…

 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678147#53

Mraw,
KiBi.


-- 
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/20140202204635.26419.46190.reportbug@arya

Re: Bug#737568: RM: partman-zfs [amd64 armel armhf i386 ia64 mips mipsel s390x sparc] -- ANAIS; no longer built on linux-any

[Cyril Brulebois]

Steven Chamberlain  (2014-02-03):
> On 03/02/14 21:49, Ansgar Burchardt wrote:
> > Please remove partman-zfs from linux-any. It's only built on
> > kfreebsd-any again since version 29.
> 
> A whole lot of changes got applied for the benefit on ZFS-on-Linux, so I
> thought.  It was sort of accidentally applied in master without a
> review, the changes are not really explained in the changelog, and some
> of it doesn't even make sense for kfreebsd.
> 
> The newly added option to create a 'ROOT' filesystem is redundant for
> kfreebsd, because you could choose to mount any ZFS filesystem as the
> root.  Furthermore that new option creates a whole hierarchy of
> subfilesystems for boot, home, var, usr without warning/asking.  I
> haven't tested, but it sounds likely to clobber any user-created UFS
> filesystems mounted on any of those, particularly /boot.  It's also
> pre-defined and not templateable, whereas the original design (based on
> partman-lvm) already was.
> 
> I feel tempted to revert much of it if kfreebsd is the only user of the
> package now.  I could maybe move those bits to a branch out of the way?

Are you thinking about origin/zol?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#737568: RM: partman-zfs [amd64 armel armhf i386 ia64 mips mipsel s390x sparc] -- ANAIS; no longer built on linux-any

[Cyril Brulebois]

(Putting -boot in the loop again.)

Steven Chamberlain  (2014-02-03):
> On 03/02/14 22:24, Cyril Brulebois wrote:
> > Are you thinking about origin/zol?
> 
> Ah, yes it's already staged there.
> 
> You reverted one commit from that series already, one that enabled
> builds for linux-any and also loaded the zfs module, so I expect it is
> completely broken on Linux already.

There's no zfs on linux…

> Everything else from that branch has potentially caused regressions on
> kfreebsd as well as the example I gave.

If there's stuff before 1bd59bde47534f2233c683150a1ada3c99fbf71a that's
causing issues, I'd expect bug reports to flow in. There's 28 in
testing, and it's been there for quite a while already, and was used to
build the d-i upload from december. Daily builds also have recent-ish
partman-zfs versions.

So zfs users might want to double-check how {well,bad} partman-zfs works
nowadays. Please note a d-i upload is pending (we're waiting for linux
to hit testing); and if #737568 is processed soon, we should get version
31 in that build.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: FreeBSD 10 userland

[Cyril Brulebois]

Steven Chamberlain  (2014-02-03):
> * mkfs.ufs (which seemed broken yesterday in jessie d-i images with
> 9.2 kernel?)

Which image(s)?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: d-i-n-i: #695500 is apparently a grub-mkimage (or debian-installer) bug

[Cyril Brulebois]

Steven Chamberlain  (2014-02-04):
> Going from GRUB 2.00-18 to 2.00-22, I don't see "error: variable
> `prefix' isn't set" any more.  It would be nice to know if the problem
> is still reproducible, although this is blocked by #711799
> 
> KiBi, please may I commit the attached change anyway (prompted by Colin
> Watson's suggestion in [0]) for the sake of clarity?

Sure, please go ahead; thanks.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: issues affecting kfreebsd d-i

[Cyril Brulebois]

Hi,

Steven Chamberlain  (2014-02-04):
> I'm guessing /var/cache/anna in the ramdisk initially, but udpkg
> installs their contents one at a time all over the root filesystem.

I'm not exactly sure how the tmpfs stuff is done on non-Linux
architectures, but /var/cache/anna is indeed the place where
udebs are downloaded to, and installed from.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Getting patches applied. emulated buildd's are good (was: kFreeBSD is "fantastic")

[Cyril Brulebois]

Drew Scott Daniels <[EMAIL PROTECTED]> (08/03/2007):
> guillem's [0] list of bugs [1] shows the main problem for the kfreebsd
> porters. 93 "important" (probably release-critical for kfreebsd) with
> patches available! 105 bugs with patches not applied.

To be fair, 20+ were opened in the last 3 days, and some are already
pending or closed (thanks!). But I agree that having some patches
sleeping during months (or years) isn't that funny for porters...

> Perhaps we can recommend marking bugs as -patch if the patch is no
> good? Maybe a user tag or some way of having patches marked as needing
> more review? I think if we did these, we'd still see that good patches
> aren't being applied but at least we'd be able to help more quickly
> identify where work is needed.

As a first guess, one could use “patch moreinfo” to ask for help or peer
review, though asking the porter/patch submitter for explanations, and
eventually the -bsd list, should be sufficient. But I agree that there
might be better semantics (set of) (user)tags.

Cheers,

-- 
Cyril Brulebois


pgp3JJ9t8OciK.pgp
Description: PGP signature

Re: pstoedit: FTBFS on GNU/kFreeBSD

[Cyril Brulebois]

Petr Salinger <[EMAIL PROTECTED]> (21/06/2006):
> The current version fails to build on GNU/kFreeBSD due to unsatisfied
> build-dependency on sysutils.
> 
> But sysutils are not needed for building. Please, could you just drop
> it.

Hi,

we had no news about this bugreport, is there anything wrong with
dropping this extra B-D?

I'm thinking about a porter NMU since this package has many reverse
dependencies, at least by lowering this B-D with a "[!kfreebsd-i386
!kfreebsd-amd64]" (and maybe "!hurd-i386" also, I'm asking GNU/Hurd
porters), so that nothing at all changes for Linux.

Thanks for considering to do this tiny modification in a Maintainer
Upload or to allow us (GNU/kFreeBSD porters) to NMU it.

Cheers,

-- 
Cyril Brulebois


pgpbcq7DNA46m.pgp
Description: PGP signature

Re: short term tasks for GNU/kFreeBSD

[Cyril Brulebois]

Petr Salinger <[EMAIL PROTECTED]> (15/03/2007):
> * make fewer packages uninstallable 
> (http://edos.debian.net/edos-debcheck/)
> 
>  - build and upload xulrunner 1.8.0.10-3
>  - porter NMU of jabber-common (#407102)
>  - port tct
>  - port cdrdao
> 
> I am currently short of time, any volunteers ? ;-)

Hi Petr and -bsd,

I'm currently finishing my first walk through the "easy" FTBFS
(according to maxwell + hagrid logs) and trying to fix as many of them
as possible, and take some notes about why I think others fail. Once
that finished, I'll have a look at your suggested tasks.

(Aurélien: a sponsored porter NMU could be interesting for me, so that I
can let my AM know that I'm able to handle this kind of things, and
jabber-common could be a good candidate, although it is not urgent
(quite a recent bug) and we might be do that with another package.)

Cheers,

-- 
Cyril Brulebois


pgpMUcqlpuH0V.pgp
Description: PGP signature

Re: short term tasks for GNU/kFreeBSD

[Cyril Brulebois]

Daniel Baumann <[EMAIL PROTECTED]> (16/03/2007):
> In the last few days, I uploaded about 10 packages of my sponsorees
> who applied your patches.

Many thanks for your and your sponsorees' responsiveness, that's really
motivating and appreciated.

Cheers,

-- 
Cyril Brulebois


pgpeS0TEObgN8.pgp
Description: PGP signature

Re: short term tasks for GNU/kFreeBSD

[Cyril Brulebois]

#include 

Aurelien Jarno <[EMAIL PROTECTED]> (16/03/2007):
> The package is currently building on my machine. I still don't know
> why this package fails to build on the two i386 build daemons, while
> they builds correctly on my machine or on io.debian.net. It builds
> fine on the amd64 build daemon.

To help me a bit with strange build systems enabling/disabling some
features (and thus some files/directories are missing at the very end of
the build and one might have difficulties to see why), I wrote a tiny
script to extract the interesting part of a buildd log (which I get from
experimental.ftbfs.de or from buildd.debian.org), i.e. the
dpkg-buildpackage until dpkg-genchanges part, also replacing some HTML
entities and mostly replacing the build directory by a given token, so
that the "normalized" build log is independant of the box on which it
was extracted. The same script also applies to a dpkg-buildpackage
output, on a devel box. I don't know if it can be of some interest to
anyone else but in this case, extract-log.pl on io, in my home.

If someone knows about this kind of tool, please let me know. If not, I
might be interested in developping it a bit to automatically fetch the
logs matching a given architecture and version. By diff'ing or wdiff'ing
two "normalized" build logs, it is quite easy to see that such directory
isn't entered, that such feature isn't available on such arch, etc.

> >   - porter NMU of jabber-common (#407102)
> 
> I agree to sponsor a NMU, as proposed by Cyril. I think the first
> thing to do is to ping the maintainer and propose him a porter NMU.

Which I've just done.

Cheers,

-- 
Cyril Brulebois


pgpK9YeDbNYzM.pgp
Description: PGP signature

New user - Some problems (emacs, sbcl)

[Cyril Brulebois]

Hi!

I'm acting as a proxy for a new user who has some troubles with his new
GNU/kFreeBSD installation. I've also set the Reply-To to his mail
address since he isn't subscribed.

,--- 
| Hello, I installed debian gnu-kbsd yesterday under qemu.  I had some
| difficulties with Xorg which were fixed, with the help of some guys in
| #gnu-kbsd.  Now there are two other problems that remain, and are
| major in my opinion:
| 
| 1. Emacs: I can't install the packages emacs or emacs21 because of
| broken dependancies.  Then i installed emacs-snapshot. Now emacs works
| in non-X, but if i start X and run emacs, or emacs-snapshot, or
| emacs-snapshot-x, i get the following error: Fattal error
| (11)Segmentation fault I think that this is a very important "bug"
| because I can hardly use my system without emacs.
| 
| 2. SBCL: The package sbcl is not available in the repos although the
| sbcl-source, and sbcl-doc are. On #gnu-kbsd I was told that it is
| because it has to be bootstraped. I would like to ask you to fix that
| as soon as possible, because the window manager i usually use
| (stumpwm), depends on sbcl, and a lot of my daily computer time has
| to do with sbcl. (well for lisp programming I could still use clisp,
| which is ported)
| 
| Thanks in advance,
| 
| Antonis Antoniadis (plutonas)
`---

I don't know much about emacs (never used it) so if someone more
familiar with it could have a look, that could be fixed more quickly
that I would be able to.

About the sbcl package, I never work on bootstrapping, but I'm willing
to try that soon.

Cheers,

-- 
Cyril Brulebois


pgp3cuqSCaPCV.pgp
Description: PGP signature

Re: New user - Some problems (emacs, sbcl)

[Cyril Brulebois]

Florian Weimer <[EMAIL PROTECTED]> (24/03/2007):
> Can SBCL still be compiled with CLISP?  In that case, it's not a real
> bootstrapping exercise, and it might be easier to go that route.

Thanks for the suggestion, but looks like a no-go since:
,---
| sbcl (1:0.9.6.0-11) unstable; urgency=low
| 
|   * Give up on the clisp cross-compiling,
| manualy recompile everywhere with sbcl.
| 
|  -- Peter Van Eynde <[EMAIL PROTECTED]>  Tue,  8 Nov 2005 21:18:05 +0100
`---

Maybe it is possible to cross-compile an older (e.g 0.9.5 version)
version using clisp and then use that cross-compiled version to build
newer ones. I'm getting in touch with Peter ASAP.

Cheers,

-- 
Cyril Brulebois


pgpunUwktgaLx.pgp
Description: PGP signature

snd_driver: bug found but not (yet) fully identified

[Cyril Brulebois]

10 kldload  NAMI  "/lib/modules/6.2-1-686/linker.hints"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_ess"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_ess.ko"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_ess.ko"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/linker.hints"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_es137x"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_es137x.ko"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_es137x.ko"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/linker.hints"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_emu10k1"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_emu10k1.ko"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_emu10k1.ko"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/linker.hints"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_ds1"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_ds1.ko"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_ds1.ko"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/linker.hints"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_csapcm"
| 29010 kldload  NAMI  "/lib/modules/6.2-1-686/snd_csapcm.ko"
| 29010 kldload  NAMI  "/boot/kernel/linker.hints"
| 29010 kldload  NAMI  "/boot/kernel/snd_csa.ko"
| 29010 kldload  NAMI  "/boot/kernel/snd_csa.ko.ko"
| 29010 kldload  RET   kldload -1 errno 2 No such file or directory
| 29010 kldload  CALL  write(0x2,0xbfbfc61c,0x9)
| 29010 kldload  GIO   fd 2 wrote 9 bytes
|   "kldload: "
| 29010 kldload  RET   write 9
| 29010 kldload  CALL  write(0x2,0xbfbfc634,0x15)
| 29010 kldload  GIO   fd 2 wrote 21 bytes
|   "can't load snd_driver"
| 29010 kldload  RET   write 21/0x15
| 29010 kldload  CALL  write(0x2,0x281a3599,0x2)
| 29010 kldload  GIO   fd 2 wrote 2 bytes
|   ": "
| 29010 kldload  RET   write 2
| 29010 kldload  CALL  write(0x2,0xbfbfc61c,0x1a)
| 29010 kldload  GIO   fd 2 wrote 26 bytes
|   "No such file or directory
|   "
| 29010 kldload  RET   write 26/0x1a
| 29010 kldload  CALL  exit(0x1)
`---

I don't really know why, but every module but snd_csa is loaded
successfully. If I kldload manually snd_csa, I'm able to load snd_driver
then, w/o troubles. What is quite weird is that snd_csa.ko is under
/lib/modules/6.2-1-686 just like every other module. I also wonder why
for each driver, the linker.hints file is read from the module directory
and for the only snd_csa, it is read from the /boot/kernel directory...

Anyway, sound up and running now. \o/

Any hint on what could be going wrong is welcome.

Cheers,

-- 
Cyril Brulebois


ktrace.txt.gz
Description: application/gunzip


pgpM1pxnrWTW2.pgp
Description: PGP signature

Buggy perl's socket library: incorrect perl build?

[Cyril Brulebois]

Hi again,

while I'm at it... I initially heard (thanks to Aurelien) of ktrace when
I asked how to debug a buggy Socket.pm (or his associated .so part).

After some tests, it looks like a normal bind() call in a C program is
successful (after all, many servers work well on GNU/kFreeBSD), with 16
as last (3rd) parameter. On GNU/Linux, a Perl program using Socket.pm
also implies a bind() call with the correct 3rd parameter. But on
GNU/kFreeBSD, this parameter is set to 0, which I guess is quite wrong
and explains while I'm getting "Invalid argument".

[For references, see #415607, #415611, vncserver is using "use Socket;"
to detect a free port to bind the server to. I'm also Cc-ing the
maintainer, Ola, so that he doesn't lose time on debugging what is a
GNU/kFreeBSD problem.]

I also wrote some scripts to automate the download and comparison of a
"personal" build log and one from buildd.d.o or experimental.ftbfs.de,
and here is the wdiff output:
  http://kibi.sysif.net/pub/logs/perl-build.wdiff

(FWIW, you can view it with syntax coloration using ":set ft=wdiff"
under vim.)

The following changes are repetitive but harmless:
> Processing hints file [-hints/linux.pl-] {+hints/gnukfreebsd.pl+}
since gnukfreebsd.pl sources linux.pl.

What is more embarrassing IMHO is lines 77-97 (library detection) as
well as the compilation of many files without LIBC:
> -DLIBC="/lib/libc-2.3.6.so" on GNU/Linux
> -DLIBC=""   on GNU/kFreeBSD

I didn't dig that much (though I probably will soon), but I wanted to
make sure that this problem is known. My guess is a buggy DynaLoader due
to wrong library detection, which could explain a wrong call to bind().
Also, I'm getting weird "Inappropriate ioctl for device" when issuing a
simple "wdiff" call with two parameters, from Perl. I don't know whether
it is related, but I'd say that Perl might be buggy in more areas that
the sole Socket.pm case.  Anyway, I'm using it intensively and these are
the only troubles I've encountered by now.

Cheers,

-- 
Cyril Brulebois


pgph4VwAafprz.pgp
Description: PGP signature

Re: Buggy perl's socket library: incorrect perl build?

[Cyril Brulebois]

Cyril Brulebois <[EMAIL PROTECTED]> (29/03/2007):
> What is more embarrassing IMHO is lines 77-97 (library detection)

And actually, when looking at what is printed to the screen, the library
detection happens in a similar way... But it is not caught by debuild in
the generated log, neither when I call dpkg-buildpackage manually with
2>&1 | tee $log. That's one more thing I'm not getting...

I tried to have a look at every occurrence of /linux/i in the debian/
and in the top-level directory, thus adjusting some triplet checks in
the ./Configure file, but then the compilation terminates after some
files. I guess I really need to know what library detection does output
before trying anything else. But the above-mentioned logging problem is
quite embarrassing...

Amazed,

-- 
Cyril Brulebois


pgpitXm3Leaip.pgp
Description: PGP signature

libsigc++: ping on #260256

[Cyril Brulebois]

Hi,

is there any reason preventing the patch for #260256 to get applied? It
was reported a while back and we haven't been receiving any answer for
1.5+ year. What would you think of a porter NMU? (Since I understand
fully that you might be busy on something else.)

Thanks in advance.

Cheers,

-- 
Cyril Brulebois


pgp4HbJ3jIyLY.pgp
Description: PGP signature

RFC: updated patch for #333147, still needs work

[Cyril Brulebois]

Hi again,

here is an updated patch for #333147, since the proposed one doesn't
apply cleanly anymore. I'd also point that the disabled patch also
contains an off-by-one correction, so one might want to keep it somehow.
At last, the package doesn't build even with the updated patch, failing
there:
> cc -pipe -O1 -mtune=i486 -fomit-frame-pointer -I../lib -Wall 
> -Wmissing-prototypes -Wstrict-prototypes -DNCH=1   -D_FILE_OFFSET_BITS=64 
> -DSBINDIR=\"/sbin\" -DUSRSBINDIR=\"/usr/sbin\" -DLOGDIR=\"/var/log\" 
> -DVARPATH=\"/var\" -DLOCALEDIR=\"/usr/share/locale\" -O1  -s  fdformat.c   -o 
> fdformat
> fdformat.c:17:22: error: linux/fd.h: No such file or directory
> fdformat.c: In function 'format_disk':
> fdformat.c:28: error: storage size of 'descr' isn't known
> fdformat.c:33: error: 'FDFMTBEG' undeclared (first use in this function)
> fdformat.c:33: error: (Each undeclared identifier is reported only once
> fdformat.c:33: error: for each function it appears in.)
> fdformat.c:34: error: invalid use of undefined type 'struct floppy_struct'
> fdformat.c:37: error: 'FDFMTTRK' undeclared (first use in this function)
> fdformat.c:42: error: invalid use of undefined type 'struct floppy_struct'
> fdformat.c:48: error: 'FDFMTEND' undeclared (first use in this function)
> fdformat.c:28: warning: unused variable 'descr'
> fdformat.c: In function 'verify_disk':
> fdformat.c:58: error: invalid use of undefined type 'struct floppy_struct'
> fdformat.c:58: error: invalid use of undefined type 'struct floppy_struct'
> fdformat.c:63: error: invalid use of undefined type 'struct floppy_struct'
> fdformat.c:78: error: 'FD_FILL_BYTE' undeclared (first use in this function)
> fdformat.c: In function 'main':
> fdformat.c:139: error: 'FDGETPRM' undeclared (first use in this function)
> fdformat.c:142: error: invalid use of undefined type 'struct floppy_struct'
> fdformat.c:143: error: invalid use of undefined type 'struct floppy_struct'
> fdformat.c:143: error: invalid use of undefined type 'struct floppy_struct'
> fdformat.c:143: error: invalid use of undefined type 'struct floppy_struct'
> make[1]: *** [fdformat] Error 1
> make[1]: Leaving directory `/home/kibi/z/util-linux-2.12r/disk-utils'
> make: *** [all] Error 1

So one has to tweak a little more to get this package compile.

Oh, debian/rules is now using a mixture of DEB_HOST_GNU_* and DEB_HOST_ARCH_*,
which might be polished, I guess, although I didn't want to be too intrusive
and probably insert some errors in there, so I tried to keep on only refreshing
the existing patch.

Cheers,

-- 
Cyril Brulebois

PS: Attached are the original patch, the refreshed one, the disabled patch with
the off-by-one fix.
diff -ur util-linux-2.12p.old/debian/patches/00list util-linux-2.12p/debian/patches/00list
--- util-linux-2.12p.old/debian/patches/00list	2005-10-06 18:45:25.0 +0200
+++ util-linux-2.12p/debian/patches/00list	2005-10-06 19:47:00.0 +0200
@@ -1,4 +1,3 @@
-10agetty
 10cal-widechar
 10cfdisk
 10debian
diff -ur util-linux-2.12p.old/debian/rules util-linux-2.12p/debian/rules
--- util-linux-2.12p.old/debian/rules	2005-10-06 18:45:25.0 +0200
+++ util-linux-2.12p/debian/rules	2005-10-06 19:52:35.0 +0200
@@ -25,7 +25,7 @@
 sparc = $(findstring $(arch),sparc)
 nohwclock = $(findstring $(arch),s390)
 
-SUBDIRS=po lib getopt disk-utils login-utils misc-utils mount sys-utils text-utils
+SUBDIRS=po lib getopt disk-utils login-utils misc-utils sys-utils text-utils
 ifeq ($(arch),$(fdisk_arch))
 SUBDIRS += fdisk
 endif
@@ -36,6 +36,7 @@
 ifneq ($(arch),$(nohwclock))
 SUBDIRS += hwclock 
 endif
+SUBDIRS += mount
 endif
 
 ifneq ($(DEB_HOST_GNU_SYSTEM),linux-gnu)
@@ -68,9 +69,12 @@
 
 SUIDFILES = debian/tmp-mount/bin/{u,}mount
 BINFILES  = sys-utils/arch text-utils/more
-UBINFILES = sys-utils/{ipcs,ipcrm,setsid} \
-	misc-utils/{namei,setterm,mcookie,whereis,ddate} \
+UBINFILES = sys-utils/{ipcrm,setsid} \
+	misc-utils/{namei,mcookie,whereis,ddate} \
 	getopt/getopt text-utils/{rev,line,pg}
+ifeq ($(DEB_HOST_GNU_SYSTEM),linux-gnu)
+UBINFILES += sys-utils/ipcs misc-utils/setterm
+endif
 SBINFILES = disk-utils/mkswap
 
 ifeq ($(DEB_HOST_GNU_SYSTEM),linux-gnu)
@@ -79,11 +83,15 @@
 SBINFILES += hwclock/hwclock
 endif
 BINFILES  += sys-utils/dmesg
-SBINFILES += disk-utils/{blockdev,raw} mount/pivot_root login-utils/agetty
+SBINFILES += disk-utils/{blockdev,raw} mount/pivot_root
 UBINFILES += disk-utils/fdformat
 USBINFILES = sys-utils/readprofile disk-utils/elvtune # disk-utils/setfdprm
 endif
 
+ifneq ($(DEB_HOST_GNU_SYSTEM),gnu)
+SBINFILES += login-utils/agetty
+endif
+
 UBINFILES2= misc-utils/chkdupex

Bug triaging, bug statuses

[Cyril Brulebois]

Hi again,

tonight I did some bug triaging in the kfreebsd-tagged bugs, adding
"patch" where needed (after having checked the success of the builds
once the patches applied), adjusting severities too, also asking the
submitter (often Aurelien, Petr) to update the patches or to have a
deeper look because of insuffient patches.

I also let voluntarily the kde-like bugs untouched, because of the
kdoomsday problem we're encountering on some architectures (an autoconf
is triggered on some of them, leading to FTBFS since auto* are not in
B-D, for reasons that I don't understand...). Having already a broken
NMU (with a package needing changes in admin/*) is enough, so I'll have
a look at them once I'm done with kdoomsday.

I've also ping'd on some bugs, and prepared (or going to prepare) some
easy NMUs, for package a bit abandoned by their maintainers (they might
be porter NMUs or QA uploads, I'll talk with the QA team before).

Please find attached a diff of the summary of the kfreebsd bugs page, as
a status update. ;-)

Cheers,

-- 
Cyril Brulebois
--- before	2007-03-31 02:27:21.0 +0200
+++ after	2007-03-31 02:28:32.0 +0200
@@ -1,10 +1,10 @@
 * Outstanding bugs -- Serious policy violations; Patch Available (2 bugs)
 * Outstanding bugs -- Serious policy violations; Unclassified (1 bug)
-* Outstanding bugs -- Important bugs; Patch Available (176 bugs)
-* Outstanding bugs -- Important bugs; Unclassified (42 bugs)
-* Outstanding bugs -- Normal bugs; Patch Available (4 bugs)
+* Outstanding bugs -- Important bugs; Patch Available (211 bugs)
+* Outstanding bugs -- Important bugs; Unclassified (18 bugs)
+* Outstanding bugs -- Normal bugs; Patch Available (2 bugs)
 * Outstanding bugs -- Normal bugs; Confirmed (1 bug)
-* Outstanding bugs -- Normal bugs; Unclassified (11 bugs)
+* Outstanding bugs -- Normal bugs; Unclassified (2 bugs)
 * Outstanding bugs -- Minor bugs; Patch Available (1 bug)
 * Outstanding bugs -- Wishlist items; Patch Available (7 bugs)
 * Outstanding bugs -- Wishlist items; Unclassified (12 bugs)


pgpe4PH4uCabD.pgp
Description: PGP signature

Netconf [was: Debian vs. Hurd init scripts: `/etc/rcS.d']

[Cyril Brulebois]

Pierre THIERRY <[EMAIL PROTECTED]> (05/04/2007):
> There is an ongoing effort to replace the rotting ifupdown package
> that deals with Debian's network interfaces:
> 
> http://wiki.debian.org/netconf/

Thanks for bringing this (back) to our attention.

> Maybe some Hurd and kFreBSD developers should take contact with
> madduck, as he's still in the design phase, and it would be great if
> this new system is flexible enough to work seamlessly with the ports
> that don't use Linux.

You could have Cc'd [EMAIL PROTECTED], but message received anyway. ;-)
I added a wishlist item asking for flexibility/modularity so that
non-Linux kernels can be handle too.

Thanks again,

-- 
Cyril Brulebois


pgpPSiZBBDzbp.pgp
Description: PGP signature

Re: Netconf [was: Debian vs. Hurd init scripts: `/etc/rcS.d']

[Cyril Brulebois]

martin f krafft <[EMAIL PROTECTED]> (05/04/2007):
> Could I get some of you net-config-savvy people to sign up to the
> mailing list:
> 
>   http://lists.alioth.debian.org/mailman/listinfo/netconf-devel

I just did.

> Also, I intend to use iproute for most everything. iproute should work
> fine on Hurd and BSD, right? So it's basically stuff like Netlink
> sockets, which are Linux-specific, and where I have to be
> cross-platform compatible through modularity, right?

AFAICT from the apt-cache results on both platforms, as well as from
<http://experimental.ftbfs.de/build.php?pkg=iproute>, iproute isn't
available either on GNU/kFreeBSD or on GNU/Hurd, unfortunately.

At least, on GNU/kFreeBSD, we have net-tools with the following content:
> [...]
> /usr/sbin
> /usr/sbin/authpf
> /sbin
> /sbin/ifconfig
> /sbin/route
> /sbin/pfctl
> /lib
> /lib/freebsd
> /lib/freebsd/route
should it be of some help.

I'm quite new to GNU/kFreeBSD, so I don't know (yet) much about
low-level things, but willing to learn and help if I can.

Cheers,

-- 
Cyril Brulebois


pgpeaoVPY00U6.pgp
Description: PGP signature

Re: Installing GNOME

[Cyril Brulebois]

Jerome Warnier <[EMAIL PROTECTED]> (13/05/2007):
> The first one is that I cannot get to install GNOME. Several
> unsolvable dependencies are making it impossible, while it works in
> GNU/Linux Sid.  How should I report this, and how could I help solving
> it?

You can report them there, but also check the status of the packages on
the buildds (e.g. through http://experimental.ftbfs.de/), check which
packages they depend on, why they are not built, why the builds fail,
etc.

Thanks for your help,

-- 
Cyril Brulebois


pgpLLHPvpyON1.pgp
Description: PGP signature

Fwd: Release Team Meeting results (the Juelich Edition)

[Cyril Brulebois]

Hi list,

please find attached a mail sent to debian-devel-announce@, some hours
ago, also available on the web archives[1].

 1. http://lists.debian.org/debian-devel-announce/2007/06/msg5.html

Cheers,

-- 
Cyril Brulebois
--- Begin Message ---
Hi,

after the release is prior to the release. As we all know that, the
Release Team members (except Steve) have met in Juelich recently to
discuss our impressions of the Etch release cycle and kick-off the Lenny
cycle.



Release team structure
~~
Steve Langasek, who served as Release Manager for the past two cycles,
doesn't want to be on the hot seat anymore. As he is still an active member
of the release team, we decided to have him titled with "Release Wizard"
now. Luk will become a Release Manager, so that we have again two
Release Managers.

Also, we decided to have the release teams be working even more closely
together. This means that Martin Zobel-Helas, who has helped out quite a
bit in the final leg of the Etch cycle, is now also officially a Release
Assistant, and Luk Claes, who is already working on the Stable Updates for
some time, is now also officially in that role.

Like after Sarge's release, we would like to get now some more people into
the release teams - just wait for a bit of time, we will send out an
explicit call about that rather soon.



Review of the Etch release cycle

We tried to work out what we liked about the Etch release cycle and
what we felt to be a problem. There are lot of items, so here's the
list:

 * Release Goals seemed to work quite well. We want to formalize
   this approach a bit for Lenny, see below for more information
   about that.

 * The linux kernel was a source of some delays for Etch. This was
   due to an unexpected high number of (critical) bugs and the
   problems around Debian's handling firmware images in the kernel.
   To solve this better next time, we want to start looking at the kernel
   earlier in the cycle and talking with the kernel team(s) more often.

 * The release notes (and upgrade tests) made fewer problems than for
   Sarge, but the work on them started too late, which lead to great
   pressure on the translators and left only very short time for an actual
   review. For Lenny, we want to improve the translation part by using
   po4a and again simply start earlier on writing the notes.

 * Quality Assurance (QA) checks on the archive were started very late in
   the cycle. They were very useful, but the timing was very unfortunate.
   We want to encourage all interested parties to start their QA checks as
   early as possible and will try to support those by making them a release
   goal. Regular rebuilds, upgrade tests for standard configurations and
   similiar checks improve Debian's quality!

 * The buildds performed a lot better than for Sarge. While the upload
   peaks prior to the Sarge freeze completly stucked the build daemons, we
   only had very small problems for Etch.  Of course, there is still
   something left to improve, but we also want to say "Thanks" for the
   things that worked quite well.

 * Automatic bin-NMUs have been of great use to shorten transitions. As
   most packages are now bin-NMUable, we will make further use of this
   tool for Lenny.

 * Udeb handling in britney still is non-existant. This is a technica
   problem that we want to solve for Lenny.

 * Version tracking in the BTS was a great improvement relative to Sarge.
   For the first time, we could actually see which packages in testing were
   buggy and did not need to resort to manual intervention and bug tags. We
   want to improve our tools to use the new BTS features (including also
   user-tags) to better track the progress of release goals and blockers.

 * The number of rc-bugs has been a big problem in the Etch cycle - it got
   out of control very early and it took a long time to get down to a
   reasonable number before the release. We are seeing the same effect for
   Lenny right now, but this time, we want to support an early BSP
   marathon to solve those bugs that were filed due to new QA measures.

 * 0-day-NMUs and the BSP marathon at the end of the release cycle helped
   a lot to bring down the number of bugs, and we will reuse this policy.

 * The freeze worked a lot better than for Sarge, both because it was
   shorter and there was more manpower to work on unblock requests. We
   hope that with even better planning will shorten the freeze time for
   Lenny again.
 
 * Final QA on the installation media and pushing them to the mirror
   network made less problems than for Sarge, but we are still unhappy
   with the time-constraints that make final tests so hard.

Please comment on these issues if you feel that important bits have been
missed, misrepresented or misjudged - and of course the release team only
sees one part of the full picture.


Release policy, blockers and goals
~

Re: Any chance for a more reliable mirror?

[Cyril Brulebois]

Frank Lichtenheld <[EMAIL PROTECTED]> (21/06/2007):
> Does anyone know why? Are there other mirrors available?
> Do you need more mirrors?

Hi Frank,

in short words: we are aware of (multiple) gnuab failures these times,
and we were thinking about using other mirror(s) and queue for kfreebsd.
I guess that Aurelien Jarno will tell you more in some moments.

Thanks,

-- 
Cyril Brulebois


pgplxdxvsS2jd.pgp
Description: PGP signature

Re: qa uploadable packages with kfreebsd bugs submission

[Cyril Brulebois]

Petr Salinger <[EMAIL PROTECTED]> (30/06/2007):
> Hi,

Hello,

> please, could some DD upload fixes for packages listed bellow, they
> are currently uploadable by Debian QA Group <[EMAIL PROTECTED]>.

I'll prepare the uploads in the next days, and will probably coordinate
with Aurelien for the sponsoring.

Thanks for spotting this.

Cheers,

-- 
Cyril Brulebois


pgpbK2maunrJU.pgp
Description: PGP signature

Re: qa uploadable packages with kfreebsd bugs submission

[Cyril Brulebois]

Petr Salinger <[EMAIL PROTECTED]> (30/06/2007):
> # #414082: gtktalog: FTBFS on GNU/kFreeBSD: needed OS DETECTION

My patch seems to be no longer applicable, I'll have a look a bit later.

> # #414133: plotmtv: FTBFS on GNU/kFreeBSD: changing your hack is needed
> # #415593: wmmemload: FTBFS on GNU/kFreeBSD: missing OS detection
> # #415597: wmmemmon: FTBFS on GNU/kFreeBSD: missing OS detection

Debdiff ready at [1], Aurelien Cc'd (just to be sure he doesn't miss
this mail).

 1. http://users.alioth.debian.org/~kibi-guest/

> #413856: axel: FTBFS on GNU/kFreeBSD: unknown platform (yet)
> #414335: datefudge: FTBFS on GNU/kFreeBSD: tiny tweak needed

MIA maintainers? From the source's debian/control:
Maintainer: Wilmer van der Gaast <[EMAIL PROTECTED]>
Maintainer: Matthias Urlichs <[EMAIL PROTECTED]>

I'll wait for a reply from you before trying to figure out myself and/or
asking the QA team whether a QA upload/orphan is OK.

Cheers,

-- 
Cyril Brulebois


pgpFLdHtXBku0.pgp
Description: PGP signature

Re: qa uploadable packages with kfreebsd bugs submission

[Cyril Brulebois]

Petr Salinger <[EMAIL PROTECTED]> (06/07/2007):
> Both are already orphaned - see #419679 and #429467.

Woops, looks like I wasn't paying attention enough. Thanks.

-- 
Cyril


pgpiLa3rfV7vj.pgp
Description: PGP signature

Re: qa uploadable packages with kfreebsd bugs submission

[Cyril Brulebois]

Petr Salinger <[EMAIL PROTECTED]> (30/06/2007):
> # #414082: gtktalog: FTBFS on GNU/kFreeBSD: needed OS DETECTION
Uploaded, but build failed because of the B-D.

> # #414133: plotmtv: FTBFS on GNU/kFreeBSD: changing your hack is needed
> # #415593: wmmemload: FTBFS on GNU/kFreeBSD: missing OS detection
> # #415597: wmmemmon: FTBFS on GNU/kFreeBSD: missing OS detection
> # #413856: axel: FTBFS on GNU/kFreeBSD: unknown platform (yet)
Uploaded and built everywhere.

> #414335: datefudge: FTBFS on GNU/kFreeBSD: tiny tweak needed
Uploaded by Matej, built too.

Cheers,

-- 
Cyril Brulebois


pgpvvC5jbHwKy.pgp
Description: PGP signature

Re: Successful jailed GNU/kFreeBSD

[Cyril Brulebois]

Joshua Cummings <[EMAIL PROTECTED]> (15/07/2007):
> Any ideas/thoughts/comments from anyone?

Just one request: Feel free to post any documentation on the Debian
Wiki[1] so that we keep track of such documentation. ;-)

 1. http://wiki.debian.org/Debian_GNU/kFreeBSD et al.

Thanks,

-- 
Cyril Brulebois


pgpyyzdx6Sekw.pgp
Description: PGP signature

debootstrap on GNU/kFreeBSD! \o/

[Cyril Brulebois]

Hi all!

After some patching, that I related a bit in[1], and now after some
cleanup, I came to a functional debootstrap on GNU/kFreeBSD -- but since
it may be of some interest to Hurd people, Cc'ing debian-hurd.

One has to precalculate some dependencies before, in an kfreebsd
environment using unstable+unreleased in apt, although the helper script
could be changed to use grep-dctrl only, so that only downloading two
appropriate files from the mirror would be sufficient.

The options I added to debootstrap are:
  --extra-include="foo bar baz"
The additional packages calculated with the helper script have to be
put there.
  --extra-suite unreleased
Can also be e.g. experimental, it has been tested successfully on a
Linux installation, adding the "seam" package.
  --extra-mirror http://your.mirror/debian
In case it is a different mirror from the one for unstable (or
whatever suite you are installing).

Now, even sources.list is created correctly; /dev isn't perfect yet, but
that should be solved outside of debootstrap, according to what I've
been told on #gnu-kbsd.

You'll find all needed file at [2] (you probably want the final diff,
and the tiny shell script with the appropriate parameters). I should
have documented correctly in the tiny shell script how to call the
helper script to calculate the dependencies.

A git tree is available as well at [3], containing my successions of
patches, starting at the current latest debootstrap (1.0.1).

Oh and I almost forgot to mention that you don't have to rebuild and
install the whole source package, apt-get source'ing it, applying the
patch, and running it with all needed parameters (that is: mirror
location and script path, the last one being needed when debootstrap is
run using ./debootstrap).

 1. http://ikibiki.org/blog/2007/08/04/Debootstrap_on_GNU_kFreeBSD/
 2. http://users.alioth.debian.org/~kibi-guest/kfreebsd/
 3. git://alioth.debian.org/~kibi-guest/debootstrap.git

Please also note that I checked several times that debootstrap wasn't
broken on Linux, although only the "release" mode was tested, but not
the "main" one. If you find any regression, please tell me ASAP so that
I can fix it.

Any comment, diff, etc., and feedback is very welcome.

Cheers,

-- 
Cyril Brulebois


pgpkLQxg1btPE.pgp
Description: PGP signature

Re: Porter help needed to build latest upstream PAM

[Cyril Brulebois]

Roger Leigh <[EMAIL PROTECTED]> (05/08/2007):
> The same considerations may also apply to the FreeBSD ports.  It
> might just build, but it might need some tweaking.

Hi Roger,

thanks for the notice. And indeed there is some work needed, see the
attached build log (in an uptodate kfreebsd-i386 chroot). I'll have a
look at this soon and get back to you, don't hesitate to poke me (KiBi)
on IRC in some days.

Cheers,

-- 
Cyril Brulebois


pam_0.99.7.1-1_kfreebsd-i386.build.bz2
Description: Binary data


pgpO7IiugD9ym.pgp
Description: PGP signature

Re: debootstrap on GNU/kFreeBSD! \o/

[Cyril Brulebois]

Cyril Brulebois <[EMAIL PROTECTED]> (05/08/2007):
>  1. http://ikibiki.org/blog/2007/08/04/Debootstrap_on_GNU_kFreeBSD/
>  2. http://users.alioth.debian.org/~kibi-guest/kfreebsd/
>  3. git://alioth.debian.org/~kibi-guest/debootstrap.git

I dropped a tiny patch in [2] to avoid component duplication (that is:
"main main" in sources.list), although it is quite harmless. From now
on, I encourage everyone to always have a look at the git tree, since I
won't spam here any time I modify something. The ``final diff'' was
mainly to give an overview of the patch.

Some notes:
 - after installation, we have the following:
| The following packages have unmet dependencies:
|   libgeom0: Depends: libexpat1 (>= 1.95.8) but it is not going to be installed
|   module-init-tools: Depends: kfreebsd-image
|   ufsutils: Depends: libedit2 (>= 2.5.cvs.20010821-1) but it is not going to 
be installed
| E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify 
a solution).
   and indeed, ``apt-get -f install'' fixes the problem, so that's not
   really a problem.

Why these problems? kfreebsd-image is a virtual package, that my
helper script can't handle. The other missing packages are
dependencies from unreleased to unstable, which I didn't consider in
my helper script yet, but I could add this feature. The fact is that
most unstable dependencies of unreleased packages are already
base/required packages, so it goes mostly OK. I could add some
checks on these unstable dependencies so as to list the non
base/required ones, and output them; then they could be added to the
normal debootstrap --include option. (I'll probably do this when
I'm rewritting the helper script to use grep-dctrl.)

 - until the /dev generation is OK, you'll have to fix the permissions
   on /dev/null. There's also no /dev/u?random, which is uncool for
   crypto-related stuff (e.g. ssh-client).

 - when ``playing'' with initscripts, I triggered by accident the
   shutdown, but the whole machine went down, so: beware.

Cheers,

-- 
Cyril Brulebois


pgplWrHcKNhs5.pgp
Description: PGP signature

Re: Porter help needed to build latest upstream PAM

[Cyril Brulebois]

Roger Leigh <[EMAIL PROTECTED]> (05/08/2007):
> The same considerations may also apply to the FreeBSD ports.  It might
> just build, but it might need some tweaking.

Hi again.

As discussed on IRC, the #error thing is quite strange. Either use
#warning (used in my patch) or use some autotools magic to disable this
file when not building on/for Linux.

Another file contains a Linux-only syscall: setfsuid(). I might be
mistaken, but every page I came across mentions it is Linux-only, and
I didn't find any Unix-wide replacement. I guess I'll be corrected by
another list subscriber if I'm wrong.

Instead of putting #ifdef/#endif everywhere in this file, I defined a
no-op when not on Linux. I guess that putting an autotools check for
this function could be a good idea.

At last, some files are not available after the install step, I
commented them out in the install file. I believe you could handle them
by dh_installing them conditionally from your debian/rules, depending on
DEB_HOST_ARCH_OS being or not ``linux'', if it turns out that GNU/Hurd
is lacking the same files.

I attached both the patch and the build log once it is applied. I didn't
do any runtime check, but I'll be pleased to do so if you describe what
you want me to try.

Cheers,

-- 
Cyril Brulebois
diff -urN pam-0.99.7.1~/Linux-PAM/modules/pam_limits/pam_limits.c pam-0.99.7.1/Linux-PAM/modules/pam_limits/pam_limits.c
--- pam-0.99.7.1~/Linux-PAM/modules/pam_limits/pam_limits.c	2007-08-06 08:58:06.0 +
+++ pam-0.99.7.1/Linux-PAM/modules/pam_limits/pam_limits.c	2007-08-06 09:02:19.0 +
@@ -14,7 +14,7 @@
  */
 
 #if !defined(linux) && !defined(__linux)
-#error THIS CODE IS KNOWN TO WORK ONLY ON LINUX !!!
+#warning THIS CODE IS KNOWN TO WORK ONLY ON LINUX !!!
 #endif
 
 #include "config.h"
diff -urN pam-0.99.7.1~/Linux-PAM/modules/pam_xauth/pam_xauth.c pam-0.99.7.1/Linux-PAM/modules/pam_xauth/pam_xauth.c
--- pam-0.99.7.1~/Linux-PAM/modules/pam_xauth/pam_xauth.c	2007-08-06 08:58:06.0 +
+++ pam-0.99.7.1/Linux-PAM/modules/pam_xauth/pam_xauth.c	2007-08-06 09:32:16.0 +
@@ -35,7 +35,12 @@
 
 #include "config.h"
 #include 
-#include 
+#ifdef __linux__
+#  include 
+#else
+#  /* no-op */
+#  define setfsuid(X) do {} while (0)
+#endif
 #include 
 #include 
 #include 
diff -urN pam-0.99.7.1~/debian/libpam-modules.install pam-0.99.7.1/debian/libpam-modules.install
--- pam-0.99.7.1~/debian/libpam-modules.install	2007-08-06 08:58:07.0 +
+++ pam-0.99.7.1/debian/libpam-modules.install	2007-08-06 09:27:47.0 +
@@ -1,8 +1,8 @@
 debian/install/etc/security/access.conf			etc/security
 debian/install/etc/security/group.conf			etc/security
 debian/install/etc/security/limits.conf			etc/security
-debian/install/etc/security/namespace.conf		etc/security
-debian/install/etc/security/namespace.init		etc/security
+#debian/install/etc/security/namespace.conf		etc/security
+#debian/install/etc/security/namespace.init		etc/security
 debian/install/etc/security/pam_env.conf		etc/security
 debian/install/etc/security/time.conf			etc/security
 debian/install/lib/security/*.so			lib/security
@@ -12,7 +12,7 @@
 debian/install/usr/share/man/man5/access.conf.5		usr/share/man/man5
 debian/install/usr/share/man/man5/group.conf.5		usr/share/man/man5
 debian/install/usr/share/man/man5/limits.conf.5		usr/share/man/man5
-debian/install/usr/share/man/man5/namespace.conf.5	usr/share/man/man5
+#debian/install/usr/share/man/man5/namespace.conf.5	usr/share/man/man5
 debian/install/usr/share/man/man5/pam_env.conf.5	usr/share/man/man5
 debian/install/usr/share/man/man5/time.conf.5		usr/share/man/man5
 debian/install/usr/share/man/man8/pam_access.8		usr/share/man/man8
@@ -26,7 +26,7 @@
 debian/install/usr/share/man/man8/pam_ftp.8		usr/share/man/man8
 debian/install/usr/share/man/man8/pam_group.8		usr/share/man/man8
 debian/install/usr/share/man/man8/pam_issue.8		usr/share/man/man8
-debian/install/usr/share/man/man8/pam_keyinit.8		usr/share/man/man8
+#debian/install/usr/share/man/man8/pam_keyinit.8		usr/share/man/man8
 debian/install/usr/share/man/man8/pam_lastlog.8		usr/share/man/man8
 debian/install/usr/share/man/man8/pam_limits.8		usr/share/man/man8
 debian/install/usr/share/man/man8/pam_listfile.8	usr/share/man/man8
@@ -35,13 +35,13 @@
 debian/install/usr/share/man/man8/pam_mail.8		usr/share/man/man8
 debian/install/usr/share/man/man8/pam_mkhomedir.8	usr/share/man/man8
 debian/install/usr/share/man/man8/pam_motd.8		usr/share/man/man8
-debian/install/usr/share/man/man8/pam_namespace.8	usr/share/man/man8
+#debian/install/usr/share/man/man8/pam_namespace.8	usr/share/man/man8
 debian/install/usr/share/man/man8/pam_nologin.8		usr/share/man/man8
 debian/install/usr/share/man/man8/pam_permit.8		usr/share/man/man8
 debian/install/usr/share/man/man8/pam_rhosts.8		usr/share/man/man8
 debian/install/usr/share/man/man8/pam_rootok.8		usr/share/man/man8
 debian/instal