Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
Ben, you're really just being a child here. Is that a really big problem to add a small text file to your package?! Is that a big maintaining burden? If you can't test it, systemd team can, just like there are arch teams to test packages on other archs the maintainers can't. It's not something that changes code or functionality to that level that it can't be maintained with help. Nobody is forcing you to use systemd, there are just people how are asking to let them use it. You talk a lot about Gentoo is about choice, but you are not giving that choice. You're forcing people to *not* use systemd (not using something else), because you don't like it. Plain simple. On Sat, May 25, 2013 at 5:00 PM, Pacho Ramos pa...@gentoo.org wrote: El dom, 26-05-2013 a las 00:14 +0800, Ben de Groot escribió: I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing list, since this discussion doesn't really belong on bugzilla. Some background copied from the bug report: [...] Probably your following comment in bug report summarizes the real reasons pointing you to not apply that patch after waiting a year for upstream action: https://bugs.gentoo.org/show_bug.cgi?id=412697#c8 Reading your comments in bug report gave me the impression of you refusing to provide the unit file simply to try to interfere as much as possible with getting higher systemd compatibility in Gentoo, even if I don't see how adding the unit file will hurt openrc users and how it will hurt you (as co-maintainer) when another dev is taking care of unit file and systemd team can also maintain it. We can now have long discussions about upstream decisions, how to handle devrel problems... but I think it's much more easy: this kind of boycott attitudes should stop in favor of common sense.
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
Is the real problem just the god damn unit/init files?! Damn, who cares about 2KiB files in the age of GiBs?! You can install 1000 of them that it will only take 2MiB of storage, so please, quit complaining about this. One thing dev's should take care is (not that affects me, 'cause I really don't care) is mentions to rc-update on einfo's. Again, I really don't care, but, for the sake of making them (openrc, systemd, etc) equal, that really shouldn't be mentioned. On Sat, May 18, 2013 at 5:47 PM, Rich Freeman ri...@gentoo.org wrote: On Sat, May 18, 2013 at 1:38 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: The decision was made long ago. Use flags are not the correct way to control solely the installation of a few small files. This was really the heart of the discussion where the decision was made before. USE flags should control things that affect dependencies, especially linked dependencies. If a package wants to pull in systemd or link to it, then it should have a USE flag if at all possible. Likewise if a package wants to pull in openrc or link to it then it should have a USE flag. When you're talking about just a few text files it isn't worth it. Those who disagree can use INSTALL_MASK and nuke them from orbit. Openrc isn't going anywhere as long as somebody cares to maintain it. I don't see that changing anytime soon, and if it does change the only thing its users can do is step up and maintain it (or pay somebody to do it for them). That's pretty-much how everything works on Gentoo, or any other volunteer distro. Don't worry about it - considering we had a few devs step up and fork udev I doubt openrc is going away anytime soon. Rich
[gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing V2
This is the same patch posted earlier but with the feedback from Steven J.
Long from the last post on the previous thread. (Thanks!)
Signed kernel modules require that the kernel is compiled with
CONFIG_MODULE_SIG=y so that during compilation, the public key hash is
stored in the kernel so that it can be verified later when insmod'ing an
external module. There is no problem with in-tree modules, this are sign
correctly and loaded, the problem is with out-of-the-tree modules installed
by portage; this ones are not signing ware.
So this patch adds a new USE flag to the linux-mod.eclass named
module-signing. We enabled, it will check if the user has selected all
the correct config options in the kernel, and optionally, where are the
private and public parts of the key so that the module is signed and
install time. If any of this fails, the installation of the module is
aborted.
From the end user perspective, if he wants to add support for this, all he
has to do is enable CONFIG_MODULE_SIG in the kernel. If no keys are found
during the build, it will be generated one. If one wants to create a key
himself, it's also possible to use this key, he just has to name it
signing_key.priv and siging_key.x509 and put it under /usr/src/linux.
After the kernel is compiled, this keys can be moved elsewhere and the path
to them specified in make.conf under the vars KERNEL_MODSECKEY and
KERNEL_MODPUBKEY.
Patch below for review, discussion and testing.
Thanks,
Carlos Silva
--- linux-mod.eclass 2012-09-15 16:31:15.0 +
+++ linux-mod.eclass 2013-03-11 18:58:34.075561064 -0100
@@ -125,9 +125,10 @@
inherit eutils linux-info multilib
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst src_install
src_compile pkg_postrm
-IUSE=kernel_linux
+IUSE=module-signing kernel_linux
SLOT=0
-RDEPEND=kernel_linux? ( virtual/modutils )
+RDEPEND=kernel_linux? ( virtual/modutils )
+ module-signing? ( app-crypt/gnupg )
DEPEND=${RDEPEND}
sys-apps/sed
kernel_linux? ( virtual/linux-sources )
@@ -208,6 +209,32 @@
fi
}
+
+# internal function
+#
+# FUNCTION: check_module_signing
+# DESCRIPTION:
+# Checks for KERNEL_MODSECKEY, KERNEL_MODPUBKEY and verifies the files
exists
+check_module_signing() {
+ use module-signing || return 1
+
+ # Check that the configuration is correct
+ KERNEL_MODSECKEY=${KERNEL_MODSECKEY:-${KV_DIR}/signing_key.priv}
+ KERNEL_MODPUBKEY=${KERNEL_MODPUBKEY:-${KV_DIR}/signing_key.x509}
+ if [[ -s ${KERNEL_MODSECKEY} ]]; then
+ eerror KERNEL_MODSECKEY points to a missing or empty file:
+ eerror ${KERNEL_MODSECKEY}
+ die Invalid KERNEL_MODSECKEY
+ fi
+ if [[ -s ${KERNEL_MODPUBKEY} ]]; then
+ eerror KERNEL_MODPUBKEY points to a missing or empty file:
+ eerror ${KERNEL_MODPUBKEY}
+ die Invalid KERNEL_MODPUBKEY
+ fi
+
+ return 0
+}
+
# internal function
#
# FUNCTION: update_depmod
@@ -581,6 +608,10 @@
return
fi
+ if use module-signing; then
+ CONFIG_CHECK+=${CONFIG_CHECK} MODULE_SIG
+ fi
+
linux-info_pkg_setup;
require_configured_kernel
check_kernel_built;
@@ -710,6 +741,12 @@
srcdir=${srcdir:-${S}}
objdir=${objdir:-${srcdir}}
+ if check_module_signing; then
+ ebegin Signing module ${modulename}
+ ${KV_DIR}/scripts/sign-file ${KERNEL_MODSECKEY} ${KERNEL_MODPUBKEY}
${objdir}/${modulename}.${KV_OBJ}
+ eend $?
+ fi
+
einfo Installing ${modulename} module
cd ${objdir} || die ${objdir} does not exist
insinto /lib/modules/${KV_FULL}/${libdir}
[gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
Hi guys,
I normally hang out on irc on #gentoo-kernel and a bunch of other #gentoo-*
channels. I stumble across the discussion of bug 447352 [1] that was
reported by a user that was enforcing module signatures on the kernel. This
made me to this patch (I talked to Mike before doing this).
Signed kernel modules require that the kernel is compiled with
CONFIG_MODULE_SIG=y so that during compilation, the public key hash is
stored in the kernel so that it can be verified later when insmod'ing an
external module. There is no problem with in-tree modules, this are sign
correctly and loaded, the problem is with out-of-the-tree modules installed
by portage; this ones are not signing ware.
So this patch adds a new USE flag to the linux-mod.eclass named
module-signing. We enabled, it will check if the user has selected all
the correct config options in the kernel, and optionally, where are the
private and public parts of the key so that the module is signed and
install time. If any of this fails, the installation of the module is
aborted.
From the end user perspective, if he wants to add support for this, all he
has to do is enable CONFIG_MODULE_SIG in the kernel. If no keys are found
during the build, it will be generated one. If one wants to create a key
himself, it's also possible to use this key, he just has to name it
signing_key.priv and siging_key.x509 and put it under /usr/src/linux.
After the kernel is compiled, this keys can be moved elsewhere and the path
to them specified in make.conf under the vars KERNEL_MODSECKEY and
KERNEL_MODPUBKEY.
Patch below for review, discussion and testing.
Thanks,
Carlos Silva
[1] https://bugs.gentoo.org/show_bug.cgi?id=447352
--- linux-mod.eclass 2012-09-15 16:31:15.0 +
+++ linux-mod.eclass 2013-03-06 15:57:25.808173694 -0100
@@ -125,9 +125,10 @@
inherit eutils linux-info multilib
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst src_install
src_compile pkg_postrm
-IUSE=kernel_linux
+IUSE=module-signing kernel_linux
SLOT=0
-RDEPEND=kernel_linux? ( virtual/modutils )
+RDEPEND=kernel_linux? ( virtual/modutils )
+ module-signing? ( dev-lang/perl dev-libs/openssl )
DEPEND=${RDEPEND}
sys-apps/sed
kernel_linux? ( virtual/linux-sources )
@@ -208,6 +209,34 @@
fi
}
+
+# internal function
+#
+# FUNCTION: check_module_signing
+# DESCRIPTION:
+# Checks for KERNEL_MODSECKEY, KERNEL_MODPUBKEY and verifies the files
exists
+check_module_signing() {
+ if ! use module-signing; then
+ return 1
+ fi
+
+ # Check that the configuration is correct
+ KERNEL_MODSECKEY=${KERNEL_MODSECKEY:-${KV_DIR}/signing_key.priv}
+ KERNEL_MODPUBKEY=${KERNEL_MODPUBKEY:-${KV_DIR}/signing_key.x509}
+ if [ ! -z ${KERNEL_MODSECKEY}x -a ! -e ${KERNEL_MODSECKEY} ]; then
+ eerror KERNEL_MODSECKEY points to a missing file:
+ eerror ${KERNEL_MODSECKEY}
+ die Invalid KERNEL_MODSECKEY
+ fi
+ if [ ! -z ${KERNEL_MODPUBKEY}x -a ! -e ${KERNEL_MODPUBKEY} ]; then
+ eerror KERNEL_MODPUBKEY points to a missing file.
+ eerror ${KERNEL_MODPUBKEY}
+ die Invalid KERNEL_MODPUBKEY
+ fi
+
+ return 0
+}
+
# internal function
#
# FUNCTION: update_depmod
@@ -581,6 +610,10 @@
return
fi
+ if use module-signing; then
+ CONFIG_CHECK+=${CONFIG_CHECK} MODULE_SIG
+ fi
+
linux-info_pkg_setup;
require_configured_kernel
check_kernel_built;
@@ -663,7 +696,7 @@
# This looks messy, but it is needed to handle multiple variables
# being passed in the BUILD_* stuff where the variables also have
- # spaces that must be preserved. If don't do this, then the stuff
+ # spaces that must be preserved. If dont do this, then the stuff
# inside the variables gets used as targets for Make, which then
# fails.
eval emake HOSTCC=\$(tc-getBUILD_CC)\ \
@@ -710,6 +743,12 @@
srcdir=${srcdir:-${S}}
objdir=${objdir:-${srcdir}}
+ if check_module_signing; then
+ ebegin Signing module ${modulename}
+ ${KV_DIR}/scripts/sign-file ${KERNEL_MODSECKEY} ${KERNEL_MODPUBKEY}
${objdir}/${modulename}.${KV_OBJ}
+ eend $?
+ fi
+
einfo Installing ${modulename} module
cd ${objdir} || die ${objdir} does not exist
insinto /lib/modules/${KV_FULL}/${libdir}
Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
On Wed, Mar 6, 2013 at 6:32 PM, Steev Klimaszewski st...@gentoo.org wrote: # This looks messy, but it is needed to handle multiple variables # being passed in the BUILD_* stuff where the variables also have - # spaces that must be preserved. If don't do this, then the stuff + # spaces that must be preserved. If dont do this, then the stuff # inside the variables gets used as targets for Make, which then # fails. eval emake HOSTCC=\$(tc-getBUILD_CC)\ \ ^^ Why did you remove the ' in don't ? Seems like it was an mistake? The rest looks fine to me, maybe Ryao can chime in, I know he was interested in module signing. Yeah, mistake there. I noticed after I sent the email ;) Removed the ' so that vim syntax wouldn't freak. Disregard that part.
Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
On Wed, Mar 6, 2013 at 8:39 PM, Peter Stuge pe...@stuge.se wrote: Carlos Silva wrote: If one wants to create a key himself, it's also possible to use this key, he just has to name it signing_key.priv and siging_key.x509 and put it under /usr/src/linux. Do you know if this is a sane default? Where do most users of signed modules store keys so far? It's where the kernel build system picks them. They only have to be there to build the kernel, nothing else. After the kernel is built, and the modules compiled and signed against that keys, they can even be removed from the system.
Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
On Wed, Mar 6, 2013 at 9:14 PM, Peter Stuge pe...@stuge.se wrote: Carlos Silva wrote: If one wants to create a key himself, it's also possible to use this key, he just has to name it signing_key.priv and siging_key.x509 and put it under /usr/src/linux. Do you know if this is a sane default? Where do most users of signed modules store keys so far? It's where the kernel build system picks them. Are you sure? I find that hard to believe? Even if I tell an external module to build against a source tree in ~/linux/ the Makefiles will go to look for the keys in /usr/src/linux/ ? OK, my bad here. The kernel build system looks for them on the root of the kernel source. To build modules, they can be anywhere as long as you have the correct path set on make.conf: KERNEL_MODSECKEY=/path/to/privkey KERNEL_MODPUBKEY=/path/to/pubkey This only works for modules. They only have to be there to build the kernel, nothing else. I'm not talking about end users, by users I mean those who use the key files to build kernels and modules. See above. I even read online that a best practice would be to generate a new set of keys on every kernel build actually deleting the keys after the kernel and external modules are compiled.
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Mon, Mar 4, 2013 at 3:28 PM, Walter Dnes waltd...@waltdnes.org wrote: I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim Just read this file and you'll have the answer: /usr/src/linux/Documentation/stable_api_nonsense.txt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog
On Sun, Mar 3, 2013 at 1:42 PM, hasufell hasuf...@gentoo.org wrote: What do we have useflags for in gentoo? add a unsupported-kernels useflag, mask it, add a clear statement in the masking reason and be done Not a bad solution, still, I, as a user, don't think making the compilation work with a specific kernel should be considered unsupported. How many times modules stop working because the kernel changed something that breakes compilation? And I'm not only talking about closed source drivers, even open source ones have this problem, but in fact, they are fixed faster. Does the gentoo community really need this kind of strictness? Don't think so.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog
On Sun, Mar 3, 2013 at 4:39 PM, Ryan Hill dirtye...@gentoo.org wrote: On Sat, 2 Mar 2013 23:11:44 -0800 Alec Warner anta...@gentoo.org wrote: I do not find their stance wholly unreasonable. They offered to point users at an overlay, if someone was willing to maintain the patches there (in lieu of user_patches.) The end result is that if users apply the patches, they will get an unsupported setup. There is a fear as well, that the patches may damage cards (since the patches are not supported by the vendor.) We're talking about updating an include path here. Some files moved. I don't think that justifies breaking stable. Exactly my point. This a simple make-it-compile-without-any-new-stuff, not add-this-cool-new-feature-to-the-package patch. There are differences in them... Again, it's just me, and i don't complain if the maintainer doesn't wan't to accept the patch, i'm just expressing my opinion.
[gentoo-dev] Fwd: Retiring...
Hi gang, I'm really sorry to leave you guys but my current life isn't compatible with working on Gentoo. Live is too busy to give Gentoo the time it deserves. I really liked to work with all of you. I'll try to contribute as much as possible via bugzzie. If anyone need any kind of help/information from me, just contact me to this email... Special thanks to dsd_ and johnm [[]] Carlos r3pek Silva -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] fwbuilder and libfwbuilder
Hi guys, if nobody has an objection to it, i'll take maintainership of the fwbuilder/libfwbuilder ebuilds since they are in need of love. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] multislot mysql
On Fri, 2006-02-03 at 10:19 +, Francesco Riosa wrote:
Ok, I've been realized that having a slotted mysql is not the dream of
every end user ... or developer.
Anyway I prefere too keep the possibility to do a similar install.
A good solution should be to add the multislot USE flag to the ebuild
and let it to decide whenever make it slotted or not, sorry, this is not
viable, yes it's already used by other important packages but not well
supported by portage and should be used only in particular situations.
The only thing that came in mind to me is to provide two series of
ebuilds, with different revision ranges.
The use flag multislot will still have a role, to make the ebuild fail
during pkg_setup() if set on the wrong ebuild.
It's possible to define the default ebuild to merge, assigning a greater
revision number will make an ebuild the default installed, I suggest the
un-slotted version to be the default.
example:
mysql-4.1.16-r[0..49] Need +multislot
mysql-4.1.16-r[50..99] Need -multislot
mysql-5.1.18-r[0..49] Need +multislot
mysql-5.1.18-r[50..99] Need -multislot
whoever want to have a slot version will need to mask revisions between
50 and 99 .
The change will happen soon, between today and tomorrow, so toughts,
flames and insults are well accepted.
- Francesco R.
I really don't like this... It will give users more work to maintain
their systems... Managing /etc/portage/ isn't easy, and forcing the
users to use it, isn't good too. I speak for mysql:
[EMAIL PROTECTED] ~ $ cat /etc/portage/package.keywords | wc -l
53
^^ And this was about 100 before i did a cleanup to it.
What i sugest is to create a diferent package, mysql-{slotted,}. You
guys from the mysql herd can use the same ebuils to both packages (the
content i mean) and just check the ${PN} for the slotted word to see if
the package is slotted or not
Just my 0.02€
--
Carlos r3pek Silva
Gentoo Developer (kernel/amd64/mobile-phone)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Unmasking modular X
On Tue, 2006-01-24 at 13:38 +0100, Christian Heim wrote: On Tuesday 24 January 2006 09:34, RH wrote: On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote: A) You have commit access to gentoo-x86, AND B) you're comfortable with the porting process OR are adept with ebuilds and would like to help I'm up for being a volunteer here. Same for me. Add me there -- Carlos r3pek Silva Gentoo Developer (kernel/amd64/mobile-phone) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Just another portage enhancement idea...
On Tue, 2005-10-11 at 09:18 -0400, Dave Nebinger wrote:
This is probably the fifth time at least that I've been bitten by this...
Portage is great in that it manages compiles for a bulk of applications
(including dependencies) in one fell swoop.
Yesterday I emerged gnome - that was it, just gnome, and it took care of the
whole thing soup to nuts. Wahoo, and kudos to all of you who put in the
work.
But here's my issue... In emerging one of the 101 packages missing on my
system for gnome, a little blurb flew buy that should have caught my
attention, a message posted in the pkg_postinst() message indicating what I
should do now that my installation has completed.
That's well and good, but as it was one of only 101 other packages, that
message quickly gets lost in the shuffle.
So here's the enhancement: have portage collect all of these kinds of
messages
and display them after all of the emerging has completed.
So here's my proposed enhancement: Before the call to pkg_postinst(), set a
flag that causes einfo/ewarn/etc. to tee the output generated by the ebuild
to /var/log/portage_postinst.log (or something configurable in make.conf,
whatever). Preface the first generated line with the ${P} so we know what
it's related to. After the pkg_postinst() method completes, clear the flag
and other emerges can carry on as they need to.
Had this kind of thing been in place, after emerging 101 packages I could go
to the postinst log and see everything that I had to do, including the little
blurb that I had missed before.
Yes, I know folks are going to say that you can enable portage logging and
look for messages that need to be taken care of. But I just emerged 101 new
packages, have many emerge -ud worlds, etc. resulting in almost 2000 files
out there in /var/log/portage. Talk about the needle in the haystack,
there's not even some specific keywords I could grep on to hit on the
relevant information.
Understandably I don't know what you all will say about this. It seems like
a
great idea to me, and wouldn't appear to come with all the political issues
that the 'extending the ebuild meta data' or some other issues that have come
up recently.
But I'll leave it to the rest of you to decide...
I could be wrong, and if i am, someone from the portage team to correct
me, but i think this will come in the next major version of the portage
along with the tool elog.
--
Carlos r3pek Silva
Gentoo Developer (kernel/amd64/mobile-phone)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] New global use flag: nsplugin
On Fri, 2005-08-26 at 19:18 +0100, Carlos Silva wrote: Hey! Why was reading the use.local.desc file and noticed that there are 6 packages with this use flag... If nobody oposes it, I'll make it a global use flag with the Description all the nsplugin local flags have :) Just commited the changes to CVS. -- Carlos r3pek Silva Gentoo Developer (kernel/amd64/mobile-phone) signature.asc Description: This is a digitally signed message part
[gentoo-dev] My GPG Key
About a week ago, i sent a mail to this list saying that i lost my key and posting a new one (AAC32A11). Now, i'm sending this email saying that i revoked this new key, since i managed to get my original one. Sorry for any inconvinience. -- Carlos r3pek Silva Gentoo Developer (kernel/amd64/mobile-phone) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Put DESCRIPTION HOMEPAGE and LICENSE in another place
I know that portage team is closed for new features :) but this just came to my mind just 5 minutes ago and seemed good enought to try. Let's just think that portage handles 5 version of package foo and foo has http://www.foo.org; and homepage, GPL-v2 license and foo just make your pc look faster as DESCRIPTION. If we sum all the bytes that this _repeated_ info occupies in app-misc/foo we get 90 bytes (including '=' and '' for package foo. If all the packages in portage were foo's, according to p.g.o there are 9923 packages, we would have 90*9923 witch gives us 893070bytes (893KB) of information that is repeated in many places. Also, we know that some packages have homepages/descriptions/linceses that are bigger then this so, in reality, this number will probably be bigger in real like. With portage growing every day, this will get even bigger. My ideia was to put this kind of repeated information in some other place that is not the ebuild, let's say for e.g. under app-misc/foo/info or metadata.xml. This way, users with slow connections don't download almost 1MB of info every time they sync. What do you think of this? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Put DESCRIPTION HOMEPAGE and LICENSE in another place
On Thu, 2005-08-11 at 01:15 +0100, Ciaran McCreesh wrote: On Thu, 11 Aug 2005 01:04:25 +0100 Carlos Silva [EMAIL PROTECTED] wrote: | What do you think of this? GLEP 5 *G* :) thx for the info btw, why is the status of GLEP 5 timed out? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] devfs is dead, let's move on
On Wed, 2005-07-06 at 15:46 -0700, Greg KH wrote: Ok, now that devfs is removed from the 2.6 kernel tree[1], I think it's time to start to revisit some of the /dev naming rules that we currently are living with[2]. To start with, the 061 version of udev offers a big memory savings if you use the default kernel name of a device[3]. If you do that, it does not create a file in its database in /dev/.udevdb/ If we can move away from some of our devfs-like names, we stand to reclaim a lot of memory from everyone's machines. As an example, if we drop all of the tty/pts/vc/vcc symlinks, and just go with the default kernel name, we save 2.5Mb of space in tempfs/ramfs. I've done this on my machines and everything seems to work just fine (it looks like everything that was trying to use a tty node was just using the symlink anyway.) So, anyone have any objections to me changing the default udev naming scheme in this manner? Next up, that loony block device naming scheme (more on that later...) thanks, greg k-h Sorry to only reply to this now, but i saw a mail of you talking about ndevfs. will that go into 2.6.13? not that i use devfs, 'cause i don't, i'm just curious. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] i have an idea ! (erescue)
On Sun, 2005-05-15 at 17:18 -0400, Mike Frysinger wrote: one advantage that other binary based package managers have over Gentoo is ease of recovery from broken core packages ... break your gcc ? no problem ! simply do `apt-get install gcc` or `rpm -i gcc` or whatever my proposal is to implement a new utility (called 'erescue' for lack of a better name) that is written in C and designed to be statically linked ... then next time you break a core system package which cannot be recovered by simply running `emerge` a few times, you run `erescue broken package` for example, when i broke binutils in unstable with a gcc4 patch, i noticed that it's hard for users to *easily* recover from this ... we developers end up scrambling to build a bunch of binary packages for a variety of compatible compiler/libc combinations so the user can just wget the file and run `emerge binutils.tbz2` and be on their way the packages that would be eligible for an 'erescue' package would be just about everything when you do `USE=-* emerge system -ep` ... i'm sure we can trim many of those out though :) maybe even create a new USE flag for some of these core packages so that we can trim out more files the idea would be to create very bare min packages so that the user can simply 'rescue' themselves ... after that, they it's up to them to re-emerge the package to apply all their fun ricer-optimizations as they see fit i dont think it'd be too hard to integrate this 'rescue set' into a catalyst target so that it'll become part of our normal release schedule of stage tarballs -mike I like the ideia :) signature.asc Description: This is a digitally signed message part
