Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
Am Freitag, 8. Januar 2021, 14:26:32 EET schrieb Joonas Niilola: > # Now my question is, does anyone find any of these packages useful? > Should we go ahead and last-rite them, since it doesn't seem useful to > carry these in Gentoo? The ones broken are heading towards last-riting > nevertheless. We have done such cleanups in the past. Libraries without consumers in the Gentoo tree make in general only limited sense. That said, if they build and have an active maintainer, why not keep them for now. This is more or less a cost/benefit question. > > # So the final list of "useless" libs is: > dev-libs/atcore > dev-libs/bcm2835 > dev-libs/bitset > dev-libs/boost-mpl-cartesian_product > dev-libs/caliper > dev-libs/clhpp > dev-libs/distorm64 > dev-libs/editline > dev-libs/faxpp > dev-libs/go-usb > dev-libs/gtx > dev-libs/igraph > dev-libs/ilbc-rfc3951 > dev-libs/injeqt > dev-libs/jthread > dev-libs/kqoauth > dev-libs/libdivsufsort > dev-libs/libdnsres > dev-libs/libezV24 > dev-libs/libgcrypt-compat > dev-libs/libpcre-debian > dev-libs/libtomfloat > dev-libs/libtompoly > dev-libs/libtreadstone > dev-libs/log4sh > dev-libs/nss-pem > dev-libs/OpenSRF > dev-libs/pigpio > dev-libs/processor-trace > dev-libs/rapidxml > dev-libs/redland-bindings > dev-libs/rinutils > dev-libs/rocm-hostcall > dev-libs/smack > dev-libs/squareball > dev-libs/ustr > dev-libs/vc-intrinsics > dev-libs/xbyak > dev-libs/zookeeper-c > media-libs/cimg > media-libs/elles_icc_profiles > media-libs/esdl > media-libs/fluidsynth-dssi > media-libs/freeverb3 > media-libs/gmtk > media-libs/gnonlin > media-libs/guilib > media-libs/intel-mediasdk > media-libs/kodi-platform > media-libs/libggigcp > media-libs/libggimisc > media-libs/libgroove > media-libs/liblingoteach > media-libs/libyami > media-libs/memphis > media-libs/noise-suppression-for-voice > media-libs/raul > media-libs/sdl-terminal > media-libs/volpack > > > -- juippis -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
On Freitag, 8. Januar 2021 13:26:32 CET Joonas Niilola wrote: > # So the final list of "useless" libs is: > dev-libs/atcore This has IUSE="gui", EAPI=7 and kde proj as maintainer. Please keep. Regards signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
On 1/8/21 5:42 PM, Thomas Deutschmann wrote: > Hi, > > I wonder how you composed this list. If you just checked if there is > any revdep, the check was probably useless: > > For example, > >> dev-libs/cyberjack > > is up-to-date, has an active dev as maintainer and is required for any > ReinerSCT chipcard reader. > > Hey, I admit the motivation didn't come clear from the first post. I believe majority of listed packages to be leftovers from previous removals, thus being "useless" to us now. I also admit to checking git logs for only a handful of packages, and left few active+useful ones out from the list already. This is a genuine inquiry to find out if these libs are somehow useful for someone, not a "last-rites call for action" post ;) Although I probably will continue to look for the really outdated, EAPI-5 etc ones after a certain period of time. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
On Fri, Jan 8, 2021 at 7:27 AM Joonas Niilola wrote: > dev-libs/clhpp We want to keep this, though I admit I don't recall why nothing depends on it.
Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
Hi, please forget my previous mail. I was informed that I misread your mail, sorry about that! -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
Hi, I wonder how you composed this list. If you just checked if there is any revdep, the check was probably useless: For example, dev-libs/cyberjack is up-to-date, has an active dev as maintainer and is required for any ReinerSCT chipcard reader. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
On Fri, 8 Jan 2021 14:26:32 +0200 Joonas Niilola wrote: > dev-libs/libgcrypt-compat > dev-libs/libpcre-debian These are maintained by me and I'd like to keep them. They can be pulled in by running the esteam tool in steam-overlay for games that need them. They could potentially be used for other old or Debian-oriented binary packages too. -- James Le Cuirot (chewi) Gentoo Linux Developer pgp25epsm8vEo.pgp Description: OpenPGP digital signature
[gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
# With the help of jkroon I went through all dev-libs/* and media-libs/* packages and located each one without reverse deps, # List of dev-libs/* and media-libs/* without any revdeps: dev-libs/atcore dev-libs/bcm2835 dev-libs/bemenu dev-libs/bitset dev-libs/boost-mpl-cartesian_product dev-libs/caliper dev-libs/c-capnproto dev-libs/cgilib dev-libs/clhpp dev-libs/cloog dev-libs/cyberjack dev-libs/distorm64 dev-libs/editline dev-libs/faxpp dev-libs/go-usb dev-libs/granite dev-libs/gtx dev-libs/igraph dev-libs/ilbc-rfc3951 dev-libs/injeqt dev-libs/jthread dev-libs/keystone dev-libs/kqoauth dev-libs/libdivecomputer dev-libs/libdivsufsort dev-libs/libdnsres dev-libs/libdynd dev-libs/libezV24 dev-libs/libgcrypt-compat dev-libs/libgpiod dev-libs/liblzw dev-libs/libmelf dev-libs/libpcre-debian dev-libs/libtomfloat dev-libs/libtompoly dev-libs/libtreadstone dev-libs/libusbhp dev-libs/light dev-libs/log4sh dev-libs/nss-pem dev-libs/OpenSRF dev-libs/pigpio dev-libs/processor-trace dev-libs/qrosscore dev-libs/rapidxml dev-libs/redland-bindings dev-libs/replicant dev-libs/rinutils dev-libs/rocm-hostcall dev-libs/smack dev-libs/squareball dev-libs/stp dev-libs/tvision dev-libs/ucommon dev-libs/ustr dev-libs/vc-intrinsics dev-libs/weston dev-libs/xbyak dev-libs/zlog dev-libs/zookeeper-c media-libs/cimg media-libs/elles_icc_profiles media-libs/esdl media-libs/fluidsynth-dssi media-libs/freeverb3 media-libs/gmtk media-libs/gnonlin media-libs/guilib media-libs/icclib media-libs/intel-mediasdk media-libs/jbig2enc media-libs/kodi-platform media-libs/libbsb media-libs/libggigcp media-libs/libggimisc media-libs/libgroove media-libs/libicns media-libs/liblingoteach media-libs/libmpeg3 media-libs/libmpris2client media-libs/libsixel media-libs/libyami media-libs/memphis media-libs/noise-suppression-for-voice media-libs/phat media-libs/raul media-libs/sdl-terminal media-libs/taglib-extras media-libs/tse3 media-libs/volpack # Following packages did not compile: dev-libs/caliper https://bugs.gentoo.org/737106 (dev-libs/papi, a build-dep is broken) dev-libs/zookeeper-c https://bugs.gentoo.org/747592 media-libs/intel-mediasdk https://bugs.gentoo.org/740070 # Already package.masked: dev-libs/ilbc-rfc3951 dev-libs/OpenSRF dev-libs/ustr # Following packages appear in optfeature or elog otherwise: (none) # These packages install binaries, emerged with USE="tools": dev-libs/bemenu dev-libs/c-capnproto dev-libs/cgilib dev-libs/cloog dev-libs/cyberjack dev-libs/granite dev-libs/keystone dev-libs/libdivecomputer dev-libs/libdynd dev-libs/libgpiod dev-libs/liblzw dev-libs/libmelf dev-libs/libusbhp (/usr/bin/hptest) dev-libs/light dev-libs/qrosscore dev-libs/replicant dev-libs/stp dev-libs/tvision dev-libs/ucommon dev-libs/weston dev-libs/zlog media-libs/icclib media-libs/jbig2enc media-libs/libbsb media-libs/libicns media-libs/libmpeg3 media-libs/libmpris2client media-libs/libsixel media-libs/phat media-libs/taglib-extras media-libs/tse3 # So the final list of "useless" libs is: dev-libs/atcore dev-libs/bcm2835 dev-libs/bitset dev-libs/boost-mpl-cartesian_product dev-libs/caliper dev-libs/clhpp dev-libs/distorm64 dev-libs/editline dev-libs/faxpp dev-libs/go-usb dev-libs/gtx dev-libs/igraph dev-libs/ilbc-rfc3951 dev-libs/injeqt dev-libs/jthread dev-libs/kqoauth dev-libs/libdivsufsort dev-libs/libdnsres dev-libs/libezV24 dev-libs/libgcrypt-compat dev-libs/libpcre-debian dev-libs/libtomfloat dev-libs/libtompoly dev-libs/libtreadstone dev-libs/log4sh dev-libs/nss-pem dev-libs/OpenSRF dev-libs/pigpio dev-libs/processor-trace dev-libs/rapidxml dev-libs/redland-bindings dev-libs/rinutils dev-libs/rocm-hostcall dev-libs/smack dev-libs/squareball dev-libs/ustr dev-libs/vc-intrinsics dev-libs/xbyak dev-libs/zookeeper-c media-libs/cimg media-libs/elles_icc_profiles media-libs/esdl media-libs/fluidsynth-dssi media-libs/freeverb3 media-libs/gmtk media-libs/gnonlin media-libs/guilib media-libs/intel-mediasdk media-libs/kodi-platform media-libs/libggigcp media-libs/libggimisc media-libs/libgroove media-libs/liblingoteach media-libs/libyami media-libs/memphis media-libs/noise-suppression-for-voice media-libs/raul media-libs/sdl-terminal media-libs/volpack # Now my question is, does anyone find any of these packages useful? Should we go ahead and last-rite them, since it doesn't seem useful to carry these in Gentoo? The ones broken are heading towards last-riting nevertheless. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
El mié, 11-02-2015 a las 09:22 +0100, Jeroen Roovers escribió: On Sun, 08 Feb 2015 11:17:19 +0100 Pacho Ramos pa...@gentoo.org wrote: Many times has raised the question about how we could handle those packages (like icon packs, wallpapers...) that are not arch dependent and, then, could be stabilized all at the same time by the first arch team that is going to stabilize it. If you do that, then what is the point of having a stable request in the first place? The many-eyeballs argument is gone then, so what are we left with? The point is to test if it breaks depending on the arch, not to get it tested by maintainers + a random of arch teams depending on each package For example, for ubuntu-wallpapers package there is no need to overload three different arch-teams (or even more if it was keyworded on more arches) It isn't a team that is doing the stabilisation, it's a single person who may or may not have looked at what the new version does and how well it installs, and may or may not feel some pressure to rush it. As I said before many times, having more people on more architecture teams look at the same problem actually helps catch bug at a late stage but arguably still in time. Removing or weakening that last line of defence (either by having a single person do stabilisations for multiple architectures, or by removing most architecture teams from each single task) will increase the bug rate for stable ebuilds (even more). jer Current situation only leads to stabilizations hanging for months with some arch teams having really big pending lists (taking care of their rate of stabling). Of course, if you want to have an exception for HPPA (as it has for other stuff like the profiles), there is no problem. We can keep leaving hppa there if you want to double check them (HPPA is not a problem as it has a stable tree that is small enough to be maintainable)
Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
On Sun, 08 Feb 2015 11:53:39 -0500 Brian Evans wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/08/2015 05:17 AM, Pacho Ramos wrote: Hello Many times has raised the question about how we could handle those packages (like icon packs, wallpapers...) that are not arch dependent and, then, could be stabilized all at the same time by the first arch team that is going to stabilize it. Some months ago it was suggested that this packages could have a KEYWORD with a value like ~arch for example that could indicate this situation: http://www.gossamer-threads.com/lists/gentoo/dev/283020 But it was shown that it would be difficult to make it work properly at PM level. Then, I was wondering if we could handle this simply by having: - A new keyword for bugzilla like STABLEREQALL to easily allow arch teams to filter this kind of packages and handle them in this special way - A new key for metadata.xml files to specify there that the package can be handled in that way. What do you think about this? It wouldn't need any change at PM level and, then, it should be easy to do. I would like to see packages with PHP scripts (only) be included with such a proposal. i.e. dev-php/PEAR-* . They are only text files which may only rely on dev-lang/php USE which are simple to detect with repoman failures. This is way too dangerous. Perl packages are also text files, but there was a case in history, when perl package was working only on specific architecture. Best regards, Andrew Savchenko pgpDXI3JuR17b.pgp Description: PGP signature
Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
Pacho Ramos pa...@gentoo.org napisał: El mié, 11-02-2015 a las 09:22 +0100, Jeroen Roovers escribió: On Sun, 08 Feb 2015 11:17:19 +0100 Pacho Ramos pa...@gentoo.org wrote: Many times has raised the question about how we could handle those packages (like icon packs, wallpapers...) that are not arch dependent and, then, could be stabilized all at the same time by the first arch team that is going to stabilize it. If you do that, then what is the point of having a stable request in the first place? The many-eyeballs argument is gone then, so what are we left with? The point is to test if it breaks depending on the arch, not to get it tested by maintainers + a random of arch teams depending on each package For example, for ubuntu-wallpapers package there is no need to overload three different arch-teams (or even more if it was keyworded on more arches) But what if the wallpapers contain exploits that work only on specific arches? ;) It isn't a team that is doing the stabilisation, it's a single person who may or may not have looked at what the new version does and how well it installs, and may or may not feel some pressure to rush it. As I said before many times, having more people on more architecture teams look at the same problem actually helps catch bug at a late stage but arguably still in time. Removing or weakening that last line of defence (either by having a single person do stabilisations for multiple architectures, or by removing most architecture teams from each single task) will increase the bug rate for stable ebuilds (even more). jer Current situation only leads to stabilizations hanging for months with some arch teams having really big pending lists (taking care of their rate of stabling). Of course, if you want to have an exception for HPPA (as it has for other stuff like the profiles), there is no problem. We can keep leaving hppa there if you want to double check them (HPPA is not a problem as it has a stable tree that is small enough to be maintainable) Of course there's always the option of dropping stable keywords. -- Michał Górny
Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
On Sun, 08 Feb 2015 11:17:19 +0100 Pacho Ramos pa...@gentoo.org wrote: Many times has raised the question about how we could handle those packages (like icon packs, wallpapers...) that are not arch dependent and, then, could be stabilized all at the same time by the first arch team that is going to stabilize it. If you do that, then what is the point of having a stable request in the first place? The many-eyeballs argument is gone then, so what are we left with? It isn't a team that is doing the stabilisation, it's a single person who may or may not have looked at what the new version does and how well it installs, and may or may not feel some pressure to rush it. As I said before many times, having more people on more architecture teams look at the same problem actually helps catch bug at a late stage but arguably still in time. Removing or weakening that last line of defence (either by having a single person do stabilisations for multiple architectures, or by removing most architecture teams from each single task) will increase the bug rate for stable ebuilds (even more). jer
[gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
Hello Many times has raised the question about how we could handle those packages (like icon packs, wallpapers...) that are not arch dependent and, then, could be stabilized all at the same time by the first arch team that is going to stabilize it. Some months ago it was suggested that this packages could have a KEYWORD with a value like ~arch for example that could indicate this situation: http://www.gossamer-threads.com/lists/gentoo/dev/283020 But it was shown that it would be difficult to make it work properly at PM level. Then, I was wondering if we could handle this simply by having: - A new keyword for bugzilla like STABLEREQALL to easily allow arch teams to filter this kind of packages and handle them in this special way - A new key for metadata.xml files to specify there that the package can be handled in that way. What do you think about this? It wouldn't need any change at PM level and, then, it should be easy to do.
Re: [gentoo-dev] Suggestion about how to tell ATs that a package can be stabilized on all arches at the same time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/08/2015 05:17 AM, Pacho Ramos wrote: Hello Many times has raised the question about how we could handle those packages (like icon packs, wallpapers...) that are not arch dependent and, then, could be stabilized all at the same time by the first arch team that is going to stabilize it. Some months ago it was suggested that this packages could have a KEYWORD with a value like ~arch for example that could indicate this situation: http://www.gossamer-threads.com/lists/gentoo/dev/283020 But it was shown that it would be difficult to make it work properly at PM level. Then, I was wondering if we could handle this simply by having: - A new keyword for bugzilla like STABLEREQALL to easily allow arch teams to filter this kind of packages and handle them in this special way - A new key for metadata.xml files to specify there that the package can be handled in that way. What do you think about this? It wouldn't need any change at PM level and, then, it should be easy to do. I would like to see packages with PHP scripts (only) be included with such a proposal. i.e. dev-php/PEAR-* . They are only text files which may only rely on dev-lang/php USE which are simple to detect with repoman failures. Brian -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJU15STXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NkMyRTQ0RUQ5MEUzMjc1OEU3RDU1QzBE MUY3ODFFRkY5RjRBM0I2AAoJENH3ge/59KO2wFEQAI2xAB27C8KhEpChVcteIy4g dKIn4dDJGhBxKPqs7Jz3I9A/G6dFmLd0lanPglXWzGND0N0MRtwEJpMuHMWRtuEB 6HQcBCX78OrTnE5Etiba/MZzaqvUs0mOdEBk8+Ay2UQcldEf1Z69FbJqC5CnGpEX Pj9Pwv2dD34GJxEhCVWslfjlec9tzs8jaV3iy/aS1BC75oektRkn7iVWzuPWneC8 /CihWDBUwsm7REexeZxcIaSzkTJjNdfK8728bPYshSKa/dtTzmgtyenOES4MZ39Y TWmVamR1m9AdCG7i8ZmSmtMXupMZswDfNn7lKjvlmHyGfK45eZKPtl6cFnRHNwTl nfm9ZUe8c+oILNbT279t3pyBTRZNlcMFeV7lFYTgGEkZjz0Zkz0K2nrlQ7jj9cNA jAxbdYvSJozyf2sPD5U+4JGQbUanY8XLkt5IC1akPYOI9wRIv3R9J4h3fO7bFZFj zsgmYj9LYe8ie9/7QDIruV14PhmJzOvxDMTdZKcal2IjaCTDT2tFQIr80UBy3aDN rxASDbi7/vL/gGrKmzwjbm1SM6Fgzt4gMLAQWlErmmiyUHnMYQ79qQlH/aDgGmSU jqdLYahx0KSsHrbgGMdFi6CMFy/0xvM6/X9nr/wZbvCgc3fqsy0JZh9w/xRGEsBt sPiU1Hr2E7Sd2TpDnhft =NiPF -END PGP SIGNATURE-
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
08.11.2013 09:04, Johann Schmitz пишет: On 07.11.2013 21:18, Rich Freeman wrote: Seriously, though, I'd love to see these needs better supported. I think we need to start by defining what the needs actually are (less redundancy, more consistency, etc). Then we figure out how to best address them. It could be individuals donating VMs, or it might be Gentoo buying resources from any number of vendors, or it could be Gentoo going out and looking for donors. I agree with that. It's easier to decide what to do if we know what we need. A solution built by the infra team would be the best solution for the same reasons why it's better to put stuff on the devspace instead of private servers (availabilty; who can fix stuff, logins, etc). But if someone need resources and a box to play with I would happily provide an Xen instance. Just wondering: How is the AT for $minorarch done? Is it possible to run, say, mips on xen/whatever through some emulation layer or is real hardware a requirement for this archs? For the security concerns: I think these boxes should be used for testing only and not for development - every commit must be done from a box fully under the dev's control. Usually it is done via qemu, but as was said - it is damn slow. I use qemu for emulating ARM device for compilation, cause it's faster than compile on device(Raspberry Pi) itself mostly because of I/O. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
Johann Schmitz er...@gentoo.org writes: Is it possible to run, say, mips on xen/whatever through some emulation layer or is real hardware a requirement for this archs? Yes, via qemu. But very slow, nearly unusable even on a powerful mainstream amd64 server.
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
Dear Denis, Denis M. g...@politeia.in writes: Please review this, and if you agree that it'd be a good idea come with any suggestions to make it happen as well as with any other thoughts/sys-specs/instances we should be looking for. Thanks for the offering. Though not a member, AT teams might benefit from such a build farm. What are you suggesting practically, making a policy for everyone to donate VM to Gentoo, or developing a midware to do so? Cheers, Benda
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 12:53 PM, hero...@gentoo.org wrote: Dear Denis, Hi Benda, Denis M. g...@politeia.in writes: Please review this, and if you agree that it'd be a good idea come with any suggestions to make it happen as well as with any other thoughts/sys-specs/instances we should be looking for. Thanks for the offering. Though not a member, AT teams might benefit from such a build farm. Almost every Gentoo dev that does software testings of some sorts could benefit from these build farms (although I'd refrain from using that term ;) ..). What are you suggesting practically, making a policy for everyone to donate VM to Gentoo, or developing a midware to do so? My initial idea was to suggest this here (in the gentoo-dev@ ML) first and see what you guys think about the idea. If it gets accepted by majority, then a policy, rules, etc... should be gathered through your comments here. After that we could make a wiki page (as Ago suggested while we were talking about this in IRC) and spam the gentoo-user ML and see how many good people are there :-). Cheers, Benda Regards, Denis M. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On Thu, Nov 7, 2013 at 7:14 AM, Denis M. g...@politeia.in wrote: Almost every Gentoo dev that does software testings of some sorts could benefit from these build farms (although I'd refrain from using that term ;) ..). Don't let me put a damper on your plans as-is, but I'd be interested if developers who frequently perform these kinds of tasks post about what they're actually doing. Rather than just asking people to give random others ssh access to random boxes, it might make sense to streamline certain tasks. Imagine a tool that takes in a list of atoms and dumps a tarball of build logs in some standard layout. That could be easily distributed (assuming packages were reasonably independent), and tools like tatt might even be adapted. Not a reason to delay what you propose, just another opportunity.
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
Rackspace (where I work) currently has a developer discount program. I think we also host some open source stuff for various projects. Right now you can try to use http://developer.rackspace.com/ but if we want to make this more official I can ask around. Let me know if we want this as a more official thing (rackspace donating compute resources), no guarantees though :D. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 02:48 PM, Matthew Thode wrote: Rackspace (where I work) currently has a developer discount program. I think we also host some open source stuff for various projects. Right now you can try to use http://developer.rackspace.com/ but if we want to make this more official I can ask around. Let me know if we want this as a more official thing (rackspace donating compute resources), no guarantees though :D. To be honest, I would like Gentoo infra to come up with a solution sometime... Last time (a year ago) i asked them about this, they said they have a cluster/big box for this purpose but they just didn't have the time to deploy it properly or something. Not everyone can afford paid solutions when it comes to contributing to free software -- Regards, Markos Chandras
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 12:26 PM, Markos Chandras wrote: On 11/07/2013 02:48 PM, Matthew Thode wrote: Rackspace (where I work) currently has a developer discount program. I think we also host some open source stuff for various projects. Right now you can try to use http://developer.rackspace.com/ but if we want to make this more official I can ask around. Let me know if we want this as a more official thing (rackspace donating compute resources), no guarantees though :D. To be honest, I would like Gentoo infra to come up with a solution sometime... Last time (a year ago) i asked them about this, they said they have a cluster/big box for this purpose but they just didn't have the time to deploy it properly or something. Not everyone can afford paid solutions when it comes to contributing to free software iirc, we give $200 if infra for developer accounts for a couple of months. If a deal is struck it would likely be more and forever or something. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 08:59 PM, Matthew Thode wrote: On 11/07/2013 12:26 PM, Markos Chandras wrote: On 11/07/2013 02:48 PM, Matthew Thode wrote: Rackspace (where I work) currently has a developer discount program. I think we also host some open source stuff for various projects. Right now you can try to use http://developer.rackspace.com/ but if we want to make this more official I can ask around. Let me know if we want this as a more official thing (rackspace donating compute resources), no guarantees though :D. To be honest, I would like Gentoo infra to come up with a solution sometime... Last time (a year ago) i asked them about this, they said they have a cluster/big box for this purpose but they just didn't have the time to deploy it properly or something. Not everyone can afford paid solutions when it comes to contributing to free software iirc, we give $200 if infra for developer accounts for a couple of months. If a deal is struck it would likely be more and forever or something. I've been running my VM for Ago for 13 months now (started on september 2012), where are my $200? ;-) Regards, Denis M. (Phr33d0m) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On Thu, Nov 7, 2013 at 3:08 PM, Denis M. g...@politeia.in wrote: On 11/07/2013 08:59 PM, Matthew Thode wrote: iirc, we give $200 if infra for developer accounts for a couple of months. If a deal is struck it would likely be more and forever or something. I've been running my VM for Ago for 13 months now (started on september 2012), where are my $200? ;-) Can't argue with that. :) Seriously, though, I'd love to see these needs better supported. I think we need to start by defining what the needs actually are (less redundancy, more consistency, etc). Then we figure out how to best address them. It could be individuals donating VMs, or it might be Gentoo buying resources from any number of vendors, or it could be Gentoo going out and looking for donors. I suspect that if we went out with something specific in mind we might be able to find a sponsor - but it is always best to have some idea just what we're going to be using any donations for (this will be our stage3 builder which cranks out a new stage3 every 20 minutes and reports build failures to double as a tinderbox, etc). Rich
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 09:18 PM, Rich Freeman wrote: On Thu, Nov 7, 2013 at 3:08 PM, Denis M. g...@politeia.in wrote: On 11/07/2013 08:59 PM, Matthew Thode wrote: iirc, we give $200 if infra for developer accounts for a couple of months. If a deal is struck it would likely be more and forever or something. I've been running my VM for Ago for 13 months now (started on september 2012), where are my $200? ;-) Can't argue with that. :) Seriously, though, I'd love to see these needs better supported. I think we need to start by defining what the needs actually are (less redundancy, more consistency, etc). Then we figure out how to best address them. It could be individuals donating VMs, or it might be Gentoo buying resources from any number of vendors, or it could be Gentoo going out and looking for donors. I suspect that if we went out with something specific in mind we might be able to find a sponsor - but it is always best to have some idea just what we're going to be using any donations for (this will be our stage3 builder which cranks out a new stage3 every 20 minutes and reports build failures to double as a tinderbox, etc). Rich Currently Diego's tinderbox does something like that AFAIK. Compiles things and (almost?) automatically submits bugs against the packages with the relevant logs, etc... The initial idea behind my suggestion was that the devs would have the enough system resources to address these bugs (and the ones reported from the users, of course). An example here could be the following: finding/confirming a compilation bug for a package with ~10 USE flags could take tatt quite some compilations depending on the USE flag's combinations (this is actually what arch testers do in order to stabilize/keyword a package). Another example would be, as I mentioned in my previous mails to this thread - a new glibc version comes out and (as you know) quite some packages fail to compile against it. Having the resources, it would be possible to track these packages faster instead of relying on random users/testers to report them to bugs.g.o. And a last one would be testing new KDE/GNOME/whatever-meta-with-huge-number-of-packages. As an AT member myself I could only give examples on how using such system of donating/providing instances would be a benefit. For a comprehensive list of the tasks (for consistency as you said), I'd wait for actual devs to enumerate their needs. I doubt this will go as further as Gentoo actually *buying* resources. The reason is obvious - things have been going fine till now, why throw monnies for something as 'unnecessary' (which is why I haven't received a penny for it, hehehe), that's why I came with the donorship-of-instances version. I believe the 'going out looking for donors' part you said is basically what I'm suggesting here, although I believe you meant donors = huge companies providing clusters, and I doubt that'll happen. From my observation, you can get a lot of work done on a simple 2GB-ram-4-cores VirtualBox VM. Not to talk that lots of people nowadays have these resources to spare. That's why getting actual people (and not companies or whatever) to donate their system resources is easier to get/reach. Regards, Denis M. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/11/13 09:20 AM, Rich Freeman wrote: On Thu, Nov 7, 2013 at 7:14 AM, Denis M. g...@politeia.in wrote: Almost every Gentoo dev that does software testings of some sorts could benefit from these build farms (although I'd refrain from using that term ;) ..). Don't let me put a damper on your plans as-is, but I'd be interested if developers who frequently perform these kinds of tasks post about what they're actually doing. Rather than just asking people to give random others ssh access to random boxes, it might make sense to streamline certain tasks. Imagine a tool that takes in a list of atoms and dumps a tarball of build logs in some standard layout. That could be easily distributed (assuming packages were reasonably independent), and tools like tatt might even be adapted. Not a reason to delay what you propose, just another opportunity. I guess nobody wants to try and setup a VM-image-based heterogeneous grid system, huh? :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlJ8AcIACgkQ2ugaI38ACPCqHwEAulNSjBvU4WsLu91zChM8esBf M7FWlAdM++LUsfZ0y/cA/3oZp4+7mjeWbJdUlNxtAGBDYYxD9WfNzpitwX0IFWnN =q61v -END PGP SIGNATURE-
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 03:07 PM, Denis M. wrote: On 11/07/2013 09:18 PM, Rich Freeman wrote: On Thu, Nov 7, 2013 at 3:08 PM, Denis M. g...@politeia.in wrote: On 11/07/2013 08:59 PM, Matthew Thode wrote: iirc, we give $200 if infra for developer accounts for a couple of months. If a deal is struck it would likely be more and forever or something. I've been running my VM for Ago for 13 months now (started on september 2012), where are my $200? ;-) Can't argue with that. :) Seriously, though, I'd love to see these needs better supported. I think we need to start by defining what the needs actually are (less redundancy, more consistency, etc). Then we figure out how to best address them. It could be individuals donating VMs, or it might be Gentoo buying resources from any number of vendors, or it could be Gentoo going out and looking for donors. I suspect that if we went out with something specific in mind we might be able to find a sponsor - but it is always best to have some idea just what we're going to be using any donations for (this will be our stage3 builder which cranks out a new stage3 every 20 minutes and reports build failures to double as a tinderbox, etc). Rich Currently Diego's tinderbox does something like that AFAIK. Compiles things and (almost?) automatically submits bugs against the packages with the relevant logs, etc... The initial idea behind my suggestion was that the devs would have the enough system resources to address these bugs (and the ones reported from the users, of course). An example here could be the following: finding/confirming a compilation bug for a package with ~10 USE flags could take tatt quite some compilations depending on the USE flag's combinations (this is actually what arch testers do in order to stabilize/keyword a package). Another example would be, as I mentioned in my previous mails to this thread - a new glibc version comes out and (as you know) quite some packages fail to compile against it. Having the resources, it would be possible to track these packages faster instead of relying on random users/testers to report them to bugs.g.o. And a last one would be testing new KDE/GNOME/whatever-meta-with-huge-number-of-packages. As an AT member myself I could only give examples on how using such system of donating/providing instances would be a benefit. For a comprehensive list of the tasks (for consistency as you said), I'd wait for actual devs to enumerate their needs. I doubt this will go as further as Gentoo actually *buying* resources. The reason is obvious - things have been going fine till now, why throw monnies for something as 'unnecessary' (which is why I haven't received a penny for it, hehehe), that's why I came with the donorship-of-instances version. I believe the 'going out looking for donors' part you said is basically what I'm suggesting here, although I believe you meant donors = huge companies providing clusters, and I doubt that'll happen. From my observation, you can get a lot of work done on a simple 2GB-ram-4-cores VirtualBox VM. Not to talk that lots of people nowadays have these resources to spare. That's why getting actual people (and not companies or whatever) to donate their system resources is easier to get/reach. Regards, Denis M. I may also have a small openstack cluster I can let people use soonish. Working on a backlog of issues now. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07.11.2013 21:18, Rich Freeman wrote: Seriously, though, I'd love to see these needs better supported. I think we need to start by defining what the needs actually are (less redundancy, more consistency, etc). Then we figure out how to best address them. It could be individuals donating VMs, or it might be Gentoo buying resources from any number of vendors, or it could be Gentoo going out and looking for donors. I agree with that. It's easier to decide what to do if we know what we need. A solution built by the infra team would be the best solution for the same reasons why it's better to put stuff on the devspace instead of private servers (availabilty; who can fix stuff, logins, etc). But if someone need resources and a box to play with I would happily provide an Xen instance. Just wondering: How is the AT for $minorarch done? Is it possible to run, say, mips on xen/whatever through some emulation layer or is real hardware a requirement for this archs? For the security concerns: I think these boxes should be used for testing only and not for development - every commit must be done from a box fully under the dev's control. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSfHDMAAoJEKCEBkJ3xQHt2NgH/RxKb8nQDTnpjmTjkiJs/i04 JC36jxOj/ZMSSmyayssw/lpIHVB0z3V+nypLwDZnoTR5AfqQZ2O63G2OUSQwl0MN SCHYNvrQrqxPeRmQ8SBP8VMiDK6vClgRSSnJaRAKKI+ZzpDVf5BjljRr4YeakV/t iEvVpWeFt+gRDZBdFL2mInkbJ+3QBuPU08PS2p2mdrfZ3/b046eqZBQcmjnIk2/r rfVkaQ69IzS90tvv55AM3jjGIFxa/Fh5eIw7CC/VCyhiqH2egRfTTaCfdFz4VWTs 2IWNuwK3K9hxiCxzsH+IvLtqIvNYVXHdqy/6JfcIfGdlEI7/rdk2/I8VpWaOKy0= =36Sm -END PGP SIGNATURE-
[gentoo-dev] Suggestion: support the Dev team with system resources
Hello gentoo-dev@, Starting with a little intro, I'm currently providing a Gentoo VM to a gentoo dev (Agostino Sarubbo (ago)) for the purpose of testing/stabilizing/keywording packages, which is part of his task as a developer and being part of the AT team. I've been running the VM for him for a couple of months now and AFAIK he's been giving it a great use ;-). The main idea here is to allow Gentoo contributors and members (not necessary) of the Gentoo community, to be able to support the developer team providing their spare system resources, by, for example, running a Virtual Machine (or any sort of xen, kvm, virtualbox, vmware, whatever...) instance where the devs can run tasks they'd normally wouldn't be able to run with their systems, because: * They're doing some other tests at the moment * They're on ~arch and need stable * They're not on the architecture needed for that testing * Their system is not 'powerful' enough * etc... The purpose of doing this is that the developers that have the time and dedication would be able to run a couple of different tests concurrently, on different 'instances' provided by the community. That will greatly, IMHO, improve the team's performance and not only in the AT field. The instances provided wouldn't forcefully need to meet any specific minimum requirements (this would be decided once (and if) this gets accepted), but a dual core system with 512MB ram would be somewhat an acceptable instance for the bigger arches (x86 amd64), and maybe lower specs for the other arches[1]. As an example here, I'm giving Ago a VirtualBox VM with 2GB ram and 4 virtual CPUs. Also, for the contributors there shouldn't be any minimum uptime to meet, they'll run the instances the time they use their systems, and if they leave them idle all day/night that would just be better, although they should be able to specify to the team normally the hours their systems would be usable by the devs. There should be a list of users that are able to share their resources and each dev(s) would be given a certain number of instances depending on their needs and such. I know that you might think that doing this will lower the contributor's desktop experience (as VMs tend to be somewhat heavy while compiling). The usage of the AUTOGROUP kernel scheduler and cgroups tends to make the desktop very much usable under high CPU pressure. Please review this, and if you agree that it'd be a good idea come with any suggestions to make it happen as well as with any other thoughts/sys-specs/instances we should be looking for. If you don't think this is a good idea or that it won't profit the Gentoo dev team, please tell me why. Regards, Denis M. (Phr33d0m) PS: This is a re-send as I firstly sent it without subscribing to the ML. So sorry if you receive it 2 times. [1] I apologize if this statement is wrong, it's based of my 0 knowledge on the other arches and the resources they need. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
Am Donnerstag, 7. November 2013, 00:18:19 schrieb Denis M.: Hello gentoo-dev@, Starting with a little intro, I'm currently providing a Gentoo VM to a gentoo dev (Agostino Sarubbo (ago)) for the purpose of testing/stabilizing/keywording packages, which is part of his task as a developer and being part of the AT team. I've been running the VM for him for a couple of months now and AFAIK he's been giving it a great use ;-). The main idea here is to allow Gentoo contributors and members (not necessary) of the Gentoo community, to be able to support the developer team providing their spare system resources, by, for example, running a Virtual Machine (or any sort of xen, kvm, virtualbox, vmware, whatever...) instance where the devs can run tasks they'd normally wouldn't be able to run with their systems, because: ... I appreciate the idea, but security-wise it's pretty dangerous - given that you as a Gentoo dev are doing sensitive work that may affect many people on a machine not controlled by you yourself nor Gentoo Infra. Call me paranoid, but please no. And in absolutely no case one should commit to the tree from such a machine, even with stuff like agent forwarding. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 12:37 AM, Andreas K. Huettel wrote: Am Donnerstag, 7. November 2013, 00:18:19 schrieb Denis M.: Hello gentoo-dev@, Starting with a little intro, I'm currently providing a Gentoo VM to a gentoo dev (Agostino Sarubbo (ago)) for the purpose of testing/stabilizing/keywording packages, which is part of his task as a developer and being part of the AT team. I've been running the VM for him for a couple of months now and AFAIK he's been giving it a great use ;-). The main idea here is to allow Gentoo contributors and members (not necessary) of the Gentoo community, to be able to support the developer team providing their spare system resources, by, for example, running a Virtual Machine (or any sort of xen, kvm, virtualbox, vmware, whatever...) instance where the devs can run tasks they'd normally wouldn't be able to run with their systems, because: ... I appreciate the idea, but security-wise it's pretty dangerous - given that you as a Gentoo dev are doing sensitive work that may affect many people on a machine not controlled by you yourself nor Gentoo Infra. I completely agree with this, but it's not entirely true. Why? I'll give the example of the AT team: 1. You sync the tree before you start your work (that way you verify the tree is clean). 2. Then you start testing the packages or bugs you're after, which in matter of security is meaningless because testing packages is usually just compiling and running to see if it works as expected. 2.1. Apply random patches to fix if there's an issue. 2.2. goto 2. 3. etc... I see no issue in this in matter of security. Another example would be devs testing packages under development (internal usage in gentoo), for example how new versions of openrc/systemd/glibc/whatever can affect X. I do understand your concern, although I wouldn't call you paranoid as it's just normal to not trust a system that's not completely under your control, but as I said, you don't really... 'care' about it/that. Call me paranoid, but please no. And in absolutely no case one should commit to the tree from such a machine, even with stuff like agent forwarding. Of course! Commiting or any other form of direct communication with the gentoo infra. (either commit to tree or `git push`-ing to any of the other gentoo repos) would be highly discouraged, and I didn't, in any moment, think someone would think of doing that :P. The idea behind this is using the provided instance only and exclusively for testing something you'd normally can't do on your system. Regards, Denis M. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Suggestion to drop pcre from default enabled USE flags in profiles
After reading: https://bugs.gentoo.org/show_bug.cgi?id=419795 I think that would be interesting to try to not get grep build with pcre support by default, specially after reading man grep and seeing that its support is tagged as experimental: -P, --perl-regexp Interpret PATTERN as a Perl regular expression. This is highly experimental and grep -P may warn of unimplemented features. Also, at least of my systems there are only a few installed packages with this USE flag and, then, I am unsure about real advantage of having it enabled by default :-/ What do you think? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion to drop pcre from default enabled USE flags in profiles
On 6/6/12 10:26 AM, Pacho Ramos wrote: After reading: https://bugs.gentoo.org/show_bug.cgi?id=419795 I think that would be interesting to try to not get grep build with pcre support by default, specially after reading man grep and seeing that its support is tagged as experimental: This is more a reason to mask USE=pcre for grep, rather than taking global action, where pcre may have different meaning or status for other packages. Also, at least of my systems there are only a few installed packages with this USE flag and, then, I am unsure about real advantage of having it enabled by default :-/ This is a possible reason for dropping it, but I'm not sure. What exactly uses it and why? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion to drop pcre from default enabled USE flags in profiles
El mié, 06-06-2012 a las 10:37 +0200, Paweł Hajdan, Jr. escribió: On 6/6/12 10:26 AM, Pacho Ramos wrote: After reading: https://bugs.gentoo.org/show_bug.cgi?id=419795 I think that would be interesting to try to not get grep build with pcre support by default, specially after reading man grep and seeing that its support is tagged as experimental: This is more a reason to mask USE=pcre for grep, rather than taking global action, where pcre may have different meaning or status for other packages. I thought about that option at first time, but later I checked grep ChangeLog and saw pcre USE flag was dropped time ago but later readded due user request. Also, at least of my systems there are only a few installed packages with this USE flag and, then, I am unsure about real advantage of having it enabled by default :-/ This is a possible reason for dropping it, but I'm not sure. What exactly uses it and why? Paweł In my laptop, just now, only a few: $ equery hasuse pcre * Searching for USE flag pcre ... [IP-] [ ] app-admin/syslog-ng-3.2.5:0 [IP-] [ ] dev-lang/swig-2.0.4-r1:0 [IP-] [ ] dev-libs/rasqal-0.9.28:0 [IP-] [ ] sys-apps/grep-2.9:0 but running it with -p shows me there are a lot that I don't know if their support deserves to be enabled by default :( signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion to drop pcre from default enabled USE flags in profiles
On Wednesday 06 June 2012 04:26:11 Pacho Ramos wrote: I think that would be interesting to try to not get grep build with pcre support by default, specially after reading man grep and seeing that its support is tagged as experimental: -P, --perl-regexp Interpret PATTERN as a Perl regular expression. This is highly experimental and grep -P may warn of unimplemented features. the experimental aspect doesn't matter. don't use -P and it isn't an issue. personally, i don't care about pcre. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion to drop pcre from default enabled USE flags in profiles
El mié, 06-06-2012 a las 13:23 -0400, Mike Frysinger escribió: On Wednesday 06 June 2012 04:26:11 Pacho Ramos wrote: I think that would be interesting to try to not get grep build with pcre support by default, specially after reading man grep and seeing that its support is tagged as experimental: -P, --perl-regexp Interpret PATTERN as a Perl regular expression. This is highly experimental and grep -P may warn of unimplemented features. the experimental aspect doesn't matter. don't use -P and it isn't an issue. personally, i don't care about pcre. -mike The problem is that grep keeps linked against libpcre and it can cause problems like pointed in referred bug report, and it's really risky as people can have their portage completely broken for example when libpcre is downgraded for some reason. That doesn't sound like a good *default* behavior for me Of course, other option would be to default to -pcre for grep only (by default), but I don't know if we really want every package to have pcre by default... signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion to drop pcre from default enabled USE flags in profiles
On Wednesday 06 June 2012 14:06:47 Pacho Ramos wrote: The problem is that grep keeps linked against libpcre and it can cause problems like pointed in referred bug report, and it's really risky as people can have their portage completely broken for example when libpcre is downgraded for some reason. That doesn't sound like a good *default* behavior for me there are plenty of core tools that can be broken by other packages forcing broken behavior like library downgrades. and FEATURES=preserve-libs would gracefully handle this. off the top of my head, lib dependencies that can bring a system down: - bash links against ncurses readline - sed links against acl - coreutils links against acl/libcap/selinux/gmp - grep links against pcre (with at least USE=acl being a profile default) so highlighting the grep/pcre dep doesn't seem like it accomplishes much -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion to drop pcre from default enabled USE flags in profiles
El mié, 06-06-2012 a las 14:53 -0400, Mike Frysinger escribió: On Wednesday 06 June 2012 14:06:47 Pacho Ramos wrote: The problem is that grep keeps linked against libpcre and it can cause problems like pointed in referred bug report, and it's really risky as people can have their portage completely broken for example when libpcre is downgraded for some reason. That doesn't sound like a good *default* behavior for me there are plenty of core tools that can be broken by other packages forcing broken behavior like library downgrades. I know that, but I am simply trying to get safer values that could help to minimize the risk a bit and, since enabling pcre system wide didn't look (and still don't look) really needed to me, I asked to stop enabling it to prevent this exact risk that looks major enough to me and FEATURES=preserve-libs would gracefully handle this. off the top of my head, lib dependencies that can bring a system down: - bash links against ncurses readline - sed links against acl - coreutils links against acl/libcap/selinux/gmp - grep links against pcre (with at least USE=acl being a profile default) so highlighting the grep/pcre dep doesn't seem like it accomplishes much -mike I am not trying to reach the safest and unbreakable update path that won't ever fail as explained at top ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion for getting rid of udev
On 10/17/2011 01:59 PM, Joost Roeleveld wrote: On Sunday, October 16, 2011 12:33:51 PM Zac Medico wrote: If those LVM volumes require userspace tools to mount, then I think it's perfectly reasonable to expect them to use either an initramfs or a simple linuxrc approach [1] to ensure that /usr is mounted before init starts. [1] http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml If this approach works, would it be an option to add this to the LVM [1] and RAID+LVM [2] pages? You can use a linuxrc instead of an initramfs as long as your root filesystem can be mounted automatically via kernel parameters, and that root filesystem contains the necessary userspace tools (like busybox and lvm) to mount everthing else that's required to be mounted before init starts. [1] http://www.gentoo.org/doc/en/lvm2.xml [2] http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml -- Thanks, Zac
Re: [gentoo-dev] Suggestion for getting rid of udev
On Sunday, October 16, 2011 12:33:51 PM Zac Medico wrote: On 10/16/2011 06:07 AM, Rich Freeman wrote: On Sat, Oct 15, 2011 at 6:07 PM, Zac Medico zmed...@gentoo.org wrote: I don't think it's a good idea for Gentoo to encourage users to have /usr on a separate partition. We should probably remove the separate /usr partition from Code Listing 2.1: Filesystem usage example in our handbook: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=4#d oc_chap2_pre1 Well, if we want to do that then we should also update: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml Of course - that is an initramfs-less configuration, and such a thing would be nearly impossible to do with /usr on root unless you basically don't put anything of value on the LVM volumes in the first place. You could put everything but /boot on LVM and then use an initramfs. Or, you need to cover mounting /usr, /var, etc from the initramfs. And I don't think it is a good idea to NOT have a supported RAID/LVM configuration. That is hardly an edge case... If those LVM volumes require userspace tools to mount, then I think it's perfectly reasonable to expect them to use either an initramfs or a simple linuxrc approach [1] to ensure that /usr is mounted before init starts. [1] http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.x ml If this approach works, would it be an option to add this to the LVM [1] and RAID+LVM [2] pages? [1] http://www.gentoo.org/doc/en/lvm2.xml [2] http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml -- Joost
Re: [gentoo-dev] Suggestion for getting rid of udev
On Sat, Oct 15, 2011 at 6:07 PM, Zac Medico zmed...@gentoo.org wrote: I don't think it's a good idea for Gentoo to encourage users to have /usr on a separate partition. We should probably remove the separate /usr partition from Code Listing 2.1: Filesystem usage example in our handbook: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=4#doc_chap2_pre1 Well, if we want to do that then we should also update: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml Of course - that is an initramfs-less configuration, and such a thing would be nearly impossible to do with /usr on root unless you basically don't put anything of value on the LVM volumes in the first place. You could put everything but /boot on LVM and then use an initramfs. Or, you need to cover mounting /usr, /var, etc from the initramfs. And I don't think it is a good idea to NOT have a supported RAID/LVM configuration. That is hardly an edge case... Rich
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 12:40:23AM -0400, Walter Dnes wrote: Hi all Recently, there was a firestorm on the gentoo-user list over the idea that udev would eventually require /usr to be on the same physical parition as /, or else use initramfs, which is its own can of worms. I'm not a programmer, let alone a developer. Rather than merely ranting, I went and searched for an alternative. udev is not the problem here, please do not shoot the messenger. And read the documentation for what is going on before making statements like we have to replace udev, otherwise it comes across very foolish. Forking udev is probably not an option. The udev lead developer is a Redhat employee, and his direction seems to be to drag everybody in Redhat's direction. Our community doesn't have Redhat's billions. Since when was udev written by RedHat's billions? You do know the history of it, right? The other option is to drop udev entirely. As an example, I suggest looking at Alpine Linux http://alpinelinux.org/ It's a lightweight server-oriented distro. It uses busybox's mdev instead of udev, and some other mdev substitutes in place of standard packages. Haha, mdev, yeah right. Have fun with that... greg k-h
Re: [gentoo-dev] Suggestion for getting rid of udev
On 10/16/2011 06:07 AM, Rich Freeman wrote: On Sat, Oct 15, 2011 at 6:07 PM, Zac Medico zmed...@gentoo.org wrote: I don't think it's a good idea for Gentoo to encourage users to have /usr on a separate partition. We should probably remove the separate /usr partition from Code Listing 2.1: Filesystem usage example in our handbook: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=4#doc_chap2_pre1 Well, if we want to do that then we should also update: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml Of course - that is an initramfs-less configuration, and such a thing would be nearly impossible to do with /usr on root unless you basically don't put anything of value on the LVM volumes in the first place. You could put everything but /boot on LVM and then use an initramfs. Or, you need to cover mounting /usr, /var, etc from the initramfs. And I don't think it is a good idea to NOT have a supported RAID/LVM configuration. That is hardly an edge case... If those LVM volumes require userspace tools to mount, then I think it's perfectly reasonable to expect them to use either an initramfs or a simple linuxrc approach [1] to ensure that /usr is mounted before init starts. [1] http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml -- Thanks, Zac
Re: [gentoo-dev] Suggestion for getting rid of udev
On Sat, 15 Oct 2011 00:06:03 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. Eventually, that hits Mac or Windows-like levels of dictating 1 or 2 sets of choices and nothing else. If I wanted Mac or Windows, I'd be running Mac or Windows. If the developers don't deliberately make my system break if /usr and /var aren't physically on / (and no initramfs), I'm willing to do a bit of extra work to configure things my way. Speaking of tight integration, what happens if Redhat's employees make udev depend on systemd? And what happens, if GNU folks make GNU userland depend on Hurd? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 12 Oct 2011 18:49:19 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? What's the 'deep integration' here? AFAICS the main point here is that you want to make udev capable of guessing all your filesystem structure, and maybe even mounting it. Yeah, sounds really KISS. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
Sorry for being completely OT now, will be the only mail on this from my side... On Thursday, 13. October 2011 18:05:47 Ciaran McCreesh wrote: On Thu, 13 Oct 2011 11:14:31 -0400 Olivier Crête tes...@gentoo.org wrote: On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote: On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. The problem with a platform that just works is that when it doesn't work, no-one knows how to fix it. That's what's happened here: the deep integration doesn't work in the common case that /usr is on its own filesystem, but because of all the excessive coupling you're unable to fix it and so are trying to pass the blame elsewhere. The first step in fixing it is to decouple all of the horrible mess that has been making its way into the base system over the past couple of years. in what way will exherbo deal wih this mess? Are there any plans? Feel free to mail me privately and/or answer this on the user-ML, I think some of us are quite interested. Thanks, Michael
Re: [gentoo-dev] Suggestion for getting rid of udev
On 15.10.2011 10:42, Michael Schreckenbauer wrote: in what way will exherbo deal wih this mess? Are there any plans? We don't support /usr on a separate partition. People can, of course, do that and I'll point them to dracut for creating an initramfs. Or they can do whatever works for them. People using Exherbo are expected to be able to deal with such stuff. Best regards, Wulf signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger w...@mailstation.de wrote: On 15.10.2011 10:42, Michael Schreckenbauer wrote: in what way will exherbo deal wih this mess? Are there any plans? We don't support /usr on a separate partition. People can, of course, do that and I'll point them to dracut for creating an initramfs. Or they can do whatever works for them. People using Exherbo are expected to be able to deal with such stuff. And I believe exherbo recommends systemd as init system. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Suggestion for getting rid of udev
On Sat, Oct 15, 2011 at 2:13 AM, Canek Peláez Valdés can...@gmail.com wrote: On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger w...@mailstation.de wrote: On 15.10.2011 10:42, Michael Schreckenbauer wrote: in what way will exherbo deal wih this mess? Are there any plans? We don't support /usr on a separate partition. People can, of course, do that and I'll point them to dracut for creating an initramfs. Or they can do whatever works for them. People using Exherbo are expected to be able to deal with such stuff. And I believe exherbo recommends systemd as init system. Yes, they do: http://exherbo.org/docs/install-guide.html o Install an init system There’s no init system in our stages. This allows you to choose whatever init system (or none) you’d like to use: - sys-apps/systemd (recommended) - modern, fast init system. Needs kernel =2.6.36-rc1. - sys-apps/baselayout - Gentoo’s old, crufty Baselayout-1. - sys-apps/upstart - Ubuntu’s init system. We don’t generally supply init scripts for this. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Suggestion for getting rid of udev
On Saturday 15 October 2011 03:29:54 Michał Górny wrote: On Sat, 15 Oct 2011 00:06:03 -0400 Walter Dnes wrote: On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. Eventually, that hits Mac or Windows-like levels of dictating 1 or 2 sets of choices and nothing else. If I wanted Mac or Windows, I'd be running Mac or Windows. If the developers don't deliberately make my system break if /usr and /var aren't physically on / (and no initramfs), I'm willing to do a bit of extra work to configure things my way. Speaking of tight integration, what happens if Redhat's employees make udev depend on systemd? And what happens, if GNU folks make GNU userland depend on Hurd? with gnulib in place, they (directly) won't -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion for getting rid of udev
On Saturday, October 15, 2011 09:29:54 AM Michał Górny wrote: On Sat, 15 Oct 2011 00:06:03 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. Eventually, that hits Mac or Windows-like levels of dictating 1 or 2 sets of choices and nothing else. If I wanted Mac or Windows, I'd be running Mac or Windows. If the developers don't deliberately make my system break if /usr and /var aren't physically on / (and no initramfs), I'm willing to do a bit of extra work to configure things my way. Speaking of tight integration, what happens if Redhat's employees make udev depend on systemd? And what happens, if GNU folks make GNU userland depend on Hurd? They'll finally get to version 1.x and Hurd can be used instead of the Linux kernel if someone wants to? :) -- Joost
Re: [gentoo-dev] Suggestion for getting rid of udev
On 10/15/2011 01:57 AM, Wulf C. Krueger wrote: On 15.10.2011 10:42, Michael Schreckenbauer wrote: in what way will exherbo deal wih this mess? Are there any plans? We don't support /usr on a separate partition. People can, of course, do that and I'll point them to dracut for creating an initramfs. Or they can do whatever works for them. People using Exherbo are expected to be able to deal with such stuff. I don't think it's a good idea for Gentoo to encourage users to have /usr on a separate partition. We should probably remove the separate /usr partition from Code Listing 2.1: Filesystem usage example in our handbook: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=4#doc_chap2_pre1 -- Thanks, Zac
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thu, Oct 13, 2011 at 10:12:52AM -0400, Thomas Kahle wrote https://www.xkcd.com/963/ Xorg --configure -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Suggestion for getting rid of udev
On Fri, Oct 14, 2011 at 8:37 PM, Walter Dnes waltd...@waltdnes.org wrote: On Thu, Oct 13, 2011 at 10:12:52AM -0400, Thomas Kahle wrote https://www.xkcd.com/963/ Xorg --configure Funny, I haven't used a /etc/X11/Xorg.conf in years: negra ~ # ll /etc/X11/ total 20 drwxr-xr-x 2 root root 4096 Sep 12 17:49 app-defaults -rwxr-xr-x 1 root root 1301 Aug 31 15:54 chooser.sh drwxr-xr-x 2 root root 4096 Sep 30 09:36 Sessions -rwxr-xr-x 1 root root 923 Aug 31 15:54 startDM.sh drwxr-xr-x 3 root root 4096 Aug 31 15:54 xinit negra ~ # It's great; it just works. And it is thanks (in great part) to udev. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. Eventually, that hits Mac or Windows-like levels of dictating 1 or 2 sets of choices and nothing else. If I wanted Mac or Windows, I'd be running Mac or Windows. If the developers don't deliberately make my system break if /usr and /var aren't physically on / (and no initramfs), I'm willing to do a bit of extra work to configure things my way. Speaking of tight integration, what happens if Redhat's employees make udev depend on systemd? -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote: On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 2011-10-12 at 00:40 -0400, Walter Dnes wrote: Hi all Recently, there was a firestorm on the gentoo-user list over the idea that udev would eventually require /usr to be on the same physical parition as /, or else use initramfs, which is its own can of worms. I'm not a programmer, let alone a developer. Rather than merely ranting, I went and searched for an alternative. You completely misunderstand what Kay wants, what we are saying that is that you need to mount /usr at the same time as you mount /, which you can still do in your initramfs, etc. That said, we, the GNOME upstream, think that having a separate /usr is a completely stupid idea. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion for getting rid of udev
2011/10/13 Olivier Crête tes...@gentoo.org: We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. I'd also look at it another way. It is a lot easier to take a well-integrated platform and chop out the parts that you don't need, than to take a million pieces and build yourself an integrated platform. I think the key is to still define boundaries between the layers and interfaces such that you still can chop out parts. I think that there is a danger that we may get to a point where that becomes increasingly difficult. If KDE and Gnome were to come out with separate incompatible implementations of SysVInit, XDM, X11, and automounting then having both on the same system would no longer be a matter of just picking a session in the XDM interface. However, the vertical integration right now isn't that bad. We can deploy udev/dbus/etc and people who don't need it can just remove it without much fuss. Rich
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thursday 13 October 2011 11:17:07 Olivier Crête wrote: That said, we, the GNOME upstream, think that having a separate /usr is a completely stupid idea. considering GNOME's track record wrt what they think is a good idea in the UI land, i'm not sure this statement is terribly compelling -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion for getting rid of udev
On 13 October 2011 20:58, Rich Freeman ri...@gentoo.org wrote: 2011/10/13 Olivier Crête tes...@gentoo.org: We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. I'd also look at it another way. It is a lot easier to take a well-integrated platform and chop out the parts that you don't need, than to take a million pieces and build yourself an integrated platform. While it has been the way just about all platform development on Linux has taken place, what this mode of thinking ignores is that gratuitously supporting as many corner cases as you can means that you need to support a combinatorial explosion of pieces, which so far has only managed to keep our stack fragmented and an enormous pita to work with. I'm not saying we should narrow our focus too much, but every decision to support weird ways of doing things has a cost, and if you're going to support it, you (as an upstream developer) are spending time that could possibly have been spent making the whole system better. (that's to set some perspective on why things are heading the way they are, and discussing whether this is sensible or not probably is going to spin offtopic for gentoo-dev really quickly) While I've seen a lot of whining about this whole issue, I certainly haven't been seen any effort to actually solve the problem within the existing framework. For example, if someone cares enough, why not write a wrapper script to track down the programs and libraries at runtime that actually do use /usr so it's easier to say these packages install rules that need / and /usr on the same partition. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: While I've seen a lot of whining about this whole issue, I certainly haven't been seen any effort to actually solve the problem within the existing framework. For example, if someone cares enough, why not write a wrapper script to track down the programs and libraries at runtime that actually do use /usr so it's easier to say these packages install rules that need / and /usr on the same partition. (1) udev has provided a workaround of sorts for this already: udevadm trigger --type=failed. this is the udev-postmount init.d script. (2) it's fairly trivial to locate most (all?) the failing rules with a single grep: grep /usr -R /lib/udev/rules.d/. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thu, 13 Oct 2011 11:14:31 -0400 Olivier Crête tes...@gentoo.org wrote: On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote: On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. The problem with a platform that just works is that when it doesn't work, no-one knows how to fix it. That's what's happened here: the deep integration doesn't work in the common case that /usr is on its own filesystem, but because of all the excessive coupling you're unable to fix it and so are trying to pass the blame elsewhere. The first step in fixing it is to decouple all of the horrible mess that has been making its way into the base system over the past couple of years. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On 10/13/2011 08:02 PM, Mike Frysinger wrote: On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: While I've seen a lot of whining about this whole issue, I certainly haven't been seen any effort to actually solve the problem within the existing framework. For example, if someone cares enough, why not write a wrapper script to track down the programs and libraries at runtime that actually do use /usr so it's easier to say these packages install rules that need / and /usr on the same partition. (1) udev has provided a workaround of sorts for this already: udevadm trigger --type=failed. this is the udev-postmount init.d script. (2) it's fairly trivial to locate most (all?) the failing rules with a single grep: grep /usr -R /lib/udev/rules.d/. nitpicking for (2): also /var, since that's used by alsa's udev rules (alsactl stores info there to restore mixers for eg)
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger vap...@gentoo.org wrote: On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: While I've seen a lot of whining about this whole issue, I certainly haven't been seen any effort to actually solve the problem within the existing framework. For example, if someone cares enough, why not write a wrapper script to track down the programs and libraries at runtime that actually do use /usr so it's easier to say these packages install rules that need / and /usr on the same partition. (1) udev has provided a workaround of sorts for this already: udevadm trigger --type=failed. this is the udev-postmount init.d script. (2) it's fairly trivial to locate most (all?) the failing rules with a single grep: grep /usr -R /lib/udev/rules.d/. If this comment is true (haven't looked at the code): https://bugs.gentoo.org/show_bug.cgi?id=375263#c23 that trigger has been removed from udev. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thu, Oct 13, 2011 at 11:55 AM, Canek Peláez Valdés can...@gmail.com wrote: On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger vap...@gentoo.org wrote: On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: While I've seen a lot of whining about this whole issue, I certainly haven't been seen any effort to actually solve the problem within the existing framework. For example, if someone cares enough, why not write a wrapper script to track down the programs and libraries at runtime that actually do use /usr so it's easier to say these packages install rules that need / and /usr on the same partition. (1) udev has provided a workaround of sorts for this already: udevadm trigger --type=failed. this is the udev-postmount init.d script. (2) it's fairly trivial to locate most (all?) the failing rules with a single grep: grep /usr -R /lib/udev/rules.d/. If this comment is true (haven't looked at the code): https://bugs.gentoo.org/show_bug.cgi?id=375263#c23 that trigger has been removed from udev. Answering myselef; it is gone: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=289a1821a4a7636ce42a6c7adc3a9bb49421a5ea commit 289a1821a4a7636ce42a6c7adc3a9bb49421a5ea Author: Kay Sievers kay.siev...@vrfy.org Date: Thu Oct 6 00:45:06 2011 +0200 remove 'udevadm trigger --type=failed' and SYSFS, ID, BUS keys Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thursday 13 October 2011 14:55:45 Canek Peláez Valdés wrote: On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger wrote: On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: While I've seen a lot of whining about this whole issue, I certainly haven't been seen any effort to actually solve the problem within the existing framework. For example, if someone cares enough, why not write a wrapper script to track down the programs and libraries at runtime that actually do use /usr so it's easier to say these packages install rules that need / and /usr on the same partition. (1) udev has provided a workaround of sorts for this already: udevadm trigger --type=failed. this is the udev-postmount init.d script. (2) it's fairly trivial to locate most (all?) the failing rules with a single grep: grep /usr -R /lib/udev/rules.d/. If this comment is true (haven't looked at the code): https://bugs.gentoo.org/show_bug.cgi?id=375263#c23 that trigger has been removed from udev. ... which is what spurred this entire debate in the first place -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 12 Oct 2011 00:40:23 -0400 Walter Dnes waltd...@waltdnes.org wrote: The other option is to drop udev entirely. As an example, I suggest looking at Alpine Linux http://alpinelinux.org/ It's a lightweight server-oriented distro. It uses busybox's mdev instead of udev, and some other mdev substitutes in place of standard packages. It uses openrc. Furthermore, previous versions of Alpine were based on Gentoo as per http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package so there should be no problem with us borrowing back from Alpine. Goodbye desktop users then. We recently dropped HAL. Now all the magic that was done by HAL (and required udev anyway) is done through udev directly. Dropping udev = dropping it all. This means that no *kit would work anymore, xorg will require explicit configuration, bluez may not work anymore as well. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/12/11 05:40, Walter Dnes wrote: Hi all The other option is to drop udev entirely. As an example, I suggest looking at Alpine Linux http://alpinelinux.org/ It's a lightweight server-oriented distro. It uses busybox's mdev instead of udev, and some other mdev substitutes in place of standard packages. It uses openrc. Furthermore, previous versions of Alpine were based on Gentoo as per http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package so there should be no problem with us borrowing back from Alpine. This is a joke right? All the desktop infrastructure depends on that. Are you suggesting to make Gentoo an embedded/server only distro? - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOlTzUAAoJEPqDWhW0r/LC2rAQAI9+GgYyUZqOPcL8dXa/oDJP 8zAn1w6aJfYW1MJOLlFxx48pYC4G64xencGKUGMyCKdwNGHxEYIAnLIB1fjEIwKz c5gFWjgZyOG1etDJblYtHUEdUDzqVz1EpFmyt/ASxJRsaCOTFv0NyG26tw4cumBT Gpkf/qSwENnSNo+HlMdjlqUzioiSa9afZe/4IkZRKH8NL3UOXEd8Ud605L5YDJoC uErGRamsdRP4XuNU9oB230QVHy2/7vsxZhtDJ3d22MHECF9rpdPfgmZ2zAmUe3ut /NPau8xZG/1udf6REcIZHcg8ERXMl5hO38GuYoyO8/gtxcLLcFaDVMzTzLdaoWg/ H6rB9HhbhZYy9049sPtA2VP+jfCCdriLWpi6G1/XyotgK2e0zgGUIATPskf+Ge5N Nb20Mr2fEbqTgd5SdcPDM4dq0y8at1u8WaAJDfvvy8mvEwwX42GZJK2wsMdY0x/k G85zKQm7pZNnk0V17czUcnkbO+D8Ormw/wImMLrA9KidmC2FbHgPj4qOYAR6Dsso 0i6gvgCai+y0cymTnSYM99xo4KAU/ZKcqGsNtbUKaJ1IwR3tPgGLwHb70NPZF3e5 ssxtG4Su4wo2WGfMfNcPgjTA9hbYW2JGM2s4TH9+V7BVv+wW9b7osyiplJ3f0X7l Kq7yoCCF499m/BMoTgot =cicu -END PGP SIGNATURE-
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 05:32:05AM +, Nathan Phillip Brink wrote You can already try out what using mdev instead of udev is like in Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use, remerge busybox. You must be sure to be using busybox-1.92.2 or later for bug #83301. Did you mean busybox-1.19.2? That's the latest ebuild in /usr/portage, and it's still ~amd64 (~everything for that matter). # rc-update add mdev sysinit # rc-update del udev sysinit But be 'ware that this isn't guaranteed to provide a successful boot ;-). Thanks for the idea. I have a spare box kicking around that I can try it on. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Suggestion for getting rid of udev
Goodbye desktop users then. We recently dropped HAL. Now all the magic that was done by HAL (and required udev anyway) is done through udev directly. My system worked just fine before HAL was introduced, thank you. I always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask and my system continued to work just fine, thank you. Given the great HAL fiasco, the fact that HAL has been incorporated into udev is yet one more reason for dropping udev G. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Suggestion for getting rid of udev
On Tue, Oct 11, 2011 at 10:05:15PM -0700, Zac Medico wrote Are you aware of the simple linuxrc approach that I suggested here? http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml Thanks for the pointer. I've got a spare box kicking around that I'll try this on. I really do want it to work. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 12:40 AM, Walter Dnes waltd...@waltdnes.org wrote: Forking udev is probably not an option. The udev lead developer is a Redhat employee, and his direction seems to be to drag everybody in Redhat's direction. Our community doesn't have Redhat's billions. We should note that RedHat is already spending their billions to make dracut smarter, and if initramfs is good enough for RHEL then it should be good enough for us if somebody just has to have /usr on a separate device and needs some of the fancier udev rules to work on boot. For those who don't need dracut there was already a stated desire to provide a simplified initramfs. And, for less complex setups, you don't need it at all. My concern with something like dropping udev is that it would make us different from every other desktop distro out there. I'm not aware of any distro packaging Gnome/KDE without udev. Not having Redhat's billions to me is a good reason to try to do things the same way that Redhat does them - so that we're not re-inventing the wheel. Gentoo is still a fairly meta distro and if users want to remove udev they probably can do it without a great deal of hassle if they don't want hot more hotplugish experience and don't use the big desktop environments. It just doesn't make sense to make that a default. In the same way I don't mind a list of CFLAGS that spans 3 lines but I'd never advocate putting that into the default make.conf. Rich
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 6:09 AM, Walter Dnes waltd...@waltdnes.org wrote:
Goodbye desktop users then.
We recently dropped HAL. Now all the magic that was done by HAL (and
required udev anyway) is done through udev directly.
My system worked just fine before HAL was introduced, thank you. I
always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask
and my system continued to work just fine, thank you.
This is not about *your* system, it's about the general Gentoo
community systems. And in most cases, the functionality that mdev
provides is not even a fraction of what udev can do, like it or not.
I have a pair of bluetooth headphones; I turn them up and set them to
pair with something, and gnome-shell in GNOME 3 right away asks me if
it's OK to pair with them. I say yes, and the headphones are
immediately available in the desktop; thanks to PulseAudio, I can
transfer all my apps (or only some of them) to the headphones, without
even needing to pause the streams.
All of this without a single modification to a config file. It just
works. And that is thanks to udev (among several other pieces of the
stack).
mdev is designed for embedded systems (like busybox). By design it
cannot handle of the cases that udev handles, and so it is not suited
for a general purpose distribution like Gentoo. If you wan to try to
use it, that's your right of course. But don't ask the Gentoo devs to
do the work for you; do it yourself. And be aware that anyway the devs
will choose to stick with udev (like many have already said), because
they have to think about the general case, not an arbitrary particular
case.
Just the .02 ${CURRENCY} from an old Gentoo user happy with systemd,
dracut, udev, dbus, GNOME 3, and other really cool new technologies.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 12 Oct 2011 09:09:49 -0400 Walter Dnes waltd...@waltdnes.org wrote: Goodbye desktop users then. We recently dropped HAL. Now all the magic that was done by HAL (and required udev anyway) is done through udev directly. My system worked just fine before HAL was introduced, thank you. I always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask and my system continued to work just fine, thank you. Given the great HAL fiasco, the fact that HAL has been incorporated into udev is yet one more reason for dropping udev G. Thanks for your insight on the topic. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 6:39 PM, Walter Dnes waltd...@waltdnes.org wrote: Goodbye desktop users then. We recently dropped HAL. Now all the magic that was done by HAL (and required udev anyway) is done through udev directly. My system worked just fine before HAL was introduced, thank you. I always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask and my system continued to work just fine, thank you. Given the great HAL fiasco, the fact that HAL has been incorporated into udev is yet one more reason for dropping udev G. Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. This thread is a waste of time. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 1:49 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? So, Gentoo is about choice and empowering the user, so I think that if somebody wants to offer patches that allow mdev to work better without adversely affecting udev use then I'd encourage devs to accept those patches. However, if Gentoo aims to make Gnome/KDE difficult to deploy with the default configuration we'll be shooting ourselves in the feet. I think a lot more people run KDE/Gnome on Gentoo than run Gentoo with /usr not on root but who are unwilling to run an initramfs. Rich
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wednesday 12 October 2011 09:26:12 Rich Freeman wrote: On Wed, Oct 12, 2011 at 12:40 AM, Walter Dnes wrote: Forking udev is probably not an option. The udev lead developer is a Redhat employee, and his direction seems to be to drag everybody in Redhat's direction. Our community doesn't have Redhat's billions. We should note that RedHat is already spending their billions to make dracut smarter, and if initramfs is good enough for RHEL then it should be good enough for us if somebody just has to have /usr on a separate device and needs some of the fancier udev rules to work on boot. For those who don't need dracut there was already a stated desire to provide a simplified initramfs. And, for less complex setups, you don't need it at all. i don't think this logic is that great. RHEL/Fedora do a lot of things that they consider desirable but which are simply their opinion on the topic. for a while there, they pretty much forced LVM down everyone's throat during the install. it's been a while since i last installed/maintained those distros (thankfully), but their initramfs setups were always way more flaky than they should have been and fairly difficult to recover from. the firstboot idea is another great example of things not fully thought through ahead of time. systemd is a good choice for some, but its desire to be Linux-specific and require recent kernels is a limitation. if you want to use initramfs on your system, you certainly can. if you want to do lvm/whatever rootfs, then feel free. if you want to run systemd, np. you want to add bloat with firstboot, by all means. but a Gentoo system will not require any of these things (unless you choose to customize your own system in such a way) regardless of how much money other distros throw at their own ideas. note: i'm not advocating dropping udev by default as i think it's completely unrealistic, and unlike the other projects mentioned, has been widely adopted across pretty much all distros. it also doesn't really address the *underlying* problem: package rules that require /usr to be mounted. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 09:09:24AM -0400, Walter Dnes wrote: On Wed, Oct 12, 2011 at 05:32:05AM +, Nathan Phillip Brink wrote You can already try out what using mdev instead of udev is like in Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use, remerge busybox. You must be sure to be using busybox-1.92.2 or later for bug #83301. Did you mean busybox-1.19.2? That's the latest ebuild in /usr/portage, and it's still ~amd64 (~everything for that matter). Yes, Oops. -- binki Look out for missing or extraneous apostrophes! pgpKZ0WR9QjLJ.pgp Description: PGP signature
[gentoo-dev] Suggestion for getting rid of udev
Hi all Recently, there was a firestorm on the gentoo-user list over the idea that udev would eventually require /usr to be on the same physical parition as /, or else use initramfs, which is its own can of worms. I'm not a programmer, let alone a developer. Rather than merely ranting, I went and searched for an alternative. Forking udev is probably not an option. The udev lead developer is a Redhat employee, and his direction seems to be to drag everybody in Redhat's direction. Our community doesn't have Redhat's billions. The other option is to drop udev entirely. As an example, I suggest looking at Alpine Linux http://alpinelinux.org/ It's a lightweight server-oriented distro. It uses busybox's mdev instead of udev, and some other mdev substitutes in place of standard packages. It uses openrc. Furthermore, previous versions of Alpine were based on Gentoo as per http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package so there should be no problem with us borrowing back from Alpine. The only reason Alpine isn't usuable for regular users right now is that it's built with uclibc, which will break closed-source binary blobs (e.g. Flash and Acrobat and many video card drivers). I'm not a developer or programmer, so correct me if I'm wrong, but it shouldn't be difficult to replace uclibc with the standard library, and build away. Another option is to take the current Gentoo setup, drop udev and use mdev in the same manner as Alpine uses it. In case anyone asks, auto mounting should still be possible. Attached is an excerpt from /var/log/messages from a basic Alpine install. The kernel messages were generated when I inserted a USB key into a usb jack. -- Walter Dnes waltd...@waltdnes.org Oct 9 13:46:00 e521 kern.info kernel: [10714.105621] usb 2-8: new high speed USB device using ehci_hcd and address 4 Oct 9 13:46:00 e521 kern.info kernel: [10714.241353] usb 2-8: New USB device found, idVendor=13fe, idProduct=1e00 Oct 9 13:46:00 e521 kern.info kernel: [10714.241357] usb 2-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 9 13:46:00 e521 kern.info kernel: [10714.241360] usb 2-8: Product: Patriot Memory Oct 9 13:46:00 e521 kern.info kernel: [10714.241362] usb 2-8: Manufacturer: Oct 9 13:46:00 e521 kern.info kernel: [10714.241364] usb 2-8: SerialNumber: 078215A302CF Oct 9 13:46:00 e521 kern.info kernel: [10714.244241] scsi4 : usb-storage 2-8:1.0 Oct 9 13:46:01 e521 kern.notice kernel: [10715.279753] scsi 4:0:0:0: Direct-Access Patriot Memory PMAP PQ: 0 ANSI: 0 CCS Oct 9 13:46:02 e521 kern.notice kernel: [10715.930991] sd 4:0:0:0: [sdb] 31326208 512-byte logical blocks: (16.0 GB/14.9 GiB) Oct 9 13:46:02 e521 kern.notice kernel: [10715.931980] sd 4:0:0:0: [sdb] Write Protect is off Oct 9 13:46:02 e521 kern.debug kernel: [10715.931983] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00 Oct 9 13:46:02 e521 kern.err kernel: [10715.931986] sd 4:0:0:0: [sdb] Assuming drive cache: write through Oct 9 13:46:02 e521 kern.err kernel: [10715.935986] sd 4:0:0:0: [sdb] Assuming drive cache: write through Oct 9 13:46:02 e521 kern.info kernel: [10715.981381] sdb: sdb1 Oct 9 13:46:02 e521 kern.err kernel: [10715.986028] sd 4:0:0:0: [sdb] Assuming drive cache: write through Oct 9 13:46:02 e521 kern.notice kernel: [10715.986035] sd 4:0:0:0: [sdb] Attached SCSI removable disk
Re: [gentoo-dev] Suggestion for getting rid of udev
On 10/11/2011 09:40 PM, Walter Dnes wrote: Hi all Recently, there was a firestorm on the gentoo-user list over the idea that udev would eventually require /usr to be on the same physical parition as /, or else use initramfs, which is its own can of worms. I'm not a programmer, let alone a developer. Rather than merely ranting, I went and searched for an alternative. Are you aware of the simple linuxrc approach that I suggested here? http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml -- Thanks, Zac
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 12:40:23AM -0400, Walter Dnes wrote: Hi all Recently, there was a firestorm on the gentoo-user list over the idea that udev would eventually require /usr to be on the same physical parition as /, or else use initramfs, which is its own can of worms. I'm not a programmer, let alone a developer. Rather than merely ranting, I went and searched for an alternative. ... Another option is to take the current Gentoo setup, drop udev and use mdev in the same manner as Alpine uses it. In case anyone asks, auto mounting should still be possible. Attached is an excerpt from /var/log/messages from a basic Alpine install. The kernel messages were generated when I inserted a USB key into a usb jack. Seeing from the prior conversations here (sorry for lack of citation) and http://lists.busybox.net/pipermail/busybox/2011-September/076710.html , I suspect that the root problem isn't with udev itself but with the udev rules. The magic which makes automatic userspace configuration possible is in the udev rules and makes udev appear to be the problem. For example, if you switch to mdev currently, you will notice that X11's device autodetection doesn't work so well. (At least for me, X11's autodetection magically works for detecting input devices with udev but not with mdev). It is concievable that you could develop a parallel database of mdev-compatible rules and even let packages install rules specific to themselves (with modification to mdev http://lists.busybox.net/pipermail/busybox/2011-September/07.html ). With these sorts of things, you might figure out a way to make X11's device autoconfiguration work or perform other device initialization tasks. But at the same time, you have a good chance of accidentally introducing a reliance on libraries/programs installed to /usr. This latter problem is the issue, deciding how much software should have --prefix=/ versus the normal --prefix=/usr. You can already try out what using mdev instead of udev is like in Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use, remerge busybox. You must be sure to be using busybox-1.92.2 or later for bug #83301. # rc-update add mdev sysinit # rc-update del udev sysinit But be 'ware that this isn't guaranteed to provide a successful boot ;-). Oct 9 13:46:00 e521 kern.info kernel: [10714.105621] usb 2-8: new high speed USB device using ehci_hcd and address 4 Oct 9 13:46:00 e521 kern.info kernel: [10714.241353] usb 2-8: New USB device found, idVendor=13fe, idProduct=1e00 Oct 9 13:46:00 e521 kern.info kernel: [10714.241357] usb 2-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 9 13:46:00 e521 kern.info kernel: [10714.241360] usb 2-8: Product: Patriot Memory Oct 9 13:46:00 e521 kern.info kernel: [10714.241362] usb 2-8: Manufacturer: Oct 9 13:46:00 e521 kern.info kernel: [10714.241364] usb 2-8: SerialNumber: 078215A302CF Oct 9 13:46:00 e521 kern.info kernel: [10714.244241] scsi4 : usb-storage 2-8:1.0 Oct 9 13:46:01 e521 kern.notice kernel: [10715.279753] scsi 4:0:0:0: Direct-Access Patriot Memory PMAP PQ: 0 ANSI: 0 CCS Oct 9 13:46:02 e521 kern.notice kernel: [10715.930991] sd 4:0:0:0: [sdb] 31326208 512-byte logical blocks: (16.0 GB/14.9 GiB) Oct 9 13:46:02 e521 kern.notice kernel: [10715.931980] sd 4:0:0:0: [sdb] Write Protect is off Oct 9 13:46:02 e521 kern.debug kernel: [10715.931983] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00 Oct 9 13:46:02 e521 kern.err kernel: [10715.931986] sd 4:0:0:0: [sdb] Assuming drive cache: write through Oct 9 13:46:02 e521 kern.err kernel: [10715.935986] sd 4:0:0:0: [sdb] Assuming drive cache: write through Oct 9 13:46:02 e521 kern.info kernel: [10715.981381] sdb: sdb1 Oct 9 13:46:02 e521 kern.err kernel: [10715.986028] sd 4:0:0:0: [sdb] Assuming drive cache: write through Oct 9 13:46:02 e521 kern.notice kernel: [10715.986035] sd 4:0:0:0: [sdb] Attached SCSI removable disk Unless if I'm missing something, those messages _always_ show up even if udev or mdev haven't been invoked. -- binki Look out for missing or extraneous apostrophes! pgpnJRnFjxFhx.pgp Description: PGP signature
Re: [gentoo-dev] Suggestion: Portage should not mask packages globally, but only for some arches
W dniu 02.02.2011 08:59, Nikos Chantziaras pisze:
It seems that KDE 4.6 is still hard-masked for x86 and amd64 because
it's waiting for ppc and ppc64 keywords. I believe it would be
beneficial for people if they wouldn't have to wait for arches that
don't affect them at all.
It seems better if the packages can be unmasked for x86 and amd64 and
only kept hard-masked for ppc/ppc64 while they wait for keywords.
Otherwise, all arches will feel the effect of the slowest one without
there being a need for this.
I don't know what gave you the idea that ppc* has anything to do with
masking/unmasking of KDE-4.6. Just 2 facts:
1) you can unmask anything by using /etc/portage/package.unmask,
therefore nothing can ever hold *you* back
2) arches already have independent package.mask files, see
${PORTDIR}/profiles/arch/powerpc/package.mask for an example.
Best regards,
Kacper Kowalik
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Suggestion: Portage should not mask packages globally, but only for some arches
It seems that KDE 4.6 is still hard-masked for x86 and amd64 because it's waiting for ppc and ppc64 keywords. I believe it would be beneficial for people if they wouldn't have to wait for arches that don't affect them at all. It seems better if the packages can be unmasked for x86 and amd64 and only kept hard-masked for ppc/ppc64 while they wait for keywords. Otherwise, all arches will feel the effect of the slowest one without there being a need for this.
Re: [gentoo-dev] Suggestion related with dropping keywords policy
El jue, 17-06-2010 a las 06:07 +0200, Jeroen Roovers escribió: On Fri, 11 Jun 2010 07:39:01 -0400 Joseph Jezak jos...@gentoo.org wrote: Your preferred method is exactly how (as a ppc keyworder) I like to see these kind of bugs handled. Dropping keywords makes an awful lot more work for us and hurts our users, especially since we're not always very prompt at handling bugs. Well, reasoning for the HPPA team, which maintains an architecture that is dying rather more quickly than PPC32 (which still has all kinds of embedded uses and so on),, in favour of IA64, I'd rather see dropped keywords than new profile entries, possibly with the keyworded ebuilds being gradually removed after an OK. That way I can make a choice to keep a package (set) for a bit or to stop supporting it immediately. In that case, could you then consider to un-CC from keywording bugs hppa team is not willing to fix? I think it would help a lot to clean the tree of old versions that are been kept as it's the inly keyworded on hppa Thanks a lot signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On Thu, 17 Jun 2010 14:04:42 +0200 Pacho Ramos pa...@gentoo.org wrote: In that case, could you then consider to un-CC from keywording bugs hppa team is not willing to fix? I think it would help a lot to clean the tree of old versions that are been kept as it's the inly keyworded on hppa Sounds like a plan. The problem I see is the amount of breakage that would cause in reverse dependencies, but can I hazard a guess that the greater desktop teams have ample compute power to resolve those? Regards, jer
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On Fri, 11 Jun 2010 07:39:01 -0400
Joseph Jezak jos...@gentoo.org wrote:
Your preferred method is exactly how (as a ppc keyworder) I like to
see these kind of bugs handled. Dropping keywords makes an awful lot
more work for us and hurts our users, especially since we're not
always very prompt at handling bugs.
Well, reasoning for the HPPA team, which maintains an architecture
that is dying rather more quickly than PPC32 (which still has all kinds
of embedded uses and so on),, in favour of IA64, I'd rather see dropped
keywords than new profile entries, possibly with the keyworded ebuilds
being gradually removed after an OK. That way I can make a choice to
keep a package (set) for a bit or to stop supporting it immediately.
Since there is no unveiling effect in re-adding dropped keywords, as
opposed to using profile masks that you can only remove safely by
first revdep-checking the entire tree again, I'd rather have people
file bug reports than touching the HPPA profile files themselves.
Since we (HPPA) basically agreed to drop support for the major desktop
environments in due time already (we still need to make that official
some time soon and then actually work on the problem for the last time),
dropping those keywords is a lot better than masking specific versions
of ebuilds or specific uses of USE flags.
Funnily enough, I've expressed these wishes to the people who are doing
the *DEPEND checks before they commit (hundreds of ebuilds) time and
again, and still ended up with sometimes years old entries in
package.{,use.}mask files.
In fact I think there's a bug open about it and I tried to get some
discussion about it going on this very mailing list. :)
jer
Re: [gentoo-dev] Suggestion related with dropping keywords policy
El lun, 14-06-2010 a las 04:59 +0200, Jeroen Roovers escribió: What is the problem? The files in place ask you to file a bug report instead of fiddling with the files yourselves. I put that in place because I got (fucking) tired of seeing the after effects of people fiddling with the arch profile files without 1) consideration, 2) informing the involved arch team. What do you expect? File a bloody bug report detailing the (commit) problem you are facing and you will probably see 1) response and 2) cooperation. If you fuck around with the arch profile files without doing any of that, you will face 1) a lack of willingness to cooperate and 2) evil wrath. Regards, jer The problem is that, at least regarding gnome related bugs, there are a lot of keywords dropped for your arch that could be prevented use.masking an USE, like, for example, dev-util/anjuta-2.28*, that is causing us to preserve and old (and broken) 2.24 release only for hppa. My intention is only to try to help you and improve the situation, I also have opened bug reports for every change have committed to, for example, powerpc profiles (you will see that I edited your profile yesterday, but it was because I totally missed the note preventing us to do that, this is why I didn't committed any more changes and sent reply above; it wasn't premeditated) Would you allow me to edit hppa package.use.mask *if I open corresponding bug report* ? Thanks :-) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On Mon, 14 Jun 2010 10:08:58 +0200 Pacho Ramos pa...@gentoo.org wrote: The problem is that, at least regarding gnome related bugs, there are a lot of keywords dropped for your arch that could be prevented use.masking an USE, like, for example, dev-util/anjuta-2.28*, that is causing us to preserve and old (and broken) 2.24 release only for hppa. What bug is that? :) jer
Re: [gentoo-dev] Suggestion related with dropping keywords policy
El lun, 14-06-2010 a las 11:30 +0200, Jeroen Roovers escribió: On Mon, 14 Jun 2010 10:08:58 +0200 Pacho Ramos pa...@gentoo.org wrote: The problem is that, at least regarding gnome related bugs, there are a lot of keywords dropped for your arch that could be prevented use.masking an USE, like, for example, dev-util/anjuta-2.28*, that is causing us to preserve and old (and broken) 2.24 release only for hppa. What bug is that? :) jer http://bugs.gentoo.org/show_bug.cgi?id=298200#c23 ;-) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On 06/11/2010 12:27 PM, Pacho Ramos wrote: From my point of view, I would prefer to: 1. Mask caps for net-wireless/bluez on affected arches, letting us to keep bluez keyworded. 2. Open two bug reports as done with current policy: one for keywording libcap-ng and other to check bluez works ok with it asking arch team to unmask that USE flag if possible. There's nothing preventing you from already doing this. package.use.mask is something package maintainers themselves should be looking after for their packages. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion related with dropping keywords policy
El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió: On 06/11/2010 12:27 PM, Pacho Ramos wrote: From my point of view, I would prefer to: 1. Mask caps for net-wireless/bluez on affected arches, letting us to keep bluez keyworded. 2. Open two bug reports as done with current policy: one for keywording libcap-ng and other to check bluez works ok with it asking arch team to unmask that USE flag if possible. There's nothing preventing you from already doing this. package.use.mask is something package maintainers themselves should be looking after for their packages. Regards, Petteri OK, thanks a lot :-D signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion related with dropping keywords policy
El dom, 13-06-2010 a las 14:43 +0200, Pacho Ramos escribió: El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió: On 06/11/2010 12:27 PM, Pacho Ramos wrote: From my point of view, I would prefer to: 1. Mask caps for net-wireless/bluez on affected arches, letting us to keep bluez keyworded. 2. Open two bug reports as done with current policy: one for keywording libcap-ng and other to check bluez works ok with it asking arch team to unmask that USE flag if possible. There's nothing preventing you from already doing this. package.use.mask is something package maintainers themselves should be looking after for their packages. Regards, Petteri OK, thanks a lot :-D The problem is that hppa team seems to not allow others than they to edit their package.use.mask :-/, is there any special reason for it? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion related with dropping keywords policy
On Mon, 14 Jun 2010 00:29:19 +0200 Pacho Ramos pa...@gentoo.org wrote: El dom, 13-06-2010 a las 14:43 +0200, Pacho Ramos escribió: El dom, 13-06-2010 a las 14:16 +0300, Petteri Räty escribió: On 06/11/2010 12:27 PM, Pacho Ramos wrote: From my point of view, I would prefer to: 1. Mask caps for net-wireless/bluez on affected arches, letting us to keep bluez keyworded. 2. Open two bug reports as done with current policy: one for keywording libcap-ng and other to check bluez works ok with it asking arch team to unmask that USE flag if possible. There's nothing preventing you from already doing this. package.use.mask is something package maintainers themselves should be looking after for their packages. Regards, Petteri OK, thanks a lot :-D The problem is that hppa team seems to not allow others than they to edit their package.use.mask :-/, is there any special reason for it? What is the problem? The files in place ask you to file a bug report instead of fiddling with the files yourselves. I put that in place because I got (fucking) tired of seeing the after effects of people fiddling with the arch profile files without 1) consideration, 2) informing the involved arch team. What do you expect? File a bloody bug report detailing the (commit) problem you are facing and you will probably see 1) response and 2) cooperation. If you fuck around with the arch profile files without doing any of that, you will face 1) a lack of willingness to cooperate and 2) evil wrath. Regards, jer
Re: [gentoo-dev] Suggestion to ask devs to change their bugzilla name when becoming devaway
2010/6/10 Pacho Ramos: El jue, 10-06-2010 a las 12:23 -0600, Joe Peterson escribió: I think a better solution, if we need to indicate this, is to have bugzilla grab the status from devaway and display it next to the dev's name in bug reports. Changing the user's name seems a bit cumbersome, and I don't agree that people will know what devaway means - i.e. they may not even google it. It's what bug 256934 is about but, until it's solved... :-/ sounds like a huge pita for people. better to spend cycles getting things upgraded and integrated properly. -mike
Re: [gentoo-dev] Suggestion to ask devs to change their bugzilla name when becoming devaway
El vie, 11-06-2010 a las 00:38 +0200, Christian Ruppert escribió: On 06/10/2010 07:07 PM, Pacho Ramos wrote: Hello Currently, we only need to set a proper message in ~/.away (as talked in http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml ) when becoming devaway. The problem is that a lot of our users don't know about that devaway list and, then, they will still open bug reports and complaint when their reports get stalled due maintainer not being available. My suggestion (until http://bugs.gentoo.org/show_bug.cgi?id=256934 is solved) is to add a new step to how to use the Devaway System instructions asking people to also change their bugzilla name appending (Devaway), for example: Pacho Ramos would be changed to Pacho Ramos (Deavaway) Then, people could simply search devaway in google and would get proper information (gentoo devway page is the first shown) Thanks The devaway status/links are planned for bugzilla-3. Great to know! Thanks :-) Are you ok with making bug 256934 block bug 213782 then? Best regards signature.asc Description: Esta parte del mensaje está firmada digitalmente
[gentoo-dev] Suggestion related with dropping keywords policy
Hello Let my explain the problem and my suggestion to handle it better (at least from my point of view) with an example: Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added. Since libcap-ng was not keyworded in all arches but x86 and amd64, I had to drop keywords for bluez and open http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it. From my point of view, I would prefer to: 1. Mask caps for net-wireless/bluez on affected arches, letting us to keep bluez keyworded. 2. Open two bug reports as done with current policy: one for keywording libcap-ng and other to check bluez works ok with it asking arch team to unmask that USE flag if possible. This way to go would have the advantage of letting people running bluez on affected arches to still get the latest bluez version instead of still having to run a pretty old (and buggy) one. Thanks for considering it signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Suggestion related with dropping keywords policy
Pacho Ramos pa...@gentoo.org said: Hello Let my explain the problem and my suggestion to handle it better (at least from my point of view) with an example: Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added. Since libcap-ng was not keyworded in all arches but x86 and amd64, I had to drop keywords for bluez and open http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it. From my point of view, I would prefer to: 1. Mask caps for net-wireless/bluez on affected arches, letting us to keep bluez keyworded. 2. Open two bug reports as done with current policy: one for keywording libcap-ng and other to check bluez works ok with it asking arch team to unmask that USE flag if possible. This way to go would have the advantage of letting people running bluez on affected arches to still get the latest bluez version instead of still having to run a pretty old (and buggy) one. it seems to depend on turnaround time. if arch teams respond quickly, then the USE flag masking would just be an increase in workload. if they are slow to respond then that may be a good investment. given that one cant dictate the speed at which arch teams work, your proposal sounds very sensible. I am OK with both methods. kind regards Thilo Thanks for considering it signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion related with dropping keywords policy
Hello Let my explain the problem and my suggestion to handle it better (at least from my point of view) with an example: Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added. Since libcap-ng was not keyworded in all arches but x86 and amd64, I had to drop keywords for bluez and open http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it. From my point of view, I would prefer to: 1. Mask caps for net-wireless/bluez on affected arches, letting us to keep bluez keyworded. 2. Open two bug reports as done with current policy: one for keywording libcap-ng and other to check bluez works ok with it asking arch team to unmask that USE flag if possible. This way to go would have the advantage of letting people running bluez on affected arches to still get the latest bluez version instead of still having to run a pretty old (and buggy) one. Thanks for considering it Your preferred method is exactly how (as a ppc keyworder) I like to see these kind of bugs handled. Dropping keywords makes an awful lot more work for us and hurts our users, especially since we're not always very prompt at handling bugs. Thanks for bringing this up on the mailing list! -Joe
[gentoo-dev] Suggestion to ask devs to change their bugzilla name when becoming devaway
Hello Currently, we only need to set a proper message in ~/.away (as talked in http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml ) when becoming devaway. The problem is that a lot of our users don't know about that devaway list and, then, they will still open bug reports and complaint when their reports get stalled due maintainer not being available. My suggestion (until http://bugs.gentoo.org/show_bug.cgi?id=256934 is solved) is to add a new step to how to use the Devaway System instructions asking people to also change their bugzilla name appending (Devaway), for example: Pacho Ramos would be changed to Pacho Ramos (Deavaway) Then, people could simply search devaway in google and would get proper information (gentoo devway page is the first shown) Thanks signature.asc Description: Esta parte del mensaje está firmada digitalmente
