Re: [gentoo-dev] Last-rites: app-admin/lastpass-cli

2021-03-14 Thread Dale
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

2020-06-11 Thread Dale
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.

2020-05-26 Thread Dale
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 / ...)

2020-05-02 Thread Dale
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

2019-10-25 Thread Dale
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

2019-10-25 Thread Dale
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/*

2017-11-24 Thread Dale
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

2017-09-28 Thread Dale
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?

2017-05-12 Thread Dale
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

2017-02-27 Thread Dale
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)

2016-09-26 Thread Dale
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)

2016-09-26 Thread Dale
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

2016-06-08 Thread Dale
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

2016-05-23 Thread Dale
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

2016-05-23 Thread Dale
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

2016-02-09 Thread Dale
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

2016-02-08 Thread Dale
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

2015-12-19 Thread Dale
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

2015-11-03 Thread Dale
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

2015-11-02 Thread Dale
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

2015-11-02 Thread Dale
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

2015-11-02 Thread Dale
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

2015-11-02 Thread Dale
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

2015-11-02 Thread Dale
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

2015-11-02 Thread Dale
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

2015-11-01 Thread Dale
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)

2015-10-15 Thread Dale
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

2015-10-04 Thread Dale
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

2015-10-02 Thread Dale
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"

2015-09-11 Thread Dale
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

2015-09-08 Thread Dale
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

2015-09-07 Thread Dale
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

2015-09-06 Thread Dale
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

2015-08-15 Thread Dale
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

2015-08-03 Thread Dale
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

2015-08-03 Thread Dale
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

2015-07-08 Thread Dale
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

2015-05-17 Thread Dale
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

2014-07-21 Thread Dale
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

2014-06-04 Thread Dale
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?

2013-12-13 Thread Dale
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)

2013-11-04 Thread Dale
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)

2013-11-04 Thread Dale
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)

2013-11-04 Thread Dale
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

2013-08-16 Thread Dale
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

2013-08-16 Thread Dale
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

2013-07-25 Thread Dale
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

2013-05-30 Thread Dale
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

2013-03-23 Thread Dale
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)

2013-01-23 Thread Dale
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

2013-01-20 Thread Dale
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

2013-01-20 Thread Dale
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

2012-12-21 Thread Dale
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

2012-12-21 Thread Dale
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

2012-12-21 Thread Dale
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

2012-12-20 Thread Dale
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

2012-12-15 Thread Dale
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]

2012-12-01 Thread Dale
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]

2012-12-01 Thread Dale
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

2012-09-27 Thread Dale
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

2012-09-27 Thread Dale
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

2012-08-07 Thread Dale
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)

2012-07-24 Thread Dale
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)

2012-07-24 Thread Dale
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

2012-07-17 Thread Dale

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

2012-07-17 Thread Dale
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

2012-06-17 Thread Dale
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

2012-06-16 Thread Dale
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

2012-05-05 Thread Dale
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

2012-05-05 Thread Dale
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

2012-05-05 Thread Dale
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

2012-05-04 Thread Dale
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

2012-03-28 Thread Dale
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

2012-03-28 Thread Dale
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

2012-03-28 Thread Dale
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

2012-03-28 Thread Dale
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

2012-03-10 Thread Dale
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

2012-02-13 Thread Dale
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?

2012-02-10 Thread Dale
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

2012-01-21 Thread Dale
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

2012-01-21 Thread Dale
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

2012-01-21 Thread Dale
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

2012-01-21 Thread Dale
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

2012-01-18 Thread Dale

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

2012-01-17 Thread Dale

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

2012-01-17 Thread Dale

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

2012-01-17 Thread Dale

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

2012-01-11 Thread Dale

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

2012-01-11 Thread Dale

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

2012-01-10 Thread Dale

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

2012-01-10 Thread Dale

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

2012-01-10 Thread Dale

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

2012-01-10 Thread Dale

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

2012-01-04 Thread Dale

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

2012-01-01 Thread Dale

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

2012-01-01 Thread Dale

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

2012-01-01 Thread Dale

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




Re: [gentoo-dev] RFC: deprecate /usr/share/doc/$PF

2011-12-18 Thread Dale

Ulrich Mueller wrote:

On Sun, 18 Dec 2011, Alexandre Rostovtsev wrote:

Can we please avoid the bloat of another directory level here?
${CATEGORY}/${PN} will be even longer than ${PF} in most cases.

The problem is that ($PN, $CATEGORY) pairs are not unique. Think of
x11-terms/terminal:0 and gnustep-apps/terminal:0, or
app-misc/beagle:0 and sci-libs/beagle:0, or app-misc/nut:0 and
sys-power/nut:0. I could not think of any better solution than using
$CATEGORY/$PN-$SLOT.

Thinking about it a little more, I believe that ${CATEGORY} shouldn't
appear anywhere in the path of installed files, for the following
reasons:

1. Users may not know the category of a package, therefore it's not
obvious for them where to find its documentation. (Think of it from
the perspective of a user on a multiuser system, who didn't install
the packages on that system.) OTOH, the name of the package (PN) is
obvious in most cases, since it will coincide with the upstream
name.

2. It doesn't play well with bash completion. When searching for
documentation of a specific package (and only knowing PN), one can
currently type the pathname up to PN and press tab which will
complete PVR. With CATEGORY _before_ PN this would no longer work.

3. CATEGORY and SLOT are Gentoo specific, related to the way how we
organise our packages. Neither of them should appear in the
directory structure of installed packages. The problems related to
package and slot moves (where CATEGORY or SLOT change) also show
that something is wrong with the approach. (BTW, in the current
system, PR is also Gentoo specific. It doesn't suffer from problems
with package moves though.)


Do you have a better proposal that does not rely on $PVR?

Leave things as they are. It's not perfect, but IMHO your approach
would create at least as many problems as it would solve.
Alternatively, a minimal solution would be to drop only ${PR}, i.e.
install documentation under /usr/share/doc/${P}.

Ulrich




I like the logic in #1 as a user.  What if two packages have the same 
name but different categories tho?  It is rare but I do run into this 
from time to time.  I try to emerge something but am informed by emerge 
that I have to include the category for emerge to know exactly which 
package I want installed.


I do agree that docs are sometimes hard to find.  The only way I have 
any success is equery files package name then see where it put them or 
if there is none to find.


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] have portage be quiet by default

2011-11-14 Thread Dale

Zac Medico wrote:

On 11/13/2011 03:09 PM, Thomas Sachau wrote:

Zac Medico schrieb:

On 11/13/2011 07:49 AM, Thomas Sachau wrote:

Please give me a good reason, why i should by default do more things (adding 
quiet-build=n to the
default emerge opts or searching for and opening the build.log) and what i or 
others do get from
that. And less lines on the screen is no added value for me, it removes value.

Why should we expose new users to legacy defaults that are useless to
more than 99% users, when they would most likely prefer the
--quiet-build display?

Why should we change the default behaviour for existing users? Those, who dont 
want to see it,
probably already use --jobs or quiet-build=y. For the rest, they either dont 
know about those
options (which does not get better, if some default behaviour changes) or they 
dont want those
options (in which case you force them to change their configuration/scripts/way 
to do things).

When we change defaults, it affects everyone who hasn't yet overridden
the setting in EMERGE_DEFAULT_OPTS. That's just how it is.


Additionally, do you have any numbers about existing or new users and about the 
percentage, which
would like the build output to be quiet?

All I have is the feedback from this mailing list, an my own intuition.
My intuition says that --quiet-build is reasonable default that the
silent majority of people will welcome.



Here is some feedback then.  I liked it the way it was.  When a build 
fails, I do a one of install of that package and I like to see the 
output.  Why, because sometimes it gives me a hint as to why it failed 
or something I can google for.


This is a users point of view.  I expect things to remain the same 
unless that will break something.  I like emerge, or any program, to 
work like it always has, at least what the user sees, until the change 
is so drastic to compel a change a user does see.


So, the option to change the output that people expect to see is not 
anything that needs to be done.  It doesn't change what portage does 
under the hood and there is no real reason to change it.


On a side note.  I do wish things like this, added features to portage, 
could be announced on something like user-announce.  That would mean a 
addition mailing list but that could be read only except to devs.  When 
something is going to change, announce it there.  Maybe some thread on 
the forums for those who don't use mailing lists.  I have noticed that 
portage is a moving target.  Things are constantly being added and it is 
difficult to keep up at times.  This would certainly help.  The messages 
would be few but I think it would be awesome to have.  When something 
gets added, send out a announcement so people know to expect it and can 
decide if it is something they can use.


Hope you enjoy my feedback even tho it is different from what you 
expected.  I'm rare but not that rare.


Dale

:-)  :-)



Re: [gentoo-dev] Re: have portage be quiet by default

2011-11-14 Thread Dale

Zac Medico wrote:

On 11/13/2011 08:24 AM, Duncan wrote:

The previous defaults made perfect sense to me already.  Parallel emerge
jobs already puts portage in quiet mode, and that's what most people who
care (see my point above about whether this is the right distro choice or
not) should already be using.  That default makes sense, since otherwise
the output would be jumbled anyway.

1-at-a-time merge defaults are therefore where the question is.  Two
positions could be taken here.  If it is argued that those who care will
already be using parallel mode in most cases, and that those who care but
that can't be bothered to switch their defaults really should be
questioning whether gentoo is an appropriate choice in the first place,
then a noisy default for 1-at-a-time makes sense too, because the only
time most (who care) will see it is when they're actually troubleshooting
something and thus deliberately using 1-at-a-time mode, in which case the
higher level of detail by default for that mode makes the the most sense.

Ever since I added --jobs support, I've felt that suppression of build
output would be a better default for at least the following reasons:

1) I estimate that the flooding of the terminal with build output is
useless for more than 99% of users. Usually, there's too much
information scrolling by at too high of a rate for it to be
intelligible. Having this as the default behavior is ridiculous and
leads to jokes like apt-gentoo [1]. Generally, people who want to
analyze build output are best served by PORT_LOGDIR.


One key.  Scroll Lock.  You can look all you want then hit it again to 
let it carry on.  There is also ctrl Z as well.  I use that a good bit 
to see what is going on.  Just type in fg to carry on.


As for progress, genlop -c does that already.


2) With --quiet-build, the user is presented with a useful summary of
overall progress, along with current load average data. The output is
consistent regardless of whether or not the emerge --jobs option is used.

[1] http://chris-lamb.co.uk/2011/08/12/careful-what-you-wish-for/


Unless you are trying to compile one that failed earlier.  Then you 
don't want the default, you want to see what made it fail.  Then google 
is our friend again.


That said, GREAT work on portage.  :-D

Dale

:-)  :-)



  1   2   3   >