Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 02/09/2012 01:04, Tim Kientzle wrote: > Will new versions of pkgng support old packages? > > Some folks maintain their own package repositories and > will get rather grumpy if an update to pkgng requires them > to rebuild their entire repository. There's a distinction between the format of pkg tarballs, and the formats of the repository catalogue database or the locally installed packages database. If you're maintaining your own repository, then an update to the repo catalogue format means you'ld just need to re-run 'pkg repo'. You won't need to rebuild all the existing package tarballs in your repository. If the repository catalogue format has changed, pkg repo will detect this, and automatically do a full repo catalogue rebuild rather than an incremental one. As rebuilding the repo database is something you'ld do routinely anyhow as part of normal maintenance I don't see this as being a significant extra burden. Similarly, an update to the locally installed packages database schema will be applied transparently when you first use the updated version of pkgng. It won't require you to reinstall any packages. There aren't any plans to change the pkg tarball format that I know of at the moment, but if there were, then they certainly would have to maintain backwards compatibility -- old pkg tarballs will still work with the newer pkgng. Not sure about any guarantees that vice-versa would always work, but way the YAML metadata in the pkg tarball is handled is tolerant of new additions, so it should usually be possible to arrange things so that an older pkgng can cope with a newer pkg tarball. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
[PATCH] Locking for bt(4)
I have patches to add locking for the bt(4) driver if anyone is able to test them. The patches should apply to 8 or 9 as well as HEAD. Please enable INVARIANTS during at least initial testing. Thanks. http://www.FreeBSD.org/~jhb/patches/bt_locking.patch -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sep 1, 2012, at 12:40 PM, Matthew Seaman wrote: > On 01/09/2012 18:43, Tijl Coosemans wrote: >> In this scenario the ports tree needs to keep support for older releases, >> but that's a consequence of the fact that there's only one ports tree for >> all releases. Somewhere in between the ports and the various releases there >> has to be some form encapsulation, not just for pkg, but for all the tools >> used by the ports tree. Given how the ports tree currently encapsulates >> both the old and new pkg tools I don't see how supporting multiple versions >> of pkgng would be a problem because presumably the difference between pkgng >> versions is going to be much smaller than the difference between the old >> and new tools. > > New functionality already in the process of development will entail > making non-backwards compatible changes to the DB schema. If we're tied > to supporting a version of pkgng bundled with a release, that's going to > make rolling out such changes much harder. On the other hand, if pkgng > is in ports, then we can release a new version and simultaneously > publish new package sets (incorporating the update to pkgng) from the > repositories which will have been built using the updated DB schema. Will new versions of pkgng support old packages? Some folks maintain their own package repositories and will get rather grumpy if an update to pkgng requires them to rebuild their entire repository. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sat, Sep 01, 2012 at 08:40:03PM +0100, Matthew Seaman wrote: > On 01/09/2012 18:43, Tijl Coosemans wrote: > > In this scenario the ports tree needs to keep support for older releases, > > but that's a consequence of the fact that there's only one ports tree for > > all releases. Somewhere in between the ports and the various releases there > > has to be some form encapsulation, not just for pkg, but for all the tools > > used by the ports tree. Given how the ports tree currently encapsulates > > both the old and new pkg tools I don't see how supporting multiple versions > > of pkgng would be a problem because presumably the difference between pkgng > > versions is going to be much smaller than the difference between the old > > and new tools. > New functionality already in the process of development will entail > making non-backwards compatible changes to the DB schema. If we're tied > to supporting a version of pkgng bundled with a release, that's going to > make rolling out such changes much harder. On the other hand, if pkgng > is in ports, then we can release a new version and simultaneously > publish new package sets (incorporating the update to pkgng) from the > repositories which will have been built using the updated DB schema. One restriction is that the old pkg should be able to detect the new pkg package in the repository. If not, users of an old version will have to install the new pkg manually. This restriction is much weaker than requiring an upgrade using the old pkg, mainly because pkg does not depend on anything else. All other packages can use features and bugfixes in the new pkg and need not carry around workarounds for years. If the base system is also managed by pkg, which is currently not the case, the assumption that the pkg package does not depend on anything may no longer hold. It might depend on a new libc in the new base system, for example. > The ports tree doesn't track the versioning of the base system, and it > makes perfect sense to me that tools for dealing with the ports should > follow changes to ports rather than changes to the base. Yes. -- Jilles Tjoelker ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sat, Sep 1, 2012 at 12:40 PM, Matthew Seaman wrote: > On 01/09/2012 18:43, Tijl Coosemans wrote: >> In this scenario the ports tree needs to keep support for older releases, >> but that's a consequence of the fact that there's only one ports tree for >> all releases. Somewhere in between the ports and the various releases there >> has to be some form encapsulation, not just for pkg, but for all the tools >> used by the ports tree. Given how the ports tree currently encapsulates >> both the old and new pkg tools I don't see how supporting multiple versions >> of pkgng would be a problem because presumably the difference between pkgng >> versions is going to be much smaller than the difference between the old >> and new tools. > > New functionality already in the process of development will entail > making non-backwards compatible changes to the DB schema. If we're tied > to supporting a version of pkgng bundled with a release, that's going to > make rolling out such changes much harder. On the other hand, if pkgng > is in ports, then we can release a new version and simultaneously > publish new package sets (incorporating the update to pkgng) from the > repositories which will have been built using the updated DB schema. > > The ports tree doesn't track the versioning of the base system, and it > makes perfect sense to me that tools for dealing with the ports should > follow changes to ports rather than changes to the base. Again, this is part of the reason why I suggested multiple release trains. Although it's more painful for bapt@, et all, it's ultimately what would need to be done in order for pkgng to be packaged with a release or set of releases. I would be happy to assist with this -- it's the least I could do. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't build FreeBSD-head with CLANG
-- Eir Nym On 1 September 2012 03:12, Dimitry Andric wrote: > On 2012-08-30 18:43, Eir Nym wrote: >> >> On 30 August 2012 20:16, Dimitry Andric wrote: > > ... > >>> It seems the WERROR= in the xfs module Makefile was right there from the >>> start, but it was never removed. I have compiled it using gcc, and >>> there are actually no warnings from gcc at all. With clang, there are >>> several warnings, so I have added a few workaround -Wno-xxx flags for >>> them. > > > I committed the fixes in r239959. I tried building your GENERIC_PF > kernel configuration, and it worked just fine now. Thank you! I'll review my configurations and rebuild my box. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 01/09/2012 18:43, Tijl Coosemans wrote: > In this scenario the ports tree needs to keep support for older releases, > but that's a consequence of the fact that there's only one ports tree for > all releases. Somewhere in between the ports and the various releases there > has to be some form encapsulation, not just for pkg, but for all the tools > used by the ports tree. Given how the ports tree currently encapsulates > both the old and new pkg tools I don't see how supporting multiple versions > of pkgng would be a problem because presumably the difference between pkgng > versions is going to be much smaller than the difference between the old > and new tools. New functionality already in the process of development will entail making non-backwards compatible changes to the DB schema. If we're tied to supporting a version of pkgng bundled with a release, that's going to make rolling out such changes much harder. On the other hand, if pkgng is in ports, then we can release a new version and simultaneously publish new package sets (incorporating the update to pkgng) from the repositories which will have been built using the updated DB schema. The ports tree doesn't track the versioning of the base system, and it makes perfect sense to me that tools for dealing with the ports should follow changes to ports rather than changes to the base. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 9/1/2012 7:43 PM, Tijl Coosemans wrote: On 31-08-2012 14:22, Baptiste Daroussin wrote: On Fri, Aug 31, 2012 at 08:10:50AM -0400, John Baldwin wrote: On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. I like the idea of also providing a self-installing package, and it seems really easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5 minutes which looks pretty good, this could also be a very simple and easy way to integrate into bsdinstaller. I'll do work in that direction. Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. I do think that is something bsdinstall should be able to handle, and I would certainly want bsdinstall to include a dialog that says "do you want to install the package manager?" Of course this is being worked on by dteske@ on his bsdconfig scripts, so yes in anycase the bsdinstaller will end up with a boostrap dialog to install pkgng. Something else I thought of, you can't assume there's a working internet connection during installation. And also, even if there is a connection, can you guarantee that the downloaded pkg supports the packages on the dvd for the lifetime of the release? The packages set included on the dvd will probably be EOLed before the lifetime of the release. I really think you should just do vendor imports of pkg in base and include pkg on the dvd. There's no bootstrap problem then and the dvd is nicely self-contained. It also shouldn't be a problem to keep the official pkg repo for that release compatible with it. Just keep using the same version of pkg to create the repo. You've been able to develop and introduce pkgng without breaking older releases which shows having pkg tools tied to releases was never a problem. All that was needed was to move pkg development outside base. You should be able to do pkg 2.0 development in the same way. And when that new version is ready you import betas and release candidates in head and use current users as testers, just like is done with clang. In this scenario the ports tree needs to keep support for older releases, but that's a consequence of the fact that there's only one ports tree for all releases. Somewhere in between the ports and the various releases there has to be some form encapsulation, not just for pkg, but for all the tools used by the ports tree. Given how the ports tree currently encapsulates both the old and new pkg tools I don't see how supporting multiple versions of pkgng would be a problem because presumably the difference between pkgng versions is going to be much smaller than the difference between the old and new tools. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 31-08-2012 14:22, Baptiste Daroussin wrote: > On Fri, Aug 31, 2012 at 08:10:50AM -0400, John Baldwin wrote: >> On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote: >>> On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. >>> >>> I like the idea of also providing a self-installing package, and it seems >>> really >>> easy to do, so I'll try to see what I can do in this area I'll wrote a PoC >>> in 5 >>> minutes which looks pretty good, this could also be a very simple and easy >>> way >>> to integrate into bsdinstaller. >>> >>> I'll do work in that direction. >>> >>> Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, >>> because the user may not know where to download the pkg-setup.sh. >> >> I do think that is something bsdinstall should be able to handle, and I would >> certainly want bsdinstall to include a dialog that says "do you want to >> install >> the package manager?" > > Of course this is being worked on by dteske@ on his bsdconfig scripts, so yes > in > anycase the bsdinstaller will end up with a boostrap dialog to install pkgng. Something else I thought of, you can't assume there's a working internet connection during installation. And also, even if there is a connection, can you guarantee that the downloaded pkg supports the packages on the dvd for the lifetime of the release? I really think you should just do vendor imports of pkg in base and include pkg on the dvd. There's no bootstrap problem then and the dvd is nicely self-contained. It also shouldn't be a problem to keep the official pkg repo for that release compatible with it. Just keep using the same version of pkg to create the repo. You've been able to develop and introduce pkgng without breaking older releases which shows having pkg tools tied to releases was never a problem. All that was needed was to move pkg development outside base. You should be able to do pkg 2.0 development in the same way. And when that new version is ready you import betas and release candidates in head and use current users as testers, just like is done with clang. In this scenario the ports tree needs to keep support for older releases, but that's a consequence of the fact that there's only one ports tree for all releases. Somewhere in between the ports and the various releases there has to be some form encapsulation, not just for pkg, but for all the tools used by the ports tree. Given how the ports tree currently encapsulates both the old and new pkg tools I don't see how supporting multiple versions of pkgng would be a problem because presumably the difference between pkgng versions is going to be much smaller than the difference between the old and new tools. signature.asc Description: OpenPGP digital signature
Re: rpcbind does not honor -h flag
Hi! > Please file a PR against rc ASAP. > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117711 > Looks like Matteo Riondato had created a patch for the problem in 2008: > > http://people.freebsd.org/~matteo/diff/117711rpcbind.diff > > but he never received any feedback from Carlos Eduardo Monti to see if > the patch fixed the problem. > I don't know if the patch will apply to the current FreeBSD rpcbind > code, give it a try and submit a follow up to the PR. In the current form the patch fails in rpcbind.c on 9.1-RC1. There are two problems with the current rpcbind.c. 1) It seems to be that even if some -h is given, the rpcbind code uses some SUN-RPC trickery around the /etc/netconfig file to open sockets for localhost in v4 and v6. Is it required to bind to localhost according to the RPC spec ? 2) And it opens some dynamic ports for other uses -- anybody has an idea why this is necessary ? Is there an requirement for this in the spec ? Below is an example of both issues. root rpcbind2134 4 udp6 *:* *:* root rpcbind2134 5 stream /var/run/rpcbind.sock root rpcbind2134 6 udp6 *:111 *:* root rpcbind2134 7 udp6 *:924 *:* root rpcbind2134 8 tcp6 *:111 *:* root rpcbind2134 9 udp4 *:111 *:* root rpcbind2134 10 udp4 *:645 *:* root rpcbind2134 11 tcp4 *:111 *:* Here's rpcbind started with -h : root rpcbind2195 4 udp6 *:* *:* root rpcbind2195 5 stream /var/run/rpcbind.sock root rpcbind2195 6 udp6 ::1:111 *:* root rpcbind2195 7 udp6 *:1013*:* root rpcbind2195 8 tcp6 ::1:111 *:* root rpcbind2195 9 udp4 127.0.0.1:111 *:* root rpcbind2195 10 udp4 :111*:* root rpcbind2195 11 udp4 *:634 *:* root rpcbind2195 12 tcp4 127.0.0.1:111 *:* root rpcbind2195 13 tcp4 :111*:* One can see two dynamic udp ports opened (one v4, one v6). I might be naive, but from what I understand, it should not open that many sockets, but only like this: root rpcbind2195 10 udp4 :111*:* root rpcbind2195 13 tcp4 :111*:* If this naive 'spec' is correct, would a patch to do just this and nothing more be OK ? -- p...@opsec.eu+49 171 3101372 8 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re[2]: misc/171209: ping: sendto: Invalid argument
Hi, Gleb. GS> Can you please provide your full host configuration: rc.conf, firewall GS> rules if there are any? How to repeat: ifconfig rl0 add 192.168.0.2/24 route add default 192.168.1.1 192.168.1.1 is not on my LAN 192.168.0.0/24 FreeBSD must log right error messages so people can understood that it is mean. --- kernel: arpresolve: can't allocate llinfo for 10.11.19.52 +++ kernel: 10.11.19.52 is not on your LAN ---ping: sendto: Invalid argument +++ping: sendto: gateway to host is not on LAN ---traceroute: sendto: Invalid argument +++traceroute: sendto: gateway to host is not on LAN -- С уважением, Eugen mailto:kes-...@yandex.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH] Locking for aic(4)
Still working on patches for drivers from the last century. The latest installment is a patch for aic(4). It should apply to 8 and 9 as well as HEAD. Please ensure INVARIANTS is enabled during testing. http://www.FreeBSD.org/~jhb/patches/aic_locking.patch -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
