Re: Bug#674541: ruby1.8: segfaults when compiled with gcc-4.7
On Sun, May 27, 2012 at 11:11:10PM +0100, Steven Chamberlain wrote: > I discovered other segfaults during 'test all'. An small, easily > reproducible testcase is test/io/nonblock/test_flush.rb, which is fixed > by compiling with the -fno-tree-dce compiler option. ruby-ffi's spec/ffi/function_spec.rb test also fails every time when ruby1.8 was built using gcc-4.7 without -fno-tree-dce, but is fixed by adding -fno-tree-dce when building ruby1.8. Just in case that helps anyone ... -- Colin Watson [cjwat...@ubuntu.com] -- 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/20130319123155.ga22...@riva.ucam.org
Re: pu: package grub2/1.99-27.1+deb7u1
On Fri, Jun 28, 2013 at 01:09:20AM +0200, Robert Millan wrote: > Version of grub currently in wheezy could break bootability when > kernel is upgraded to 9.1. This will become specially relevant for > upgrade path when jessie is released. > > See bug #699002 for details. > > There's a very simple fix, cherry-picked from upstream. Ack from me FWIW. -- Colin Watson [cjwat...@debian.org] -- 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/20130628050218.gp1...@riva.ucam.org
Re: d-i-n-i: #695500 is apparently a grub-mkimage (or debian-installer) bug
On Sun, Oct 13, 2013 at 10:27:27PM +0200, Didier 'OdyX' Raboud wrote: > I spent some more time debugging this RC bug by setting up my server and > testing the PXE boot of kfreebsd-i386 on two different laptops; the > results are: > > * the "error: prefix is not set" error always appears when using the > wheezy grub2pxe; it also happens with the current sid grub2pxe [0]; > * the resistance to this error apparently depends on the PXE > implementation: > - my "acer Aspire One" displays the error and then proceeds to > displaying grub, then allowing the boot of the kfreebsd-i386 > installer; > - my "ThinkPad X220" displays the error and stops; > - kvm launched locally with [1] proceeds to grub; > > [0] > http://http.debian.net/debian/dists/sid/main/installer-kfreebsd-i386/20130430/images/netboot/grub2pxe > [1] kvm -m 256 -net nic -net - > user,bootfile=/grub2pxe,tftp=/usr/lib/debian-installer/images/7.0/kfreebsd-amd64/gtk/ > > As debian-installer-netboot-images is only copying these files from the > mirrors, I don't think it is the correct source package to track this > bug. The above tests now make me think that this is either a problem of > debian-installer calling grub-mkimage wrongly in > build/config/kfreebsd.cfg or a bug in grub-mkimage not incorporating the > prefix correctly when creating a PXE image. I was staring at this bug for the nth time, and noticed something. debian-installer is calling grub-mkimage with the "i386-pc" image type when building netboot images, the same way as it does when building CD images. This is very probably wrong; it should be using "i386-pc-pxe" instead. The difference between these image types is that i386-pc prefixes the image with diskboot.img, while i386-pc-pxe prefixes the image with pxeboot.img. The former tries to read core.img off the local hard disk, while the latter assumes that it's already been read into memory and just jumps to it. It is absolutely wrong to use i386-pc for an image that isn't installed to a local disk. I suspect that the reason everyone is terribly confused about reproducing this is that it will depend on what you happen to have installed on your local disk, as well as what KVM's PXE environment happens to provide as the drive reference. Could you try this patch and see if it helps? I'm betting that it will at least be much closer to functional. diff --git a/build/config/hurd.cfg b/build/config/hurd.cfg index 21091fc..a40a977 100644 --- a/build/config/hurd.cfg +++ b/build/config/hurd.cfg @@ -114,7 +114,7 @@ arch_netboot_dir: fi # Generate grub2pxe - grub-mkimage -O i386-pc --prefix="(pxe)/$(NETBOOT_PATH)" \ + grub-mkimage -O i386-pc-pxe --prefix="(pxe)/$(NETBOOT_PATH)" \ -o $(TEMP_NETBOOT_DIR)/core.img \ $(GRUB_MODULES) $(GRUB_MODULES_PXE) # workaround a gPXE bug diff --git a/build/config/kfreebsd.cfg b/build/config/kfreebsd.cfg index 080111a..1b05133 100644 --- a/build/config/kfreebsd.cfg +++ b/build/config/kfreebsd.cfg @@ -137,7 +137,7 @@ arch_netboot_dir: fi # Generate grub2pxe - grub-mkimage -O i386-pc --prefix="(pxe)/$(NETBOOT_PATH)" \ + grub-mkimage -O i386-pc-pxe --prefix="(pxe)/$(NETBOOT_PATH)" \ -o $(TEMP_NETBOOT_DIR)/core.img \ $(GRUB_MODULES) $(GRUB_MODULES_PXE) # workaround a gPXE bug Thanks, -- Colin Watson [cjwat...@debian.org] -- 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/20131206134112.gl16...@riva.ucam.org
Accepted partman-zfs 35 (source kfreebsd-i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 21 Jul 2014 15:26:37 +0100 Source: partman-zfs Binary: partman-zfs Architecture: source kfreebsd-i386 Version: 35 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Colin Watson Description: partman-zfs - Add to partman support for ZFS (udeb) Changes: partman-zfs (35) unstable; urgency=medium . * Remove pre-wheezy dependency on libparted0-udeb, which is no longer needed; this will become libparted2-udeb with parted 3.1. Checksums-Sha1: 0486482330ba2cf04e93d88e845069b9fb18419a 1694 partman-zfs_35.dsc 6969d85971db61aa911f562cbf9e1f3bee982e63 258984 partman-zfs_35.tar.xz 34b53e44f96196c3956ea1a467afc6f07c28cd94 330418 partman-zfs_35_kfreebsd-i386.udeb Checksums-Sha256: e415aa7a88fe94ab858d64da6cf3aad154f50b25e79018f8a197c69dfa0efcff 1694 partman-zfs_35.dsc 017b6b941e60bc318f80f29b4ad98456b38cc9d1f7ce195d3aec81ab80c5a638 258984 partman-zfs_35.tar.xz 1049dbad2226e5f05ab9a2646f7ac6546ff88978f75c19289eeb86a8397c4ea0 330418 partman-zfs_35_kfreebsd-i386.udeb Files: 911fb52eb1864b135e18dfdf00c219da 1694 debian-installer standard partman-zfs_35.dsc 3aff9bf61737f3cd0bff831ba238c13b 258984 debian-installer standard partman-zfs_35.tar.xz d3b5b3b853a0e90aa1e952aa00f8077b 330418 debian-installer standard partman-zfs_35_kfreebsd-i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Colin Watson -- Debian developer iQIVAwUBU80kGDk1h9l9hlALAQhe3Q/+JBtStuPO15ZruMm6twu/ln8JikBuhNEv CyjHS4iQW0NBeE5ykggab5RrgtFucVdZhhVFbpcg4+2lhyu4rY0ECX9Ec34kqFRY A9TlrVrgz6h8FJqVOVHJmHvU90PVMIAxzHf8yqrmqzULeHeVrEcEO/ACnSw4ZyXD t44fcyApZRbAqrJ2eQdyzfrlHZvI13BEwa0+VyKPsg9fsOtLai6H3bvL4Pj2Rihl Opdt1qaWQsyVGFV00VTFDx2PFgbVPx4/n55zJSgQ1mcqpqV5NiPDWZG8pzMG5TAr glo2uXctVMBzbvbb+9TzONb7ZTSxiJyFOqRbXV1fcX8I3IKs6xXTP1+HvU5RXy9v dafsIxiJPbrwVldKmV3JISVdZVvGZDRxPxF0g+TELWITDwC/0auQd3LVHrgNFm8v Zodbz+bFWHrobleP44lA5rLwvpCu6YWJEWmuzvzNmnI4DdSmQjlEtKE711pK70+d WiHRLGv9lYyZD52eJWi1I+FLK/xoRfWMf9jABPZgZ0RKlcyYCmJHU4RF2fTs0V2J 8r+5buzbYt7JG2j8aKW9Q9gVMriMym84Nb88c831UY5Xf1et739ZeBAm8TXdC/3/ CA+8rBQBW5ybmSXAjnmGwtU/4xIYsnE6VE1gJQlFEBcppIkl8dbk78/feYp7ljyL wmkhI/EuPmU= =6M7s -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: https://lists.debian.org/e1x9fro-sv...@franck.debian.org
Accepted partman-zfs 36 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Aug 2014 19:43:47 +0100 Source: partman-zfs Binary: partman-zfs Architecture: source Version: 36 Distribution: unstable Urgency: high Maintainer: Debian Install System Team Changed-By: Colin Watson Description: partman-zfs - Add to partman support for ZFS (udeb) Closes: 757664 Changes: partman-zfs (36) unstable; urgency=high . * Cope with parted 3.2 automatically creating a partition when creating a fresh loop label (closes: #757664). Checksums-Sha1: 9a2d84eff9d7f96f69368f56cd4f7ddf68b010e4 1708 partman-zfs_36.dsc 4e253044650e30fc3458c7c868ce0a286e56bbd7 259228 partman-zfs_36.tar.xz Checksums-Sha256: aac7ed0b872371fc84a898fff6618fe4f17f66d768124fc0840bba1f8ab78c59 1708 partman-zfs_36.dsc 19efc465928912c02121d814da3f9ef859d4903acaf66f06e572edf1f4386b6e 259228 partman-zfs_36.tar.xz Files: 9b6f4ae35dc68c22f40b7b08ba906849 1708 debian-installer standard partman-zfs_36.dsc 3c6991dde158d069e518c96c641a9ded 259228 debian-installer standard partman-zfs_36.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Colin Watson -- Debian developer iQIVAwUBU+e9gzk1h9l9hlALAQiuXw//SosZfdLsjpR4sxa5vH1UDuZM4Hx/9iF6 VLKk0wwYueNNHwdxSrfKRyy26br7jBZeQWULRn53LxXGq6bZKBwS0PYgtI6jBxOY 1ps3nG63v2No9UH8p5bCruSuY8yxUKZc5yu5iNCr44ADboARkVKq54OkkLKEgIBk Zp9zhTFxFYGxjZEc0/KRgO91szmhrErdQQ9Ao6wcL6e2PEWnB91tMDsSKCmQzwrQ T9zOIZ8Tghqlnys92XfjymBpk8j/+SEaqVOlmwdHArShsUiw+5aydx9osigCL7km qGzUl4WPqpTslOl2ftVUsT0s/VZTu3dTqbXh8GSIJdrBmMBTaLs55zEJLDIIAaGt 9uChGxTBUJ5Luzn7NSILtfUzMfuW5Eu+Ap39VlXw9SkFFEWimTp/8uXlmKJ2pb+n gYN8D8oXA9YjZ8JgsbKR0iqw2EYiMz++S1KkK0VxwX5kx+7+cndn0/WkgRZrr0UM RBLtg5g2YH/czVSmgj3lLuJCTmTOdWQuLnWd7JowOcTPMurtSECdmf1b6jj1kFbY 7ued/jggH57WofiVCPsPIr/Jtzt7cbjPbTtICCNG1BIYM93YyjjBOaFMqrPfDg3D x9U6j67Ymr+E0gUDzWc3TFSM1X4BLtPMrUVqEHb4SybKQN6eJzjEx5jWS3BavP8/ /hh8sIfvYq4= =GDsC -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: https://lists.debian.org/e1xgyp6-0001md...@franck.debian.org
Re: Bug#757986: kfreebsd: multiple "inappropriate ioctl for device" prompts
On Fri, Sep 19, 2014 at 02:57:06PM +0100, Steven Chamberlain wrote: > I was able to review Jeff Epler's original patch for this issue, make > sure I properly understood it, clean it up and test it again in a full > d-i image. I can now happily sign off on this as a correct fix. > > I've attached it in the form of a commit for parted packaging Git. It > updates the existing kfreebsd-gnu.patch with Jeff's new code, and > refreshes the others. Thanks! Applied in spirit (i.e. git-dpm checkout-patched, git rebase -i upstream, edit kfreebsd-gnu.patch, applied the same delta, git rebase --continue, git-dpm update-patches, and amended that commit with the changelog). I'll upload shortly. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140919144539.gd5...@riva.ucam.org
Re: Bug#640334 ([kfreebsd] dash: faccessat implementation of "test -x" always returns true for user root) makes update-grub fail
On Mon, Sep 05, 2011 at 05:16:54AM +0200, Axel Beckert wrote: > I just ran into this issue with update-grub, too: > > [...] > /usr/sbin/grub-mkconfig: 291: /usr/sbin/grub-mkconfig: /etc/grub.d/README: > Permission denied > > There runs a "test -x /etc/grub.d/README" just before that problem > happens and /usr/sbin/grub-mkconfig is a /bin/sh script. > > This is related to https://bugs.launchpad.net/bugs/537123 (update-grub > fails if /etc/grub.d/README executable bit set) which seems to either > not fixed or showed up again as a regression (see comment #4). That > issue is also present in Debian Sid. It just showed up on kfreebsd > because of "test -x" failing to report executable bits properly. > > Colin: Yeah, that's how I stumbled upon the fact that LP: 537123 is > not fixed or has a regression. :-) Thanks for noticing this. I've fixed this in GRUB upstream and will backport to Debian and Ubuntu. -- Colin Watson [cjwat...@debian.org] -- 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/20110905125943.gc3...@riva.dynamic.greenend.org.uk
Bug#665997: closed by Guillem Jover (Bug#665997: fixed in libbsd 0.4.0-1)
reopen 665997
found 665997 libbsd/0.4.0-1
thanks
On Tue, May 29, 2012 at 07:06:30AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:libbsd package:
>
> #665997: libbsd uses wrong compiler when cross-building
>
> It has been closed by Guillem Jover .
[...]
> - Autoconfiscated, supports cross-building natively. (Closes: #665997)
This is nearly there, but not quite. You're not passing the required
--build and --host options to configure, so it doesn't know that it's
supposed to cross-compile. I've confirmed that the following patch
fixes it.
* Pass correct --build= and --host= options to configure.
diff -Nru libbsd-0.4.2/debian/rules libbsd-0.4.2/debian/rules
--- libbsd-0.4.2/debian/rules 2012-06-27 08:22:33.0 +0100
+++ libbsd-0.4.2/debian/rules 2012-11-22 02:06:32.0 +
@@ -9,6 +9,14 @@
CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)
LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS)
+DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
+
+confflags := --build=$(DEB_BUILD_GNU_TYPE)
+ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
+confflags += --host=$(DEB_HOST_GNU_TYPE)
+endif
+
lib := libbsd0
libdbg := $(lib)-dbg
@@ -24,7 +32,8 @@
LDFLAGS="$(LDFLAGS)" \
--disable-silent-rules \
--prefix=/usr \
- --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
+ --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
+ $(confflags)
build-indep:
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
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/20121122022010.ga28...@riva.dynamic.greenend.org.uk
Re: Bug#189425: openssh: with default config, sshd fails on kernels other than Linux > 2.0
On Thu, Apr 17, 2003 at 06:24:24PM +0200, Robert Millan wrote: > Package: openssh > Version: unavailable; reported 2003-04-17 > Severity: normal > > As noted in the debconf template: > > NB! If you are running a 2.0 series Linux kernel, then privilege > separation will not work at all, and your sshd will fail to start > unless you explicitly turn privilege separation off. > > I suggest that defaults are reverted for both when sshd_config needs > to be generated in postinst and when sshd_config is taken from the > packaged file, so that any kernel other than Linux later than 2.0 > gets a default config without priviledge separation. Now that we've gone to all the effort of introducing it, I do think that the default should be to enable privilege separation; the cases where it's a problem are exceptions (PAM is still a problem, but I think that's going to be improved upstream soon). We could turn it off for some specific known cases, though. If you could provide a reasonably reliable way to identify them then that would be helpful. However, if at all possible I'd prefer to fix privsep. > On the non-linux ports: note that priviledge separation is not supported > on GNU, and will probably never be, since it has a different concept of > user priviledges. I don't understand why. Privilege separation just requires a separate user and group which is used for processing network data, the ability for sshd running as root to setuid(), setgid(), and setgroups() to that user and group, and an empty chroot. I didn't think GNU was so different that this would be unavailable; in fact, I would expect all of these features to be available on any Debian system. The reason why privilege separation doesn't work on Linux 2.0 was originally due to the lack of anonymous memory mapping, and now that that has been worked around it's due to a simple bug (#150976). Could you please explain the problem on GNU in more detail? > I'm not sure about the *BSD ports. Since privilege separation was developed on BSD, it seems highly likely that the BSD ports will support it. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Fixed RC bug in frozen parted : #392767: [mac] parted is unable to reread partition tables created by d-i/partman.
On Tue, Nov 07, 2006 at 08:14:45PM +0100, Sven Luther wrote: > On Tue, Nov 07, 2006 at 08:08:26PM +0100, Robert Millan wrote: > > I'm sorry. Please feel free to disable the patch; I'm thinking it was not a > > good idea to apply it in the package before it was merged upstream (as it > > was > > about to, last time I visited this). > > > > Apologises for the hassle. > > No problem, i am happy we found it before the release though. > > Will you be able to work out a better/cleaner patch ? And work with us to > merge it upstream ? I filed a bug with the correct fix for this problem two months ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386973 I highly recommend applying that instead. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#430455: sshd in unstable not executable any longer, seems to be a shared library
reopen 430455 thanks On Tue, Jun 26, 2007 at 03:24:42PM +, Thorsten Glaser wrote: > close 430455 > thanks (a) Please don't use the 'close' command to close bugs; as http://www.debian.org/Bugs/server-control notes, this is a deprecated practice. (b) I've already changed my local tree to avoid building PIEs on anything other than Linux and NetBSD (note that I tagged this bug pending), so please leave this bug open until I upload that. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#430455: openssh PIEs, part II
On Wed, Jun 27, 2007 at 12:00:04AM +, Thorsten Glaser wrote: > As for the PIEs, kFreeBSD 6.x kernel has gained a patch to support > executing PIEs some time ago (since I only tested 5.4 and 7.0 I had > not known that, plus I'm not exactly a heavy Debian user...), and > they backported the fix to the 5.x kernel series (the 7.0 series are, > according to the developers, "experimental", and outdated). To be honest, since it isn't mandatory, I'd rather not have the support headache for a while. > So there is no need on your part to not build PIEs on kFreeBSD any > more. (I wonder what the benefit of a PIE is, do you happen to have > a pointer to some docs/manual on it? I know (now) in theory what a > PIE is, but don't see the point.) It lets us take advantage of address space layout randomisation to make stack-smashing attacks harder. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [gsoc2009] debian-installer on Debian GNU/kFreeBSD
On Thu, Mar 05, 2009 at 07:46:08PM +0200, Ross Cameron wrote: > Why not re-impliment the installer in a more OS neautral way (plugins for > different kernel/userland types) instead of porting it? > > That way it will look and feel and act (hopefully) the same as it currently > does, but now the code is future proof? Gunnar's description was not really very accurate, IMO. Much of d-i was already made reasonably OS-neutral by myself and others when we were thinking about Hurd support, even though we never actually got that working. It certainly already *does* have plugins for the sorts of things you're referring to; d-i is almost entirely plugins ... The hardest bit, by far, is figuring out how to boot the thing. :-) You need some way to boot with an initial filesystem entirely in RAM, and furthermore this initial filesystem needs to be writable (so you can't just use some local equivalent of a loop-mount of a filesystem from a CD; this is where it got notably tricky on the Hurd). If you can do that, everything else is likely to be a fairly trivial porting exercise. > On Thu, Mar 5, 2009 at 4:20 PM, Gunnar Wolf wrote: > > Please note I'm mostly a mildly-informed-newbie, both in FreeBSD and > > in d-i topics. Still, I've played with both. Your goal is very > > interesting and I can only hope for you to pursue and succeed in it - > > And do it in a generic way, which would allow for easily adapting to > > any other kernel. > > > > Still, from what I have seen, d-i uses throughout the system many > > Linux-specific constructs (I'm mostly looking at udev), and many d-i > > components assume Linux structures (i.e. setting up partitions with > > LVM, using GRUB or LILO as the bootloader, the supported filesystems, > > etc.) > > > > Still, if you are willing to dive deep into it... I know it will help > > greatly our project's support for other OSs. I don't think it's > > probable that -at least in early stages- you will get commit access to > > the d-i repository, and you won't want to be stuck in an old version > > (but that's easily fixable by many techniques). In any case, I cannot > > mentor you, but if you want somebody cheering along, count me in :) Martin Michlmayr persuaded me to tentatively volunteer for mentoring the addition of mtd support, but actually I'd be much more excited about mentoring this project if it had a good student. Martin, is it possible that somebody else could mentor mtd support? -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [gsoc2009] debian-installer on Debian GNU/kFreeBSD
On Mon, Mar 09, 2009 at 01:47:52PM -0300, Otavio Salvador wrote: > Martin Michlmayr writes: > > * Colin Watson [2009-03-09 00:01]: > >> Martin Michlmayr persuaded me to tentatively volunteer for mentoring > >> the addition of mtd support, but actually I'd be much more excited > >> about mentoring this project if it had a good student. Martin, is it > >> possible that somebody else could mentor mtd support? > > > > Maybe Riku would be interested, but I'm not sure how how low-devel > > knowledge of parted and partman is needed for the mtd project. (My > > lack of knowledge in this area is the reason I haven't volunteered as > > mentor for the mtd project.) > > For parted I belive it would be better to be done at parted's upstream > side. I belive that it should be easy to get that supported at parted > side. As far as I've been able to understand, it definitely requires additional work in d-i too. Perhaps parted would be an interesting project on its own, though, and since it's a dependency that could resolve the mentorship question. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [patch]Re: debootstrap on Debian GNU/kFreeBSD + questions
ined by handling $extra_debs until the end.
> +# Probably not needed, so merging $required and $extra_debs
> +required="$required $extra_debs"
The semantics here are messy (what if you wanted them to be installed in
debootstrap's second stage instead?) and are another indication that
--extra-include should be discarded.
> @@ -542,12 +591,16 @@
> rm -f "$TARGET/etc/apt/sources.list"
> fi
> if [ "${MIRRORS#http://}"; != "$MIRRORS" ]; then
> - setup_apt_sources "${MIRRORS%% *}"
> - mv_invalid_to "${MIRRORS%% *}"
> + setup_apt_sources $SUITE "${MIRRORS%% *}"
> + mv_invalid_to $SUITE "${MIRRORS%% *}"
> else
> - setup_apt_sources "$DEF_MIRROR"
> - mv_invalid_to "$DEF_MIRROR"
> + setup_apt_sources $SUITE "$DEF_MIRROR"
> + mv_invalid_to $SUITE "$DEF_MIRROR"
> fi
> + if [ "$EXTRA_SUITE" != "" ]; then
> + setup_apt_sources $EXTRA_SUITE $EXTRA_MIRROR
> + mv_invalid_to $EXTRA_SUITE $EXTRA_MIRROR
> + fi
>
> if [ -e "$TARGET/debootstrap/debootstrap.log" ]; then
> if [ "$KEEP_DEBOOTSTRAP_DIR" = true ]; then
Again, this should remember that it's iterating over mirror/suite pairs.
> Index: functions
> ===
> --- functions (revision 57816)
> +++ functions (working copy)
> @@ -374,12 +374,21 @@
>
> download () {
> mk_download_dirs
> - "$DOWNLOAD_DEBS" $(echo "$@" | tr ' ' '\n' | sort)
> + local suite="$1"
> + local mirrors="$2"
> + shift 2
> + "$DOWNLOAD_DEBS" "$suite" "$mirrors" $(echo "$@" | tr ' ' '\n' | sort)
> }
>
> download_indices () {
> mk_download_dirs
> - "$DOWNLOAD_INDICES" $(echo "$@" | tr ' ' '\n' | sort)
> + local suite="$1"
> + local mirrors="$2"
> + shift 2
> + # It is never called with any additional parameters, why not just
> + # getting rid of the echo/tr/sort stuff? It might have been a
> + # copy/paste from the other function wrapper.
> + "$DOWNLOAD_INDICES" "$suite" "$mirrors" $(echo "$@" | tr ' ' '\n' |
> sort)
> }
>
> debfor () {
Neither of these appears to take account of the fact that each mirror
you specify might have different layouts (see mirror_style).
> + # Avoid component duplication (which is harmless anyway, components
> + # just appear several times in sources.list in this case) when
> + # download_release_indices() is called more than once.
This seems like a hack. Shouldn't components be calculated independently
for each mirror/suite pair?
> (cd "$TARGET/$APTSTATE/lists"
> - for a in debootstrap.invalid_*; do
> + for a in debootstrap.invalid_dists_${suite}_*; do
>mv "$a" "${m}_${a#*_}"
>done
> )
Your editor seems to have converted a tab to spaces here. Please try to
avoid this.
> setup_apt_sources () {
> + local suite="$1"
> + shift 1
Just 'shift' will do.
> Index: debootstrap.8
> ===
> --- debootstrap.8 (revision 57816)
> +++ debootstrap.8 (working copy)
> @@ -135,6 +135,30 @@
> .IP "\fB\-\-debian\-installer\fP"
> Used for internal purposes by the debian-installer
> .IP
> +.SH "PORTER OPTIONS"
> +.
> +.PP
> +The following options should be useful only to porters whose arch has
> +not yet been integrating into the official archive, and who need to
> +download additional packages from a suite called \fIunreleased\fR or
> +similar.
I can think of other cases where this is useful. Let the user worry
about who they are - just document the options you're adding together
with the existing options.
> +Note that all dependencies have to be solved manually: the extra
> +included packages should be autosufficient (in \fIEXTRA_SUITE\fR);
> +and their dependencies in \fISUITE\fR have to be added using
> +\fB\-\-include\fP. A helper script is available in debootstrap's
> +sources, see \fIscripts/porters/\fR).
I think we should fix this bug rather than enshrining it in
documentation. :-)
Thanks,
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [patch] libdebian-installer poll()
On Tue, Jul 07, 2009 at 01:05:41AM +0200, Luca Favatella wrote:
> This patch solves a poll() portability issue on kfreebsd-i386, and
> shouldn't affect other archs.
>
> I tested this on kfreebsd-i386, solving an infinite loop.
> Index: src/exec.c
> ===
> --- src/exec.c(.../trunk/packages/libdebian-installer)
> (revision 59247)
> +++ src/exec.c
> (.../branches/d-i/kfreebsd/packages/libdebian-installer)(revision
> 59254)
> @@ -164,7 +164,12 @@
>
> for (i = 0; i < pipes; i++)
> {
> +// References: http://www.greenend.org.uk/rjk/2001/06/poll.html
While // is a valid comment syntax in C99, it wasn't in earlier versions
of C, and I believe that /* ... */ is still preferred in libd-i.
> +#if defined(__FreeBSD_kernel__)
> + if ((pollfds[i].revents & POLLIN) && (! (pollfds[i].revents &
> POLLHUP)))
> +#else
>if (pollfds[i].revents & POLLIN)
> +#endif
This looks OK.
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [patch] kfreebsd-i386 kernel udeb: fix ABI and fix dependency version
On Thu, Jul 16, 2009 at 11:47:18AM +0200, Luca Favatella wrote: > This patch fixes in the kfreebsd-i386 kernel udeb > * ABI (see also [0]) > * a dependency version > > Sorry for writing one patch and one mail for two fixes, but I decided > to do so because the fixes are very simple. Looks fine; OK to commit. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565109: gnome install dependency update-binfmts (Linux Only)
On Tue, Feb 02, 2010 at 12:27:21PM +0100, Petr Salinger wrote: >> We really should either: >> * get it working, if relevant; >> * get it to fail gracefully; >> * get it removed from any relationships for non-Linux ports. >> >> (But someone may have better ideas.) >> >> Manually removing/not-installing it is a pain, even when one is >> already aware of this issue. > > And/or change binfmt-support from architecture "all" to "linux-any". > It would add at about 250 KB to whole Debian archive size. If it's at all possible, I'd really far prefer to get it working on BSD. It's a useful abstraction layer, and it would be more useful if we could rely on it working across all architectures. Does BSD have anything remotely similar to Linux's binfmt_misc that could be used to implement this? -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: parted unblock, and upcoming transition
On Thu, Mar 25, 2010 at 02:03:30PM +0100, Aurelien Jarno wrote: > Philipp Kern a écrit : > > On Thu, Mar 25, 2010 at 11:49:40AM +0100, Philipp Kern wrote: > >> so parted FTBFSes on kfreebsd due to configure not knowing about it > >> (#575007). Is there progress on this? (As it will block testing > >> migration due to kfreebsd issues being RC if the package has built > >> successfully before.) > > > > I was told that this might be due to upstream dropping support, > > thus also pointing -bsd to it. > > > > I assume parted would be needed for d-i on kfreebsd too? > > The FreeBSD patches have been dropped, so parted has to be ported again. > I don't know when I'll have time to work on that. In the meanwhile, > parted can probably be removed from kfreebsd. I'm working on it right now. It's not a trivial forward-port, but it doesn't look too bad. -- Colin Watson [cjwat...@debian.org] -- 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/20100325132527.gk4...@riva.ucam.org
Re: libparted0-udeb: not installable on kfreebsd-*, depends on libgeom0
On Tue, May 04, 2010 at 04:59:38PM +0200, Cyril Brulebois wrote: > Package: libparted0-udeb > Version: 2.2-5 > Severity: serious > Tags: d-i > Justification: Not installable > User: debian-bsd@lists.debian.org > Usertags: kfreebsd > > Hi, > > thanks to your efforts, parted gets now built again on kfreebsd-*; > unfortunately its udeb isn't installable since it depends on libgeom0. > According to this mail[1], it might be a wrong version of a patch? > > 1. http://lists.debian.org/debian-bsd/2010/04/msg00037.html > > I didn't find time to investigate yet, but I don't want to forget about > it totally. I'm afraid I don't understand Aurelien's mail. The current version (as far as I'm aware) of the parted FreeBSD patch entirely relies on libgeom. Wouldn't the correct fix for this be to build a libgeom0-udeb? Thanks, -- Colin Watson [cjwat...@debian.org] -- 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/20100614114647.ga13...@riva.ucam.org
Re: libparted0-udeb: not installable on kfreebsd-*, depends on libgeom0
On Mon, Jun 14, 2010 at 04:41:50PM +0200, Aurelien Jarno wrote: > Colin Watson a écrit : > > On Tue, May 04, 2010 at 04:59:38PM +0200, Cyril Brulebois wrote: > >> thanks to your efforts, parted gets now built again on kfreebsd-*; > >> unfortunately its udeb isn't installable since it depends on libgeom0. > >> According to this mail[1], it might be a wrong version of a patch? > >> > >> 1. http://lists.debian.org/debian-bsd/2010/04/msg00037.html > >> > >> I didn't find time to investigate yet, but I don't want to forget about > >> it totally. > > > > I'm afraid I don't understand Aurelien's mail. The current version (as > > far as I'm aware) of the parted FreeBSD patch entirely relies on > > libgeom. Wouldn't the correct fix for this be to build a libgeom0-udeb? > > The problem is that the current version which is in the package is the > old version of the patch, instead of the one that has been improved > during the GSoC last year. The current version needs libgeom, while the > improved version doesn't need it. > > The versions 1.8.8 were using the improved version, while the versions > 2.2 have switched back to the original version, which introduced back a > few bugs, especially with SCSI drives. > > You can find the improved version of this patched, ported for 2.2 at > this URL: > > http://temp.aurel32.net/kfreebsd-gnu.patch Ah, thanks. I remember seeing this in the past and I could have sworn I'd already applied it, but evidently not. Some kind of bug report as a reminder would have been nice ... I'll upload this shortly. -- Colin Watson [cjwat...@debian.org] -- 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/20100614152237.ge12...@riva.ucam.org
Re: ZFS support
On Wed, Sep 01, 2010 at 02:36:17PM +0200, Robert Millan wrote:
> This patch adds ZFS support to grub-installer.
Thanks for this patch.
> diff -ur grub-installer-1.55.old/grub-installer
> grub-installer-1.55/grub-installer
> --- grub-installer-1.55.old/grub-installer2010-08-18 16:38:02.0
> +0200
> +++ grub-installer-1.55/grub-installer2010-09-01 13:47:23.554370178
> +0200
> @@ -75,10 +75,15 @@
>
> serial="$(get_serial_console)"
>
> +grub_probe () {
> + apt-install grub-common
> + $chroot $ROOT grub-probe $@
> +}
apt-install is not that cheap; it has to set up the target chroot and
then tear it all down again. Could you please add a bit of state here
to remember when grub_probe has already been called?
> @@ -118,7 +123,7 @@
> }
>
> findfs () {
> - mount | grep "on $ROOT${1%/} " | tail -n1 | cut -d' ' -f1
> + grub_probe -t device $1
> }
>
> findfstype () {
I think this should be OK, although I'm (possibly unjustifiably)
paranoid about unexpected side-effects at this point. Perhaps you could
add the original mount-grepping code back in as a fallback in case
grub-probe fails? For example, I'm wondering about the case where / is
a dm-crypt device.
This can be applied after these changes.
--
Colin Watson [cjwat...@debian.org]
--
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/20101109181322.ga15...@riva.ucam.org
Re: RFC: future size of embed area in partition labels
On Sat, Nov 13, 2010 at 10:48:31PM +0100, Robert Millan wrote: > When using MSDOS labels, an embed region (empty space) > before first partition was usually reserved. This used to be > 62 sectors, which is enough for most filesystems (and GRUB > developers have worked hard to ensure our filesystem code > fits in that space). Recently, Parted developers increased > what Parted considers "optimum" alignment to 2048 (due to > Windows Vista compatibility problems I don't really care about), > and as a result in the default layout the embed region has > grown to almost 1 MiB, which is more than enough for GRUB. As a point of information, it's not just about Windows compatibility. Optimal alignment is valuable for performance on many modern drives. Cylinder alignment used to be a performance win but hasn't been needed for (I believe) decades. If you align to 2048 sectors (1MiB) then you ensure optimal performance across a wide variety of drives, which means that the likelihood of having to adjust partitions when migrating between drives is reduced. While it so happens that Windows uses 1MiB alignment by default nowadays, my understanding is that Microsoft made that change for essentially the same reasons we're making it. Thus it isn't really accurate to paint it as a matter of compatibility. (GNU Parted's NEWS file gives essentially the same reason, and does not mention Windows.) > Unfortunately this "optimum" alignment is not always used. > Under certain conditions a "minimum" alignment of 1, or > the usual "cylinder" alignment of 63 take place (I'm unsure > which are these, although I've been able to reproduce > the problem. But this isn't relevant, what matters is that > this logic is present in parted and partman-base). If you can reproduce this, please attach installation logs, particularly /var/log/partman. This should not generally happen as of partman-base 141 (2010-04-27). (Obviously, we can only control the size of the embedding area when we're creating the partition table from scratch; trying to move existing operating systems around transparently is bad karma. I trust you're not talking about situations where the partition table already exists.) > - Switch to GPT as default partition label > Pros: > - Modern design, with metadata redundancy, checksums, > partition limit higher than 4 (no need for "extended" > kludge). > - We're moving to GPT anyway when disks surpass 2 TiB, > doing it now ensures wider testing before the codebase > that will have to deal with this is released. > Con: > - Lack of compatibility with old operating systems > (even modern versions of Windows are unable to boot > from a GPT disk AFAIK) Windows' policy, as I understand it, is to support GPT only when booting from UEFI, which is only supported in Windows 64. As we both know, GPT systems can be booted using BIOS, although they do rely on the protective MBR to do so, and you have to ensure that the BIOS Boot Partition resides below 2TiB (which partman does not currently validate, although it will create it that way unless the first 2TiB of the disk are already in use). From talking to BIOS vendors, nobody really seems quite sure whether INT 13 Function 42 et al actually work portably with 64-bit addresses the way they're supposed to - although of course this holds regardless of the partition table type you're using. Anyway, that's mostly by the by. I think our current policy of using GPT by default only when it's necessary (UEFI, or the disk size exceeds 2TiB) is OK, really. Being more aggressive just courts problems when they aren't necessary (when you make a big change that isn't strictly necessary, people blame any new problems on the change even if they would have had other problems without it, sadly), and I think we're getting a reasonable amount of GPT testing even today. > - Modify partman-auto to include embed space explicitly in > its recipes. > Pro: > - embed space is visible to user > Con: > - embed space is visible to user This feels like overkill, and in any case I think it would just shuffle the problem around. > - Increase minimum alignment in parted to 2048 > Pros: > - Simple fix. > Cons: > - Unwanted side effects. > - Temporary kludge. This seems wrong. partman should only ever tell libparted to use minimal alignment if you explicitly instruct it to do so using preseeding (and it's a fairly obscure and new template so I doubt it is in widespread use). Sometimes people need to use cylinder for particular compatibility reasons; it's not the default and I wouldn't like us to make a change that prevented them from doing this because it is sometimes g
Re: RFC: future size of embed area in partition labels
On Mon, Nov 22, 2010 at 01:59:36PM +0100, Robert Millan wrote: > 2010/11/18 Colin Watson : > > (Obviously, we can only control the size of the embedding area when > > we're creating the partition table from scratch; trying to move existing > > operating systems around transparently is bad karma. I trust you're not > > talking about situations where the partition table already exists.) > > Yes and no. ISTR if the partition table already exists, BUT user > requested to use "the whole disk" for installation, the result is > still a small embed area. I'll recheck. That's definitely not as expected. > > Windows' policy, as I understand it, is to support GPT only when booting > > from UEFI, which is only supported in Windows 64. > > A huge mistake if you ask me, but well, it's their problem. It > just bothers me that this will artificially push EFI after it failed > to gain acceptance by its own merit during the last 10 years. I agree it's a mistake in Windows, but regarding UEFI acceptance, it does depend on how you look at it. My understanding is that well over half [1] the systems distributed over the last couple of years use UEFI with a compatibility layer to implement their BIOS (so UEFI is more often than not there but invisible), and that traditional BIOS implementations are well on their way to dying out. Of course I'm sure the answers depend on whom you talk to, since it seems as though nobody keeps very authoritative track of the numbers. [1] I forget the exact numbers and can't find the reference, so take this as you will, but it was something along those lines. > > Let's just dig into the reason why the embedding area is small in the > > cases you've seen. I suspect that it may just be a simple bug, and > > won't require policy changes to fix. > > I'm short on time currently but I'll hopefully be able to do this > before the release. Aren't we all :-) Thanks. -- Colin Watson [cjwat...@debian.org] -- 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/20101122133646.gr12...@riva.ucam.org
Re: APT archive
On Sun, Jan 20, 2002 at 07:36:13PM -0700, Joel Baker wrote: > Currently it has some of the base SGML packages and a few things that are > useful for pulling down other packages or compile work. More will be on its > way soon (current goal: get groff working so that many things which use it > for docs work; this means getting X working, which means getting debconf > working, which means... :) I'm working on an experimental upload of groff which should make life a bit easier there; it should be ready in the next couple of days for somebody to try to build. Does NetBSD have ? -- Colin Watson [EMAIL PROTECTED]
Re: Dependancies on libc
On Wed, Jan 23, 2002 at 09:00:14PM -0700, Joel Baker wrote:
> Having run into a few packages, now, which have dependancies on specific
> GNU libc versions (or rather, libc versions, when all that the packaging
> system understands is libc == GNU libc), which compiled just fine under
> the NetBSD libc, I come to the following conclusion:
>
> We should request that a provision be made for desginating which libc is
> required, from the developer/policy community. As a starting point, I'll
> toss out one possible resolution:
>
> Rename the libc-* packages to libc-gnu-* (or gnu-libc-*), and use Provides
> headers to "fake" the old names, for a period of time (IE, to allow a grace
> period in which packages which depend on libc can change their dependancy
> listing). Other libc packages would then be libc-netbsd-* or netbsd-libc-*
> in a similar fashion, allowing proper dependancy declarations for any libc
> packages which might end up being part of Debian.
I'd strongly recommend not doing this. Firstly, Provides: don't work in
the case of versioned dependencies, and I suspect not for versioned
build-dependencies either, so you're asking every other architecture to
switch over several thousand packages all at once just to adjust the
naming. That's not a good idea.
Secondly, each architecture really has to have only one libc; when you
switch to another one, you're effectively creating a new architecture
anyway, and it doesn't matter if package names clash between
architectures. Furthermore, the glibc packages already have different
names on three Debian architectures (alpha and ia64 use libc6.1{,-dev},
while hurd-i386 uses libc0.2{,-dev}). Since one of those architectures
was released with potato and another will release with woody, people
should have got used to dealing with this a long time ago.
I assume you're talking about 'Build-Depends: libc6-dev (>= foo)', so
you can use the fact that build-dependencies can include architecture
restrictions. They'll end up looking something like this (depending on
exactly what the netbsd-i386 libc is being called):
Build-Depends: libc6-dev (>= foo) [!alpha !ia64 !hurd-i386 !netbsd-i386],
libc6.1-dev (>= foo) [alpha ia64], libc0.2-dev (>= foo) [hurd-i386], libc-dev
[netbsd-i386]
Yes, it's ugly, but not many packages should need versioned
build-dependencies on libc6-dev. If anyone has an unversioned
build-dependency on libc6-dev, you can file bugs against them, as
libc6-dev is build-essential on the architectures which have it.
As for binary dependencies on libc6, well, those are usually generated
using shlibdeps anyway.
--
Colin Watson [EMAIL PROTECTED]
Re: Reassurance
On Mon, Oct 21, 2002 at 04:57:52PM -0700, Jeremy C. Reed wrote: > Hopefully, the Debian sources are updated. > > A quick look at http://www.debian.org/security/2002/ does not indicate > sendmail/smrsh or groff/pic. We fixed the groff/pic hole roughly forever ago - I'm not sure why it took NetBSD so long to issue an advisory. http://www.debian.org/security/2001/dsa-072 Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#175370: A reliable way to get LC_CTYPE encoding
On Wed, Jan 15, 2003 at 09:34:45AM -0600, Steve Langasek wrote: > On Wed, Jan 15, 2003 at 07:31:42AM -0600, Colin Watson wrote: > > On Tue, Jan 14, 2003 at 05:40:45PM -0600, Steve Langasek wrote: > > > FWIW, I did some research into nl_langinfo() for an upstream recently, > > > and found that it's implemented on at least these platforms: > > > > > >Linux (glibc) > > >FreeBSD > > >NetBSD > > >Solaris > > >AIX > > > Hmm, groff needed a patch not all that long ago because Debian > > GNU/NetBSD didn't have nl_langinfo(CHARSET). Maybe it's a recent ^^^ I meant CODESET ... > > addition. > > According to NetBSD's own on-line manpages (I've misplaced the URL ATM), > they've supported it since 1994. Perhaps it's implemented but buggy? Bug #130356 prompted the change to groff. The BSD list may know more. > Is Debian GNU/NetBSD using the same libc that NetBSD uses? Yep. Cheers, -- Colin Watson [EMAIL PROTECTED]
iconv availability
Hi, iconv is part of glibc on Debian GNU/Linux. Is it available anywhere on Debian GNU/*BSD? I plan to use it in man-db and would like to know if I'm going to need special dependencies for the BSD ports. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: iconv availability
On Sat, Mar 01, 2003 at 08:20:15PM -0700, Joel Baker wrote: > On Sat, Mar 01, 2003 at 03:08:02PM +0000, Colin Watson wrote: > > iconv is part of glibc on Debian GNU/Linux. Is it available anywhere on > > Debian GNU/*BSD? I plan to use it in man-db and would like to know if > > I'm going to need special dependencies for the BSD ports. > > I have libiconv ITP'ed and pending upload once there is a binary section > that can take it. This is the GNU iconv library (separate from the glibc > code), but as far as I can tell from reading the docs, the API is the same. If that includes /usr/bin/iconv, then excellent. (Sorry if I wasn't clear - that was what I meant originally, not iconv().) If the package name is just 'iconv' then I'll depend on that for the BSDs somehow. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#741656: grub-common: grub-mkrescue lost its -J flag, d-i now FTBFS on kfreebsd-*
On Sat, Nov 26, 2016 at 06:17:28AM +0100, Cyril Brulebois wrote: > kfreebsd-* builds are now failing to build with: > | # Create the ISO with Joliet extensions, needed for win32-loader.ini > | # NOTE: "-- -J" is a workaround for #741656 in grub-common > | grub-mkrescue --output=./tmp/netboot-10/mini.iso ./tmp/netboot-10/cd_tree > -- -J > | xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project. > | > | xorriso : FAILURE : Not a known command: '-J' > | > | xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' > | install -m 644 -D ./tmp/netboot-10/mini.iso dest/netboot-10/mini.iso > | install: cannot stat './tmp/netboot-10/mini.iso': No such file or directory > | Makefile:798: recipe for target 'dest/netboot-10/mini.iso' failed > > I think that started with grub2 (2.02~beta3-1) reaching unstable: > https://tracker.debian.org/news/805858 > > as upload timing would match the start of the FTBFS according to graphs > on the summary page: > https://d-i.debian.org/daily-images/daily-build-overview.html > > Also, util/grub-mkrescue.c's argument handling got changed between grub2 > 2.02~beta2-36 and 2.02~beta3-1. Yep, as Thomas said, this changed back to the original state in 2.02~beta3. I think that in fact allows us to close #741656 if you also revert your previous workaround in d-i, but please confirm. Compare: https://anonscm.debian.org/cgit/pkg-grub/grub.git/commit/?id=496cca85259c77b5fc8ad39a9064c83c3a39b7a6 (Sorry, I forgot that d-i had worked around this.) -- Colin Watson [cjwat...@debian.org]
Re: Bug#741656: grub-common: grub-mkrescue lost its -J flag, d-i now FTBFS on kfreebsd-*
Source: grub2 Source-Version: 2.02~beta3-1 On Sat, Nov 26, 2016 at 09:56:46PM +0100, Cyril Brulebois wrote: > Colin Watson (2016-11-26): > > Yep, as Thomas said, this changed back to the original state in > > 2.02~beta3. I think that in fact allows us to close #741656 if you also > > revert your previous workaround in d-i, but please confirm. Compare: > > > > > > https://anonscm.debian.org/cgit/pkg-grub/grub.git/commit/?id=496cca85259c77b5fc8ad39a9064c83c3a39b7a6 > > > > (Sorry, I forgot that d-i had worked around this.) > > (No worries.) > > Yeah, a revert was what I had in mind, but I thought I'd double check > anyway. Just pushed it, triggered a build on falla and fischer, and > builds seem happier now. Thanks! > > I think this bug report should be closed now? Indeed, thanks. Done with this message. -- Colin Watson [cjwat...@debian.org]
