Re: [gentoo-dev] Re: Packages/build systems not honoring LINGUAS and a sane solution
On Mon, Feb 20, 2012 at 03:16:29PM -0800, Alec Warner wrote: On Mon, Feb 20, 2012 at 1:26 PM, Jeroen Roovers j...@gentoo.org wrote: On Mon, 20 Feb 2012 14:00:31 -0600 Ryan Hill dirtye...@gentoo.org wrote: Yes, please. Once these get fixed then we can drop localepurge. That's a lot of bugs to fix, and the way LINGUAS now works, we could at least do with a QA check that helps figure out which packages break when new translations are added to new releases, or when old translations get dropped. And please ignore hyperactive bug wranglers who think they get to decide when you've filed enough bugs. We want these reports. Give the guy bug assignment privileges and move on. And/or get the automated check in place, and make sure package maintainers see them. I gave him editbugs last week. Tracker bug #405485 added. Not wanted man pages are also considered as wrong locale installed bugs? Right now I have about 30 directories in /usr/share/man with different (not wanted) languages... Piotr Szymaniak. -- - Poznaje sie tylko to, co sie oswoi - powiedzial lis. - Ludzie maja zbyt malo czasu, aby cokolwiek poznac. Kupuja w sklepach rzeczy gotowe. A poniewaz nie ma magazynow z przyjaciolmi, wiec ludzie nie maja przyjaciol. -- Antoine De Saint-Exupery, Le Petit Prince signature.asc Description: Digital signature
[gentoo-dev] Re: color management in gentoo (kde expecially) proposal for help
re-adding the list, gmail still fool me some times. 2012/2/23 Kai-Uwe Behrmann k...@gmx.de: Hello, glad to read from you. Am 23.02.12, 15:47 +0100 schrieb Francesco Riosa: Hi, my name is Francesco Riosa, I would be interested in a more complete support of the oyranos color managment programs in ::gentoo. Oyranos is intended to be multy platform and in some sense multy os, but in the current incarnation has good support for kde. Joseph works on a GUI front end for Qt to broaden the support. And you are right, KDE's KolorManager is in the best shape. Synnefo is already in a good shape too right? I would also like to see a complete replacement for icc-examin, expecially it's ability to see multiply profiles in the same 3d space, you know, to be able to say those 300€ for a better monitor were a good price ;-) In case there is interest I can apply to return as a developer in gentoo, will respond to emails this week end (25/26 Feb) I read this as a offer to help packaging in gentoo. Typical I work with packagers and like to easen their work. Personally I maintain a openSUSE colour managed software stack as packager myself and be open for suggestions or ideas from Fedora and gladly from gentoo as well. indeed it's an offer for direct or proxyed help gentoo, a pair of ideas that would help gentoo later Often it was mentioned to use autotools or cmake. The next soon to be released rersion of libXcm, one small library, will be autotooled. The conversion is a hard and time consuming part for me, but we hope to get all packages converted. Initially I had some help, which was a good kick off. unlike the rest of the world I prefer cmake over autotools, but if you need help on autotools I suggest to ask this list, there is a lot of expertise here and packagers are going to fix bug in build system anyway, so better soon than later. Gentoo has good support for quite every build system out there, but yes the two you mentioned are preferred. While gentoo is more flexible than binary distro, there is one thing that help them a lot, do releases (possibly often), they need a fixed point to start with, having only a git repository where to pull mean to be a second class cityzen. In case you want to maintain gentoo specific files inside the upstream packages and keep them up to date, that is possible. I do so with a rpm and deb make target. Not sure if that makes sense for gentoo. I'm quite sure it's not needed, to the opposite, generally those files go out of sync easily and are better mantained by gentoo devs. The build scripts and a README are linked here: http://www.oyranos.org/wiki/index.php?title=Oyranos/git icc_examin-build-local.sh can be adapted. As one nice step it would be great, if you can name one or more command lines to get gentoo ready for building Oyranos and the other parts of the software stack. So people could test Oyranos from git easily inside gentoo. I've the complete oyranos software stack building well in gentoo at the moment (using git) :-) I'm _not_ offering support for digikam, for which I develop, because I would like to mantain a two step verification process (developer/packager) Regards, Francesco kind regards Kai-Uwe -- www.oyranos.org oy#open...@freenode.org
Re: [gentoo-dev] RFC patch for obs-service.eclass
Michal Hrusecky - 11:18 21.02.12 wrote:
Hi,
any objections against following patch? I guess I'm the only one using
this eclass anyway. So what the patch does. In gentoo we have build
renamed to avoid clashes and moved to the different directory. More and
more services are using parts of the build, so instead of patching all
services, I think it would be better to do it in eclass.
During last checks before commiting I found an error I overlooked
previously due to some changes elsewhere, so here is the latest patch I
want to commit (also incorporates the feedback I received).
--
Michal Hrusecky mi...@gentoo.org
? obs-service.eclass.patch
Index: obs-service.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/obs-service.eclass,v
retrieving revision 1.1
diff -u -B -r1.1 obs-service.eclass
--- obs-service.eclass 16 Sep 2011 15:49:19 - 1.1
+++ obs-service.eclass 24 Feb 2012 10:19:00 -
@@ -65,13 +65,25 @@
SRC_URI+= ${OBS_URI}/${i}
done
-S=${WORKDIR}
-
-# @FUNCTION: obs-service_src_configure
+# @FUNCTION: obs-service_src_unpack
# @DESCRIPTION:
# Does nothing. Files are not compressed.
obs-service_src_unpack() {
debug-print-function ${FUNCNAME} $@
+ cd ${DISTDIR}
+ mkdir -p ${S}
+ cp ${A} ${S}
+}
+
+# @FUNCTION: obs-service_src_prepare
+# @DESCRIPTION:
+# Replaces all /usr/lib/build directories with /usr/share/suse-build to reflect
+# where suse-build is installed in Gentoo.
+obs-service_src_prepare() {
+ debug-print-function ${FUNCNAME} $@
+ debug-print Replacing all paths to find suse-build in Gentoo
+ find ${S} -type f -exec \
+ sed -i 's|/usr/lib/build|/usr/share/suse-build|g' {} +
}
# @FUNCTION: obs-service_src_install
@@ -81,17 +93,17 @@
debug-print-function ${FUNCNAME} $@
debug-print Installing service \${OBS_SERVICE_NAME}\
exeinto /usr/lib/obs/service
- doexe ${DISTDIR}/${OBS_SERVICE_NAME}
+ doexe ${S}/${OBS_SERVICE_NAME}
insinto /usr/lib/obs/service
- doins ${DISTDIR}/${OBS_SERVICE_NAME}.service
+ doins ${S}/${OBS_SERVICE_NAME}.service
if [[ -n ${ADDITIONAL_FILES} ]]; then
debug-print Installing following additional files:
debug-print${ADDITIONAL_FILES}
exeinto /usr/lib/obs/service/${OBS_SERVICE_NAME}.files
for i in ${ADDITIONAL_FILES}; do
- doexe ${DISTDIR}/${i}
+ doexe ${S}/${i}
done
fi
}
-EXPORT_FUNCTIONS src_install src_unpack
+EXPORT_FUNCTIONS src_install src_prepare src_unpack
signature.asc
Description: Digital signature
Re: [gentoo-dev] Understanding the LINGUAS variable and use-expand
On Wed, Feb 8, 2012 at 12:04 PM, Mart Raudsepp l...@gentoo.org wrote:
On K, 2012-02-08 at 11:32 -0500, Mike Gilbert wrote:
I am considering simplifying www-client/chromium from the current mess
based on the linguas USE flags to basically just this:
if [[ ${LINGUAS} ]]; then
for x in *.pak; do
mylang=${x%.pak}
mylang=%{x/-/_}
has $mylang $LINGUAS || rm $x
done
fi
I think users could be surprised a bit about cases where you have
variants or dialects, e.g currently as IUSE=linguas_fr_FR, when users
only have LINGUAS=fr - in gettext they often don't have a fr_FR.po, just
fr.po; if locale has LC_MESSAGE and LANG at fr_FR, it will look at fr
if more specific fr_FR not found.
I define things like LINGUAS=en en_US et et_EE to be really sure, but
I doubt many users do that (but that's just a guess).
If it's exposed via IUSE, then they can at least have some visual cue of
that.
I guess it wouldn't be a concern if we had a tool to set the LINGUAS
that handled this variant logic nicely, or just educating users in
documentation, make.conf.example comments and so on.
Thanks for catching that Mart. I think I have addressed the dialect
issue by more directly emulating the autoconf macro. See below.
I would greatly appreciate any additional feedback anyone has on this subject.
New code, currently used (experimentally) in
google-chrome-19.0.1049.3_alpha123257.ebuild:
if [[ %UNSET% != ${LINGUAS-%UNSET} ]]; then
local found desiredlang presentlang pak pakname
pushd ${CHROME_HOME}locales /dev/null || die
for pak in *.pak; do
pakname=${pak%.pak}
pakname=${pakname/-/_}
presentlang=$(chromium_lang ${pakname})
# Do not issue warning for en_US locale. This is the fallback
# locale so it should always be installed.
if [[ ${presentlang} == en_US ]]; then
continue
fi
found=
for desiredlang in ${LINGUAS}; do
if [[ ${desiredlang} == ${presentlang}* ]]; then
found=1
break
fi
done
if [[ -z ${found} ]]; then
rm ${pak} || die
fi
done
popd /dev/null
fi
Re: [gentoo-dev] eutils.eclass: make_desktop_entry doesn't follow freedesktop spec
On Thu, 23 Feb 2012, Pacho Ramos wrote: The cited specification [1] says: | The table below describes Additional Categories. The Related | Categories column lists one or more categories that are suggested | to be used in conjunction with the Additional Category. As I read it, Utility is only a suggestion, but isn't mandatory as main category for TextEditor. [1] http://standards.freedesktop.org/menu-spec/latest/apa.html I have no problem on moving them to Development if you think their fit better there Please do. Ulrich
[gentoo-dev] preserve_old_lib and I'm even more lazy
Currently preserve_old_lib functions generate two commands per preserved lib: # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' # rm '/usr/lib/libv8.so.3.9.4' I'd like to modify eutils.eclass to only generate one command: # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' \ rm '/usr/lib/libv8.so.3.9.4' What do you think? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On Fri, Feb 24, 2012 at 1:43 PM, Alexis Ballier aball...@gentoo.org wrote: moreover the wont delete the lib if revdep-rebuild failed i think, so it should be even safer to copy/paste :) Am I the only paranoid person who moves them rather than unlinking them? Oh, if only btrfs were stable... Rich
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
El vie, 24-02-2012 a las 18:56 +0100, Paweł Hajdan, Jr. escribió: Currently preserve_old_lib functions generate two commands per preserved lib: # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' # rm '/usr/lib/libv8.so.3.9.4' I'd like to modify eutils.eclass to only generate one command: # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' \ rm '/usr/lib/libv8.so.3.9.4' What do you think? Great, I am already running both in that way manually ;) signature.asc Description: This is a digitally signed message part
[gentoo-dev] btrfs status and/was: preserve_old_lib
Rich Freeman posted on Fri, 24 Feb 2012 13:47:45 -0500 as excerpted: On Fri, Feb 24, 2012 at 1:43 PM, Alexis Ballier aball...@gentoo.org wrote: moreover the wont delete the lib if revdep-rebuild failed i think, so it should be even safer to copy/paste :) FWIW this is the preserved_libs feature/bug I ran into in early testing, that convinced me to turn it off. Running revdep-rebuild manually was far safer anyway, since at least then I /knew/ the status of various libs, they weren't preserved on first run, then arbitrarily deleted on second, even if it still broke remaining depending apps to do so. So if that was reliably fixed, I'd be FAR happier about enabling FEATURES=preserved-libs. I'm not sure I actually would as I like a bit more direct knowledge of stale libs on the system than the automated handling gives me, but at least I'd not have to worry about the so-called preserved libs STILL disappearing and leaving broken packages, if I DID enable it! So definitely ++ on this! =:^) Am I the only paranoid person who moves them rather than unlinking them? Oh, if only btrfs were stable... FWIW, in the rare event it breaks revdep-rebuild or the underlying rebuilding itself, I rely on my long set FEATURES=buildpkg and emerge -K. In the even rarer event that too is broken, there's always manual untarring of the missing lib from the binpkg (I've had to do that once when gcc itself was broken due to an unadvised emerge -C that I knew might break things given the depclean warning, but also knew I could fix with an untar if it came to it, which it did), or if it comes to it, booting to backup and using ROOT= to emerge -K back to the working system. [btrfs status discussion, skip if uninterested.] I'm not sure if that's a reference to the btrfs snapshots allowing rollbacks feature, or a hint that you're running it and worried about its stability underneath you... If it's the latter, you probably already know this, but if it's the former, and for others interested... I recently set the btrfs kernel options and merged btrfs-progs, then read up on the wiki and joined the btrfs list, with the plan being to get familiar with it and perhaps install it. From all the reports about it being an option for various distros, etc, now, and all the constant improvement reports, I had /thought/ that the biggest issue for stability was the lack of an error-correcting (not just detecting) fsck.btrfs, and that the restore tool announced late last year, that allows pulling data off of unmountable btrfs volumes was a reasonable workaround. What I found, even allowing for the fact that such lists get the bad reports and not the good ones, thus paint a rather worse picture of the situation than actually exists for most users, is that... BTRFS still has a rather longer way to go than I had thought. It's still FAR from stable, even for someone like myself that often runs betas and was prepared to keep (and use, if necessary) TESTED backups, etc. Maybe by Q4 this year, but also very possibly not until next year. I'd definitely NOT recommend that anyone run it now, unless you are SPECIFICALLY running it for testing and bug reporting purposes with garbage data (IOW, data that you're NOT depending on, at the btrfs level, at all) that you are not only PREPARED to lose, but EXPECT to lose, perhaps repeatedly, during your testing. IOW, there's still known untraced and unfixed active data corruption bugs remaining. Don't put your data on btrfs at this point unless you EXPECT to have it corrupted, and want to actively help in tracing and patching the problems! Additionally, for anyone who has been interested in the btrfs RAID capacities, striped/raid0 it handles, but its raid1 and raid10 capacities are misnamed. At present, it's strictly two-way-mirror ONLY, there's no way to do N-way (N2) mirroring aside from layering on top of say mdraid, at all, and of course layering on top of mdraid loses the data integrity guarantees at that level, btrfs still has just the one additional copy it can fall back on. This SERIOUSLY limits btrfs data integrity possibilities in a 2+ drive failure scenario. btrfs raid5/6 isn't available yet, but the current roadmap says kernels 3.4 or 3.5. Multi-mirror is supposed to be built on that code, tho the mentions of it I've seen are specifically triple-mirror, so it's unclear whether arbitrary N-way (N3) mirroring as in true raid1 will be possible even then. But whether triple-way specifically or N-way (N=3), given it's on top of raid5/6, to be introduced in 3.4/3.5, triple-way mirroring thus appears to be 3.5/3.6 at the earliest. So while I had gotten the picture that btrfs was stabilizing and it was mostly over-cautiousness keeping that experimental label around, that's definitely NOT the case. Nobody should really plan on /relying/ on it, even with backups, until at least late this year, and very possibly looking at 2013 now.
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
Am I the only paranoid person who moves them rather than unlinking them? Oh, if only btrfs were stable... Is this a reference to snapshots? You can use ZFS for those. The kernel modules are only available in the form of ebuilds right now, but they your data should be safe unless you go out of your way to break things (e.g. putting the ZIL/SLOG on a tmpfs). Alternatively, there is XFS, which I believe also supports snapshots.
Re: [gentoo-dev] btrfs status and/was: preserve_old_lib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Have you tried ZFS? The kernel modules are in the portage tree and I am maintaining a FAQ regarding the status of Gentoo ZFS support at github: https://github.com/gentoofan/zfs-overlay/wiki/FAQ Data stored on ZFS is generally safe unless you go out of your way to lose it (e.g. put the ZIL/SLOG on a tmpfs). On 02/24/12 18:26, Duncan wrote: Rich Freeman posted on Fri, 24 Feb 2012 13:47:45 -0500 as excerpted: On Fri, Feb 24, 2012 at 1:43 PM, Alexis Ballier aball...@gentoo.org wrote: moreover the wont delete the lib if revdep-rebuild failed i think, so it should be even safer to copy/paste :) FWIW this is the preserved_libs feature/bug I ran into in early testing, that convinced me to turn it off. Running revdep-rebuild manually was far safer anyway, since at least then I /knew/ the status of various libs, they weren't preserved on first run, then arbitrarily deleted on second, even if it still broke remaining depending apps to do so. So if that was reliably fixed, I'd be FAR happier about enabling FEATURES=preserved-libs. I'm not sure I actually would as I like a bit more direct knowledge of stale libs on the system than the automated handling gives me, but at least I'd not have to worry about the so-called preserved libs STILL disappearing and leaving broken packages, if I DID enable it! So definitely ++ on this! =:^) Am I the only paranoid person who moves them rather than unlinking them? Oh, if only btrfs were stable... FWIW, in the rare event it breaks revdep-rebuild or the underlying rebuilding itself, I rely on my long set FEATURES=buildpkg and emerge -K. In the even rarer event that too is broken, there's always manual untarring of the missing lib from the binpkg (I've had to do that once when gcc itself was broken due to an unadvised emerge -C that I knew might break things given the depclean warning, but also knew I could fix with an untar if it came to it, which it did), or if it comes to it, booting to backup and using ROOT= to emerge -K back to the working system. [btrfs status discussion, skip if uninterested.] I'm not sure if that's a reference to the btrfs snapshots allowing rollbacks feature, or a hint that you're running it and worried about its stability underneath you... If it's the latter, you probably already know this, but if it's the former, and for others interested... I recently set the btrfs kernel options and merged btrfs-progs, then read up on the wiki and joined the btrfs list, with the plan being to get familiar with it and perhaps install it. From all the reports about it being an option for various distros, etc, now, and all the constant improvement reports, I had /thought/ that the biggest issue for stability was the lack of an error-correcting (not just detecting) fsck.btrfs, and that the restore tool announced late last year, that allows pulling data off of unmountable btrfs volumes was a reasonable workaround. What I found, even allowing for the fact that such lists get the bad reports and not the good ones, thus paint a rather worse picture of the situation than actually exists for most users, is that... BTRFS still has a rather longer way to go than I had thought. It's still FAR from stable, even for someone like myself that often runs betas and was prepared to keep (and use, if necessary) TESTED backups, etc. Maybe by Q4 this year, but also very possibly not until next year. I'd definitely NOT recommend that anyone run it now, unless you are SPECIFICALLY running it for testing and bug reporting purposes with garbage data (IOW, data that you're NOT depending on, at the btrfs level, at all) that you are not only PREPARED to lose, but EXPECT to lose, perhaps repeatedly, during your testing. IOW, there's still known untraced and unfixed active data corruption bugs remaining. Don't put your data on btrfs at this point unless you EXPECT to have it corrupted, and want to actively help in tracing and patching the problems! Additionally, for anyone who has been interested in the btrfs RAID capacities, striped/raid0 it handles, but its raid1 and raid10 capacities are misnamed. At present, it's strictly two-way-mirror ONLY, there's no way to do N-way (N2) mirroring aside from layering on top of say mdraid, at all, and of course layering on top of mdraid loses the data integrity guarantees at that level, btrfs still has just the one additional copy it can fall back on. This SERIOUSLY limits btrfs data integrity possibilities in a 2+ drive failure scenario. btrfs raid5/6 isn't available yet, but the current roadmap says kernels 3.4 or 3.5. Multi-mirror is supposed to be built on that code, tho the mentions of it I've seen are specifically triple-mirror, so it's unclear whether arbitrary N-way (N3) mirroring as in true raid1 will be possible even then. But whether triple-way specifically or N-way (N=3),
Re: [gentoo-dev] btrfs status and/was: preserve_old_lib
On Fri, Feb 24, 2012 at 8:06 PM, Richard Yao r...@cs.stonybrook.edu wrote: Have you tried ZFS? Yes - but not terribly interested in doing that on linux. I do appreciate that it can be done, but still lacks raid-z reshaping, which means it isn't quite flexible enough. On 02/24/12 18:26, Duncan wrote: FWIW, in the rare event it breaks revdep-rebuild or the underlying rebuilding itself, I rely on my long set FEATURES=buildpkg and emerge -K. I also use buildpkg, but I don't keep them around forever. I'm not sure if that's a reference to the btrfs snapshots allowing rollbacks feature, or a hint that you're running it and worried about its stability underneath you... That would be the former. I'm QUITE aware of its stability. I've played around with it on a VM - I posted on my blog an experience with it around a year ago as well. It has come quite a way, but it is definitely not production quality. Xfs-tools is useful if you want to try breaking it - I think I posted on my blog an article about capturing linux kernel core dumps for debugging purposes - it panics quite readily. If you do want to mess with it I'd recommend using the git kernel maintained by the btrfs team. It is obviously bleeding-edge, but due to the high pace of fixes it tends to be more stable than the version in the mainline kernel. Rich
[gentoo-dev] Re: About gcc-4.6 unmasking
On Mon, 20 Feb 2012 19:03:13 -0600 Ryan Hill dirtye...@gentoo.org wrote: On Mon, 20 Feb 2012 21:34:14 +0100 Pacho Ramos pa...@gentoo.org wrote: I don't know if this has been discussed before but, what issues are preventing us from unmasking gcc-4.6 (and think on a near stabilization)? I have read hardmask message but it simply explains that it's masked for testing purposes :-/ Grub is the only blocker. I don't want to unmask something that makes people's systems unbootable. Okay, I'm bringing up a dual-boot system this weekend. If I can get it to fail I'll have something to debug. If not, I'm just going to make grub die on amd64 when 4.6 is used. So, wish me bad luck. :D -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On Fri, Feb 24, 2012 at 7:31 PM, Richard Yao r...@cs.stonybrook.edu wrote: Am I the only paranoid person who moves them rather than unlinking them? Oh, if only btrfs were stable... Is this a reference to snapshots? You can use ZFS for those. The kernel modules are only available in the form of ebuilds right now, but they your data should be safe unless you go out of your way to break things (e.g. putting the ZIL/SLOG on a tmpfs). Alternatively, there is XFS, which I believe also supports snapshots. I've been using btrfs exclusively for about 6 months, and I don't *think* I've lost anything... :)
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On Fri, Feb 24, 2012 at 10:44 PM, Mike Gilbert flop...@gentoo.org wrote: I've been using btrfs exclusively for about 6 months, and I don't *think* I've lost anything... :) From what I've seen as long as you keep things simple, and don't have heavy loads, you're at least reasonably likely to get by unscathed. I'd definitely keep good backups though. Just read the mailing lists, or for kicks run xfs-test on your server. Xfs-test doesn't do any direct disk access or anything like that - it is no different than running bazillions of cat's, mv's, rm's, cp's, etc. It most likely will panic your system if you try it on btrfs - on ext4 it will probably load the living daylights out of it but you should be fine. The issues with btrfs at this point are the ones that aren't so easy to spot, like race conditions, issues when you use more unusual configurations, and so on. Oh, and go ahead and try filling up your disk some time. If your kernel is recent enough it might not panic when you get down to a few GB left. I'm eager for the rise of btrfs - it IS the filesystem of the future. However, that cuts both ways right now. Rich
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On Fri, 2012-02-24 at 22:44 -0500, Mike Gilbert wrote: On Fri, Feb 24, 2012 at 7:31 PM, Richard Yao r...@cs.stonybrook.edu wrote: Am I the only paranoid person who moves them rather than unlinking them? Oh, if only btrfs were stable... Is this a reference to snapshots? You can use ZFS for those. The kernel modules are only available in the form of ebuilds right now, but they your data should be safe unless you go out of your way to break things (e.g. putting the ZIL/SLOG on a tmpfs). Alternatively, there is XFS, which I believe also supports snapshots. I've been using btrfs exclusively for about 6 months, and I don't *think* I've lost anything... :) I did ... tried it out and found it tougher than reiserfs to break which is saying something considering how flaky extended 2/3 proved for the same task. Problem was, once it broke you couldnt fix it :( Also there are some things that dont work, one of which was a few packages would always fail to emerge when using btrfs for temp storage (I think one was libreoffice) So I deleted the btrfs partitions and put reiserfs back ... BillK
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On 02/24/2012 08:10 PM, William Kenworthy wrote: Also there are some things that dont work, one of which was a few packages would always fail to emerge when using btrfs for temp storage (I think one was libreoffice) I've been using btrfs for temp storage, for more than a year, and haven't noticed any problems with specific packages (libroffice builds fine). The only problems I've experienced are: 1) Intermittent ENOSPC when unpacking lots of files. Maybe this is related to having compression enabled. I haven't experienced it lately, so maybe it's fixed in recent kernels. 2) Bug 353907 [1] which is fixed in recent kernels and coreutils. [1] https://bugs.gentoo.org/show_bug.cgi?id=353907 -- Thanks, Zac
[gentoo-dev] rfc: virtual/modutils and module-init-tools
All, in preparation to unmask udev-181, it was brought to my attention that a number of packages in the tree have direct dependencies on module-init-tools. Udev-181 requires kmod, which is a replacement for module-init-tools. I have added virtual/modutils to the tree which as of now prefers module-init-tools over kmod. The dependencies on module-init-tools in the tree should be changed to virtual/modutils. I am willing to do this myself if no one objects. If I do, should I open individual bugs for the packages? Also, this brings up another question. I replaced module-init-tools in the system set with virtual/modutils. But, since it is possible to have a linux system with a monolithic kernel, should this even be in the system set? If not, once the dependencies are correct, I propose dropping virtual/modutils from the system set. On the other hand, if we want virtual/modutils in the system set, there should be no dependencies in the tree on virtual/modutils. Thoughts? William pgp4lnvXWSch3.pgp Description: PGP signature
