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-portage-dev] [PATCH] portage.output: Replace darkblue colors with teal
Michael Orlitzky wrote: > On Sat, 2021-12-04 at 10:47 +0100, Fabian Groffen wrote: >> Now, if you would make a supported claim that all terminals we install >> use a black background by default, your change becomes more valid. >> >> > For one, when you're working through the handbook to install Gentoo, > you're doing it on a black background. > > Or if you have any physical servers. The dark-blue-on-black is even > more fun to read from three feet away on the CRT monitor from 1995 in > the back of a poorly lit server room. > > > > As a user, I like the new color. I to use a black background and the dark blue is hard to see. I've also had to either copy and paste elsewhere or change the default color of Konsole. I might add, every console, the ctrl+alt+F1 console, that I have ever seen is also black. As a user, +1 for the change. If it is OK, +10. 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 <rdalek1...@gmail.com> 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] 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 <patr...@gentoo.org> 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 <keytoas...@gentoo.org> > 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 <rdalek1...@gmail.com> 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 1:08 AM, Dale <rdalek1...@gmail.com> 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
Ciaran McCreesh wrote: > On Mon, 2 Nov 2015 14:00:18 -0600 > Dale <rdalek1...@gmail.com> wrote: >> Rich Freeman wrote: >>> On Mon, Nov 2, 2015 at 1:08 AM, Dale <rdalek1...@gmail.com> 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
hasufell wrote: > On 11/02/2015 10:54 PM, Dale wrote: >> Ciaran McCreesh wrote: >>> On Mon, 2 Nov 2015 14:00:18 -0600 >>> Dale <rdalek1...@gmail.com> wrote: >>>> Rich Freeman wrote: >>>>> On Mon, Nov 2, 2015 at 1:08 AM, Dale <rdalek1...@gmail.com> 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
Matt Turner wrote: > On Mon, Nov 2, 2015 at 5:20 PM, Dale <rdalek1...@gmail.com> 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 <rdalek1...@gmail.com> wrote: >>>>>> Rich Freeman wrote: >>>>>>> On Mon, Nov 2, 2015 at 1:08 AM, Dale <rdalek1...@gmail.com> 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
Rich Freeman wrote: > On Mon, Nov 2, 2015 at 8:20 PM, Dale <rdalek1...@gmail.com> 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 <rdalek1...@gmail.com> 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 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 <vap...@gentoo.org> 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 <z...@gentoo.org> 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 <z...@gentoo.org> 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 <rdalek1...@gmail.com> 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] 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] 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] 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 m...@gentoo.org 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 robb...@gentoo.org 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 ssuomi...@gentoo.org 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 m...@gentoo.org 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)
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 alan.mckin...@gmail.com 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=2chap=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: 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 rdalek1...@gmail.com 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)
Tom Wijsman wrote: On Mon, 04 Nov 2013 14:02:28 -0600 Dale rdalek1...@gmail.com 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: [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] 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] 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.1r2=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 fe...@desaster-games.com 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
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: RFC: new qt category
Ben de Groot wrote: On 20 January 2013 21:35, Dale rdalek1...@gmail.com 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: Wordiness
Michael Mol wrote: On Fri, Dec 21, 2012 at 8:31 AM, Matt Turner matts...@gentoo.org 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] 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: 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] Moving our/portage stuff to var
Ciaran McCreesh wrote: On Thu, 20 Dec 2012 18:44:06 +0100 Ulrich Mueller u...@gentoo.org 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]
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] 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. mode=rant 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. /mode 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] 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] How to raise money for Gentoo
Alec Warner wrote: On Thu, Sep 27, 2012 at 4:11 PM, Dale rdalek1...@gmail.com 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] Questions about SystemD and OpenRC
Michał Górny wrote: On Tue, 7 Aug 2012 13:31:32 -0400 Michael Mol mike...@gmail.com wrote: On Tue, Aug 7, 2012 at 12:29 PM, Michał Górny mgo...@gentoo.org wrote: On Tue, 7 Aug 2012 11:33:59 -0400 Sylvain Alain d2racing...@gmail.com wrote: The KDE team seems to work on that too : http://lists.kde.org/?l=kde-core-develm=134052539215508w=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 7:07 AM, Fabian Groffen grob...@gentoo.org 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] 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 grob...@gentoo.org 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] 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] 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] 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
Jesus Rivero (Neurogeek) wrote: On May 5, 2012 3:14 PM, Markos Chandras hwoar...@gentoo.org 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 maksbo...@gentoo.org 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] 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
Ben wrote: On 6 May 2012 08:29, Dale rdalek1...@gmail.com 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] 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] 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 pa...@gentoo.org 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] 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] 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. Again agreed, But really, to some degree it's something that's only learned from experience. If anything, what I'd suggest for the installation manual partitioning section would be a variant on the programmer's dictum: Plan to throw one away, because you're either going to end up doing it anyway after you make your mistakes and figure out the way you /should/ have done it, or putting up with a sub-optimum setup if you don't throw one away, and planning for it from
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 something 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: newsitem: unmasking udev-181
Rich Freeman wrote: On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs willi...@gentoo.org 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 zmed...@gentoo.org wrote: On 02/10/2012 06:17 PM, Ryan Hill wrote: On Fri, 10 Feb 2012 10:50:39 -0800 Hilco Wijbenga hilco.wijbe...@gmail.com 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
Michał Górny wrote: On Wed, 18 Jan 2012 01:20:03 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org 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] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Sat, 21 Jan 2012 06:28:54 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Wed, 18 Jan 2012 01:20:03 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org 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 Sat, 21 Jan 2012 15:34:39 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Sat, 21 Jan 2012 06:28:54 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Wed, 18 Jan 2012 01:20:03 -0600 Dale rdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org 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
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] 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, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org 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
Mike Gilbert wrote: On Tue, Jan 17, 2012 at 10:38 PM, Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.dewrote: * Micha?? Górnymgo...@gentoo.orgschrieb: 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, 17 Jan 2012 21:38:26 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org 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
Michał Górny wrote: On Wed, 11 Jan 2012 10:34:34 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 16:40:01 -0600 Dalerdalek1...@gmail.com wrote: I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. The mess was created by people shouting 'hey, real men use separate /usr for no good reason! Be awesome like us'. I think it is more like people do that when they have a good reason to do so. I plan to put mine on /usr when I get the chance and know that this init crap isn't going to break my rig. It's not being awesome either. Remind me of a single good reason. Last time I heard those were mostly hacks and laziness. I already stated the reason. I'm going to put /usr on LVM. That is not only a good reason, it is a GREAT reason. It is a hack. How is putting /usr, /var, /home and such on LVM a hack? Your definition of hack must have some really low standards. Does installing Linux fall into your hack category to? 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órnymgo...@gentoo.org 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
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org 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? Took me days to get dracut to work. Where does 15 minutes come from? How much time does it take when the initramfs fails? I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. 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 12:56:11 -0600 Dalerdalek1...@gmail.com wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org 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? Took me days to get dracut to work. Where does 15 minutes come from? I just took the time I needed to write an initramfs from scratch and divided it by two, assuming using an already-made tool is simpler. Wish it was like that for me. I never got one made from scratch to work. How much time does it take when the initramfs fails? The same when rootfs fails? Only the fact that initramfs is less likely to break than rootfs, and you have a pretty good opportunity now to experiment with it while nothing on your system made it useless without one. Funny, I never had the rootfs fail before. I have had init thingys fail many many times. They lead to a reinstall since I had no idea how to fix it. I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. The mess was created by people shouting 'hey, real men use separate /usr for no good reason! Be awesome like us'. I think it is more like people do that when they have a good reason to do so. I plan to put mine on /usr when I get the chance and know that this init crap isn't going to break my rig. It's not being awesome 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
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Rich Freeman wrote: On Tue, Jan 10, 2012 at 1:56 PM, Dalerdalek1...@gmail.com wrote: Took me days to get dracut to work. Where does 15 minutes come from? How much time does it take when the initramfs fails? I've used dracut on a few VMs now and on my main Gentoo box. My experience has been that it didn't take long to figure out, and it is trivially easy to install. Now, whether it works is a separate issue. Most of the time it works just fine, and it is no harder to deploy than typing genkernel all. When it doesn't work then you're going to spend a whole lot more time trying to fix it - I'm still tweaking mine. Granted, its failure mode is only disastrous in an unattended system in my case since I can just type one line at the dash shell and exit and it boots fine. I just need to get unlazy and debug the script... Rich I finally got dracut to work, I think it is anyway. I asked on the user list but no one knows I guess since there are no replies. I tried genkernel when I first installed Gentoo. I found it MUCH easier to do my own kernel. Genkernel never built a bootable kernel for my rig. I don't recall the errors now but it didn't work and I tried many times. I still do my kernels by hand. The thing about me is that I left my previous distro because of the init thingy CONSTANTLY failing and rpm dependency issues. Now, here I am again. By the way, I didn't mess with the init thingy either. It broke all on its own. This makes me wonder if the dependency issues has gotten sorted out. My brothers Kubuntu seems to work fine. It just makes me wonder. 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
Hinnerk van Bruinehsen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.01.2012 19:56, Dale wrote: Michał Górny wrote: On Tue, 10 Jan 2012 19:14:52 +0100 Enrico Weigeltweig...@metux.de wrote: * Micha?? Górnymgo...@gentoo.org 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? Took me days to get dracut to work. Where does 15 minutes come from? How much time does it take when the initramfs fails? I keep hoping that all the smart people involved in this will see the mess it is creating. I'm not the sharpest tool in the shed but I'm sharp enough to see the mess this is going to create and I'm just a desktop user. I feel sorry for people with more complicated systems or remote ones. Dale :-) :-) If you have got it working once, it should take less than 15 minutes (I've made myself a bashscript with the exact dracut commandline parameters needed for my system). But I have to agree with you, that exotic setups (I have encypted root on my laptop) are very bad documented. If dracut shall become standard for Gentoo (alternative: genkernel can build an initramfs) someone will have to write an exact howto with the most important (or better all) commandline arguments and kernel commandline parameters. Hinnerk -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPDIzWAAoJEJwwOFaNFkYccIUH/2sPXpD/nOyrMZi34eUgV8qp NVa/JvVUEiSdxpETJoahwNTT1tOilxXA5ospLK3FShDyMqmngaFtTp8dqaiojOwg OOcNkmq8/W6GUVrRUOfBjM1LORVOcGkGWAQ2RNkah388M7HCXe98bgKSd7vLJtbd E5deIZ8ETLaJ2+tQh1L3Af6D7hUlZolbwwmUGl7b81o6O1YFjkvaZFiNBBoSQ8rD h+OXxnsXn72xFIqek/egpPkUqHDRhtO4hvo6fJR5JZGpF8r1HeS3y4Fa/jFPVrtV EUsdkCulW5ZDQt0pXbWDOugMhEFtkJ3NMlZKUiqdKYiiZmJcmp1Rgu0NQYlw0uY= =bupg -END PGP SIGNATURE- If I recall correctly, it took me at least three or four web sites and the man page to get dracut to work. This is something that needs to be worked on hugely before this goes to much farther. Gentoo doesn't need to lose its status on the docs. I tried to follow the Gentoo doc and it would not even boot. I tried everything I could find but it still didn't work. Out of date, maybe. I dunno. It just didn't work for me. Thing is, my current setup doesn't even need one. I plan to have a separate /usr on LVM as soon as I can get me one more large drive. I'll have to have one then. 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
Jeroen Roovers wrote: On Sun, 01 Jan 2012 16:49:42 -0500 Olivier Crêtetes...@gentoo.org wrote: That's why you have dracut to do it for you. Which is keyworded at this point. Stable users do what? It's keyworded for only two arches. And amd64 is one of them. I'd say it is a fairly popular arch too. ;-) 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
Sven Vermeulen wrote: But if people really want to focus on initramfs, I'd appreciate some documentation help on it. Not only on how to create one, but also why it is necessary, how to manage initramfs'es, the concepts underlying, etc. Wkr, Sven Vermeulen This is my issue as well. I tried to make a init* to deal with this and have yet to get one to work, not one single working boot up. I have tried different howtos and not one of them produced anything that works. I have not found a dracut howto that makes any sense either. Sorry but genkernel left a bad taste in my mouth ages ago. As bad as I hate to even use a init*, I hate even worse being told I have to have one and not being able to get one to work following the docs. There needs to be some really well tested docs for people to use before this kicks in. Now to go brush my teeth. :/ This init* thingy tastes really bad. 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
Rich Freeman wrote: On Sun, Jan 1, 2012 at 4:45 AM, Dalerdalek1...@gmail.com wrote: This is my issue as well. I tried to make a init* to deal with this and have yet to get one to work, not one single working boot up. I have tried different howtos and not one of them produced anything that works. I have not found a dracut howto that makes any sense either. Sorry but genkernel left a bad taste in my mouth ages ago. While I think that the direction we're moving in (/usr on root or use an initramfs) is inevitable, I do agree that it needs some improvement. I've gotten Dracut to work fine in VMs (even with fairly complex setups), but every time I try it on my server it doesn't set up the raid for some reason, and drops me to a dash shell. If I just run mdadm_auto at that point it takes about 15 seconds to find and setup my raid, and just typing exit boots the system just fine. I keep it as an option in grub so that whenever my raid device numbers get mixed up (seems to happen every other month for no apparent reason) I can boot the system, since dracut does use the mdadm.conf and UUIDs to put everything in the right place and find the right root (something you can't do without an initramfs). One of these days I'll figure out how to hack an mdadm_auto into the script as a last-ditch measure and then I'll just have to deal with a one-minute delay. For being the wave of the future it seems like the only documentation Dracut has is a single page website with a few paragraphs of info. I think the bottom line is that the future may look inevitable, but it isn't actually here yet. I advocate being ready for the future, but let's try not to force its arrival before everything is mature (though having it in portage as an option is completely in the spirit of Gentoo). Rich I installed dracut and it did something, although I'm not sure what yet. I googled until I think google should be tired of me to find docs to help. Getting it to run was on one page, then figuring out some options was on yet another page, then grub was on yet another. I don't know yet if some of these are outdated or anything so I don't know if it is going to work or just blow up something. Please, don't ask me what it did. I said I did it, I didn't say I understand it. If it is broken or breaks in the future, I'm screwed. (Sort of starting to wonder why I left Mandriva now. I could have swore I wanted to be rid of init* stuff and make my on freakin kernels. ) I might also add for those considering dracut being the official way, it is keyworded at this point. I would think someone needs to get this stable or whatever needs doing before telling folks to use this. It may work fine but if that is the case, then it needs to be unkeyworded. Spell check doesn't like our terms here. I think the future is actually taking several steps backward. That point has been discussed to death tho. I hope Sven has his thinking hat on. Maybe I can help some with the docs. If it works for me, it should work for most. 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
Olivier Crête wrote: On Sun, 2012-01-01 at 01:33 -0600, Matthew Thode wrote: On Sun, 01 Jan 2012 02:12:22 -0500 Olivier Crêtetes...@gentoo.org wrote: All of my systems currently have a seperate /usr that is mounted at boot. Unfortunately I do agree that this is not something that we can fight. This was brought up earlier and the only thing we can do for people like myself (who mount /usr at boot) is to create a simple initramfs that only has the purpose of mounting /usr at boot. The main thing I don't like about initramfs is that we have to regenerate it any time we update the packages that get included in it. That's why you have dracut to do it for you. Which is keyworded at this point. Stable users do what? 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
