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
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 09/01/2012 23:01, Matthew Seaman wrote: As rebuilding the repo database is something you'ld do routinely anyhow as part of normal maintenance Errr ... what? Why would this be true? Doesn't pkg keep the repo database up to date as it's making changes? -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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 09/01/2012 12:59, Garrett Cooper wrote: 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. Garrett, I think you're seriously misunderstanding how pkg is going to work. One thing we desperately want to get away from is tying ports stuff to specific base releases. Can you please be more clear as to why you keep trying to pull things back in the wrong direction? -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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
On 08/30/2012 09:16, Dimitry Andric wrote: [Note that linking GPL-contaminated code into your kernel proper is, shall we say, ideologically impure ;-) But that is not the issue here.] Can you keep this kind of stuff to -chat please? The more we deal with the technical aspects the better off we will all be. I for one put ext2fs in my kernel config because I have critical stuff on those file systems and I both do want the speed boost and don't want to worry about what's going to happen when I boot a new kernel. Tools, not policy. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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 02/09/2012 08:16, Doug Barton wrote: On 09/01/2012 23:01, Matthew Seaman wrote: As rebuilding the repo database is something you'ld do routinely anyhow as part of normal maintenance Errr ... what? Why would this be true? Doesn't pkg keep the repo database up to date as it's making changes? Other tools like poudriere or tinderbox are used to maintain the repository -- building ports etc. These tools invoke 'pkg create' to create each individual pkg tarball, and at the end of a session of package building invoke 'pkg repo' one time to update the repository catalogue. It's that last step I was describing. Mind you, having a mode to add a package to the repo and update the catalogue all in one would be pretty useful. Good idea. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Bull Mountain (IvyBridge +) random number generator
It is relatively well known that Ivy Bridge CPUs (Core iX 3XXX) have built-in hardware random number generator, which is claimed to be both very fast and high quality. Generator is accessible using non-privileged RDRAND instruction. It is claimed that CPU performs sanitization of the random sequence. In particular, it seems that paranoid AES encryption of the raw random stream, performed by our padlock driver, is not needed for Bull Mountain (there are hints that hardware performs it already). See http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0 http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/ and IA32 ADM. Patch at http://people.freebsd.org/~kib/misc/bull_mountain.2.patch implements support for the generator. I do not own any IvyBridge machines, so I cannot test. Patch makes both padlock and bull generators the options, you need to enable IVY_RNG to get support for the generator. I would be interested in seeing reports including verbose boot dmesg, and some tests of /dev/random quality on the IvyBridge machines, you can start with http://lists.gnupg.org/pipermail/gnupg-devel/2000-March/016328.html. Thanks. pgpWI1zFeuN0l.pgp Description: PGP signature
