[gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
I would like to suggest that the "server" profile variants (ie default/linux/amd64/10.0/server) be unlisted from profiles.desc, so that they do not show up in "eselect profile list" for new users. As far as I know, this server target is unmaintained, undesirable, and somewhat silly, if you look at its make.defaults. If this target is being kept around just so we don't break older setups, then simply removing from profiles.desc would allow these systems to keep using the profile, without presenting it as a viable option for new users. Thoughts? -Ben Kohler
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
There are other ways to achieve a "lighter" system, but that's not really what this is about. The server profiles are not any lighter than the base profiles. To those in favor of keeping some kind of "server" profile around, how would it differ from the base profile? What would you enable or disable on top of the base? I am pretty sure that the current USE="-perl -python snmp truetype xml" is not what any of you would suggest. In my opinion, removing /usr/portage/profiles/targets/server/make.defaults and having the "server" target apply nothing over the base profiles, and then dropping the warning from the server profiles, would be a better situation than where we are now. -Ben On Thu, Oct 11, 2012 at 5:22 PM, Gregory M. Turner wrote: > On 10/11/2012 1:04 PM, Walter Dnes wrote: > >> On Thu, Oct 11, 2012 at 03:22:17PM -0400, Mike Frysinger wrote >> >> sounds like something to fix rather than punt. i don't know why >>> you think having server profiles is "undesirable", but i certainly >>> desire it on many systems. like servers. the desktop and developer >>> profiles are not appropriate. >>> >> >> If you want a light >> profile, I suggest doing what I do... start your USE variable in >> make.conf with "-*", and add any flags you need, either in package.use or >> in make.conf. >> > > > > -gmt > > >
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
This is why I said that the server profile are no lighter than the base.
It's actually the base PLUS "snmp truetype xml".
My original suggestion of hiding or removing the server profiles was based
on the assumption that no one wants to maintain it. The server profiles
*in their current state* are silly & undesirable, in my view. The server
target has not been touched in almost 2 years, and most of the people using
it are doing so based on false assumptions.
If it is to remain in its current state, I think it should at least be
removed from the .desc listing. If we have a plan to make the server
profiles useful again, as a purposeful set of flags applied against the
base, then keeping these profiles listed is great. I would use a server
profile myself, in such case.
-Ben
On Fri, Oct 12, 2012 at 8:53 AM, Mike Gilbert wrote:
> On Fri, Oct 12, 2012 at 4:18 AM, Rich Freeman wrote:
> > On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras
> wrote:
> >> +1. I want these profiles to *staty*. I am using this profile on my
> >> "home boxes". It is the most minimal profile as the rest of the
> >> profiles pull in too much useless stuff. What is wrong with these
> >> profiles anyway?
> >
> > Looking at the actual profiles themselves, using server vs the base
> > profile makes these changes:
> > USE="-perl -python snmp truetype xml"
> >
>
> perl and python have not been enabled in the default/linux profile for
> some time now:
>
> RCS file: /var/cvsroot/gentoo-x86/profiles/default/linux/make.defaults,v
>
> revision 1.15
> date: 2011-10-05 15:22:13 -0400; author: darkside; state: Exp;
> lines: +2 -2; commitid: 2e764e8cae624567;
> Remove USE={python,perl} from default profile, as discussed/announced.
> Bug 250179
>
> Disabling those flags in the server profile is redundant.
>
>
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
I hope this discussion doesn't end when the warnings are removed. These
server profiles are still useless and misleading, they do not need to exist
in their current form. Your previous statement that these are the most
minimal profiles, is not accurate. The base profiles are the most minimal
(non-selinux) ones.
-Ben
On Sun, Oct 14, 2012 at 5:00 AM, Markos Chandras wrote:
> On Fri, Oct 12, 2012 at 3:29 PM, Daniel Pielmeier
> wrote:
> > Markos Chandras schrieb am 12.10.2012 10:08:
> >>
> >> +1. I want these profiles to *staty*. I am using this profile on my
> >> "home boxes". It is the most minimal profile as the rest of the
> >> profiles pull in too much useless stuff. What is wrong with these
> >> profiles anyway?
> >>
> >
> > If you want a minimal profile you don't need the server profile.
> >
> > "ln -s ${PORTDIR}/profiles/default/linux/${ARCH}/10.0 make.profile"
> > gives you a minimal profile.
> >
> > --
> > Regards
> > Daniel
> >
>
> I removed the ewarn message from the amd64/10.0/server profile. If
> nobody objects I will remove it from the x86 as well (CC'ing x86 to
> get their attention)
>
> --
> Regards,
> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
>
>
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
On Sun, Oct 14, 2012 at 11:22 PM, Mike Frysinger wrote:
>
> please stop top posting. you're making a mess of this whole thread.
>
> sounds like we should extend the profiles.desc file or profile structure to
> include a description so that people know the intention of each one. the
> only
> marker we had before was implicitly in the name (".../server" and
> ".../desktop").
> -mike
>
Sorry about that.
The addition of this extra info about the profiles sounds great, but back
to the original issue-- what *is* the intention of the server target?
Right now it seems like nothing more than a broken outdated vanity title,
for people who feel that using a "standard" profile on a server is icky.
No one actually believes that the server target's USE flags make any
sense, and no one has proposed what they SHOULD be. All that seems to be
established is a general feeling "don't take away our server profiles".
Whether it's time to flat out *remove* those profiles, I don't know. But
if these profiles aren't going to be updated or maintained in any way, I
believe that new users should be shielded from them. They are not a viable
or sensible choice for ANY new installation. In my ideal world ("if I were
king"), today I would delist them from profiles.desc, and send out a news
item warning of their immediate deprecation and planned removal 3 months
from now.
-Ben
Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, Feb 9, 2017 at 2:18 PM, Daniel Campbell wrote: > > I support the idea of a profile-set variable that determines whether or > not IUSE is respected. Minimalists get their systems faster, we get > something that adds to Gentoo's versatility and an additional profile. > Of course, we should be asking the anti-IUSE people if that would be > good enough to make the profiles/systems they want possible. > > -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 > > Can't this already be accomplished by modifying the USE_ORDER variable? -Ben
Re: [gentoo-dev] Sets vs Meta ebuilds
On Mon, Jul 10, 2017 at 2:25 PM, William L. Thomson Jr. wrote: > On Mon, 10 Jul 2017 15:15:35 -0400 > "William L. Thomson Jr." wrote: > > > # emerge -pC tomcat-servlet-api > > * This action can remove important packages! In order to be safer, > > use > > * `emerge -pv --depclean ` to check for reverse dependencies > >before > > * removing packages. > > Rather than a message like the above. I think portage should generate a > message/warning saying you are removing a package that is not in your > world file. Which means you are removing a package you did not install > directly. Just like if you were to remove a system package. > > That way people would know if they are removing something that is a > dependency. > > -- > William L. Thomson Jr. > Use -c rather than -C, like grknight suggested, and it will. -Ben
Re: [gentoo-dev] Sets vs Meta ebuilds
On Mon, Jul 10, 2017 at 2:36 PM, William L. Thomson Jr. wrote: > ... > Calculating dependencies... done! > >>> No packages selected for removal by depclean > >>> To see reverse dependencies, use --verbose > Packages installed: 1779 > Packages in world:194 > ... > # emerge -pC gcc > * This action can remove important packages! In order to be safer, use > * `emerge -pv --depclean ` to check for reverse dependencies > before > * removing packages. > > ... > > You aren't taking the time to read your own emerge output. Now, both of these recommend --pretend, but you can use --ask with it, for a safe unmerge that checks for reverse deps THEN allows you to continue only if it's safe. Try "emerge -cav gcc. -Ben
Re: [gentoo-dev] Sets vs Meta ebuilds
> > > - The -c option should say why it will not remove. > > > -- > William L. Thomson Jr. > It does, if you use the --verbose flag. This is mentioned in your emerge output a few times. -Ben
Re: [gentoo-dev] Sets vs Meta ebuilds
On Mon, Jul 10, 2017 at 3:27 PM, William L. Thomson Jr. wrote: > > > Not sure why anyone would have objection to such a warning like exists > for other things. Or providing more information to the user as to why a > package was not removed, or should not be removed. > > -- > William L. Thomson Jr. > If you want dependencies checked, use the correct option which checks them. This takes significantly longer than -C, as it's significantly more complex to check for. As far as I can tell, you are literally asking for -C to behave like -c, when you could just be using -c instead. -Ben
Re: [gentoo-dev] Sets vs Meta ebuilds
On Mon, Jul 10, 2017 at 4:42 PM, William L. Thomson Jr. wrote: > > If people understood, then saying use -c or -C makes no sense. It does > not address the lack of output from either I am talking about. > > -- > William L. Thomson Jr. > I really thought I understood you in that you wanted true reverse dependencies calculated, to check against that, and warn for it. I think that you are actually talking about a warning upon forced unmerge of anything not in /var/lib/portage/world, is that correct? -Ben
Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only
On Thu, Jul 13, 2017 at 9:29 AM, Mike Gilbert wrote: > > We are actually talking about protecting people who run something like > rm -rf /sys/firmware/efi/efivars/ as root. > > If you are dumb enough to do something like that, you almost deserve > to spend a couple hundred on a new motherboard. > > While I can think of a few ways you can accidentally do this via bindmounts and such, I think it's also worth mentioning that this "bricking" only happens on a very very small number of systems with a specific buggy UEFI implementation, the vast majority of UEFI hardware will not be "bricked" by wiping efivars. I'm still onboard with protecting users from this out of the box, but it's not like without this change, we'll have gentoo boxes dropping dead all over the place every week. We're protecting from something that requires both a very specific firmware bug AND serious user error, to trigger. -Ben
Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution
On Tue, Dec 26, 2017 at 6:11 PM, Rich Freeman wrote: > Does this still cause a warning? I thought that openrc/sysvinit were > now pulled in via a virtual these days (alongside systemd), and were > not directly in @system. Or do we still have functions.sh issues? > > -- > Rich > Still throws warning due to unresolved bug https://bugs.gentoo.org/375115 -Ben
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Wed, Feb 17, 2016 at 7:39 AM, Richard Yao wrote: > > > I have no idea why we are even discussing the choice of default for > virtual/udev to have subdiscussions about kdbus. Practically everyone on > the list thinks eudev is the best choice. > I think a lot of us appreciate that eudev exists as a lifeboat or backup plan, but want to wait until there's a real, obvious, technical reason to switch. MOST of the reasons given have just been vague predictions of future doom and gloom. And if we dare ask for more technical reasons, we get berated for being a "systemd lover". "Let's wait until udev becomes unusable" doesn't seem that unreasonable to me, and it has nothing to do with being pro or anti systemd. -Ben
Re: [gentoo-dev] Changing order of default virtual/udev provider
On Wed, Feb 17, 2016 at 7:55 AM, Richard Yao wrote: > > > eudev has every commit scrutinized by people who care about using it on > Gentoo. systemd-udev does not. Consequently, eudev has avoided the system > boot breaking regressions that prompted its creation. That is a good reason > to make it the new default. If it fails to fulfill its duties, then this > could be revisited, but that should be unlikely. > > I think if someone could enumerate those specific breakages and present it as evidence, that could get more people on board for this change. Moreso than just "upstream doesn't care about us" or "eventually split udev will be impossible". -Ben
Re: [gentoo-dev] grub-2 configuration
On Sat, Oct 8, 2016 at 9:28 AM, Tom H wrote: > On Tue, Oct 4, 2016 at 11:34 PM, William Hubbs > wrote: > > > > You don't have to use grub-mkconfig. You can write /boot/grub/grub.cfg > > by hand if you want, and it appears that the syntax is documented in > > the grub info pages. > > If you write "/boot/grub/grub.cfg" by hand and run grub-mkconfig by > mistake, you'll wipe out your config. It's safer to write it to > "/etc/grub.d/40_custom" and "chmod -x" the other files in > "/etc/grub.d/". > > Well "grub2-mkconfig" by itself doesn't write anywhere unless you pass a -o parameter. If you are "accidentally" running "grub2-mkconfig -o /boot/grub/grub.cfg" and it catches you by surprise that /boot/grub/grub.cfg is overwritten, you have bigger problems. Let's not make up problems where there are none. -Ben
Re: [gentoo-dev] Uppercase characters in package names
> > > Keep in mind some will emerge libraries dependencies for their own projects > and development. They do not always have to be merged as a dependency of > another package. > > It might be confusing to know when it is acceptable to use mixed case and > not. > > -- > William L. Thomson Jr. > It's really not confusing, you're making up issues just to hear yourself talk. -Ben
[gentoo-dev] Re: Packages up for grabs: media-gfx/rawtherapee media-libs/libiptcdata
On 2/24/23 04:58, Marek Szuba wrote: In light of the current (proxied) maintainer having stated they no longer have a Linux desktop and therefore expect difficulties in continuing to maintain their packages, media-gfx/rawtherapee I will take this one unless anyone else is really passionate about it. It's related to one of my other packages (fotoxx) and I've done the last bump and a few minor fixes on it already. -Ben
[gentoo-dev] Last rites: sys-apps/memtest86
# Ben Kohler (2024-04-07) # Long ago forked to and obsoleted by sys-apps/memtest86+. Upstream has # abandoned this for their proprietary UEFI-based one (packaged in gentoo as # as sys-apps/memtest86-bin). # Removal on 2024-05-07. Bug #502464, #607494, #628528, #750677, #887003, # #912973, #920109 sys-apps/memtest86
[gentoo-dev] Last rites: media-video/unifi-video
# Ben Kohler (2024-04-07) # Abandoned upstream long ago in favor of Unifi Protect (running only on an # official Unifi appliance. Likely contains lots of security holes in bundled # libs. # Removal on 2024-05-07. Bug #928881 acct-group/unifi-video acct-user/unifi-video media-video/unifi-video
Re: [gentoo-dev] Gentoo identification in Primary Volume Descriptor of ISOs
On 5/2/24 06:15, Michal Prívozník wrote: Hi, I've noticed (thanks to an issue reported against Libvirt [1]), that neither minimal installation ISO nor liveGUI ISO contain anything inside their Primary Volume Descriptors that would hint the ISO contains Gentoo. This is unfortunate a bit, because matching VolumeID is exactly how tools like libosinfo detect distro on given ISO [2] and then can recommend some values when creating VMs with that ISO. In this specific case, minimal amount of memory required to even boot the ISO (yeah, it currently reports 256MiB which is too small for anything really). Is there any chance this could be fixed, e.g. by reporting something in VolumeID? Michal 1: https://gitlab.com/libvirt/libvirt/-/issues/600 2: https://gitlab.com/libosinfo/osinfo-db/-/blob/main/data/os/gentoo.org/gentoo-rolling.xml.in?ref_type=heads Hi Michal, Thanks for bringing this to our attention. Relatively recently, our ISO build tool catalyst started using grub-mkrescue to prepare the bootloaders and create the iso [1], and we seem to have lost the volume IDs at that time. I've just added a -volid parameter back in [2] which should restore the volume IDs we were using before and should match what libosinfo is expecting. The change should apply to our next weekly autobuilds. Before: install-x86-minimal-20240429T170419Z.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'ISOIMAGE' (bootable) After: install-x86-minimal-20240429T170419Z.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Gentoo x86 20240429T170419Z' (bootable) [1] https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=0a27a7a39a7d6944618009f8027fb09a22244c34 [2] https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=04c70a9df505718c7e97ca1484f7c03270e6824c
Re: [gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
On Thu, Dec 27, 2012 at 5:40 PM, Andreas K. Huettel wrote:
> 2) Deprecate the 10.0 profiles NOW by removing them from profiles.desc and
> putting the new 13.0 profiles there. This has absolutely no effect on
> running
> installations.
>
> 3) Make a news item about removal of 10.0 profiles in a year /
> ${TIMESCALE}.
>
> 4) One ${TIMESCALE} later, remove 10.0 profiles. This is the ugly part, and
> users need to be warned and prepared properly - here everyone needs an
> EAPI5
> capable portage.
>
This seems like a great time to deprecate & remove the unmaintained server
profile target, as has been previously discussed. Is this doable or is
that another issue to be tackled another day?
-Ben Kohler
Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
On Sun, Jan 20, 2013 at 11:27 PM, Ben de Groot wrote: > On 21 January 2013 12:16, Peter Stuge wrote: > > Panagiotis Christopoulos wrote: > >> I don't build server machines every day, others do and it would be > >> much appreciated if they could respond here. > > > > I build catalyst stage4s. Any default profiles are kindof pointless > > for me; I have USE=-* and the flags that I want. > > > > Anything else seems a bit too random. > > This is why I think we do need something like a truly minimal profile > to start building from. Too many people are doing this. Remember that we can also modify USE_ORDER to specifically drop profile flags *or* package-default flags, but not necessarily both. Maybe this is something that should be brought "above the table" and documented. It's a lot harder to shoot yourself in the foot by just dropping profile flags, but keeping package defaults. Of course, that adds another factor to the USE=dri in profile versus package-default discussion, too. -Ben Kohler
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On Fri, Feb 15, 2013 at 7:48 AM, Ian Stakenvicius wrote: > > > I expect to see the full result one would have to emerge -epv > [package] , at least that will report the repos for all *DEPENDs > (although it is a bit overkill to have users submit that in the > general case) > > There are also commands like "eix --installed-from-overlay" to see at a glance what questionable packages may be in play. Clearly we have a dev or 2 with some overlay hate, but I don't really think that's relevant to this project discussion. It certainly shouldn't be a show stopper. -Ben
Re: [gentoo-dev] New install isos needed
On Sun, Mar 24, 2013 at 6:33 AM, Alexander Berntsen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Making an install ISO is as pointless as writing a CMS for > Gentoo.org... Gentoo should only bother if it is really necessary. > > ZSH-related bugs fixed ? Link SystemRescueCD : Link something else > I really feel like we should still have an official minimal iso, but there is no reason it needs to be on the same schedule as the weekly stage3 autobuilds. It doesn't even need to be "autobuilt" at all, a couple of hand-rolled hand-reviewed releases a year, or as-needed based on new features that show up. -Ben
Re: [gentoo-dev] New install isos needed
On Sun, Mar 24, 2013 at 2:46 PM, Alexander Berntsen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 24/03/13 20:32, Ben Kohler wrote: > > I really feel like we should still have an official minimal iso > Feelings do not matter. > > - -- > Alexander > As a very active contributor in #gentoo, assisting new users every day with their first-time gentoo installs, I strongly believe it's important that we have an official install medium upon which the official installation handbook is based. But I would also like to see the handbook expanded a bit to make it clear that nearly any other livecd can be used, when the official minimal cd has bugs or just lacks some features for a special setup. -Ben (iamben @ freenode)
Re: [gentoo-dev] New install isos needed
On Sun, Mar 24, 2013 at 2:46 PM, Alexander Berntsen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 24/03/13 20:32, Ben Kohler wrote: > > I really feel like we should still have an official minimal iso > Feelings do not matter. > > - -- > Alexander > Just to add a bit more, to get across the point that I'm not just some random whining user-- most of the "major" bugs on our stage3s and minimal isos in the last 6 months or so were reported by me. The firmware issue that sparked this thread, was reported, investigated, and solved by me. BUT I don't think that we should scrap the gentoo minimal iso, just change the release schedule & processes. -Ben
Re: [gentoo-dev] New install isos needed
On Mon, Mar 25, 2013 at 8:45 AM, Rich Freeman wrote: > > Tend to agree. To install Gentoo you really just need a shell, the > ability to partition and create filesystems, some basic networking > (even that is somewhat optional), and a text editor. Sure, a browser > and such is a real nice-to-have, as would be something nicer than > nano, but you really don't need them to install Gentoo. As an experienced user, it's fairly easy to run through the basic gentoo install procedure from just about any root-on-linux login prompt you can find. But like it or not, some new users do depend on a certain amount of consistency and and blindly-trusted copy-paste-ability. Even the gentoo-based sysresccd deviates enough to make things interesting at times. As cool as zsh is, having it as the default shell (with non-gentoo-standard prompt) IS going to throw some people for a loop. Not to mention the polluted environment issues (ie $path set after chroot). I think it's important that our officially-endorsed iso stays closely tied to the "standard gentoo" setup. For the new user experience, I don't think "any old linux iso will do just fine" applies. BTW I just quoted your one paragraph because I definitely agree with everything else you said. -Ben
Re: [gentoo-dev] bash-3.1 stable
On Tue, Apr 2, 2013 at 9:39 AM, hasufell wrote: > On 04/02/2013 04:01 PM, Markos Chandras wrote: > > Here we go again. Fine, keep arguing about the really important > > question "why old X is in the tree when new X is stable". > > Did anyone actually consider to ask the maintainers instead of opening > > a public debate on this? I guess no, because > > bikeshedding in the mailing list is so much better. > > > > I am sorry about that. In fact I was about to file a bug, but then > decided to take it up here and CC base-system. That was probably a mistake. > > Thanks to everyone for the comments... or not. > > People who are not interested in this topic should ignore the thread, it's not necessary to reply with the word "bikeshedding" every time you see a thread that you consider mundane or trivial. I was looking forward to hearing some insights on why bash-3.1 is still around, when I get sick of hearing about it, I'll stop following the thread. -Ben
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, Jul 24, 2013 at 2:01 PM, Peter Stuge wrote: > > > To be clear: I am not suggesting to change the meaning of stable, > I am suggesting that the latest available upstream kernel should > perhaps be the default for Gentoo users. How to make that happen > is less important, the idea to automatically mark v-s stable is > only that, an idea. :) > > > //Peter > > You seem to be ignoring the regressions that often come with new kernel releases, the very common breakage caused in stable "genkernel all", and other various complications. Unleashing brand new kernel.org sources on stable users as soon as they are released seems crazy to me. These releases surely bring more than just "the newest fixes". Going straight to stable is (in my eyes) so far from being a viable option, that "always unstable, allow unstable if you're ok with the risk/benefit tradeoff" seems like the best bet, to me. -Ben
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 9:17 AM, Patrick Lauer wrote: > > > Any users trying this sidegrade will be left without support and risk > being ridiculed by annoyed bystanders. > > There are many of us supporting systemd + gnome 3.8 in #gentoo right now today, and I am strongly discouraging this "ridicule". We also discourage ridicule when someone asks for support on KDE, Gnome, Pulseaudio, NetworkManager, proprietary drivers, or any of the other packages that tend to draw such polar opinions-- but are fully supported. I do think it's a good idea to get all this out in the open though-- make sure users know exactly what they're getting into, how much it's going to turn their gentoo world upside down (for a day or 2), WHY this is happening, and what the alternatives are. Most of this has been covered in this thread already. But it's not unsupported just because some people don't know how (or have no desire) to support it. As for the stabilization issue-- it seems like most people against stabilization just want ~arch as a barrier or "whoa, wait up a sec" warning to stable users don't stumble upon systemd, which makes sense. But I think there are better ways to accomplish this, rather than abusing keywords. -Ben
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Sat, Aug 10, 2013 at 6:59 AM, Tom Wijsman wrote:
>
>
> Support for it is given all over the place; like for instance in #gentoo
> and #gentoo-desktop on the FreeNode IRC network, on the Gentoo Forums,
> on the gentoo-user ML as well as for bugs on the Bugzilla bug tracker.
>
> The people saying this is unsupported are either WISHING it was
unsupported, or they are completely uninformed (w.r.t. systemd usability on
gentoo) and are just here to express general anti-systemd sentiment. In
either case, they are not really contributing anything worthwhile to this
discussion.
People are running gnome-3.8 and systemd today, on gentoo. It's working
great for tons of people out there. We're supporting it in #gentoo and on
the forums today, with much success. If you ("people out there", not you
Tom) don't realize that yet, please pull your head out of the sand.
-Ben
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Fri, Dec 6, 2013 at 9:26 AM, Ian Stakenvicius wrote: > > > If the stage3 could include a dhcp client and (ideally imo) netifrc, > even though they aren't a part of @system, that would help prevent the > "stuff missing, damnit, have to reboot back to livecd" cycle. Since > it isn't part of @world we would still need the documentation and > instructions for someone to explicitly choose a network provider, > otherwise they'll be bitten with it disappearing via --depclean. > > The user can still bring up networking via ifconfig or udhcpc if he happens to miss the handbook section on networking. If the user skips parts of the handbook, things may not work quite right... but the manual workaround is so trivial anyway, this is really a non-issue. Just make it clear that "emerge netifrc" is needed to use net.* scripts, and mention some alternatives. A news item would be a good idea to warn veteran "haven't used the handbook in years" people. -Ben
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Wed, Dec 11, 2013 at 1:30 PM, Peter Stuge wrote: > > > I think that nobody who is not intimately familiar with the > development in both projects can think anything that is actionable. > > It's insulting to see how people all over the internet run as fast > as they possibly can in whatever direction even though they have > nearly zero detailed understanding of the options they are choosing > between. > > Suggesting cronie in the handbook seems like a no-brainer. Do you have some information on vixie-cron that we're all missing? -Ben
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Fri, Dec 13, 2013 at 10:08 AM, Peter Stuge wrote: > Sergey Popov wrote: > > >>> Last time I checked, vixie-cron upstream was died > > >> > > >> If vixie-cron upstream is dead as you say > > > > > > Define dead? > > > > Bugs are not fixed for a very long time, no answers on private > > e-mails or in maillists. > > Define very long time? > > > //Peter > If you have some reason we should be sticking to vixie-cron, please stop being so mysterious and share it with the rest of us. Thanks! -Ben
Re: [gentoo-dev] Portage Feature Request: making thirdpartymirrors easier to manage
On Wed, Jan 8, 2014 at 12:37 PM, Alex Xu wrote: > > > Eww. Geographically-close files should be made available through > GENTOO_MIRRORS and the regular distfiles system. > I think you may be missing the point of this proposal, or are unaware of how profiles/thirdpartymirrors and SRC_URI="mirror://.." work. Readability and maintanence issues aside (which themselves are huge), the current setup with a list of literally hundreds of geographically-random mirrors for one source, is quite often doing a disservice to our users. Most of the very large upstream mirror list sources are already sorted geographically, it would be great to take advantage of this. And to me, it seems like the proposed thirdpartymirrors/mirrorname/ setup seems quite elegant. I'm sure it would be optional and mirror lists that can't take advantage of this would just use a flat file at thirdpartymirrors/mirrorname. -Ben
Re: [gentoo-dev] Portage Feature Request: making thirdpartymirrors easier to manage
On Mon, Jan 6, 2014 at 2:20 PM, Robin H. Johnson wrote: > This is a small feature request, but it will require a modification to > PMS, so I describe it here. > > The present thirdpartymirrors file is unwieldy, and difficult to manage > due to it's format with very long lines. It also doesn't permit easy > comments. Presently commits to it look very ugly, because diffs are > line-based, and we pack a lot into each line. > > I would like to make it a directory instead of a single file, and extend > the internal syntax. > > I am very excited about this whole idea, this thirdpartymirrors setup badly needs some reworking. To me it makes the most sense to turn thirdpartymirrors into a dir, with a file structure like: thirdpartymirrors/mirror1 thirdpartymirrors/mirror2 thirdpartymirrors/mirror3/ thirdpartymirrors/mirror3/Asia thirdpartymirrors/mirror3/Europe thirdpartymirrors/mirror3/Etc thirdpartymirrors/mirror4 I'm not sure I see much real value in allowing individual profiles to add/remove mirrors from each group, to be honest. Maybe I'm just not thinking of the right scenarios. But I really do believe just the basic changes like splitting the file so each group gets its own file, one server per line, with comments, etc... will be a huge help in using and maintaining these groups. -Ben
Re: [gentoo-dev] Portage QOS
On Thu, Jan 9, 2014 at 6:44 AM, Igor wrote: > > > According to distro watch: > > ... > According to Linux Counter > > ... > "What are distro watch and linux counter and who cares what their opt-in stats gathering says?" -most Gentoo users I've ever talked to I think if you drop the premise "Gentoo is dying, how do we fix it?" and just focus on "Here are some ideas on how we can improve Gentoo", you'll get a better response here. From what I see (IRC activity, new ebuild activity, bugzilla activity, etc), our community seems stronger than ever. I think a lot of us are puzzled that you think Gentoo has "stopped". You have some great ideas but this is not a sinking ship scenario. -Ben
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Fri, May 30, 2014 at 11:50 AM, Tom Wijsman wrote: > On Fri, 30 May 2014 19:26:38 +0300 > Samuli Suominen wrote: > > > I'll give it 48 hours and then p.mask it. > > Genkernel itself does work; so, there is no point to masking it. > > I like the message the package.mask would send to maintainers, but that would be very bad for our handbook to recommend a hard masked tool. FYI this has been an ongoing problem for some time-- genkernel's code is still well maintained and seeing development, it's the arch-specific kernel configs that are unmaintained. And broken in quite a few ways right now. We have a few people willing to spend the 20 minutes it would take to fix all of these config problems, but no one in an official dev seat. None of the current genkernel maintainers want to touch the kernel config part. As nice at it sounds to just DROP these configs, that option is not really feasible considering the way we currently use genkernel in our handbook. Relying on the kernel's own defconfig, "genkernel all" will NOT produce the same mostly-usable-on-any-hardware result that we now rely on. I would be more than willing to whip up a config that fixes this udev issue plus a dozen more, and post it somewhere for review. But I'd only be able to cover x86/amd64. Or anyone else can do it-- load up our existing config into menuconfig (probably against current stable gentoo-sources, add/remove a handful of options to fix up all these bugs. Save, exit, give it to the genkernel maintainer and we're done. -Ben Kohler
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Fri, May 30, 2014 at 12:59 PM, Tom Wijsman wrote: > > Good idea, we really could use some kind of kernel seeds in the Portage > tree; if someone is willing to maintain them, knowing that Pappy has > maintained them for years and spoke about it it seems like hard work. > > Remember that these "kernel seeds" are actually pretty far from what we need for genkernel defaults (at least the way we currently recommend using it in our install handbook). The kernel seeds provide a good sane kernel config *with little or no specific hardware support*. But I'm definitely in favor of separately packaging the kernel configs. -Ben
Re: [gentoo-dev] Re: RFC: news item for upower
On Wed, Jun 4, 2014 at 11:24 AM, Samuli Suominen wrote: > > > Wrong. I'm always using the -t (--tree) flag with Portage and I would > have seen upower being the culprit immediately, > and second command would have been `eix upower` to see available > versions, at which point I would have seen > upower-pm-utils, and figured it out. > > - Samuli > > I'm glad this fire has mostly been put out, but I think you are making quite a leap here that normal users can "see upower-pm-utils, and figure it out". You may be too close to this problem to understand just how confusing it is to everyone else. No offense intended. -Ben
[gentoo-dev] Adding USE=udev to linux profiles
Hello, I'd like to propose adding USE=udev to our linux profiles (in profiles/default/linux/make.defaults probably). This flag is already enabled on desktop profiles but it also affects quite a few packages used on non-desktop linux systems. This flag provides useful functionality that most linux users will want. I'm a bit surprised that we still don't have it in all linux profiles, but I think we've worked around this in the past by adding IUSE=+udev to quite a few of those packages (33 packages, 116 ebuilds, by my count). This missing flag came to my attention again on bug 661584 where lvm2 has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users have a bit of a mismatch between the 2 and get ugly errors on cryptsetup. Since this flag only affects linux, I think it makes more sense to set it in linux profiles than to use IUSE defaults. Any objections to this idea? Thanks, Ben
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/19/2018 05:00 PM, Michael Orlitzky wrote: Please add defaults per-package, only where they make sense. Enabling flags globally creates a huge headache for people that want them off. If I want to undo your new flag, I have to set USE="-udev" globally, and that clobbers any important per-package defaults that maintainers have set. I was well aware of that when I prepared this proposal, and it's true of every USE flag in any profile's make.defaults. I still believe it's the correct course of action. Thanks, Ben
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/19/18 20:54, Mikle Kolyada wrote: > +1. widely used profiles should have as least flags enabled by default > as possible, I would not be happy with +udev on my servers. > I disagree with this premise. The default and most widely used profiles should fit the most common use cases. I'd be curious as to what problems would be caused on your servers if this flag were turned on-- specifically what packages will get the flag turned on, where that bothers you? On my servers, the impact is very minimal. I'm not totally sure that my proposal of USE=udev is correct/justified, but there are a few counter-arguments I've heard that I don't think hold water, I'd like to focus on the others. -Ben pEpkey.asc Description: application/pgp-keys
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/19/18 22:40, Benda Xu wrote: > > To represent the Gentoo Prefix users, we would like to have USE=udev > turned off or even hard masked on linux-prefix profiles. > > Yours, > Benda > I believe this is an argument in favor of moving the default to profiles then, out of IUSE defaults, right? -Ben pEpkey.asc Description: application/pgp-keys
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/19/18 23:04, Michael Orlitzky wrote: > > No I'm not. I'm saying add them per-package, because it's a better > design. We have package.use in profiles now, not just IUSE defaults. > > Global defaults have problems: > > * They can't be undone. It's next to impossible for me to undo > USE=udev when set in a profile that is inherited by all others. > > * USE=udev means different things for different packages. You think it > "makes udev work" or whatever, but nobody has any idea what it does > for half of the packages that use it. The meaning is package- > specific, so the default should be package-specific. > > * They're easy to set, but hard do unset when you realize you were > wrong a year from now. > > If you really want to enable it globally after being told that it's bad > engineering and downright annoying, go do it in a profile that I can > avoid and not "linux". > I believe you're arguing against profile global USE in general, can you start a new thread for that if you believe it's worth discussing? We do have global USE in profiles now and I believe that the sane default for linux profiles is to have udev support globally. -Ben pEpkey.asc Description: application/pgp-keys
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/25/2018 02:28 AM, Andrew Savchenko wrote: Adding udev to the base profile will make customization much harder for people unwilling to use udev. This is the problem. To stay on the original track, I was suggesting adding it to the linux profile component, not base. And people who are unwilling to use udev would disable it globally, like people who are unwilling to use pam or ipv6. But I understand where you're coming from in general-- that we've already achieved a good minimal balance in enabling udev only where it's really needed, and enabling it in linux make.defaults will make it difficult to get back to that state. So I will just continue to ask for IUSE=+udev where I believe it's very important for sane functionality of a particular package. In other words, I'm no longer pushing for the make.defaults change. -Ben
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 07/26/2018 02:59 AM, Andrew Savchenko wrote: Hi! On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote: I'd like to propose adding USE=udev to our linux profiles (in profiles/default/linux/make.defaults probably). This flag is already enabled on desktop profiles but it also affects quite a few packages used on non-desktop linux systems. This flag provides useful functionality that most linux users will want. I'm a bit surprised that we still don't have it in all linux profiles, but I think we've worked around this in the past by adding IUSE=+udev to quite a few of those packages (33 packages, 116 ebuilds, by my count). This missing flag came to my attention again on bug 661584 where lvm2 has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users have a bit of a mismatch between the 2 and get ugly errors on cryptsetup. Since this flag only affects linux, I think it makes more sense to set it in linux profiles than to use IUSE defaults. Any objections to this idea? A user had contacted me with his input from the HPC world, I'm redirecting his e-mail here. James is whitelisted now so he can further participate in this discussion himself if necessary. As an HPC user of Gentoo I agree that minimal and highly optimized Gentoo setups are indeed very useful and must stay that way. Begin forwarded message: Date: Wed, 25 Jul 2018 13:31:59 -0400 From: james To: birc...@gentoo.org Subject: udev's future Hello Andrew, Sorry, I do not have direct posting ability to gentoo-dev, so in hopes of finding a dev-sponsor, I hope you will paraphrase this email to you for the sake of preventing 'dev as a default' or base setting of any sort. My research and testing for new HPC configurations, has systemd and udev at the heart of codes to avoid to optimize the heterogeneous nature of the clusters I'm building. In fact my development work, although delayed due to transient-illness, is more of a gentoo-centric convergence of embedded-gentoo, minimal (server) gentoo, gentoo-hpc clusters and unikernels. As far as performance and security are concerned 'less' is always better. Those codes and ebuild that are desired are to added in a higher level; hoping to continue the leverage the portage tree of applications, only as dynamically required. Avoidance of setting udev or in any form mandating any part of systemd will have dire consequences and cost me months, if not years to find a way to 'totally undo' the ravages of udev. Minimized kernels are also fundamental to my loosely-coupled (gentoo) HPC development. Even tiny Rtos based embedded linux systems are in the process of being included in a loosely-coupled gentoo centric heterogeneous HPC cluster. I would 'beg' against making udev primary under any circumstance. Gentoo has a unique and powerful position, just for it's position of choice and minimizational features; After 15 years, I'd hate to have to work in another distro, as gentoo has served me extraordinarily well over the decades. sincerely, James Horton, PE Best regards, Andrew Savchenko No one was ever talking about forcing udev usage, just default-enabling support on a few MORE packages than we already do. Our standard linux stage3's are already udev-enabled. But not udev-forced, anywhere. Nothing about my proposal was going to force udev on people who don't want udev at all-- let's not even go down that rabbit hole of discussion. I was only pushing for more consistency-- either your system would be fully udev-enabled, or not at all. -Ben
[gentoo-dev] Gentoo i486 support
Hi guys,
For some time now, we've been shipping broken i486 stage3s that do not
run on pre-i686 hardware [1]. Due to a change in catalyst [2], we no
longer set CXXFLAGS in the default make.conf, so the x86 profiles' (imho
wrong/broken) defaults [3] kick in.
I'd like to get this fixed, and I see 3 possible solutions, listed in
order of my own preference:
1) Adjust x86 profile defaults to drop the problematic -march=i686.
This would be more in line with amd64 profiles (et al), which set no
-march value so it can run on any hardware for this arch.
2) Patch catalyst to start setting CXXFLAGS again. Rather than roll
back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that we
start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}"
CXXFLAGS=${COMMON_FLAGS}" etc. I prepared such a patch a while back
[4], which seems to work but may need a bit of updating.
3) Drop i486 support. We're only pretending to have support now, we
could officially stop building these broken stages completely.
Personally I think #1 is the most technically correct and least amount
of work. The only result will be slightly less optimized builds for
people who choose not to customize *FLAGS at all in make.conf. But this
is correct behavior. What we have now is akin to setting -march=core2
on amd64 stage3 and saying "oops it doesn't work on early 64bit AMD
cpus, but oh well most people have newer and will appreciate the
optimization".
Thoughts?
-Ben
[1] https://bugs.gentoo.org/654080
[2]
https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=b409bd9bb4b50f69a555e4e148057ade86a7ed16
[3]
https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/arch/x86/make.defaults
[4] https://bugs.gentoo.org/575446#c4
[gentoo-dev] [PATCH] tmpfiles.eclass: fix @USAGE to not include function name
Signed-off-by: Ben Kohler
---
eclass/tmpfiles.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/tmpfiles.eclass b/eclass/tmpfiles.eclass
index 68478ffbcd6..360c5e3b816 100644
--- a/eclass/tmpfiles.eclass
+++ b/eclass/tmpfiles.eclass
@@ -63,7 +63,7 @@ esac
RDEPEND="virtual/tmpfiles"
# @FUNCTION: dotmpfiles
-# @USAGE: dotmpfiles ...
+# @USAGE: ...
# @DESCRIPTION:
# Install one or more tmpfiles.d files into /usr/lib/tmpfiles.d.
dotmpfiles() {
@@ -84,7 +84,7 @@ dotmpfiles() {
}
# @FUNCTION: newtmpfiles
-# @USAGE: newtmpfiles .conf
+# @USAGE: .conf
# @DESCRIPTION:
# Install a tmpfiles.d file in /usr/lib/tmpfiles.d under a new name.
newtmpfiles() {
@@ -102,7 +102,7 @@ newtmpfiles() {
}
# @FUNCTION: tmpfiles_process
-# @USAGE: tmpfiles_process ...
+# @USAGE: ...
# @DESCRIPTION:
# Call a tmpfiles.d implementation to create new volatile and temporary
# files and directories.
--
2.23.0
[gentoo-dev] [PATCH] common-lisp-3.eclass: fix various @USAGE inconsistencies
Some of these functions are missing @USAGE even though they do require
arguments. There's also a redundant function name in a few places.
Signed-off-by: Ben Kohler
---
eclass/common-lisp-3.eclass | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/eclass/common-lisp-3.eclass b/eclass/common-lisp-3.eclass
index ae229491025..65ad5a58a34 100644
--- a/eclass/common-lisp-3.eclass
+++ b/eclass/common-lisp-3.eclass
@@ -75,6 +75,7 @@ common-lisp-install-one-source() {
}
# @FUNCTION: lisp-file-p
+# @USAGE:
# @DESCRIPTION:
# Returns true if ${1} is lisp source file.
lisp-file-p() {
@@ -84,6 +85,7 @@ lisp-file-p() {
}
# @FUNCTION: common-lisp-get-fpredicate
+# @USAGE:
# @DESCRIPTION:
# Outputs the corresponding predicate to check files of type ${1}.
common-lisp-get-fpredicate() {
@@ -98,7 +100,7 @@ common-lisp-get-fpredicate() {
}
# @FUNCTION: common-lisp-install-sources
-# @USAGE: common-lisp-install-sources path [...]
+# @USAGE: [...]
# @DESCRIPTION:
# Recursively install lisp sources of type ${2} if ${1} is -t or
# Lisp by default. When given a directory, it will be recursively
@@ -126,6 +128,7 @@ common-lisp-install-sources() {
}
# @FUNCTION: common-lisp-install-one-asdf
+# @USAGE:
# @DESCRIPTION:
# Installs ${1} asdf file in CLSOURCEROOT/CLPACKAGE and symlinks it in
# CLSYSTEMROOT.
@@ -140,7 +143,7 @@ common-lisp-install-one-asdf() {
}
# @FUNCTION: common-lisp-install-asdf
-# @USAGE: common-lisp-install-asdf path [...]
+# @USAGE: [...]
# @DESCRIPTION:
# Installs all ASDF files and creates symlinks in CLSYSTEMROOT.
# When given a directory, it will be recursively scanned for ASDF
@@ -167,7 +170,6 @@ common-lisp-3_src_install() {
}
# @FUNCTION: common-lisp-find-lisp-impl
-# @USAGE: common-lisp-find-lisp-impl
# @DESCRIPTION:
# Outputs an installed Common Lisp implementation. Transverses
# CLIMPLEMENTATIONS to find it.
@@ -179,7 +181,7 @@ common-lisp-find-lisp-impl() {
}
# @FUNCTION: common-lisp-export-impl-args
-# @USAGE: common-lisp-export-impl-args
+# @USAGE:
# @DESCRIPTION:
# Export a few variables containing the switches necessary
# to make the CL implementation perform basic functions:
--
2.23.0
[gentoo-dev] [PATCH] bash-completion-r1.eclass: minor @USAGE syntax fixes
Signed-off-by: Ben Kohler
---
eclass/bash-completion-r1.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/bash-completion-r1.eclass b/eclass/bash-completion-r1.eclass
index 7a69f485a74..636371df9d6 100644
--- a/eclass/bash-completion-r1.eclass
+++ b/eclass/bash-completion-r1.eclass
@@ -91,7 +91,7 @@ get_bashhelpersdir() {
}
# @FUNCTION: dobashcomp
-# @USAGE: file [...]
+# @USAGE: [...]
# @DESCRIPTION:
# Install bash-completion files passed as args. Has EAPI-dependant failure
# behavior (like doins).
@@ -106,7 +106,7 @@ dobashcomp() {
}
# @FUNCTION: newbashcomp
-# @USAGE: file newname
+# @USAGE:
# @DESCRIPTION:
# Install bash-completion file under a new name. Has EAPI-dependant failure
# behavior (like newins).
--
2.23.0
[gentoo-dev] [PATCH] perl-app.eclass: remove unneeded @USAGE lines
Signed-off-by: Ben Kohler
---
eclass/perl-app.eclass | 3 ---
1 file changed, 3 deletions(-)
diff --git a/eclass/perl-app.eclass b/eclass/perl-app.eclass
index 6b762dd83b3..074902294e5 100644
--- a/eclass/perl-app.eclass
+++ b/eclass/perl-app.eclass
@@ -21,7 +21,6 @@ case "${EAPI:-0}" in
esac
# @FUNCTION: perl-app_src_prep
-# @USAGE: perl-app_src_prep
# @DESCRIPTION:
# This is a wrapper function to perl-app_src_configure().
perl-app_src_prep() {
@@ -29,7 +28,6 @@ perl-app_src_prep() {
}
# @FUNCTION: perl-app_src_configure
-# @USAGE: perl-app_src_configure
# @DESCRIPTION:
# This is a wrapper function to perl-module_src_configure().
perl-app_src_configure() {
@@ -37,7 +35,6 @@ perl-app_src_configure() {
}
# @FUNCTION: perl-app_src_compile
-# @USAGE: perl-app_src_compile
# @DESCRIPTION:
# This is a wrapper function to perl-module_src_compile().
perl-app_src_compile() {
--
2.23.0
[gentoo-dev] [PATCH] prefix.eclass: minor @USAGE fix
Signed-off-by: Ben Kohler
---
eclass/prefix.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/prefix.eclass b/eclass/prefix.eclass
index 8ae3e3a531d..435e99fdf92 100644
--- a/eclass/prefix.eclass
+++ b/eclass/prefix.eclass
@@ -111,7 +111,7 @@ hprefixify() {
}
# @FUNCTION: prefixify_ro
-# @USAGE: prefixify_ro .
+# @USAGE:
# @DESCRIPTION:
# prefixify a read-only file.
# copies the files to ${T}, prefixies it, echos the new file.
--
2.23.0
[gentoo-dev] [PATCH] qmail.eclass: minor @USAGE fix
Signed-off-by: Ben Kohler
---
eclass/qmail.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/qmail.eclass b/eclass/qmail.eclass
index 150b6c00aab..8dd3ae99043 100644
--- a/eclass/qmail.eclass
+++ b/eclass/qmail.eclass
@@ -69,7 +69,7 @@ dospp() {
}
# @FUNCTION: dosupervise
-# @USAGE: dosupervise [ ]
+# @USAGE: [ ]
# @DESCRIPTION:
# Install runfiles for services and logging to supervise directory
dosupervise() {
--
2.23.0
[gentoo-dev] [PATCH] ruby-fakegem.eclass: function name typo fix & minor @USAGE fixes
Signed-off-by: Ben Kohler
---
eclass/ruby-fakegem.eclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass
index a6a7654f9e6..f75e1669b0c 100644
--- a/eclass/ruby-fakegem.eclass
+++ b/eclass/ruby-fakegem.eclass
@@ -207,7 +207,7 @@ ruby_fakegem_gemsdir() {
}
# @FUNCTION: ruby_fakegem_doins
-# @USAGE: file [file...]
+# @USAGE: [file...]
# @DESCRIPTION:
# Installs the specified file(s) into the gems directory.
ruby_fakegem_doins() {
@@ -217,8 +217,8 @@ ruby_fakegem_doins() {
) || die "failed $0 $@"
}
-# @FUNCTION: ruby_fakegem_newsins
-# @USAGE: file filename
+# @FUNCTION: ruby_fakegem_newins
+# @USAGE:
# @DESCRIPTION:
# Installs the specified file into the gems directory using the provided
filename.
ruby_fakegem_newins() {
@@ -262,7 +262,7 @@ ruby_fakegem_install_gemspec() {
}
# @FUNCTION: ruby_fakegem_gemspec_gemspec
-# @USAGE: gemspec-input gemspec-output
+# @USAGE:
# @DESCRIPTION:
# Generates an installable version of the specification indicated by
# RUBY_FAKEGEM_GEMSPEC. This file is eval'ed to produce a final specification
@@ -272,7 +272,7 @@ ruby_fakegem_gemspec_gemspec() {
}
# @FUNCTION: ruby_fakegem_metadata_gemspec
-# @USAGE: gemspec-metadata gemspec-output
+# @USAGE:
# @DESCRIPTION:
# Generates an installable version of the specification indicated by
# the metadata distributed by the gem itself. This is similar to how
@@ -282,7 +282,7 @@ ruby_fakegem_metadata_gemspec() {
}
# @FUNCTION: ruby_fakegem_genspec
-# @USAGE: output-gemspec
+# @USAGE:
# @DESCRIPTION:
# Generates a gemspec for the package and places it into the "specifications"
# directory of RubyGems.
@@ -327,7 +327,7 @@ EOF
}
# @FUNCTION: ruby_fakegem_binwrapper
-# @USAGE: command [path] [content]
+# @USAGE: [path] [content]
# @DESCRIPTION:
# Creates a new binary wrapper for a command installed by the RubyGem.
# path defaults to /usr/bin/$command content is optional and can be used
--
2.23.0
[gentoo-dev] [PATCH] s6.eclass: minor @USAGE fixes
Signed-off-by: Ben Kohler
---
eclass/s6.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/s6.eclass b/eclass/s6.eclass
index 32521515497..245df1e1118 100644
--- a/eclass/s6.eclass
+++ b/eclass/s6.eclass
@@ -48,7 +48,7 @@ s6_get_servicedir() {
}
# @FUNCTION: s6_install_service
-# @USAGE: servicename run finish
+# @USAGE: [finish]
# @DESCRIPTION:
# Install an s6 service.
# servicename is the name of the service.
@@ -75,7 +75,7 @@ s6_install_service() {
}
# @FUNCTION: s6_service_down
-# @USAGE: servicename
+# @USAGE:
# @DESCRIPTION:
# Install the "down" flag so this service will not be started by
# default.
@@ -97,7 +97,7 @@ s6_service_down() {
}
# @FUNCTION: s6_service_nosetsid
-# @USAGE: servicename
+# @USAGE:
# @DESCRIPTION:
# Install the "nosetsid" flag so this service will not be made a session
# leader.
--
2.23.0
[gentoo-dev] [PATCH] texlive-common.eclass: fix several @USAGE problems
Signed-off-by: Ben Kohler
---
eclass/texlive-common.eclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/eclass/texlive-common.eclass b/eclass/texlive-common.eclass
index e9a2eee65bd..b36be7a4db3 100644
--- a/eclass/texlive-common.eclass
+++ b/eclass/texlive-common.eclass
@@ -61,7 +61,7 @@ texlive-common_is_file_present_in_texmf() {
}
# @FUNCTION: texlive-common_do_symlinks
-# @USAGE: < src > < dest >
+# @USAGE:
# @DESCRIPTION:
# Mimic the install_link function of texlinks
#
@@ -99,7 +99,7 @@ texlive-common_do_symlinks() {
}
# @FUNCTION: etexlinks
-# @USAGE: < file >
+# @USAGE:
# @DESCRIPTION:
# Mimic texlinks on a fmtutil format file
#
@@ -117,7 +117,7 @@ etexlinks() {
}
# @FUNCTION: dobin_texmf_scripts
-# @USAGE: < file1 file2 ... >
+# @USAGE: [file2] ...
# @DESCRIPTION:
# Symlinks a script from the texmf tree to /usr/bin. Requires permissions to be
# correctly set for the file that it will point to.
@@ -133,10 +133,10 @@ dobin_texmf_scripts() {
}
# @FUNCTION: etexmf-update
-# @USAGE: In ebuilds' pkg_postinst and pkg_postrm phases
# @DESCRIPTION:
# Runs texmf-update if it is available and prints a warning otherwise. This
-# function helps in factorizing some code.
+# function helps in factorizing some code. Useful in ebuilds' pkg_postinst and
+# pkg_postrm phases.
etexmf-update() {
if has_version 'app-text/texlive-core' ; then
@@ -151,10 +151,10 @@ etexmf-update() {
}
# @FUNCTION: efmtutil-sys
-# @USAGE: In ebuilds' pkg_postinst to force a rebuild of TeX formats.
# @DESCRIPTION:
# Runs fmtutil-sys if it is available and prints a warning otherwise. This
-# function helps in factorizing some code.
+# function helps in factorizing some code. Used in ebuilds' pkg_postinst to
+# force a rebuild of TeX formats.
efmtutil-sys() {
if has_version 'app-text/texlive-core' ; then
--
2.23.0
[gentoo-dev] [PATCH] udev.eclass: minor @USAGE fixes
Signed-off-by: Ben Kohler
---
eclass/udev.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index baf60584938..2873ae9a92c 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -80,7 +80,7 @@ get_udevdir() {
}
# @FUNCTION: udev_dorules
-# @USAGE: rules [...]
+# @USAGE: [...]
# @DESCRIPTION:
# Install udev rule(s). Uses doins, thus it is fatal in EAPI 4
# and non-fatal in earlier EAPIs.
@@ -95,7 +95,7 @@ udev_dorules() {
}
# @FUNCTION: udev_newrules
-# @USAGE: oldname newname
+# @USAGE:
# @DESCRIPTION:
# Install udev rule with a new name. Uses newins, thus it is fatal
# in EAPI 4 and non-fatal in earlier EAPIs.
--
2.23.0
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
On Fri, Jan 23, 2015 at 4:38 PM, Michał Górny wrote: > > 3. Put it in an ebuild, after all. This will add a lot of complexity > but GPG comes for free, plus some people will actually test > and stabilize it. > > I think this should be in an ebuild. You mentioned that it's only needed ONCE, but it's needed ONCE for everytime one install gentoos, along the same lines as mirrorselect. A couple of years from now, do we want users to have to dig through several dozen old news items to get this tool? I know the ebuild's a bit of extra work but then the python issues can also be properly handled. And bugs can be properly handled, etc etc. -Ben
Re: [gentoo-dev] why is a line in /usr/portage/profiles/base/package.use.mask ignored?
On Wed, Feb 25, 2015 at 5:23 AM, wrote: > Hello *, > > dev-lisp/ecls-15.2.21 does not compiled with USE=cpu_flags_x86_sse. So, > I've added the line > > =dev-lisp/ecls-15.2.21 cpu_flags_x86_sse > > to .../profiles/base/package.use.mask. But I still see > > dns ~ # emerge -pv dev-lisp/ecls > [ebuild R] dev-lisp/ecls-15.2.21:0/15.2.21::gentoo > [15.2.21:0/15.2.21::grozin] USE="X emacs libatomic%* threads unicode -debug > -gengc -precisegc" CPU_FLAGS_X86="sse*" 0 KiB > > Why isn't sse masked? > > Andrey > > This is because these cpu_flags_x86_* flags are masked globally in profiles/base/use.mask then unmasked where they're valid, like in profiles/arch/amd64/use.mask. So that later (global) unmask overrides your package-specific mask in the base profile. If you add your package.use.mask entry in profiles/arch/amd64/package.use.mask then I believe it should work. -Ben
Re: [gentoo-dev] do we need special elog messages for bindist?
On Wed, Feb 25, 2015 at 1:38 PM, Mike Gilbert wrote: > > > I would like to remove the elog for a couple of reasons: > > 1. The use flag description is there for whoever cares to read it. > There is no need to alert the user every time. > 2. We are not lawyers, and I have no business giving legal advice > about patent law which varies from country to country. > > To take it one step further: I think it would make more sense to call > the flag "h264" or something similar. We could then set > RESTRICT="h264? ( bindist )" if we want to give some indication that > it is not appropriate for binary redistribution. > > What you're saying here makes sense and I agree, but our users are already pretty confused about USE=bindist... what it does, why it's enabled by default, etc. If this is going to stay enabled by default in our stage3s (there's an open bug about possibly changing that) then I really think we should add a paragraph to the handbook that explains things. It seems that most new users don't have any idea what bindist is until they find some feature missing or they hit the classic openssl/openssh blocker and someone has to explain the whole thing to them. So in summary, let's get rid of the per-ebuild einfo warnings but let's educate the users about USE=bindist earlier. -Ben
Re: [gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7
On Sun, Jul 5, 2015 at 2:25 PM, Sebastian Pipping wrote: > > > I really wonder if there is any update path from having > > dev-qt/qtcore-4.8.6-r2 > dev-qt/qtgui-4.8.6-r4 > > installed before to > > dev-qt/qtcore-4.8.7 > dev-qt/qtgui-4.8.7 > > > > Usually this kind of conflict happens when for SOME reason, at least one part of the dev-qt/*:4 collection is not being pulled into the depgraph, like if there's one qt* package which is now orphaned/depcleanable. If even one piece is not pulled into the dep list, it will try to hold all the rest of the pieces back at 4.8.6. Something like this may help, to just force all installed qt4 pieces to upgrade, regardless of whether they are deps of anything: emerge -1av $(qlist -ICS dev-qt/ | grep 4$) Another possibility for a conflict is if you have some package.use entries for dev-qt/ that are too version specific, where the upgraded 4.8.7 version of some component would not meet the USE requirements of some reverse dep. Then it'd lock that one component at 4.8.6 and again it's game-over for the upgrade. Hope this helps, Ben Kohler (iamben @ Freenode)
Re: [gentoo-dev] LibreSSL import plan
On Tue, Sep 29, 2015 at 8:43 AM, hasufell wrote: > On 09/29/2015 03:32 PM, Rich Freeman wrote: > > [...] > > I have waited 9 days. I don't see a reason to wait another few weeks, > just because you like to bikeshed a lot. > > I honestly feel like you are wasting my time, unless _you_ can come up > with a better solution and offer to do the actual work. > > So far, no one has worked much on libressl, except me, blueness, hannob > and a few community contributors (like Aric Belsito). > > That said, I will go ahead with my work now. If you have something to > actually contribute, please ping me. > > It makes me sad to see how you treat your fellow developers. I apologize in advance for wasting more precious seconds of your time reading this. -Ben
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
On 7/8/21 6:54 AM, Michael Orlitzky wrote: On Wed, 2021-07-07 at 22:01 -0700, Matt Turner wrote: Enable these flags by default, since they effectively add no additional dependencies: Why? This list should be getting smaller, not larger. That's a valid opinion/viewpoint, but it's not a fact. Someone may have wanted these features to be optional, but that doesn't automatically imply that they should be disabled for everyone out of the box. Not everyone wants minimalism, some people want the expected features to just be enabled by default. -Ben
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
On 7/12/21 10:30 AM, Peter Stuge wrote: Matt Turner wrote: If you can find a case where you wouldn't want to enable one of these USE flags, please let me know and I'll reconsider my position. My catalyst spec files all have use: -* foo bar x y z specifically because the defaults are never what I want for any given system. I build desktops, servers, containers, VM appliance images and embedded system, and I know what I want in each one. Especially the latter frequently have only very few USE flags set and I want zero extra dependencies. I think you're making a great argument that you'd be completely unaffected by any of the suggestions in this thread. I don't consider needing "use: -*" at all a desirable situation. This catalyst warning might support that: Warning!!! The use of -* in $stage/use will cause portage to ignore package.use in the profile and portage_confdir. You've been warned! I see it as a shortcoming of the standard profiles that I have to essentially create my own in order to get what I want, as opposed to being able to build upon something truly minimal. I'd claim most of these packages' bzip2/lzma/zstd USE flags should be removed in favor of statically enabling them That is the direct opposite of Gentoo's single most core value: choice Choice makes sense when there's a legitimate trade-off to be made. I explained that and why I frequently do not want those USE flags set, demonstrating that I want choice here. You can of course dismiss any concern which disagrees with your opinion as illegitimate. Please do not bother asking questions if that's your style. Choice isn't dogma. Is there a difference between dogma and value? I understand choice to be a core value in Gentoo. Maybe that's wrong (now)? Core values are more important than pretty much anything else. Choice isn't always possible. That's not this case. If choice is indeed a core value then where choice is pretty easy (this case) in my mind there needs to be an overwhelmingly strong argument to conciously and intentionally disable choice. Just don't do it. Kthx. This kind of thing is nothing but irritating. Please don't do this. I'm sorry if it wasn't clear that "Just don't do it. Kthx." meant exactly what you wrote: This kind of thing (increase default USE-flags) is nothing but irritating. Please don't do this. Kind regards //Peter Hi Peter, Nobody is "disabling choice" here, a change in defaults doesn't remove your ability to choose something else. And I understand your sentiment that adding more default-on flags goes against YOUR goals of a minimal gentoo, but I'd like to remind you and others that this minimalism is not the goal of every gentoo user. More default features might irritate you and other minimalists, but it may significantly improve the gentoo experiences of everyone else. I want to be clear that I'm not saying you are wrong, but remember that your perspective is not the only correct one on this topic. -Ben
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
On 7/12/21 12:25 PM, Michael Orlitzky wrote: We've kept things the same level of difficulty for one group of people, but made them much harder for another. In no situation can anyone who wants everything enabled have a harder time than 'adds USE="bzip2 lzma zstd" to make.conf', but everyone else suffers to some degree. That's discouraging choice overall. Point taken. If IUSE="-flag" were actually common in reality, I'd use it as evidence that MY way is better, but alas.. =) -Ben
Re: [gentoo-dev] https://packages.gentoo.org/ - lag
On 9/10/21 5:42 AM, Jaco Kroon wrote: So just wondering how frequently packages.gentoo.org updates? https://bugs.gentoo.org/811801 -Ben
