Re: [gentoo-dev] rfc: location of portage tree
On 29 March 2012 07:43, Aaron W. Swenson titanof...@gentoo.org wrote: So, we're all getting way off topic and discussing reorganizing the whole enchilada. How about we all agree or disagree on the primary point: The Portage tree doesn't belong in /usr. +1 I believe that it does belong under /var/cache/. =0 # Not sure , semantically it doesn't make sense as its not behaving as a caching mechanism of any kind and would rather /var/portage or /var/lib/portage or something in that direction over /var/cache . I'd even prefer /var/lib/repositories/portage over /var/cache/portage/ We can go a bit further and make it /var/cache/gentoo-repos/portage/. That way Layman and friends can all make the move there quite simply without major infrastructure changes. The Portage PMS on it's next release would just do a 'mkdir /var/cache/gentoo-repos/portage/ sync rm -rf /usr/portage echo Portage has moved' on its next 'emerge --sync' while still looking in both locations for packages. I'd rather this change not be automatic, and should be driven by ENV variables, and the new layout be a default layout for new systems, and write an e-news article describing the default change and how to migrate to the new layout for people who want to. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] rfc: location of portage tree
On 29 March 2012 08:21, Aaron W. Swenson titanof...@gentoo.org wrote: 'Support' is the keyword here. The repositories are regenerated given machinesan 'emerge --sync' and can be considered as temporary as the packages themselves are impermanent. Further, the repository isn't required to persist. If somebody really wanted to be hard on our infrastructure, they could do an 'emerge --sync' at boot to repopulate /var/cache/gentoo-repos/. Though of course, if anybody has custom stuff in say, /usr/portage/local/ which they make by hand, nuking /usr/portage will make you *Very* unpopular. As will I be if I have /usr/portage/distfiles under /usr/portage/ and you nuke /usr/portage including distfiles. I could download distfiles again, but sorry, bandwidth is not free in every country, and neither is the time wasted by redownloading it all. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] rfc: location of portage tree
On Thu, Mar 29, 2012 at 2:26 AM, Kent Fredric kentfred...@gmail.com wrote: On 29 March 2012 08:21, Aaron W. Swenson titanof...@gentoo.org wrote: 'Support' is the keyword here. The repositories are regenerated given machinesan 'emerge --sync' and can be considered as temporary as the packages themselves are impermanent. Further, the repository isn't required to persist. If somebody really wanted to be hard on our infrastructure, they could do an 'emerge --sync' at boot to repopulate /var/cache/gentoo-repos/. Though of course, if anybody has custom stuff in say, /usr/portage/local/ which they make by hand, nuking /usr/portage will make you *Very* unpopular. As will I be if I have /usr/portage/distfiles under /usr/portage/ and you nuke /usr/portage including distfiles. I could download distfiles again, but sorry, bandwidth is not free in every country, and neither is the time wasted by redownloading it all. Zac's migration plan doesn't involve moving data at all, merely changing the default for new installs. I think this is a pretty simple migration plan provided you are ok with it taking a decade. It will be hard on doc writers who instead of getting to write /usr/portage everywhere will likely have to write $PORTDIR or $(portageq env PORTDIR) instead. -A -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Arbitrary breakage: sys-fs/cryptsetup
On 03/22/2012 03:20 PM, Alexandre Rostovtsev wrote: [1] For one, genkernel should bomb out if it can't comply with a command-line arg instead of just putting non-alert text up. There is already a bug open about this issue: https://bugs.gentoo.org/show_bug.cgi?id=409277 With that bug fixed by now is there still need for a news entry? Best, Sebastian
Re: [gentoo-dev] New License: FreeBSD License
On Wed, 28 Mar 2012 22:00:17 -0400 Richard Yao r...@cs.stonybrook.edu wrote: You are right. I spoke to ulm about this and the disclaimer can be considered separate from the license. Gentoo/FreeBSD will need to switch to BSD-2, but aside from that, there is no need for a new license. grep shows that a lot of files in freebsd source tree have a 3 clause bsd; if you can identify files with a BSD-2 license, then you can append it to the LICENSE field, but a switch is incorrect A.
Re: [gentoo-dev] Arbitrary breakage: sys-fs/cryptsetup
On 03/29/2012 12:58 PM, Sebastian Pipping wrote: On 03/22/2012 03:20 PM, Alexandre Rostovtsev wrote: [1] For one, genkernel should bomb out if it can't comply with a command-line arg instead of just putting non-alert text up. There is already a bug open about this issue: https://bugs.gentoo.org/show_bug.cgi?id=409277 With that bug fixed by now is there still need for a news entry? Best, Sebastian It doesn't look fixed to me, only temporarily worked around to force USE static on cryptsetup. Should be kept open until genkernel is fixed to generate the initramfs in a way it doesn't need the static cryptsetup. I've been told dracut is able to handle this. Unverified. - Samuli
[gentoo-dev] Last rites: net-im/twittare
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (29 Mar 2012) # Does not work with twitter anymore. Dead upstream # Fails because of underlinking. Bug #379277 net-im/twittare - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPdK4wAAoJEPqDWhW0r/LChRYP/jd4QuW19b/qEblEAC14Jmi0 k72cCHxgJhNhOFdqy8UC0PTTkpbBynjhwp+z7TF9pOyKi3Iyo2dOmza8hd8q8N+3 xv9IbJGddghLSX62kvWHwT8WlOFyM3OaeB+3Qm87xEcFuZUJIreC9DIAIoxgdb1L yeczfi1Aq3eYkSZUm+Juh4jyg46gVs/NJ5+yUdHVDT3bZCWoiAkFvlVhE/hkSlB+ i5C6ab0It5sX8BpDn5c4GtLotmWYCg1g3MQlSu3QybrOhZ4EMn/olJW6gzl+1cnk mZXjyHF3xlskiEOsR2hn97ldyBNwPFju7/LzRJaYSzyfJ/dG3otbi2+kFWoB13pB kvdZRDDC8qZ6PBmGPuZ7ra8MfvNalAF4Xp25youZH1BIQrmNDIUIm6xNZdTHfGPQ Bf78FfzYetyyRyweJm8LGrIpqby556kn4MAKX9DAjSqkc1oMFnCw+75LPVOKRaRN PksM7aDlfSTiMeRVhoZKwDKgxcclt+p9DDkjLMg+apnMrBSe/E3nU9tf0OuChj9E L8O1IRQtuOE7Zkk5OwJTTg4xHdpEzzH6DWBpvsE9hHeQ29NzICXV18v+o+GlmBNh sTCGZSIg748012E2SAuHeYeKGZfYWRFgqZhcFPNma5+00+IvbB9kSomswqwfy9oY E0TC620tezjlGsESz0JH =yw8E -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: location of portage tree
On 2012.03.28 08:46, Alex Alexander wrote: On Tue, Mar 27, 2012 at 02:05:54PM -0500, William Hubbs wrote: All, I know this has come up before, but I don't really recall what the specific objections were. IMO the portage directory doesn't belong under /usr at all. [snip] William If/when this happens, we should also consider improving the internal structure of the portage folder. At the moment we just throw everything in it, which is not very user friendly. I recommend creating a subfolder for the actual tree, keeping distfiles and packages out. For example, my /usr/portage/ on this system looks like this: portage/ tree/ profiles/ - tree/profiles/ distfiles/ packages/ layman/ it is a big improvement over the current distfiles-and-packages-mixed-with-tree-while-layman-wanders state :) -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com Lets move packages/ out of there. I share /usr/portage over NFS to several different arches. Sharing /usr/portage/packages is a really bad idea in that set up. As they all run ~arch, they all build packages so I can downgrade quickly. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees
Re: [gentoo-dev] rfc: location of portage tree
On 2012.03.28 20:04, Rich Freeman wrote: On Wed, Mar 28, 2012 at 2:53 PM, Christoph Mende ange...@gentoo.org wrote: I believe it's /var/lib/name. Here's what FHS says: /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. I can do rm -rf /usr/portage ; mkdir /usr/portage ; emerge --sync and it will work just fine, I think. That's pretty much what happened in a stage1 or stage2 install. Its not cache though as you don't get back the same data as was deleted. Think 6 month old install. That really does point to cache. The only thing different from a browser cache is that portage doesn't automatically refresh it. distfiles and packages are the same (well, depending on where you get your binpackages from, that might or might not be a cache per-se - if you're just using FEATURES=buildpkg then you can do an emerge -e world and get it back). Nope. If you have just done rm -rf /usr/portage ; mkdir /usr/portage ; emerge --sync, then emerge -e world gets you the equivelent of emerge --sync emerge world -uDN Even if you haven't fetched a new tree, you have lost all your old binary packages, which you were keeping in case of a broken ~arch upgrade that needs to be reverted in a hurry. e.g. one of the nice big shiny packages that emerge -e world just updated for you. [snip] Rich -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees
Re: [gentoo-dev] automated bug filing (i.e. pybugz) failing because of missing token
On Tue, Mar 27, 2012 at 1:03 PM, William Hubbs willi...@gentoo.org wrote: On Tue, Mar 27, 2012 at 05:19:10PM +0200, Paweł Hajdan, Jr. wrote: On 3/26/12 7:20 PM, Mike Gilbert wrote: On Mon, Mar 26, 2012 at 1:08 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: I posted this issue here because it's not obvious what to do with it. That version of pybugz worked for me before (20 February 2012). Any ideas? I'm guessing it was broken by the upgrade from Bugzilla 4.0 to Bugzilla 4.2. I think you should file a bug for pybugz. :) Right, and indeed I've found existing https://github.com/williamh/pybugz/pull/19 (there is patch inside). That is now merged into pybugz-, but it had nothing to do with the bugzilla 4.2 issues. I will see what else I can come up with, but patches/suggestions are welcome. William My plan is to add support for the jsonrpc api, which I was going to do this weekend. -A
Re: [gentoo-dev] rfc: location of portage tree
On Thu, Mar 29, 2012 at 10:26:22PM +1300, Kent Fredric wrote Though of course, if anybody has custom stuff in say, /usr/portage/local/ which they make by hand, nuking /usr/portage will make you *Very* unpopular. http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#book_part3_chap5 in the install handbook gives /usr/local/portage as an example overlay directory. I thought it was implicit that one shouldn't edit or create files in /usr/portage because they may be overwritten by the system e.g. during an emerge --sync. Maybe the manual needs to state this explicitly. Also, /usr/local is the standard place to keep one's own software and/or global customizations that aren't handled by the package manager, but don't belong in one user's home directory. -- Walter Dnes waltd...@waltdnes.org
