Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
Nirbheek Chauhan wrote: On Fri, Jul 1, 2011 at 11:03 AM, Dalerdalek1...@gmail.com wrote: William Hubbs wrote: As a user, if a person hasn't upgraded in about 6 months, they may as well reinstall anyway. That is usually the advice given on -user. After a year without updating, it is certainly easier and most likely faster to reinstall. Except for the fact that while you upgrade, you still have a usable system. Reinstallation means a massive time-sink during which your machine is completely unusable. This is not an option for a lot of people. If -user is regularly giving that kind of advice, I think you guys are making a huge mistake. I'm not going to support this kind of max-6-month-upgrade life cycle for Gentoo. We're effectively driving our users away to distros like Ubuntu that allow you to upgrade every LTS release instead of constantly or every 6 months. Well, it has been done. A while ago, if I recall this correctly, someone hadn't updated in about a year. He tried to upgrade but ran into issue after issue. After a couple days, he ended up reinstalling. It just depends on what updates have come along that causes issues. I think things are better than they used to be but sometimes, it is faster to just reinstall and be done with it. It's either spend a day or more dealing with problems or spending a day getting a fresh start. As for not having a system, I have one when I do my install. I just boot Knoppix and use it. I can use a web browser to follow the docs and check email. It's one of many ways to install Gentoo. It's not about what Gentoo supports, it's about what is faster, easier or at times, both. Dale :-) :-)
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
On Thu, 30 Jun 2011, William Hubbs wrote: Please discuss. Did I leave out any steps? Are there any points I have left out besides the time window between steps 2 and 3? Should there be a time window before removing baselayout-1? What about between steps 1 and 2? What do you consider to be a reasonable time window before we stop supporting migration from baselayout-1 to baselayout-2/openrc? I'm thinking on the order of a few months, but not years. We have a policy on this, see http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt: | Upgrade path for old systems | | Vote (unanimous): The ebuild tree must provide an upgrade path to a | stable system that hasn't been updated for one year. So the time window should be at least one year after stabilisation of baselayout-2 and openrc. Ulrich
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
On 07/01/11 07:56, Nirbheek Chauhan wrote: On Fri, Jul 1, 2011 at 11:03 AM, Dale rdalek1...@gmail.com wrote: William Hubbs wrote: As a user, if a person hasn't upgraded in about 6 months, they may as well reinstall anyway. That is usually the advice given on -user. After a year without updating, it is certainly easier and most likely faster to reinstall. Except for the fact that while you upgrade, you still have a usable system. Reinstallation means a massive time-sink during which your machine is completely unusable. This is not an option for a lot of people. I'd call myself an affected user in this context: As (lazy) administrator of some servers (hardened) and desktops (stable), both virtualbox servers and guests, as well as an x86 binhost vm for the laptop, and the only requirement of keep-it-working, I'm doing the upgrades somewhat seldom: up to 1.5 years, especially for the hardened servers. As I don't care for compilation time (the servers are up 24/7), my thought to still allow for a somewhat stable upgrade path: Regularly (twice a year?) take a tree snapshot to keep around (infra? releng?), and provide some mechanism (eselect?) to pick such an old snapshot instead of the current (rsync) one. Then, run each (half-year) update within a couple of days... Maybe the tree snapshots are there already within the live-cds: Do we aim to provide an upgrade path from one live-cd snapshot to the next one? /haubi/ -- Michael Haubenwallner Gentoo on a different level
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog
В Чтв, 30/06/2011 в 19:27 +, Sebastian Pipping (sping) пишет:
Log:
net-misc/aria2: Bump to 1.12.0, looks trivial
EAPI=2
inherit bash-completion
...
pkg_setup() {
if use scripts use !xmlrpc use !metalink; then
ewarn Please also enable the 'xmlrpc' USE flag to actually use
the additional scripts
fi
}
This really calls for REQUIRED_USE from EAPI=4.
REQUIRED_USE=scripts? ( ^^ ( xmlrpc metalink ) )
src_install() {
emake DESTDIR=${D} install || die emake install failed
rm -rf ${D}/usr/share/doc/aria2
|| die
--
Peter.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog
On Fri, 01 Jul 2011 12:03:41 +0400
Peter Volkov p...@gentoo.org wrote:
pkg_setup() {
if use scripts use !xmlrpc use !metalink; then
This really calls for REQUIRED_USE from EAPI=4.
REQUIRED_USE=scripts? ( ^^ ( xmlrpc metalink ) )
That's not the same condition as the one in the pkg_setup.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[gentoo-dev] Re: rfc: deprecation of baselayout-1.x
Nirbheek Chauhan posted on Fri, 01 Jul 2011 11:26:50 +0530 as excerpted: On Fri, Jul 1, 2011 at 11:03 AM, Dale rdalek1...@gmail.com wrote: William Hubbs wrote: As a user, if a person hasn't upgraded in about 6 months, they may as well reinstall anyway. That is usually the advice given on -user. After a year without updating, it is certainly easier and most likely faster to reinstall. Except for the fact that while you upgrade, you still have a usable system. Reinstallation means a massive time-sink during which your machine is completely unusable. This is not an option for a lot of people. This isn't really true. Reinstallation in the sense used here, and in the sense that removing baselayout-1 support would require, can simply mean untarring a new stage-3 tarball over top of an existing system and going from there. That gets one a(n) unbroken and updated base on which to rebuild. If one already has their general world file and USE flags setup and is already reasonably familiar with Gentoo, it goes pretty fast, particularly if one isn't rearranging partitions, etc, as one wouldn't be if we're comparing to a no-reinstall, and the system remains generally functional thru most or all of it. Alternatively, if one wants a clean install, one can install to a new chroot (probably on a different partition), keeping the existing system intact and up and running until the new system is ready, then rebooting into it, and after some basic testing to be sure it really /is/ ready, blowing away the old system partition. This allows one to keep the same /home and data partitions, and to copy over or use for reference the old configuration in /etc. I actually did something very similar to the chroot install both when first installing Gentoo (using an existing Mandrake system, this was 2004), and when building the 32-bit netbook image I built on a dedicated 32-bit image partition my main machine but transferred to a thumb-drive for initial boot on the netbook, and now keep updated using ssh and rsync over ssh. It's not difficult, and even with the differences between the 64-bit main machine and the netbook (image), much of the configuration was copied over then changed as necessary. It would be even easier if it was a reinstall to a new partition on the same machine with basically the exact same config. So keeping an up and running machine even with a reinstall isn't a problem, certainly no more of one than fighting with broken installs, because everything has changed out from under the existing one. And I've done in-place upgrades to my netbook image, which doesn't get updated nearly as frequently as my main machine, too. Even having gone thru the updates one at a time on the main machine, after about 6 months, it becomes *HARD* to update the existing installation, because stuff simply /has/ changed out from under it, and at about 8 months, probably 6 months if I hadn't been keeping up on another machine so had already gone thru the process incrementally once, it really *IS* more practical to reinstall, generally meaning in practice, doing an in-place stage-3 tarball extraction and an emerge --emptytree @system followed by emerge --emptytree ~world. If -user is regularly giving that kind of advice, I think you guys are making a huge mistake. I'm not going to support this kind of max-6-month-upgrade life cycle for Gentoo. We're effectively driving our users away to distros like Ubuntu that allow you to upgrade every LTS release instead of constantly or every 6 months. Perhaps so. But really, Gentoo isn't a perfect fit for everyone and we're only lying to ourselves and doing a disservice to our potential users to pretend it is. If people are only updating every six months or less frequently, then they really ought to be using a distribution designed for exactly that sort of upgrade scenario, and Gentoo simply doesn't fit the description. It can certainly still be made to work, and for one-offs like the year of military duty many countries have, it's a good thing that it can be made to work, but it's making life (and Linux) more difficult than it really needs to be, if that's going to be one's routine update spacing, and IMO we ARE simply lying to ourselves, etc, pretending otherwise. And it's hurting our regular users too, because time spent trying to keep year-out compatibility is time that cannot be spent keeping packages updated and keeping rolling updates smooth. None-the-less, as someone else points out, the policy /is/ one year. At that point an upgrade's going to be rather difficult in any case, but the line must be drawn somewhere, and if we're not deliberately breaking stuff out to a year, that makes the six-month upgrades at least reasonably possible. If the policy were six months, or even say 8-9 months, it's quite possible six-month updates would be more difficult as well, and I doubt anyone would sanely argue that a
Re: [gentoo-dev] Re: rfc: deprecation of baselayout-1.x
On 07/01/11 11:25, Duncan wrote: Nirbheek Chauhan posted on Fri, 01 Jul 2011 11:26:50 +0530 as excerpted: On Fri, Jul 1, 2011 at 11:03 AM, Dale rdalek1...@gmail.com wrote: William Hubbs wrote: As a user, if a person hasn't upgraded in about 6 months, they may as well reinstall anyway. That is usually the advice given on -user. After a year without updating, it is certainly easier and most likely faster to reinstall. Except for the fact that while you upgrade, you still have a usable system. Reinstallation means a massive time-sink during which your machine is completely unusable. This is not an option for a lot of people. This isn't really true. Reinstallation in the sense used here, and in the sense that removing baselayout-1 support would require, can simply mean untarring a new stage-3 tarball over top of an existing system and going from there. That gets one a(n) unbroken and updated base on which to rebuild. No. Bad Duncan. Stop breaking things badly. Portage tends to get REALLY confused with that and usually unmerges glibc or other funnies. What you want is either using a binhost (like tinderbox.dev.gentoo.org) or a chroot in which you can build the binpkgs which you can then install with emerge -K ... So keeping an up and running machine even with a reinstall isn't a problem, certainly no more of one than fighting with broken installs, because everything has changed out from under the existing one. It's not as easy as it could be. We should figure out a reliable way to move an old install forward ... (I have some ideas, but it all takes time and lots of testing) -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
[gentoo-dev] Last rites: app-arch/upm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (1 Jul 2011) # Dead upstream, no updates since 2002. Does not build # against glibc-2.14 ( bug #371157 ). Masked for removal # in 30 days app-arch/upm - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJODaQmAAoJEPqDWhW0r/LCxXQQALzyFXfeRD6CQvIyY3T6kJ+B XUEW0qgy4z6JXkH+Ya4ps72XDAXBJcMyWpTMFUeMNwbZ+jE6hyBc4dMg6fQRleda Epz6xn2gPKv7W3zVMpPWx/0h5JvazDW2hD2Hswxc7RJfiS1ULarkCK9KkVbDtHCq UTwTbArQdbqU+wwz53SyIR3J1ix5OR+73z8VnxnohXN86M7vFgkoirfL142Hju4U Ldtc+pmyfC+meZtZqi5sXeGjgC9WP4mNam8b8/lIaXcyklU0MmqS7p5JMrZlOEX2 hzsAqBiHSxS1ocayLuIMgp4EcPMePlPCyLJibEMvaaRz5znFUQWwM1/uy9Iol1Pu fIWn2kDop0SZkK9rnXNiFn2CPd8e+Ss4PlBv7J5YMO3eBgFx2pyUmF5lplwX3P/V DUtE1UWaYu85XR7EVL3LvPlgttPONsJ5yq5mbL0KigtpjgZRTNMJyZxUHFmBm9Lg 7aIa6Cgl4swjz1hVKEMAdw8qGp+LKIzhan0KY8J3ZQNNsrtXHNK6XLfvToHTyPPc Ns9AXD3hkfx5VkfmlAGbYj29l+ICoeW2ulKuq4JIMcaA34iKqPdwi2k3p2PdhGz6 SZTlWUwQwQuMndOIBGvbrJp1iNmv4CAQilA0tjo5J08KSE/y9hKDyUO6BEPFoQLV FZJS7ZK+TjcK3W2Evtk0 =Hoix -END PGP SIGNATURE-
[gentoo-dev] Last Rites: net-libs/clinkcc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (1 Jul 2011) # Does not build against gcc-4.5. Bug #323061 # Masked for removal in 30 days net-libs/clinkcc - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJODaUEAAoJEPqDWhW0r/LC/oIP/0mEFgMJLRbUKkOvevo5UJew MBRKNjSzAt+1o2h+xj9kFOks5mFDvKQr2OOmf3OBWRnyG0bDpysKUcL/yY6miCO0 mwkKd8UYOqndNP9/4liKuWIGpIjqPdkIbhxtzTkKLwzhBrPSk27s54KSiPFVKuQ3 Zdx8s4hc7ulVSZu647kdU5O+rOaUq0Oaa+6r2Ankgl2UAU9zdJilGLCaco74IkpO szOUmDh/GU4OS2ghX7aGltHn2/bwSg35bOZ4oLEoa0wdThMBIZCKIHBnw2ajTrhK Sx/N7M3KzxFaKzObqo+EPYF0a95O4ueFyIZLgm0RAJEb6Hmu4fbkCVx+fEp9vjyq ZUDHgaZoklcWmKwQF/WXgwR99Mk4rLzRVCH93gOTuJjJz0ZNjfymhJX37gYq3GZq QCbEUx2MW7jtCb7fAdQegxIfq1W5NqItECgQ3QAODUMk0MAy4RwozpSQhBwAvMnF 1b4nhe8GIWtXIvR7xTTVCX5sMot6W9WkvWrFhfHX6MxX1tYDnnNMxqQNFMRNMpKC sERmKfZcNqlFQvIZ/foCvUWHdeGMB6I14rOg3LOd5ftFQzL3xx6biMBXuamHhGJH jJysV08Zx73Qs+FvoqYx2Goaer5vvFGmJC/vcVixg6VQQev8Tr3Z5QylwBA6ypt+ zPt71Zcmjruyl3mUkBTz =CkF6 -END PGP SIGNATURE-
[gentoo-dev] Last rites: sys-apps/pcmcia-cs*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (1 Jul 2011) # The whole suite seems abandoned. # QA and compilation problems ( bug #236286 ). # Has been replaced by sys-apps/pcmciautils # Masked for removal in 30 days sys-apps/pcmcia-cs sys-apps/pcmcia-cs-cis sys-apps/pcmcia-cs-modules sys-apps/pcmcia-cs-pnptools =virtual/pcmcia-2.4 =virtual/pcmcia-2.6 - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJODaeGAAoJEPqDWhW0r/LC4WwP/jOnvC4ZaX7CVk/82iWZs2NA icttSJsnnysrhe7PWjKdbFi0PsvtqUSdAR2lD2ap4aMXZ7yPH9mpXLIKc+mRmlxQ pohTeB2o4Q+KT6YqTtH6wNgpz9+e1gVdE2bq9H6tvz2b08aDPAboGB8o0clzijN6 1XzLR/QxbV/k5Z0v6bMnTC7bjA9ks0URCNorGrNVczWnEUmNlf+mhZjRvaAnpIu1 jtP5bHzPzgncKW4Qe9j+4Klca2cfhvcXN3UyFTx3L6dhj/4ulDKLxNCIqmhGXNDr emDU32mOUvEeojWCMej7hKuzI6vwXVdfrxUurzn2TMhAWYGKkTYC9tISLoXVCgzp plxoZamR1b23s7iIHwI8kVVb3ftO3CETONEDrlsI5ZgmTW29umCxZUVlr5DYAqrq V4j+cHhwJVNtQDdTv8lexX46ffWnZJv44DMxIpMr576K6HmhrLI8kpNuFqH/XXKX sNeIE2v6VDNuTuvCY5DhFXv1cxT7RBhPHw4ZqyV6/sH4eDuv1LQlSnTDHVivUqqA 2Hwg3d0MjQpe1mh5yr/v+rbySc0D5PSExyE5pp3mzDcq+JC5qnrnLVaFNiVKGn+G j2v+Zfu03OF4lI2q8wcsK4WPRqF4gSc2a23DQvYZfeSeomw5tJ0EtbFN57BTJ/J6 p083kDeTQHyZv8IhPEOP =dSIW -END PGP SIGNATURE-
[gentoo-dev] Last rites: app-emulation/gdb-armulator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (1 Jul 2011) # Does not respect LDFLAGS (bug #333505). # The core functionality has been replaced by # app-emulation/qemu # Masked for removal in 30 days app-emulation/gdb-armulator - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJODakgAAoJEPqDWhW0r/LCQTUP/2MKQs+HImJozgf1OO4hCQBm 7QfzVbsGkD9rcAw9biFdGVS57Nk3fRvlZcY1QiPfcEOSo6WxD/sgxHBln0VA8vSn ntOc2JI+YNJ4D6iyB5qxWJE1UKJufSgevbTG1neWyXwpgX0lXz9TWtbMHgzHnFJ1 SkJHo+xCVI5TYZDtXwXQ+mwRr2uK7tuOvsG5VGq3q7UuIsE+Ta+EyvSgBWZo3LdX UnSzsP+fD48HC0rMFs6t5AujX0SmWBGd7D/pjHcNMp9PRlckhnuFcZEMX0COlKWG DKNzISK4Tl43VeVpksJStSPLrNeMHJJJ2mjUZcWRhzdBtVpu9mEkUvDsBCDPJnHN zLuFeyR1ZcTtVL/+INI4ZViL/8m/0WXE+oCg3RfpeHXNU290SCz09tPgRRLgr9KU uuKsTw36mhD0PdWHJlzZLk9jiwjwXViAQReA7KAaZ+DUXbGAMx1OIBj87zSW2W9a VL0aR0pupcHTsBpaZjKNH4SyLQi2qtelah4ExdAcTN5feA4vlJXfqN4iYseiUlmB pmFJ3+SXVU62+jELyZUjkT6J5AF17cPxFYeDuMfpcgUU4OwfAXOqYkAy45Tgs817 ENEB07+iZbWDSmThZAmy7SaVa5PaZ0USFTJikLQOZzY0l8J6g/8D6IkKYAWMjc+x VddB4gk6OnnWQY+Cu8rz =N0bL -END PGP SIGNATURE-
[gentoo-dev] Last Rites: app-emulation/gdb-armulator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (1 Jul 2011) # Does not build against gcc-4.5. Bug #320337. # Masked for removal in 30 days app-emulation/pearpc - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJODanEAAoJEPqDWhW0r/LC6BEQAI0iD8snGd2504pe1tsZ46VY ntYXesbHEDSjQ4ZxGfjzh/QWeRPsWpZxT2Ce5mcavm/vmcsAW2CGSn5gIf9unKdN sY9Kduxy9DQTuPvfmAIagEN88be8PtFrnpogNo7Rmq1iineeYlXWe6v344jtUYxL l5S2xlUO/nHYDxNa2GnPbbLrzFYe2RraUs7o+T+R63iOB+xe8tGlXoLUi9tXgE7a pSSf51eDITlYCnbsYwxnW2vFlSOFkGkXUjOPl+mNZpY88ShW2pnls+Mih3TA47OC AJTkpYIwThw2pDszFVRbuM1aal0hB0X/BjigVIYG77EMgTYLLlnjAd/vIAm94Qdl CF1LWFHRue2B6sMXBxGopCf8y1fssxJW0aaYM2NBH0DsmvSe/H4UoanTS54MkMiu WTYh/MxwgB98iQIV5TJhyfry7jokLiigvumfo3Mm7gg+rbXmGwe3kUorOz0txPtX Jq14ZwWjp4+c1/5qid/koTqu4GZKjP5angWIK9dbVPmLcqLUD8lICQHdImqLSyU9 Y7ioGehpWCuFV5iGflPM0jvC3Rta7W67IcE8phecAD9SZpFinNGtZXqiZNFWJdjH hPRDMFm1VdbYCaQRMtYx5NPZ7aS6TyAdKxBWsvycrfbysZpcCs9pelMgEtWvRpcW uRPhGgFv2ygoKljJU84Y =Ylh0 -END PGP SIGNATURE-
[gentoo-dev] Last rites: app-crypt/steghid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (1 Jul 2011) # Does not build against gcc-4.5. Bug #319679 # Masked for removal in 30 days app-crypt/steghid - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJODaq3AAoJEPqDWhW0r/LCLqsP/37id10hgAtpUHiew9W3yuu0 6lOlkJz3z/XC27js5Gxf0udmI/ldW3GK41BgzAd8FyVSnNcw6kcLeyD76ABjPyGe e/Vgp6bmPrXxR9ziwhu3jY31y+AE8ehMXDWs9kG/eP53RRWN3A/r74qZtG56/hEW Gmu47JMIxLxjlgZGh5nEXoAvUFPPibJypQbTfNfnTUEL1tU2rwW/a3q5akLln/ek TNg8MhyZj9vdNIHQQ8ap+MgXNW0t40f95TH8O7ggbYKFVhY/wwqdJPYqPqcwf5pW 6+wrulv36JAQq4kScPCh3/T/aY3xzDarie+F4esJ8wfRT55AZfPVYi7RFY7+/xqm hyI2+HKiVUnatgDtt/ufAT1qciyjtkA6GikWgiObJ68zIi12IWxaFv/i+B03AHup xOig+AdmdjcPbkOPhoHf+/ZIMXMUpDzrFirzgCBjpcyNbLqbf4CMP4uGmmCDfoaf 9yi2qW6+qojbLqf9BKN0g8Kc+8+76KbGxsWJ6taNqjkX+NR3kQkXwKVspl5S/nd1 Gy+LatKMOnor0D+NIZAT5EDJPDWfCBPgSlhcYLhEecuaKeLRJq7YiBZZGFchcsAK tsEIXWZjRcqHeAV/r1+m6NQh1W66oeBV42jRj3jQ4P+uhNUo+bqWVy7hZMU+70dR NIyUG6WS4YxRYrLMF+Oh =jmsI -END PGP SIGNATURE-
[gentoo-dev] Re: rfc: deprecation of baselayout-1.x
Patrick Lauer posted on Fri, 01 Jul 2011 11:45:16 +0200 as excerpted: So keeping an up and running machine even with a reinstall isn't a problem, certainly no more of one than fighting with broken installs, because everything has changed out from under the existing one. It's not as easy as it could be. We should figure out a reliable way to move an old install forward ... (I have some ideas, but it all takes time and lots of testing) Can't disagree there. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
On Fri, Jul 01, 2011 at 08:38:38AM +0200, Ulrich Mueller wrote: On Thu, 30 Jun 2011, William Hubbs wrote: Please discuss. Did I leave out any steps? Are there any points I have left out besides the time window between steps 2 and 3? Should there be a time window before removing baselayout-1? What about between steps 1 and 2? What do you consider to be a reasonable time window before we stop supporting migration from baselayout-1 to baselayout-2/openrc? I'm thinking on the order of a few months, but not years. We have a policy on this, see http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt: | Upgrade path for old systems | | Vote (unanimous): The ebuild tree must provide an upgrade path to a | stable system that hasn't been updated for one year. So the time window should be at least one year after stabilisation of baselayout-2 and openrc. To clarify then, we can do everything except remove the migration code from the openrc ebuilds. That step needs to wait until 28 Jun 2012 right? William pgpLF4mqYSCei.pgp Description: PGP signature
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
On Fri, 1 Jul 2011, William Hubbs wrote: We have a policy on this, see http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt: | Upgrade path for old systems | | Vote (unanimous): The ebuild tree must provide an upgrade path to | a stable system that hasn't been updated for one year. So the time window should be at least one year after stabilisation of baselayout-2 and openrc. To clarify then, we can do everything except remove the migration code from the openrc ebuilds. That step needs to wait until 28 Jun 2012 right? If that is sufficient for providing an upgrade path, then yes. Ulrich
[gentoo-dev] Last Rites: app-text/notecase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (1 Jul 2011) # Dead upstream. Does not build against # x11-libs/gktsourceview-2.10. Bug #314779 # Masked for removal in 30 days app-text/notecase - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJODbxZAAoJEPqDWhW0r/LC2JwP/RuiX3GX+42LjMBllj1Q+p1t vB7gdMf+FYpdzmaEk/O6UgKGXyUhikI2eY+cyCYAgmkThSFuSO5HV5+ukkTuVwy9 EiVIdoc+olxKRKs2KG6BkuSfGJWfDkSn587Rzcn/tpWDByn7y3Aa5j1jhTQjrlnc m4NPYPsmVE9MMhJ6hTBDBADk9UD/b8KjpIuhxd2kjHi0Q9ik/w5N5htCKYv2z2KI xn0wRdvz9u0W9ystChtvEAsGUmcfZlpytGpmK1jBINrZCx5YWDaPRY2wdYP3LoJV NqyTTAQcaQ+sjMaEN9tDcAU+7PjJUssXaUEEyedgTfj71U7eCCWAvZZ02RQv4+gJ M2bVBvXEryfwvua1lkDMnPmQ+r6JBEZFV4HBpKevvQiO4+4RVHG92M3va8orluMP tTSXs/3Xi20GeUM8sJKonPS4HSRHxZkalLjEjCN8eIOqPkkMW2B5vlhu23qRxVj8 rv5dXQTpLdcAclJyQ5gZszV4Bbu4fz8QOIns2B8dfzVrdMwjZr8ESBf6iJTf7Eg2 2lArxYQrdJov5AoI5oXkXCFaynE0K4GDPoQtXZu3TdBOOvV4VmngX1AQu1afcNij sLidpQqwVfFfolJ0fSM/s+l0p/NBS4+ocFqxM905zu+rDA8tQDV7IdCk+w7z1eq8 yMtUX7tOGiU3F2C7cLUS =FTfe -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog
В Птн, 01/07/2011 в 09:09 +0100, Ciaran McCreesh пишет:
On Fri, 01 Jul 2011 12:03:41 +0400
Peter Volkov p...@gentoo.org wrote:
pkg_setup() {
if use scripts use !xmlrpc use !metalink; then
This really calls for REQUIRED_USE from EAPI=4.
REQUIRED_USE=scripts? ( ^^ ( xmlrpc metalink ) )
That's not the same condition as the one in the pkg_setup.
Ah, yea. I guess any of xmlrpc or metalink are required for scripts. So,
correct one should be:
REQUIRED_USE=scripts? ( || ( xmlrpc metalink ) )
--
Peter.
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
On 11:26 Fri 01 Jul , Nirbheek Chauhan wrote: Except for the fact that while you upgrade, you still have a usable system. Reinstallation means a massive time-sink during which your machine is completely unusable. This is not an option for a lot of people. If -user is regularly giving that kind of advice, I think you guys are making a huge mistake. I'm not going to support this kind of max-6-month-upgrade life cycle for Gentoo. We're effectively driving our users away to distros like Ubuntu that allow you to upgrade every LTS release instead of constantly or every 6 months. In my experience, updates become massively difficult after about 6 months unless you have deep expertise in Gentoo. You run into blocker after blocker after USE-flag problem after resolution failure and an ongoing series of confusing messages with no apparent end in sight. We may call it supported (and technically, we're right) but it isn't realistically possible for most users. After handing over administration of about 10 systems to someone else with less experience in Gentoo, I still get called in about once every couple of months to help every time one of these weird problems comes up. I recommended upgrades to the new admin every 3 months, which is a point where nearly everything still works cleanly. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpbxhlF9Fgwu.pgp Description: PGP signature
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
On Fri, Jul 01, 2011 at 09:08:53AM -0500, Donnie Berkholz wrote: On 11:26 Fri 01 Jul , Nirbheek Chauhan wrote: Except for the fact that while you upgrade, you still have a usable system. Reinstallation means a massive time-sink during which your machine is completely unusable. This is not an option for a lot of people. If -user is regularly giving that kind of advice, I think you guys are making a huge mistake. I'm not going to support this kind of max-6-month-upgrade life cycle for Gentoo. We're effectively driving our users away to distros like Ubuntu that allow you to upgrade every LTS release instead of constantly or every 6 months. In my experience, updates become massively difficult after about 6 months unless you have deep expertise in Gentoo. You run into blocker after blocker after USE-flag problem after resolution failure and an ongoing series of confusing messages with no apparent end in sight. We may call it supported (and technically, we're right) but it isn't realistically possible for most users. Right. I can't tell you how many times I've seen on -user where someone comes back after not upgrading for longer than 6 months and finds themselves in a very tricky situation. Since we have a council decision that says the migration path has to exist for a year, that's what I'll follow. However, if someone waits a year to upgrade a gentoo system, things will have changed so much that the upgrade process will be challenging for them to say the least, unless they know gentoo very well. William pgp1ZvZDk6LjB.pgp Description: PGP signature
[gentoo-dev] rfc: gentoo base functions
All, this is a followup thread to the one about openrc being mandatory on all gentoo systems. I started a new thread, because I want to figure out which functions located in /etc/init.d/functions.sh need to be available regardless of the init system in use. So far, I'm thinking this is the list: ebegin, eend, eerror, eerrorn, eindent, einfo, einfon, eoutdent, esyslog, ewarn, ewarnn, ewend, vebegin, veend, veindent, veinfo, veoutdent, vewarn, vewend Am I missing anything?? Thanks, William pgpC8g5z8LS5F.pgp Description: PGP signature
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
William Hubbs wrote: On Fri, Jul 01, 2011 at 09:08:53AM -0500, Donnie Berkholz wrote: On 11:26 Fri 01 Jul , Nirbheek Chauhan wrote: Except for the fact that while you upgrade, you still have a usable system. Reinstallation means a massive time-sink during which your machine is completely unusable. This is not an option for a lot of people. If -user is regularly giving that kind of advice, I think you guys are making a huge mistake. I'm not going to support this kind of max-6-month-upgrade life cycle for Gentoo. We're effectively driving our users away to distros like Ubuntu that allow you to upgrade every LTS release instead of constantly or every 6 months. In my experience, updates become massively difficult after about 6 months unless you have deep expertise in Gentoo. You run into blocker after blocker after USE-flag problem after resolution failure and an ongoing series of confusing messages with no apparent end in sight. We may call it supported (and technically, we're right) but it isn't realistically possible for most users. Right. I can't tell you how many times I've seen on -user where someone comes back after not upgrading for longer than 6 months and finds themselves in a very tricky situation. Since we have a council decision that says the migration path has to exist for a year, that's what I'll follow. However, if someone waits a year to upgrade a gentoo system, things will have changed so much that the upgrade process will be challenging for them to say the least, unless they know gentoo very well. William I been using Gentoo since about 2003, old 1.4 days, and I wouldn't try to upgrade after six months unless there has been very few major changes. I may would sync and see what it looks like but if I see several blockers or some major upgrade, like expat if I recall correctly, then it would be a fresh install for me. So, I'm a long time Gentoo user and I been around the block a few times and I certainly know where to get help, but even with all that between my ears, I still say it is faster to start over. If in say the past three months there have been a few major upgrades, I would do the same. If in 9 months it has just been normal upgrades, then I would try it. It all depends on what has changed and how much time it would take to work through the problem. Now if you have some very complicated server setup, then that may be different. At that point you would have to put in the balance what is easier and faster, upgrade or re-install. Generally, emerge -ep world | genlop -p plus time to configure everything again versus time needed to work through the upgrade, which there is no certainty of. That's the balance. Having the world file and some needed files from /etc would make things a lot faster too. Balance. Just don't fall off the scale. lol Dale :-) :-)
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog
On 07/01/2011 10:03 AM, Peter Volkov wrote:
В Чтв, 30/06/2011 в 19:27 +, Sebastian Pipping (sping) пишет:
Log:
net-misc/aria2: Bump to 1.12.0, looks trivial
EAPI=2
inherit bash-completion
...
pkg_setup() {
if use scripts use !xmlrpc use !metalink; then
ewarn Please also enable the 'xmlrpc' USE flag to actually use
the additional scripts
fi
}
This really calls for REQUIRED_USE from EAPI=4.
REQUIRED_USE=scripts? ( ^^ ( xmlrpc metalink ) )
If we use EAPI 4 in that ebuild we cannot make it stable anytime soon,
correct?
Sebastian
Re: [gentoo-dev] rfc: gentoo base functions
On Fri, Jul 1, 2011 at 10:44, William Hubbs wrote: this is a followup thread to the one about openrc being mandatory on all gentoo systems. I started a new thread, because I want to figure out which functions located in /etc/init.d/functions.sh need to be available regardless of the init system in use. So far, I'm thinking this is the list: ebegin, eend, eerror, eerrorn, eindent, einfo, einfon, eoutdent, esyslog, ewarn, ewarnn, ewend, vebegin, veend, veindent, veinfo, veoutdent, vewarn, vewend Am I missing anything?? and the env vars as provided by `/lib/rc/bin/eval_ecolors`. otherwise, i think this is a good starting point and covers the ones off the top of my head. note that this is the list required if openrc is not installed. if openrc is installed, there are more. but those arent considered portable as they're specific to baselayout-1/openrc. -mike
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog
On 07/01/11 21:25, Sebastian Pipping wrote: [SNIP] If we use EAPI 4 in that ebuild we cannot make it stable anytime soon, correct? As far as I'm aware we have a stable portage with EAPI 4 in the tree for a few weeks now, so you can actively use it everywhere. -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
[gentoo-dev] Re: rfc: deprecation of baselayout-1.x
Duncan posted on Fri, 01 Jul 2011 11:26:58 + as excerpted: Patrick Lauer posted on Fri, 01 Jul 2011 11:45:16 +0200 as excerpted: [Keeping an up and running system during a reinstall is] not as easy as it could be. Can't disagree there. =:^) ... And upon further thought, can't disagree with the first part, either. I've seen people untar a stage tarball over top and have it work for recovery, but that was with a generally uptodate system in any case, so dropping in a current stage3 generally replaced existing files. You're very correct about portage getting confused if the existing packages are outdated, since the tarball would be dropping in untracked files. At least in the past, portage wouldn't unmerge glibc or the like, but it certainly WOULD leave the untracked cruft around. It's not stage tarball related but I once had to deal with recovering from the loss of a /usr/ partition so when I loaded the backup partition, /usr/ and / and /var/ weren't in sync any more, meaning the package database was unsynced. /That/ was an interesting thing to recover from, involving lots of manual equery belongs loops and tracking down whether orphaned files were deletable or something eselect or the like handled... over time as various weird bugs showed up because something was using the untracked crufty version instead of the new one. So I KNOW what the results of that unmanaged cruft can be! (My resulting policy is to keep /, most of /var/, and most of /user/ on the same partition, everything that portage touches. So if I have to fallback to backup, it might be dated, but at least portage's database will be in sync with what's actually installed.) (I'd have simply skipped this to avoid the noise only it was unfinished business where I knew I was wrong and hadn't said so, and therefore bothering me greatly. Now I can sleep properly again! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: rfc: deprecation of baselayout-1.x
On Fri, Jul 1, 2011 at 4:05 PM, Duncan 1i5t5.dun...@cox.net wrote: You're very correct about portage getting confused if the existing packages are outdated, since the tarball would be dropping in untracked files. At least in the past, portage wouldn't unmerge glibc or the like, but it certainly WOULD leave the untracked cruft around. I wonder if there is a way to get around keeping cruft in the tree for the sake of those who don't update often. Something that comes to mind is having a binpkg repository for everything in system - essentially a binpkg stage3. I'll tinker with that a little, but if catalyst just uses emerge then an easy way to generate this would be to add FEATURES=buildpkg to the autogenerated stage3s. Then we just need to mirror the binary packages a little. We should discourage users from using it except for rescue. It would be undesirable anyway since it would need to use stock use flags. Rich
[gentoo-dev] Re: rfc: deprecation of baselayout-1.x
Rich Freeman posted on Fri, 01 Jul 2011 16:50:28 -0400 as excerpted: I wonder if there is a way to get around keeping cruft in the tree for the sake of those who don't update often. Something that comes to mind is having a binpkg repository for everything in system - essentially a binpkg stage3. Useful idea. One thing to keep in mind when we're talking about the download of historical binaries is the obligations of the GPL, etc, in that regard. Gentoo doesn't normally have to worry about this as it normally ships sources, not binaries, and for current stage tarballs, which /are/ binary, the sources are, pretty much by definition as Gentoo handles it, made available at the same time (tho there might possibly be argument over whether they're made available at the same place, etc, I've made no attempt to grok or verify the legal minutia in that regard). But once you start shipping historical binaries, as we're talking here, we need to worry about EITHER keeping sources available at the same time/ place for them too, as long as they're shipped, OR keeping them available to be shipped upon request to ANYONE for up to three years. Based on previous discussion, the make available at the same time and place clause is considered easier for distributions such as Gentoo to fulfill than the upon request for three years clause. (That's the GPLv2 requirements as I understand them. I don't understand the GPLv3 and its differences in that regard really at all... except that I believe the same basic idea remains valid. IANAL. The Gentoo Foundation folks are the ones who probably should be tracking this. Etc...) This discussion came up at least once before, some years ago, when Gentoo was still making available historic stage tarballs dating back to 1.4 or earlier, and there was some real question as to whether we were sure that all the required sources were still available. I never validated whether action was actually taken, but the conclusion from that discussion, IIRC, was that the best practical action we could take would be to (1) ensure that we always kept corresponding sources from then on and made them available at the same time/place as the binaries, and (2), quit distributing the historic interest stages that there was a legitimate question about as to whether we could provide sources or not. Just something to keep in mind any time the idea of public availability of non-current binaries, for whatever reason, comes up. It's not all purely technical worries, tho fortunately, implementation of the legal requirements does ultimately boil down to technical details, too. I'd opine that's one practical reason why binaries remain a definite secondary from Gentoo's perspective -- sources-only lessens the legal requirements DRAMATICALLY, both as regards the GPL, and in regard to patents. Hopefully that's not a discouragement for something that I really believe is a great idea, but it /does/ need to be considered. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01-07-2011 19:33, Patrick Lauer wrote: On 07/01/11 21:25, Sebastian Pipping wrote: [SNIP] If we use EAPI 4 in that ebuild we cannot make it stable anytime soon, correct? As far as I'm aware we have a stable portage with EAPI 4 in the tree for a few weeks now, so you can actively use it everywhere. This prompted me to search the council meeting logs about EAPI 4 use for stable packages. Contrary to my recollection, this topic fell off the council radar a few months ago. In any case, as decided in the February[1] meeting, EAPI 4 was approved for tree use. The first portage version with EAPI-4 support[2] was marked stable over 3 months ago[3]. I did a quick grep in the tree and count over 500 ebuilds with EAPI 4 and amd64 or x86 keywords, so we already have quite a few EAPI=4 stable packages in the tree. [1] - http://www.gentoo.org/proj/en/council/meeting-logs/20110201-summary.txt [2] - https://bugs.gentoo.org/358009 [3] - http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/portage/portage-2.1.9.42.ebuild?view=log - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJODnYtAAoJEC8ZTXQF1qEPub8P/1hYj/8jyw6eligk+pUV3P8W /yUK/71w3Em151IlVF4nkCRLhCM0FW+TpqVcmau/EKja5wzL/X+vaIaGKwjqfh39 Z3O0cjCs8hV/SZ/AscHkdiLG4TmL8M0zeHmTc7xKw1FW7QuLe6nOuZoBOSlYVwqX M+g/dm/snxQcfsxn0YNNn2g/GYrk8whUg6YBmqdqSlElh5xJS1Zvi+BokAPQqgu8 mK4DMs2yxEb6aOXsvCYDiwLgPfxZVCbAkXoqqEOQtHjoA76lDUt3LByP11fCTZXo ysUqDlXbL98ToX/jPRNNDLjdFKKKnaTcYjdEM1mzyou1i/tvQWJaTuvPrZzPohCy ph21dEJKEq70ECSCBUr26HQ9bOSyEDcyV415SENFt1Rp8lXhK4dIwPDXsMrHkC1F DzBa/8sGwFjtlLqj+x2pOzROx8lBrSRZE7vVwW4fabpoqM1VSqtqQSsQLufqpzz5 MpEtvf8kr9d6G2rHUzEDN0PuOj5ouwEi0AyG0IutAgIRx7UO4SmGrY0tbfImdgvd O9ynGdbrGd9zlRBsbrdtGHlNmAzF8C9+ZgxzMUduHKFfNNYdPeAmV6lO8EjZDKF6 PLyUVKx0dh1RUsYwtJRV/RSWzRjtuqeoLDjMR5lxchB+MaF4qw1FGYTiU/Sg6Szw gUmWGfpa/FQzM6uThtmp =TiQL -END PGP SIGNATURE-
