Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Eddie Chapman wrote: > Michał Górny wrote: >> On Sat, 2024-03-30 at 14:57 +, Eddie Chapman wrote: >> >>> Note, I'm not advocating ripping xz-utils out of tree, all I'm saying >>> is wouldn't it be nice if there were at least 2 alternatives to choose >>> from? That doesn't have to be disruptive in any way, people who wish to >>> continue using and trusting xz-utils should be able to continue to do so >>> without any friction whatsoever. >> So, you're basically saying we should go out of our way, recompress all >> distfiles using two alternative compression formats, increase mirror load >> four times and add a lot of complexity to ebuilds, right? >> >> -- >> Best regards, >> Michał Górny >> > Yes that's a very good point, that was something I was wondering in > weighing up both sides, what the costs would be practically, as I don't > know the realities of running Gentoo infrastructure. And maybe the costs > is just too high of a price to pay. > > I wonder if increased use of git repos rather than distributed tarballs > could be part of a solution to those issues, although that could put quite > a storage burden on every user. Unless they were all shallow git pulls and > the user could optionally choose to tar up the git directory after clone > with compression. But yes granted then there is even more ebuild > complexity. > > > . > There is a lot of unknowns out there. From what I've read, the person responsible for writing the code inserted this hack. There may be no way to prevent this. Basically, the person that should have been trusted with this code violated that trust. Why is unknown but I'm as curious about that as anything. It's like when someone goes to a grocery store to buy a tomato. They want organic and there is a organic sticker on the tomato. You either trust that sticker, and the person/company who put it on there, or you don't trust that sticker at all and avoid buying all tomatoes. The trust starts with the person/company that puts that sticker on the tomato. The person who was trusted with that code, broke that trust. There is likely hundreds of packages out there in the exact same position. Any package that has few or only one person writing the code can do the same thing. While this should be analyzed as more info comes in, right now, we should let the devs get us back to as safe a place as possible. Since it appears to affect systemd users who don't use Gentoo, which is a huge target, they certainly need to react as quickly as they can to the devs actions. Let's just not overreact just yet. The devs has rolled back to a safe, safer, version. Let time and more info sort this out. If it is needed, xz will go away, which shouldn't come as a surprise. I'm sure the person who did this will never get that trust back. Long term, this is going to be interesting to see what all gets revealed. The why is one thing. Another is how to prevent if it can be at all. I'm going back to my hole now. Dale :-) :-) P. S. Links that some may want to follow, instead of a -dev thread. https://bugs.gentoo.org/928134 https://forums.gentoo.org/viewtopic.php?p=8821925
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
orbea wrote: > On Sat, 30 Mar 2024 03:07:13 - > "Eddie Chapman" wrote: > >> Given what we've learnt in the last 24hrs about xz utilities, you >> could forgive a paranoid person for seriously considering getting rid >> entirely of them from their systems, especially since there are >> suitable alternatives available. Some might say that's a bit >> extreme, xz-utils will get a thorough audit and it will all be fine. >> But when a malicious actor has been a key maintainer of something as >> complex as a decompression utility for years, I'm not sure I could >> ever trust that codebase again. Maybe a complete rewrite will emerge, >> but I'm personally unwilling to continue using xz utils in the >> meantime for uncompressing anything on my systems, even if it is done >> by an unprivileged process. >> >> I see that many system package ebuilds unconditionally expect >> app-arch/xz-utils to be installed simply to be able to decompress the >> source archive in SRC_URI. So simply specifying -lzma on your system >> isn't going to get rid of it. >> >> No one could have been expected to foresee what's happened with >> xz-utils, but now that it's here, perhaps Gentoo (and other projects >> that do) should consider not relying on a single decompression >> algorithm for source archives, even just as an insurance against some >> other yet unknown disaster with one algorithm or another in future? >> >> And yes I'm sure there will be individual packages that currently >> absolutely need xz-utils installed during the build process, and one >> or two that absolutely have to have it available at runtime, but those >> bridges can be crossed as and when. >> >> Eddie >> >> > I think this is an overreaction and we should wait for the dust to > settle before making drastic disruptive changes. > > >From the news item email: "Impact == Our current understanding of the backdoor is that is does not affect Gentoo systems, because 1. the backdoor only appears to be included on specific systems and Gentoo does not qualify; 2. the backdoor as it is currently understood targets OpenSSH patched to work with systemd-notify support. Gentoo does not support or include these patches; Analysis is still ongoing, however, and additional vectors may still be identified. For this reason we are still issuing this advisory as if that will be the case." When I started reading it, I was concerned as well as I know it is used on my system. However, when I got to the part about it not likely to affect Gentoo, my level of concern dropped significantly. If this is still true, there's no need to be concerned. If things has changed and it does affect Gentoo, I'm sure there will be changes made that will either fix the issue for good or at least provide a workaround until a solution is found. Gentoo has some awesome devs. Someone will find a solution. I notice that it has already been changed in the tree to a version that does not have the malicious code. That alone should be a solution until a new plan is made. While I'm a little concerned and hope for a proper solution, I'm not to worried. I certainly don't think we should overreact this early. Give the devs and upstream time to work this out. Just a users opinion. Dale :-) :-)
Re: [gentoo-dev] last rites: sys-fs/eudev
Sam James wrote: > Oskari Pirhonen writes: > >> [[PGP Signed Part:Undecided]] >> On Wed, Sep 13, 2023 at 03:10:51 -0500, Dale wrote: >>> Andrew Ammerlaan wrote: >>>> And then another thing, how is it possible that so many people missed >>>> the news item? They are displayed quite prominently I think, and >>>> emerge will keep buggering you about it until it is marked as read. >>>> Just wondering if there is something that can be improved here. >>>> >>>> Best regards, >>>> Andrew >>> >>> I'm pretty good at reading the news items. I seem to recall that you >>> see one only if it affects you, you have a package installed or >>> something. So, if it shows up, it is best to take notice. That said, I >>> don't recall seeing the news item either. I can't imagine me missing it >>> but I also can't imagine me not taking action either. After all, (eu)dev >>> is a important package. >>> >>> One thing is for sure, the name is rather obvious. The first word in >>> the title is eudev. I have yet to figure out how I missed it. Given >>> the number of people who did, could there have been a glitch and it >>> didn't show for some weird reason? Has someone who understands the code >>> checked to see if there was some typo that made it not show for most >>> users? >>> >>> I do think this is worth looking into. It just seems odd. >>> >> It's not impossible for a news item to have bugs. >> >> Somewhat recently, when the hardened toolchain changes were being made, >> a news item was sent out recommending an `-e @world`. I knew it was >> coming because I saw the drafts of the news item here (as well as >> discussion on irc), so I was surprised when I didn't see it on my >> laptop on the day of. But I did see it on my work machine. >> >> We managed to track it down to my work machine using the hardened >> profile whereas my laptop is using the hardened/selinux profile, and >> Portage didn't quite catch that as being relevant for both. > FTR: since then, the Portage logic got fixed but I also used it as > impetus to implement a bunch of tests for the news item logic which > would've caught this and a few other problems. > > But definitely possible this happened here. > >> - Oskari >> >> [[End of PGP Signed Part]] > Maybe this won't happen again since some changes have been made. Could be there was a glitch at that time. I also monitor -dev so that I can have a heads up for future changes. That said, I usually wait until I see the news item to actually take action. Sometimes there may need to be changes in the tree before taking action. When the news item shows up, those changes are usually made. It's time to act on it. Thanks for the info. Dale :-) :-)
Re: [gentoo-dev] last rites: sys-fs/eudev
Andrew Ammerlaan wrote: > > And then another thing, how is it possible that so many people missed > the news item? They are displayed quite prominently I think, and > emerge will keep buggering you about it until it is marked as read. > Just wondering if there is something that can be improved here. > > Best regards, > Andrew I'm pretty good at reading the news items. I seem to recall that you see one only if it affects you, you have a package installed or something. So, if it shows up, it is best to take notice. That said, I don't recall seeing the news item either. I can't imagine me missing it but I also can't imagine me not taking action either. After all, (eu)dev is a important package. One thing is for sure, the name is rather obvious. The first word in the title is eudev. I have yet to figure out how I missed it. Given the number of people who did, could there have been a glitch and it didn't show for some weird reason? Has someone who understands the code checked to see if there was some typo that made it not show for most users? I do think this is worth looking into. It just seems odd. Dale :-) :-)
Re: [gentoo-dev] last rites: sys-fs/eudev
Alexe Stefan wrote: > On 9/13/23, Dale wrote: >> Alexe Stefan wrote: >>> While my posts may be a little bit inflammatory, no one pointed out >>> where I'm wrong. >>> I don't hate gentoo, but I don't want choice to be taken away from users. >>> If we(the users) only respond to issues that individually impact us, >>> choice will be taken away from everyone eventually(unless it's the >>> "right" choice as agreed by Lennart & co). It is called "divide and >>> conquer". >>> I do not hate gentoo. I want to see it offer as much choice as >>> possible, not restrict it. >>> I had to bear with systemd for some time before going to gentoo. I >>> don't want that to happen again. >>> >>> >> I'm a eudev user. I don't like systemd either. I'm actually having to >> deal with it for the first time after installing Ubuntu for a NAS box on >> a under powered rig with not a lot of memory. I can honestly say, I >> don't like systemd from experience. I'm one who will likely have to >> switch to udev even tho I don't care too. While I'm not excited about >> it, given the lack of coders wanting to keep it alive, I'll just have to >> switch. I may be losing a choice but hey, at least I had one that other >> distros never had. Some distros switched with no alternative long ago. >> >> If I, someone who hates change, can change, I'm not sure why you can't >> accept that eudev just may have reached its end of life on Gentoo. I >> missed the news item a year or so ago. I had no idea it was not being >> maintained on Gentoo. This sort of hit me all at once, most likely the >> same as you. Unless someone steps up in the next week or so, I'll be >> switching. At the least, I'm grateful to have OpenRC. Don't get me >> started on trying to figure out how to restart a service on Ubuntu. As >> bad as all the compiling is, Gentoo is a walk in the park. Restart a >> service, /etc/init.d/> are close>. Try that in Ubuntu. Forget a hair cut this month. I'm >> doing good to have hair. :@ Let's see what happens and if eudev dies, >> let's accept it and be grateful for the time we did have a choice, while >> some kinks got worked out of systemd udev at least. >> >> To the other devs reading this thread still. Thanks much from a 20 year >> user of Gentoo. It was bumpy at first but it sure has come a >> LNG ways. I can't say enough about how much emerge has improved >> and how dependencies are resolved with ease for us users. The work on >> the emerge command and ebuilds has improved a LOT. I still wish the >> error output was more friendly but hey, at least there is a whole lot >> less of it. :-D >> >> Let's deal with what is in front of us. Thanks again to the devs. >> >> Dale >> >> :-) :-) >> >> I'm going back to my hole now. >> >> > I do deal with what is in front of us. Today it's eudev. Tomorrow will > be opentmpfiles or openrc. > > And if they are no longer maintained, then what? Post a lot of replies on a mailing list? The point is, right now no one is wanting to maintain eudev. There are a lot of packages that get removed for the exact same reason. Some are no longer useful to anyone, some just don't have anyone to maintain regardless of whether anyone uses them or not. Once they are no longer maintained and things start to break, they get removed. Only if someone steps up to maintain a package, does that package get to live. It's been that way for many years. The packages you gave as examples, will likely have their day as well, one day. I don't think any of your posts has changed that fact. In all honestly, if anyone was interested in stepping up and at least trying to maintain eudev, they most likely aren't now. After all, if they stop maintaining eudev later for whatever reason, they have you to look forward too. I'm sure several devs have your messages sent straight to the trash. One posted as much. You are not accomplishing anything, likely even hurting yourself. I think I'm done here too. Dale :-) :-)
Re: [gentoo-dev] last rites: sys-fs/eudev
Alexe Stefan wrote: > > While my posts may be a little bit inflammatory, no one pointed out > where I'm wrong. > I don't hate gentoo, but I don't want choice to be taken away from users. > If we(the users) only respond to issues that individually impact us, > choice will be taken away from everyone eventually(unless it's the > "right" choice as agreed by Lennart & co). It is called "divide and > conquer". > I do not hate gentoo. I want to see it offer as much choice as > possible, not restrict it. > I had to bear with systemd for some time before going to gentoo. I > don't want that to happen again. > > I'm a eudev user. I don't like systemd either. I'm actually having to deal with it for the first time after installing Ubuntu for a NAS box on a under powered rig with not a lot of memory. I can honestly say, I don't like systemd from experience. I'm one who will likely have to switch to udev even tho I don't care too. While I'm not excited about it, given the lack of coders wanting to keep it alive, I'll just have to switch. I may be losing a choice but hey, at least I had one that other distros never had. Some distros switched with no alternative long ago. If I, someone who hates change, can change, I'm not sure why you can't accept that eudev just may have reached its end of life on Gentoo. I missed the news item a year or so ago. I had no idea it was not being maintained on Gentoo. This sort of hit me all at once, most likely the same as you. Unless someone steps up in the next week or so, I'll be switching. At the least, I'm grateful to have OpenRC. Don't get me started on trying to figure out how to restart a service on Ubuntu. As bad as all the compiling is, Gentoo is a walk in the park. Restart a service, /etc/init.d/. Try that in Ubuntu. Forget a hair cut this month. I'm doing good to have hair. :@ Let's see what happens and if eudev dies, let's accept it and be grateful for the time we did have a choice, while some kinks got worked out of systemd udev at least. To the other devs reading this thread still. Thanks much from a 20 year user of Gentoo. It was bumpy at first but it sure has come a LNG ways. I can't say enough about how much emerge has improved and how dependencies are resolved with ease for us users. The work on the emerge command and ebuilds has improved a LOT. I still wish the error output was more friendly but hey, at least there is a whole lot less of it. :-D Let's deal with what is in front of us. Thanks again to the devs. Dale :-) :-) I'm going back to my hole now.
Re: [gentoo-dev] last rites: sys-fs/eudev
Eli Schwartz wrote: > On 9/12/23 3:05 PM, orbea wrote: >> On Tue, 12 Sep 2023 14:51:34 -0400 >> Matt Turner wrote: >>> Conspiracy alert! >>> >>> It's been more than 2 years since >>> https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html >>> >>> >>> People have had plenty of time. More chances than were fair have been >>> given. Nothing has changed, except eudev has further diverged from >>> upstream udev. >>> >> >> Unfortunately this flew under the radar for a lot of people, when I >> asked Sam about this on irc a while ago I was informed (As I >> understood) that eudev was still going to be an option into the future >> and as the ebuild was still getting updates I never considered this is >> how the core Gentoo devs felt. > > It sounds to me like the last-rite system has worked and achieved the > desired goal then. It is no longer flying under the radar, and for > people who use eudev and wish to see it be a supported option, a fire > has been lit under them to get involved. > > Do keep in mind that based on commit history the only person that > cares about eudev at all for years now is Sam, and that's apparently > out of mere obligation. He is not listed as an eudev project member or > package maintainer, the actual eudev project should likely acknowledge > reality and disband in order to more effectively communicate their > intent. > > None of this is or ever was sustainable -- do not expect people who > don't use a thing, aren't willing to maintain a thing, but intercede > out of obligation to be an effective maintainer or be willing to do so > in perpetuity. > > If I had to take a wild guess, "it is still going to be an option into > the future" actually meant "we aren't ready to treeclean it yet, > people still use it, so we're gonna see how low-effort it is to keep > it limping along without any maintainers but also maybe someone would > like to maintain it". > > Sure enough, the total lack of gentoo maintainers for this package > meant that once people who were engaging with ebuild updates *purely* > out of a sense of obligation could no longer justify continuing to do > so when the package wasn't compatible with its reverse dependencies, > those people decided that it was time to step down. > > It's great to see people who do care and actually use the software, > step up in their place. > > Picking fairly random message to reply too. I'm a regular user, for some 20 years now. I'm also a eudev user at the moment. I'm also not a fan of systemd and friends. It's why I started using eudev long ago. So, like eudev, not much on systemd stuff and currently use eudev. With that info shared, this is my take on this. It seems that while eudev is alive upstream for other distros, no one cares to maintain it on Gentoo anymore because it doesn't serve a purpose other than avoiding systemd. While I kinda like that purpose, I'm not maintaining eudev either. If no one steps up and pinky swears to maintain eudev, it will and should be removed from the tree. After all, this is about 2 years past due it seems. While I wish someone would maintain eudev, I'm not going to jump up and down demanding or even implying someone should do so. It sounds like it was easier in the past to maintain it but upcoming changes is going to make that more time consuming and require more work. It appears no one is yet willing to take that effort on. In my opinion, this thread has raised the awareness of the eudev situation long ago. If no one steps up, then it is time to retire eudev and all of us eudev lovers will just have to switch. This is just the way FOSS works sometimes. I recall switching from udev to eudev. It was as simple as unmerge one, emerge the other. I assume it will be pretty simple and straight forward this time to do the reverse. I did see somewhere that one should check configs and make sure there is no systemd/udev entries, in case it masks or prevents something from being installed. I already checked mine. My vote, give it time. If someone steps up, great. If not, we just have to switch to udev and move on. Debating it even more is unlikely to change anything and may even send some running away. I just wish we knew just how many people actually used eudev. Based on this thread, I know of 2. I know one of them can't code. That's me!! ;-) My $0.02 worth. Dale :-) :-)
Re: [gentoo-dev] last rites: sys-fs/eudev
orbea wrote: > On Mon, 11 Sep 2023 17:29:47 +0200 > "Andreas K. Huettel" wrote: > >> Am Montag, 11. September 2023, 17:22:43 CEST schrieb orbea: >> >>> Upstream is maintained still. >>> >>> https://github.com/eudev-project/eudev >>> >> No, it's not. >> >> > Based on what? It has several commits this year and is currently > working on both of my systems. Is there something specific showing why > its not maintained? > > . > On the link above it says this: On 2021-08-20 Gentoo decided to abandon eudev and a new project was established on 2021-09-14 by Alpine, Devuan and Gentoo contributors (alphabetical order). It seems to have a upstream that is active but no one is maintaining it on Gentoo. Basically, it needs a Gentoo maintainer now. It would seem given the time span that no one wants to take it. Like others, I use it but didn't know it wasn't maintained anymore. I hope someone will step up but if not, looks like we have to use udev. Dale :-) :-)
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
Georgy Yakovlev wrote:
> Hi,
>
> I've been approached multiple times with that request, and a lot of
> time I see new users completely destroyed by rust build time and disk
> space requirements.
>
> WDYT about switching order of rusts in a virtual?
>
> RDEPEND="|| (
> ~dev-lang/rust-${PV}
> ~dev-lang/rust-bin-${PV}
> )"
>
>
> becomes
>
> RDEPEND="|| (
> ~dev-lang/rust-bin-${PV}
> ~dev-lang/rust-${PV}
> )"
>
>
> Existing installs should be unaffected ofc.
> But portage may prefer to depclean rust and not rust-bin if both are
> present.
> Users who wish to use source version at all times can just add it to
> world file.
>
> I see both positives and negatives of doing that, but would like to
> reach out to community first.
>
> Thanks!
>
> --
> Georgy
>
>
As a user, if I recall correctly, if a user wants rust-bin, all they
have to do is emerge -1 rust-bin and then let whatever package pull in
the virtual for rust. The virtual will be satisfied and rust-bin will
be used. From my understanding, that is the purpose of virtuals,
allowing users to pick what they want to use to satisfy the
requirement. I wouldn't want either rust in my world file as it is not
a package I use directly. It should be a dependency of another package,
such as Firefox. To me, this sounds like there should be a note added to
a install guide so new users are aware of this, provided it isn't
already mentioned.
Gentoo is known for compiling from sources. Defaulting to a package
that is a binary but available as a package from source that requires
compiling, that would be unexpected.
Just my $0.02 worth, as a user.
Dale
:-) :-)
Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage
Roy Bamford wrote: > On 2022.01.05 20:22, Sam James wrote: >> >>> On 5 Jan 2022, at 19:02, Roy Bamford >> wrote: >>> Sam, >>> >>> Do users with FEATURES=distcc still have to opt out of this >>> MAKEOPTS clamping? >>> >> Great point! I think we could add an exemption for that and make it a >> noop or warning-only. >> >> Best, >> sam >> >> > > Sam, > > You are building a better mousetrap here. That's not a reason to try. > > Do users of I_KNOW_WHAT_I_AM_DOING, who have already > opted to shoot themselves in both feet, get a free pass here? > > There are users who run emerge --jobs=X with MAKEOPTS='-jY" > and get firefox, thunderbird and libreoffice all building concurrently > as they allow X * Y MAKE threads, reduced by this proposed > throttling, still triggering the OOM. > > I don't think you can head that off beforehand. > As a user, can I get a large +1 to that. For me, it is usually Seamonkey, Firefox, Libreoffice, that big qt package or some combination of two or more of them. I've had times where all of those just happen to upgrade at the same time. My solution was to put those on spinning rust while using tmpfs for everything else and if needed, using --exclude to put off one or more of them then do those later. While I like the general idea of this, and would love to see emerge be able to handle it without failures, I'm not sure how emerge or it's options can prevent it without slowing down other packages. My thinking, have emerge trigger when certain packages are in the upgrade list and only allow one package in that list to update at a time. For example. If Firefox, Libreoffice and that qt package are in the list of upgrades, whichever hits first causes the others to wait until the first one is done. That will make it so only one large package is being upgraded at a time and be able to have fast settings for other smaller and less memory hungry packages as well. How to do that, I'm not a coder so no idea but I know there are some awesome coders here who may can find a way. If that idea is even something that could be done. Since I rarely post here, keep up the great work. :-D Dale :-) :-)
Re: [gentoo-dev] Last-rites: app-admin/lastpass-cli
Gokturk Yuksek wrote: > # Göktürk Yüksek (2021-03-14) > # Dead upstream. No revdeps. > # Removal in 60 days to allow people extra time > # for transitioning out. Bug #776262. > app-admin/lastpass-cli > > Due to recent changes to Lastpass, I switched to Bitwarden. It may be worth mentioning somewhere that you can export from Lastpass and import to Bitwarden and not lose any passwords. My switching took about 5 minutes, some of which is downloading the sources and add-ons. Thought it worth a mention. Dale :-) :-)
Re: [gentoo-dev] [RFC] Codec project
Kent Fredric wrote: > On Wed, 10 Jun 2020 20:25:20 +0200 > Michał Górny wrote: > >> The general purpose of codec project [2] is to maintain core libraries >> for various multimedia format encoder/decoder libraries. It's like >> gfx+sound+video except only for core packages and not every possible >> single viewer, player, editor, frontend... I believe that this specific >> focus make more sense than the wider projects, i.e. it is more likely >> than N people will actually co-maintain libraries used by many tools vs >> N people co-maintain 20 alternative sound players (when they are >> unlikely to use more than one at a time). > Somehow I get the impression that "codec" as a scope is still too general. > > For instance, people well acquainted with audio codecs aren't > necessarily well acquainted with video codecs, or image codecs. > > A package that only does audio-playback for instance, won't be of > interest to somebody who predominantly cares about video playback. > > I'm not entirely against it as a concept as-is, I just suspect it will > reiterate the previous problem. As a user, how about media? Multimedia? Or would those interfere with other packages? I might add, regardless of name, will it be active enough to keep it alive or will it go the same as the last? Dale :-) :-)
Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
Piotr Karbowski wrote: > Hi, > > On 26/05/2020 00.34, Philip Webb wrote: >> I'ld rather you didn't. > You didn't provided any rationale for that. Running X as root is anti > pattern, especially nowadays when so little effort is required to not > have to run it as root. > > You can either enable elogind, or you can enable suid if you want to > preserve your status quo, we're talking here about defaults that user > can change if he has a reason to do so. > > -- Piotr. > As a user. [ebuild R ] x11-base/xorg-server-1.20.7:0/1.20.7::gentoo USE="elogind ipv6 libglvnd suid udev xorg -debug -dmx -doc -kdrive -libressl -minimal (-selinux) -static-libs -systemd -unwind -wayland -xcsecurity -xephyr -xnest -xvfb" I don't recall the security issue that setting comes with. As a user, I'd rather defaults be secure and if I need to make a exception, then I can do so locally. I use elogin, used the other method until the recent change, so I likely don't need it set this way. If I understand this correctly, I'm going to disable suid and use the more secure method. I think it is reasonable since most likely, most users would expect the more secure method as a default and use a login tool that works with that setting. Those who use some other method, such as manually starting X, they still have the option to set it in whatever way works for them. I do agree with the point in another post that there should be some sort of notice about the change. One that is easily seen since it can cause problems. In the middle of typing, I made the change and ran into no problems so far. I restarted the GUI and logged in just fine. Just a users perspective. Dale :-) :-)
Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)
Georg Rudoy wrote: > On 02.05.2020 at 20:30 user Andreas K. Hüttel wrote: >> I'm hereby volunteering to clean things up. But - I'll go the brutal way: >> >> * Legacy boot and MBR will get kicked out. * >> >> This is your chance to protest or support. > I just installed Gentoo last month on an AMD64 machine that was booted in > legacy mode > and I had no control over that as far as I can tell. > That was a very recent, freshly ordered Ryzen 3700 Hetzner server. > > Dunno if such anecdotical evidence proves anything though. > > My system is not to old and would need legacy as a option as well. I actually picked one that didn't do EFI and such. I'd be fine with a link to another page tho. It may make it easier for everyone else while those of us with legacy can still get to the info. Users point of view. Dale :-) :-)
Re: [gentoo-dev] separate /usr without initramfs
William Hubbs wrote: > Hi Dale, > > I would like to call your attention to a couple of things in my message. > > On Fri, Oct 25, 2019 at 01:40:10PM -0500, Dale wrote: >> William Hubbs wrote: > *snip* > >>> I want to hear from people who have / and /usr on separate partitions >>> and who are not using an initramfs. >>> >>> If you are in this group, I have a very specific question. Why aren't >>> you using an initramfs? > *snip* > >> I have a separate /usr among others and always have. The reason I do >> that, /boot and / are normal partitions but everything else is LVM. I >> can adjust the size of everything BUT /boot and /. At the time I did >> that, the init thingy was not needed if I recall correctly. I might >> add, I've had to grow /usr and /var a couple times. Before LVM, it >> meant copying over to another drive, repartitioning and then restoring >> to the old drive. Time consuming and one wrong command could ruin a >> install. >> >> While I have a init thingy, I do not like it. I've had a couple >> failures already with those things. Luckily I keep older kernels and >> such for that. If I had my wish, I would not need a init thingy, ever. >> It's just one more thing that can cause problems. There's already more >> than enough things that can break. While I understand the problem comes >> from upstream, I still think it sucks. It's easy enough to have a >> unbootable kernel as it is. Adding another layer for booting to fail >> should be avoided. BTW, I use dracut. I tried to build it other ways >> but couldn't get it to work. Bad thing is, when one fails even built >> with dracut, I have no clue how it works really so no idea how to fix >> other than using a older kernel or just rerunning dracut and hoping for >> the best. > > You just stated that you have an initramfs, so you did not thoroughly > read my message. I specifically asked to hear from folks who aren't > using one. All of this is irrelivent since you are. > >> I'm also not looking forward to the other situation you mentioned >> either. At some point, having separate partitions won't be easy with or >> without a init thingy. I can't easily resize / without reworking the >> whole thing. > > Like I said above, separate partitions without an initramfs has been > broken for many years. We have been doing some downstream hacking that > made it work for some people. You are obviously not one of those people > since you use an initramfs. > > Can you please not add irrelivent noise to this thread? > > William I did read your message. The reason I posted, I wish I did NOT have to have one and I was in the situation you describe. From what people post, here and elsewhere, my system may not boot without one. So, if it is possible to NOT have a init thingy, I'd love to see that supported. I might also add, I originally thought this was on -user not -dev. I did see that wrong. Dale :-) :-)
Re: [gentoo-dev] separate /usr without initramfs
William Hubbs wrote: > Hey all, > > I have been advised to bring this topic back to the list before taking > any action, so here it is. > > First, I need to clarify what I'm *NOT* talking about. > > This discussion has nothing to do with whether or not you have the > split-usr use flag turned on; all of us officially have that on because > /bin, /lib* and /sbin are directories in the official Gentoo setup. In > other words, I am *not* talking about forcing the /usr merge. > > Unfortunately, the concept of separate usr has gotten wrapped up in the > split-usr use flag and doesn't have to be. For the record, I mean something > very specific when I say "separate usr". I am talking about the situation > where /usr is a mount point separate from /, so in this thread, let's stick > to "separate usr" for that situation. I am *not* even saying that using > separate usr is wrong or unsupported. You can even run separate usr with > split-usr turned off if you would like to do so. > > Now for the use case I want to talk about, and that is using separate > /usr without using an initramfs to boot your system and pre-mount /usr. > > If you do this, many things are broken, and this is why the binary > distros all use an initramfs if you do this. This configuration is also > unsupported officially in Gentoo [1] [2], and it is not shown as the > example setup in our handbook. > > I want to hear from people who have / and /usr on separate partitions > and who are not using an initramfs. > > If you are in this group, I have a very specific question. Why aren't > you using an initramfs? > > Thanks, > > William > > [1] https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt > [2] > https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=a79dd69b0cca439bc0c483c9193c79e0554819d0 I have a separate /usr among others and always have. The reason I do that, /boot and / are normal partitions but everything else is LVM. I can adjust the size of everything BUT /boot and /. At the time I did that, the init thingy was not needed if I recall correctly. I might add, I've had to grow /usr and /var a couple times. Before LVM, it meant copying over to another drive, repartitioning and then restoring to the old drive. Time consuming and one wrong command could ruin a install. While I have a init thingy, I do not like it. I've had a couple failures already with those things. Luckily I keep older kernels and such for that. If I had my wish, I would not need a init thingy, ever. It's just one more thing that can cause problems. There's already more than enough things that can break. While I understand the problem comes from upstream, I still think it sucks. It's easy enough to have a unbootable kernel as it is. Adding another layer for booting to fail should be avoided. BTW, I use dracut. I tried to build it other ways but couldn't get it to work. Bad thing is, when one fails even built with dracut, I have no clue how it works really so no idea how to fix other than using a older kernel or just rerunning dracut and hoping for the best. I'm also not looking forward to the other situation you mentioned either. At some point, having separate partitions won't be easy with or without a init thingy. I can't easily resize / without reworking the whole thing. Just my point of view on why I don't like the thing and wish I didn't have to have one. Dale :-) :-)
Re: [gentoo-dev] Last Rites: Ancient x11-drivers/*
Richard Bradfield wrote: > On Thu, Nov 23, 2017 at 11:24:24PM -0800, Matt Turner wrote: >> Very few if any users. They break occasionally with new xserver >> versions, and then I have to do the leg work to fix them, make the >> upstream releases, and then push them into Gentoo. Again, for between >> zero and one person to use. >> ... >> x11-drivers/xf86-video-modesetting > > I guess I should put my hand up and admit to being "the one user" for > this driver. I've got an ancient netbook with an Intel GMA3600, for > which there is no accelerated Xorg driver, which means I'm stuck with > xf86-video-modesetting. > > Obviously not asking you to keep putting in effort just for me, so what > are my next steps if this package is masked and I later need to update? > Seems that "one" just doubled. root@fireball / # equery list x11-drivers/xf86* * Searching for xf86* in x11-drivers ... [IP-] [ ] x11-drivers/xf86-input-evdev-2.10.5:0 [IP-] [ ] x11-drivers/xf86-video-vesa-2.3.4:0 root@fireball / # equery d x11-drivers/xf86-input-evdev x11-drivers/xf86-video-vesa * These packages depend on x11-drivers/xf86-input-evdev: kde-plasma/plasma-desktop-5.11.3 (mouse ? x11-drivers/xf86-input-evdev) x11-base/xorg-drivers-1.19 (input_devices_evdev ? x11-drivers/xf86-input-evdev) * These packages depend on x11-drivers/xf86-video-vesa: x11-base/xorg-drivers-1.19 (video_cards_vesa ? x11-drivers/xf86-video-vesa) root@fireball / # What will change without it, not sure. :/ Dale :-) :-)
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
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 > > Since `systemctl restart foo` works, I had a workaround anyway. > > Talking with Whubbs about it, I found that our service script only > supports OpenRC, via rc-service. I looked around, and from what I can > tell, most distros ship a service tool for all supported init systems. I.e., > Debian/Ubuntu: supports sysvinit and systemd via init-system-helpers > CentOS/Fedora: provides support for systemd via initscripts > OpenSUSE: has a working service binary for systemd (according to #suse) > > I'd like to propose moving `service` out of OpenRC and into a separate > package that OpenRC and systemd can both use. It's very possible that we > could simply package/use another distro's scripts (I haven't evaluated > that though). > I thought this was familiar. This was discussed not long ago and as far as I can tell, nothing came of it. https://archives.gentoo.org/gentoo-dev/message/9bd54475fc23b9c265984c5a91129710 Hope that link works, if not, this is the subject of the discussion. "[openrc] [systemd] make `service` common for both OpenRC and SystemD (like Debian/Ubuntu/whatever did)" It has a few replies. Dale :-) :-) * *
Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
Daniel Campbell wrote: > On 05/11/2017 12:51 AM, Michał Górny wrote: >> In fact, I'm personally leaning towards not building docs at all >> in ebuilds. It's practically a wasted effort since most of the time >> users read docs online anyway. > I believe that's a little myopic; a user (or even developer) may not > have Internet access all the time, or may not have it in their primary > development environment. Having a copy of the docs locally (the entire > point of USE="doc") is super valuable to have when you're away from the > network. I'm sure I'm not alone as one of the people who uses the flag > and appreciates the work that goes into making sure said flag works. > > Sure, we could yank out every single USE="doc", but then we lose a nice > feature of the tree and users are back to either (a) trawling the Web to > find the project site, then hope they have docs in a separate download, > or (b) we end up with foo+1 packages, one extra for any package that has > documentation. Neither are particularly good solutions; Debian has done > the latter and it results in a huge number of packages for little gain. As a long term user, I always look at the docs first. One reason, the docs should match the version I have installed. If a package has changed recently, the online docs become version dependent which makes it harder to find online. I've actually ran into that before when I'm googling trying to get something to work to only find out that the way things are set up has changed and no longer applies to what I have installed. Having the docs included when available should be required. Dale :-) :-)
Re: [gentoo-dev] gentoo-dev+unsubscr...@lists.gentoo.org
Christophe Farges wrote: > Not quite there. List-Unsubscribe: <mailto:gentoo-dev+unsubscr...@lists.gentoo.org> Send a empty email TO that address not with it in the subject line. Hope that helps. Dale :-) :-)
Re: [gentoo-dev] newsitem: openrc 0.22 updates (second draft)
William Hubbs wrote: > On Mon, Sep 26, 2016 at 12:27:18PM -0500, Dale wrote: >> William Hubbs wrote: >> >> "then overridden bby configuration stored in" >> >> should be >> >> "then overridden by configuration stored in" >> >> Minor typo or sticky keyboard. > This is fixed, and I removed the partial sentence just below it as well. > > William I was wondering about that little dot. I assumed it was there on purpose for some reason. Well, both fixed and that's what matters. Dale :-) :-)
Re: [gentoo-dev] newsitem: openrc 0.22 updates (second draft)
William Hubbs wrote: "then overridden bby configuration stored in" should be "then overridden by configuration stored in" Minor typo or sticky keyboard. Dale :-) :-)
Re: [gentoo-dev] The future of the Sunrise project
Chí-Thanh Christopher Nguyễn wrote: > > I agree that the Sunrise repository should be removed from > repositories.xml. I don't know if there is any way of informing users > beforehand of this change happening. If not, then a grace period is > probably pointless. > > > > Best regards, > Chí-Thanh Christopher Nguyễn > > [0] > https://archives.gentoo.org/gentoo-dev/message/753620a99ab88b9525a253590617db3c > > Just a thought here. Is there a way to do a news announcement for people that have a package installed from the overlay? If that could be done, then users who don't use it won't be bothered by it but users who do will get the news announcement about its future. Dale :-) :-)
Re: [gentoo-dev] please remove me off your mailing list
Kent Fredric wrote: > On 24 May 2016 at 08:08, Dale wrote: >> Nope. It doesn't work that way. Try this: >> >> List-Unsubscribe: <mailto:gentoo-dev+unsubscr...@lists.gentoo.org> >> >> Send a empty email to that and I think you have to confirm. >> >> Dale > > A nice approach I recently saw to this problem on another mailing list > was they had somebody who *could* manually remove people from mailing > lists, > and they'd respond with something along the lines of "We've done this > for you now, but if anyone wants to do this, just email ... > blahblahblah+unsubscribe themselves". > > That makes the effort less for the person requesting removal, and > reduces their margin of error. > > Whether or not gentoo can/wants to do the same, eh. > > Just when I saw it I though "Nice, this is waaay better then the > standard 'you did wrong, try again' ". > Well, I started to do the Hotel California thing but wasn't sure if everyone would get that, including the one wanting to check out and leave. LOL Dale :-) :-)
Re: [gentoo-dev] please remove me off your mailing list
Tyler Pohl wrote: > tylerap...@gmail.com <mailto:tylerap...@gmail.com> > > Thanks, > -- > Tyler Pohl Nope. It doesn't work that way. Try this: List-Unsubscribe: <mailto:gentoo-dev+unsubscr...@lists.gentoo.org> Send a empty email to that and I think you have to confirm. Dale :-) :-)
Re: [gentoo-dev] usr merge
James Le Cuirot wrote: > On Sat, 9 Apr 2016 12:09:38 -0400 > waltd...@waltdnes.org wrote: > >>> I never really got the mentality that using an initramfs is a >>> burden. >> One more piece of software that can go wrong. You have to >> maintain+configure it; e.g. sync software and library versions with >> what's on the rest of the system. > Errm, have you ever actually used dracut? > > dracut --kver 4.5 > > Wow, that was hard! It requires zero configuration and that's true even > if you've got LVM on top of LUKS on top of RAID or something equally > complex. If you're already running that kernel version, you don't even > need to specify it. > FYI. I've had those to fail too. As Walt said, just one more thing to fail. Dale :-) :-)
Re: [gentoo-dev] Changing order of default virtual/udev provider
Rich Freeman wrote: > There is already a thread on gentoo-user asking how to safely switch > from udev->eudev. If that were just a part of the handbook that isn't > even a migration they'd have to make on a new install. Nor would > udev->systemd. To summarize my goals in this thread: 1. Suggest that > rather than picking a winner we instead just let the user pick the > winner. 2. Demonstrate the futility of actually trying to pick a > winner, because we all have different values on this subject. The reason for that thread was because the user had a entry that enabled systemd for a package. Once that was found and removed, the switch was like it should be. Unmerge udev and emerge eudev. Back to my hole. Dale :-) :-)
Re: [gentoo-dev] Changing order of default virtual/udev provider
Andrew Savchenko wrote: > On Mon, 8 Feb 2016 06:12:05 -0500 Anthony G. Basile wrote: >> On 2/8/16 4:25 AM, Brian Dolbec wrote: >>> On Mon, 8 Feb 2016 10:08:22 +0100 >>> Patrick Lauer wrote: >>> >>>> Ohey, >>>> >>>> I've opened a bug at: >>>> https://bugs.gentoo.org/show_bug.cgi?id=573922 >>>> >>>> The idea here is to change the order of the providers of virtual/udev. >>>> For existing installs this has zero impact. >>>> For stage3 this would mean that eudev is pulled in instead of udev. >>>> >>>> The rationale behind this is: >>>> >>>> * eudev is an in-house fork, and there's more than a dozen distros >>>> already using it by default that are not us. Which is a little bit >>>> weird ... >>>> >>>> * Both udev and eudev have pretty much feature parity, so there won't >>>> be any user-visible changes >>>> >>>> * udev upstream strongly discourages standalone udev (without systemd) >>>> since at least 2012 >>>> >>>> (see for example: >>>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html >>>> https://lkml.org/lkml/2012/10/3/618 >>>> ) >>>> >>>> So it'd be (1) following upstreams recommendations and (2) dogfooding >>>> our own tools. I don't see any downsides to this :) >>>> >>> +1 >>> >>> I switched to eudev a few years ago and glad I did. >>> >>> The non-systemd profiles should have eudev as default. >>> >> just pile the pressure on :) > +1 > I use eudev on all setups (both home and work) for years now. > The experience is yummy. > > Best regards, > Andrew Savchenko +1 As a lowly user, I switched very shortly after eudev was started. I think it was like the second or third release. So far, I've not seen any problems. It just works. One thing about Gentoo, for those who don't want eudev, they can always select another tool. Back to my hole. Dale :-) :-)
Re: [gentoo-dev] Re: News item: GRUB security update
Rich Freeman wrote: > On Sat, Dec 19, 2015 at 8:24 AM, Tobias Heinlein > wrote: >> Hi, >> >> On 18.12.2015 21:06, Mike Gilbert wrote: >>> Hi, please review the news item below. >> thanks for drafting this news item. However, the usual way to inform >> users about security flaws is by sending a GLSA. :) >> >> Based on your news item, we have drafted a GLSA now. It's currently >> pending review by one other member of the security team and we will send >> it in a few hours. >> > << SNIP >> > 2. Users probably don't regularly read GLSAs, since for the most part > it just tells them to update packages they've probably already > updated. How do we make ones that actually have instructions beyond > updating stand out? > > I know I stopped reading GLSAs ages ago, because they tended to tell > me to update to a package I had updated to a week before, and when > they said something else 90% of the time it was because there was an > error in the GLSA (usually this happened with subslots and the GLSA > just said of ranges that were vulnerable vs fixed). Granted, I have caught one > or two episodes over the years where the actual package might not have > been completely addressed and an older slot needed fixing. > > I guess my point isn't that GLSAs are a bad thing, but users need a > really high S/N ratio if we want them to pay attention. We need to > separate the mundane from the important. > +1. Given all the changes that have been done, I don't even know how to read them any more because I stopped a long time ago. I might add, I also don't read blogs about this sort of thing. About the only time I read a blog is if it is linked to here or on -user. Other than that, rarely if ever. All things considered, if it isn't a news item or something I follow on this list, I may never know about it. I really depend on the news items. Just keep the noise down or folks will start to ignore them too, although y'all are good at it only telling us about things that affect us. Dale :-) :-)
Re: [gentoo-dev] Re: ChangeLog
Rich Freeman wrote: > On Mon, Nov 2, 2015 at 9:31 PM, Dale wrote: >> That is why a link was posted for me to use github instead. I >> do realize and understand that git and github are two different things >> but it seems they can work together as well. It ended up that the info >> I needed was on github but not to be found on any Gentoo site at the time. > Anything in /usr/portage that you can find on github is also on > https://gitweb.gentoo.org/repo/gentoo.git/, which is a Gentoo site. > > That's kind of the point of git - there are a bazillion tools > available for it and it makes it very easy to clone a full repository > with full history. It also lowers the bar to contribution. > > I get that you're frustrated with the change, and there are a few > others that are as well, but thousands of people use Gentoo, and > generally people only bother to post on lists when they're frustrated. > We can't go into panic mode every time somebody raises a complaint, > and ultimately everybody here is a volunteer. > > The complaints don't really bother me much personally, but I do get > concerned that they'll discourage others from contributing. I can > just ignore threads like these easily enough, but people get > frustrated when they contribute and others just criticize. > What makes it so bad is the confusion as Duncan pointed out. I been following this list for a long time, several years actually. I don't read some threads because they are just devs talking about ebuilds and such and generally that doesn't interest me. That said, I do watch for future changes and was even glad that the change was finally happening. It had been talked about for ages. My understanding was this. If a person didn't want to use the new tools, nothing would change. Us regular users could continue on like we always have. The change was mostly for devs and other people who wanted to submit fixes that make it to the tree and use github etc to do it. When the change first happened, there was several issues that popped up and I watched as the threads explained the situation as best as I could. Anytime a change happens, things are going to pop up. It just seemed to me that after all the years of talking about this change, it would seem that some of the basic things should be worked out before the change. It's not like this new tool set and method of doing things just popped up one day and the switch happened a week later. It had been a work in progress for something close to forever in Gentoo time. Frustrated, yea. Not at first but this has been going on for a while. Right now, I have a package that fails to build and I don't know where the changelogs are for it and which ones would match what I have locally. In the meantime, I'm skipping it. It's not that I can't fix the problem, it's that I can't find information to find out what changed. After all, it compiled fine several times before. Something changed but no clue what, yet. I might also add, the only thing getting updated when I sync in /usr/portage is the ebuilds. The changelogs haven't updated in months. Just keep in mind, I'm not a dev. I'm a user. I post from a user perspective. Something is broke and it affects me and others. Hopefully someone will find a fix, soon I hope and I suspect others hope the same. Dale :-) :-)
Re: [gentoo-dev] Re: ChangeLog
Rich Freeman wrote: > On Mon, Nov 2, 2015 at 8:20 PM, Dale wrote: >> I thought Gentoo was not depending on git/github either. > Take 5min and read the wikipedia articles on both git and github, please. > > Gentoo is not going to depend on github, because of the social contract > issues. > > Gentoo absolutely does depend on git, and it is 100% FOSS. > > If these statements seem contradictory, you really need to look up a > video on git 101/etc. To be fair, I don't think you can truly use git > without first groking it, and you won't accomplish that until you > understand its data model. Git is a terrific data model wrapped in a > mediocre command line utility. > Based on Robin's earlier post, it seems this is going to be fixed, how and when may still be open tho. The reason github entered into this is not because I am confusing the two but because very shortly after this change, I had to go to the github website to find out what changed with some packages because I was having upgrade issues. That is what made me mention github. If I have to go to github to get info about a Gentoo package and it isn't available on a Gentoo site, that sounds fishy. I also recall that at that time, package.gentoo.org was not updating either. That is why a link was posted for me to use github instead. I do realize and understand that git and github are two different things but it seems they can work together as well. It ended up that the info I needed was on github but not to be found on any Gentoo site at the time. My other issue is how these two match up time wise. I synced the tree yesterday. If I go to github or even packages.gentoo.org to see a changelog, that info may be out of date. That is why some of us want them to be done at the same time and stored locally. Changes that were made overnight and today don't apply to me because my tree is older than that. If I sync then run to the website, it may be more relevant but it can't be guaranteed that it is. Dale :-)
Re: [gentoo-dev] Re: ChangeLog
Rich Freeman wrote: > On Mon, Nov 2, 2015 at 8:20 PM, Dale wrote: >> I thought Gentoo was not depending on git/github either. > Take 5min and read the wikipedia articles on both git and github, please. > > Gentoo is not going to depend on github, because of the social contract > issues. > > Gentoo absolutely does depend on git, and it is 100% FOSS. > > If these statements seem contradictory, you really need to look up a > video on git 101/etc. To be fair, I don't think you can truly use git > without first groking it, and you won't accomplish that until you > understand its data model. Git is a terrific data model wrapped in a > mediocre command line utility. > Based on Robin's earlier post, it seems this is going to be fixed, how and when may still be open tho. The reason github entered into this is not because I am confusing the two but because very shortly after this change, I had to go to the github website to find out what changed with some packages because I was having upgrade issues. That is what made me mention github. If I have to go to github to get info about a Gentoo package and it isn't available on a Gentoo site, that sounds fishy. I also recall that at that time, package.gentoo.org was not updating either. That is why a link was posted for me to use github instead. I do realize and understand that git and github are two different things but it seems they can work together as well. It ended up that the info I needed was on github but not to be found on any Gentoo site at the time. My other issue is how these two match up time wise. I synced the tree yesterday. If I go to github or even packages.gentoo.org to see a changelog, that info may be out of date. That is why some of us want them to be done at the same time and stored locally. Changes that were made overnight and today don't apply to me because my tree is older than that. If I sync then run to the website, it may be more relevant but it can't be guaranteed that it is. Dale :-)
Re: [gentoo-dev] Re: ChangeLog
Matt Turner wrote: > On Mon, Nov 2, 2015 at 5:20 PM, Dale wrote: >> hasufell wrote: >>> On 11/02/2015 10:54 PM, Dale wrote: >>>> Ciaran McCreesh wrote: >>>>> On Mon, 2 Nov 2015 14:00:18 -0600 >>>>> Dale wrote: >>>>>> Rich Freeman wrote: >>>>>>> On Mon, Nov 2, 2015 at 1:08 AM, Dale wrote: >>>>>>>> Then perhaps all this should have been worked out BEFORE switching >>>>>>>> to github? >>>>>>> We didn't switch to github. >>>>>> Then why are people saying to use git to look at the logs? I don't >>>>>> want to use git. >>>>> git != github... >>>>> >>>>>> I liked being able to go to the tree and look at the >>>>>> change logs when I needed to which is sometimes often. >>>>> I think you have a technology comprehension problem here, rather than a >>>>> technology problem. The problem is your workflow, not the tools. >>>>> >>>> What I understand is this. The logs since github started being used are >>>> no longer updated like they used to be. I realize that git is a command >>>> but it seems that git gets its info from github since the logs are no >>>> longer downloaded when I sync the tree. >>> No. You should really read some tutorials/introductions on git to >>> understand how it works and this ML isn't the place for that. It's not >>> like SVN, so you don't even need an internet connection for the tree to >>> work (e.g. if you've copied it via USB even). Github is totally >>> unrelated here. >>> >>> >> >> So you are telling me that people using github and the switch that took >> place has absolutely nothing to do with the changelogs going dead? > You keep saying GitHub. Github is not relevant to this discussion. > > Yes, the ChangeLogs stopped being updated because of git. > > The git transition had been 9 years in the making and has massively > improved Gentoo development. Look at the graph of contributions per > month: https://www.openhub.net/p/gentoo > > It was decided that the missing infrastructure for ChangeLogs was not > a sufficient reason to block a hugely important change. > > People care about finishing this, as evidence by this thread. Please > stop complaining. > > What bothers me is that people make it sound like it is ONLY me that is having this issue when I have seen it posted here and on -user as well by others. I agree that the change has improved things because even tho I don't update as often as some do, I see more updates. I'm not arguing that point for sure. Even I can see that improvement. I just ask that people not point at me like it is only me that has a problem when even Robin replied that the problem is known about and some changes seem to be coming, hopefully soon since I miss the changelogs. I also find it odd that early on, I was told to go to the github website to get info regarding changes to Gentoo packages. I even bookmarked the link. Even package.gentoo.org was out of date for a while. Thing is, that doesn't match what I have locally because that includes changes made since my last sync. It's not easy to find out what applies to me locally since they are not in sync. Having it in the tree like it once was means they are synced at the same time and the info there matches what is in the tree locally because they get updated together. As it is, if it is being worked on, fine. Just don't tell me that I'm the only one with outdated changelogs and that I don't know the difference between a software package and a website. I've been to gituhub, as I was told to, and I know about the git software package too. I just prefer not to use the website and would like up to date logs locally like it should be and it appears from Robins reply is being worked on at some point. It just seems they want to finish something else first. Dale :-) :-)
Re: [gentoo-dev] Re: ChangeLog
hasufell wrote: > On 11/02/2015 10:54 PM, Dale wrote: >> Ciaran McCreesh wrote: >>> On Mon, 2 Nov 2015 14:00:18 -0600 >>> Dale wrote: >>>> Rich Freeman wrote: >>>>> On Mon, Nov 2, 2015 at 1:08 AM, Dale wrote: >>>>>> Then perhaps all this should have been worked out BEFORE switching >>>>>> to github? >>>>> We didn't switch to github. >>>> Then why are people saying to use git to look at the logs? I don't >>>> want to use git. >>> git != github... >>> >>>> I liked being able to go to the tree and look at the >>>> change logs when I needed to which is sometimes often. >>> I think you have a technology comprehension problem here, rather than a >>> technology problem. The problem is your workflow, not the tools. >>> >> What I understand is this. The logs since github started being used are >> no longer updated like they used to be. I realize that git is a command >> but it seems that git gets its info from github since the logs are no >> longer downloaded when I sync the tree. > No. You should really read some tutorials/introductions on git to > understand how it works and this ML isn't the place for that. It's not > like SVN, so you don't even need an internet connection for the tree to > work (e.g. if you've copied it via USB even). Github is totally > unrelated here. > > So you are telling me that people using github and the switch that took place has absolutely nothing to do with the changelogs going dead? Before I sent my first message here, I looked at the changelogs for several packages in the portage tree that I know for certain have been updated. Just as the OP stated in his email, those updates to those changelogs stopped in August. That is about the same time this git/github happened. While I do believe the git/github change has helped in a lot of ways, some of us still want our changelogs up to date so that we can see them and know what is going on, especially if we run into trouble and need to know what changed and when and need it to fix things. I find it odd that I have a problem, others are having the same complaint but it is me not wanting to use git/github that is the problem. I thought Gentoo was not depending on git/github either. Dale :-) :-)
Re: [gentoo-dev] Re: ChangeLog
Ciaran McCreesh wrote: > On Mon, 2 Nov 2015 14:00:18 -0600 > Dale wrote: >> Rich Freeman wrote: >>> On Mon, Nov 2, 2015 at 1:08 AM, Dale wrote: >>>> Then perhaps all this should have been worked out BEFORE switching >>>> to github? >>> We didn't switch to github. >> Then why are people saying to use git to look at the logs? I don't >> want to use git. > git != github... > >> I liked being able to go to the tree and look at the >> change logs when I needed to which is sometimes often. > I think you have a technology comprehension problem here, rather than a > technology problem. The problem is your workflow, not the tools. > What I understand is this. The logs since github started being used are no longer updated like they used to be. I realize that git is a command but it seems that git gets its info from github since the logs are no longer downloaded when I sync the tree. It was really nice to be able to see those logs and be able to find out what changed especially if you want to hold off on a update that isn't important. Generally, the only way to know if it is important or not is to look at the logs and see why something is being changed. Also, I don't want to turn into Duncan and write a book to be sure that every specific detail is covered. I try to keep it short and basic. If the problem is me not understanding the problem then why are others complaining about the missing logs too? If it was just me then I would be the only one complaining about them being no longer updated. Obviously, it is not just me. Well, obvious to some but maybe not some others. We just want the logs back so we can see what is going on and for it to be easily available, preferably done with the sync like it used to be. The recent changes broke that and it needs to be fixed. Dale :-) :-)
Re: [gentoo-dev] Re: ChangeLog
Rich Freeman wrote: > On Mon, Nov 2, 2015 at 1:08 AM, Dale wrote: >> Then perhaps all this should have been worked out BEFORE switching to >> github? > We didn't switch to github. Then why are people saying to use git to look at the logs? I don't want to use git. I liked being able to go to the tree and look at the change logs when I needed to which is sometimes often. Now, that is gone because it is somewhere else and people are saying to use git to get them. Sounds like a switch to me. > >> I don't mind change but it seem this one wasn't really ready to be done >> yet although most made it sound like it was. > IMO we took too long as it is. I'd have pushed it faster, but just as > I don't have access to fix this bug I didn't have access to implement > git, and those with access wanted to keep Changelogs, so we did. > > If you haven't already gotten the impression, Gentoo is mostly a > conglomeration of various associations of devs who tend to do their > own thing, each with different sets of knowledge/access. When there > is a direct conflict between two groups we generally (if often not > enthusiastically) accept the votes of the Council to settle disputes. > For the most part the Council has the ability to tell devs to NOT do > things. When something needs to be done somebody has to step up and > do it. Complaining on the lists mainly seems to de-motivate people > from working on anything. By all means point out that something isn't > working, but attitudes tend to be contagious. > Yea, breaking things does tend to start attitudes when the people that break them act like it isn't their problem to fix when they broke it. I didn't do anything to remove the logs. That wasn't me and it wasn't a few others that want/need them back either. Argue and point the finger somewhere else if you want but I didn't create the problem, the devs that supported this move did and it seems it wasn't as well thought as some of us users was lead to believe. How about fixing it now. I might add, this makes me very leery of trusting changes like this in the future. If something as important as logs can't be thought about before doing something like this, then what else can be overlooked in the future? As it is, it seems like that could be a lot. Dale :-) :-)
Re: [gentoo-dev] Re: ChangeLog
Rich Freeman wrote: > On Sun, Nov 1, 2015 at 8:22 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> I know if I were still on rsync (or webrsync), I'd be raising hell about >> the lack of >> changelogs well before now > Perhaps rather than raising hell you'd do better to raise money to > hire an infra team to fix the bug or something. > > I get the frustration, but we only have a few people who have the > necessary access to fix the problem. Infra is also a difficult > project to deal with in general because it is fairly closed due to the > implications of having random people messing with it. I don't really > see anybody stepping up to try to change anything fundamental about it > either. This isn't the sort of thing that will get better if the > council votes on something. > Then perhaps all this should have been worked out BEFORE switching to github? As a user, I would look at the change logs pretty regular, more than the ebuilds to be honest. Now, there is none. If a package changes, I have no clue why it changed unless I go dig that information out somewhere and that somewhere doesn't seem to be in one place. When I tried to dig some info out a while back, I found some on github thingy and then some more on gentoo.org itself. I'm still not sure what change lead to what because there is no real order of events that I could see. This was shortly after the change. After that, screw it. I don't mind change but it seem this one wasn't really ready to be done yet although most made it sound like it was. I been using Gentoo since 2003, the 1.4 days, and even I can't figure out where to find information easily and I have a stable DSL connection. I feel real sorry for people who don't have one. I might add, I had a really limited dial-up connection when I first started using Gentoo so I know how it is to be in that situation. I haven't forgot those days. Going back to my hole for the simple reason, it's screwed up and no one seems to think it worth fixing. I noticed that as soon as I saw the you need to figure out a way to fix it yourself comment. One thing about being around so long, when you see that comment, you may as well kiss it good bye. That's code for we aren't going to fix it, you figure out a way for yourself. It's rare that anything gets fixed after that. Dale :-) :-)
Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)
Andrew Udvare wrote: >> On 2015-10-14, at 23:39, Mike Frysinger wrote: >> >> iputils is currently in @system for everyone. by default, it only >> installs `ping`. do we feel strongly enough about this to require >> all systems include it ? or should this wait for the long idea of >> releasing stage4's instead of stage3's ? >> -mike > If I had got on a machine lacking the ping command, I would immediately > install it and otherwise avoid that machine (it's 'broken'). It really should > not get removed, plus it is tiny. > > A lot of hosts now block ICMP requests but it's just habit for many to type > `ping google.com` or similar to test when they suspect their internet is down. > > Andrew > +1 I do this all the time myself. Dale :-) :-)
Re: [gentoo-dev] tcltk herd empty
Joshua Kinard wrote: > On 10/02/2015 08:44, Dale wrote: >> Michał Górny wrote: >>> Dnia 2015-10-02, o godz. 03:38:16 >>> Daniel Campbell napisał(a): >>> >>>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA256 >>>> >>>> On 09/30/2015 06:02 AM, Justin (jlec) wrote: >>>>> Hi, >>>>> >>>>> is no active maintainer for tcltk in Gentoo anymore. >>>>> >>>>> Please stand up or try to remove tcltk support from your packages. >>>>> >>>>> Justin >>>>> >>>> I know next to nothing about tcl/tk but it's been an idle curiosity of >>>> mine. Are there any particularly important packages that run on them? >>> dev-tcltk/expect is sometimes used for modem chats. >>> >>> net-im/tkabber used to be pretty good but I haven't looked at it in ages. >>> >> >> I have these that use tcl or tk: >> >> >> root@fireball / # equery h tk >> * Searching for USE flag tk ... >> [IP-] [ ] app-office/scribus-1.4.4-r1:0 >> [IP-] [ ] dev-lang/R-3.2.2:0 >> [IP-] [ ] dev-lang/python-2.7.10:2.7 >> [IP-] [ ] dev-lang/python-3.4.3:3.4 >> [IP-] [ ] dev-python/pillow-2.8.1:0 >> [IP-] [ ] dev-python/pyopengl-3.0.2-r1:0 >> [IP-] [ ] dev-vcs/git-2.4.9:0 >> [IP-] [ ] net-im/pidgin-2.10.11:0 >> [IP-] [ ] sci-electronics/pcb-20140316:0 >> [IP-] [ ] virtual/python-imaging-2:0 >> root@fireball / # equery h tcl >> * Searching for USE flag tcl ... >> [IP-] [ ] dev-db/sqlite-3.8.10.2:3 >> [IP-] [ ] media-gfx/graphviz-2.26.3-r4:0 >> [IP-] [ ] net-analyzer/rrdtool-1.5.4:0 >> [IP-] [ ] net-im/pidgin-2.10.11:0 >> [IP-] [ ] sys-libs/db-4.8.30-r2:4.8 >> root@fireball / # > tcl/tk support should remain if at all possible, especially in Python. TCL is > the base language, and well-entrenched in some really niche areas, like > eggdrop > bot scripting and the like. IIRC, everything in TCL is effectively a string, > and it's very much an event-driven language via the use of "binds". > > Tk is for creating cross-platform GUIs using TCL, and Python people have > likely > encountered Tk as "Tkinter", Python's wrapper around Tk for creating > cross-platform Python GUIs (like gitk). > I recall that at least one, maybe more, needed those flags to install. At least it did at the time. I think, key word think, pcb and maybe scribus is in that category. I'm not real sure on the others. Generally, if something is required like that, I just set it in make.conf for everything. If it causes a problem, I disable it in package.use for that package. The biggest reason for the post is to let them know that at least one lowly user has those packages that use it. Honestly, I have no idea what it does or what function it adds, until your post anyway. I just followed what portage told me. If support for it drops, I'll just try to adjust to it. If a package must have it and won't build without it, then I can post here or b.g.o. and either that package has to go the same way as tk and/or tcl or someone will do some fixes so that they can be back in the tree again. Either way, it will work out. Dale :-) :-) P. S. I'm getting a error message on your OpenPGP. I get this: "Error - No valid armored OpenPGP data block found". If that is caused by something on your end, may want to look into it.
Re: [gentoo-dev] tcltk herd empty
Michał Górny wrote: > Dnia 2015-10-02, o godz. 03:38:16 > Daniel Campbell napisał(a): > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On 09/30/2015 06:02 AM, Justin (jlec) wrote: >>> Hi, >>> >>> is no active maintainer for tcltk in Gentoo anymore. >>> >>> Please stand up or try to remove tcltk support from your packages. >>> >>> Justin >>> >> I know next to nothing about tcl/tk but it's been an idle curiosity of >> mine. Are there any particularly important packages that run on them? > dev-tcltk/expect is sometimes used for modem chats. > > net-im/tkabber used to be pretty good but I haven't looked at it in ages. > I have these that use tcl or tk: root@fireball / # equery h tk * Searching for USE flag tk ... [IP-] [ ] app-office/scribus-1.4.4-r1:0 [IP-] [ ] dev-lang/R-3.2.2:0 [IP-] [ ] dev-lang/python-2.7.10:2.7 [IP-] [ ] dev-lang/python-3.4.3:3.4 [IP-] [ ] dev-python/pillow-2.8.1:0 [IP-] [ ] dev-python/pyopengl-3.0.2-r1:0 [IP-] [ ] dev-vcs/git-2.4.9:0 [IP-] [ ] net-im/pidgin-2.10.11:0 [IP-] [ ] sci-electronics/pcb-20140316:0 [IP-] [ ] virtual/python-imaging-2:0 root@fireball / # equery h tcl * Searching for USE flag tcl ... [IP-] [ ] dev-db/sqlite-3.8.10.2:3 [IP-] [ ] media-gfx/graphviz-2.26.3-r4:0 [IP-] [ ] net-analyzer/rrdtool-1.5.4:0 [IP-] [ ] net-im/pidgin-2.10.11:0 [IP-] [ ] sys-libs/db-4.8.30-r2:4.8 root@fireball / # Dale :-) :-)
Re: [gentoo-dev] Re: USE="gui"
Duncan wrote: > hasufell posted on Fri, 11 Sep 2015 22:34:04 +0200 as excerpted: > >> USE flags in gentoo are the best and the worst thing at the same time. >> They are also mostly the main reason people don't like gentoo, because >> USE flags are (for todays situation) pretty much not an appropriate >> pattern to reflect real-world configuration. To be more precise... USE >> flags are first-class citizens and there is only one layer of them. > I agree with the one-layer problem, but just to say, without something > like USE flags, despite their single-layer-problem, I'd not be using > gentoo. Perhaps better can be done, but in the absence of better at the > moment, for better or worse, USE flags do get the job done, and I'd hate > to be without either them or an at least equally (if not more) powerful > replacement. > +1 If there is not some way to disable/enable things, there is little point is using Gentoo. Actually, Gentoo loses something huge that makes Gentoo different. Besides, how would you tell a package how and what to compile without USE flags?? Dale :-) :-)
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-09-06 23:59 UTC
Top posting for consistency. Just to be sure my first post was read the way it was intended, it was meant as a joke but also to make sure whoever takes care of this was aware it wasn't working the way it should. I was aware that the move to git sort of messed up some things, bumps in the road if you will, but my post was not meant to be a bad thing by any means. As I have pointed out on other threads, git was a big move. The fact that there is a few bumps/issues that have to be worked on isn't a surprise to me or likely anyone else. So, my original post was meant to point out that the script that does this isn't working and to get the attention of whoever oversees it. In a sort of joking way. I think folks that see my posts on -user would know how I am but I don't post on -dev a lot. By the way, glad y'all got things switched over. I know y'all been working on getting this done for well . . . ages now. Even if there was another year of waiting, there would still have been a few bumps/issues to work out. Just keep up the good work and thanks for all you do. I been bumping around Gentoo for over a decade now. It doesn't get any better. Dale :-) :-) Robin H. Johnson wrote: > I've been travelling a lot the past month (Helsinki, LA, Seattle), and > it's on my list of stuff to do (along with finalize and announce the > migrated git history). > > On Mon, Sep 07, 2015 at 06:46:11PM +0100, malc wrote: >> I updated the scripts and since I didn't find them in a relevant >> infra-repo, posted them to a couple of other replies to earlier week's >> versions of this, cc: Robin. >> I've heard nothing. I have opened >> https://bugs.gentoo.org/show_bug.cgi?id=559894 and attached them >> there. >> >> On Mon, Sep 7, 2015 at 5:27 PM, Dale wrote: >>> Daniel Campbell wrote: >>> >>> On 09/06/2015 05:10 PM, Dale wrote: >>>> Robin H. Johnson wrote: >>>>> The attached list notes all of the packages that were added or >>>>> removed from the tree, for the week ending 2015-09-06 23:59 UTC. >>>>> >>>>> Removals: >>>>> >>>>> Additions: >>>>> >>>>> -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : >>>>> robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E >>>>> B27B 944E 3488 4E85 >>> >>>> U. You sure? >>>> Dale >>>> :-) :-) >>> IIRC Robin's spoke with multiple other devs and a script has been >>> written to work on git. It just hasn't had everything ironed out yet. >>> Most notable being the cronjob that does the e-mail, based on what we >>> see. :) Give it some time. >>> >>>> >>> >>> I saw some of the posts here about it and I thought they fixed it but I >>> guess it was something else they fixed. I'm sure they will get around to it >>> one day. No big deal, just wanted to post to hopefully get the attention of >>> the person that does that sort of thing. Just in case they thought it was >>> fixed but somehow it failed. >>> >>> Dale >>> >>> :-) :-)
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-09-06 23:59 UTC
Daniel Campbell wrote: > On 09/06/2015 05:10 PM, Dale wrote: > > Robin H. Johnson wrote: > >> The attached list notes all of the packages that were added or > >> removed from the tree, for the week ending 2015-09-06 23:59 UTC. > >> > >> Removals: > >> > >> Additions: > >> > >> -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : > >> robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E > >> B27B 944E 3488 4E85 > > > > U. You sure? > > > Dale > > > :-) :-) > > IIRC Robin's spoke with multiple other devs and a script has been > written to work on git. It just hasn't had everything ironed out yet. > Most notable being the cronjob that does the e-mail, based on what we > see. :) Give it some time. > > > I saw some of the posts here about it and I thought they fixed it but I guess it was something else they fixed. I'm sure they will get around to it one day. No big deal, just wanted to post to hopefully get the attention of the person that does that sort of thing. Just in case they thought it was fixed but somehow it failed. Dale :-) :-)
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-09-06 23:59 UTC
Robin H. Johnson wrote: > The attached list notes all of the packages that were added or removed > from the tree, for the week ending 2015-09-06 23:59 UTC. > > Removals: > > Additions: > > -- > Robin Hugh Johnson > Gentoo Linux Developer > E-Mail : robb...@gentoo.org > GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 U. You sure? Dale :-) :-)
Re: [gentoo-dev] Excessive rsync time after git migration
Joshua Kinard wrote: > This might already be covered in one of the other e-mail threads, but I've > been > super-busy as of late and just recently ran 'emerge --sync' on my main dev box > for the first time after the git migration. I just synced my main dev box > again, ~10 hours after the last sync, but it looks like the 'Manifest' files > for *every* package in the tree are getting downloaded with each sync. > > I compared two Manifest files from a given package that shouldn't have changed > in the last 10 hours (sys-kernel/mips-sources), and there is nothing different > timestamp wise or content wise between then. So I'm not sure what's causing > 'emerge --sync' to re-fetch the whole file. > > Has anyone else noticed this and/or have a workaround? It's causing some > excessive disk thrashing, and what used to be a few seconds to sync is now > taking 5-10mins or more (depending on which machine I'm syncing). > I have synced a few times since the change and each time, it takes a lot longer to sync. You are not the only one that has noticed this. No clue as to why or how to fix tho. Dale :-) :-)
Re: [gentoo-dev] useflag policies
Maciej Mrozowski wrote: > On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: > | The approach qt4=qt4 > | and qt5=qt5 seems simpler on the surface, but it means that users end > | up having to set tons of per-package configurations when they don't > | actually care which one they use, > > I will risk a thesis that if they didn't care, they wouldn't have chosen > Gentoo... > > regards > MM > > You may lose that one if I'm seeing your point correctly. See Alan and my earlier replies. I have both qt4 and qt5 set and I leave which is best to use to the devs to control in the ebuild. If for example qt5 does not work well for a package, let the ebuild pick qt4 for that package. If qt5 works reliably, then build with qt5. If I have a problem with it, then I can set it in package.use if needed, doesn't build or function correctly or I want qt5 even if it isn't stable. As things switch to qt5 more, I don't have to do anything except let the updates roll out as they become stable and the dev sets that in the ebuild. Keep in mind, devs already do a LOT of the selection process. Otherwise, we could set any and every USE flag and package combination there is without any restrictions. In other words, we could have USE flag soup even if it is known that two or more USE flags clash. As it is, if a dev knows two flags clash, we get a nifty error message and then we get to figure out how to get it to work right, sometimes portage's error message is cryptic to say the least. If I took your point wrong, my apologies. Lowly user. Dale :-) :-)
Re: [gentoo-dev] Re: useflag policies
Michael Palimaka wrote: > On 03/08/15 07:14, NP-Hardass wrote: >> ^^ has the pleasant side effect of being easier to read, as a user. The >> user receives a message saying "at-most-one-of" instead of some >> convoluted other expression that they don't understand. >> >> I am all for the use of ^^ add the default for this reason. > This introduces a usability nightmare for anyone with both qt4 and qt5 > in their global USE flags (a common configuration). > > > As a Gentoo user. This is what I have set and what I hope to get because of the settings. I have both qt4 and qt5 set in make.conf for my USE flags. I expect qt5 for whatever packages can work with qt5 and qt4 for whatever isn't ready for qt5 but requires qt. If for some reason a package isn't quite ready for qt5 and won't function correctly for me, I can always set that in package.use until it is. My current entries for this: media-libs/phonon-vlc qt5 media-video/mkvtoolnix -qt5 I don't have notes on that so not sure what was ran into to require those. I may comment those out and give them another try. Point of this post, provide a little user info about expectations and settings. Y'all sort out the best way forward and let us know if we need to change something. :-) Dale :-) :-)
Re: [gentoo-dev] A question to Russian Gentoo Developers Community about import software substitution
Tyler Pohl wrote: > > How can I unsucribe from this mailing list > > https://gentoo.org/get-involved/mailing-lists/instructions.html Dale :-) :-)
Re: [gentoo-dev] News item review: SquashDelta syncing support
Michał Górny wrote: > Dnia 2015-05-16, o godz. 20:38:36 > Michael Orlitzky napisał(a): > >> On 05/16/2015 06:01 PM, Michał Górny wrote: >>>> We have gentoo-announce@g.o and gentoo-user@g.o too! >>> That's gentoo-dev-announce. 'dev' is the key part. And gentoo-user@ is >>> doubtedly used by sysadmins. >>> >> This one: >> >> https://archives.gentoo.org/gentoo-announce/ > First time I hear about it. Looks to be used primarily for GLSAs. > I wonder if anyone actually uses it. > I subscribe to it and wish more things, new features for example, would be posted there. Sometimes portage has a new feature and unless one reads the man page, one has no clue. Of course, my wish is not limited to portage's new features. Other new Gentoo things would be nice too. Dale :-) :-)
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC
Diamond wrote: > On Mon, 21 Jul 2014 00:25:02 + > "Robin H. Johnson" wrote: > > >> Removals: >> net-misc/curl2014-07-15 09:29:56 blueness > Is this a joke? Isn't curl as basic package as wget? > > Look under additions. It's there. Dale :-) :-)
Re: [gentoo-dev] Re: RFC: news item for upower
Ben Kohler wrote: > > On Wed, Jun 4, 2014 at 11:24 AM, Samuli Suominen <mailto:ssuomi...@gentoo.org>> 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 As a user, I have ran into blockers quite a few times. I either end up asking on -user or using the trial and error approach. A lot of the time, the trial and error approach fails and I still end up posting on -user or find where someone else beat me to it. It's rare with the output that portage gives that I can figure out why something is blocking. Generally this is just a issue of a different version of the same package being needed. Given that in this case it is a entirely different package that is needed to resolve it, I certainly would have been posting on -user. Unless portage spelled it out that I needed to use a different package all together, it would have never occurred to me. I might add, I been using Gentoo since 2003. I'm not a dev for sure and don't do scripting stuff so diggin in the ebuilds doesn't generally help me much either. Just a users point of view. Dale :-) :-)
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
Mike Gilbert wrote: > On Wed, Dec 11, 2013 at 2:25 PM, Michael Orlitzky wrote: >> On 12/10/2013 09:18 PM, Paul B. Henson wrote: >>> I'd say go one step further and get rid of vixie-cron completely, is >>> there anything it does that cronie can't do as well or better? >> Is cronie a drop-in replacement, or do I have to do some thinking when >> replacing vixie-cron? >> > It should be a drop-in. The only change to make would be to remove > vixie-cron and add cronie to the default runlevel. > > I switched my system and that is all I had to do. I think "drop-in" is a good term. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Tom Wijsman wrote: > On Mon, 04 Nov 2013 14:02:28 -0600 > Dale wrote: > >> You are right, it does require prior knowledge and as a user gets that >> knowledge, they likely end up where Alan, Duncan and myself are. That >> would be emerge -uaDN world. > > And from there you can continue; like adding -vt --unordered-display > and the list goes onto get a lot more detail, it can be handy to see > what depends on what such that you don't look at a flat list wondering > where a dependency came from. I haven't looked further at all the more > specific parameters one can pass; but well, surely there's some > objective and/or subjective improvement still possible there. The -v option is already in my make.conf file for portage but I do type it in out of habit sometimes. I do sometimes add -t if I think it will help. Sometimes it does, sometimes it doesn't. My point still remains, emerge -uaDN world has given me the most stable system so far. Removing any of those options results in issues and I end up going back to the command I should have used to begin with. > > >> I have needed this more than once in the past. I would run into a >> problem and recompiling the obvious packages didn't correct the >> issue. Doing a emerge -e world would fix the issue. > > Usually I debug / troubleshoot it for long enough to avoid that; but > well, yeah, depending on the situation `emerge -e @world` could take > a lot less time. Especially on a new Gentoo install where this might be > more likely to happen as you often change things in the early days... > When I run into a issue and post on -user and no one has a fix, I assume that I'm not going to find a fix on my own either. Duncan, Alan, Neil and others are MUCH more experienced than I am on the code part. So, if I need something fixed, emerge -e world may be the only option. Speed may not matter since anything else could still leave me with a not so stable issue. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
Tom Wijsman wrote: > On Mon, 04 Nov 2013 06:06:52 -0600 > Dale wrote: > >> But after a person has used Gentoo a while, they figure out what >> process leads to the most stable update process. > > Do they? What do you consider a stable update process? I consider it stable when things work as they should except for known bugs upstream. Obviously if there is a known bug upstream then that bug will likely filter right on through to Gentoo. That said, if the Gentoo devs can correct a issue, they do so but that is not always the case either. > > > I come across users on a daily basis which > > - haven't upgraded their system lately because they're not good at it; > - get into unclear slot conflicts locking them out of updates; > - some build failure disallows their dependency graph from completing; > - managed to finally update, but don't know about depclean; > - managed to finally depclean, but don't know about eclean. > > It involves a lot of prior knowledge, manual checking and what in order > to be able to update the system; I wouldn't label this "stable", but > rather "dependent on the person updating it" and to some extent even > "dependent on whether the person memorized all the docs and/or gets > helped or get it told in the support channels". > > There are some improvements possible in these situations; I'm planning > to discuss some ideas and write some patches where possible, and I > hope other people jump on the bandwagon to help improve user experience. > > That doesn't mean I consider it bad or that we need to go hand holding. It does require prior knowledge which is why I said what I did. I used to do emerge -u world way back when. That would SOMETIMES lead to issues because it may not go deep enough. Then I added -D which helped but from time to time would still miss something. So, I added the backtrack to make.conf. That improved things even more. Over time, I realized that I needed to add the -N option so it got added to the command. As it is now, I have that knowledge. I learned some of that the hard way. You are right, it does require prior knowledge and as a user gets that knowledge, they likely end up where Alan, Duncan and myself are. That would be emerge -uaDN world. Right now, that has lead me to the most stable OS. When it doesn't, I do a emerge -e world if nothing else fixes the issue. That doesn't happen as much as it used to because either Zac is tweaking portage or devs are doing better on the ebuilds. Heck, it could be both since both need to work well to get a good end result. > >> The only way to get a more stable system is to do a emerge -e world >> and update that way. At least that has been my experience so far. > > I have never needed this; I wonder whether there exists an example case > for this, I only see this used when someone changes compiler / flags > and wants to ensure the whole system turns into rice. * I have needed this more than once in the past. I would run into a problem and recompiling the obvious packages didn't correct the issue. Doing a emerge -e world would fix the issue. Obviously something fell through the cracks that my usual command would miss but the -e would catch since it does all packages. I never reported the issue since I don't know what specifically fixed the issue. There is no way for a person to figure out if it is a portage issue, ebuild issue or some other issue. I didn't see the point in filing a bug because there is no way to track down the source of the problem. This is my experience. By all means, if you do something different and it works for you, do it your way. I'm going to continue doing what works for me. If someone asks me how I do things, I'll recommend the same command/settings I use just like I'm sure some other old timers will do. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
yac wrote: > On Mon, 4 Nov 2013 09:51:32 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > >> Daniel Campbell posted on Mon, 04 Nov 2013 02:50:27 -0600 as >> excerpted: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 11/03/2013 10:15 PM, yac wrote: >>>> On Sun, 03 Nov 2013 11:02:31 +0200 Alan McKinnon >>>> wrote: >>>> >>>> [snip] >>>>>> >>>>>> Afaik there is no official way to update gentoo, is there? >>>>> >>>>> It's always been "emerge -avuND world" >>>> [snip] >>>> >>>> Is this documented annywhere? I have a hard time finding it. I can >>>> see it mentioned eg. in man emerge in -c option but that's not >>>> good enough. >> >> Read the handbook lately? =:^) >> >> Handbook, part 2, Working with Gentoo, Chapter 1, A Portage >> Introduction, Doc_chapter 3, Maintaining Software (this is the amd64 >> link): >> >> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml? >> part=2&chap=1#doc_chap3 >> >> Look under the heading Updating your System. That starts with... >> >> emerge --update --ask world >> >> ... then discusses --deep, --withbdeps=y, and --newuse, so the >> example full update is ... >> >> emerge --update --deep --with-bdeps=y --newuse world >> >> --ask and --pretend are discussed in the same doc_chapter as well, as >> is -v (tho inconsistently, I don't see the long-option --verbose >> discussed, as it is for the others). >> >> --depclean, --search and --unmerge are discussed in that chapter too, >> as is gentoolkit with equery and revdep-rebuild. About the only >> thing missing is sets, and they're missing from working with portage >> (part 3) AFAICT as well, most likely because the handbooks simply >> haven't been updated for sets yet. > > Yes, there is describes what are possible ways to update the system and > what criteria goes into selection of the packages to update but not > which one is recommended, generaly for regular update. Could be > helpful for newbs and to avoid doubt even between more experienced > users. > > I think only -u world could be used to do updates. (possible > --with-bdeps could be recommended too, for better security until users > find out about glsa-check, though I think it is limited to packages > that are believed to be widely deployed. > > But after a person has used Gentoo a while, they figure out what process leads to the most stable update process. They also figure out what defaults to add to make.conf as well. For that, it is as Duncan and Alan describe. Both have been using Gentoo for quite a while. I been using Gentoo for a good ten years. I installed from Gentoo 1.4 I think. Here is mine in make.conf: EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=30 --keep-going -v -j10 --quiet-build=n -1" For my updates, I use this: emerge -uaDN world The only way to get a more stable system is to do a emerge -e world and update that way. At least that has been my experience so far. If Zac adds some other nifty feature, then I may add to the above as needed. For the past few years, that has resulted in as stable a system as I can get. I do from time to time run emerge -e world just for giggles when I have something acting odd and can't put my finger on the issue. Sometimes, that fixes it, sometimes not. Again, most of this comes from experience. The handbook explains it then the user figures it out from there. My $0.02 worth. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: [gentoo-user] OpenRc-0.12 is coming soon
Doug Goldstein wrote: > > sys-apps/etckeeper is what you want. Works great. It even has portage > integration. Though I'd recommend going with the ~arch version instead > of stable for that portion. > > -- > Doug Goldstein I think this is something dispatch-conf does too. I use that but still make a backup myself, just in case. Generally, a successful reboot is a good sign that the configs are working. Going to look into this but the home page doesn't really show me much, yet. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: [gentoo-user] OpenRc-0.12 is coming soon
Walter Dnes wrote: > 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. > When I reboot and everything works, I make a new backup of /etc. Going to add /var/lib to that to now. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] revbumping ebuilds after USE dependency changes
Alex Alexander wrote: > Hello, > > Please revbump an ebuild after changing its USE dependencies. > > Using net-p2p/transmission as an example, it used to depend on > dev-qt/qtgui:4=[dbus] > however, qtgui lost the dbus useflag, so the dependency was changed to > dev-qt/qtgui:4=[dbus(+)] > without revbumping the transmission ebuild. [0] > > Portage fails to notice this when resolving dependencies if the package was > installed prior to the change, resulting in errors like the following: > (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts > with dev-qt/qtgui:4/4=[dbus] required by > (net-p2p/transmission-2.80::gentoo, installed) > > which, I imagine, could be very frustrating for a user who doesn't mess > with the internals of Gentoo often. > > You might think that such a revbump is overkill, but in reality the user will > have to re-emerge the package anyway in order to get rid of the error, so there > is no point in avoiding it, unless portage changes the way it handles these > changes. > > [0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2 > > Thanks, As a lowly user, I have been banging on this for a few days now. I'm almost bald from all the hair pulling. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
Tom Wijsman wrote: > For the same reason we have all the other eselect modules. > http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) As someone else pointed out, not the same thing. Quoting: William Hubbs wrote: > Yes, but the init system module that project refers to is already there. > Check out eselect rc. It has nothing to do with switching init systems. > It appears to be a wrapper around rc-update and a couple of other things > to manage init scripts and runlevels. > > Thanks, > > William > In case you missed the post, thought I would provide it to clear up the matter. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] New install isos needed
Andreas K. Huettel wrote: > Am Samstag, 23. März 2013, 21:40:16 schrieb Markos Chandras: >>> Why not officially recommend SystemRescueCD instead? >>> >> Looks really bad to recommend another installation media (even if it >> is based on Gentoo) to people who want >> to install our distro. I'd rather Gentoo recommended the live DVDs we >> do from time to time than having these autobuilds around >> that seem to break far too often. > > Except for the fact that downloading a DVD is slightly different from > downloading a CD... > > Seriously. SystemRescueCD is more or less exactly what we would need. Has > anyone ever approached the SystemRescueCD developers? > I must confess, I have not used the official Gentoo ISOs in ages. I use the SystemRescueCD from a USB stick all the time. I update it regularly as well. Speaking of, I need to update again. I stopped using it because I was always having either one trouble or another. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: news item for udev 197-r3 upgrade (yes, I know, it's late)
Duncan wrote: > Samuli Suominen posted on Thu, 24 Jan 2013 04:04:19 +0200 as excerpted: > >> > On 23/01/13 21:06, Felix Kuperjans wrote: >>>> >>> On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans >>>> >>> wrote: >>>>> >>>> Samuli Suominen wrote: >>>>>> >>>>> please review this news item >>>>> >>>> >>>>> >>>> /dev/root is no longer available in this udev version >>>>> >>>> >>>>> >>>> I suggest including in the news item, that /dev/root must be replaced >>>>> >>>> with the actual root device or LABEL=..., UUID=... and the like in >>>>> >>>> /etc/fstab. >>>>> >>>> >>> >> Well, *if* a line with /dev/root is present in /etc/fstab, the system >>> >> does not boot up properly (tested it right now). >>> >> I always though such a line in /etc/fstab is needed so that fsck is run >>> >> on the root filesystem... >>> >> >>> >> Removing the line completely boots up fine, but the filesystem has not >>> >> been fscked on boot. >> > >> > I don't think we ever instructed users for adding such line... if we >> > did, I'll eat my words. >> > So, I don't think it's necessary to instruct them away from it either, >> > never seen such fstab line. > Well technically, we used (and still use, see below) the uppercase > /dev/ROOT, with instructions documenting what to replace it with. But > some users apparently simply lowercased that ROOT, and for years it "just > worked". (Below output edited slightly for posting. $>> indicates the > shell prompt.): > > $>>equery b fstab > * Searching for fstab ... > sys-apps/baselayout-2.2 (/usr/share/baselayout/fstab) > > $>>grep -i /dev/root /usr/share/baselayout/fstab > /dev/ROOT /ext3 noatime 0 1 > > $>> > > [TLDR folks can stop there. The rest is historic observation, arguably > interesting, admittedly ranty, but not vital.] > > Years ago (remember, my first successful gentoo install was 2004.1), the > fstab example file found in /usr/share/baselayout/fstab was packaged as > /etc/fstab directly. Now, the handbook of the era took great pains to > guide people thru editing it appropriately, saying the ALLCAPS entries > were intended to be replaced as appropriate for the individual install, > AND people were expected to actually use etc-update or the like for its > intended purpose, so people weren't /supposed/ to have it simply > overwritten. I started using Gentoo in the 1.4 days. I to changed /dev/ROOT to /dev/root and added the proper locations/options for root and every other mount point I have. This is the first I have heard of fstab not needing the root mount line. If this is a change, someone needs to tell the users, even us old timers. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: RFC: new "qt" category
Ben de Groot wrote: > On 20 January 2013 21:35, Dale wrote: >> Same here. I have had to re-emerge qt packages several times myself. >> It seems that when I do, I have to do them all one at a time too. > In which case you're better off with something like: >emerge -a1 `eix --only-names -IC qt` > I'm not a developer and I don't write fancy commands like that. When something needs to be emerged or re-emerged, I do it by hand. Sometimes, I emerge one, then emerge the next one etc etc. Sometimes I put all packages on the same line. I don't use commands like yours unless I copy and paste it from a news item or something. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: RFC: new "qt" category
Duncan wrote: > Ben de Groot posted on Sun, 20 Jan 2013 16:24:14 +0800 as excerpted: > >> On 20 January 2013 00:48, Duncan <1i5t5.dun...@cox.net> wrote: >>> *** (VERY strongly!) Please avoid namespace pollution! Don't drop the >>> hyphenated qt-pkg names. As a user, most of the time I DO only refer >>> to the package name, and dropping the qt- from qt-core, qt-gui, etc, is >>> WAYYY too generic to be practical. I for one would be cursing the >>> generic names every time I had to deal with the package. (Tho it's a >>> kde upstream issue, the same applies to "the application formerly known >>> as kcontrol", now the impossibly generic system-settings, and the >>> former ksysguard, now generically system-monitor. Anyone active on the >>> kde general or kde linux lists knows I simply refuse to use the generic >>> names.) >> And how often do you specifically emerge individual qt modules? These >> are usually pulled in as dependencies, and the great majority of users >> do not have to deal with this. (Just emerge smplayer, or emerge >> kde-meta, or emerge -uD1 @world ...) > More often than one might think. =:^] > > Same here. I have had to re-emerge qt packages several times myself. It seems that when I do, I have to do them all one at a time too. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: eudev project announcement
J. Roeleveld wrote: > However, it is, in my opinion, a workaround for a problem that has > been forced upon me. As soon as eudev is stable enough, I will dump udev. >> [1] https://bugs.gentoo.org/441004 > Strange, I use a current-stable version of genkernel, /usr is on LVM and the > system boots correctly without issues. > > -- > Joost > > Same here. I have /usr on LVM and plan to use eudev as SOON as it is ready. I'm just waiting on someone to post that it is as easy as unmerging udev and emerging eudev and maybe a reboot. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: eudev project announcement
J. Roeleveld wrote:
> On Friday, December 21, 2012 08:52:00 AM Dale wrote:
>> J. Roeleveld wrote:
>>> On Friday, December 21, 2012 08:51:09 AM Ian Stakenvicius wrote:
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA256
>>>>
>>>> On 21/12/12 03:10 AM, J. Roeleveld wrote:
>>>>> An init* needs to be kept in sync with the rest of the system as
>>>>> well.
>>>> Just to be clear, by "init*" you mean {initrd,initramfs} , correct?
>>> Yes
>>>
>>> On the Gentoo-user mailing list, that's one of the two common ways of
>>> referring to it. The other one is " init-thingy ". ;)
>>>
>>> --
>>> Joost
>> I plead guilty on starting this one. It was I. Joost, point your
>> fingers at me. It's OK.
> Dale, you may have invented the word " init-thingy ", but others have started
> to copy it :)
>
> --
> Joost
>
>
That name is better than what I would like to call it. o_O
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
Re: [gentoo-dev] Re: eudev project announcement
J. Roeleveld wrote:
> On Friday, December 21, 2012 08:51:09 AM Ian Stakenvicius wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 21/12/12 03:10 AM, J. Roeleveld wrote:
>>> An init* needs to be kept in sync with the rest of the system as
>>> well.
>> Just to be clear, by "init*" you mean {initrd,initramfs} , correct?
> Yes
>
> On the Gentoo-user mailing list, that's one of the two common ways of
> referring to it. The other one is " init-thingy ". ;)
>
> --
> Joost
>
>
I plead guilty on starting this one. It was I. Joost, point your
fingers at me. It's OK.
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
Re: [gentoo-dev] Re: Wordiness
Michael Mol wrote: > On Fri, Dec 21, 2012 at 8:31 AM, Matt Turner wrote: >> On Thu, Dec 20, 2012 at 11:05 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> My point is that you consistently write long essays that I, and >> apparently most others, don't bother to read. I'm not sure if you're >> aware of this. >> >> Someone said on IRC this morning in response to this thread >> >>> the tragic thing is that guy would be able to make valuable contributions >>> if it weren't for the excessive length of his mails >> So, your emails are way too long. A huge percentage of recipients >> don't bother to read them. I don't know whether you just enjoy writing >> (you must!) or if you hope to actually be heard, but as it stands now >> you're not being heard by most. >> > I dunno. I read them. > > Duncan, I think the clue here, though, is that you should start a > blog. I'd read that, too. :) > > > -- > :wq > > Me too. He does give a history of why things are the way they are when he writes. Sometimes that history gives context and good reasoning. I might also add, some people write short emails then have responses that request more info. I think Duncan just heads those off and makes his point the first time around. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Moving our/portage stuff to var
Ciaran McCreesh wrote: > On Thu, 20 Dec 2012 18:44:06 +0100 > Ulrich Mueller wrote: >> There's no good reason for nesting it so deeply. As it is proposed >> above, /var/cache/portage would contain only two subdirectories, and >> /var/cache/portage/repositories only a single "gentoo" on a stable >> system. Also /var/cache itself isn't overpopulated; I count about ten >> entries on my systems. > You really think most people don't have to use overlays? > >> We should go with a shorter (easier to remember, easier to type) path >> and move things at least one level up. Two would be even better. > You shouldn't ever be typing that path in... > I was thinking tab completion myself. Just hit a couple letters and hit tab. That tab key types much faster and more accurately than I can. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] eudev project announcement
Roy Bamford wrote: > On 2012.12.15 03:52, Richard Yao wrote: >> Dear Everyone, >> >> I am pleased to announce the Gentoo eudev project. > [snip] >> Yours truly, >> Richard Yao >> > [snip] > > I welcome the choice that this new project brings, that's what Gentoo > is about - choice. > > I wish eudev both good luck and success. Success comes in many forms, > so I won't try to predict exactly what that means. Suffice to say, we > will all recognise it when we see it. > +1 and I'm looking forward to using it too. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
Michael Orlitzky wrote: > On 12/01/2012 09:48 PM, Duncan wrote: >> Chí-Thanh Christopher Nguyễn posted on Sun, 02 Dec 2012 01:28:26 +0100 as >> excerpted: >> >>> If this change is applied anyway, I suggest to at least produce a news >>> item in order to not surprise users about the sudden loss of their >>> openldap server. >> I wouldn't object to a news item. More information is good. >> >> >> >> However, hasn't it always been gentoo policy to *STRONGLY* encourage >> users to run emerge --pretend/--ask and EXAMINE THE RESULTS for anything >> unexpected, and resolve it in one way or another to "expected", before >> going ahead? >> >> Thus, anyone suddenly losing their openldap server as a result of a >> simple uncaught USE flag change, "gets to keep the pieces", as the saying >> commonly goes. Gentoo has /always/ been about reasonable documentation >> but has /never/ been about handholding. We've never been afraid to point >> users who expect to be handheld or babysat to other distributions that >> are a more appropriate match to their expectations. > We should! This is just an excuse for shitty QA. These things have real > consequences for real people. > Normal user posting ahead: I don't see it as a QA problem. I see it as the person sitting in the chair not knowing what they are doing. Gentoo has never been a 'hand holding' distro. The info is given before the update, it is up to the person in the chair to notice the changes and adjust IF needed. >> So yes, a news item is reasonable as it's arguably part of that "good >> documentation". But in general, there's something wrong if we're unduly >> worrying about loss of functionality involving a USE flag change, or even >> a simple USE flag default change, because equally as arguably, anyone not >> catching such things with the --pretend/--ask they do BEFORE letting >> things just run, and/or not following up accordingly, really should be >> thinking about a distribution other than gentoo in the first place. >> That's a fact that's not really practical to change at this point, both >> because we haven't the manpower to do all the required handholding, and >> because it would make gentoo into something it's not, and something it >> was never intended to be. Paraphrasing Star Trek's Bones, that would be >> "Gentoo, Jim, but not as we know it." >> >> >> > I beat my wife, is it her fault she gets beaten for choosing to be with > me? Don't blame the victim. If she chooses to stay with you, then she lives with that choice. She may be the victim but she chose to stay and that is her decision. Maybe she likes it that way. Who knows. > > Handholding != making an effort not to screw up people's systems. Even > with emerge --pretend, all I'm going to see is that the minimal flag > switched from off to on by default. Which I'll interpret as meaning, > "the minimal flag was changed so that openldap[minimal] today means what > openldap[-minimal] did yesterday." > > Someone's going to reboot three months after this change and their whole > office is going to be down while they try to figure out why they don't > have an LDAP server. For even a small business, that could mean > thousands of dollars. > > "Ha ha, you shouldn't have trusted me!" is not the appropriate response. > > If you see the flag changing, best find out what that change is about BEFORE you update. I do this every time I update. I check USE flag changes, upgrade/downgrade and anything else Zac has done to help me see what is coming. A news item is fine to give additional notice but it is still up to the person in the chair. As a user, I don't expect Gentoo to hold my hand like I am a 3 year old crossing the road. If a person needs that hand holding, maybe Gentoo is not for them. There are plenty of distros that hold your hand while you cross the road. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
Peter Stuge wrote: > Michael Orlitzky wrote: >> I just get annoyed with the "don't use Gentoo unless you like your >> stuff broken" attitude. > Don't confuse stuff changing with stuff breaking - they are very > different things. > > In Gentoo stuff changes every single day. I heard that gentoo-x86 > gets some number of commits per hour, or was it per minute.. > > Stuff generally doesn't change for changes sake, but because the > change is an overall improvement to Gentoo. Gentoo being source > based is also a big part of why there are so many and frequent > changes. > > This means that anyone who wants to use Gentoo and have a system > which reliably does what they want it to do *need to pay attention*. > > They need to pay attention to what happens upstream, and they need to > pay attention to what happens in Gentoo. Not by monitoring every > mailing list, but by monitoring what portage will do when they use > it, and by being sure that this is what they desire. USE flags are a > huge part of this. Guessing at what any USE flag means is no good, so > yes, sometimes it is needed to actually look at the ebuild to learn > what will happen. Personally I find ebuilds to be amazing as > documentation, because they are also the actual code. > > I've built some Gentoo systems tailored to specific needs which work > great but which are not getting updated, because the sysadmins who > take care of those systems since they were deployed aren't > comfortable and efficient with Gentoo. That's fine - Gentoo is > clearly not a system for everyone. > > But it *is* a fantastic system for those who are aware that a finely > tuned machine requires good care, and who are able and willing to > take such care, by being active in creation of their systems. It is > fantastic because it is so easy for Gentoo to change for the better, > which happens constantly. > > I think USE=-server is a great way to change the ebuild for the > better. I don't care at all about a news item. They are generally > only annoying me. :) > > > //Peter > > +1 As a regular desktop user, I know to look before updating. If I don't understand something, I search the mailing list in the past week or so in case someone else has run into the issue, I search the forums but most importantly, I also read this mailing list. Generally changes are talked about here first. The others are my backups. If none of those answers my question, I don't update until I get a answer. If needed, I ask on the -user mailing list what something is for or what something means. Basically, it is up to me to educate myself about changes. It has always been like this, when you update, do -p or -a first. If you blindly update, you get to fix it because it is your own fault for the breakage. Zac, he has done one heck of a job with portage giving us information. We can see USE flag changes and everything else BEFORE emerge does anything. If a person doesn't do that, they are going to cause themselves trouble and they should only complain to themselves. Gentoo has never been a distro to hold a persons hand. If a person needs their hands held, they should have chosen another distro. Gentoo is not a hand holding distro. It's just a distro that has great docs for people to learn first, then update. This has been a users perspective. Back to my hole. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] How to raise money for Gentoo
Alec Warner wrote: > On Thu, Sep 27, 2012 at 4:11 PM, Dale wrote: >> wbrana wrote: >>> Page www.gentoo.org asks for donations >>> "Donate to support our development efforts." >>> Gentoo could get more money if all *.gentoo.org would contain >>> advertisements. >>> >>> >> >> My questions are this: Does Gentoo need more money? Is it in need of >> more funds to support itself? > On a yearly basis, we take in more money than we spend. We primarily > spend money on fees (legal, accountant, etc) and funding requests > (infra hardware, requests from foundation members.) > > Its all on http://foundation.gentoo.org if you are curious. The 2011 > report notes that we have approximately $70,000 USD in funds. Some > Gentoo developers want to do more conference-type events. However > those typically come with much higher budgets than our funds and > require sponsors to make happen. Without clearer goals on what to > spend the money on, I can't really see the need to increase our > advertising. > > We primarily get money from Paypal and Google Summer of Code. > > -A > >> Dale >> >> :-) :-) >> >> -- >> I am only responsible for what I said ... Not for what you understood or how >> you interpreted my words! >> >> > Thanks for the answer. If Gentoo ever gets to a point where it needs funds to maintain itself, I would like a dev to post to the user mailing list. I'm certain we could donate if we know there is a need. I certainly would and I'm sure others would too. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] How to raise money for Gentoo
wbrana wrote: > Page www.gentoo.org asks for donations > "Donate to support our development efforts." > Gentoo could get more money if all *.gentoo.org would contain advertisements. > > My questions are this: Does Gentoo need more money? Is it in need of more funds to support itself? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Questions about SystemD and OpenRC
Michał Górny wrote: > On Tue, 7 Aug 2012 13:31:32 -0400 > Michael Mol wrote: > >> On Tue, Aug 7, 2012 at 12:29 PM, Michał Górny >> wrote: >>> On Tue, 7 Aug 2012 11:33:59 -0400 >>> Sylvain Alain wrote: >>> >>>> The KDE team seems to work on that too : >>>> http://lists.kde.org/?l=kde-core-devel&m=134052539215508&w=2 >>> it's actually worth it. >>> more user-spread FUD or however you like to call it on the topic >>> than I'm not sure if *devs* are actually working on that. I believe >>> there's >> Perhaps not official Gentoo devs, but users taking development >> initiative to solve a problem in userland. I'm not an official Gentoo >> dev, either, but I think it'd be a very bad idea to discourage or >> ridicule such initiative. Someone putting in that much effort in light >> of all the information already available isn't something that should >> be taken lightly! > I don't want to offend anyone but let's be honest: people start many > initiatives, and they are not always right, no matter how many effort > is put. I don't want to discourage it but sometimes I dislike > the importunity accompanying it. > > Users are free to do whatever they want as long as it doesn't harm > the rest of users. And I'm afraid that too much enthusiasm over mdev > will actually cause a number of users to end up being disappointed > that one or another magic requiring udev no longer works. User perspective follows: What I don't like about the way Walter, mdev, is being treated is this. People say that if you don't like the way udev is going, WRITE CODE. If you are not going to write code, don't complain about udev. Then Walter, I think I got the name right, comes along and comes up with a alternative for udev that seems to work well for the people using it. Then people complain because he is actually stepping up and WRITING CODE. Well, it seems a person can't win on this. Some, no names mentioned, need to make up their minds. Either listen when people don't like the way things are going or let people write code to have a alternative to whatever people are not liking and don't complain because people are stepping up and doing something about it, for example, writing code. As to mdev not being as feature rich as udev, well, some people don't need the features udev has and I don't think anyone is saying mdev is the same as udev. It even says on the wiki that there are some situations where it should not even be tried because it is known to not work. Given that, if a person tries to use mdev to replace udev in a situation where it is known not to work, then they should read more closely. It's not Walters fault, it's the person in the chair. Now, since Walter didn't like the way things are going, can he write code and be left in peace to do so? Maybe have a little bit of support while he is doing it? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
Rich Freeman wrote: > On Tue, Jul 24, 2012 at 2:59 PM, Fabian Groffen wrote: >> On 24-07-2012 14:52:43 -0400, Rick "Zero_Chaos" Farina wrote: >>> This is a change that will break all new installs and expecting >>> experienced gentoo users to read the handbook is simply a fantasy. >> I don't see how it breaks. And secondly, if you do refuse to read the >> manual, why don't you refuse to read elogs, news messages, and what >> more? > The difference is that news only communicates what is "news." Unless > the manual contains a revision history it contains everything you > already know, perhaps with a gem buried in there somewhere. > > This is the same reason why when something is wrong with Chromium you > are supposed to post a 5-line patch to the bug and not a 300MB tarball > with the patch applied, though at least in that case modern tools > actually make finding the change fairly easy. > >> Do we really have to babysit people, because they think they're too >> smart to check on the manual once again? Or when they notice things >> seem different? Any search engine is your friend. > There is the principle of not surprising people. This is a big change > - a file central to the config of Gentoo that has been in one place > for more than a decade, and is now moving. The change makes sense and > should be embraced, but there is no harm in pointing it out. > > Sure, when my system breaks I'm pretty smart and can usually figure > out how to fix it. That doesn't mean that I don't appreciate a > heads-up before it breaks. > > Rich > > +1 I might also add, I printed the manual years ago. I rarely look at the online version. User opinion. Back to eating my apple pie. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
Rich Freeman wrote: > On Tue, Jul 24, 2012 at 7:07 AM, Fabian Groffen wrote: >> I don't know about general consensus. In my opinion, it's plain spam to >> existing users. (And that would IMO be the xth news item in a row to be >> spam.) > Can't say I agree here. Some news items have been more useful than > others, but I doubt the typical Gentoo user (who does not subscribe to > -dev) would think that many of the past messages have been spam. > > << SNIP >> > > Rich > > I agree with this. I see messages that may not apply to me but I always keep in mind that it may apply to a large number of other users. I would MUCH rather see a message sent out that doesn't apply to me than to not see one that should have been sent out but wasn't. Just a users opinion and expectations. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Opinion against /usr merge
William Hubbs wrote: > On Tue, Jul 17, 2012 at 06:13:06PM -0500, Dale wrote: >> William Hubbs wrote: >>> >>> This is not quite correct. The initramfs is required because of [1]. >>> >>> >>> William >>> >> Where is [1]? > [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > We have a way around this in some limited circumstances with > busybox[sep-usr], but that definitely does not support anything fancy > like rade, lvm, etc. > > William > Ah, read that link a while back. Nothing new there I don't guess. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Opinion against /usr merge
William Hubbs wrote: > > This is not quite correct. The initramfs is required because of [1]. > > > William > Where is [1]? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Greg KH wrote: > On Sat, Jun 16, 2012 at 06:37:41PM -0500, Steev Klimaszewski wrote: >> Just picking a random response to reply to. I'm not speaking >> officially, however, I'm pretty sure we at Genesi aren't going to pay >> Microsoft in order to boot our own boards. > If you don't want your boards to be Windows 8 certified, then you are > fine. Otherwise, you have to follow their guidelines, which I don't > think requires paying them any money if you want to run Windows 8. > > Also, as these are "your own boards", you control the BIOS, so you don't > even have to implement UEFI, or, if you do, you can control what keys > are installed in the BIOS by default. > > So I don't understand the issue here, please explain. > > greg k-h > > . > I'm glad you said that. If I was going to have to pay M$ to run Linux, I was thinking of shooting them with laser eyes or something. I have no plans to ever support M$ in any shape, form or fashion. Period. Thing is, they will likely try to make it so you can't disable it eventually. Some politician will try to make it a law if nothing else. After all, politicians are clueless anyway. Reminds me of chickens and it raining. :/ Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
Duncan wrote: > > Looking at the broader picture, the problem of extraneous packages in the > world file has always concerned me. If it were to be done over again, > and I think Zac would likely agree, emerge would use --oneshot by > default, so as not to contaminate the world file unnecessarily. Then > there'd be a different option (say -2) to add the package to the world > file if that's what was actually intended. > > That's actually how I have my emerge front-end scriptlets/aliases setup > here. -1 is the default; if I want it in the world file I use the *2 > script variant, which omits the -1. > > But of course changing behavior in mid-stream doesn't work so well, so > emerge continues to stick stuff in the world file by default. > I added -1 to my make.conf a long time ago. Whenever I emerge something and want it in the world file, just use the --select option. If I already emerged something but then want to add it to the world file, just add the -n option too. That keeps the world file clean and I can test things before adding anything to the world file. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
Ben wrote: > On 6 May 2012 08:29, Dale wrote: >> I mentioned this once a long time ago. We expect things to stay the >> same unless we do something to change them. If things change without us >> doing the change, we tend to freak out a bit. We don't need any >> freaking out. > > Sounds to me like it would be a good idea to make a new, more minimal profile. > What do you guys think? > > Cheers, > Ben | yngwin > > Me, I don't mind the change but please let us know if the current one is changed. Why not put this in for the 2012 or 11 profile? Whatever number comes next. That way the users will know to look and have to change to the new profile. I usually do a emerge -uvaDN world before I change profiles, then change the profile and repeat with -a. That is when I expect to see USE flag changes and lots of other goodies that you devs do. :-) Someone mentioned a news item. That would work but maybe a new and fancy profile would work too. Someone may want to make others changes to while they are at it. Just a thought. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
Michael Weber wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 05/05/2012 09:55 PM, Dale wrote: >> Not to mention, you add the possibility that the user may miss the >> change since they are not expecting it. I would expect it when I >> was changing profiles but not so much just coming out of the blue. > > We should make emerge -v (display USE flags) non-optional. > Users should be trained to recognize the green/red use flag changes. I already have mine set that way. I also try to watch for the changes but sometimes the way the lines wrap I may miss one here and there. That has bit me a couple times. I sort of expect USE flags to stay the same for the most part. Profile changes are expected to change things but I rarely change those. I mentioned this once a long time ago. We expect things to stay the same unless we do something to change them. If things change without us doing the change, we tend to freak out a bit. We don't need any freaking out. Dale :-) :-) > > Do whatever you what, I've set make.conf:USE=ldap on machines relying > on it. > > Michael -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
Jesus Rivero (Neurogeek) wrote: > > On May 5, 2012 3:14 PM, "Markos Chandras" <mailto:hwoar...@gentoo.org>> wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> On 05/05/2012 06:10 PM, Alec Warner wrote: >> > On Sat, May 5, 2012 at 5:31 PM, Maxim Koltsov >> > mailto:maksbo...@gentoo.org>> wrote: >> >> Hi, I just installed fresh system on my pc, selected >> >> 'default/linux/x86/10.0/desktop' profile and noticed ldap among >> >> default USE flags. Why is that needed? I suppose there are more >> >> users w/o ldap auth on desktops than with it. So my proposal is >> >> to remove it from profiles/targets/desktop/make.defaults. Any >> >> objections? >> >> >> > >> > So how are you going to avoid destroying machines that rely on it >> > being on by default? >> > >> > -A >> > >> Users will note the use flag change when they run "emerge -uDN world" >> and they will add it to their make.conf. I am also in favor of >> dropping ldap from the desktop profiles. > > I don't like this change much. There are valid use cases for an ldap use > flag in the desktop profile that could break easily with this change. > > Also, you could make the same case for adding -ldap to your make.conf Not to mention, you add the possibility that the user may miss the change since they are not expecting it. I would expect it when I was changing profiles but not so much just coming out of the blue. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] Chromium bundled code
Greg KH wrote: > On Fri, May 04, 2012 at 11:02:01AM -0700, Luca Barbato wrote: >> On 03/05/12 18:22, Mike Frysinger wrote: >>>> (As soon I have some time I might dabble with a dbus integration for mdev) >>> >>> we would have to make mdev available as a sep package then ... don't want >>> busybox itself linking against anything beyond the C library. >> >> The integration would be mdev -> shell -> dbus or mdev -> socket -> >> dbus. I consider dbus still not reliable for core services. > > When was the last time dbus crashed on you? > > And what would you consider "reliable" enough for "core services"? dbus > has proven itself over _many_ years to handle all of the issues that > something like this requires very well. It's a non-trivial thing to > implement and the authors of it have done a very good job, after > learning how to do it from other failed attempts at the same thing. > > And what are you going to do when dbus moves into the kernel itself > (hint, it will be there soon)? How are you going to not use it then? > > greg k-h > > This question is not directed at me but I'll give a response to my experience a few months ago. I woke up to my system fans blowing like crazy. Trust me, if you can hear noise on a HAF-932, they are spinning pretty good. It was mostly air I was hearing but anyway. I use KDE and have Konsole open at all times. I switched to the desktop with it, after noticing on Gkrellm that my CPU was maxed out and that almost all my ram was in use and some swap too. I don't mean cached or anything either, I mean actively in use. At any rate, when it finally switched to the desktop with Konsole on it, which took a bit, I ran top. At the top for both CPU and memory usage was dbus. I tried to restart the dbus service, thinking it would kill it and restart without all the ram and CPU usage. I could then logout and back in, maybe. I never got my prompt back and it never showed dbus as stopped either. I then switched to a console. I did a 'rc boot' and it was slowly switching to it and did but it couldn't stop the dbus service. I just typed in reboot and let it restart from scratch. Was it dbus itself, I dunno for sure. I am sure it was dbus that was maxing out my CPU and ram. I did recompile dbus after the reboot and it has not done it since. If I could reproduce it or had more info, I would have mentioned it when it happened. I'm thinking rays from Mars or something. ;-)It wasn't hardware either. This system has been running fine ever since. By the way, I have 16Gbs of ram. If I recall correctly, dbus was using over 14Gbs of ram and something was using swap. Keep in mind, I had KDE running with Seamonkey, Konsole, Konqueror and a couple other apps open. I use about 1.5Gbs when my desktop is in normal use. Swappiness is set to 20. In other words, only use swap when it is getting deep. It was using half my swap so it must have been pretty deep. So, even dbus can have a bad day at times. Sure wish I knew what caused it tho. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] Re: rfc: location of portage tree
Duncan wrote: > Ian Stakenvicius posted on Wed, 28 Mar 2012 15:53:16 -0400 as excerpted: > >> Although, we could always make emerge do an automatic --sync if, say, >> /path/to/portage/profiles doesn't exist. :) > > Ugh, no. Some (many?) of us have a separate portage tree partition, and > occasionally accidentally do an emerge without it mounted. > Having portage decide that it should automatically start downloading a > new tree directly onto the filesystem containing the mountpoint is *NOT* > ideal! > +1 Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] Re: About suggesting to create a separate partition for portage tree in handbook
Duncan wrote:
> Dale posted on Wed, 28 Mar 2012 19:35:40 -0500 as excerpted:
>
>> Joshua Saddler wrote:
> Agreed, tho ACTUALLY having the documentation available, AND LINKING to
> it in the handbook ("For an in-depth discussion, read..."), would be a
> good thing.
>
>> Well, way back when I first installed Gentoo, I actually read some
>> before I even started. I learned through all that reading that /,
>> /boot, /home, /usr, /usr/portage and /var are best on their own
>> partition. Each of those are for different reasons.
>
> Same here. It's a bit of a point of pride for me that before I even had
> my own gentoo system installed (some problem due to my wanting posix
> threading, then relatively new to Linux, over Linux threads; didn't work
> for me with 2004.0, worked great with 2004.1), I had read the handbook,
> etc, and was replying on the lists to questions from folks who obviously
> hadn't read up...
I started with 1.4. Dang I'm getting old. It's one reason I would hate
to leave Gentoo.
>
> But I already had a good idea what I wanted my partition layout to look
> like based on my Mandrake experience. The questions I needed to ask,
> because they were NOT covered in the manual (or anywhere else in the
> documentation I could find at the time), and because they were self-
> evidently going to have rather different answers on gentoo than on
> mandrake, were things like:
>
> Just how big IS the portage tree?
>
> What about the package tree?
>
> What about the sources tree?
I think I found that info somewhere before I installed. Plus, one could
ask someone on IRC too. If they have it on a separate partition, the
results of df would be good enough and quick.
>
> After a couple partition reorganizations, I ended up with sources inside
> the portage tree, but packages on its own partition, making it easier to
> keep packages backed up, something the portage tree and sources don't
> need as the net's a far more sufficient backup for them than I could ever
> manage locally.
>
>
> For years I've thought that a bit more emphasis should be placed on
> FEATURES=binpkg, given the many ways it can save your ass and/or make
> troubleshooting a current version issue far easier. And while I agree
> that the installation section of the handbook, in any case, isn't the
> place for complex discussion of the many system partitioning schemes and
> their positives/negatives, information such as the above, exactly what
> sort of realistic sizes can be expected for the portage tree itself, for
> sources, and for binpkgs (if the feature is enabled), should be covered.
>
> That's because most gentoo users have at least some experience on other
> distros before they come to gentoo, and thus likely already have a
> preferred partitioning setup... if they care about it at all. All they
> really need is information about the relative sizes of gentoo-specific
> features, the ebuild tree, sources, and binpkgs, and perhaps a bit better
> coverage of the binpkgs option (which I'd simply link-punt in the install
> section as well, but cover it a bit better under the working with portage
> section, with the install-section link pointing there).
>
>> The root partition is obvious, I would hope anyway. ;-) The boot
>> partitions comes in handy if you don't automount it or have more than
>> one distro installed. Home is obvious. People recommended /usr because
>> it could a) be mounted read only and b) it can be enlarged if needed
>> since it tends to grow a lot. Portage since it is tons of small files
>> and tends to fragment a lot. The var partition is so that if some error
>> message repeats itself overnight and fills up the partition it at least
>> doesn't lock up the whole system. I actually had this one happen to me
>> once. For some reason, even logrotate didn't catch it, tar up and
>> delete the old ones. I woke up to a mess that only going to single user
>> would fix. The best thing I did was to have /var on its own partition.
>
> FWIW, that's /var/log on it's own partition here, for exactly the reason
> you mention. But /var itself is on rootfs here, these days.
That would work too. At the time, /var was recommended.
>
>> When people are planning to install Gentoo and they have not done at
>> least some research, I think they should get to keep the pieces.
>> Installing Gentoo is not something to do on a whim. It should be
>> planned and thought through even if the person is completely new to
>> Gentoo. I read up for at least a month before ever even starting.
>
>
Re: [gentoo-dev] rfc: location of portage tree
Marc Schiffbauer wrote:
> * Aaron W. Swenson schrieb am 27.03.12 um 21:59 Uhr:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 03/27/2012 03:47 PM, Alec Warner wrote:
>>> On Tue, Mar 27, 2012 at 12:40 PM, William Hubbs
>> /var/cache/{ebuilds,distfiles,eclasses,profiles}
>>
>> Or we can just call it Portage.
>>
>> We call it the "Portage tree", just like we call it gentoo-x86 but
>> that isn't what it only contains, in several places, both in official
>> docs and unofficial docs, tweets, pins, notes, stickies
>>
>> /var/cache/portage is my vote.
>
> +1
>
> I like the idea of one directory because I wthink lots of people do
> have that stuff in a dedicated filesystem which today is mounted on
> /usr/portage. It would only have to be mounted to /var/cache/portage
> and this people were done with "migration".
>
> Having several directories will make it much harder to make "the
> portage stuff" be in its own fs. (be it several fs or symlinks ...)
>
> -Marc
As a lowly user, I would like it on /var but could careless about the
directory though the above would work fine. Reason, I have /var on its
own partition already. I also have /usr/portage on its own too. Since
the /usr/portage has lots of ever changing files and CAN get fragmented
a lot, this solves a lot of issues since a lot of things in /var are in
the same boat. A user could use a file system that is better at this
sort of thing and have only one partition to handle it all.
Back to my hole. Twice now.
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!
Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
Joshua Saddler wrote: > On Tue, 27 Mar 2012 19:49:00 +0200 > Pacho Ramos wrote: > >> Hello >> >> I am a bit surprised handbook still doesn't suggest people to >> create a separate partition for /usr/portage tree. I remember my >> first Gentoo systems had it inside / and that lead to a lot of >> fragmentation, much slower "emerge -pvuDN world" (I benchmarked it >> when I changed my partitioning scheme to put /usr/portage) separate >> and a lot of disk space lost (I remember portage tree reached >> around 3 GB of disk space while I am now running with 300MB) >> >> Could handbook suggest people to put /usr/portage on a different >> partition then? The only doubt I have is what filesystem would be >> better for it, in my case I am using reiserfs with tail enabled, >> but maybe you have other different setups. >> >> Thanks for discussing this :) > > not gonna happen, for reasons that SwifT & others already mentioned. > this is the sort of non-simple, non-trivial text/info/instructions > that would be better suited to an "optimizing your FS layout" article > on the gentoo wiki, or similar. Well, way back when I first installed Gentoo, I actually read some before I even started. I learned through all that reading that /, /boot, /home, /usr, /usr/portage and /var are best on their own partition. Each of those are for different reasons. The root partition is obvious, I would hope anyway. ;-) The boot partitions comes in handy if you don't automount it or have more than one distro installed. Home is obvious. People recommended /usr because it could a) be mounted read only and b) it can be enlarged if needed since it tends to grow a lot. Portage since it is tons of small files and tends to fragment a lot. The var partition is so that if some error message repeats itself overnight and fills up the partition it at least doesn't lock up the whole system. I actually had this one happen to me once. For some reason, even logrotate didn't catch it, tar up and delete the old ones. I woke up to a mess that only going to single user would fix. The best thing I did was to have /var on its own partition. When people are planning to install Gentoo and they have not done at least some research, I think they should get to keep the pieces. Installing Gentoo is not something to do on a whim. It should be planned and thought through even if the person is completely new to Gentoo. I read up for at least a month before ever even starting. I agree with having a simple manual for the folks that want to install just to look and then have a separate manual, wiki even, for more serious set ups. This can include things like RAID, LVM and having more than a couple partitions. Of course, Gentoo is almost endless in options. Back to my hole. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
Rich Freeman wrote: > On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs wrote: >> here is the udev 181 unmasking news item. >> >> If all goes well, this will be committed to the tree on 3/14 UTC. > > I guess this might be OK for unstable, but before this goes stable we > really need to improve the docs around this. As far as I can tell > neither the genkernel nor dracut docs have specific instructions about > how to handle mounting /usr. Since having a separate /usr is often > the result of having a more complex configuration (nfs, lvm, mdraid, > etc), instructions explaining how things work and how to handle > variations is pretty important. Perhaps genkernel automagically does > the right thing in some cases, but I know that dracut does not unless > you properly configure it. I doubt either tool will handle more > complex situations without some scripting. > > I'm not really asking for automation here - just documentation and > reasonable stability in how things work. > > Again, this is likely more of a concern before this is stabilized. > However, knowing what I went through to get my bind-mounted /usr on > LVM+mdraid working with dracut, I can imagine that any unstable users > with tricky setups could face a fun weekend. > > Perhaps a suggestion for the news item. I'd recommend that anybody > who needs an initramfs to mount /usr get that working BEFORE they > upgrade udev. This situation is a heck of a lot easier to figure out > if the system still can be booted when the initramfs doesn't work. > > Rich > > +1 Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] About masking net-misc/mDNSResponder for removal
"Paweł Hajdan, Jr." wrote: > On 2/13/12 11:55 AM, Pacho Ramos wrote: >> El jue, 09-02-2012 a las 12:41 +0100, Pacho Ramos escribió: >>> Hello >>> >>> Looks like our net-misc/mDNSResponder packages are orphan and >>> unmaintained for a looong time, they also have some opened bugs (with >>> hangs, build problems...) and looks like avahi with mdns compat can >>> replace it. >>> >>> OK with masking it for removal? If not, is anyone willing to maintain >>> it? >> >> OK to start dropping it from dependencies and mask it for removal? > > Since there was no response to the original e-mail... I second this. > > +1 to remove the mess. > I just noticed this: kde-base/kdelibs-4.8.0-r1 (!bindist ? net-misc/mDNSResponder) kde-base/krdc-4.8.0 (zeroconf ? net-misc/mDNSResponder) media-libs/libgphoto2-2.4.11-r1 (zeroconf ? net-misc/mDNSResponder) net-misc/ntp-4.2.6_p4 (zeroconf ? net-misc/mDNSResponder) I'm assuming this is not going to break something. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] Re: The following USE changes are necessary to proceed - Why?
Ryan Hill wrote: > On Fri, 10 Feb 2012 19:20:30 -0800 > Zac Medico wrote: > >> On 02/10/2012 06:17 PM, Ryan Hill wrote: >>> On Fri, 10 Feb 2012 10:50:39 -0800 >>> Hilco Wijbenga wrote: >>> >>>> The following USE changes are necessary to proceed: >>>> #required by net-libs/gnutls-2.12.16[nettle], required by gnutls (argument) >>>>> =dev-libs/nettle-2.4 gmp >>> >>> I've been tripped up by this in the past. Can we change the order of the >>> lines or add some whitespace or indent it or make it a different color or >>> something? >> >> Okay, done: >> >> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=2d08e6c4520556e5acc0055cdb3d68028eed3243 > > wOOt! > Yea, he's getting quicker all the time. I'm scared to even *THINK* of something new now. :/ Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Zac Medico wrote: > On 01/21/2012 01:34 PM, Dale wrote: >> Michał Górny wrote: >>>> It's funny how I never needed one before either but now things are >>>> being broken. It's not LVM that is breaking it either. I wouldn't >>>> need the initramfs even if It was on a regular partition until the >>>> recent so called "improvements." >>> >>> ...and your main argument is 'long, long ago someone decided that it >>> should match the same taste as mine, so it should be like it forever'. >>> Of course, those times there were no such thing as an initramfs... >>> >> >> >> Then don't break that. Just because someone came up with a initramfs >> doesn't mean everyone should be forced to use one. > > The old way imposes requirements that are no longer supported by > upstream software. So, you basically have three choices: > > 1) Use old software that supports the old way > 2) Develop new software to support the old way > 3) Use an initramfs or pre-init script to mount /usr if it must be on > a separate partition So the solution is to break things because things are broken. Sort of running in circles there. Pardon me, I'm dizzy. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: > On Sat, 21 Jan 2012 15:34:39 -0600 > Dale wrote: > >> Michał Górny wrote: >>> On Sat, 21 Jan 2012 06:28:54 -0600 >>> Dale wrote: >>> >>>> Michał Górny wrote: >>>>> On Wed, 18 Jan 2012 01:20:03 -0600 >>>>> Dale wrote: >>>>> >>>>>> Michał Górny wrote: >>>>>>> On Tue, 17 Jan 2012 21:38:26 -0600 >>>>>>> Dale wrote: >>>>>>> >>>>>>>> Michał Górny wrote: >>>>>>>>> On Tue, 10 Jan 2012 19:14:52 +0100 >>>>>>>>> Enrico Weigelt wrote: >>>>>>>>> >>>>>>>>>> * Micha?? Górny schrieb: >>>>>>>>>> >>>>>>>>>>> Does working hard involve compiling even more packages >>>>>>>>>>> statically? >>>>>>>>>> I guess, he means keeping udev in / ? >>>>>>>>> Because adding 80 KiB of initramfs hurts so much? We should >>>>>>>>> then put more work just to ensure that admin doesn't have to >>>>>>>>> waste 15 minutes to recompile the kernel (if necessary), >>>>>>>>> create an initramfs and add it to bootloader config? >>>>>>>>> >>>>>>>> 80Kbs? You sure about that? I somehow failed to mention this >>>>>>>> before. I noticed it when I saw another reply to this post. >>>>>>>> Reality check: >>>>>>> 80 KiB is enough for mounting plain /usr and booting with it. >>>>>>> See tiny-initramfs (but I haven't tested it thoroughly). >>>>>>> >>>>>> >>>>>> My plan is to have /usr on lvm. I think it will end up larger >>>>>> and it still adds one more thing to break. >>>>>> >>>>>> I really wish someone would get a better plan. I think I see a >>>>>> garbage dump ahead with lots of Linux distros headed that way. >>>>> >>>>> Better plan how? LVM requires udev for some reason. Letting rootfs >>>>> grow with data unnecessary for a number of users is no good plan >>>>> either. Just install that initramfs, be done with it and let us >>>>> focus on actual work rather than fixing random breakages. >>>>> >>>>> We already usually have separate /boot to satisfy the needs of >>>>> bootloader. Then you want us to chain yet another filesystem to >>>>> satisfy the needs of another layer. Initramfs reuses /boot for >>>>> that. >>>>> >>>> >>>> >>>> The point is, I don't like initramfs. I don't want to use one. >>> >>> And I don't like binaries on rootfs. I don't want to have ones. >>> >>> So we're talking about taste... >> >> >> Actually, we're talking about how things has worked so well for a VERY >> long time and there is no need to reinvent the wheel. > > And required a considerable amount of work which increases due to > software getting more complex and users wanting more features. > > And I don't get 'the wheel' here? What wheel? I'd say we rather want to > get rid of the useless fifth wheel. Actually, they are adding the fifth wheel. > >>>> It's funny how I never needed one before either but now things are >>>> being broken. It's not LVM that is breaking it either. I wouldn't >>>> need the initramfs even if It was on a regular partition until the >>>> recent so called "improvements." >>> >>> ...and your main argument is 'long, long ago someone decided that it >>> should match the same taste as mine, so it should be like it >>> forever'. Of course, those times there were no such thing as an >>> initramfs... >>> >> >> >> Then don't break that. Just because someone came up with a initramfs >> doesn't mean everyone should be forced to use one. > > And noone is forced to update the system either. > Oh, that makes perfect sense. Thinks for the showing of brilliance there. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: > On Sat, 21 Jan 2012 06:28:54 -0600 > Dale wrote: > >> Michał Górny wrote: >>> On Wed, 18 Jan 2012 01:20:03 -0600 >>> Dale wrote: >>> >>>> Michał Górny wrote: >>>>> On Tue, 17 Jan 2012 21:38:26 -0600 >>>>> Dale wrote: >>>>> >>>>>> Michał Górny wrote: >>>>>>> On Tue, 10 Jan 2012 19:14:52 +0100 >>>>>>> Enrico Weigelt wrote: >>>>>>> >>>>>>>> * Micha?? Górny schrieb: >>>>>>>> >>>>>>>>> Does working hard involve compiling even more packages >>>>>>>>> statically? >>>>>>>> I guess, he means keeping udev in / ? >>>>>>> Because adding 80 KiB of initramfs hurts so much? We should then >>>>>>> put more work just to ensure that admin doesn't have to waste 15 >>>>>>> minutes to recompile the kernel (if necessary), create an >>>>>>> initramfs and add it to bootloader config? >>>>>>> >>>>>> 80Kbs? You sure about that? I somehow failed to mention this >>>>>> before. I noticed it when I saw another reply to this post. >>>>>> Reality check: >>>>> 80 KiB is enough for mounting plain /usr and booting with it. See >>>>> tiny-initramfs (but I haven't tested it thoroughly). >>>>> >>>> >>>> My plan is to have /usr on lvm. I think it will end up larger and >>>> it still adds one more thing to break. >>>> >>>> I really wish someone would get a better plan. I think I see a >>>> garbage dump ahead with lots of Linux distros headed that way. >>> >>> Better plan how? LVM requires udev for some reason. Letting rootfs >>> grow with data unnecessary for a number of users is no good plan >>> either. Just install that initramfs, be done with it and let us >>> focus on actual work rather than fixing random breakages. >>> >>> We already usually have separate /boot to satisfy the needs of >>> bootloader. Then you want us to chain yet another filesystem to >>> satisfy the needs of another layer. Initramfs reuses /boot for that. >>> >> >> >> The point is, I don't like initramfs. I don't want to use one. > > And I don't like binaries on rootfs. I don't want to have ones. > > So we're talking about taste... Actually, we're talking about how things has worked so well for a VERY long time and there is no need to reinvent the wheel. > >> It's funny how I never needed one before either but now things are >> being broken. It's not LVM that is breaking it either. I wouldn't >> need the initramfs even if It was on a regular partition until the >> recent so called "improvements." > > ...and your main argument is 'long, long ago someone decided that it > should match the same taste as mine, so it should be like it forever'. > Of course, those times there were no such thing as an initramfs... > Then don't break that. Just because someone came up with a initramfs doesn't mean everyone should be forced to use one. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: > On Wed, 18 Jan 2012 01:20:03 -0600 > Dale wrote: > >> Michał Górny wrote: >>> On Tue, 17 Jan 2012 21:38:26 -0600 >>> Dale wrote: >>> >>>> Michał Górny wrote: >>>>> On Tue, 10 Jan 2012 19:14:52 +0100 >>>>> Enrico Weigelt wrote: >>>>> >>>>>> * Micha?? Górny schrieb: >>>>>> >>>>>>> Does working hard involve compiling even more packages >>>>>>> statically? >>>>>> I guess, he means keeping udev in / ? >>>>> Because adding 80 KiB of initramfs hurts so much? We should then >>>>> put more work just to ensure that admin doesn't have to waste 15 >>>>> minutes to recompile the kernel (if necessary), create an >>>>> initramfs and add it to bootloader config? >>>>> >>>> 80Kbs? You sure about that? I somehow failed to mention this >>>> before. I noticed it when I saw another reply to this post. >>>> Reality check: >>> 80 KiB is enough for mounting plain /usr and booting with it. See >>> tiny-initramfs (but I haven't tested it thoroughly). >>> >> >> My plan is to have /usr on lvm. I think it will end up larger and it >> still adds one more thing to break. >> >> I really wish someone would get a better plan. I think I see a >> garbage dump ahead with lots of Linux distros headed that way. > > Better plan how? LVM requires udev for some reason. Letting rootfs grow > with data unnecessary for a number of users is no good plan either. > Just install that initramfs, be done with it and let us focus on actual > work rather than fixing random breakages. > > We already usually have separate /boot to satisfy the needs of > bootloader. Then you want us to chain yet another filesystem to satisfy > the needs of another layer. Initramfs reuses /boot for that. > The point is, I don't like initramfs. I don't want to use one. It's funny how I never needed one before either but now things are being broken. It's not LVM that is breaking it either. I wouldn't need the initramfs even if It was on a regular partition until the recent so called "improvements." Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
Duncan wrote: Considering glibc was just one of some 200-ish packages I rebuilt early today due to -N, most of the rest being kde-4.7.97 (aka 4.8-rc2) which will be in-overlay for just a few more days as 4.8-release is due next week, because gentoo/kde just removed the long-masked kdeenablefinal USE flag, which because it was masked (and I didn't unmask it) did NOT affect my kde as installed so I basically did the rebuild for nothing... I'm not going to complain much about a mere single package, glibc, triggering a -N rebuild. But I'm not going to complain about gentoo/kde doing it with 200-ish, either (way more if I had all of kde installed, I don't), for several reasons: 1) I'm not only running ~arch, I'm running the overlay. 2) I'm not only running the overlay, I'm deliberately unmasking and running upstream prereleases. But more important than either of those... 3) Mike's right. The -N is simply available to give users a way to be notified of such changes if they wish to be, presumably thru use of -p or -a. It DOESN'T mean they have to actually do the remerge, as they can either choose to ignore -N and not use it entirely, thus remaining blissfully unaware of such changes, or use it simply as notification, go look at the logs and see what the change was about, and decide based on that whether it's worth the remerge. I simply chose to do the 200+ package rebuild because I've learned that once I use -N to find out and investigate (which I do), after making any appropriate changes on my end, with a quad-core system, enough RAM to point PORTAGE_TMPDIR at tmpfs, and PORTAGE_NICENESS set to 19, it's simply easier to do the rebuild and not worry about it any more than it is to have to continue to mentally negate those changes every time I do the -N checks until I DO either rebuild or update. Plus, I look at it this way. It's winter here in Phoenix and while Phoenix isn't too cold, it was cold enough last nite that the extra computer heat from rebuilding a couple hundred packages didn't go to waste! =:^) If it were summer and I was having to run the AC to pump that heat outside, too, my decision may well have been different, especially since I'll already be updating to the full release when it comes out in a week or so. But then again maybe not, too, because I simply rest better when I know I'm all updated and my computer's all squared away with gentoo and the various overlays I follow. But either way, it's my decision, and I appreciate that Gentoo respects that and leaves the decision to me. =:^) That said, I also appreciate the care big projects like gentoo/kde normally take to synchronize such big changes to release, keywording and stabilization updates, as /either/ doing 200+ unnecessary rebuilds very often, or conversely, the constant tension of knowing I'm not fully synced if I continuously ignored -N packages, would get old rather fast. But for a single package, meh... I do a little overkill when I do my updates. I run emerge -uvaDN world and let it do its thing. I would rather rebuild a package or two, or possibly even more, and know for sure that my system is more sane than I am. I started doing it this way because I was running into issues with packages being upgraded and another kinda sort of needing it but not to the point that it poked portage in the eye. That said, if I start having the same issue with emerge -uvaDN world, I'll be doing emerge -ev world then, just to make sure it catches it all. I may not do that as often but at least it gives me the system stability I want. I do have one wish. I wish some changes were planned a little better. Things like KDE, LOo and a maybe a couple other large packages, get some change then just a few days latter, another change that requires a recompile. I do wish sometimes that both changes could be done at the same time. I'm not complaining mind you. It's just a wish. I'm with Duncan tho. It's cold right now. I can't get folding to download a unit and I need some HEAT. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dale wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigelt wrote: * Micha?? Górny schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: 80 KiB is enough for mounting plain /usr and booting with it. See tiny-initramfs (but I haven't tested it thoroughly). My plan is to have /usr on lvm. I think it will end up larger and it still adds one more thing to break. I really wish someone would get a better plan. I think I see a garbage dump ahead with lots of Linux distros headed that way. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Mike Gilbert wrote: On Tue, Jan 17, 2012 at 10:38 PM, Dale wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltwrote: * Micha?? Górnyschrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: root@fireball / # ls -al /boot/initramfs-3.* -rw-r--r-- 1 root root 5444240 Jan 1 07:24 /boot/initramfs-3.1.5-gentoo.img -rw-r--r-- 1 root root 5515132 Jan 9 07:57 /boot/initramfs-3.2.0-r1.img root@fireball / # That's using the dracut tool. Somehow, over 50Mbs is not anywhere close to 80Kbs, or maybe my calculator is broken. Your calculator is off by a power of 10. It is. Still, 5Mbs is a lot larger than 80Kbs. Thanks for the correction. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigelt wrote: * Micha?? Górny schrieb: Does working hard involve compiling even more packages statically? I guess, he means keeping udev in / ? Because adding 80 KiB of initramfs hurts so much? We should then put more work just to ensure that admin doesn't have to waste 15 minutes to recompile the kernel (if necessary), create an initramfs and add it to bootloader config? 80Kbs? You sure about that? I somehow failed to mention this before. I noticed it when I saw another reply to this post. Reality check: root@fireball / # ls -al /boot/initramfs-3.* -rw-r--r-- 1 root root 5444240 Jan 1 07:24 /boot/initramfs-3.1.5-gentoo.img -rw-r--r-- 1 root root 5515132 Jan 9 07:57 /boot/initramfs-3.2.0-r1.img root@fireball / # That's using the dracut tool. Somehow, over 50Mbs is not anywhere close to 80Kbs, or maybe my calculator is broken. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Alec Warner wrote: On Wed, Jan 11, 2012 at 9:01 AM, Michał Górny wrote: It is a hack. Your opinion is noted, but that doesn't make better or worse than other folks ideas. -A -- Best regards, Michał Górny I agree. It doesn't break things that was working either. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
