Re: [gentoo-dev] [v1.0.2] GLEP 74: Full-tree verification using Manifest files
On Wed, Nov 01, 2017 at 09:44:09AM +0100, Micha?? Górny wrote > All that said, if we really have a problem that needs solving here, I'm > not convinced MISC is the right solution for it. If people need to > explicitly exclude stuff, then I suppose the configuration-injected > ignore list is much better solution for this. An example of stuff you'd run into; my make.conf has the line... PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" I've attached a script that I run whenever I add a directory to the exclusion list. It's specific to me, ie. program categories I don't use. It deletes the specified portage dirs, and updates the exclusion file. It really speeds up "emerge --sync" on my ancient Atom netbook with 2 gigabytes of ram. Will there still be an option to cycle through all existing top-level subdirectories of /usr/portage and check against the directory manifests? -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications cleanup.gz Description: Binary data
Re: [gentoo-dev] RFC v2: news item for the 17.0 profiles
On Wed, Oct 11, 2017 at 07:28:12PM -0400, Brian Evans wrote > It gets forced on with the 17.0 profile. Did you switch yet? Not yet. I'm currently delving further into an obscure ebuild failure for python, so that I can submit a more detailed bug report. Once I get that done (I already have a workaround), I'll look at the profile jump. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] RFC v2: news item for the 17.0 profiles
On Wed, Oct 11, 2017 at 12:41:06AM -0400, Walter Dnes wrote > I'm on 6.3.0 on x86, which is currently unstable on *ALL* arches, and > "emerge -pv =sys-devel/gcc-6.3.0" shows "(-pie)". And x86 32-bit gcc-6.4.0 shows (-pie) as well... == [d531][waltdnes][~] ACCEPT_KEYWORDS="~x86" emerge -pv =sys-devel/gcc-6.4.0 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS] sys-devel/gcc-6.4.0:6.4.0::gentoo [6.3.0:6.3.0::gentoo] USE="cxx fortran nptl openmp sanitize vtv (-altivec) (-awt) -cilk -debug -doc (-fixed-point) (-gcj) -go -graphite (-hardened) (-jit) (-libssp) -mpx (-multilib) -nls -objc -objc++ -objc-gc -pch -pgo (-pie) -regression-test -ssp -vanilla" 74,379 KiB -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] RFC v2: news item for the 17.0 profiles
> Display-If-Installed: >=sys-devel/gcc-6.4.0 [...snip...] > Switching the profile modifies the use-flags of GCC 6 to generate > PIE executables by default; thus, you need to do the rebuilds > even if you already used GCC 6 beforehand. > > If you do not follow these steps you may get spurious build > failures when the linker tries unsuccessfully to combine non-PIE > and PIE code. > = I'm on 6.3.0 on x86, which is currently unstable on *ALL* arches, and "emerge -pv =sys-devel/gcc-6.3.0" shows "(-pie)". Two questions... 1) Will 6.3.0 be skipped for stabilization? 2) If someone decides to override and set "-pie" in USE, will their current systems continue to function? On a new install I'll go with the default, but "emerge -e" takes a long time on my current machine. It's an ancient 2008 CORE2 with 3 gigs of ram, but it works fine for me, including Youtube 1080P streaming. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
On Thu, Sep 28, 2017 at 04:27:31PM -0500, Austin English wrote
> (Note: serious discussion, please take systemd trolling elsewhere).
>
> While having the pleasure of working with some proprietary software
> recently, I was asked to run `service foo restart`, and was surprised to
> see:
> foobar ~ # service foo restart
> * service: service `foo' does not exist
Ridiculous! We need to develop one universal standard that covers
everyone's use cases. https://xkcd.com/927/
But if you insist, why not just set up a short bash script called
"service" rather than monkeying with every init system's internals?
#!/bin/bash
if [[ ]] ; then
systemctl ${2} ${1}
elif [[ ]] ; then
/etc/init.d/${1} ${2}
elif [[ ]] ; then
else
echo "ERROR: Unsupported init system; 'service' call failed"
fi
This can handle a large number of different inits, with as many "elif"
lines as you care to add. But, how do we reliably detect the currently
running init system? Are there running processes, or entries in /sys/
or /proc/ or /dev that are unique to to each init system?
--
Walter Dnes <waltd...@waltdnes.org>
I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] [PATCH v2] eclass/kernel-2.eclass: Remove use of tr in global scope
On Thu, Aug 31, 2017 at 02:11:30PM -0400, Mike Pagano wrote > On Thu, Aug 31, 2017 at 07:27:10PM +0200, Micha?? Górny wrote: > > W dniu czw, 31.08.2017 o godzinie 12???33???-0400, u??ytkownik Mike Pagano > > napisa??: > > > As per PMS remove calls to external command 'tr' in global scope See bug > > > #629106. > > > > Closes: https://bugs.gentoo.org/629106 > > > > (assuming you want the bug closed) > > > > > > > Thanks for the review. Committed. It seems we are limited by PMS one > way or the other. If someone has a better idea of doing this simple > lowercase/uppercase change that satisifies PMS at all versions I am > happy to revisit. Is "sed -e" allowed? E.g. [d531][waltdnes][~] echo "AbCd" | sed -e 's/\(.*\)/\L\1/' abcd [d531][waltdnes][~] echo "AbCd" | sed -e 's/\(.*\)/\U\1/' ABCD -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review
On Wed, Aug 02, 2017 at 03:25:01PM -0400, Mike Gilbert wrote > On Wed, Aug 2, 2017 at 3:07 PM, Martin Vaeth <mar...@mvath.de> wrote: > > Mike Gilbert <flop...@gentoo.org> wrote: > >> On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth <mar...@mvath.de> wrote: > >>> If this already was discussed then sorry for the noise: > >>> > >>> What is the rationale for merging lib32 with lib? > >>> Wouldn't it be somewhat cleaner to have a completely > >>> split structure > >>> > >>> lib64 > >>> lib32 > >>> libx32 (possibly) > >>> lib > >> > >> Here are a couple of reasons: > >> > >> 1. Other distros (notably Red Hat and Fedora) put 32-bit libs in "lib". > > > > According to bug 506276, Debian has instead merged 64-bit to lib. > > So it seems to me that there is no "mainstream" to follow. > > Perhaps striving for the cleanest solution would be the best? > > Debian puts 64-bit libs in /lib/(host), where (host) is something like > x86_64-linux-gnu. They don't get put in /lib directly. They call this > "multiarch". > > Migrating Gentoo to a "multiarch" config is a larger project. And what happens when 128-bit cpus debut? /lib128? -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Fri, Jul 28, 2017 at 05:56:25PM -0400, William L. Thomson Jr. wrote > If upstream does a new release, fixes bugs. Gentoo marks a previous > release stable. It is stabilizing a package with issues fixed upstream. > That does not make sense. Gentoo issues maybe good, but not upstreams. > > I maintained packages like iText which used to have a 30 day release > cycle. Up till recently Jetty was about the same. As a end user, I > needed the bug fixes. Not the delay for it be marked stable. > > I stopped running Redhat long ago due to time to vet updates. I run > Gentoo for the speed of being able to package and test out new code. What I get out of this discussion is that some people prefer to run ~arch versus stable arch. I have no problem with that. But I do object to dropping "stable" altogether. I personally run stable with the rare occasional unstable package, where it's either not available as stable, or the unstable version fixes a bug in the stable version. And just for kicks I'm running gcc 6.3.0. It's one thing to rush-stabilize a new package that fixes a security hole. But I don't see the point of rush-stabilizing everything "just because". I recommend mostly keeping our current setup, with one change, i.e. allowing security-fix ebuilds to go "stable" immediately. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] vim-syntax USE flag
On Sun, Jul 23, 2017 at 05:46:04PM +0300, Andrew Savchenko wrote > On Sat, 22 Jul 2017 22:00:16 +0100 Sergei Trofimovich wrote: > > On Sat, 22 Jul 2017 16:27:39 -0400 > > Mike Gilbert <flop...@gentoo.org> wrote: > > > > > Packages currently handle installation of vim syntax support files > > > inconsistently. Some builds install the files if the "vim-syntax" USE > > > flag is enabled, while others install them unconditionally. This reminds me of /usr/share/locale/*/LC_MESSAGES/ and /usr/share/man/*/man/. There seem to be a lot of packages that are hardcoded by upstream to install umpteen locales of this stuff. > > > > > > Do these files fall into the "small text files" category for > > > unconditional installation? If so, we should probably phase out the > > > vim-syntax USE flag. > > > > I'd say use flag is not needed as long as it does not slow vim startup > > down by much and does not change editor behaviour for every single > > edited file type. > > The problem here is more complicated. What about 100 plugins from > different packages which of them is fast enough, but together they > are slowing vim down to unacceptable level? Such case is > especially sensitive on slow hardware. > > That's why fine control over vim files is mandatory. Yes, it > requires to rebuild packages, but with ccache/distcc available this > is not a huge issue. And if someone really want to avoid such > rebuilds, vim files can always be put to a separated package; > though I see no real reason to do this. > > Using INSTALL_MASK here is not an option, because toggling of > individual vim files using it will be a nightmare. A heavy-handed solution to the extra man pages and LC_MESSAGES stuff I mentioned above, is "localepurge". The file "/etc/locale.nopurge" contains a list of locales to *NOT* purge. LC_MESSAGES and man pages for all other locales are wiped. I'm not a professional programmer, but the following approach looks promising... Option A) A standalone program/script called "vimodulepurge" which would consult a file "/etc/vimodule.nopurge". The algorithm would be to "equery b" for each module in the module directory. If the owner of the module is not listed in "/etc/vimodule.nopurge", delete the module. Option B) Integrate this functionality into Portage. During the install process, check if the ebuild being installed is listed in "/etc/vimodule.nopurge". If not, skip installing files into the vim modules directory. If "/etc/vimodule.nopurge" doesn't exist, or "NEEDSCONFIGFIRST" has not been commented out, allow the modules to be installed. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On Tue, Jul 11, 2017 at 04:57:21PM -0400, William L. Thomson Jr. wrote > On Tue, 11 Jul 2017 13:27:57 -0700 > Daniel Campbell <z...@gentoo.org> wrote: > > > Portage's fault. If you don't want a package added to a set or world, > > you'll need to use the -1 (--oneshot) option. > > Did you even read above? I clearly state WITHOUT -1 option > > > I added it to my default > > emerge options in make.conf for exactly that reason (clean world); > > The point is people should not have to do such. Or remember to always > use -1 when re-emerging a dep, system, world, or set package. Step back for a minute, and relax. There is a reason you're getting blowback. You're asking for changes that would affect everybody else. This is similar in principle to what Lennart Poettering did, and you're getting the same reaction he got. I understand that *YOU* want changes to how Portage works on *YOUR* machine. No problem. Set EMERGE_DEFAULT_OPTS in make.conf. If you want excruciating detail on --depclean then check the small script I posted elsewhere in this thread. Portage has many customization options; use them. If you can't be bothered to use available customization options to set up your machine to your liking, but ask for a change of defaults that also affects everybody else, don't be surprised at the negative reaction. You would've gotten a much better reception, if you had gone to the gentoo-user list and asked "How do I tweak Portage to do this, that, and the other". -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Sets vs Meta ebuilds
I have a script I've written for my own use. It's not 100% polished,
but it does the job for me. My "autodepclean" script runs
"emerge --pretend --depclean", and reformats the output into another
script, named "cleanscript", which contains a bunch of lines like...
emerge --depclean --verbose =fu-bar/xyz-1.2.3
Before running "./cleanscript", I check it for problems. Here's the
autodepclean script...
#!/bin/bash
# autodepclean script v 0.04 released under GPL v3 by Walter Dnes 2012/07/09
# Generates a file "cleanscript" to remove unused ebuilds, including
# buildtime-only dependancies.
#
# Warning; this script is still beta. I recommend that you check the output
# in cleanscript before running it.
#
# With the arrival of "virtual/editor", the script now suggests removing
# app-editors/nano, which may not be what you want. If you want to keep
# nano, put it into world
#
# version 0.03 disables the removal of gentoo-sources. Your current kernel
# is not always the most recent one in /usr/src.
#
# version 0.04 adds "--verbose" to the "emerge --depclean". This makes it
# easier to track down circular dependancies.
#
echo "#!/bin/bash" > cleanscript
echo "#" >> cleanscript
emerge --pretend --depclean |\
grep -A1 "^ .*/" |\
grep -v "^ \*" |\
grep -v "^--" |\
sed ":/: {
N
s:\n::
s/selected: /-/
s/^ /emerge --depclean --verbose =/
}" | grep -v "gentoo-sources" >> cleanscript
echo "revdep-rebuild" >> cleanscript
chmod 744 cleanscript
--
Walter Dnes <waltd...@waltdnes.org>
I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Sets vs Meta ebuilds
On Sun, Jul 09, 2017 at 09:49:08AM -0400, William L. Thomson Jr. wrote > On Sun, 9 Jul 2017 05:24:19 -0400 > "Walter Dnes" <waltd...@waltdnes.org> wrote: > > > Yes, for gcc. > > Which if someone ignores warnings, and breaks their system, it is on > them. At that point your best to remove said package from the set, and > then proceed with removing the set. "Fat-Finger" does happen once in while. Removing the risk of it happening in the first place is a lot more robust/bulletproof. > > If / when I unmerge the meta-set, I want to only unmerge stuff that > > is not part of (packages I normally require). I do not want all > > members of the set unmerged unconditionally, regardless of being > > dependancies for packages I still have. > > That is a matter of knowing what is in the set and on your system. In > that case the idea for a set would be to add packages that are NOT part > of your normal system. Adding packages part of your system would defeat > the benefit. > > > This is where a meta-package is superior to a set. I simply unmerge > > the meta-package, and "emerge --ask --depclean". If a meta-set item > > is a dependancy of a package that I'll be keeping, it won't get > > removed. I do not want to risk removing a package that is needed > > elsewhere. And 2 or 3 years later, I may have installed packages > > that have members of the meta-set as a dependancy. A meta-package > > removes the risk of shooting myself in the foot. > > Yes in the case you just add stuff into a set, not paying attention if > it is a dep of another package, present or future. Then a meta ebuild > does allow someone to be "lazier" ( not insulting you ) and know less > about their system and packages. Just toss package names into a ebuild, > and not worry if its a dep or not, past, present, or future. Everybody who doesn't run LFS (Linux From Scratch) is "lazy" in that regard. Figuring out dependancies is the job of a package manager, not the end-user. I may be getting old, and my head may be slowly becoming like that of Captain Picard in STTNG (Star Trek The Next Generation). I do appreciate being able to decide I want something installed and telling Portage to "Make it so", and letting it take care of details. a) I don't want to have to spend time figuring out if an item is or is not a deep dependancy of a package I currently have. b) I may install other packages later on which may have items already in the set as a dependancy. c) Even if *I* don't change "world", GNOME's ever-growing hard-coded dependancy list will change. hicolor-icons is just one example. I use ICEWM as my WM, with no DE (see my sig). But gnumeric is/was a good spreadsheet that I need. Over the years, I've seen stuff added to gnumeric's dependancies like "goffice", "ghostscript", "harfbuzz", "dbus", etc, etc. Most of that comes via GTK3. I wouldn't be surprised if GTK4 adds pulseaudio and/or systemd as hard-coded dependancies. I'd love to see somebody port gnumeric and Pale Moon to use FTLK ( http://www.fltk.org/index.php ) instead of GTK, to get away from that bloat. Too bad I'm not a programmer. > It is a way to go, but others may want more fine grained control and > have more awareness of package dependencies, and only add non > dependent non-system packages to a set. Assuming it's not a lot of additional work, what exactly do sets allow that meta packages don't? -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Sets vs Meta ebuilds
On Sat, Jul 08, 2017 at 09:29:42PM -0400, Rich Freeman wrote > It is slightly more cruft than a set, but honestly not a great deal so. The only problem is that you have to maintain ebuilds in an overlay and run "repoman manifest" every time you create or edit a meta package. Here's an off-the-wall idea to combine the best of both worlds... * create virtual/rdepend.ebuild in the overlay * can it inherit/include an RDEPEND list from a specific text file? E.g. /etc/portage/package_rdepend * "emerge rdepend" after adding items to /etc/portage/package_rdepend * "emerge --depclean" after deleting from /etc/portage/package_rdepend -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Sets vs Meta ebuilds
On Sat, Jul 08, 2017 at 09:32:09PM -0400, William L. Thomson Jr. wrote > On Sat, 8 Jul 2017 20:27:38 -0400 > "Walter Dnes" <waltd...@waltdnes.org> wrote: > > > > > Though I will have to see what happens if a package is listed in > > > more than one set. I think there is a hierarchy there. > > > > I tried "emerge -pv --unmerge @palemoon_build", and it was ready to > > delete all the stuff, including gcc, etc. > > Did you get any warnings? Your about to remove a system package, etc. Yes, for gcc. > If you are making sets, adding system packages, and removing those. I > would assume you are doing that as some sort of testing. Which would > want to re-emerge/install those packages. Depending on what your doing > very likely would want to make and use binaries in that process. Surely > if removing system packages :) Here's the problem... when I need some extra packages for a specific project, I want them to be pulled in *IF NOT ALREADY PRESENT*. If/when I finish the project, I want to remove packages *THAT ARE NOT DEPENDANCIES FOR OTHER PACKAGES I'M KEEPING*. Using set terminology, as in high school math, where * A is the set of (packages I normally require) * B is the set of (requirements for project X) ...I want to end up with ( A union B ) If I ever finish the project and decide to unmerge the meta-set I only want to unmerge... ( A union B ) - ( A ) If / when I unmerge the meta-set, I want to only unmerge stuff that is not part of (packages I normally require). I do not want all members of the set unmerged unconditionally, regardless of being dependancies for packages I still have. This is where a meta-package is superior to a set. I simply unmerge the meta-package, and "emerge --ask --depclean". If a meta-set item is a dependancy of a package that I'll be keeping, it won't get removed. I do not want to risk removing a package that is needed elsewhere. And 2 or 3 years later, I may have installed packages that have members of the meta-set as a dependancy. A meta-package removes the risk of shooting myself in the foot. > > I deleted /etc/portage/sets/palemoon_build, and the entry > > "@palemoon_build" from /var/lib/portage/world_sets. It turns out > > that all these packages are required anyways. > > Meaning little was removed after you did emerge --depclean world ? Nothing would've been removed. Several months ago, the hicolor-icon theme would've been removed. But it has recently been added to the ever-growing list of gtk dependancies. GTK == GNOME Tool Kit, regardless of what they officially call it. I only ran a "pretend" unmerge, to see what would happen if I did unmerge the set. As a precaution, I've decided to migrate over to a meta-package. As per Rich Freeman's recommendation, I'll go with RDEPEND, and fill in optional descriptive fields in the meta-set. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Sets vs Meta ebuilds
On Fri, Jul 07, 2017 at 01:07:57PM -0400, William L. Thomson Jr. wrote > On Fri, 7 Jul 2017 12:57:17 -0400 > Brian Evans <grkni...@gentoo.org> wrote: > > > Beware of sets.. if you put toolchain packages in a set and later > > do 'emerge --unmerge @custom-set' , emerge will happily destroy > > your toolchain. > > That is not much different than removing a system package directly. > If you do foolish things you will run into such problems. That would > be a self inflicted issue. Likely done out of not knowing what you > are doing. I build Pale Moon to my own custom specs, as well as a contributed SSE-only build for older machines. At one point, I read the list of necessary stuff to do the build. I incorporated the following into /etc/portage/palemoon_build >=app-arch/zip-2.3 >=dev-lang/perl-5.6 >=dev-lang/python-2.7.3 >=dev-lang/yasm-1.0.1 >=dev-libs/glib-2.24 dev-vcs/git media-libs/fontconfig >=media-libs/freetype-2.1.0 media-libs/mesa =sys-devel/autoconf-2.13 sys-devel/gcc <=x11-libs/gtk+-3.0 x11-libs/libXt x11-themes/hicolor-icon-theme > Though I will have to see what happens if a package is listed in more > than one set. I think there is a hierarchy there. I tried "emerge -pv --unmerge @palemoon_build", and it was ready to delete all the stuff, including gcc, etc. > Not to mention if it was removed. I think the world or system set > would pull it back in. Kind of hard to "pull it back in" if gcc or glib or ncurses isn't present. This is rather dangerous. The problem is that, unlike an ebuild, "emerge --unmerge @set" removes all packages in the set, regardless of whether they're required by another package or not. I deleted /etc/portage/sets/palemoon_build, and the entry "@palemoon_build" from /var/lib/portage/world_sets. It turns out that all these packages are required anyways. hicolor-icon-theme was not required previously, but gtk seems to add more and more GNOME dependencies every time I update my system. Let's say I try to do this as a meta package. So in my overlay I create a category "meta-set" and a file "meta-set/pmbuild-0.ebuild" EAPI=5 SLOT="0" KEYWORDS="amd64 x86" DEPEND=" >=app-arch/zip-2.3 >=dev-lang/perl-5.6 >=dev-lang/python-2.7.3 >=dev-lang/yasm-1.0.1 >=dev-libs/glib-2.24 dev-vcs/git media-libs/fontconfig >=media-libs/freetype-2.1.0 media-libs/mesa =sys-devel/autoconf-2.13 sys-devel/gcc <=x11-libs/gtk+-3.0 x11-libs/libXt x11-themes/hicolor-icon-theme" Does each entry have to be detailed with configure, install, etc, stuff, or is this sufficient? -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] New 17.0 release profiles
On Thu, Jun 15, 2017 at 11:41:11PM +0200, Andreas K. Huettel wrote > Check the /etc/portage/make.profile symlink. It points to the > eselected profile. Replace that symlink with a new one pointing to > the corresponding 17.0 directory. I just synced and updated world. Profile 17.0 exists for amd64 but not for x86. Is that supposed to be the case? This is a Core2 Due from 2008, with 3 gigs or ram, which I'm running as x86 (32-bit). [d531][root][~] ll /usr/portage/profiles/default/linux/amd64 total 32 drwxr-xr-x 5 root root 4096 Jun 13 14:27 . drwxr-xr-x 18 root root 4096 May 9 16:48 .. drwxr-xr-x 8 root root 4096 May 8 19:21 13.0 drwxr-xr-x 8 root root 4096 Jun 13 14:27 17.0 drwxr-xr-x 3 root root 4096 May 8 19:21 dev -rw-r--r-- 1 root root2 Aug 8 2015 eapi -rw-r--r-- 1 root root 340 Feb 28 14:50 package.use.mask -rw-r--r-- 1 root root 37 Aug 8 2015 parent [d531][root][~] ll /usr/portage/profiles/default/linux/x86 total 24 drwxr-xr-x 3 root root 4096 May 9 16:48 . drwxr-xr-x 18 root root 4096 May 9 16:48 .. drwxr-xr-x 6 root root 4096 May 8 19:21 13.0 -rw-r--r-- 1 root root2 Aug 8 2015 eapi -rw-r--r-- 1 root root 340 Feb 28 14:50 package.use.mask -rw-r--r-- 1 root root 35 Aug 8 2015 parent -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] New 17.0 release profiles
On Thu, Jun 15, 2017 at 11:41:11PM +0200, Andreas K. Huettel wrote > Am Sonntag, 11. Juni 2017, 20:39:00 CEST schrieb Walter Dnes: > > 1) Should I be doing bug reports on the Gentoo bugzilla or upstream? > > Gentoo please, though also submitting stuff upstream and linking to > it in the Gentoo bug is appreciated. I submitted https://bugs.gentoo.org/show_bug.cgi?id=621638 earlier this week for ICEWM. The solution appears to be to keyword and install x11-wm/icewm-1.3.12-r1 It's running fine for me, built under GCC 6.3.0 Bug https://bugs.gentoo.org/show_bug.cgi?id=594136 for xfreecell was already submitted back in 2016-09-17. And thanks for the 17.0 symlinking info. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] New 17.0 release profiles
On Sat, Jun 10, 2017 at 05:15:05PM +0200, Andreas K. Huettel wrote
> -> The new profiles will NOT have any entries in profiles.desc
> yet. For "normal people" that means DO NOT SWITCH to these profiles
> yet. <-
>
> However, if you're involved with toolchain, languages, etc, already
> run gcc-6, and know what you're doing, feel free to adjust your
> profile symlink manually. You will have to rebuild all packages
> installing static archives because of the PIC flip.
>
> All testing is appreciated, as is writing of documentation. Just be
> advised to watch this list for news since THINGS MAY STILL CHANGE
> in weird and wonderful ways.
I'm running GCC 6.3.0 on a few machines with almost all other packages
stable. Only busybox is static on my machines, and it's been rebuilt.
So far I've run into...
* games-board/xfreecell needs CXXFLAGS="${CXXFLAGS} -Wno-narrowing"
in a custom env to build.
* x11-wm/icewm segfaults right after startup when built with GCC 6.3.0
so I have to build with 5.4.0. /var/log/Xorg.0.log is useless because
it sees a normal startup and a "normal exit". Other people on the
Gentoo user forum report no problems with ICEWM under GCC 6.3.0.
The above 2 items happen on an older desktop and netbook (both 32-bit
Gentoo), and a newer desktop (64-bit Gentoo). I'm partially finished
re-installing on a "newer" notebook (64-bit Gentoo). Questions...
1) Should I be doing bug reports on the Gentoo bugzilla or upstream?
2) What is the detailed procedure for adjusting symlinks to the 17.0
profile? Probably simple enough after you've done it once or twice,
but I've never had to do it manually before. According to
https://wiki.gentoo.org/wiki/Upgrading_Gentoo
> In the simplest case users only have to change the
> /etc/portage/make.profile symlink, in the worst case they may have
> to recompile the entire system from scratch while doing a neat
> voodoo dance.
--
Walter Dnes <waltd...@waltdnes.org>
I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] [RFC] NeoVim and vim-syntax
On Fri, Jun 02, 2017 at 01:14:31PM +1200, Kent Fredric wrote > On Thu, 1 Jun 2017 09:38:01 -0400 > "Walter Dnes" <waltd...@waltdnes.org> wrote: > > > As mentioned elsewhere, what happens when two or three other > > people do their own forks? Plugin 1 works with vim A and B but > > not C or D. Plugin 2 works with vim A and C and D but not B. The > > number of directories could potentially be 2^N where N is the number > > of forks. And who's going to do the necessary testing across > > multiple versions? And remember that each minor version bump of any > > of the forks could render another fork's plugin incompatable. This > > is a classic "moving target". The only way that works is to have > > each fork look after their own copies of plugins. > > If and when that happens: It already has happened. Compare /usr/portage/app-editors against http://texteditors.org/cgi-bin/wiki.pl?ViFamily Portage has... * elvis * levee * nvi * vi * vim * vis ...not to mention neovim, which doesn't show up on texteditors.org. > "4" could alternatively be implemented by creating a meta-file that > enumerates a list of source files to symlink, and the list of vim > implementations that are known to be supported by it, and then a > tool can fix up the difference in pkg_postinst or on-demand. This would require a multi-dimensional array of approx 7 packages (today) versus however many ebuilds are currently in Portage for each editor. Do I see any volunteers for compatibility testing for all current and future VI-family editors and plugins on all current and future ebuilds on all arches (small and large endian) and various USE flags? And what happens when 2 or more editors make different plugins with the same file names? This is not a "software ecosystem", and the various upstreams are not obligated to co-operate with each other. Indeed, the reason for a fork may be bad blood between developers in the first place. A lot of complexity to save a few kbytes on a multi-terabyte hard drive (even a 128 gig SSD) does not make sense. And it may actually use more space in the long run. If I have only vim, do I really want everybody else's plugins installed? No. But if I do switch over to another VI-family editor, or install one simultaneously, how does a separate "plugins package" know which plugins to install? And if I uninstall one editor, how does the "plugins package" know which plugins to uninstall? -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] [RFC] NeoVim and vim-syntax
On Wed, May 31, 2017 at 11:54:59PM +0100, Ciaran McCreesh wrote > - Have a separate anyvimishthing directory, and make both vim and > neovim look there, and only make plugins that have been tested to work > with both install to that directory. As mentioned elsewhere, what happens when two or three other people do their own forks? Plugin 1 works with vim A and B but not C or D. Plugin 2 works with vim A and C and D but not B. The number of directories could potentially be 2^N where N is the number of forks. And who's going to do the necessary testing across multiple versions? And remember that each minor version bump of any of the forks could render another fork's plugin incompatable. This is a classic "moving target". The only way that works is to have each fork look after their own copies of plugins. This reminds me of Firefox and Pale Moon, except that browser plugins are user-installed. After the initial fork from Firefox, plugins were mostly compatable amongst the two browsers. Over time, as the code diverged, fewer plugins remained compatable (not talking about Firefox's upcoming deprecation of XUL). E.g. Pale Moon now has a forked version of Ad Block Plus to ensure that it works on Pale Moon.. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] toolchain meeting agenda for today 19:00 UTC #gentoo-toolchain
On Fri, May 26, 2017 at 08:29:59PM +0200, Kristian Fiskerstrand wrote > On 05/26/2017 08:07 PM, Alexis Ballier wrote: > > A bit late to the party, but what was the outcome of the meeting, esp. > > this part ? > > Unofficial log from meeting: > https://download.sumptuouscapital.com/gentoo/tmp/gentoo-toolchain.log.txt The irc log mentions problems with some ebuilds under some versions of GCC. In a similar vein, are there any anticipated issues with binaries built under older GCC versions running on a system that is otherwise all-GCC-6.3.0? I'm thinking of pre-built binaries like Pale Moon (from their website), firefox-bin, seamonkey-bin, openoffice-bin, libreoffice-bin, libreproject-bin, etc. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list
On Wed, May 24, 2017 at 05:51:00AM -0400, Rich Freeman wrote > What value would be obtained by posting this stuff for user comment? > I'd also note that only one of those was posted on -dev-announce for > comment as far as I'm aware. Two are package/project-level changes > which typically don't get wide discussion. I was using the Firefox PulseAudio event as another example of stuff that happens in some obscure location that ordinary users don't know about. It was https://bugzilla.mozilla.org/show_bug.cgi?id=1247056 YES!!! It was done as a bug in the Firefox bugzilla. How many regular users religiously follow that? There were some people who "upgraded" Firefox one day, and discovered that sound no longer worked on it. It was done with so little communication that several Firefox maintainers for various linux distros (i.e. not exactly ordinary users) were unaware that they should set PulseAudio as a hard dependancy for Firefox. An item I just remembered was the switchover from "/dev/hda" to "/dev/sda". One day I upgraded (the kernel?), and got a panic at the next bootup. Fortunately, I have a "Production" and an "Experimental" kernel in my LILO menu, so I was able to reboot, and fall back to the previous kernel. A new kernel always goes into "Experimental". I "promote" the Experimental kernel to Production after it has run without problems for a couple of weeks. Another one was when font packages stopped generating ISO8859-1 fonts if you didn't add the "nls" USE flag. No news item. Xfreecell stopped working because it couldn't find the font. The point I'm trying to make is that these kind of surprises should not happen, be they OS-level or application-level. Regular users should not have to follow this list. Even if you're not going to alter course regardless of feedback, at least let users know so they're not caught unawares. If nothing else, post news items to Gentoo-user ***AHEAD OF TIME*** warning about changes like these. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list
On Wed, May 24, 2017 at 08:41:25AM +0200, Micha?? Górny wrote > Next time such a thing happens, the discussion will happen on a > completely private media or not happen at all because of the state > of this mailing list. Is this what you really want? Here's the part you did not quote... >> If we could have a guarantee of proposed changes like that being >> posted on Gentoo-User for comment, rather than being sprung on >> users by surprise, I'd be willing to sign off this list. Note where I said "...posted on Gentoo-User for comment...". What I'm asking is for such proposed changes to be posted on Gentoo-User, and the discussion/feedback/flamefests/etc will be on Gentoo-User. This type of surprise stuff seems to happen a lot in Open Source... * Gentoo /usr * Firefox Australis UI, and dropping ALSA and going PulseAudio-only * GNOME getting a hard-coded dependancy on systemd * etc, etc -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list
Let's step back a minute, and consider *WHY* non-developers feel the need to join this list in the first place. Do you remember the acrimony after the decision to not officially support a separate /usr without initramfs? A lot of people who complained on the Gentoo-User list were bluntly told that the devs hadn't heard much objection, and that they should've expressed their opinion on *THIS* list *BEFORE* the final decision was made. This reminds me of a quote from The Hitchiker's Guide To The Galaxy... "But the plans were on display..." "On display? I eventually had to go down to the cellar to find them." "That's the display department." "With a flashlight." "Ah, well, the lights had probably gone." "So had the stairs." "But look, you found the notice, didn't you?" "Yes," said Arthur, "yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'." I'd really rather not have to follow an additional list which includes a lot of very technical items and patches that are over my head. But after the separate /usr fiasco, I don't feel I have any choice. If we could have a guarantee of proposed changes like that being posted on Gentoo-User for comment, rather than being sprung on users by surprise, I'd be willing to sign off this list. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Sun, May 14, 2017 at 04:56:29PM +, James McMechan wrote > Silly Notes: > While I personally considered IA64 useless shortly after arrival, > Intel has just (5/11/17) announced another bump in that family the > 9700 Series. And it will also be the last Itanium released http://www.pcworld.com/article/3196080/data-center/intels-itanium-once-destined-to-replace-x86-in-pcs-hits-end-of-line.html The contract/agreement, between HPE and Intel, covers development of Itanium through to the end of 2017. Intel is not selling enough of them to warrant further development. Intel has been urging Itanium users to migrate to high-end Xeons. Some features, formerly available from Intel only on Itanium, have started showing up on high-end Xeons. An interesting, somewhat cynical, post on Slashdot... https://hardware.slashdot.org/comments.pl?sid=10604939=54412501 suggests that Intel came up with a radically different design for Itanium, versus x86, specifically to avoid a cross-licencing agreement that allows AMD to clone Intel x86 and x86_64 cpus. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp", v2
On Tue, May 09, 2017 at 06:58:42PM -0500, Matthias Maier wrote > This is a reworded news item (assuming we proceed with the plan to > default-enable USE=pie). Suggestions for improving the emerge command to > fix static archives is highly welcomed. > > Matthias > > > > Title: GCC 6 defaults to USE="pie ssp" > Author: Matthias Maier <tam...@gentoo.org> > Content-Type: text/plain > Posted: 2017-05-09 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: >=sys-devel/gcc-6.3.0 > > In Gentoo, several GCC features can be default disabled or enabled > via use-flags of sys-devel/gcc. Starting with gcc-4.8.3 we have already > enabled default SSP [1]. Since the PIE patchset for default position > independent executable support was integrated upstream [2,3], starting > with gcc-6.3 we are also enabling PIE by default (via a default-enabled > use-flag pie) in regular (non-hardened) profiles. Has anyone checked 32-bit systems? "emerge -pv =sys-devel/gcc-6.3.0" on a 2008 Core2duo 32-bit install (my GCC 6.3.0 testbed) shows "(-pie)". I read that as the "pie" USE flag being hard-masked out. On my 64-bit desktop, "pie" is the default. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
[gentoo-dev] USE flag name collision in use.local.desc "graphite"
Is it considered a reportable bug? [i660][waltdnes][~] grep :graphite /usr/portage/profiles/*.desc /usr/portage/profiles/use.local.desc:dev-lang/gnat-gpl:graphite - Add support for the framework for loop optimizations based on a polyhedral intermediate representation /usr/portage/profiles/use.local.desc:media-libs/harfbuzz:graphite - Use graphite to render complex non-Roman writing systems /usr/portage/profiles/use.local.desc:sys-devel/gcc:graphite - Add support for the framework for loop optimizations based on a polyhedral intermediate representation The "graphite" USE flag means something entirely different for harfbuzz, i.e. build media-libs/harfbuzz against media-gfx/graphite2 -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc
On Wed, Apr 26, 2017 at 11:32:21AM +0200, Andreas K. Huettel wrote
> Except that "switching back" from gcc-5 to gcc-4 doesn't really work,
> and that gcc-4 will happily use gcc-5 libraries, with unintended
> consequences.
It can be done, but it takes a little work. I do a contributed build
for Pale Moon using gcc 4.9.4 as per the developers' specs, and I use
5.4.0 for personal builds at home. This is done on a 32-bit CoentOS 6.5
chroot, in order to use an older gtk2 (long story). The native compiler
is gcc 4.7.4. I build self-contained gcc 4.9.4 and 5.4.0 environments.
Example follows, with gcc-4.9.4 going into $HOME/gcc494/
###
#
# Instructions adapted from https://gcc.gnu.org/wiki/InstallingGCC
wget http://ftpmirror.gnu.org/gcc/gcc-4.9.4/gcc-4.9.4.tar.bz2
tar xjf gcc-4.9.4.tar.bz2
#
# To get gmp, mpc, mpfr, and isl libs
# You *MUST* run this script from the top-level GCC source dir
cd gcc-4.9.4
contrib/download_prerequisites
export CFLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
-fno-unwind-tables -fno-asynchronous-unwind-tables"
export CXXFLAGS="${CFLAGS}"
export MAKEOPTS="-j4"
#
# You *MUST NOT* run ./configure from the toplevel GCC source dir
mkdir gcc-build && cd gcc-build
../configure --prefix=$HOME/gcc494 \
--disable-multilib \
--enable-libstdcxx-threads \
--enable-libstdcxx-time \
--enable-shared \
--enable-__cxa_atexit \
--disable-libunwind-exceptions \
--disable-libada
make -j4
make install
###
So far, so good, but we also need to force invocations of "gcc" to use
this version. The build script sources the following commands (and
other build-specific stuff) before starting the compile...
###
export GCCX_ROOT=$HOME/gcc494
export PATH=$GCCX_ROOT/bin:$PATH
export MANPATH=$GCCX_ROOT/share/man:MANPATH
export INFOPATH=$GCCX_ROOT/share/info:$INFOPATH
export LD_LIBRARY_PATH=$GCCX_ROOT/lib:$GCCX_ROOT/lib:$LD_LIBRARY_PATH
export LD_RUN_PATH=$GCCX_ROOT/lib:$GCCX_ROOT/lib:$LD_RUN_PATH
export LIBRARY_PATH=$GCCX_ROOT/lib:$GCCX_ROOT/lib:$LIBRARY_PATH
export INCLUDE_PATH=$GCCX_ROOT/include:$INCLUDE_PATH
export CPLUS_INCLUDE_PATH=$GCCX_ROOT/include:$CPLUS_INCLUDE_PATH
export C_INCLUDE_PATH=$GCCX_ROOT/include:$C_INCLUDE_PATH
###
The include script to use gcc 5.4.0 differs in only the first line...
###
export GCCX_ROOT=$HOME/gcc540
###
Would the various "export" commands work if inserted into make.conf?
Actually, would they even need the "export " portion of the declaration?
--
Walter Dnes <waltd...@waltdnes.org>
I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Re: stable gcc 5.4.0 ??
On Thu, Apr 20, 2017 at 05:52:20PM -0500, Matthias Maier wrote > (A-C) gcc-5.4.0 and gcc-4.9.4 are slotted separately. What is going to > be the default is entirely up to you. Good to hear. Like I said, on a fresh install I'd go with the current version (5.4). But for now, I'll wait for other people to experience problems. If nothing major, I might switch at a convenient time. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Re: stable gcc 5.4.0 ??
On Thu, Apr 20, 2017 at 07:36:03AM +0200, Tomas Mozes wrote > > The default is new: > https://www.gentoo.org/support/news-items/2015-10-22-gcc-5-new-c++11-abi.html And the news item says... > Display-If-Installed: >=sys-devel/gcc-5 ...which means that people like me, who currently have 4.9.4, won't know about it until after the fact. Then they'd have to... [i660][waltdnes][~] emerge -pve @world Total: 529 packages (3 upgrades, 526 reinstalls), Size of downloads: 10,360 KiB ...fun !NOT. If you're doing a fresh install, ***WITH A GCC5-BUILT INSTALL CD AND STAGE 3***, then yes, go for it. But changing horses in mid-stream can be painfull. Would it hurt to stay with 4.9.4 for the time being, assuming that you're not using prebuilt stuff like firefox-bin or libreoffice-bin? What would be the best way to go about it? A) Would 5.4.0 be slotted separately, and 4.9.4 left as the default? B) Add "-D_GLIBCXX_USE_CXX11_ABI=0" to CFLAGS and CXXFLAGS C) Mask out ">sys-devel/gcc-4.99" D) Allow "--with-default-libstdcxx-abi=gcc4-compatible" via a USE flag? Whatever option is selected, people need to be warned about it *NOW*, not after gcc-5.4.0 has been installed. I wonder if it's going to be worth it to go to 5.4. Looking at https://gcc.gnu.org/ today, I see... GCC 5.4 Status: 2016-06-03 (regression fixes & docs only). GCC 6.3 Status: 2016-12-21 (regression fixes & docs only). GCC 7.1 Status: 2017-04-20 (frozen, all changes require RM approval). Development: GCC 8.0 Status: 2017-04-20 (regression fixes & docs only). Maybe we should what many enterprises do with Windows; i.e. skip a version and go straight to gcc-6. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Re: stable gcc 5.4.0 ??
> It is stable. Even there are open bugs, arches started stabilizing it. Is gcc-5.4.0 built "--with-default-libstdcxx-abi=gcc4-compatible"? On the Pale Moon linux sub-forum, there were crashing issues with the contributed Ubuntu build when Ubuntu switched to gcc 5. The maintainer of the Ubuntu Pale Moon build had to drop back to gcc 4.9 to fix the crashes. At home, for personal use, I build Pale Moon with a manually built version of gcc 5.4.0. Pale Moon has been rock solid for me on Gentoo and on a refurbished Lenovo T400 running Puppy Linux. The option "--with-default-libstdcxx-abi=gcc4-compatible" may be the reason it works for me. This may be valid for other applications, too. I think the problem is that you need the entire system to be one of... "--with-default-libstdcxx-abi=new" or "--with-default-libstdcxx-abi=gcc4-compatible" Mixing together does not seem to work. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
On Sun, Mar 26, 2017 at 01:04:18PM -0700, Brian Dolbec wrote > > So with a general file name of arches.desc Is there any other data > that we want to include in that file? Possibly migrated from other > file(s). In that case a dictionary format yaml file might be best. > My example below has additional info over what was proposed. On Sun, Mar 26, 2017 at 10:29:17PM +0200, Ulrich Mueller wrote > > Please don't. Any such sophisticated file formats don't play well with > standard Unix tools like grep. Also the file will have have to be used > by tools like app-emacs/ebuild-mode, and to my knowledge there exists > no solid parser for yaml in elisp. > > A simple text file with one record per line has the advantage that it > can be easily parsed in any language. A compromise that addresses both concerns. How about a collection of records in the format... arch:attribute:data Examples amd64:stability: stable amd64:bits: 64 amd64:description: Includes CPU manufaturers such as Intel, AMD, others... amd64:comments: The most common/popular arch in the tree... amd64:email: amd64@... mips:stability: testing mips:bits: 32 mips:description: Risc based achitecture ... (not fact checked) mips:comments: Primarily used in some laptops and single board development systems... mips:email: foo@... m68k:stability: unstable m68k:bits: 8 m68k:description: Motorola... m68k:comments: embedded... m68k:email: embedded@... Hopefully, there's no need to go JSON format (bleagh). To simplify parsing, fields for one arch should be clustered together. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
- Typo... Additional Security Project bugzilla notes * The Security Project is except (should that read "exempt"?) - An intermediate level before masking might be issuing a warning if some simple, specific remediation measure can protect against a vulnerability. E.g. forcing cups to only listen to 127.0.0.1 or :1 - If you want to absolutely ensure that people are warned of a severe, but remediable vulnerability, is it acceptable to "break the build" by requiring a new local USE flag for the ebuild? I'm thinking of something like "glep_0001234", "glep_0001235", "glep_0001236", etc, and have the ebuild die if the flag is not set, and print out a URL for a security problem. This could be abstracted to make.conf with a new variable... GLEP="0001234 0001235 0001236 etc etc" This would probably be the last stage before masking. It would deliberately break the build, and require the user/admin to take manual action (add the flag for the GLEP) before proceeding further. This is a heavy-handed method, but masking is more final. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, Feb 02, 2017 at 01:01:52PM -0500, Rich Freeman wrote > Is there a better way we can have our cake and eat it too? I'll admit > that a huge package.use on the minimal profile isn't a whole lot > better than a huge package.use on all the other profiles. > > Do we need another form of syntax in individual ebuilds to try to > separate out the various cases you cite? Does anybody care to > actually suggest one? > > I still think that we shouldn't encourage users to lightly deviate > from all the upstream defaults. There are of course legitimate > reasons for doing so, and you and I can probably appreciate when we > should do this, but for somebody starting out we're giving them a lot > of rope to hang themselves with. The "case" for IUSE often depends on a fallacious strawman argument about USE="-*". The strawman argument is that people run with the USE variable in make.conf consisting of "USE=-*" and that every package requires an entry in package.use WRONG! WRONG! WRONG! That is a braindead approach. The way I recommend doing it is... USE="-* fu bar blah blah blah" ...where commonly-used flags are included in USE. My rule-of-thumb is Given that * not including a flag in USE requires X entries adding it in package.use * including a flag in USE requires Y entries negating it in package.use If ( X > Y ) then include the the flag in USE else do not include the the flag in USE end if I effectively "build my own profile" rather than depend on multiple levels of inheritance. My current desktop runs with the following USE flags... USE="X apng bindist ffmpeg jpeg opengl png szip truetype x264 x265 xorg threads webp -acl -berkdb -caps -cracklib -crypt -filecaps -gallium -gdbm -graphite -gstreamer -iconv -introspection -ipc -iptables -ipv6 -libav -llvm -manpager -nls -openmp -pam -pch -sendmail -tcpd -udev -unicode -xinerama" Note all the negative flags. I'll try installing uclibc to a laptop one of these days. I figure that it'll probably have a shorter USE line if I start USE with "-*", and I will not have a larger package.use file. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, Feb 02, 2017 at 09:11:26AM -0500, Michael Orlitzky wrote > 2 To avoid an unsatisfied REQUIRED_USE by default. > > * Example: having a non-empty RUBY_TARGETS by default. What's wrong with having emerge spit out an error message, and telling the user that they need to set a flag to one of 2-or-more options? > 4 To make the default build agree with the maintainer's personal > preferences. > > * Example: enabling hpn in net-misc/openssh by default. Another example is IPV6 which most people do not yet have from their ISP as a regular service. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...
On Fri, Jan 27, 2017 at 02:57:00PM -0500, james wrote > > Exactly:: simplify the flags, profiles and associated constructs down to > the bare bones. Even embedded (arm/mips/etc) builds could benefit from a > really minimized gentoo as a starting point. Freedom to build and fork > Gentoo, per GLEP 70 is a wonderful idea, whose time has arrived. That > would set the stage for quickly building highly specific gentoo installs > (VMs, Containers, Clusters or unikernel); all via a 'recipe' from the > minimal core-sed, which could then take a variety of forms, such as > bare-metal builds vi IPMI, ipxe, or more traditional formularies like > chef, puppet, ansible as well as a myriad of other possibilities. > > > All of the traditional gentoo installs, such as the handbook, would > benefit from simplification and the natural clarity that simplification > brings. Builds of things like simple standard gentoo-cluster-CI. > Nothing would preclude the adventuresome from building up a > traditional, highly customized install, for a specific needs such as > currently is the (handbook) practice. But additional gentoo installs > that are quick, streamlined and soot a specific itch. A possible starting point... * Start with a basic text-mode install, with minimal USE flags USE="-* foo bar etc..." * Specialized profiles could be generated by a 3-step process 1) Append any required profile-specific additional USE flags 2) Necessary profile-specific apps and/or libraries could be listed in sets in /etc/portage/sets 3) emerge --changed-use --deep --update @world The advantage to this approach is that we're not talking forks. This is pure Gentoo, with customizations that fall within the realm of regular Gentoo. If anybody has problems, they can go to generic Gentoo support forums/lists for help. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Last-rites: www-plugins/pipelight
On Tue, Jan 17, 2017 at 04:51:35AM -0800, Daniel Campbell wrote > On 01/10/2017 11:29 AM, NP-Hardass wrote: > > # NP-Hardass <np-hard...@gentoo.org> (19 Jan 2017) > > # Upstream has discontinued Pipelight and Firefox is in the process > > # of removing NPAPI support (which Pipelight relies upon), making > > # this obsolete. > > # Masked for removal in 30 days. > > www-plugins/pipelight > > > > > Would this work for Pale Moon by any chance? According to their webpage https://www.palemoon.org/roadmap.shtml NPAPI plug-ins are still supported. > Technology support > Pale Moon supports and will continue to support the following > features/technologies: > > * Full UI customization > * Full theming (complete themes) and lightweight theming (personas) > * XUL and XBL to build interfaces > * NPAPI plug-ins > * XPCOM binary components for extensions > * Overlay and bootstrapped extensions, including restartless ones > * Access to low-level APIs from extensions > * Pale Moon Sync (in the secure, time-tested Weave fashion) -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] bzipped manpages
On Wed, Jan 11, 2017 at 05:15:25PM +0100, Jan Stary wrote > On Jan 11 13:34:09, sven.e...@gmx.de wrote: > > Am Dienstag, 10. Januar 2017, 13:36:15 CET schrieb Jan Stary: > > > > You arguing that 40MB is nothing on modern systems (which, by the way is > > > > not exactly true, talking about embedded ones). > > > > > > Can you gove an example of an embedded system with manpages? > > > > My Raspberry Pi 3. ;-) > > How is that an embedded system? > It's a full blown linux installation. Not every "full blown linux installation" has a multi-terabyte hard drive attached. There are small laptops with SSDs instead of spinning disks. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Gcc 6 and Gcc 5 update
On Sun, Dec 11, 2016 at 06:59:17PM +0100, Magnus Granberg wrote > Hi > > Gcc 6.X update: > Gcc 6.3 will soon get released in one or two weeks on that the > pie use flag will get unmasked and gcj will be masked for java is > removed in gcc 7 Package that fail with the pie flag needed to get > fixed upstream for we are not the only dist that use it now days. > > Gcc 5.X update > Time to start fixing bugs [1] for it is time to mark it stable. > it will be 5.4 or 5.5. Any more bugs that need fixing that not in > the gcc 5 porting? > [1] https://bugs.gentoo.org/show_bug.cgi?id=536984 Are the gmp, mpc, mpfr, and isl libs included? According to the "Support libraries" section at https://gcc.gnu.org/wiki/InstallingGCC > Alternatively, after extracting the GCC source archive, simply > run the ./contrib/download_prerequisites script in the GCC source > directory. That will download the support libraries and create > symlinks, causing them to be built automatically as part of the GCC > build process. Set GRAPHITE_LOOP_OPT=no in the script if you want > to build GCC without ISL, which is only needed for the optional > Graphite loop optimizations. That approach guarantees that the appropriate library versions are available for the version of GCC that you're building. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Uppercase characters in package names
On Fri, Dec 02, 2016 at 09:49:59PM -0600, William Hubbs wrote > > So, should we clean up / rename packages that do not follow this as we > find them, like my ConfigArgParse example? find /usr/portage -name *.ebuild | grep [A-Z] | sed "s/-[0-9].*//" | sort -u > upper.txt ...gives 1814 *UNIQUE* packages, usually vith multiple ebuild versions for each package. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Commented packages in the @system set
On Thu, Oct 27, 2016 at 01:10:10AM +, Peter Stuge wrote > waltd...@waltdnes.org wrote: > > For a build-from-source distro like Gentoo, gcc and associated > > tools are a vital part of the distro. > > A stage4 created (and updated) on a catalyst build farm doesn't need > to have gcc, but may still need libstdc++. That just moves the requirement for gcc+tools to the catalyst build farm. OK, let's get specific... a *STANDALONE* Gentoo machine requires gcc+tools. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] git-r3: initial draft for review [v2]
On Mon, Sep 02, 2013 at 01:33:19PM +0200, Micha?? Górny wrote Dnia 2013-09-01, o godz. 16:49:34 William Hubbs willi...@gentoo.org napisa??(a): Please don't. I also do not want escape sequences in log files. Ok, '--color' removed. However, I think we should work something out to get both parties satisfied. Maybe portage feature or a tool to 'uncruft' logs from escape sequences since many people actually benefit from them. As per my bug https://bugs.gentoo.org/show_bug.cgi?id=463954 it is a pain. Try figuring out the following as viewed in mc (Midnight Commander)... WARN: prepare It seems that you need to set USE_PYTHON to make sure that legacy packages will be built with respect to PYTHON_TARGETS correctly: USE_PYTHON='.[35;1m2.7.[0m' Note that... grep foo bar.txt ...returns colour-highlighted text, while... grep foo bar.txt output.txt ...returns plain text. So it can be done properly for everybody. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs? (was: Re: [gentoo-dev] rfc: escape sequences in logs)
On Tue, Sep 03, 2013 at 10:25:19AM +0200, Ulrich Mueller wrote
Escape sequences have been designed for communication with peripheral
devices, not for markup or as a storage format.
Also future colorful display generally won't be portabe because
escape sequences depend on the setting of the TERM variable. (And
again, software that emits them with TERM=dumb or TERM unset is
broken.)
Similar to...
USE=foo bar emerge blah blah blah
...can the average user do something like...
TERM=dumb emerge blah blah blah
I don't believe very many users or admins babysit an entire 2 hour
emerge --deep --update @world session, hitting {CTRL-S} when some
colour pops up. In my case, I examine /var/log/portage/elog after the
emerge finishes, successfully or unsuccessfully. And I don't use an
editor to view log files. I use mc (Midnight Commander) which views
plain text, but doesn't decode ANSI. A nice feature of mc is that I can
sort the file list by various options. When looking at emerge output in
/var/log/portage/elog, I want to sort by file-modify-time, so I can
easily see which files were output in the most recent emerge run.
--
Walter Dnes waltd...@waltdnes.org
I don't run desktop environments; I run useful applications
Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs? (was: Re: [gentoo-dev] rfc: escape sequences in logs)
On Tue, Sep 03, 2013 at 10:15:39PM +0200, Tom Wijsman wrote That is not what this is about, this is about having escape sequences in build logs obtained from Bugzilla; because, they aid in skimming through logs (until we implement the feature I asked for in subject). The road to binary syslog files is paved with good intentions, or something like that. Question... why does it have to be escape sequences? Can't it be readable plain text? E.g. something like... //STDERR.OUT.START foo bar blah blah blah //STDERR.OUT.END This would be easy to grep and/or parse in bash. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On Tue, Sep 03, 2013 at 11:44:45PM +0200, Tom Wijsman wrote +1 I am still not convinced we are experiencing an actual practical problem for the majority of the build logs that are attached; we've been doing this for years, why is it so suddenly considered a problem? As I pointed out in a message to the previous thread... == WARN: prepare It seems that you need to set USE_PYTHON to make sure that legacy packages will be built with respect to PYTHON_TARGETS correctly: USE_PYTHON='.[35;1m2.7.[0m' == See https://bugs.gentoo.org/show_bug.cgi?id=463954 -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] rfc: stabilization policies
On Tue, Aug 20, 2013 at 04:12:45PM -0400, Michael Orlitzky wrote On 08/20/2013 02:19 PM, William Hubbs wrote: My question is, how can we improve our stabilization procedures/policies so we can convince people not to run production servers on ~arch and keep the stable tree more up to date? Just delete /etc/conf.d/net with an ~arch update every once in a while, that should convince them =) Stable is fine for the most part. The bitrot complaint is basically I can't be bothered to add packages to /etc/portage/package.accept_keywords individually. What he said. Most of our servers have one or two packages in there, for which I've already filed a stabilization bug. From a regular user POV, I occasionally have one or 2 packages that I keyword, because I want their specific feature; e.g. a ~ version of UFRAW that will read the RAW format from my new camera, which stable won't. I can see giving up on vanilla-sources kernels. See http://gentoo.2317880.n4.nabble.com/newsitem-Kernel-Team-vanilla-sources-policy-td266519.html Executive summary... the releases are so fast+furious, that keeping up with stabilization is not possible, so it'll always be ~. It sucks, but it's still better than running ~arch. Problems like this should be fixed, but if you decide it's easier to ACCEPT_KEYWORDS=~arch than deal with the exceptions, you're asking for trouble. Wise words. That level of laziness *ON A PRODUCTION SERVER* is unacceptable. Are there any other packages that get updated as often as vanilla sources? Maybe they should be considered for a similar policy. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: [gentoo-user] OpenRc-0.12 is coming soon
On Fri, Aug 16, 2013 at 12:46:34PM -0400, Rich Freeman wrote Also, it really isn't Gentoo-specific, but putting /etc in a git repo is a really good practice, and I'm wondering if it should go in the handbook as a result. For regular users, who won't be up to developer standards, maybe the wording should be a more generic make a backup copy of /etc. I also recommend backing up /var/lib, which contains iptables rules, alsa state, portage world, and other goodies. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 08, 2013 at 04:19:26PM -0700, Greg KH wrote On Thu, Aug 08, 2013 at 09:40:00PM +0100, Mike Auty wrote: On 08/08/13 11:38, Samuli Suominen wrote: i'm not volunteering but I never really got why our GNOME maintainers insisted on staying with it instead of going with the distribution after it was clear logind is a dead end on non-systemd systemd Ok, So there's lots of people that don't want systemd. Can't we group together and have some kind of an affect on upstream? Become upstream developers and create fixes to remove the dependancy either by working on openrc features to emulate the same things that systemd has that GNOME requires, or split things out of GNOME so that it does not require systemd dependencies. But to complain to upstream without providing patches is a bit futile, don't you think? That's not how open source projects work, we all know that. greg k-h -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 08, 2013 at 09:40:00PM +0100, Mike Auty wrote So there's lots of people that don't want systemd. Can't we group together and have some kind of an affect on upstream? The answer is... probably not, given the My way or the Highway attitude of the GNOME developers. GNOME users who are unhappy about systemd, are being forced to choose... * either they run GNU/Linu-x * or else they run GNOME/Lenna-x ...pick 1 of the above. Is there some way, we as the Gentoo Foundation, Developers or even just Users can form a petition, or an open letter, that might make enough impact on the Gnome foundation for them to reconsider their position? Again, no, they haven't listened to end users in the past, and they will not listen to end users now. Even more so if you're a Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy http://lalists.stanford.edu/lad/2009/06/0191.html Perhaps if there were an init system specification project, separate from systemd, that systemd had to adhere to rather than deciding to change the rules at a random version (like 205), then Gnome could potentially have other options than just systemd? Again, how do you force a rogue upstream development team to follow *YOUR* rules? Answer; you can't. If you want GNOME-like goodness, consider Cinnamon/Consort/Mate/Kate/etc/etc. I'm a neutral observer of this entire mess... see my sig. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 08, 2013 at 11:40:58AM -0400, Ian Stakenvicius wrote It may be pertinent for this reason (a smoother upgrade path) and this reason alone, to stabilize gnome-3.6 first -- just to get into gnome3 (and get gnome-2 removed) without having to also deal with the systemd migration at the same time. If you've followed the user mailing list, you'll know that I'm not exactly a systemd fanboi, and as per my sig, I don't have any stake in this battle. But if you want to do a 2-step switch to GNOME 3.8, then why not... 1) switch from openrc to systemd first 2) once you have that working, then worry about upgrading to GNOME 3.8 -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 09, 2013 at 11:16:37AM +0200, Tom Wijsman wrote Though, an init system standard might be the most promising approach. Ahemmm http://xkcd.com/927/ -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 09, 2013 at 08:27:23AM +0800, Patrick Lauer wrote What makes this situation so difficult is that it's not a single random package, but one of the bigger desktop environments that has painted itself into a corner. (Plus an uncooperative upstream, so all the blame gets thrown at the gentoo maintainers from both sides. Awesome way to destroy crew morale :) ) I don't think you realize what you're asking for. This is a lot more than just a few patches. You're effectively asking for fork of GNOME, just like eudev has forked from udev. GNOME forks already exist. Just off the top of my head... XFCE, Cinnamon, Consort, Mint, Mate, Kate, Unity, etc, etc. If you don't like GNOME, try one of them. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] renaming gentoo-oldnet
On Mon, Aug 05, 2013 at 10:09:54PM +, Robin H. Johnson wrote Naming goals: - Should describe what it does - Does NOT have a name conflict as verified by Google. - Does NOT imply OpenRC. - Implying Gentoo is fine, as it's where the package comes from. - Should drop 'old' Some suggestions, keying in on the fact that it's shellscript-based - netshell or netshellrc - shellnet or shellnetrc - bashnet or bashnetrc - ashnet or ashnetrc Note that the rc suffix does not imply OpenRC, e.g... [i660][waltdnes][~] ll /etc/*rc -rw-r--r-- 1 root root 1484 Jun 14 08:17 /etc/drirc -rw-r--r-- 1 root root 1304 Jul 27 20:30 /etc/eixrc -rw-r--r-- 1 root root 1855 Feb 14 2010 /etc/inputrc -rw-r--r-- 1 root root 125 May 13 09:27 /etc/mail.rc -rw-r--r-- 1 root root 8949 Jul 4 12:53 /etc/nanorc -rw-r--r-- 1 root root 77 Jun 14 04:11 /etc/procmailrc -rw-r--r-- 1 root root 4479 Jun 14 02:54 /etc/wgetrc -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Base profile changes should be announced/discussed on this list.
On Wed, Jul 31, 2013 at 08:21:20AM +0200, Michael Weber wrote Mostly everything is configurable, and revertable as user - granted. I'd like to see a announcement and an optional discussion on this list if base profile gets changed [0] - current case bug 449364 [1]. I'm not opposed to the specific change, or base system changes in general, but I don't like seeing them slip thru under the radar. Just have the honesty and brin gsuch changes to public. [In this case] having an working mouse copy'n'paste eases the way from stage3 to a set up X server, X server tends to break, and it doesn't collide with X anymore. So it only needs 1MB data [2], which is very usefull editing stage3 with it's default editor - nano. I see the point that's it's useless on headless virtual boxes. my 2 cents. Hold on a minute. There is a *MAJOR* difference between gpm the USE flag, and sys-libs/gpm the mouse server. I'm one of those weird guys who starts USE with -*. And I do not have gpm the USE flag enabled. I do, however, have sys-libs/gpm running just fine, thank you, minus the gpm flag. I can assure you that gpm works just fine during the install, even without the gpm flag. I see the point that's it's useless on headless virtual boxes Actually, if you ssh into the virtual box from a text console, it still works. If there was a move afoot to remove sys-libs/gpm from the install ISO, I would be part of the crowd up in arms about this. But that's totally a separate item from the USE flag. Since I've never used the gpm USE flag, I have to ask... what additional goodies does USE=gpm bring to the table? How exactly, does it improve things beyond the basic sys-libs/gpm? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Base profile changes should be announced/discussed on this list.
On Wed, Jul 31, 2013 at 12:58:37PM +0200, Michael Weber wrote On 07/31/2013 11:53 AM, Walter Dnes wrote: Hold on a minute. There is a *MAJOR* difference between gpm the USE flag, and sys-libs/gpm the mouse server. [...] If there was a move afoot to remove sys-libs/gpm from the install ISO, I would be part of the crowd up in arms about this. It does affect the presence of sys-libs/gpm in stage3 tarballs. It gets pulled into stage3 via sys-libs/ncurses[gpm] [1]. Which will no longer be the case, since sys-libs/gpm is not in @system. About additional effects, see [2]. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-libs/ncurses/ncurses-5.9-r2.ebuild?revision=1.17view=markup [2] michael@x catalyst 1 % equery hasuse gpm * Searching for USE flag gpm ... [IP-] [ ] app-editors/emacs-24.3-r2:24 [IP-] [ ] app-editors/gvim-7.3.1214:0 [IP-] [ ] app-editors/vim-7.3.1214:0 [IP-] [ ] app-misc/mc-4.8.7:0 [IP-] [ ] media-libs/aalib-1.4_rc5:0 [IP-] [ ] sys-libs/ncurses-5.9-r2:5 [IP-] [ ] www-client/elinks-0.12_pre5-r2:0 [IP-] [ ] www-client/links-2.7:2 [IP-] [ ] www-client/w3m-0.5.3-r1:0 -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Base profile changes should be announced/discussed on this list.
On Wed, Jul 31, 2013 at 12:58:37PM +0200, Michael Weber wrote On 07/31/2013 11:53 AM, Walter Dnes wrote: Hold on a minute. There is a *MAJOR* difference between gpm the USE flag, and sys-libs/gpm the mouse server. [...] If there was a move afoot to remove sys-libs/gpm from the install ISO, I would be part of the crowd up in arms about this. It does affect the presence of sys-libs/gpm in stage3 tarballs. It gets pulled into stage3 via sys-libs/ncurses[gpm] [1]. Which will no longer be the case, since sys-libs/gpm is not in @system. Arrrgh; I apologize for that fumble-fingers moment. I think I just sent an unfinished message. What I was going to say was that gpm appears to be active on the minimal install ISO. That comes before the stage tarball. Or is the proposal to remove gpm altogether from the install ISO? I would be unhappy with that, to say the least. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] s/disk space/drive space
On Tue, Jul 30, 2013 at 10:00:26PM +0200, Jeroen Roovers wrote On Tue, 30 Jul 2013 10:53:11 -0400 Rich Freeman ri...@gentoo.org wrote: On Tue, Jul 30, 2013 at 10:40 AM, viv...@gmail.com viv...@gmail.com wrote: does storage space make everyone happy? rich0 is confused and looks over at the storage space he keeps his bicycles in... So what colour would your storage space be? I think mauve has the most ram http://dilbert.com/strips/comic/1995-11-17/ -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-dev] PYTHON flags grammar? why?
On Sat, Jul 27, 2013 at 09:59:38AM +0200, Ulrich Mueller wrote On Sat, 27 Jul 2013, Leho Kraav wrote: php5-5 vs python2_7 Why, how did that happen? Using the hyphen is cleaner, because the underscore is used as the separator for USE_EXPAND. (OTOH, as long a nobody will introduce a PYTHON_TARGETS_PYTHON2 variable, python2_7 will also work fine.) Out of sheer curiousity, why does make.conf need all 3 of... PYTHON_SINGLE_TARGET=python2_7 PYTHON_TARGETS=python2_7 USE_PYTHON=2.7 -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Wed, Jul 03, 2013 at 02:42:56PM +0200, Tom Wijsman wrote With USE=-experimental (which will be the default) they are excluded by default, after enabling that the user can exclude patches by setting UNIPATCH_EXCLUDE through the package.env mechanism. Here's my user, not-a-developer, perspective. I think that there should be a mechanism to enable one patch at a time. Here's the rationale... Assume that there are 50 different patches available. I may want/need features provided by 1 of those patches. I probably do *NOT* want to enable the other 49 patches. This is similar in concept to enabling one ~amd64 ebuild, versus globally enabling ~amd64. Even if I can come up with the list of the 49 patches to exclude, what happens when the next developer comes along with patch #51? Does it get applied next time I build a kernel (ouch)? IANAD (I Am Not A Developer), but if I did want to apply custom patches, I think the right approach would be to somewhere manually modify UNIPATCH_LIST. If that approach won't work, maybe a USE_EXPAND flag make.conf might be the way to go. E.g. CUSTOM_PATCH=foo bar would resolve to USE=custom_patch_foo custom_patch_bar -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Re: eselect init
On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote - eselect init will be opt-in ***FOR THE TIME BEING***, people can be left on their own tools if the want it This statement should bring the same reaction as the posting that udev source was being rolled into the systemd tarball. It implies that eselect init will eventually become mandatory. Your situation is a special use-case, i.e. a developer who wants to switch between a production init system, and a test init system, possibly multiple times a day. You're a developer, you know which files to change, put together your own scripts, and run them as necessary. Set up your own overlay and write your own eselect init ebuild. No problem. But why should this eventually be a part of mainstream Gentoo? BTW, I'm a bigger fan of busybox than most Gentoo users. Remember the announcement of systemd/udev tarball integration, and supposed deprecation of a separate /usr? I was the -disturber who started up the https://wiki.gentoo.org/wiki/Mdev wiki page on how to replace udev with mdev. I also did a page on automounting at... https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount Having said that, I don't see how busybox development justifies an additional layer of complexity for everybody's bootup. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 10:52:49AM +0200, Tom Wijsman wrote On Wed, 29 May 2013 00:36:58 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: 3b) Except... at that point root isn't writable Let me stop you here. Does it need to be writable at that point? We're reading the path of the init file to boot from a file, we start the executable at that path; no writes are involved here. The only problem left here is that some init systems need a specific version of the inittab file, although this can likely be changed in late shutdown as the only exception to this approach. In order for a different init system to come up, some file(s) somewhere *MUST* be different, no ifs/ands/ors/buts. The problem with an eselect approach is that it's like asking a brain surgeon to operate on himself. The proper procedure is to have another brain surgeon operate on him while the patient is under anesthesia. It sounds very feasible for init systems that are an exception to just being able to switch init alone or have conflicting files to fix up whatever is inconsistent; either by scheduling changes till when the disk is writable, or by doing it on shutdown... But it occurred to me that we actually do have a demonstrated workable and long used in actual practice exception to the normal boot case as precedent, where such maintenance tasks traditionally occur, single user mode. Iff nothing else is feasible enough, this makes a lot of sense to me. There are a couple of other possible approaches... 1) If the 2 systems can achieve peacefull co-existance (i.e. no identically-named files with different contents) then simply have 2 boot entries in /etc/lilo.conf (or grub equivalant)... append = init=/etc/foo append = init=/etc/bar ...and select whichever one you want from the boot menu. This guarantees a) the system shuts down properly with the old init b) the system starts up properly with the new init c) if the new files are incorrect/unbootable, you can simply reboot to the old version and try to figure out what went wrong [initr* SNIP] Having an initr* as a requirement for being able to switch init system is maybe a bit too much to ask; same as above, iff nothing else ... 2) We already have such a solution; it's called the Gentoo minimal install ISO. If the 2 init systems conflict over identically-named files, I strongly recommend that the changes be done while booted from a gentoo minimal install ISO. This guarantees a) the system shuts down properly with the old init b) the system starts up properly with the new init c) if the new files are incorrect/unbootable, you can simply chroot into the machine and send pleas for help to the Gentoo user mailing list ;) -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote Walter Dnes waltd...@waltdnes.org wrote: In order for a different init system to come up, some file(s) somewhere *MUST* be different, no ifs/ands/ors/buts. How true is this in general? It is usually only a change of the init parameter. Where is the init parameter changed? Even if it's only the append line in /etc/lilo.conf, my above statement still holds true. If you've got two identical machines with byte-identical hard drives, they can not boot two different OS's or init systems. The problem with an eselect approach is that it's like asking a brain surgeon to operate on himself. eselect and wrappers don't operate on themselves, please elaborate. The operating system is changing itself. [SNIP to shorten mail] Users can already do this, this isn't a solution. [SNIP to shorten mail] Again: Users can already do this, this isn't a solution. See above... If users can already do it themselves, then why this entire thread? Why do we need eselect/whatever? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Switchup-mode and boottime selector? Was: eselect init
these scripts, and I'd envision people writing extension scripts for all sorts of additional functionality. Backups while the system is quiesced? Hook for boot-chart and similar modes? A fast-boot special media-player mode? Something else exotic in mind? No problem! Hack up a special purpose switchup-mode script for it, and the world's your oyster! I think you've just re-invented the bootloader (lilo/grub). It can boot Gentoo, Fedora, BSD, any special-purpose kernel you wish, and even Windows 7 for that matter. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-dev] Separate boot/root already [WAS: eselect init]
On Mon, May 27, 2013 at 01:47:49AM +0200, Luca Barbato wrote Yes, I tested it first and got the whole system unworkable, one single mode later I baked something to get at least the minimal functionality, supporting our xdm script properly required some more effort I hadn't time to pour that day. People who want to try something different in distros, without irrevocably switching over, normally have a separate partition. This is beginning to look like the simplest, least error-prone approach, even if it is heavy-ganded. Out of sheer curiosity... is bb-init based on busybox? If so, a separate partition would also prevent standard utilities from stomping all over their busybox symlink equivalants. Add another entry to the grub/lilo menu, and boot from that. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] eselect init
On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote On Sat, 25 May 2013 12:25:03 +0200 Peter Stuge pe...@stuge.se wrote: I would actually expect the change to take effect immediately. Then how would you be able to shutdown / reboot your system in a clean way? The premise here is that when you boot with an init system you must shutdown with that same init system, you can't just start one init system and expect the other init system to cleanly shut down its services. Therefore implementing this would either be unclean or way to complex. From all the methods discussed doing it on boot sounds the most sane. It has to be done *VERY* early at boot, or else we're back to the problem you described above. It's almost like a brain surgeon operating on himself. Here are a couple of outside the box ideas that haven't been mentioned yet... 1) boot into single mode before doing the changeover. Both grub and lilo support single mode boot as per... http://www.gentoo-wiki.info/TIP_Booting_into_single_user_mode 2) have the setup/switchover mechanism built into the Gentoo minimal install ISO. The advantage here is that if the system ends up no longer bootable off the harddrive, you can still boot from the ISO, chroot into the system on the harddrive, and send emails to the gentoo-user list asking for help G. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
On Wed, May 22, 2013 at 11:42:08AM -0700, Zac Medico wrote It will require portage to be able to predict where the units are installed, and also be able to avoid accidentally wiping out anything else that may be installed nearby. The prediction issue also comes up in this bug which requests a 'dounit' ebuild helper: https://bugs.gentoo.org/show_bug.cgi?id=469086 Maybe the package manager should query the unit location from pkg-config? I think this is the wrong algorithm... i.e. asking where files of type X are installed, and wreaking havoc in in that location. I think that it would be more robust for the installer to decide which files are of type X, and not install them in the first place. This approach does not risk wiping files from another program in the same directory. And preventative action is generally better than cleaning up after the fact. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
On Fri, May 17, 2013 at 10:45:18PM -0500, William Hubbs wrote No one is arguing against that. All this thread is about is making systemd a first-class citizen, like OpenRC/Sysvinit, so it will be as smooth as possible for someone who wants to switch between the two. It seems that some of the proposals are crossing the line to make systemd first-class and openrc second-class. *THAT* is what's causing the complaints. The best analogy I can think of is the more extreme type of affirmative action that effectively amounts to racial discrimination against white people. The pro-systemd group here is advocating double-standards... 1) http://www.gossamer-threads.com/lists/gentoo/dev/272180?do=post_view_threaded Having a package to install every systemd unit in existence just clutters the end user's system and makes it harder to tell which units are actually valid. Yet openrc users are supposed to accept having their systems cluttered with systemd units. 2) I suggested keying on a systemd USE flag, to inform portage whether or not to install systemd units. I was told that https://bugs.gentoo.org/show_bug.cgi?id=198901 forbade using it that way. And therefore systemd config files would be installed regardless of flags. Therefore udev/eudev don't have systemd flags. But both have openrc flags, and will not run OK on an openrc machine without the openrc flag. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: CPU use flag detection
On Sat, May 18, 2013 at 12:14:35PM -0700, Matt Turner wrote The particularly annoying thing about using them is that there's no -mmmx2 or -mmmxext... Now that you mention it... [i660][waltdnes][~] grep mmxext /usr/portage/profiles/use.local.desc media-libs/libpostproc:mmxext - Enable mmx2 support. media-plugins/vdr-softdevice:mmxext - enables MMXExt support media-video/ffmpeg:mmxext - Enables mmx2 support media-video/libav:mmxext - Enable mmx2 support. media-video/mplayer:mmxext - Enables mmx2 support media-video/mplayer2:mmxext - Enables mmx2 support x11-libs/pixman:mmxext - Enable MMX2 support. ...shouldn't mmxext be moved out of use.local.desc into use.desc? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 08, 2013 at 11:49:18PM +0800, Ben de Groot wrote And I believe the council has only spoken out against using a useflag for installing such files. Afaik they haven't spoken out against a systemd-units package. Please refer me to their decision if I'm wrong. Wouldn't the systemd USE flag be the appropriate one to key on? The description in /usr/portage/profiles/use.desc says... systemd - Enable use of systemd-specific libraries and features like socket activation or session tracking Surely, units files qualify as systemd-specific features. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 08, 2013 at 10:31:21PM +0530, Arun Raghavan wrote The overhead of the files' presence is trivial, and most users won't care. Those who do care have a trivial line to add in make.conf, and that is for the small number of people who share your vitriol for the systemd project. Then howsabout a units ebuild that installs all available units files for systemd users? The overhead of the files' presence is trivial, and most systemd users won't care. The thread title says it all... normal Gentoo users don't use systemd. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] GNOME migrating from GConf to GSettings; effects on Gentoo?
On Wed, May 01, 2013 at 12:10:33AM -0400, Alexandre Rostovtsev wrote On Tue, 2013-04-30 at 23:26 -0400, Walter Dnes wrote: On Tue, Apr 30, 2013 at 11:17:35PM -0400, Alexandre Rostovtsev wrote It impacts users who use stable keywords and are therefore stuck with GNOME-2.32. The workaround is for affected users to switch to ~arch keywords (note that GNOME-3.x ebuilds in ~arch get vastly more care and attention from us than the theoretically stable GNOME-2.32). And the real solution is to finally stabilize some release of GNOME-3.x Thanks for the info. I didn't realize that stable was that far behind. Now to see how much I have to keyword. If you want a ready-to-use package.keywords file for GNOME 3, we have one in the gnome overlay that is reasonably well-maintained: http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=blob;f=status/portage-configs/package.keywords.gnome3 I think I just realized what this means. I run ICEWM, not GNOME. GNUMERIC and ABIWORWD and GIMP are the 3 GNOME apps that I use a lot. Do I have to emerge GNOME-BASE in it's entirety just to get GSettings working? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] GNOME migrating from GConf to GSettings; effects on Gentoo?
On Wed, May 01, 2013 at 09:22:56AM -0400, Alexandre Rostovtsev wrote On Wed, 2013-05-01 at 04:19 -0400, Walter Dnes wrote: I think I just realized what this means. I run ICEWM, not GNOME. GNUMERIC and ABIWORWD and GIMP are the 3 GNOME apps that I use a lot. Do I have to emerge GNOME-BASE in it's entirety just to get GSettings working? Then I misunderstood. I thought that you were running GNOME-2.32 and were complaining that while 2.32-era programs like epiphany-2.32, gnome-control-center-2.32, etc. expect all their settings to be stored in gconf, modern programs or libraries designed for GNOME-3 expect these settings to be stored in gsettings, which results in inconsistencies and strange behavior. But if you are running IceWM, this should not be a problem. To get gsettings working, you only need 4 things: dbus, glib, dconf, and gsettings-desktop-schemas. And the latest stable versions of them would be sufficient. Thank you very much. This will be helpful on my netbook (2 gigs ram and Intel Atom processor). Gnome 3.x would be too much for it to run. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] GNOME migrating from GConf to GSettings; effects on Gentoo?
On Tue, Apr 30, 2013 at 11:17:35PM -0400, Alexandre Rostovtsev wrote It impacts users who use stable keywords and are therefore stuck with GNOME-2.32. The workaround is for affected users to switch to ~arch keywords (note that GNOME-3.x ebuilds in ~arch get vastly more care and attention from us than the theoretically stable GNOME-2.32). And the real solution is to finally stabilize some release of GNOME-3.x Thanks for the info. I didn't realize that stable was that far behind. Now to see how much I have to keyword. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 04:45:50PM +0200, Samuli Suominen wrote Those 70-* and 80-* are in udev pkg_postinst, this news item, everywhere... can all 3 be deleted if you haven't modified them yourself. So that leaves one... local.rules... dunno about that. I'm curious. One paragraph you should add to the news item is... === Users who change interface names will need to search, as root, for references to eth[0-9] in their config files. Then they will have to change the config files to reflect the new names. At least the following search is suggested... grep -rl eth[0-9] /etc /var/lib Also any custom firewall/routing/network scripts in other locations should be searched for references to eth[0-9]. === -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On Fri, Mar 29, 2013 at 01:38:03PM -0400, Rich Freeman wrote On Fri, Mar 29, 2013 at 12:40 PM, Markos Chandras hwoar...@gentoo.org wrote: In my mind, the message says either remove 70-* and setup 80-* or your system will end up broken. The other bit is that modifying symlinks in /etc/init.d is only mentioned in passing. That is a VERY important step unless your new name happens to be the same as your old one, otherwise on the next boot the system will not have a working network interface, which will hamper efforts to fix for casual/new users, and cause real trouble for those doing remote administration (though anybody doing anything serious on a remotely-administered box should have some kind of console-level access outside of the OS - like serial console or iLO/etc support). That's only the beginning for the necessary changes. I'm running mdev on this machine, so it won't affect me, but here goes... [d531][root][~] grep -rl eth[0-9] /etc/* /etc/conf.d/net /etc/conf.d/network /etc/conf.d/netmount /etc/dosemu/dosemu.conf /etc/hibernate/common.conf /etc/rc.conf I've eliminated some specific stuff that only I do. * /etc/conf.d/net Is going to have to be modified by users. * I believe /etc/conf.d/network is a doc file for /etc/conf.d/net. * /etc/conf.d/netmount Who changes that? * /etc/dosemu/dosemu.conf It's an app, but may require changes. * /etc/hibernate/common.conf It's an app, but may require changes. * /etc/rc.conf Is going to have to be modified by users. Fun for users, and app upstreams. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] New install isos needed
On Sat, Mar 23, 2013 at 04:11:14PM -0400, Michael Orlitzky wrote -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/23/2013 02:50 PM, Pacho Ramos wrote: El sáb, 23-03-2013 a las 14:40 -0400, Rick Zero_Chaos Farina escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/23/2013 02:06 PM, Pacho Ramos wrote: Today I tried to boot latest install ISO (from January) and hit this bug: https://bugs.gentoo.org/show_bug.cgi?id=455924 This breaks a lot of hardware requiring firmwares (like some wireless drivers) Could a new ISO set be released? Based on my recent testing it seems that amd64 builds are working properly, however, the x86 ones are still missing firmware. no idea how that is happening, maybe it's just me. $0.02 I have tried this morning install-amd64-minimal-20130110.iso (the last version offered) and it is affected by that bug report :/ See also: https://bugs.gentoo.org/show_bug.cgi?id=377865 The installation media has been totally useless on a large bit of hardware for over three months. We should just suggest SystemRescueCD if no one can be bothered to make Gentoo installable. The net-setup utility on the install seems to have problems with anything out of the ordinary. e.g. https://bugs.gentoo.org/show_bug.cgi?id=447110 I an issue, too. I took the minimal install CD and ran isohybrid on it. My netbook doesn't have a CD or DVD drive, so I *HAVE TO* use a USB stick. I tried to set up my netbook as... IP address 192.168.123.252 netmask 255.255.255.248 (YES!) broadcast 192.168.123.255 default gateway 192.168.123.254 It failed, and I ended up with an address in the 169.254.xxx.xxx range. Typing in the manual ifconfig and route commands worked, so I went on and ignored the problem. A newer Gentoo user, e.g. me a few years ago, might have given up. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Tue, Mar 05, 2013 at 04:47:09PM +0800, Greg KH wrote On Tue, Mar 05, 2013 at 02:01:31AM -0500, Walter Dnes wrote: On Mon, Mar 04, 2013 at 03:44:33PM -0100, Carlos Silva wrote On Mon, Mar 4, 2013 at 3:28 PM, Walter Dnes waltd...@waltdnes.org wrote: I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim Just read this file and you'll have the answer: /usr/src/linux/Documentation/stable_api_nonsense.txt Thanks. That was an eye-opener. If user-space drivers are really that slow, we may as well stick with VESA as a fallback. Ok, I'll bite, What do you mean by that? Where does the stable_api_nonsense.txt file talk about userspace drivers? greg I wrote that file k-h My statement was a general response to the entire thread. Sorry, I should've retitled it [REDUX whatever] * stable_api_nonsense.txt explained lack of a stable *KERNEL* api * Duncan's message talked about slow *USERSPACE* API... Of course it's possible to implement a userspace driver that wouldn't have the same issues as it'd use the stable userspace API, but that's generally accepted to be far too high a performance cost for graphics drivers, regardless of the kernel involved (MS tried it too for stability reasons and gave up at the performance penalty they were taking). So between your file, and Duncan's message, I saw that... 1) a stable kernel API is not possible 2) a userspace API is too slow. I apologize again for the vagueness in my previous reply. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Sun, Mar 03, 2013 at 10:48:07PM -0500, Rick Zero_Chaos Farina wrote I am sorry that this package has been such a headache for you, unfortunately binary drivers (especially) are often like that. Thanks for all your hard work keeping this usable. I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Mon, Mar 04, 2013 at 03:44:33PM -0100, Carlos Silva wrote On Mon, Mar 4, 2013 at 3:28 PM, Walter Dnes waltd...@waltdnes.org wrote: I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim Just read this file and you'll have the answer: /usr/src/linux/Documentation/stable_api_nonsense.txt Thanks. That was an eye-opener. If user-space drivers are really that slow, we may as well stick with VESA as a fallback. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: How a proper server profile should look like
On Tue, Jan 22, 2013 at 02:06:29PM +0100, Alexander Berntsen wrote As a long-time user, I can't put myself in a first-time user's frame of reference. But it would be useful for me whenever I'm installing Gentoo on a new device, if I were able to have the profile's USE-flags listed. (I know I can find them elsewhere, but it would still be convenient for me.) Maybe a note in the install docs to run... emerge --info | grep ^USE -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: How a proper server profile should look like
On Mon, Jan 21, 2013 at 11:51:54AM -0600, Dustin C. Hatch wrote The package defaults have gotten out of hand, in my opinion. I use default/linux/amd64/10.0 on all my machines and my /etc/portage/package.use directories have dozens of -flag entries for packages with ridiculous defaults, and almost none that come from the profile. I'm considering removing pkginternal from USE_ORDER. Have you heard the old joke about how an elephant is actually a mouse designed by a committee? The same thing applies to distro bloat. Some people want feature A, others want feature B, and others want feature C. The final result is a distro with features A *AND* B *AND* C. I was originally drawn to Gentoo with the Gentoo Ricer atitude. But now it's the fine-grained control of USE flags that makes me stay with Gentoo. I think we may have to admit that one size does not fit all. There are just too many individual scenarios. A truly minimal build should be sufficient to boot to a text console, and have networking and portage to be able to build further up the chain. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: How a proper server profile should look like
On Mon, Jan 21, 2013 at 02:28:47PM -0500, Rich Freeman wrote On Mon, Jan 21, 2013 at 12:51 PM, Dustin C. Hatch admiraln...@gmail.com wrote: The package defaults have gotten out of hand, in my opinion. I use default/linux/amd64/10.0 on all my machines and my /etc/portage/package.use directories have dozens of -flag entries for packages with ridiculous defaults, and almost none that come from the profile. I'm considering removing pkginternal from USE_ORDER. And this is the problem with having the default profile be really minimal. It just moves the problem into per-package defaults that are much more painful to override. I don't think changing the profile is the solution. I doubt that dozens of maintainers will immediately unset unwanted default USE flags simply because the default profile is made more bloated. As I mentioned in a previous message, my personal experience is that it's actually less work to start with -*, and add as required, rather than to use defaults and then hack and slash at the unwanted stuff. Mind you, as per my sig, I run ICEWM and leave the extra ram for useful applications. We may simply have to admit that we can't please everybody. I suggest a minimal profile instead. It would boot to a text console, and have networking and portage, allowing you to build further. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
On Thu, Jan 17, 2013 at 07:09:29AM -0500, Michael Mol wrote On Jan 17, 2013 3:35 AM, Dirkjan Ochtman d...@gentoo.org wrote: On Thu, Jan 17, 2013 at 3:23 AM, Walter Dnes waltd...@waltdnes.org wrote: If someone wants a *REALLY* basic system, they can start off with USE=-* and add on stuff as necessary when portage complains and/or ebuilds break. That's what I'd recommend to someone wanting to set up a basic server machine. Yeah, but that sucks with USE_EXPAND. For example, I sure want some version of Python installed, but setting USE=-* removes all support for Python versions and has me add them one by one. I guess I could do that, but now I always have to keep up to date myself, which sucks. My thought is that base should have just enough enabled for stage3 to be self-hosting. Moving existing base to something like common would retain a profile for that most people would want this set. On a lark, I once tried the default/linux/x86/10.0 profile for a re-install on my netbook without -*. I soon ended up with more - entries in make.conf and package.use, than I have add-on entries when using -*. And I was only half-way through installing the apps I normally use. I went back to -*. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
On Thu, Jan 17, 2013 at 12:59:11AM +0100, Andreas K. Huettel wrote Sure a server is something generic, too. However, since you mentioned mysql above, how about a postgres server? Or a web server using a daemon different from apache? :) This is why I think (as others) a server profile should basically be the same as a minimal profile. And then, defining a minimal profile separate from the base profile does not make too much sense. Rather, carefully try to move all specific stuff out of the base profile. If someone wants a *REALLY* basic system, they can start off with USE=-* and add on stuff as necessary when portage complains and/or ebuilds break. That's what I'd recommend to someone wanting to set up a basic server machine. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-dev] USE flag suid in both use.desc and use.local.desc
Moving USE flags from local to global status is frequently discussed here, so this seems to be the right forum to raise the issue... [d531][waltdnes][~] grep suid /usr/portage/profiles/use.desc suid - Enable setuid root program, with potential security risks [d531][waltdnes][~] grep :suid /usr/portage/profiles/use.local.desc net-analyzer/nagios-plugins:suid - Give root privileges to the ICMP, DHCP and IDE S.M.A.R.T. check binaries. This allows them to ignore the access controls that would disallow the nagios user from running the check. net-wireless/kismet:suid - Install a setuid root helper binary with limited functionality; this allows running kismet as a normal user, significantly reducing security risks BTW, I would've appreciated a headsup (news item) on Xorg getting the suid USE flag. I use startx, and I couldn't start X G. Fortunately, that was on my netbook, and I was able to Google the solution on my desktop machine... http://en.spontex.org/forum/thread/561/1/ I'm posting a heads up on the user list. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Defaulting for debug information in profiles
On Mon, Dec 17, 2012 at 01:37:27PM +0100, Sven Eden wrote
1) --- kde-base/kate
-
Compiled with -ggdb in CFLAGS:
# sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
32652140
Compiled with -g in CFLAGS:
# sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
32652140
Result: No size change at all.
2) --- dev-libs/lzo
-
Compiled with -ggdb in CFLAGS:
# sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
558664
Compiled with -g in CFLAGS:
# sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
558304
Result: A difference of 260 bytes or 0.06%. Far away from the assumed 300%.
Conclusion:
I do not doubt that -ggdb adds size. It does. And maybe, if I did an emerge
-e
@world would reduce the size used on my system between 30% and 40%. But not
about 66% like assumed.
However, even if it where around 5-6 G, it would be thrice the initial
assumption of 2G. And that's the whole point.
On my 32-bit machines I have...
FLAGS=-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
-fno-unwind-tables -fno-asynchronous-unwind-tables
CXXFLAGS=${CFLAGS}
See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
include -fno-unwind-tables -fno-asynchronous-unwind-tables. Would I
have to rebuild system and world without...
-fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
...to have debug data available?
--
Walter Dnes waltd...@waltdnes.org
I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: eudev project announcement
On Sat, Dec 15, 2012 at 07:21:21AM +, Duncan wrote Walter Dnes posted on Sat, 15 Dec 2012 01:33:04 -0500 as excerpted: [Udev-systemd has] essentially announced ahead of time that most bugs from non-systemd users would be closed with WONTFIX. Agreed, to this point. Actually, for political reasons, I hope that eudev does submit a bunch bugs+patches, and gets them rejected. Then whenever anyone complains about not sharing code, show them a bunch of WONTFIX emails from systemd/udev maintainers. This attitude is and the described events would be... unfortunate. For the reasons you list, I don't believe people should be /surprised/ if many such bugs+patches are rejected after submission, but that wouldn't make it any less unfortunate, and IMO, hoping they DO get rejected is the wrong attitude to have. I should've been clearer in my email, rather than a train-of-thought approach... 1) For appearance's sake and to make our position better in outsiders' view, I *HOPE* that eudev developers are co-operative in regards to sharing patches with systemd/udev. 2) Given past history, I *EXPECT* at least some bugs to be resolved by the systemd/udev developers as WONTFIX. It was their attitude that led to eudev in the first place. Here's a brief overview of why I think that eudev (or equivalant) is necessary... * Lennart Poettering wrote systemd * systemd will not run on machines with a separate /usr, and no initramfs. * Some people say that's because systemd is broken. Lennart says that machines systemd won't run on are broken. * That's getting into holy war territory. If it had remained strictly a Redhat-ism, we wouldn't be arguing the issue today. * The udevd tarball got merged into the systemd tarball, in order to share common code. That's when the fruit of the cow-pasture hit the fan. * Inheriting code from from systemd meant inheriting any restrictions that code had... e.g. not supporting separate /usr without initramfs That's just now. What other systemd-related restrictions/dependancies will be eventually rammed down the throats of non-users of systemd? eudev is a declaration of independance for non-systemd users. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: eudev project announcement
On Sat, Dec 15, 2012 at 07:07:09PM +0100, Micha?? G??rny wrote Waaait, what? Did something change lately or are you just repeating the same bullshit for months? Older systemd boots OK with a separate /usr and eudev. But somehow, somewhere along the line, as part of the merge, the udev portion of the systemd tarball requires initramfs. See news item... http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=36326;list=gentoo It was actually finally released 2012-03-16. If you disagree with that news item, complain directly to its author. If you can boot a udev-181 or higher system with a separate /usr, and no intrd/initramfs, I'm sure a lot of people would be very interested in knowing how. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] eudev project announcement
On Sat, Dec 15, 2012 at 05:16:48AM +0100, Peter Stuge wrote I hope that eudev wants to do the respectable thing for any fork, ie. work hard to minimize the amount of wasted effort in both projects by sharing much code and bugfixes. That would be nice if systemd/udev upstream was agreeable. On the other hand, if the systemd/udev maintainers had accepted bug reports (WONTFIX is not acceptance) and had accepted proposed patches, there wouldn't have been a need for the eudev fork in the first place. Lennart Poettering has admitted systemd's outright hostility to to standalone udev... http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html Well, we intent to continue to make it possible to run udevd outside of systemd. But that's about it. We will ***NOT POLISH THAT, OR ADD NEW FEATURES*** to that or anything. OTOH we do polish behaviour of udev when used *within* systemd however, and that's our primary focus. And what we will ***CERTAINLY NOT DO IS COMPROMISE THE UNIFORM INTEGRATION INTO SYSTEMD FOR SOME COSMETIC IMPROVEMENTS FOR NON-SYSTEMD SYSTEMS***. (Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.) They've essentially announced ahead of time that most bugs from non-systemd users would be closed with WONTFIX. Actually, for political reasons, I hope that eudev does submit a bunch bugs+patches, and gets them rejected. Then whenever anyone complains about not sharing code, show them a bunch of WONTFIX emails from systemd/udev maintainers. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] borked release media
On Sat, Dec 08, 2012 at 11:57:13PM -0500, Fernando Reyes wrote iirc the minimal install CD ISO is capable of booting from a USB device or any removable media by just running the following commands. # isohybrid image.ISO # did if=image.ISO of=/dev/sdb bs=8192k sdb being your removable device. Also keep in mind that any data on sdb will be wiped after running the dd command. Thanks. Much easier than the instructions on the Gentoo wiki. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] borked release media
On Sun, Dec 09, 2012 at 06:37:56PM -0800, Greg KH wrote Not necessarily, as I'm finding out with real hardware. My only options on the box I have is to either zero out all keys, or specifically tell the BIOS what binary to run (doesn't need to be signed, and can not be changed after telling the BIOS to use it.) Howsabout the binary being Matthew Garret's chainloader shim as per http://mjg59.dreamwidth.org/20303.html I'm working with others to see if we can programatically add keys, which we should, and if so we will offer the code up to do so (it's published already, we are working on getting it signed by the needed Microsoft keys right now.) He's already done the heavy lifting. Aren't you re-inventing the wheel? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] borked release media
On Fri, Dec 07, 2012 at 08:55:04PM -0800, Pawe?? Hajdan, Jr. wrote The serious problem here is that we need *new* users. A non-working install CD is a really bad thing here, don't you think? ;-) While we're at it, can we please also make a USB-key install ISO? I'm not asking merely because other distros do it. I'm asking because the situation has changed in the past half-dozen years. Back in 2005 or 2006, almost all machines had a CD and/or DVD, and many older PC BIOSes did not allow for booting from a USB key. Fast-forward to 2012 (and soon 2013) and... * just about every PC is capable of booting from USB * quite a few netbooks/notebooks do not have a CD or DVD drive. E.g. I had to boot from a Knoppix USB key as my working environment to do the initial portion of the Gentoo install on my netbook. Yes, I'm aware of http://www.gentoo.org/doc/en/liveusb.xml, but even I have occasionally fouled up those intructions. It doesn't exactly encourage new Gentoo users to have to go through that tap-dance. Arch linux https://wiki.archlinux.org/index.php/USB_Installation_Media manages to have a dual-bootable (CD / USB-key) image as a standard feature. In addition to installation, it would make the base of a good system rescue utility. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
On Sun, Dec 02, 2012 at 11:16:16PM +0100, Pacho Ramos wrote Maybe the easiest option would be to keep current defaults and simply include a news item when libreoffice starts to pull in openldap on a lot of systems remembering admins that they can safely enable minimal USE flag for openldap if they won't use server capabilities Howsabout following the same protocol as with CXX/NOCXX? In the past, portage would pick a default if neither was specified. That was changed to require a value, or else portage came to a screeching halt and spit out a message telling you that you have to set one of them. Set up 2 local USE flags loldapsrv and nololdapsrv. Pseudocode... IF loldapsrv then build libreoffice with full ldapserver ELSE IF nololdapsrv then build libreoffice with ldap client libraries only, removing the server portion if it already exists ELSE stop the build and spit out an error message. Explain the 2 previous options in the error message END IF Send out a news item a week or 2 in advance, telling people to set the appropriate USE variable, and what it does. The people who read and act on news items would have no hiccups at all. Those who miss it would have a one-time inconvenience, but at least their systems wouldn't be automagically screwed up. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
After a lot of screwing around, I found various ways to make the netbook not work in X, and even not boot. X won't work if I have CONFIG_STUB_POULSBO enabled. I also found that if I put video=640x480 in the lilo append= line, the machine would come up in 640x480 mode, and stay in 640x480 mode. Similarly for video=800x600. I assume it would also work for 1024x768. I believe the GRUB equivalent to lilo append= is GRUB_CMDLINE_LINUX=. I've added 2 duplicate entries in my lilo boot menu, with just the video= differing. I don't expect to give presentations with my netbook. But if I have to, I can downsize the video simply by rebooting into the appropriate mode. I have one of the really early netbooks (32-bit-only). I'm just happy that it works. One thing has made the process worthwhile. I found out via Google that setting aside some ram for the video noticably improves video performance. The netbook can now play 1080p HD Youtube videos in the large player. Not fullscreen. Before this, 1080p would stutter badly, even in Youtube's small player. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
The in-kernel GMA500 driver is being used with xf86-video-modesetting and it has some advantages over xf86-video-fbdev (like xrandr 1.2 so you can configure the resolution of your external monitor). I have seen occasional reports from users that the modesetting driver fails to detect the Poulsbo graphics, but due to lack of hardware I could not investigate further. If the modesetting driver does not work for you, then it would be a good idea to report a bug at https://bugs.freedesktop.org/ and include the relevant logs. Xorg appears to segfault with the xf86-video-modesetting driver. This includes Xorg -config. Normally, I run with no xorg.conf, no evdev, and no udev (I use mdev) and the machine works. I don't know if they'll accept a bug report due to my non-standard setup. I did some Google-searching. The vast majority of hits either had links to https://wiki.archlinux.org/index.php/Poulsbo (the Arch Linux wiki) or else copied large portions of that page. I followed their instructions, but it did not help. I'll do some more testing first, to see if I can narrow down the bug. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
On Wed, Nov 28, 2012 at 04:28:20AM +0100, Ch??-Thanh Christopher Nguy???n wrote Pacho Ramos schrieb: # Pacho Ramos pa...@gentoo.org (24 Nov 2012) # Doesn't build with current kernels (#344889). People needs to # migrate to x11-drivers/xf86-video-fbdev and be sure they have # CONFIG_STUB_POULSBO enabled in their kernels. # Removal in a month. x11-drivers/psb-kmod x11-drivers/xf86-video-psb Telling people to use xf86-video-fbdev for Poulsbo would be bad advice, they should use xf86-video-modesetting. Pacho+Christopher, I actually have an early 32-bit-only Poulsbo/Atom ASUS netbook working. I think I can speak with a little authority because of that. See message that I posted in Gentoo-Users... http://gentoo.2317880.n4.nabble.com/Intel-GMA500-Poulsbo-works-with-recent-kernels-td158517.html a few notes... 1) The instructions at http://blog.bodhizazen.net/linux/linux-gma500-poulsbo-driver-moved-out-of-staging/ list the make menuconfig steps necessary for the Poulsbo GPU. Since the Intel GMA5/600 KMS Framebuffer option is selected, xf86-video-fbdev *MUST* be used as the video driver. I did try xf86-video-modesetting, a few minutes ago and it does not support X Windows on my machine. I also suggest that those instructions be copied into the mask message, at least the following... * Kernel setup (make menuconfig) Device Drivers - Graphics support - DRM (Direct Rendering Manager) - Intel GMA5/600 KMS Framebuffer * X video driver x11-drivers/xf86-video-fbdev 2) CONFIG_STUB_POULSBO is not absolutely necessary, but may be helpful. It is related to specialized stuff like controlling brightness and other low-level video control stuff 3) See also http://blog.bodhizazen.net/linux/ubuntu-12-04-gma500-poulsbo-boot-options/ for more Poulsbo-specific tweaking. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] net-irc/xchat
On Mon, Nov 26, 2012 at 05:33:15AM -0500, Mike Frysinger wrote the inability to make users read the package.mask message explaining the situation is the only valid point in your e-mail. along those lines, a news entry is probably not even necessary. Howsabout following the same procedure as when xpdf was dropped? I vaguely remember emerge --update --deep world stopping with a message that xpdf was being dropped, and also a few alternatives were suggested in the message. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
I jumped off udev before I was pushed off... https://wiki.gentoo.org/wiki/Mdev https://wiki.gentoo.org/wiki/Mdev/Automount_USB While the Gentoo council meeting was looking at patches to udev on an ongoing basis, I was planning for a worst-case scenario where a separate /usr without initramfs is deprecated. Maybe not tomorrow or next month, but somewhere down the road. The only thing that will get me back onto udev is a separate fork, like Richard Yao's, where I don't have to worry about Lennart Poettering ramming his ideas into it. Lennart Poettering was very clear about standalone udev being a dead end. As for your statement that he isn't involved in udev, please read his post http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html where I've highlighted some words... Well, ***WE*** intent to continue to make it possible to run udevd outside of systemd. But that's about it. ***WE*** will not polish that, or add new features to that or anything. OTOH ***WE*** do polish behaviour of udev when used *within* systemd however, and that's ***OUR*** primary focus. And what ***WE*** will certainly not do is compromise the uniform integration into systemd for some cosmetic improvements for non-systemd systems. (Yes, udev on non-systemd systems is in ***OUR*** eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when ***WE*** can drop that support entirely.) If you think the statement that Lennart is at least unofficially involved in udev is don't complain to me, complain to Lennart. -- Walter Dnes waltd...@waltdnes.org We are apparently better off trying to avoid udev like the plague. Linus Torvalds; 2012/10/03 https://lkml.org/lkml/2012/10/3/349
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 07:06:04PM -0800, Greg KH wrote Again, udev isn't the problem here. It hasn't broken the standalone /usr issue at all. systemd-udev supporters have an interesting definition of broken. I plead not guilty to vandalism your honour. The complainant's window has actually been broken for several years. The stone I threw through it merely pointed out the existing brokeness. There isn't anything in udev to change for this. I don't understand why you are thinking that udev has anything to do with this issue at all. Before version 181, udev booted with a separate /usr. As of 181, it doesn't. If anything, I would argue that udev 181 was deliberately broken. The fact is, udev made new - and insane - rules that are simply *invalid*. Modern udev is broken, and needs to be fixed. It's other packages that are the problem here. You mean like systemd? When udev got rolled into the systemd tarball, and started sharing code with systemd, it also inherited its restrictions and separate-/usr-brokeness. And yes, I'm aware of bluetooth keyboard drivers. As I said in my previous message, there have always been a few edge cases that require a pre-mounted /usr to boot properly. What I'm complaining about is that the other 99% of udev users are now gratuitously forced to share the pain of the edge case users. -- Walter Dnes waltd...@waltdnes.org We are apparently better off trying to avoid udev like the plague. Linus Torvalds; 2012/10/03 https://lkml.org/lkml/2012/10/3/349
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 07:11:13PM -0800, Greg KH wrote And note, Kay and Lennart are _not_ treating udev as a second-class citizen. I said *STAND-ALONE* udev. Please re-read the two posts... http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html It's required for systemd to work properly, and other distros (like Ubuntu), use it for their systems to work properly in a stand-alone manner. So breaking that will not happen, lots of people will ensure that that does not happen, myself included. Kay and company have been rather cavalier in breaking systems in the past. Richard Yao is working on an insurance policy, just in case Kay and company do it again. -- Walter Dnes waltd...@waltdnes.org We are apparently better off trying to avoid udev like the plague. Linus Torvalds; 2012/10/03 https://lkml.org/lkml/2012/10/3/349
