Re: ipv6 Secure NDP
On 5/9/07, Mohacsi Janos [EMAIL PROTECTED] wrote: Hi, There was a plan to implement SEND at KAME, but due to IPR issues KAME did not start the implementation: http://www.kame.net/newsletter/20040525/ Maybe it could be implemented in Google Summer of Code for any BSD. Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Tue, 8 May 2007, Subhash Gopinath wrote: Hello folks, Is there a plan to implement ipv6 SEND (secure NDP) in FreeBSD? There's a userspace implementation by DoCoMo, but thats not yet in the official ports collection. Thanks, --Subhash There is still patent issues with SEND as far as I know so I do not see how this could be implemented in a GSoC? Microsoft which has claims wants a licence from them I think. I got interested in this now and since I work at Ericsson I will look this up and see what the status is from the Ericsson side of it. BR Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Experiences with 7.0-CURRENT and vmware.
I'm using FreeBSD 7.0-CURRENT under vmware and there are a few issues. First, time. hint.hw.acpi.disabled=1 This appears to make _no_ difference to time keeping on FreeBSD 7 and nor does it seem to have any impact on ACPI being loaded. Do I need to recompile a new kernel without it or is there a new way to disable ACPI? I should add that FreeBSD 6, with the same setting, is no better and that I need to run ntpdate every 5-10 minutes via crontab in order to keep good time (timekeeping is *really* bad.) In one instance, i was watching zpool iostat 1 and it appeared like the rows were muching up at a rate of 2 a second for a minute or so. How do I disable TSC timekeeping? (NetBSD has this disabled by default in their kernels.) Or is there somethign else I must do? Second, networking. Prior to FreeBSD-7, the driver to use inside vmware workstation was lnc. It has worked and contiues to work great. No problemo. FreeBSD-7 uses the em driver. To put it simply, it sucks in comparison. When things really get bad I start seeing em0: watchdog timeout messages on the console. I looked and I don't see a lnc driver anywhere. Is there another alternative (le?) driver that I can use in place of em, if so, how? Apart from these two issues (which are very central ones :-(), I'm using FreeBSD in a 64bit vmware workstation environment quick successfully and ZFS is quite happy with all the kva :-) ZFS and zpools are working just as I expect, even if a bit slower due to vmware but I'm not cranking out benchmarks here. Oh, and how do I fix ssh/rsh to do passwordless sessions? I'm trying to setup cron jobs to automate various tasks but there's this small hurdle called a password prompt that I can't seem to get rid of :-/ Cheers, Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Experiences with 7.0-CURRENT and vmware.
Darren Reed wrote: I'm using FreeBSD 7.0-CURRENT under vmware and there are a few issues. First, time. hint.hw.acpi.disabled=1 This appears to make _no_ difference to time keeping on FreeBSD 7 and nor does it seem to have any impact on ACPI being loaded. Do I need to recompile a new kernel without it or is there a new way to disable ACPI? I should add that FreeBSD 6, with the same setting, is no better and that I need to run ntpdate every 5-10 minutes via crontab in order to keep good time (timekeeping is *really* bad.) In one instance, i was watching zpool iostat 1 and it appeared like the rows were muching up at a rate of 2 a second for a minute or so. How do I disable TSC timekeeping? (NetBSD has this disabled by default in their kernels.) Or is there somethign else I must do? Does: hint.apic.0.disabled=1 Help? Second, networking. Prior to FreeBSD-7, the driver to use inside vmware workstation was lnc. It has worked and contiues to work great. No problemo. FreeBSD-7 uses the em driver. To put it simply, it sucks in comparison. When things really get bad I start seeing em0: watchdog timeout messages on the console. I looked and I don't see a lnc driver anywhere. Is there another alternative (le?) driver that I can use in place of em, if so, how? Apart from these two issues (which are very central ones :-(), I'm using FreeBSD in a 64bit vmware workstation environment quick successfully and ZFS is quite happy with all the kva :-) ZFS and zpools are working just as I expect, even if a bit slower due to vmware but I'm not cranking out benchmarks here. Oh, and how do I fix ssh/rsh to do passwordless sessions? I'm trying to setup cron jobs to automate various tasks but there's this small hurdle called a password prompt that I can't seem to get rid of :-/ Use a password-free (R|D)SA key. Dominic ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Experiences with 7.0-CURRENT and vmware.
On Thu, 10 May 2007, Darren Reed wrote: I'm using FreeBSD 7.0-CURRENT under vmware and there are a few issues. Generally speaking, I would suggest sending this post to current@, not hackers@, since your comments largely have to do between differences between -STABLE and -CURRENT, making it ideal fodder for the mailing list dedicated to -CURRENT development. First, time. hint.hw.acpi.disabled=1 This appears to make _no_ difference to time keeping on FreeBSD 7 and nor does it seem to have any impact on ACPI being loaded. Do I need to recompile a new kernel without it or is there a new way to disable ACPI? Have you tried hint.acpi.0.disabled=1 instead? This is what appears in acpi(4), and is what is used in various existing boot loader bits when I grep around. I should add that FreeBSD 6, with the same setting, is no better and that I need to run ntpdate every 5-10 minutes via crontab in order to keep good time (timekeeping is *really* bad.) In one instance, i was watching zpool iostat 1 and it appeared like the rows were muching up at a rate of 2 a second for a minute or so. How do I disable TSC timekeeping? (NetBSD has this disabled by default in their kernels.) Or is there somethign else I must do? kern.timecounter.hardware: ACPI-fast kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) I believe you can simply set kern.timecounter.hardware=APCI-fast and it will do what you expect. An interesting question is why it selects what is arguably the wrong one; a post to current@ might help resolve that. Second, networking. Prior to FreeBSD-7, the driver to use inside vmware workstation was lnc. It has worked and contiues to work great. No problemo. FreeBSD-7 uses the em driver. To put it simply, it sucks in comparison. When things really get bad I start seeing em0: watchdog timeout messages on the console. I looked and I don't see a lnc driver anywhere. Is there another alternative (le?) driver that I can use in place of em, if so, how? Has VMware changed what network hardware they emulate, and/or does VMware offer options about what virtual hardware to expose? The if_em driver is for Intel ethernet cards; historically VMware has exposed a Lance ethernet device supported by the lnc(4) device driver; now that driver has indeed been replaced with le(4). But if if_em is probing, it suggests a VMware change rather than a FreeBSD change, which you may be able to revert by telling it to expose a Lance-style device as opposed to an Intel device. There was recently a rather large overhaul of the if_em driver in 7.x--I suggest e-mailing Jack Vogel (jfv) who is bother a FreeBSD committer and the Intel employee responsible for the if_em driver. He may rightly point out that this isn't real hardware, rather, virtual hardware, and therefore not supported by Intel, but it might also be that the new version of the driver contains a bug, there's an ACPI issue of some sort, etc. Apart from these two issues (which are very central ones :-(), I'm using FreeBSD in a 64bit vmware workstation environment quick successfully and ZFS is quite happy with all the kva :-) ZFS and zpools are working just as I expect, even if a bit slower due to vmware but I'm not cranking out benchmarks here. Oh, and how do I fix ssh/rsh to do passwordless sessions? I'm trying to setup cron jobs to automate various tasks but there's this small hurdle called a password prompt that I can't seem to get rid of :-/ Generally speaking, this would be a discouraged configuration, but you will probably need to frob two settings: first, PermitEmptyPasswords in sshd_config, and second, force non-PAM validation by setting UsePAM to false. Instead of doing this, I would advise instead setting up an SSH key for the account, and not set a passphrase on the SSH key. This doesn't require any changing of the global sshd configuration and should offer most of the same benefits. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Experiences with 7.0-CURRENT and vmware.
On Thu, May 10, 2007 at 01:28:16PM +0100, Robert Watson wrote: On Thu, 10 May 2007, Darren Reed wrote: I'm using FreeBSD 7.0-CURRENT under vmware and there are a few issues. Redirecting to [EMAIL PROTECTED] First, time. hint.hw.acpi.disabled=1 This appears to make _no_ difference to time keeping on FreeBSD 7 and nor does it seem to have any impact on ACPI being loaded. Do I need to recompile a new kernel without it or is there a new way to disable ACPI? Have you tried hint.acpi.0.disabled=1 instead? This is what appears in acpi(4), and is what is used in various existing boot loader bits when I grep around. In another reply it was hint.apic.0.disabled=1. My current loader.conf: vm.kmem_size=536870912 vm.kmem_size_max=536870912 unset acpi_load hint.acpi.0.disabled=1 hint.apci.0.disabled=1 hint.acpi.0.disabled=1 hint.apci.0.disabled=1 vfs.zfs.arc_max=402653184 Booting with this gives me: kernel: Timecounter ACPI-safe frequency 3579545 Hz quality 1000 and ACPI enabled. I should add that FreeBSD 6, with the same setting, is no better and that I need to run ntpdate every 5-10 minutes via crontab in order to keep good time (timekeeping is *really* bad.) In one instance, i was watching zpool iostat 1 and it appeared like the rows were muching up at a rate of 2 a second for a minute or so. How do I disable TSC timekeeping? (NetBSD has this disabled by default in their kernels.) Or is there somethign else I must do? kern.timecounter.hardware: ACPI-fast kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) I believe you can simply set kern.timecounter.hardware=APCI-fast and it will do what you expect. An interesting question is why it selects what is arguably the wrong one; a post to current@ might help resolve that. Hmm. # sysctl kern.timecounter.hardware=ACPI-fast kern.timecounter.hardware: ACPI-safe sysctl: kern.timecounter.hardware: Invalid argument Or is this a loader.conf setting? Second, networking. Prior to FreeBSD-7, the driver to use inside vmware workstation was lnc. It has worked and contiues to work great. No problemo. FreeBSD-7 uses the em driver. To put it simply, it sucks in comparison. When things really get bad I start seeing em0: watchdog timeout messages on the console. I looked and I don't see a lnc driver anywhere. Is there another alternative (le?) driver that I can use in place of em, if so, how? Has VMware changed what network hardware they emulate, and/or does VMware offer options about what virtual hardware to expose? I don't believe so. It still probes as pcn under NetBSD. The if_em driver is for Intel ethernet cards; historically VMware has exposed a Lance ethernet device supported by the lnc(4) device driver; now that driver has indeed been replaced with le(4). Right. I believe it still is lance, but somehow em is showing up. But if if_em is probing, it suggests a VMware change rather than a FreeBSD change, which you may be able to revert by telling it to expose a Lance-style device as opposed to an Intel device. There's no way to choose the type of card vmware emulates. Generally speaking, this would be a discouraged configuration, but you will probably need to frob two settings: first, PermitEmptyPasswords in sshd_config, and second, force non-PAM validation by setting UsePAM to false. Instead of doing this, I would advise instead setting up an SSH key for the account, and not set a passphrase on the SSH key. This doesn't require any changing of the global sshd configuration and should offer most of the same benefits. btw, there are instances where you can be promopted 6 times for a password when logging in with ssh, 3 times with Password: prompt and another three with [EMAIL PROTECTED]'s password: promopt. Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
My PPP timer PR [nag]
Hello hackers@, bin/102747 has been sitting there for about 8 months, with no activity since it was assigned to brian@, all my mail to whom bounces [CC'd just in case]. The patch attached in the PR has been working for me since, so it not being fixed in the main tree isn't a problem with me. I just thought someone would benefit from it being committed... HAND, -- DoubleF No virus detected in this message. Ehrm, wait a minute... /kernel: pid 56921 (antivirus), uid 32000: exited on signal 9 Oh yes, no virus:) pgp19LVYYp1HM.pgp Description: PGP signature
Re: Experiences with 7.0-CURRENT and vmware.
On Thursday, 10 May 2007 at 12:54:45 +, Darren Reed wrote: On Thu, May 10, 2007 at 01:28:16PM +0100, Robert Watson wrote: On Thu, 10 May 2007, Darren Reed wrote: I'm using FreeBSD 7.0-CURRENT under vmware and there are a few issues. Redirecting to [EMAIL PROTECTED] First, time. hint.hw.acpi.disabled=1 This appears to make _no_ difference to time keeping on FreeBSD 7 and nor does it seem to have any impact on ACPI being loaded. Do I need to recompile a new kernel without it or is there a new way to disable ACPI? Have you tried hint.acpi.0.disabled=1 instead? This is what appears in acpi(4), and is what is used in various existing boot loader bits when I grep around. In another reply it was hint.apic.0.disabled=1. My current loader.conf: vm.kmem_size=536870912 vm.kmem_size_max=536870912 unset acpi_load hint.acpi.0.disabled=1 hint.apci.0.disabled=1 hint.acpi.0.disabled=1 hint.apci.0.disabled=1 vfs.zfs.arc_max=402653184 Booting with this gives me: kernel: Timecounter ACPI-safe frequency 3579545 Hz quality 1000 and ACPI enabled. I should add that FreeBSD 6, with the same setting, is no better and that I need to run ntpdate every 5-10 minutes via crontab in order to keep good time (timekeeping is *really* bad.) In one instance, i was watching zpool iostat 1 and it appeared like the rows were muching up at a rate of 2 a second for a minute or so. How do I disable TSC timekeeping? (NetBSD has this disabled by default in their kernels.) Or is there somethign else I must do? kern.timecounter.hardware: ACPI-fast kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) I believe you can simply set kern.timecounter.hardware=APCI-fast and it will do what you expect. An interesting question is why it selects what is arguably the wrong one; a post to current@ might help resolve that. Hmm. # sysctl kern.timecounter.hardware=ACPI-fast kern.timecounter.hardware: ACPI-safe sysctl: kern.timecounter.hardware: Invalid argument Or is this a loader.conf setting? Second, networking. Prior to FreeBSD-7, the driver to use inside vmware workstation was lnc. It has worked and contiues to work great. No problemo. FreeBSD-7 uses the em driver. To put it simply, it sucks in comparison. When things really get bad I start seeing em0: watchdog timeout messages on the console. I looked and I don't see a lnc driver anywhere. Is there another alternative (le?) driver that I can use in place of em, if so, how? Has VMware changed what network hardware they emulate, and/or does VMware offer options about what virtual hardware to expose? I don't believe so. It still probes as pcn under NetBSD. The if_em driver is for Intel ethernet cards; historically VMware has exposed a Lance ethernet device supported by the lnc(4) device driver; now that driver has indeed been replaced with le(4). Right. I believe it still is lance, but somehow em is showing up. But if if_em is probing, it suggests a VMware change rather than a FreeBSD change, which you may be able to revert by telling it to expose a Lance-style device as opposed to an Intel device. There's no way to choose the type of card vmware emulates. Generally speaking, this would be a discouraged configuration, but you will probably need to frob two settings: first, PermitEmptyPasswords in sshd_config, and second, force non-PAM validation by setting UsePAM to false. Instead of doing this, I would advise instead setting up an SSH key for the account, and not set a passphrase on the SSH key. This doesn't require any changing of the global sshd configuration and should offer most of the same benefits. btw, there are instances where you can be promopted 6 times for a password when logging in with ssh, 3 times with Password: prompt and another three with [EMAIL PROTECTED]'s password: promopt. Darren This is on a 6 BETA install of VMware. As you can see from below I'm using if_le. This happened by default AFAIR. Maybe I can check my config though to see if there's a way to set the interface. I don't get a chance to use this as much as I'd like though so I can't claim to have much VMware knowledge. FreeBSD beastie.dwlabs.ca 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Wed Mar 21 03:25:17 ADT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 le0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:0c:29:a4:2a:26 inet 192.168.0.102 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect status: active plip0: flags=108810POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT metric 0 mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00
New FreeBSD package system (a.k.a. Daemon Package System (dps))
Dear Jordan Recently I stumbled across a document you wrote in 2001, entitled FreeBSD installation and package tools, past, present and future. I find FreeBSD appealing and I would like to contribute it its success, and as your article describes, the installation and packaging system is lacking. Since the installation system is being tackled under a SoC project I am hoping to give the packaging system a go. I was hoping you could help me with an update about the situation with pkg. I have searched the FreeBSD mailing lists and have found little information on the package system. Once I have a (much more) complete understanding of the packaging system (and providing there is work to be done) I would like to write up a proposal to solve the problems, and perhaps provide some innovating new capabilities. After that I will gladly contribute what I can to this (possible) project and hopefully further and improve FreeBSD. Any assistance or information you can give I will be greatly appreciate. I look forward to your reply. David pgp7JOsxLJgHm.pgp Description: PGP signature
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
David Naylor wrote: Dear Jordan Recently I stumbled across a document you wrote in 2001, entitled FreeBSD installation and package tools, past, present and future. I find FreeBSD appealing and I would like to contribute it its success, and as your article describes, the installation and packaging system is lacking. Since the installation system is being tackled under a SoC project I am hoping to give the packaging system a go. I've just read the document, and since I was also thinking about the ports/packages system lately, here are a few random ideas: - I think it's time to give up on using BDB+directory tree full of text files for storing the installed packages database, and I propose all of this be replaced by a single SQLite database. SQLite is public domain (can be slurped into base system), embeddable, stores all data in a single file, lightweight, fast, and can be used to do fancy things such as reporting. The current pkg_info's behaviour that takes *noticable* *time* to generate 1 line of output per package is horrible in this day and age. And the upcoming X11/X.Org 7.2 with cca 400 packages (which is in itself horrible just for a X11 system) will make it unbearable (also portupgrade which already looks slower by the day). - A quick test confirms that the current bsdtar will happily ignore any extra data at the end of a tgz/tbz archive, so package metadata can be embedded there, thus conserving existing infrastructure and being fast to parse. I suggest encoding this metadata in a sane and easy to parse XML structure. I cannot currently actively participate in implementing proposed things, but I can give advice on sqlite, database and xml schemas if anyone wants to... signature.asc Description: OpenPGP digital signature
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
Ivan Voras wrote: David Naylor wrote: Dear Jordan Recently I stumbled across a document you wrote in 2001, entitled FreeBSD installation and package tools, past, present and future. I find FreeBSD appealing and I would like to contribute it its success, and as your article describes, the installation and packaging system is lacking. Since the installation system is being tackled under a SoC project I am hoping to give the packaging system a go. I've just read the document, and since I was also thinking about the ports/packages system lately, here are a few random ideas: - I think it's time to give up on using BDB+directory tree full of text files for storing the installed packages database, and I propose all of this be replaced by a single SQLite database. SQLite is public domain (can be slurped into base system), embeddable, stores all data in a single file, lightweight, fast, and can be used to do fancy things such as reporting. The current pkg_info's behaviour that takes *noticable* *time* to generate 1 line of output per package is horrible in this day and age. And the upcoming X11/X.Org 7.2 with cca 400 packages (which is in itself horrible just for a X11 system) will make it unbearable (also portupgrade which already looks slower by the day). ok, let me give you some words that come from the wisdom of having done this for 30 years. Use an SQL DB file for this over my dead body.. Now having said that, I need to modify it a bit and explain. Explanation: The number of times I've gone into /var/db/pkg to read the files to figure out what the fsck is going on, is very large. It is also possible to delete files and edit them. This is very important to me in this imperfect world when the pkg system gets things wrong (oh no, don't tell me that the new pkg system never gets things wrong.. like including a file in 2 packages). Modification: Now, I have no objection to a DB file of some sort IF (and only if) it is somehow rebuildable from a text base which is kept somewhere, like the password database is done. but PLEASE, NO SQL in the base system! - A quick test confirms that the current bsdtar will happily ignore any extra data at the end of a tgz/tbz archive, so package metadata can be embedded there, thus conserving existing infrastructure and being fast to parse. I suggest encoding this metadata in a sane and easy to parse XML structure. I cannot currently actively participate in implementing proposed things, but I can give advice on sqlite, database and xml schemas if anyone wants to... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
In [EMAIL PROTECTED], Ivan Voras [EMAIL PROTECTED] typed: I cannot currently actively participate in implementing proposed things, but I can give advice on sqlite, database and xml schemas if anyone wants to... One of the things that would be nice for a replacement to do would be to correctly install i386 packages on amd64 platforms (and similar things). The binaries will run if we have all the libraries installed, but getting them installed is painful. At the very least, an installed package needs to know what platform it was built for, so that packages being installed cross-platform have a chance of figuring out whether or not the installed version of FOO will work for them, or they need to get a version for their specific platform. If the new version can't make cross-platform installs work, hopefully that goal can be kept in mind while the work is beign done. Personally, I'd still like LOCALBASE to move out of /usr/local. Maybe it's time to reconsider that. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On Thu, May 10, 2007 at 09:47:49PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Ivan Voras [EMAIL PROTECTED] typed: I cannot currently actively participate in implementing proposed things, but I can give advice on sqlite, database and xml schemas if anyone wants to... One of the things that would be nice for a replacement to do would be to correctly install i386 packages on amd64 platforms (and similar things). This has nothing to do with a new packaging system and can be done today if someone cares enough to work on it. The binaries will run if we have all the libraries installed, but getting them installed is painful. At the very least, an installed package needs to know what platform it was built for, so that packages being installed cross-platform have a chance of figuring out whether or not the installed version of FOO will work for them, or they need to get a version for their specific platform. If the new version can't make cross-platform installs work, hopefully that goal can be kept in mind while the work is beign done. Personally, I'd still like LOCALBASE to move out of /usr/local. Maybe it's time to reconsider that. Not gonna happen as a default, but you can change it on your systems if you like. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
In [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] typed: On Thu, May 10, 2007 at 09:47:49PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Ivan Voras [EMAIL PROTECTED] typed: I cannot currently actively participate in implementing proposed things, but I can give advice on sqlite, database and xml schemas if anyone wants to... One of the things that would be nice for a replacement to do would be to correctly install i386 packages on amd64 platforms (and similar things). This has nothing to do with a new packaging system and can be done today if someone cares enough to work on it. Well, yeah - *anything* can be done if someone cares enough to work on it - it's all just SMOP. You could definitely put enough smarts into the package installer do this without actually changing the packaging system. But if we're gonna change the packaging system anyway, why not consider adding information that the package building software already has so that the package installer software doesn't have to try and figure it out? The binaries will run if we have all the libraries installed, but getting them installed is painful. At the very least, an installed package needs to know what platform it was built for, so that packages being installed cross-platform have a chance of figuring out whether or not the installed version of FOO will work for them, or they need to get a version for their specific platform. If the new version can't make cross-platform installs work, hopefully that goal can be kept in mind while the work is beign done. Personally, I'd still like LOCALBASE to move out of /usr/local. Maybe it's time to reconsider that. Not gonna happen as a default, but you can change it on your systems if you like. Not very reliably. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On Thu, May 10, 2007 at 10:03:22PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] typed: On Thu, May 10, 2007 at 09:47:49PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Ivan Voras [EMAIL PROTECTED] typed: I cannot currently actively participate in implementing proposed things, but I can give advice on sqlite, database and xml schemas if anyone wants to... One of the things that would be nice for a replacement to do would be to correctly install i386 packages on amd64 platforms (and similar things). This has nothing to do with a new packaging system and can be done today if someone cares enough to work on it. Well, yeah - *anything* can be done if someone cares enough to work on it - it's all just SMOP. You could definitely put enough smarts into the package installer do this without actually changing the packaging system. But if we're gonna change the packaging system anyway, why not consider adding information that the package building software already has so that the package installer software doesn't have to try and figure it out? Sure, we could pile on some more features onto a 6 year old design document that never got out of the design phase, or someone could just go and make the relatively minor changes to support i386 packages on amd64 now. I guess it's always more fun to build dream castles though :) Not gonna happen as a default, but you can change it on your systems if you like. Not very reliably. Best I can offer ;) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
In [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] typed: On Thu, May 10, 2007 at 10:03:22PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] typed: On Thu, May 10, 2007 at 09:47:49PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Ivan Voras [EMAIL PROTECTED] typed: I cannot currently actively participate in implementing proposed things, but I can give advice on sqlite, database and xml schemas if anyone wants to... One of the things that would be nice for a replacement to do would be to correctly install i386 packages on amd64 platforms (and similar things). This has nothing to do with a new packaging system and can be done today if someone cares enough to work on it. Well, yeah - *anything* can be done if someone cares enough to work on it - it's all just SMOP. You could definitely put enough smarts into the package installer do this without actually changing the packaging system. But if we're gonna change the packaging system anyway, why not consider adding information that the package building software already has so that the package installer software doesn't have to try and figure it out? Sure, we could pile on some more features onto a 6 year old design document that never got out of the design phase, or someone could just go and make the relatively minor changes to support i386 packages on amd64 now. I guess it's always more fun to build dream castles though :) Last time I looked into this, it didn't look relatively minor to me. But hey, if there's a document listing what needs to be done somewhere and it's really relatively minor, I need this bad enough to deal with that. On the other hand, if no one has actually done the work to figure out what this would really take, is wishful thinking really enough to keep a very desirable feature (well, it's desirable enough that most Linux platforms seem to offer it) from even being considered? Not gonna happen as a default, but you can change it on your systems if you like. Not very reliably. Best I can offer ;) Is this the new motto for FreeBSD? Good QA practices would have the ports built with that knob set to something something other than the default at regular intervals. Lately things have been better, but I've found broken things in the last twelve months. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
David Naylor wrote: Dear Jordan Recently I stumbled across a document you wrote in 2001, entitled FreeBSD installation and package tools, past, present and future. I find FreeBSD appealing and I would like to contribute it its success, and as your article describes, the installation and packaging system is lacking. Since the installation system is being tackled under a SoC project I am hoping to give the packaging system a go. I was hoping you could help me with an update about the situation with pkg. I have searched the FreeBSD mailing lists and have found little information on the package system. Once I have a (much more) complete understanding of the packaging system (and providing there is work to be done) I would like to write up a proposal to solve the problems, and perhaps provide some innovating new capabilities. After that I will gladly contribute what I can to this (possible) project and hopefully further and improve FreeBSD. Any assistance or information you can give I will be greatly appreciate. I look forward to your reply. David Yipes. The name of the game is to get something working in the base system, instead of dragging in multiple 3rd party packages, with licensing schemes that may not be aligned with the BSD license. SQL's great, SQL's wonderful for db use, but the problem is that supporting it from my POV would cause a lot more grief and waiting than having me wait a few months to get a BDB compatible scheme out the door. If only Oracle didn't make BDB 3.x non-BSD license friendly though.. that would be nice.. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On Thu, May 10, 2007 at 11:15:37PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] typed: On Thu, May 10, 2007 at 10:03:22PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] typed: On Thu, May 10, 2007 at 09:47:49PM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Ivan Voras [EMAIL PROTECTED] typed: I cannot currently actively participate in implementing proposed things, but I can give advice on sqlite, database and xml schemas if anyone wants to... One of the things that would be nice for a replacement to do would be to correctly install i386 packages on amd64 platforms (and similar things). This has nothing to do with a new packaging system and can be done today if someone cares enough to work on it. Well, yeah - *anything* can be done if someone cares enough to work on it - it's all just SMOP. You could definitely put enough smarts into the package installer do this without actually changing the packaging system. But if we're gonna change the packaging system anyway, why not consider adding information that the package building software already has so that the package installer software doesn't have to try and figure it out? Sure, we could pile on some more features onto a 6 year old design document that never got out of the design phase, or someone could just go and make the relatively minor changes to support i386 packages on amd64 now. I guess it's always more fun to build dream castles though :) Last time I looked into this, it didn't look relatively minor to me. But hey, if there's a document listing what needs to be done somewhere and it's really relatively minor, I need this bad enough to deal with that. There are a few ways you can go. The simplest is to install a complete i386 world in e.g. /compat/ia32 and have i386 packages installed there, and change the kernel to do a magic directory lookup for i386 binaries that does path munging like the linuxulator does with /compat/linux. If you want the i386 packages to live in /usr/local alongside the amd64 packages, you'll need to do something like adding an @arch directive to the +CONTENTS file recorded in /var/db/pkg, and add some checking to pkg_add to ensure that when you install a package, everything it depends on was built for the same architecture. You'd need to also add these checks to bsd.port.mk so it exits gracefully when someone tries to natively compile a port for which non-native dependencies are installed (e.g. it's going to be really unhappy if it finds i386 headers or libraries). This method might be more trouble than it's worth. On the other hand, if no one has actually done the work to figure out what this would really take, is wishful thinking really enough to keep a very desirable feature (well, it's desirable enough that most Linux platforms seem to offer it) from even being considered? You misunderstand me: by all means people should work on improving our package infrastructure -- but it's wrong to pin your hopes on a possibly mythical future event when you can easily solve a problem today. Not gonna happen as a default, but you can change it on your systems if you like. Not very reliably. Best I can offer ;) Is this the new motto for FreeBSD? Good QA practices would have the ports built with that knob set to something something other than the default at regular intervals. Lately things have been better, but I've found broken things in the last twelve months. You'll be delighted to know that I have been doing precisely this for the past few years. If you're interested I'll CC you the errors from my next build so you can help work on improving compliance. Kris pgpppJiFJPNzY.pgp Description: PGP signature
