[gentoo-dev] GSoC proposal: cp --reflink support for zfs.
Hi, I would like to implement cp --reflink support for ZFSOnLinux as my GSoC project. cp --reflink is used to create a COW copy of a file, so the file will not take any disk space if it's not modified. This feature is very useful for cases like storing a lot of almost identical virtual machine images. Also this is a frequently requested feature for ZoL. [1][2][3] Currently only btrfs support this feature, so my goal it to bring it to ZoL as well. I think the only way to do it (without changing too many parts of ZoL) is to use the deduplication feature of zfs. A COW copy could be done by create a new entry in ddt for the old file, and create a new file which points to the ddt entry. Please let me know if this proposal makes sense, and if that's the right way to do it. Thanks. [1]: https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w [2]: https://github.com/zfsonlinux/zfs/issues/405 [3]: https://github.com/zfsonlinux/zfs/issues/1063 -- Regards Yuxuan Shui
Re: [gentoo-dev] Python project is looking for a new PyPy maintainer/hacker
Dnia 2014-01-07, o godz. 10:56:16 Alice Ferrazzi alice.ferra...@gmail.com napisał(a): I'm interested in helping out, I usually use PyPy and im good at python coding. I'm not sure about PyPy code but i will check as fast as i can. Ping. I'm sorry for not replying earlier but I think I expected you'd write again after checking the code :). Are you still interested? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.
On 12/03/14 03:15 AM, Yuxuan Shui wrote: Hi, I would like to implement cp --reflink support for ZFSOnLinux as my GSoC project. cp --reflink is used to create a COW copy of a file, so the file will not take any disk space if it's not modified. This feature is very useful for cases like storing a lot of almost identical virtual machine images. Also this is a frequently requested feature for ZoL. [1][2][3] Currently only btrfs support this feature, so my goal it to bring it to ZoL as well. I think the only way to do it (without changing too many parts of ZoL) is to use the deduplication feature of zfs. A COW copy could be done by create a new entry in ddt for the old file, and create a new file which points to the ddt entry. Please let me know if this proposal makes sense, and if that's the right way to do it. Thanks. [1]: https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w [2]: https://github.com/zfsonlinux/zfs/issues/405 [3]: https://github.com/zfsonlinux/zfs/issues/1063 While I can't comment too much on the technical aspects, they seem to be relatively sound. However, there are some issues with the, er... other aspects, for lack of better terminology. 1. This is possibly out of scope as a Gentoo project, since ZOL is not really part of Gentoo. If it's not, then you're out of luck, because ZOL is not an accepted organization. 2. This is likely too small to be a GSoC project. Perhaps see [0] for a list of example ideas, if only so you can get a grasp on the size of a good project. It does sound like a good idea though, and even if you can't do it as part of GSoC, you should pursue it anyways. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gentoo-functions is in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/03/14 09:10 PM, William Hubbs wrote: On Tue, Mar 11, 2014 at 10:10:42AM -0400, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/03/14 07:30 PM, William Hubbs wrote: All, for bug 373219 [1], we are working on providing a functions.sh that does not rely on OpenRc so that people who are not using OpenRc can completely remove it from their systems. I can now report that gentoo-functions has been added to the tree. Also, I have opened a tracker [2] that explains how to change packages that source /etc/init.d/functions.sh. They should first check for the existence of /lib/gentoo/functions.sh and source that. If it doesn't exist, they should source /etc/init.d/functions.sh. Also, do not add hard dependencies to your packages on gentoo-functions. The goal is to add gentoo-functions to @system once it is stable. The quickest way to find things that will need this fix is to rm /etc/init.d/functions.sh and file bugs against things that break and make them block the tracker. - From what I remember about conversations on this in the past, and hopefully vapier can confirm, the de-facto location for this script is supposed to be /etc/init.d/functions.sh. Was there a general consensus on the approval of that location change? I still think, at worst, we should ensure the gentoo-functions script installs a symlink here (possibly taking over the one installed by openrc, if openrc still installs one) This was discussed at length on the bug. After multiple people presented arguments supporting changing this location, vapier was given ample time to weigh in with reasons that we shouldn't change it. He did not, so it has been changed [1]. yeah.. I scanned that bug, saw his arguments, but didn't see anything afterwards that seemed to address his arguments (nor anything that specifically addressed the removal of /etc/init.d/functions.sh as the de-facto location). Don't get me wrong, i think it is very pertinent to install the actual lib elsewhere, but since this is still the de-facto location we should have a symlink. No, I don't think gentoo-functions should take over the symbolic link in /etc/init.d/functions.sh; that needs to stay with OpenRc. My plan there is to work that into a script that prints a warning message. It will stay that way until openrc-1.0. OpenRc upstream uses semantic versioning [2]. This means that as long as we are at 0.x we have to keep things backward compatible. ...why not? As you've said yourself, nothing related to openrc uses /etc/init.d/functions.sh; if everything else in the tree is going to use the new gentoo-functions lib, why wouldn't custom end-user scripts too? (again, scanned the bug, didn't see anything relevant to this) Also, just to confirm, this new path is compatible with the einfo package used as part of Prefix, yes? Or other arrangements have been made (ie, the einfo package will be dropped from baselayout-prefix)? No one has said anything to me about prefix so I don't know what they want to do. To be honest I would prefer that they drop einfo. unless there is a good reason for them not to. This is something that should probably be managed, then, before the migration to gentoo-functions is completed -- anyone here from th prefix team, that wants to weigh in? Will gentoo-functions work in prefix (well enough to replace einfo)? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlMgXdIACgkQ2ugaI38ACPCseAD/VLbvGkzN53hx8Z0C9xOHlJxe VOZu39w+HQhVa5V6vGMA/A+zmmnKjMV1pqJSgCJhgClBu7Ms9QeauZKcvjeKddqx =Ozpu -END PGP SIGNATURE-
[gentoo-dev] Re: GSoC proposal: cp --reflink support for zfs.
A key feature of reflinks is that they operate on any data in a mountpoint, but what you described only applies to data with a deduplication table entry. In such cases, it do not see what it accomplishes over simply using data deduplication. In specific, there is no efficiency advantage. It is not clear to me that trying to cut corners to obtain one is possible without incurring consistency issues with the deduplication table falling out of sync. In the case that there is no deduplication table entry, you would need to rewrite the file. reflinks are intended to be as done as quickly as hard links, so this would seem to negate the benefit. Matthew Ahrens and I have discussed reflinks in the past and we both agree that they would be non-trivial to implement. That does not mean it cannot be done, but I do not think this particular approach would succeed. However, I encourage you to keep thinking about such things. If you think of a way of doing this that seems workable, it would likely be something that could be made into a GSoC project. With that said, if you want to do a ZoL-related project for Gentoo, I have some other things that I could suggest that I believe are workable. Such ideas are things that I was asked to prepare on extremely short notice and I have not yet had time to publish them. Let me know if you would be interested. On Mar 12, 2014, at 3:15 AM, Yuxuan Shui yshu...@gmail.com wrote: Hi, I would like to implement cp --reflink support for ZFSOnLinux as my GSoC project. cp --reflink is used to create a COW copy of a file, so the file will not take any disk space if it's not modified. This feature is very useful for cases like storing a lot of almost identical virtual machine images. Also this is a frequently requested feature for ZoL. [1][2][3] Currently only btrfs support this feature, so my goal it to bring it to ZoL as well. I think the only way to do it (without changing too many parts of ZoL) is to use the deduplication feature of zfs. A COW copy could be done by create a new entry in ddt for the old file, and create a new file which points to the ddt entry. Please let me know if this proposal makes sense, and if that's the right way to do it. Thanks. [1]: https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w [2]: https://github.com/zfsonlinux/zfs/issues/405 [3]: https://github.com/zfsonlinux/zfs/issues/1063 -- Regards Yuxuan Shui
Re: [gentoo-dev] Make udev optional in net-wireless/bluez?
Gilles Dartiguelongue wrote: Making udev dependency always on is a deliberate choice here I thought Gentoo was about users having choice? Sad face. we simply don't want users to get confused That's not helpful, when the premise is to deliver choice. I hope someone does apply the patch. //Peter pgpwCf0CNVRjg.pgp Description: PGP signature
Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.
On 03/12/2014 08:45 AM, Alex Xu wrote: On 12/03/14 03:15 AM, Yuxuan Shui wrote: Hi, I would like to implement cp --reflink support for ZFSOnLinux as my GSoC project. cp --reflink is used to create a COW copy of a file, so the file will not take any disk space if it's not modified. This feature is very useful for cases like storing a lot of almost identical virtual machine images. Also this is a frequently requested feature for ZoL. [1][2][3] Currently only btrfs support this feature, so my goal it to bring it to ZoL as well. I think the only way to do it (without changing too many parts of ZoL) is to use the deduplication feature of zfs. A COW copy could be done by create a new entry in ddt for the old file, and create a new file which points to the ddt entry. Please let me know if this proposal makes sense, and if that's the right way to do it. Thanks. [1]: https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w [2]: https://github.com/zfsonlinux/zfs/issues/405 [3]: https://github.com/zfsonlinux/zfs/issues/1063 While I can't comment too much on the technical aspects, they seem to be relatively sound. However, there are some issues with the, er... other aspects, for lack of better terminology. 1. This is possibly out of scope as a Gentoo project, since ZOL is not really part of Gentoo. If it's not, then you're out of luck, because ZOL is not an accepted organization. Things that provide us with improvements over what we have are definitely worth consideration as GSoC projects. However, what is accepted ultimately depends on not only feedback from a potential mentor, but also a vote of Gentoo developers. 2. This is likely too small to be a GSoC project. Perhaps see [0] for a list of example ideas, if only so you can get a grasp on the size of a good project. It does sound like a good idea though, and even if you can't do it as part of GSoC, you should pursue it anyways. Leaning on my understanding of ZFS internals, I can say that this is large enough. However, I do not think it will accomplish the desired result if implemented in the manner suggested. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Make udev optional in net-wireless/bluez?
On Wed, 2014-03-12 at 14:24 +0100, Peter Stuge wrote: Gilles Dartiguelongue wrote: Making udev dependency always on is a deliberate choice here I thought Gentoo was about users having choice? Sad face. Gentoo is usually about the maintainer's choice ;) So in the end it's up to Pacho: https://bugs.gentoo.org/show_bug.cgi?id=504324 signature.asc Description: This is a digitally signed message part
[gentoo-dev] crossdev and multilib interference
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
We have a problem where the crossdev pkg-config wrapper scripts
interfere with multilib.
crossdev for example sets in their pkg-config wrappers:
PKG_CONFIG_LIBDIR=${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/share/pkgconfig
Now, SYSROOT is chosen from multiple conditions. When emerging a
package, that happens to be / and thus results in:
//usr/lib/pkgconfig://usr/share/pkgconfig
Build systems like autotools will pick the crossdev provided
i686-pc-linux-gnu-pkg-config for the 32bit ABI which will in turn
override the eclass-exported PKG_CONFIG_LIBDIR and now effectively
find the pkg-config files in /usr/lib64/...
This is not a problem most of the time if the package just wants to
get the libs to link against.
However, every package that tries to access variables that are
different between /usr/lib32/pkgconfig/foo.pc and
/usr/lib64/pkgconfig/foo.pc like libdir will fail or produce
unexpected results.
That already happens for
x11-libs/libva-vdpau-driver
x11-libs/libva (https://bugs.gentoo.org/show_bug.cgi?id=500338)
and there are probably more.
A simple workaround is:
PKG_CONFIG=pkg-config emerge foo
But I think that is not appropriate to set in the eclass. How can we
solve this? Don't bikeshed.
-BEGIN PGP SIGNATURE-
iQJ8BAEBCgBmBQJTIIE5XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgLvMQALJT5uZFBTL5mHNBjezudMHo
ceHY3TzLfeIkWHedCLU9TAapfLjl677W0jbg25zkLayPtUR3voEAIm6xFZtF2CAS
VsBpArieXQWqtxSrT9hHC1dJeAWQvQs1kyKXBb5ido8sEBb7WpHFlEqwmUY5bn33
TZjGjcQ68EojbcFQl0vmJRx1/bgXxOr9Ir4Y1bFX92S9ENhERnisu3zZrcvC+PyH
XqXg+wFoJfxu1fSL4/llRDfyr0UJWlWdMeCpvwgkhCpn66CBwc50BwokMP4f4x3G
YDbi+1Ep4GIBVHLd5MlfZOkeqhzPQRD10lbnOHmW7Wuh6Mu87UI7G9xHWZcNyEkS
U9Ny0ejyqnx0j5TMgMP/IcpBR1PaRcceTLFYhwJrYucgcB6/YZ1sP81Yce7f2Riy
M6OZontsv8GVbPA4tsgsV4wob6XUzn6d47p4jwbq67u3GUX6QU7fNB0yJ2ga56qV
xvIaEgdOFsAZHOyix6zfTa2AqpE2LQiVfwEF2pI4J4bTCfy7DvfWhuvA5IwWyyFA
jPiGr5xEns85v2q+dagUo/iup9gzbgGQs+dH6w3wXTkip72lnbxHwiz8Pa2eIXVl
+Tvo9vcdVSzw68tF30sS005+HNorCkj/pqdC7FND/KCyC7r3aESmagibqKdUhHPc
9sN1RjgyzXYst5mvQ1Hg
=J4Qp
-END PGP SIGNATURE-
Re: [gentoo-dev] crossdev and multilib interference
On Wed, 2014-03-12 at 15:46 +, hasufell wrote:
We have a problem where the crossdev pkg-config wrapper scripts
interfere with multilib.
crossdev for example sets in their pkg-config wrappers:
PKG_CONFIG_LIBDIR=${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/share/pkgconfig
Now, SYSROOT is chosen from multiple conditions. When emerging a
package, that happens to be / and thus results in:
//usr/lib/pkgconfig://usr/share/pkgconfig
Build systems like autotools will pick the crossdev provided
i686-pc-linux-gnu-pkg-config for the 32bit ABI which will in turn
override the eclass-exported PKG_CONFIG_LIBDIR and now effectively
find the pkg-config files in /usr/lib64/...
This is not a problem most of the time if the package just wants to
get the libs to link against.
However, every package that tries to access variables that are
different between /usr/lib32/pkgconfig/foo.pc and
/usr/lib64/pkgconfig/foo.pc like libdir will fail or produce
unexpected results.
That already happens for
x11-libs/libva-vdpau-driver
x11-libs/libva (https://bugs.gentoo.org/show_bug.cgi?id=500338)
and there are probably more.
A simple workaround is:
PKG_CONFIG=pkg-config emerge foo
But I think that is not appropriate to set in the eclass. How can we
solve this? Don't bikeshed.
Two possibilities:
1. Don't allow crossdev to handle targets which are natively handled by
multilib profiles. For example, is there any legitimate reason for
wanting crossdev's i686 wrappers when on a multilib amd64 profile?
2. Have crossdev install its wrappers in a prefix, for example
in /usr/libexec/crossdev, which gets added to PATH by cross-emerge.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] gentoo-functions is in the tree
On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote: yeah.. I scanned that bug, saw his arguments, but didn't see anything afterwards that seemed to address his arguments (nor anything that specifically addressed the removal of /etc/init.d/functions.sh as the de-facto location). https://bugs.gentoo.org/show_bug.cgi?id=373219#C74 This is the first point when I proposed moving the file with a good argument and asked vapier to weigh in. Below are several points in the discussion where it was made clear that we were moving the file, and also vapier participated in reviewing alternate implementations. He suggested making this part of baselayout instead of introducing a new package. I asked him to connect with me so we could talk about why he felt that was a good place for it (since I didn't because it may need more maintenance than baselayout does). That connect never happened for whatever reason. https://bugs.gentoo.org/show_bug.cgi?id=373219#C93 https://bugs.gentoo.org/show_bug.cgi?id=373219#C95 https://bugs.gentoo.org/show_bug.cgi?id=373219#C96 https://bugs.gentoo.org/show_bug.cgi?id=373219#C116 https://bugs.gentoo.org/show_bug.cgi?id=373219#C119 https://bugs.gentoo.org/show_bug.cgi?id=373219#C120 https://bugs.gentoo.org/show_bug.cgi?id=373219#C124 No, I don't think gentoo-functions should take over the symbolic link in /etc/init.d/functions.sh; that needs to stay with OpenRc. My plan there is to work that into a script that prints a warning message. It will stay that way until openrc-1.0. OpenRc upstream uses semantic versioning [2]. This means that as long as we are at 0.x we have to keep things backward compatible. ...why not? As you've said yourself, nothing related to openrc uses /etc/init.d/functions.sh; if everything else in the tree is going to use the new gentoo-functions lib, why wouldn't custom end-user scripts too? (again, scanned the bug, didn't see anything relevant to this) The relevance is that /etc/init.d/functions.sh is currently part of OpenRc's public API, and semantic versioning has a very specific description of how to deprecate functionality. If Gentoo needs the symlink after it is removed from OpenRc, I think that is the time we can talk about putting it in gentoo-functions. Also, just to confirm, this new path is compatible with the einfo package used as part of Prefix, yes? Or other arrangements have been made (ie, the einfo package will be dropped from baselayout-prefix)? No one has said anything to me about prefix so I don't know what they want to do. To be honest I would prefer that they drop einfo. unless there is a good reason for them not to. This is something that should probably be managed, then, before the migration to gentoo-functions is completed -- anyone here from th prefix team, that wants to weigh in? Will gentoo-functions work in prefix (well enough to replace einfo)? https://bugs.gentoo.org/show_bug.cgi?id=504284 William signature.asc Description: Digital signature
Re: [gentoo-dev] gentoo-functions is in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/03/14 07:30 PM, William Hubbs wrote: The quickest way to find things that will need this fix is to rm /etc/init.d/functions.sh and file bugs against things that break and make them block the tracker. ..is there a tracker bug currently? I did a search but I didn't see anything in particular. It doesn't seem right to use the main bug 373219 ... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlMgkxUACgkQ2ugaI38ACPArRwD9GpFiGgI9K6YwYgWPzaUD9trX 7WFyEXPYvLWZqB9YHgkBAIMnKJVki5M++EuU0AgSbcef0074+eeUixG/v/xcokRK =Hfde -END PGP SIGNATURE-
Re: [gentoo-dev] gentoo-functions is in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/03/14 12:52 PM, William Hubbs wrote: The relevance is that /etc/init.d/functions.sh is currently part of OpenRc's public API, and semantic versioning has a very specific description of how to deprecate functionality. If Gentoo needs the symlink after it is removed from OpenRc, I think that is the time we can talk about putting it in gentoo-functions. Perfect. So long as that path remains intact from the perspective of gentoo's end-users. Thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlMgkzYACgkQ2ugaI38ACPBEQgD/W46QG4tmqFLGQtwCeBgKkwZp QwvsgrGr4UK9SpiM/6ABAL+OStinQ3PYskf+CdmoCXl6lIsCcMYfifmJ5La56N4s =kXCH -END PGP SIGNATURE-
Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.
Hi, On Wed, Mar 12, 2014 at 9:30 PM, Richard Yao r...@gentoo.org wrote: On 03/12/2014 08:45 AM, Alex Xu wrote: On 12/03/14 03:15 AM, Yuxuan Shui wrote: Hi, I would like to implement cp --reflink support for ZFSOnLinux as my GSoC project. cp --reflink is used to create a COW copy of a file, so the file will not take any disk space if it's not modified. This feature is very useful for cases like storing a lot of almost identical virtual machine images. Also this is a frequently requested feature for ZoL. [1][2][3] Currently only btrfs support this feature, so my goal it to bring it to ZoL as well. I think the only way to do it (without changing too many parts of ZoL) is to use the deduplication feature of zfs. A COW copy could be done by create a new entry in ddt for the old file, and create a new file which points to the ddt entry. Please let me know if this proposal makes sense, and if that's the right way to do it. Thanks. [1]: https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w [2]: https://github.com/zfsonlinux/zfs/issues/405 [3]: https://github.com/zfsonlinux/zfs/issues/1063 While I can't comment too much on the technical aspects, they seem to be relatively sound. However, there are some issues with the, er... other aspects, for lack of better terminology. 1. This is possibly out of scope as a Gentoo project, since ZOL is not really part of Gentoo. If it's not, then you're out of luck, because ZOL is not an accepted organization. Things that provide us with improvements over what we have are definitely worth consideration as GSoC projects. However, what is accepted ultimately depends on not only feedback from a potential mentor, but also a vote of Gentoo developers. Maybe I could propose this project to illumos? Since they seems to accept proposal for OpenZFS. 2. This is likely too small to be a GSoC project. Perhaps see [0] for a list of example ideas, if only so you can get a grasp on the size of a good project. It does sound like a good idea though, and even if you can't do it as part of GSoC, you should pursue it anyways. Leaning on my understanding of ZFS internals, I can say that this is large enough. However, I do not think it will accomplish the desired result if implemented in the manner suggested. Could you elaborate why this won't work? Thanks. -- Regards Yuxuan Shui
Re: [gentoo-dev] gentoo-functions is in the tree
On Wed, Mar 12, 2014 at 12:52 PM, William Hubbs willi...@gentoo.org wrote: On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote: ...why not? As you've said yourself, nothing related to openrc uses /etc/init.d/functions.sh; if everything else in the tree is going to use the new gentoo-functions lib, why wouldn't custom end-user scripts too? (again, scanned the bug, didn't see anything relevant to this) The relevance is that /etc/init.d/functions.sh is currently part of OpenRc's public API, and semantic versioning has a very specific description of how to deprecate functionality. If Gentoo needs the symlink after it is removed from OpenRc, I think that is the time we can talk about putting it in gentoo-functions. If the goal is to be able to remove openrc from systems, how does it help that we might fix any breakage after openrc no longer provides it? If the goal is to be able to remove openrc from systems, then something else needs to provide the symlink. I guess in the meantime users could just remove openrc and just manually install the symlink, but that isn't really a clean solution. Otherwise openrc can't be removed until anything that sources this is fixed. If it all does get fixed, then the symlink isn't even needed (though I suppose openrc can still provide it for any other distros that use it). Rich
Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.
On Wed, Mar 12, 2014 at 9:30 AM, Richard Yao r...@gentoo.org wrote: Things that provide us with improvements over what we have are definitely worth consideration as GSoC projects. However, what is accepted ultimately depends on not only feedback from a potential mentor, but also a vote of Gentoo developers. Honestly, this seems like a less-than-ideal fit for Gentoo. We don't really use ZFS at all, other than as yet another package in our tree. Any of the Mozilla/ GSoC ideas would make as much sense to deliver as part of the Gentoo GSoC. Now, if this were about integrating auto-snapshots into the package manager, (like can be done with snapper), etc, then I could see more relevance (though it probably wouldn't rise to a full project). I could also see some kind of project to integrate advanced filesystem features into core elements of our distro across many filesystems (though I don't really see the relevance for reflinks in particular, and they only apply to COW filesystems anyway). This just seems like a ZFS project, and not like a Gentoo project. I'd say the same if this were about adding a mute button to tabs in Chromium, or fixing the offline btrfsck, or whatever. All of those things would be useful to Gentoo, but only insofar as they'd be useful to anybody. Rich
Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.
On Wed, Mar 12, 2014 at 01:19:08PM -0400, Rich Freeman wrote: This just seems like a ZFS project, and not like a Gentoo project. I'd say the same if this were about adding a mute button to tabs in Chromium, or fixing the offline btrfsck, or whatever. All of those things would be useful to Gentoo, but only insofar as they'd be useful to anybody. Agreed. Your dear friends in Debian would enjoy such changes as well, for those using zfs with kfreebsd or a home build of the zol package. Perhaps this would be a fit for upstream? Rich Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: [gentoo-dev] gentoo-functions is in the tree
On Wed, Mar 12, 2014 at 01:08:43PM -0400, Rich Freeman wrote: On Wed, Mar 12, 2014 at 12:52 PM, William Hubbs willi...@gentoo.org wrote: On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote: ...why not? As you've said yourself, nothing related to openrc uses /etc/init.d/functions.sh; if everything else in the tree is going to use the new gentoo-functions lib, why wouldn't custom end-user scripts too? (again, scanned the bug, didn't see anything relevant to this) The relevance is that /etc/init.d/functions.sh is currently part of OpenRc's public API, and semantic versioning has a very specific description of how to deprecate functionality. If Gentoo needs the symlink after it is removed from OpenRc, I think that is the time we can talk about putting it in gentoo-functions. If the goal is to be able to remove openrc from systems, how does it help that we might fix any breakage after openrc no longer provides it? I don't follow this question. If the goal is to be able to remove openrc from systems, then something else needs to provide the symlink. I guess in the meantime users could just remove openrc and just manually install the symlink, but that isn't really a clean solution. Otherwise openrc can't be removed until anything that sources this is fixed. If it all does get fixed, then the symlink isn't even needed (though I suppose openrc can still provide it for any other distros that use it). Here is what I'm going to do inside openrc: /etc/init.d/functions.sh, which is a symlink now, will become an actual script that does the following: source @LIBEXECDIR@/sh/functions.sh ewarn $0: sourcing /etc/init.d/functions.sh is deprecated. ewarn This file will be removed in a future version of OpenRc, so please ewarn source \@LIBEXECDIR@\/sh/functions.sh if you need this functionality. Where @LIBEXECDIR@ is replaced at build time with OpenRc's libexecdir setting. From the gentoo side, when bugs are filed, the maintainers will have to make a decision about whether to source /lib/gentoo/functions.sh or @LIBEXECDIR@/sh/functions.sh based on whether their package really needs OpenRc specific functionality or not. Gentoo end users who are sourcing /etc/init.d/functions.sh will have to make the same decision. Non-gentoo end users will know what they have to do -- fix their scripts to source @LIBEXECDIR@/sh/functions.sh. So, I am having trouble seeing why the symlink will be needed at all after OpenRc removes this script in OpenRc 1.0. William signature.asc Description: Digital signature
[gentoo-dev] Re: GSoC '14 - Improved Cloud Support - Draft proposal
Hi,
On Tue, Mar 11, 2014 at 11:24 PM, Proneet Verma pronee...@gmail.com wrote:
Hi,
I am interested in working on the project Improved Cloud
Supporthttps://wiki.gentoo.org/wiki/Google_Summer_of_Code/2013/Ideas/Improved_cloud_support
for GSoC '14; for which I have drafted out my proposal for your kind
perusal here https://wiki.gentoo.org/wiki/User:Proneetv/GSoC_Proposal.
Some key points of the proposal:-
1) Currently, catalyst doesn't have support for building AMIs for cloud
services, I would like to add this feature to the Catalyst project so that
the releng team can provide Gentoo on AWS using the stages and portage
snapshot which can be built with the gentoo-catalyst tool. Here, I would be
using ec2-{ api, ami }-tools to script actions on EC2 and basically do a
typical handbook install.
2) Docker is an open source tool to easily create lightweight and self
sufficient containers. I would like to enhance the puppet-docker support to
spawn containers with the help of Puppet which is an automation tool for
system administration. Currently,
thishttps://github.com/garethr/garethr-docker has
support for Ubuntu and RedHat distributions, so I would like to add Gentoo
support into it.
3) Jenkins CI is a very popular monitoring tool, and as it isn't there in
the portage tree I would like to write ebuilds for it and become a proxy
maintainer for future support.
4) I am also looking forward to add binary package support for commonly
used packages by cloud users (like nginx, mysql, mongodb etc) as they don't
have much CPU to do on system compiling. Also, this can be improvised as,
writing Puppet class which can help in sharing packages (portage_binhost)
built once across all your systems (compiling once and using it
everywhere). Need to put in more thoughts to this part!
Please provide your feedback.
Thanking you in anticipation.
Regards,
Proneet Verma
(irc: proneet @freenode)
Re: [gentoo-dev] crossdev and multilib interference
On Wed, 12 Mar 2014 12:06:32 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Two possibilities: 1. Don't allow crossdev to handle targets which are natively handled by multilib profiles. For example, is there any legitimate reason for wanting crossdev's i686 wrappers when on a multilib amd64 profile? yes, serving as a distcc server for x86 hosts or using 'cross emerge' to build a x86 root from scratch 2. Have crossdev install its wrappers in a prefix, for example in /usr/libexec/crossdev, which gets added to PATH by cross-emerge. lgtm
Re: [gentoo-dev] gentoo-functions is in the tree
On Wed, 12 Mar 2014 13:02:13 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/03/14 07:30 PM, William Hubbs wrote: The quickest way to find things that will need this fix is to rm /etc/init.d/functions.sh and file bugs against things that break and make them block the tracker. ..is there a tracker bug currently? https://bugs.gentoo.org/show_bug.cgi?id=504116 Alias: functions.sh -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] gentoo-functions is in the tree
On Wed, Mar 12, 2014 at 01:02:13PM -0400, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/03/14 07:30 PM, William Hubbs wrote: The quickest way to find things that will need this fix is to rm /etc/init.d/functions.sh and file bugs against things that break and make them block the tracker. ..is there a tracker bug currently? I did a search but I didn't see anything in particular. It doesn't seem right to use the main bug 373219 ... http://bugs.gentoo.org/show_bug.cgi?id=504116 I thought I mentioned it earlier in the thread; sorry about that. William signature.asc Description: Digital signature
Re: [gentoo-dev] gentoo-functions is in the tree
All, thinking about this further, There may not be a need to remove /etc/init.d/functions.sh as long as it is understood that this is part of OpenRc, not the gentoo base. In other words, tools that must work when OpenRc is not present should source /lib/gentoo/functions.sh, NOT /etc/init.d/functions.sh. What are your thoughts on this approach? William signature.asc Description: Digital signature
Re: [gentoo-dev] gentoo-functions is in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/03/14 03:59 PM, William Hubbs wrote: All, thinking about this further, There may not be a need to remove /etc/init.d/functions.sh as long as it is understood that this is part of OpenRc, not the gentoo base. In other words, tools that must work when OpenRc is not present should source /lib/gentoo/functions.sh, NOT /etc/init.d/functions.sh. What are your thoughts on this approach? William Well, this will leave the de-facto path intact for the majority of users, which sounds great to me. This path -wont- be available for users that don't have openrc installed, but then, if all of the tools in portage are converted to use /lib/gentoo/functions.sh this probably won't matter -- i dont think many custom script writers using a systemd system will care about output consistency with openrc anyhow. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlMgwZoACgkQ2ugaI38ACPDcPgEAhSkoJma2GVfUeKpRoIcvHEQD tivcbFdpHRF3xTtssUYA/RXQvFCkwyqiALsu1Jm94fGTsjT1aCHxYA96oefY++Fv =Vu5p -END PGP SIGNATURE-
Re: [gentoo-dev] Make udev optional in net-wireless/bluez?
On Wed, Mar 12, 2014 at 11:16 AM, Alexandre Rostovtsev tetrom...@gentoo.org wrote: On Wed, 2014-03-12 at 14:24 +0100, Peter Stuge wrote: Gilles Dartiguelongue wrote: Making udev dependency always on is a deliberate choice here I thought Gentoo was about users having choice? Sad face. Gentoo is usually about the maintainer's choice ;) So in the end it's up to Pacho: https://bugs.gentoo.org/show_bug.cgi?id=504324 Honestly, of all the suggestions in this thread having the use-enable config setting and just outputting a warning when udev isn't enabled seems like the best solution. Sure, it is up to the maintainer, but in general we should try to support config options like this. If we only wanted packages that just work with no risk of breakage we'd be running debian. USE flags are a big point of what we're about. Anybody setting USE=-udev system-wide needs to appreciate that stuff like usb/bluetooth/etc which is runtime auto-configuring is fairly likely to not work. The profile defaults already seem reasonable, so it shouldn't be necessary to force it off for a typical user - base users will tend to get udev only if they install something like bluez, which is what 95% of users will want. For those who want to override the defaults we should give them the option to shoot themselves in both feet and the head as well if they are eager. Users who really want the Debian-like experience should just avoid setting use flags at all and pick a profile. USE defaults and profiles really eliminate the need to tweak that stuff, and emerge can auto-set package settings if required for a dependency. Rich
Re: [gentoo-dev] Make udev optional in net-wireless/bluez?
On 03/12/2014 4:21 PM, Rich Freeman wrote: On Wed, Mar 12, 2014 at 11:16 AM, Alexandre Rostovtsev tetrom...@gentoo.org wrote: On Wed, 2014-03-12 at 14:24 +0100, Peter Stuge wrote: Gilles Dartiguelongue wrote: Making udev dependency always on is a deliberate choice here I thought Gentoo was about users having choice? Sad face. Gentoo is usually about the maintainer's choice ;) So in the end it's up to Pacho: https://bugs.gentoo.org/show_bug.cgi?id=504324 Honestly, of all the suggestions in this thread having the use-enable config setting and just outputting a warning when udev isn't enabled seems like the best solution. Agreed, Alex's patch properly addresses the issue I originally raised. My initial thinking was to replace virtual/udev with the more generic virtual/dev-manager, because I didn't dig deep into understanding why virtual/udev was actually needed (I don't use bluetooth on a daily basis). -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.
It is a moot point because I do not think this project idea is feasible. On Mar 12, 2014, at 1:19 PM, Rich Freeman ri...@gentoo.org wrote: On Wed, Mar 12, 2014 at 9:30 AM, Richard Yao r...@gentoo.org wrote: Things that provide us with improvements over what we have are definitely worth consideration as GSoC projects. However, what is accepted ultimately depends on not only feedback from a potential mentor, but also a vote of Gentoo developers. Honestly, this seems like a less-than-ideal fit for Gentoo. We don't really use ZFS at all, other than as yet another package in our tree. Any of the Mozilla/ GSoC ideas would make as much sense to deliver as part of the Gentoo GSoC. Now, if this were about integrating auto-snapshots into the package manager, (like can be done with snapper), etc, then I could see more relevance (though it probably wouldn't rise to a full project). I could also see some kind of project to integrate advanced filesystem features into core elements of our distro across many filesystems (though I don't really see the relevance for reflinks in particular, and they only apply to COW filesystems anyway). This just seems like a ZFS project, and not like a Gentoo project. I'd say the same if this were about adding a mute button to tabs in Chromium, or fixing the offline btrfsck, or whatever. All of those things would be useful to Gentoo, but only insofar as they'd be useful to anybody. Rich
Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.
I do not think the original project idea is feasible as stated. On Mar 12, 2014, at 1:22 PM, Paul Tagliamonte paul...@debian.org wrote: On Wed, Mar 12, 2014 at 01:19:08PM -0400, Rich Freeman wrote: This just seems like a ZFS project, and not like a Gentoo project. I'd say the same if this were about adding a mute button to tabs in Chromium, or fixing the offline btrfsck, or whatever. All of those things would be useful to Gentoo, but only insofar as they'd be useful to anybody. Agreed. Your dear friends in Debian would enjoy such changes as well, for those using zfs with kfreebsd or a home build of the zol package. Perhaps this would be a fit for upstream? Rich Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt
Re: [gentoo-dev] gentoo-functions is in the tree
On 03/13/2014 12:52 AM, William Hubbs wrote: No, I don't think gentoo-functions should take over the symbolic link in /etc/init.d/functions.sh; that needs to stay with OpenRc. My plan there is to work that into a script that prints a warning message. It will stay that way until openrc-1.0. OpenRc upstream uses semantic versioning [2]. This means that as long as we are at 0.x we have to keep things backward compatible. ...why not? As you've said yourself, nothing related to openrc uses /etc/init.d/functions.sh; if everything else in the tree is going to use the new gentoo-functions lib, why wouldn't custom end-user scripts too? (again, scanned the bug, didn't see anything relevant to this) The relevance is that /etc/init.d/functions.sh is currently part of OpenRc's public API, and semantic versioning has a very specific description of how to deprecate functionality. Why deprecate it? I'm getting really irritated with the current trend of randomly renaming and movearounding things. All it does is confuse people, break existing setups and make documentation splitbrained (now you need to document two things, and half the old docs won't be aware of it ...) So I guess it boils down to What does the /usr movearounding gain us, err, what does renaming bits of OpenRC improve? The best explanations so far I've seen are it's nicer, we've already done it and eh mate, why not? is groovy If Gentoo needs the symlink after it is removed from OpenRc, I think that is the time we can talk about putting it in gentoo-functions. Now that is funny, but why move it away just so that users panic and re-add the wrong flavour of it? Well, progress I guess: If you change enough things in trivial ways you can claim innovation and show a great rate of change (I'm not dead yet!) grmblgr, Patrick
Re: [gentoo-dev] gentoo-functions is in the tree
On Thu, 13 Mar 2014 07:59:55 +0800 Patrick Lauer patr...@gentoo.org wrote: On 03/13/2014 12:52 AM, William Hubbs wrote: Why deprecate it? I'm getting really irritated with the current trend of randomly renaming and movearounding things. All it does is confuse people, break existing setups and make documentation splitbrained (now you need to document two things, and half the old docs won't be aware of it ...) So I guess it boils down to What does the /usr movearounding gain us, err, what does renaming bits of OpenRC improve? The best explanations so far I've seen are it's nicer, we've already done it and eh mate, why not? is groovy If Gentoo needs the symlink after it is removed from OpenRc, I think that is the time we can talk about putting it in gentoo-functions. Now that is funny, but why move it away just so that users panic and re-add the wrong flavour of it? Well, progress I guess: If you change enough things in trivial ways you can claim innovation and show a great rate of change (I'm not dead yet!) I would say it's because library code such as that really does not belong in /etc and placing it there in the first place was a mistake. This is an attempt to correct the mistake without just breaking everything without warning.
