Re: [gentoo-dev] Re: rfc: news item for app-backup/bacula
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 30 Dec 2011 12:02:09 -0500 Jonathan Callen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 12/30/2011 06:09 AM, Thomas Beierlein wrote: > > On Fri, 30 Dec 2011 11:44:23 +0100 Michał Górny > > wrote: > > > >> On Fri, 30 Dec 2011 10:43:31 +0100 Thomas Beierlein > >> wrote: > >> > >>> 4. Run the appropriate upgrade script from > >>> /usr/libexec/bacula/updatedb/. 7. Start the new Bacula. > >> > >> You still miss steps 5 and 6 ;P. > >> > > > > Oh, oh. Now I read your last line from former mail right. > > Corrected, thanks again. > > > > Thomas > > > > Title: Bacula-5.2.3 Upgrade Author: Thomas Beierlein > > Content-Type: text/plain Posted: 2011-12-30 > > Revision: 3 > This should remain as Revision: 1 until actually committed to svn. Ok, thanks. It was not so clear from reading the GLEP. > > > News-Item-Format: 1.0 Display-If-Installed: > > " You need to drop the quotes here. > Done. Regards, Thomas > > > > The 5.2.x release series of Bacula use a new database catalog > > format. If you're upgrading from a 3.x.x or 5.0.x release, you must > > upgrade your bacula catalog database. > > > > Please read the manual chapter for how to upgrade your database > > (see > > http://www.bacula.org/5.2.x-manuals/en/main/main/Installing_Bacula.html). > > > > > You can find database upgrade scripts > in /usr/libexec/bacula/(updatedb/). > > > > It is strongly recommended that you save a copy of your existing > > database before upgrading. For details how to do it please look > > into your database documentation. > > > > The simplest way to upgrade the database: > > > > 1. Stop Bacula from running (at least the director and storage > > daemons). 2. Save a copy of your existing database. 3. Emerge the > > new version of Bacula. 4. Run the appropriate upgrade script from > > /usr/libexec/bacula/updatedb/. 5. Start the new Bacula. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.18 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBCgAGBQJO/e6RAAoJELHSF2kinlg4b/IP/jrMPdNAz0eqQDi4jPtQoef5 > prG0NwfpnSfKq0vTCf+CS+tSezGgrn2GsnfAp+GFngEPAed8zZlylGsViusQjR5w > uOPkLlaYwGiKzlUjoronqm83GLbGRw2IZJuxr96t6wsk2PWMSIs4SLLDRRoA8Lis > /yZ6YtuWpkaxqdtR7GIwpW2uTK7b0L7LSR1UyIe7YO5bTQ3wlLVneysxfcNadNAh > JrT1Hi1oGR/SRtWP/J43M26mpTSibqaJjE9vU+4/UVUApquKUB/Cw8x6lPgh/hZz > 1JemFwHWeozIr6zUu0OOoqI3oN4nkO7cFyqVcZYezx5WEuaEK+NFLiNIrqFQFyyQ > uPYgKCXFmW32rhWXKVeIYNjTiX9RYrFsEUnyTOKltD5s2sGMYd0xiplYAPZDml3n > ZUTU/swMp469N5qaYq1XNrpM0GE1QztG0/Le6lvngkSIo59j330d4VsvYT410jdl > +AmFaVuTFVfvRl3A7f1B9iZ2v9HKQvguFcraC2Vp6o4QQ/TbHJqbzn9PpXjCXhjL > 5msQM/UvlaxWlK87BqXFzwUMb9lC5kRu6qqPfmevDtrkT5jaCPNAubcdz8Gnlo89 > w8grtnCNVWNbfMBVxIzOsSR1ESKAQqkm6jkgkPJnPrcrvtIi6QQhek6r59r3FIon > uSmV/1RoedqyGGsdxVyD > =urxy > -END PGP SIGNATURE- > - -- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7+6TQACgkQQe4uqXYgU9Us9wCgx+PHKgs75PQquqtS3heZzsdI rWUAn1CaXMoLAFm4QO4mmdgzGb+CSp0z =trfu -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: news item for app-backup/bacula
On Fri, Dec 30, 2011 at 10:11:58AM +0100, Michał Górny wrote: > On Fri, 30 Dec 2011 09:56:33 +0100 > Thomas Beierlein wrote: > > > The 5.2.x release series of Bacula uses a new database catalog format. > ^^^ use (singular) No, "uses" is correct here. William pgpGV23zfvRt1.pgp Description: PGP signature
Re: [gentoo-dev] rfc: news item for app-backup/bacula
On Sat, 2011-12-31 at 08:56 -0600, William Hubbs wrote: > On Fri, Dec 30, 2011 at 10:11:58AM +0100, Michał Górny wrote: > > On Fri, 30 Dec 2011 09:56:33 +0100 > > Thomas Beierlein wrote: > > > > > The 5.2.x release series of Bacula uses a new database catalog format. > > ^^^ use (singular) > > No, "uses" is correct here. Right. The word "series" has the same form in both singular and plural; in this case, it refers to a single, well-defined group of releases, so using it as singular is correct. See http://en.wiktionary.org/wiki/series#English and http://forum.wordreference.com/showthread.php?t=942433
[gentoo-dev] rfc: locations of binaries and separate /usr
All, a significant change is taking place with several upstreams that will affect us in gentoo, so I wanted to bring it to the list for discussion. Udev, kmod (which is a replacement for module-init-tools which will be needed by >=udev-176), systemd, and soon others, are advocating a major change to the locations where binaries and libraries are stored on linux systems. The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My understanding is that they want to move software that is installed in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move everything from /lib to /usr/lib. I have been working with robbat2 on solutions to the separate /usr issue (That is why I have specifically cc'd him on this email) which will allow people to not use an initramfs. If we migrate everything off of the root fs to /usr, all of those solutions become moot. On the other hand, if we don't migrate, we run the risk of eventually having our default configuration not supported by upstream. I see three options: 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. 2) Combine the sbin and bin directories both on the root filesystem and in /usr by moving things from /sbin to /bin and /usr/sbin to /usr/bin. 3) Try to maintain things the way they are as long as possible. Whether or not I like what is happening personally, I think we should consider the first option, because I think it will get more and more difficult for us to do anything else over time. And we will eventually find ourselves not supported by upstreams. Please discuss; I want to hear what you think. William pgpZfYv962yoV.pgp Description: PGP signature
[gentoo-dev] python.eclass: export pkg_setup
python.eclass currently exports the pkg_setup function under the
following circumstances:
EAPI 2, 3: When ${PYTHON_USE_WITH} or ${PYTHON_USE_WITH_OR} are defined.
EAPI 4: Always exported.
I would like to modify python.eclass to export pkg_setup
unconditionally, rather than checking EAPI and random variables. This
will make the eclass behave more consistently, which seems like a good
thing.
This may cause problems in ebuilds which inherit python after another
eclass which exports pkg_setup if the ebuild does not override pkg_setup
itself. For example:
EAPI=3
inherit fortran-2 python
With a bit of hackery in ebuild.sh (thanks to Arfrever), I have compiled
a list of ebulids which may need to be modified. This will generally
mean reordering the eclasses in the inherit line, or defining a
pkg_setup function in the ebuild.
Barring any objections, I will make any necessary modifications to these
ebuilds over the next week or so, and commit the change to python.eclass
next weekend. If anyone has a better idea for rolling this out, please
speak up. :)
Here is the list of ebuilds, along with the pkg_setup function being
overridden.
gentoo-x86:
app-portage/maintainer-helper-0.1.2: qt4_pkg_setup
dev-python/pypy-1.7: check-reqs_pkg_setup
media-plugins/mythnetvision-0.23.1_p26407: mythtv-plugins_pkg_setup
sci-chemistry/pdb-tools-0.1.4-r3: fortran-2_pkg_setup
sci-chemistry/pdb2pqr-1.5.0-r2: fortran-2_pkg_setup
sci-chemistry/pdb2pqr-1.7.0: fortran-2_pkg_setup
sci-libs/libsvm-2.90-r1: java-pkg-opt-2_pkg_setup
sci-libs/libsvm-3.0: java-pkg-opt-2_pkg_setup
sci-physics/camfr-20070717-r2: fortran-2_pkg_setup
www-apache/mod_wsgi-3.3: apache_pkg_setup
www-apps/venus-20100911: webapp_pkg_setup
sunrise:
games-puzzle/pythonsudoku-0.13: games_pkg_setup
games-rpg/pylotro-0.1.14: games_pkg_setup
media-libs/portmidi-217: java-pkg-opt-2_pkg_setup
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Sat, 31 Dec 2011 19:59:47 -0600 William Hubbs wrote: > Udev, kmod (which is a replacement for module-init-tools which will be needed > by >=udev-176), systemd, and soon others, are advocating a major change > to the locations where binaries and libraries are stored on linux > systems. > > The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My > understanding is that they want to move software that is installed in > /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move > everything from /lib to /usr/lib. I coulda swore April was another four months away... -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Hi, On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote: > I have been working with robbat2 on solutions to the separate /usr issue > (That is why I have specifically cc'd him on this email) > which will allow people to not use an initramfs. If we migrate > everything off of the root fs to /usr, all of those solutions become > moot. On the other hand, if we don't migrate, we run the risk of > eventually having our default configuration not supported by upstream. I think the general consensus among other distros is that initramfs is the new /. Many core elements of the Linux system will start installing themselves in /usr, starting with udev, so we won't have a choice anyway. Also, I doubt it's currently possible to boot a Gentoo system without /usr mounted anyway. > 1) Start migrating packages along with upstream and have everyone who > has a separate /usr (including me by the way) start using an initramfs > of some kind, either dracut or one that we generate specifically for > gentoo. The reason I suggest the initramfs, is, unfortunately if we > migrate everything, nothing else would work. I also don't see a good reason to not adopt dracut, re-implementing something that already works and is maintained by a competent upstream seems wasteful to me. I really don't see why people resist using an initramfs so much. The udev/kmod/systemd/dracut effort to standardise the base userspace of Linux is probably scary for quite a few Gentoo-ers as it means that the end result of an installed Gentoo system will be less differentiated than it was before. But it still is a step in the right direction as most of these standardized pieces are much better than what we currently have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 and unmaintained upstream shows that even a relatively large distribution like us can't maintain a competitive base system solution, adopting the udev/kmod/systemd way will allow us to use all the work that they are doing and instead concentrate on making a better system. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/01/12 15:12, Olivier Crête wrote: > Hi, > > On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote: >> I have been working with robbat2 on solutions to the separate /usr issue >> (That is why I have specifically cc'd him on this email) >> which will allow people to not use an initramfs. If we migrate >> everything off of the root fs to /usr, all of those solutions become >> moot. On the other hand, if we don't migrate, we run the risk of >> eventually having our default configuration not supported by upstream. > I think the general consensus among other distros is that initramfs is > the new /. Many core elements of the Linux system will start installing > themselves in /usr, starting with udev, so we won't have a choice > anyway. Also, I doubt it's currently possible to boot a Gentoo system > without /usr mounted anyway. "initramfs is the new /" ... and no one asked if maybe that doesn't really make sense? That people are now actively working on forcing one big system partition is annoying, but I really don't see the need to add a layer or two of complexification just because, well, why not. > >> 1) Start migrating packages along with upstream and have everyone who >> has a separate /usr (including me by the way) start using an initramfs >> of some kind, either dracut or one that we generate specifically for >> gentoo. The reason I suggest the initramfs, is, unfortunately if we >> migrate everything, nothing else would work. > I also don't see a good reason to not adopt dracut, Make it work and I'll reconsider it, until then genkernel wins by default. > re-implementing > something that already works and is maintained by a competent upstream > seems wasteful to me. I really don't see why people resist using an > initramfs so much. What does it add, apart from time to the boot process? For some setups (like my notebook with luks+lvm) there's no reasonable way around it, but on my desktop it's worse than useless. > > The udev/kmod/systemd/dracut effort to standardise the base userspace of > Linux is probably scary for quite a few Gentoo-ers as it means that the > end result of an installed Gentoo system will be less differentiated > than it was before. But it still is a step in the right direction as > most of these standardized pieces are much better than what we currently > have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 > and unmaintained upstream shows that even a relatively large > distribution like us can't maintain a competitive base system solution, Eh what? As part of the OpenRC upstream I find it weird that you call it a fiasco when it works better than the other "solutions" and had about 10 commits in the last 48 hours alone. I don't see an advantage in replacing a known-good solution with some random stuff that mostly doesn't work yet just because it's the future. > adopting the udev/kmod/systemd way will allow us to use all the work > that they are doing and instead concentrate on making a better system. > "Better" means no lennartware to me. I want to be able to fully debug init script failures, which systemd makes very hard to impossible. On some machines I have changes in the startup that would mean having to hack up something in C and hope that it doesn't crash init for systemd (what the blp?) Please don't try to bring the GnomeOS vision of having MacOS without paying for it to my computing experience ...
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 01 Jan 2012 02:12:22 -0500 Olivier Crête wrote: > Hi, > > On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote: > > I have been working with robbat2 on solutions to the separate /usr > > issue (That is why I have specifically cc'd him on this email) > > which will allow people to not use an initramfs. If we migrate > > everything off of the root fs to /usr, all of those solutions become > > moot. On the other hand, if we don't migrate, we run the risk of > > eventually having our default configuration not supported by > > upstream. > > I think the general consensus among other distros is that initramfs is > the new /. Many core elements of the Linux system will start > installing themselves in /usr, starting with udev, so we won't have a > choice anyway. Also, I doubt it's currently possible to boot a Gentoo > system without /usr mounted anyway. > > > 1) Start migrating packages along with upstream and have everyone > > who has a separate /usr (including me by the way) start using an > > initramfs of some kind, either dracut or one that we generate > > specifically for gentoo. The reason I suggest the initramfs, is, > > unfortunately if we migrate everything, nothing else would work. > > I also don't see a good reason to not adopt dracut, re-implementing > something that already works and is maintained by a competent upstream > seems wasteful to me. I really don't see why people resist using an > initramfs so much. > > The udev/kmod/systemd/dracut effort to standardise the base userspace > of Linux is probably scary for quite a few Gentoo-ers as it means > that the end result of an installed Gentoo system will be less > differentiated than it was before. But it still is a step in the > right direction as most of these standardized pieces are much better > than what we currently have. The OpenRC/baselayout-2 fiasco, not much > better than baselayout-1 and unmaintained upstream shows that even a > relatively large distribution like us can't maintain a competitive > base system solution, adopting the udev/kmod/systemd way will allow > us to use all the work that they are doing and instead concentrate on > making a better system. > All of my systems currently have a seperate /usr that is mounted at boot. Unfortunately I do agree that this is not something that we can fight. This was brought up earlier and the only thing we can do for people like myself (who mount /usr at boot) is to create a simple initramfs that only has the purpose of mounting /usr at boot. The main thing I don't like about initramfs is that we have to regenerate it any time we update the packages that get included in it. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
