Re: [gentoo-dev] /usr vs. initramfs redux
On Fri, Aug 05, 2011 at 07:42:29PM -0500, William Hubbs wrote: On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: That said, I'm a bit hesitant to describing that we recommend it regardless of the situation. What is wrong with describing when? At least inform our users that the udev rules have evolved to more than just detect and mknod scripts and that they are now relying on files and binaries available in other locations, like /usr and /var. It looks like the situation where we will have to have one is if /usr and /var are not on the same file system as /, because of how udev has evolved. This isn't always true. I have /usr and /var on separate logical volumes (and as such, separate file systems) yet I don't use DEVTMPFS nor an initrd/initramfs, so I'm sure that the answer is a bit more specific. Wkr, Sven Vermeulen
Re: [gentoo-dev] RFC: virtual/icon-theme
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/02/2011 07:30 PM, Chí-Thanh Christopher Nguyễn wrote: Markos Chandras schrieb: - --: Not all packages include the same icons so users may end up with missing icons for some applications. However, most icon themes should include all the basic icons. You could have USE flags for the virtual, so that some package could depend on virtual/icon-theme[foo-icons], while the virtual depends on foo-icons? ( || ( list of packages known to contain foo-icons ) ) Of course, this makes sense only if it is known or easy to find out which icon-themes contain which icons. Best regards, Chí-Thanh Christopher Nguyễn I plan to go ahead with my proposal. I wont use any use flags for now. Whoever feels this virtual is useful for him, he can use it, otherwise you may skip it. I will send the virtual ebuild for review before I commit it to portage tree. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOPR7JAAoJEPqDWhW0r/LCETEQAIxjs/Zi2RvjS5mnRwdp9Vqs 9brEuEXMXb6+vRwN3yfDS02a+Q+GbRz5acBI4o6d8eGOiOa/IVNzn8/EaQ7qLeGb EXrGKW6Guf0dzRvZYgwUP4CnMF6gc0pSxsH6tFdKJw6ZkXXXJHeBl5iEXTFa8fSd 2QX7pfAJlzPFLhJiyBquJ06WBCN+0SOKqEDLm3NKCB7Kb4k5IpDGvy7N3xa71pV2 8XVtlfYtXpG6sF/XuUiRk7sPJ8ZWQyRlUR9EQHBVW3SF/I3LF8plTEIBTTq1Bg5n uxmHtJHS2S3+ew77SYUuXrUsuAR2xFPryJPQ6IQqPhvJuaQleBbkaql5o3dUkHqv Gxh+CbP4wT7geb4YphR+Yn06LVUymCOhgGsK2WSOwORmWwSjHqSsX2XQLvpjey6S RL1xLS2pYvIJRcHULuU58osOZZDr8K9rO6SS/GeWJJWkjiCR+i5sywsKnnO8VR7y 1L+SOOxNiUkHgy0EMiemER1TNl7TUbJslG/J8l+BbA7BWF6iiO104exF13JVcFsk jKw7MnCs85qiTWIsLLvytXE58HwJfNin3YlrrDKJFw7AsMb7WgD4ZraUAi2UwMGH k8fuzRAxBmmTEHS0CimwsjdAvnJE8LQtoIdChnjrLGeYuJwir8DaM8vzEi7jUV+7 FwQxDY0fXEfJKiX/xRMa =DD2m -END PGP SIGNATURE-
Re: [gentoo-dev] Delivery reports about your e-mail
On Wed, Aug 3, 2011 at 07:43, Michał Górny wrote: A good moderation would be to require PGP signatures as well but I guess many devs still don't do that. while ideal, but would be an annoyingly high barrier for less up-to-speed peeps, or for people using webmail -mike
[gentoo-dev] Last rites: gnome-extra/gget
Has no maintainer. Has runtime problems. Dead upstream. Removal in 30 days. Bug #377979 gnome-extra/gget -- Peter.
[gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
All, When we migrate away from CVS for gentoo-x86 (gx86), as it looks now, the same structure will be kept as we have in CVS now. Policies to reject merge commits and only allow rebases on e.g. the Git infrastructure will even more closely match the central and server-based way of working Gentoo is used to now. In this email, I step away from the current model that Gentoo uses for the gentoo-x86 repository. Instead, I consider a repo-per-package model, as in use by e.g. Fedora [1] and Debian [2]. In short, the repo-per-package model means that each package (my-cat/package) is a separate repository in some VCS. Instead of having a huge tree that will only grow forever (gx86), packages are just in their own repository. This approach can potentially be interesting for a number of reasons: - history is per package + package is likely to be small enough not to have to consider any history removal/splitting -- everything can be retained + if a package is removed, it's repository is simply no longer considered, hence its existence and history doesn't clobber a main repository + since the repository can move, its history can also easily move along with its location, being either a category, or even as purpose (e.g. packages that started on sunrise, or in developer overlays) - tree generation is dynamic + a full (rsync) tree has to be created by first getting all repositories, and/or getting them up-to-date -- avoid those packages you don't need + easy to make different trees, e.g. a server tree (no GNOME, KDE), prefix tree (different versions of packages), etc. + easy to move packages around, their category is specified by the tree configuration, the repository the package lives in doesn't change, probably overlays, betagarden, graveyard, sunset, etc. can all go + no restriction to using only a single VCS, because packages are just refreshed before inclusion in the tree, their (source) origin doesn't matter - per package branches + instead of developing in overlays, simply branches could be used, such that a single place is sufficient to for each package + switching branches can implement atomic tree-wide changes for complex situations No restriction to using a only a single VCS. While I don't think that allowing developers to use their VCS of choice is very relevant when committing package changes, the ability to use more than just *one* VCS when assembling the rsync tree is a huge advantage if we want to migrate away from the current CVS tree slowly during a migration period. It could enable the use of git (the obvious choice of many) now, alongside the current gx86 tree. Because the rsync tree would be generated by assembling all packages that need to be in the tree, the only thing necessary for that generation is to understand which VCS commands to use to acquire/update a package and what files/directories to skip when copying the package to its final destination in the rsync tree. This is easily scriptable, given that only the old gx86 tree will be CVS, and the rest git. When rsync tree generation would be based on a file with packages to include, I can imagine a simple way define where the package comes from, and where it should end up, e.g.: my-cat;package1;git://git.g.o/foo-package.git;optionalbranch my-cat;package2;cvs://cvs.g.o/gentoo-x86/my-cat/package2; which defines the category, the package name, its source location, and perhaps something like a branch or tag in case we ever want to e.g. split development (what is now in overlays typically) from what's in the tree. Branch support would also be useful for e.g. Prefix modifications to a package, when only checked out by Prefix rsync tree generation. It can as well be a solution for what is often referred to as the slacker arches problem, when old versions of ebuilds that a maintainer wants to drop, remain available for minority arches that need them, but only for their rsync tree, without bothering the maintainer with it. Obviously, in an ideal world all packages would be in the same VCS, git in this case. With a system like this, however, CVS packages can slowly be moved to git, as their maintainers see fit. Some developers aim to benefit more from git than others. They can move their packages, directly. For the remaining packages, eventual migration is necessary, but they should block developers that want to use git for their packages less. There probably are drawbacks to this system as well. I, however, only see big advantages for the moment. Comments, thoughts, ideas welcome. [1] http://pkgs.fedoraproject.org/gitweb/ [2] http://packages.qa.debian.org/common/index.html -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/06/2011 03:13 PM, Fabian Groffen wrote: All, I think this post belongs to either -project or -scm MLs but anyway When we migrate away from CVS for gentoo-x86 (gx86), as it looks now, I like your proposal but please clarify the following two questions 1) Each package requires a new repository. Who is responsible to create that? Should developers be responsible to do that or they should ping infra? 2) Assuming the repository for a new package was created. Who is responsible to include this in the rsync generation file? I think your approach requires centralised administration to ensure minimal incidents in the infrastructure mechanisms. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOPV9gAAoJEPqDWhW0r/LCXYUP/12m801wqAFfb0mdLkckCpa4 x/B4JNYPRqu+ec8ItO+WqOlDpNdg/QSfaGy/6YwCqp4jS0Ijz+MoZDGElgyjnhTD 0M8KiYKZKlhPsf/skWfs1wfFH0IPzCBfz7+soCAp8Lx30LMqZUJjFu5jTpQRS9KX Aegn8LIlhJIF8tQk9RlfsMdqybMLLw6IGPlylDGJ0pRcJ8oGycRbePF4Gko5m5QJ iBofXfYhkZTL5vhlFotbdnVdW3q+MlwvSge4liVKiWhjLUJGvJdvJCfL85fOSQGO z1qBkOKannmdc4O4xxN2H4dVseA8rHbY1ZzxHqo5w0B5YHSJjPMe0a7CuuBXx0fW VKbC/ctVgUq1sE9caXWZQTKoV/Sy0pmokrcV0tiNELXvuw8zotNH6QO/Po3ud1WL /iLPGgyM2hT3956Zwf2nEsiTyYZIbJ0yQnFdVf4xBM//ngZfEs1cuMOAqNd7JMb+ D77Gwgs4TB2wie7WKWbYN6jrWcOCjH3BrIWz9ZHZ7+JbE1kemWG/EzNh3OO+XDKD OiKsr6IgC75K2/jTCGf8yqMlw49RodCVLHnpORlxtBgzJbVHm/hxARaFllTTAaGx 7bp25JlQId1R1lMcVOR2T5G7AMmaHEeymK6Kizx3M9xIdowxDGGx1dYRmV3a6D0c 8jL2ZFvO4AZmL+y6jQLc =XFxx -END PGP SIGNATURE-
Re: [gentoo-dev] /usr vs. initramfs redux
* Samuli Suominen schrieb am 05.08.11 um 15:43 Uhr: On 08/05/2011 04:12 PM, Marc Schiffbauer wrote: OTOH the initrd that Robin described would be a very static solution with almost no dependencies, so if genkernel had a USE flag like dracut it would be possible to build it without dracut dependency and thus would allow for smaller systems. To clarify, By dependencies in dracut you mean udev? For example yes. And by smaller systems you mean systems without udev? No. Then yes, such minimal initramfs should propably be covered in the embedded's documentation, but otherwise trying to avoid dracut is reinventing the wheel... You may be right, but to my understanding such a minimalistic initrd would really do nothing special. Possibly a small shell script run in a static busybox would do the job, Given some required conditions like having a normal boot device like /dev/sda is given this thingy would just mount the rootfs, read some config,, then mount other things like /usr and thats it. Not to forget pivot_root and starting the real init of course. Maybe something like: pseudo shell mode #!/bin/sh mount -t proc proc /proc rootfs=`sed 's/.*root=\([^ ]*\)/\$1` /proc/cmdline mount $rootfs /newroot while read device mnt fstype; do mount -t $fstype $device $mnt done /newroot/etc/initramfs.mount cd /newroot pivot_root . /oldroot exec chroot . /sbin/init # END -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpgrutzKyU1Q.pgp Description: PGP signature
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
On 7/27/11 10:06 AM, Arfrever Frehtes Taifersar Arahesis wrote: python.eclass from python overlay supports EAPI=4. Sounds good to me. Why isn't it yet in the main portage tree? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
Hey, On Sat, Aug 6, 2011 at 7:43 PM, Fabian Groffen grob...@gentoo.org wrote: In this email, I step away from the current model that Gentoo uses for the gentoo-x86 repository. Instead, I consider a repo-per-package model, as in use by e.g. Fedora [1] and Debian [2]. In short, the repo-per-package model means that each package (my-cat/package) is a separate repository in some VCS. Instead of having a huge tree that will only grow forever (gx86), packages are just in their own repository. I had mixed feelings while reading your email. The idea is certainly very intriguing, but there's a few things that make it a no-go for me: 1. One of the big things I've been looking forward to with git is the ability to do atomic commits across the tree. Addition of GNOME releases, pkgmove changes across the tree, changing ebuild/eclass behaviour, etc. without inconsistency or praying that my connection doesn't get dropped in the middle of a hundred interrelated commits. Without this feature, I think some arch teams and GNOME/KDE teams will become sad. 2. The ability to do feature commits across the whole tree instead of hundreds of tiny commits everywhere. This combined with the ChangeLog generation will save a lot of time and space. This will especially benefit arch teams, but I've felt the need for this numerous times myself. Example: we moved to using .xz tarballs for GNOME, and that touched a lot of ebuilds, and it was extremely time-consuming to repeat echangelog repoman commit per-package. 3. Adding packages from overlays via `cherry-pick` or `git am` will become extremely tedious. If thin manifests are implemented, a series of patches + a simple merge hook will be all you need to move KDE/GNOME releases from the overlay to the tree. Without a single tree, you need to go back to the current way of doing things. 4. We'll need to write extra tools to keep the user's cat/pkg list up-to-date; adding and removing repositories as needed, etc. This is added complexity for which we'll need volunteers (we've been facing a manpower shortage already...) 5. The total size of the tree will increase a *lot* since all these repositories will no longer share data. The current gentoo-x86 tree stored in git without history takes only ~25MB because ebuilds are extremely redundant. The space requirements will balloon once we need to store 15,000 repositories. And arch teams will have to store *all* of them, often on devices with very low space. The per-package models looks very neat and tidy in some respects, but the loss of a common git repository is too great, IMO. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: /usr vs. initramfs redux
Sven Vermeulen wrote: On Fri, Aug 05, 2011 at 07:42:29PM -0500, William Hubbs wrote: On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote: That said, I'm a bit hesitant to describing that we recommend it regardless of the situation. What is wrong with describing when? At least inform our users that the udev rules have evolved to more than just detect and mknod scripts and that they are now relying on files and binaries available in other locations, like /usr and /var. That seems reasonable. It looks like the situation where we will have to have one is if /usr and /var are not on the same file system as /, because of how udev has evolved. This isn't always true. I have /usr and /var on separate logical volumes (and as such, separate file systems) yet I don't use DEVTMPFS nor an initrd/initramfs, so I'm sure that the answer is a bit more specific. I have the same setup and no issues either. I think the problem is for other devices, eg someone mentioned having a bluetooth adapter in their laptop which gets picked up at boot by udev, but needs helpers in /usr. According to https://bugs.gentoo.org/show_bug.cgi?id=364235#c1 udev marks (or marked) failing probers as missing devices, not failed, so udev- postmount doesn't pick on them as needing to be rescanned. I'm not sure if that bug's been fixed or not; the call to util_run_program is no longer in that function at: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob_plain;f=udev/udev- rules.c;hb=HEAD ..but it might well have the same logical error for all I know. I don't get why we can't allow udev to need localmount, as described in the bug, with CONFIG_DEVTMPFS creating nodes needed to mount /usr /var etc, especially as that setting is now being recommended by upstream. (And ofc we don't have to use it if it's not needed.) Regards, igli. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: /usr vs. initramfs redux
Mike Gilbert wrote: On Fri, Aug 5, 2011 at 10:37 PM, William Hubbs willi...@gentoo.org wrote: Not quite. It is actually inside the kernel binary. You are thinking of an initrd. Look at these files: /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt. /usr/src/linux/Documentation/early-userspace/README The initramfs cpio archive does not HAVE to be inside the kernel binary. It may be assembled as a separate file (perhaps in /boot), and passed to the kernel by the bootloader, just as Rich describes. See the section External initramfs images in ramfs-rootfs-initramfs.txt. There's a great doc at: http://en.gentoo-wiki.com/wiki/Initramfs HTH, igli. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] RFC: virtual/x11-lock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Because of this bug[1] I would like to introduce a new virtual for all the X*lock packages. This will contain the following packages 1) alock 2) slock 3) xlockmore This will be maintained by the desktop-misc herd ( and maybe X11 if you want to ) Unless there are any objections, I will create such a virtual and send it for review [1] https://bugs.gentoo.org/show_bug.cgi?id=347729 - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOPZdCAAoJEPqDWhW0r/LCyqEP+gMTKBrNCwnYWwOX6F5pnjOV RLsjbTm5+ekc7+jYK0ApqOPhLTimhzj7Yf0ves76CJI/9RjB8NyuXQKj0vwMZa/5 ZsxB2q7ayvMFGYGyPyyCvrTQaSTla2A3hmxZZf08dlspFJQqVSIoF1kPz6CxSlfq IQxE3OcxarDEp+c5o2VhVgoevqERz/hFr3yVWTTGCjXqPkn2j5nQw8vBsbJYY2jM Nlvz0pNuNMSk7/rNXJmRiGyLrfQNkPPLEsrHVo+QJcUicLqPm3ykDTlPd62NwAY3 Ro9kP1HnvqvicX4SeNj/fGIinkFEb4aXIpU2OQU31BaqJUKzrM8pUrzKlBT5z5fq VcZ1pHsMRcD82lT0Yn2gH8laA4GkI25BuOnFU8Irqa9YNgQjcHcoN8zFpa7yiXr6 wb2FqmXWjKmkp9unUzyoe8Uuih4ZDokMFaUzKHWQ/KgfAsu4nDVLqse3NVA2Lh9E zMEnrv5mdM0xil9isTA/gcFKfosyxyl/kJkY3YHEG2SUls7tEjYBa4aA8HYSLIUq uSwfIfDrIVndvOdSBKHJgvNQeq37XfU1tgKwFUbPvnFWQESQVLKHGKdAn7sKp+NN wJAKz9sH27vDo85WeHe8nuYuM8iCm4Uxhjtp5ohs4tcmoZ7NdWRC+FQJ41GiKS0p 9q0O0eDnHXvMB+++oo+6 =o6+E -END PGP SIGNATURE-
Re: [gentoo-dev] /usr vs. initramfs redux
On Sat, 6 Aug 2011 17:52:54 +0200 Marc Schiffbauer msch...@gentoo.org wrote: Then yes, such minimal initramfs should propably be covered in the embedded's documentation, but otherwise trying to avoid dracut is reinventing the wheel... You may be right, but to my understanding such a minimalistic initrd would really do nothing special. Possibly a small shell script run You just transformed a minimalistic initrd into awfully complex command interpreter... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
Your idea is a step in the right direction, but the ideal config would have a top level portage.git with sub-modules for each category, as well as for eclass, licenses, profiles and scripts. Each category.git should have sub-modules for each package therein. Within the profiles.git it *might* be reasonable for each directory in arch/ also to be a sub-modules. Or not. That should be dicussed. And the bureaucracy should be minimal. Adding, changing or removing a submodule from its parent repo should only require a call for consensus among the devs, and not be pushed through a small set of devs on some given team. It may also be useful for the process which generates metadata/ to push out to a repo, too, just before syncing out to the rsync mirrors. Having each package in its own repo is a great idea. But a simple recursive git pull to update the whole thing is highly desireable. Git submodules fit the bill perfectly. This would require re-doing the cvs→git conversion, but it’d be worth it. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On 06/08/11 16:13, Fabian Groffen wrote: There probably are drawbacks to this system as well. I, however, only see big advantages for the moment. Comments, thoughts, ideas welcome. To be honest I don't like that idea. I don't see any benefits from doing so: - history per package - huh? git log for specific path/file works, pulling all the history for whole repository is one-time thing, does not happen often, Nirbheek already pointed out some history-sharing issues - tree generation is dynamic - actually I think this is a disadvantage, it has a nice potential to eat a lot of resources on master rsync server, also having different flavours of the tree only brings in added complexity - per package branches - I like overlays, I couldn't care less about branches for single packages :) So: - having it all in single repository means that I need to care only about one thing, not around 14956 of them - git was designed to be efficient with large repositories, use this ability - KISS -- Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On Sat, Aug 06, 2011 at 04:13:52PM +0200, Fabian Groffen wrote: When we migrate away from CVS for gentoo-x86 (gx86), as it looks now, the same structure will be kept as we have in CVS now. Policies to reject merge commits and only allow rebases on e.g. the Git infrastructure will even more closely match the central and server-based way of working Gentoo is used to now. The discussion about rejecting merges was never completed IIRC. I think there may be some very valid cases where we need merges still (esp the big atomic commit cases from KDE/GNOME), but they should still be used sparingly. Additionally, the rebase problem has problems of requiring everybody else to hard-reset their trees if they have pushed to multiple places, then rebase to push to the main tree, so I don't know if that will actually fly. In this email, I step away from the current model that Gentoo uses for the gentoo-x86 repository. Instead, I consider a repo-per-package model, as in use by e.g. Fedora [1] and Debian [2]. Everything you have mentioned here was previously covered in the discussions about Git conversion models. Please consult the history of this list, as well as the -scm list. Additionally, a large discussion about the pros and cons of all 3 models (package per repo, category per repo, single repo) was had at the GSoC mentor summit last year, and a number of the core Git developers were involved in the discussion. Problems: - atomic/well-ordered commits that span packages, eclasses and profiles/ directories. (Esp. committing to eclasses and then packages afterwards). - Massive space overhead: Every .git directory requires a minimum of 25 inodes [1], covering at least 100KiB. We have 15k packages in the tree right now. Assuming there is no tail-packing in use, that's a minimum of 1.5GiB on .git overhead. - Massive space overhead(2): Having a repo per package also removes ANY git compression advantage that would be gained where ebuilds between packages are substantially similar. The _complete_ history packfile for the Tree right is under 1GiB [2]. - Pain in branching/forking: instead of being able to just have your own local clone of the single git repo, a user wanting to work on multiple packages together would need to have repos for ALL of them. No pull/merge ability at all. [1] Git space usage testcase: mkdir foo cd foo git init \ touch bar git commit -m '.' bar \ git gc du .git --exclude '*.sample' find .git ! -name '*.sample' |wc -l [2] Packfile size: The final proposal regarding packfile size was that we were going to partition older history using grafts, similar to when Linus moved the kernel into Git, and had a graft available of the old history. Initial packfile size was under 50MiB. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
I really love the idea of being able to atomically push updates across multiple CPVs. This is also what KDE, GNOME, and many other teams are waiting for. Having multiple repos means no atomicity and at this point, I would rather prefer CVS (omg!). -- Fabio Erculiani
Re: [gentoo-dev] Re: /usr vs. initramfs redux
On 6 August 2011 20:22, Steven J Long sl...@rathaus.eclipse.co.uk wrote: I don't get why we can't allow udev to need localmount, as described in the bug, with CONFIG_DEVTMPFS creating nodes needed to mount /usr /var etc, especially as that setting is now being recommended by upstream. (And ofc we don't have to use it if it's not needed.) Personally, I need udev to start before localmount so that localmount can mount my LVM volumes. I have CONFIG_DEVTMPFS enabled too, and I like how it made my initramfs simpler, but it doesn't read rules from userspace. But udev does.
[gentoo-dev] contribution to colorgcc
Greetings, Is anybody maintaining dev-util/colorgcc? I'd like to contribute certain improvements for gcc and also support for the sun, ibm, hp and intel compilers. I pushed the current version to https://github.com/dgoncharov/colorgcc. You can pull from there or i can submit a set of patches. regards, Dmitry
Re: [gentoo-dev] /usr vs. initramfs redux
On 6 August 2011 20:52, Michał Górny mgo...@gentoo.org wrote: Then yes, such minimal initramfs should propably be covered in the embedded's documentation, but otherwise trying to avoid dracut is reinventing the wheel... You may be right, but to my understanding such a minimalistic initrd would really do nothing special. Possibly a small shell script run You just transformed a minimalistic initrd into awfully complex command interpreter... The /init on the initramfs should be a shell script, shouldn't it? If this initramfs is going to be recommended in the handbook, we need to provide an initramfs that isn't going to be too difficult to understand. Like one that can be simply extracted, tweaked, and re-compressed.
Re: [gentoo-dev] contribution to colorgcc
El 07/08/11 02:48, Dmitry Goncharov escribió: Is anybody maintaining dev-util/colorgcc? Yes the shell-tools herd. You can email them at shell-tools (at) g.o signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: /usr vs. initramfs redux
On Sat, Aug 06, 2011 at 08:22:23PM +0100, Steven J Long wrote: I have the same setup and no issues either. I think the problem is for other devices, eg someone mentioned having a bluetooth adapter in their laptop which gets picked up at boot by udev, but needs helpers in /usr. According to https://bugs.gentoo.org/show_bug.cgi?id=364235#c1 udev marks (or marked) failing probers as missing devices, not failed, so udev- postmount doesn't pick on them as needing to be rescanned. I'm not sure if that bug's been fixed or not; the call to util_run_program is no longer in that function at: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob_plain;f=udev/udev- rules.c;hb=HEAD ..but it might well have the same logical error for all I know. The concern about udev-postmount is the line that says: udevadm trigger --type=failed The --type=failed option is going away and upstream is getting rid of the failed marking eventually; there will be no more failed events either. William pgptI3fWOIy0t.pgp Description: PGP signature
Re: [gentoo-dev] contribution to colorgcc
On Sun, Aug 07, 2011 at 04:34:41AM +0200, Francisco Blas Izquierdo Riera (klondike) wrote: El 07/08/11 02:48, Dmitry Goncharov escribió: Is anybody maintaining dev-util/colorgcc? Yes the shell-tools herd. You can email them at shell-tools (at) g.o Couldn't subscribe to shell-tools (at) lists.gentoo.org. So, i just mailed it to shell-tools (at) gentoo.org. Hope, this email does not require being subscribed. regards, Dmitry
