Re: Bug #588844 python-pygccxml: broken on kfreebsd-*: RuntimeError: unable to find out location of gccxml
Hello list, I am now trying to fix a bug related to kfreebsd port. The bug is probably not a complicated issue, but I need someone who have a kfreebsd installation to help me test the patch[1]. [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=check_os_name_posix.patch;att=1;bug=588844 -- Regards, Aron Xu -- 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/aanlktimfywrhpf9psyahtno0j2ux5k0pxvgvfsvaq...@mail.gmail.com
Re: Bug #588844 python-pygccxml: broken on kfreebsd-*: RuntimeError: unable to find out location of gccxml
Aron Xu (13/11/2010): > Hello list, Hi, > I am now trying to fix a bug related to kfreebsd port. The bug is > probably not a complicated issue, but I need someone who have a > kfreebsd installation to help me test the patch[1]. there you go: | (sid)k...@asdfasdf:~$ python | Python 2.6.6 (r266:84292, Oct 9 2010, 14:11:33) | [GCC 4.4.5] on gnukfreebsd8 | Type "help", "copyright", "credits" or "license" for more information. | >>> import os | >>> os.name | 'posix' Sounds good to me. Mraw, KiBi. signature.asc Description: Digital signature
Re: [Pkg-gnupg-maint] Bug#598471: using insecure memory on GNU/kFreeBSD
2010/11/13 Thijs Kinkhorst : >>> Upstream recommends [2] setting the SUID bit and assures that "the >>> program >>> drops root privileges as soon as locked memory is allocated". >> >> However it is much easier and more secure to enable encrypted swap >> space than to use mlock. It seems that gbde and the init scripts are >> missing on GNU/kfreebsd. > > Robert, as I don't have knowledge of GNU/kFreeBSD, can you say whether the > suggestion by Werner is indeed a better way to solve this problem? I disagree. This puts an additional burden on the user. Adding SUID bit doesn't seem like a security problem. Gnupg drops privileges as soon as it's not needed anymore, and upstream recommends this in their FAQ. (Yes I know Werner is upstream, but if it's still in the FAQ I assume he doesn't consider it a bad option) CC'ing debian-bsd -- Robert Millan -- 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/aanlktinityc3mrmwg1jrybyzuu8fn7ezueahy9r8c...@mail.gmail.com
Bug#603380: messages about track alignment
Package: kfreebsd-image-8.1-1-amd64
Version: 8.1-5
Severity: normal
Tags: patch
kFreeBSD usually spits a bunch of messages about partitions
not starting/ending on track boundary during boot:
GEOM: da0: partition 2 does not start on a track boundary.
GEOM: da0: partition 2 does not end on a track boundary.
GEOM: da0: partition 1 does not start on a track boundary.
GEOM: da0: partition 1 does not end on a track boundary.
These messages are a remnant of the past, as track alignment
is currently meaningless to the disk (hard disks manage
their geometry internally, and new devices such as flash/SD
don't even have tracks).
Here's a patch to remove them.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 8.1-1-amd64
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages kfreebsd-image-8.1-1-amd64 depends on:
ii freebsd-utils 8.1-2+b1 FreeBSD utilities needed for GNU/k
ii kldutils 8.1-2+b1 tools for managing kFreeBSD module
kfreebsd-image-8.1-1-amd64 recommends no packages.
kfreebsd-image-8.1-1-amd64 suggests no packages.
-- no debconf information
--- sys/geom/part/g_part_mbr.c~ 2009-03-30 00:53:46.0 +
+++ sys/geom/part/g_part_mbr.c 2010-11-13 15:16:09.0 +
@@ -416,13 +416,6 @@
basetable->gpt_heads = heads;
}
}
- if ((ent.dp_start % basetable->gpt_sectors) != 0)
- printf("GEOM: %s: partition %d does not start on a "
- "track boundary.\n", pp->name, index + 1);
- if ((ent.dp_size % basetable->gpt_sectors) != 0)
- printf("GEOM: %s: partition %d does not end on a "
- "track boundary.\n", pp->name, index + 1);
-
entry = (struct g_part_mbr_entry *)g_part_new_entry(basetable,
index + 1, ent.dp_start, ent.dp_start + ent.dp_size - 1);
entry->ent = ent;
Re: [Pkg-gnupg-maint] Bug#598471: using insecure memory on GNU/kFreeBSD
On Saturday 13 November 2010 14:58:29 Robert Millan wrote: > >>> Upstream recommends [2] setting the SUID bit and assures that "the > >>> program > >>> drops root privileges as soon as locked memory is allocated". > >> > >> However it is much easier and more secure to enable encrypted swap > >> space than to use mlock. It seems that gbde and the init scripts are > >> missing on GNU/kfreebsd. > > > > Robert, as I don't have knowledge of GNU/kFreeBSD, can you say whether > > the suggestion by Werner is indeed a better way to solve this problem? > > I disagree. This puts an additional burden on the user. Adding SUID > bit doesn't seem like a security problem. Gnupg drops privileges as > soon as it's not needed anymore, and upstream recommends this in > their FAQ. > > (Yes I know Werner is upstream, but if it's still in the FAQ I assume he > doesn't consider it a bad option) > > CC'ing debian-bsd OK, I'll be applying your patch then in the next upload of gnupg. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Re: FreeBSD committer at Manchester BSP
2010/11/10 Michael Dorrington : > Can people please be available on IRC and/or > give Gavin and I some pointers to things that would be useful to work on. I'm unsure if this is fixed now, but I heard there are issues with wireless. Has somebody tested network-manager + (WEP | WPA)? -- Robert Millan -- 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/aanlkti=28psr=sdsts_hf1xr-dfwz90qivoctjvag...@mail.gmail.com
Re: FreeBSD committer at Manchester BSP
Robert Millan writes: > I'm unsure if this is fixed now, but I heard there are issues with wireless. wireless support in ifconfig was removed some time ago, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601803 At least unencrypted wlan works here when I use ifconfig from a chroot that has binaries from freebsd 8.1 CD-ROM. -- 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/84wrohch2s@sauna.l.org
Bug#594940: Includes binary-only and obfuscated C code
Sorry for the slight delay in responding to this. On Sun, 2010-11-07 at 14:16 +0100, Petr Salinger wrote: > >> Now we have to somehow prune current source tree and disable some > >> modules. Could we get squeeze-ignore tag for some of the affected > >> files or is it necessary to prune all affected files ? > > > > Ben's original lists included some files which we don't appear to be > > able to distribute at all. If his analysis is correct then those files > > at least would need to be removed rather than ignored. > > The question is whether pruning following files suffices: Apologies if this question has already been asked (I couldn't find the previous occurrence if it has), but what would the effect on the kfreebsd-* kernel be of removing all of the files which were originally mentioned in Ben's mails in this bug report, and is that an option which has been considered by the porters? fwiw, if the current firmware-loading mechanism could be extended to support using the firmware-* packages, the SRMs would be prepared to look at introducing the updated mechanism - and any necessary new firmware packages - as part of a Squeeze point release, if desired / required. Regards, Adam -- 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/1289668709.11930.1366.ca...@hathi.jungle.funky-badger.org
Bug#601803: kfreebsd-image-8.1-1-686: ifconfig wlan0 create wlandev ath0 => SIOCIFCREATE2: Bad address
> libbsdxml is just normal expat with different name. Also, libjail and > libsbuf seem relatively small. Would it make sense to just package > these separately and have freebsd-utils build-depend on them? Note that libsbuf is packaged already (it's in freebsd-libs). As for libbsdxml, perhaps it'd be useful if libexpat provided a compatibility symlink? -- Robert Millan -- 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/aanlktikr962iqup+bv_+gn3beqmrtlbnjvyt+5h1j...@mail.gmail.com
Bug#601803: kfreebsd-image-8.1-1-686: ifconfig wlan0 create wlandev ath0 => SIOCIFCREATE2: Bad address
Robert Millan writes: > As for libbsdxml, perhaps it'd be useful if libexpat provided a > compatibility symlink? For the headers too? They expect bsdxml.h to exist. -- 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/84pqu9cddr@sauna.l.org
Bug#601803: kfreebsd-image-8.1-1-686: ifconfig wlan0 create wlandev ath0 => SIOCIFCREATE2: Bad address
2010/11/13 Timo Juhani Lindfors : > Robert Millan writes: >> As for libbsdxml, perhaps it'd be useful if libexpat provided a >> compatibility symlink? > > For the headers too? They expect bsdxml.h to exist. Why not? It seems both useful and harmless. I'd ask the libexpat maintainer. -- Robert Millan -- 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/aanlktikmubwswh4iomijlzcjuo7ue4iyradtxehld...@mail.gmail.com
Bug#594940: Includes binary-only and obfuscated C code
what would the effect on the kfreebsd-* kernel be of removing all of the files which were originally mentioned in Ben's mails in this bug report, and is that an option which has been considered by the porters? From my (non-DD) POV, the most problematic are network drivers sys/dev/txp/3c990img.h - binary is packaged in firmware-linux-nonfree as /lib/firmware/3com/typhoon.bin sys/dev/fxp/rcvbundl.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/e100/* For our port is very important to release. It would be better to release even without any of these drivers compared to not release at all ... fwiw, if the current firmware-loading mechanism could be extended to support using the firmware-* packages, the SRMs would be prepared to look at introducing the updated mechanism - and any necessary new firmware packages - as part of a Squeeze point release, if desired / required. Could be the plan: 1) drop all files from Ben's mail, repackage .orig.tgz, disable drivers 2) upload into sid and ask for propagation into squeeze 3) start extending firmware-loading mechanism 4a) upload into sid and ask for propagation into squeeze 4b) upload into stable-proposed-updates Whether 4a or 4b depends on our timing. I have to note, that this is my personal planing, not planing of whole porter group, but I expect they would agree. Petr -- 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/pine.lnx.4.62.1011131958370.11...@sci.felk.cvut.cz
Re: Bug#588844: Bug #588844 python-pygccxml: broken on kfreebsd-*: RuntimeError: unable to find out location of gccxml
On Sat, Nov 13, 2010 at 18:35, Cyril Brulebois wrote: > Aron Xu (13/11/2010): >> Hello list, > > Hi, > >> I am now trying to fix a bug related to kfreebsd port. The bug is >> probably not a complicated issue, but I need someone who have a >> kfreebsd installation to help me test the patch[1]. > > there you go: > | (sid)k...@asdfasdf:~$ python > | Python 2.6.6 (r266:84292, Oct 9 2010, 14:11:33) > | [GCC 4.4.5] on gnukfreebsd8 > | Type "help", "copyright", "credits" or "license" for more information. > | >>> import os > | >>> os.name > | 'posix' > > Sounds good to me. > > Mraw, > KiBi. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkzeaeAACgkQeGfVPHR5Nd34IACgll0g1hS+cVodFhCq2bbgIVNT > tnMAoKSy1GaNMVwloXUQFN5kqm4M8yZY > =mNBb > -END PGP SIGNATURE- > > Thanks for your help, I've made my new version which is pending upload the fix the bug. -- Regards, Aron Xu -- 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/aanlktimjcbqoatnfbeefnipd-q5mvfjdm2vhqanxw...@mail.gmail.com
Re: [Pkg-gnupg-maint] Bug#598471: using insecure memory on GNU/kFreeBSD
On Sat, 13 Nov 2010 14:58, r...@debian.org said: > I disagree. This puts an additional burden on the user. Adding SUID I can't see why encrypting the swap puts an additional burden on the user or on the machine. If you need to swap/page something you are in either of these situations: - The process is idle for a long time. Thus there should be no burden to the user regarding the extra time it takes for the system to swap it out. The system is anyway under some stress. - There is a severe memory resource shortage and due to the ongoing swap operations in many processes, the system performance is I/O bounded and the CPU has enough time to do that little symmetric encryption. Even without having done any benchmarks I'd enbale swap encryption by default. > bit doesn't seem like a security problem. Gnupg drops privileges as > soon as it's not needed anymore, and upstream recommends this in > their FAQ. Ahemm, the FAQ. Well that beast is old and hopefully the only unmaintained part of GnuPG. The background for the SUID stuff is that back in 1998 encrypted swap partitions were not widely available and disk encryption on GNU/Linux was not available at all (due to US export restrictions). The manual even states (at least I hope) that you should set the SUID bit only if you see the warning, on modern Linux kernels there is no need for it because any process may mlock a few pages which is sufficient. With an encrypted swap partition all stuff could be much much easier. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- 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/87r5ept57v@vigenere.g10code.de
Re: [Pkg-gnupg-maint] Bug#598471: using insecure memory on GNU/kFreeBSD
2010/11/13 Werner Koch : > I can't see why encrypting the swap puts an additional burden on the > user or on the machine. This depends on whether it's the default setting or not. If it's not, it definitely does (just the burden of figuring out what the heck is wrong is already significant for many users). > Even without having done any benchmarks > I'd enable swap encryption by default. I second that. kFreeBSD disk encryption supports generating one-time keys, which works well for swap: geli onetime -s 4096 /dev/something swapon /dev/something.eli For that we're missing a port of "geli" utility, figuring out some init.d magic that would replace (or integrate with) "swapon -a", and integration with D-I to set the whole thing up. I don't have time to work on this myself. Unless someone else does, I'd still recommend adding the SUID bit as a temporary solution. What do debian-bsd folks think about this? P.S. I suggest you update that FAQ ; -) -- Robert Millan -- 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/aanlktikvjjtcm7+fbwezkoqyz+jfed+rjxwltue98...@mail.gmail.com
RFC: future size of embed area in partition labels
With the introduction of ZFS support in D-I, an existing problem with size of embed area in partition labels begins to manifest. This problem is not specific to ZFS, it affects any filesystem when its readonly implementation in GRUB reaches certain size. 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. 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). ZFS already has surpassed the 62-sector limit, not by a lot, but as it grows in complexity it'll be increasingly harder to make it fit. I expect we will eventually hit the same problem with other next-generation filesystems which are still under development, such as Btrfs or Hammer. To summarize: we're getting closer to a point in which embed area size will need to be increased, and this increase is already necessary for ZFS. I propose a number of different solutions. This list covers the approaches I could think of, but isn't exhaustive. - 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) - 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 - Increase minimum alignment in parted to 2048 Pros: - Simple fix. Cons: - Unwanted side effects. - Temporary kludge. -- Robert Millan -- 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/aanlktinjo7lm1t+fqrz4nb9uznqbo5-ah68o2pxo-...@mail.gmail.com
