[gentoo-dev] Conveying important upgrade messages to user community

[gentoo-dev] Conveying important upgrade messages to user community

[Daniel Drake]

Hi,

(sorry about last mail, hit send too early)

Recently we introduced an important behaviour change into the hotplug package. 
It used to autoload modules at bootup, now it doesn't - you have to install 
and use coldplug for that now.

We put ewarn messages in the ebuild to warn about this change. We put comments 
in the hotplug init.d script to warn about this change. I personally did not 
anticipate it affecting many people (if you are going to load a module on 
every boot up, why not just build it directly into the kernel).

However many users were affected by this. It seems people DO build kernel 
modules for their core hardware, I still don't understand why but thats beside 
the point here. Users missed the ewarn messages because hotplug was brought in 
the middle of updates of other packages (didn't help that there was a GNOME 
stable release around the same time). They did not see the comments in init.d 
because they used the "-5" option of etc-update to overwrite all files that 
they had never edited. We had bug reports and less-than-cooperative users 
flying in from many angles.

I then resorted to posting this with a kernel announcement on the homepage and 
getting a mention in the GWN. This was probably a bit late, hasn't seemed to 
help much but has rather got me more negative feedback from users who have 
gone for a complete reinstall (!? is there another misconception here? do we 
need to teach users about the "modprobe" command?) and from those who noticed 
I haven't taken up their (non-practical or impossible) suggestions to 
resolving this better.

My question is, how can we improve this situation? Portage really needs a 
decent messaging system to convey messages like this. It's in the works, 
right? It seems long overdue now...
Users suggested making the messages appear at the very end of the emerge 
process ("* X config files in /etc need updating" style), or an etc-update 
style system where you read messages and dismiss them once you've seen them, 
or a system which mails you those ewarn messages.
I really hope portage will be able to provide functionality something like 
this soon...

In the meantime, could we have handled this better with the resources 
available to us right now? How have other people coped with similar changes?

Thanks,
Daniel

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Francesco Riosa]

Daniel Drake wrote:

> Hi,
>
> (sorry about last mail, hit send too early)
>
> Recently we introduced an important behaviour change into the hotplug 
> package. It used to autoload modules at bootup, now it doesn't - you 
> have to install and use coldplug for that now.
>
> We put ewarn messages in the ebuild to warn about this change. We put 
> comments in the hotplug init.d script to warn about this change. I 
> personally did not anticipate it affecting many people (if you are 
> going to load a module on every boot up, why not just build it 
> directly into the kernel).
>
> However many users were affected by this. It seems people DO build 
> kernel modules for their core hardware, I still don't understand why 
> but thats beside the point here. Users missed the ewarn messages 
> because hotplug was brought in the middle of updates of other packages 
> (didn't help that there was a GNOME stable release around the same 
> time). They did not see the comments in init.d because they used the 
> "-5" option of etc-update to overwrite all files that they had never 
> edited. We had bug reports and less-than-cooperative users flying in 
> from many angles.
>
> I then resorted to posting this with a kernel announcement on the 
> homepage and getting a mention in the GWN. This was probably a bit 
> late, hasn't seemed to help much but has rather got me more negative 
> feedback from users who have gone for a complete reinstall (!? is 
> there another misconception here? do we need to teach users about the 
> "modprobe" command?) and from those who noticed I haven't taken up 
> their (non-practical or impossible) suggestions to resolving this better.
>
> My question is, how can we improve this situation? Portage really 
> needs a decent messaging system to convey messages like this. It's in 
> the works, right? It seems long overdue now...
> Users suggested making the messages appear at the very end of the 
> emerge process ("* X config files in /etc need updating" style), or an 
> etc-update style system where you read messages and dismiss them once 
> you've seen them, or a system which mails you those ewarn messages.
> I really hope portage will be able to provide functionality something 
> like this soon...
>
> In the meantime, could we have handled this better with the resources 
> available to us right now? How have other people coped with similar 
> changes?
>
> Thanks,
> Daniel
>
> -- 
> gentoo-dev@gentoo.org mailing list
>
>
SuSE distro's are use to send a mail to root, one per package.

imho you have pointed a ***very*** important point



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Tobias Klauser]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Tuesday 16 November 2004 14:52, Francesco Riosa wrote:

[TOFU]
>
> SuSE distro's are use to send a mail to root, one per package.

That would require to have an MTA installed by default (which, to my knowledge 
is not the case ATM). I think it's really ugly to have an MTA as a dependecy 
of portage. Besides that: How many users do know and care about mail 
in /var/mail/root?

Cheers, Tobias

-- 
Tobias Klauser <tklauser@nuerscht.ch>

GPG-Key 0x3A445520 http://tklauser.politux.org/tklauser.asc
    Fingerprint = 7474 D486 E4FC 5113 561D  B1E3 72BC 0E7E 3A44 5520

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Michiel de Bruijne]

On Tuesday 16 November 2004 16:13, Daniel Drake wrote:
> My question is, how can we improve this situation? Portage really needs a
> decent messaging system to convey messages like this. It's in the works,
> right? It seems long overdue now...

See http://bugs.gentoo.org/show_bug.cgi?id=11359 for a lot of discussion about 
this feature.

> In the meantime, could we have handled this better with the resources
> available to us right now? How have other people coped with similar
> changes?

I agree with you that the best solution is to show important messages after 
the installation. To answer your question about this specific case; I think 
timing was not very fortunately. Maybe you needed to wait a little bit longer 
between announcement and marking stable of the package.

But you must realise that there are users out there who know very little about 
Linux in general and Gentoo in specific that will start to flame if something 
goes wrong nomatter how well you prepare and announce changes. Also realise 
that these (sometimes very loud) users only represent a very small fraction 
of the userbase and the most of them really appreciate your work.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Tamas Sarga]

On Tue, 16 Nov 2004, Michiel de Bruijne wrote:

>
> On Tuesday 16 November 2004 16:13, Daniel Drake wrote:
> > My question is, how can we improve this situation? Portage really needs a
> > decent messaging system to convey messages like this. It's in the works,
> > right? It seems long overdue now...
>
> See http://bugs.gentoo.org/show_bug.cgi?id=11359 for a lot of discussion about
> this feature.
>
> > In the meantime, could we have handled this better with the resources
> > available to us right now? How have other people coped with similar
> > changes?
>
> I agree with you that the best solution is to show important messages after
> the installation. To answer your question about this specific case; I think
> timing was not very fortunately. Maybe you needed to wait a little bit longer
> between announcement and marking stable of the package.
>
> But you must realise that there are users out there who know very little about
> Linux in general and Gentoo in specific that will start to flame if something
> goes wrong nomatter how well you prepare and announce changes. Also realise
> that these (sometimes very loud) users only represent a very small fraction
> of the userbase and the most of them really appreciate your work.
>

Hi,
I'm not a Gentoo developer, so if you feel this message is just a noise,
I'm very sorry!
I know lot of users with very different habits and knowledge.
I think, that the knowledge is the bottle-neck at this case.
Lot of users don't know anything about PORTAGE_LOGDIR and the
portage-log filter scripts. I think the abilities of portage is enough,
but these aren't well-known enough. Maybe somebody (for example me)
should create an overview about PORTAGE_LOGDIR and portage-log filters.
It could go to the next GWN's tips&tricks article.

Any opinion?

Cheers,
Tamas Sarga
--
A day is 24 hours long.			Egy nap 24 órából áll.
A box of beer contains 24 bottles.	Egy tálcán 24 üveg sör van.
I don't believe in coincidence.		Nem hiszek a véletlen egybeesésekben.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

Hi,

On Tue, 2004-11-16 at 15:34 +0100, Tamas Sarga wrote:
> Lot of users don't know anything about PORTAGE_LOGDIR and the
> portage-log filter scripts. I think the abilities of portage is enough,
> but these aren't well-known enough. Maybe somebody (for example me)
> should create an overview about PORTAGE_LOGDIR and portage-log filters.
> It could go to the next GWN's tips&tricks article.

I think that would be prove very useful for most of our users.
Personally I would welcome such an entry for the GWN.

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Tue, 16 Nov 2004 15:40:07 +0100 Henrik Brix Andersen
<brix@gentoo.org> wrote:
| On Tue, 2004-11-16 at 15:34 +0100, Tamas Sarga wrote:
| > Lot of users don't know anything about PORTAGE_LOGDIR and the
| > portage-log filter scripts. I think the abilities of portage is
| > enough, but these aren't well-known enough. Maybe somebody (for
| > example me) should create an overview about PORTAGE_LOGDIR and
| > portage-log filters. It could go to the next GWN's tips&tricks
| > article.
| 
| I think that would be prove very useful for most of our users.
| Personally I would welcome such an entry for the GWN.

GWN and gentoo-announce would be a good idea. Right now gentoo-announce
is basically just used for GLSAs, it's not a general announcement kind
of thing at all.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On Tuesday 16 November 2004 16:17, Ciaran McCreesh wrote:
> GWN and gentoo-announce would be a good idea. Right now gentoo-announce
> is basically just used for GLSAs, it's not a general announcement kind
> of thing at all.

As long as the mail send to it is filtered some way I think we should start 
using gentoo-announce for these things. Similarly for an upgrade to gcc-3.4 
(if we ever will) as it will break seriously if you're not carefull.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

On Tue, 16 Nov 2004 22:06:39 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| On Tuesday 16 November 2004 16:17, Ciaran McCreesh wrote:
| > GWN and gentoo-announce would be a good idea. Right now
| > gentoo-announce is basically just used for GLSAs, it's not a general
| > announcement kind of thing at all.
| 
| As long as the mail send to it is filtered some way I think we should
| start using gentoo-announce for these things. Similarly for an upgrade
| to gcc-3.4 (if we ever will) as it will break seriously if you're not
| carefull.

Noooo, see, that one's an arch issue, and so it should go to the
gentoo-x86 mailing list that our x86 arch team set up.

Oh, wait, you mean x86 released without meeting all the officially
supported rules and didn't get moved into experimental, despite what was
decided at the manager's meeting? *sigh*

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

On Tuesday 16 November 2004 22:13, Ciaran McCreesh wrote:
> On Tue, 16 Nov 2004 22:06:39 +0100 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | On Tuesday 16 November 2004 16:17, Ciaran McCreesh wrote:
> | > GWN and gentoo-announce would be a good idea. Right now
> | > gentoo-announce is basically just used for GLSAs, it's not a
> | > general announcement kind of thing at all.
> |
> | As long as the mail send to it is filtered some way I think we should
> | start using gentoo-announce for these things. Similarly for an
> | upgrade to gcc-3.4 (if we ever will) as it will break seriously if
> | you're not carefull.
>
> Noooo, see, that one's an arch issue, and so it should go to the
> gentoo-x86 mailing list that our x86 arch team set up.
>
> Oh, wait, you mean x86 released without meeting all the officially
> supported rules and didn't get moved into experimental, despite what
> was decided at the manager's meeting? *sigh*

It's like the European Calculation Office for the (I believe) 11th year in 
a row not signing of the budget proposed by the European comittee, and 
the parliament still giving the Ok. The parliament could not give the OK 
and start a lot of mayhem, but what would it serve? It's also not the 
current comittee that can be blamed (they started two weeks ago).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Tue, 2004-11-16 at 21:13 +0000, Ciaran McCreesh wrote:
> Oh, wait, you mean x86 released without meeting all the officially
> supported rules and didn't get moved into experimental, despite what was
> decided at the manager's meeting? *sigh*

WTF are you going on about now?  Do you even know what you are talking
about or are you just spreading more x86 hate *again*?

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Wed, 17 Nov 2004 09:21:43 -0500 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| On Tue, 2004-11-16 at 21:13 +0000, Ciaran McCreesh wrote:
| > Oh, wait, you mean x86 released without meeting all the officially
| > supported rules and didn't get moved into experimental, despite what
| > was decided at the manager's meeting? *sigh*
| 
| WTF are you going on about now?  Do you even know what you are talking
| about or are you just spreading more x86 hate *again*?

I suggest you take a look through the managers' meeting logs regarding
the decided upon set of rules for an arch releasing into official rather
than experimental. Then, once you've read them and understand the
requirements, come back and explain why x86 ended up being exempt,
despite the whole "x86 will not be exempt" thing.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

On Wed, 2004-11-17 at 16:29 +0000, Ciaran McCreesh wrote:
> I suggest you take a look through the managers' meeting logs regarding
> the decided upon set of rules for an arch releasing into official rather
> than experimental. Then, once you've read them and understand the
> requirements, come back and explain why x86 ended up being exempt,
> despite the whole "x86 will not be exempt" thing.

How about you enlighten me, or better yet, point me to where I can find
these precious logs.  I don't have copies of them, nor would I know
which manager's meeting yo are referring to precisely.

I've got an even better idea.

How about explaining why if there some some major decision made that
would affect the release, that there was no notification of it other
than having to weed through the logs from the manager's meeting?

Perhaps that level of professional courtesy is a bit much to ask.  After
all, I can't think of a single reason why the release team should be
informed of changes made to the release process.  If this information
was disseminated to the release team, then it never made it to me, and
seeing as how I am the operational manager and acting strategic manager
in zhen's absence, I would think I would be the *first* person that
should have been contacted in such a situation.

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

On Wed, 17 Nov 2004 11:46:50 -0500 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| On Wed, 2004-11-17 at 16:29 +0000, Ciaran McCreesh wrote:
| > I suggest you take a look through the managers' meeting logs
| > regarding the decided upon set of rules for an arch releasing into
| > official rather than experimental. Then, once you've read them and
| > understand the requirements, come back and explain why x86 ended up
| > being exempt, despite the whole "x86 will not be exempt" thing.
| 
| How about you enlighten me, or better yet, point me to where I can
| find these precious logs.  I don't have copies of them, nor would I
| know which manager's meeting yo are referring to precisely.

The meeting in question was on 25 Oct 2004. Logs may or may not have
been posted to -core at some point.

| I've got an even better idea.
| 
| How about explaining why if there some some major decision made that
| would affect the release, that there was no notification of it other
| than having to weed through the logs from the manager's meeting?
|
| Perhaps that level of professional courtesy is a bit much to ask. 
| After all, I can't think of a single reason why the release team
| should be informed of changes made to the release process.  If this
| information was disseminated to the release team, then it never made
| it to me, and seeing as how I am the operational manager and acting
| strategic manager in zhen's absence, I would think I would be the
| *first* person that should have been contacted in such a situation.

*shrug* Don't ask me, that's a manager thing. If you're acting in zhen's
place as manager, I'd say that this would be one of *your* jobs.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

On Wed, 2004-11-17 at 16:57 +0000, Ciaran McCreesh wrote:
> The meeting in question was on 25 Oct 2004. Logs may or may not have
> been posted to -core at some point.

I'll look to see if I can find any logs.

Anyone have them they can send me?

> *shrug* Don't ask me, that's a manager thing. If you're acting in zhen's
> place as manager, I'd say that this would be one of *your* jobs.

I'm not filling in for him in his voting, etc.  In fact, you'll notice
that the last meeting he voted on one of the GLEP issues via email, so
he is still active in that regard.  I am only acting on his behalf
within the realm of releng.

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Wed, 2004-11-17 at 12:02 -0500, Chris Gianelloni wrote:

> I'm not filling in for him in his voting, etc.  In fact, you'll notice
> that the last meeting he voted on one of the GLEP issues via email, so
> he is still active in that regard.  I am only acting on his behalf
> within the realm of releng.
> 

I am still here in an administrative capacity - I just don't have the
time right now to do "real" dev work. Chris is managing all of that
quite well right now ;) (thank $DEITY!)

Cheers,
//John


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Tamas Sarga]

On Tue, 16 Nov 2004, Henrik Brix Andersen wrote:

>
> Hi,
>
> On Tue, 2004-11-16 at 15:34 +0100, Tamas Sarga wrote:
> > Lot of users don't know anything about PORTAGE_LOGDIR and the
> > portage-log filter scripts. I think the abilities of portage is enough,
> > but these aren't well-known enough. Maybe somebody (for example me)
> > should create an overview about PORTAGE_LOGDIR and portage-log filters.
> > It could go to the next GWN's tips&tricks article.
>
> I think that would be prove very useful for most of our users.
> Personally I would welcome such an entry for the GWN.
>
> Sincerely,
> Brix
> --
> Henrik Brix Andersen <brix@gentoo.org>
> Gentoo Linux
>

Hi,
Some people said, it would be good and noone said it would be trash, so
I'll do it ;)
Once time, when GWN tips&tricks part asked for articles, I wrote a
letter to gwn-feedback@gentoo.org, but I didn't get any reply. This is
the good address, if I have questions about articles?
I will ask these questions here too, maybe someone can answer me.
What format is the most convenience to the GWN guys? Should I write it
as plain text, or simple html, or should I use the tags, used in GWN?
When and where should I post it to go this to the next GWN?

TIA.
Cheers,
Tamas Sarga
--
A day is 24 hours long.			Egy nap 24 órából áll.
A box of beer contains 24 bottles.	Egy tálcán 24 üveg sör van.
I don't believe in coincidence.		Nem hiszek a véletlen egybeesésekben.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Douglas Pollock]

On Tuesday November 16 2004 10:13 am, Daniel Drake wrote:
> We put ewarn messages in the ebuild to warn about this change. We put
> comments in the hotplug init.d script to warn about this change. I
> personally did not anticipate it affecting many people (if you are going to
> load a module on every boot up, why not just build it directly into the
> kernel).

One possibility is that the module does not exist in the kernel driver tree 
(third-party).  Another possibility is that it is a driver for a pluggable 
device.  If the device is not plugged in, then there is no need for the 
module to be loaded.  A third possibility is that the driver is buggy, and 
that -- in the event of a problem -- reloading the module can sometimes 
correct problems.



cheers,
d.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Tamas Sarga]

On Tue, 16 Nov 2004, Douglas Pollock wrote:

>
> On Tuesday November 16 2004 10:13 am, Daniel Drake wrote:
> > We put ewarn messages in the ebuild to warn about this change. We put
> > comments in the hotplug init.d script to warn about this change. I
> > personally did not anticipate it affecting many people (if you are going to
> > load a module on every boot up, why not just build it directly into the
> > kernel).
>
> One possibility is that the module does not exist in the kernel driver tree
> (third-party).  Another possibility is that it is a driver for a pluggable
> device.  If the device is not plugged in, then there is no need for the
> module to be loaded.  A third possibility is that the driver is buggy, and
> that -- in the event of a problem -- reloading the module can sometimes
> correct problems.
>
>
>
> cheers,
> d.
>

Hi,
2nd possibility doesn't count at this case. This function will work with
the new hotplug, only the startup won't. Hotplug will listen for
*plug-in* events, and load approproate moduls, but when a device is
attached to your computer when you boot, there won't be *plug-in* event.
The main advantage of this that the boot procedure will be shorter,
'cause hotplug won't search for devices on all port/bus/etc.

TIA.
Cheers,
Tamas Sarga
--
A day is 24 hours long.			Egy nap 24 órából áll.
A box of beer contains 24 bottles.	Egy tálcán 24 üveg sör van.
I don't believe in coincidence.		Nem hiszek a véletlen egybeesésekben.

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Conveying important upgrade messages to user community

[Duncan]

Tamas Sarga posted <Pine.LNX.4.58.0411161734520.18945@work.hu>, excerpted
below,  on Tue, 16 Nov 2004 17:42:17 +0100:


> On Tue, 16 Nov 2004, Douglas Pollock wrote:
> 
> 
>> On Tuesday November 16 2004 10:13 am, Daniel Drake wrote:
>> > I personally did not anticipate it affecting many people (if you are
>> > going to load a module on every boot up, why not just build it
>> > directly into the kernel).
>>
>> Another possibility is that it is a driver for a pluggable device.  If
>> the device is not plugged in, then there is no need for the module to
>> be loaded.
>>
> [That] possibility [doesn't] count at this case. This function will work
> with the new hotplug, only the startup won't. Hotplug will listen for
> *plug-in* events, and load approproate moduls, but when a device is
> attached to your computer when you boot, there won't be *plug-in* event.
> The main advantage of this that the boot procedure will be shorter,
> 'cause hotplug won't search for devices on all port/bus/etc.

I appreciate the distinction between hotplug/coldplug/unplugged that I
believe you are trying to make, but the possibility does indeed still
count.

What happens if a situationally critical pluggable device is plugged in at
boot?  I don't have a laptop so this particular usual example doesn't
affect me personally, but I understand it's a big deal for a significant
segment of the user base.  Some laptop users may use pluggable NICs (wired
or wireless) and expect the machine to boot to network if they are in at
boot (coldplugged), yet want the flexibility of booting no-net if it's not
plugged at boot.  That requires modules and a "coldplug" solution, or it
won't support either the unplugged at boot option (if the module is
built-in or loaded unconditionally using modules.autoload) or the plugged
at boot (coldplug) option (if it's loaded only with hotplug, no coldplug
script existing).


Personally, I prefer as small a "core" kernel as possible, with only
keyboard/input and my IDE and fs modules being built-in, to avoid initrd,
and everything else possible being modularized, including rtc and a few
other modules I load using modules.autoload and never unload.  Other
modules (alsa and sound hardware, mainly) get loaded at boot either by
coldplug or by autoload, but I like the flexibility of being able to
reload them or simply unload them if need be.

That's one of the good things about Linux and open source in general -- it
maintains far more admin level choice than typical commercial products, so
those that want it all built-in can have it that way, while those that
like slimmed down systems or load all the modules at boot but like the
flexibility can have it that way as well.  Typical commercial products
choose one or the other for supportability reasons, regardless of the
needs or desires of an individual installation/admin.

However, I suppose this is getting off topic for the thread..

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

On Tue, 2004-11-16 at 20:54 -0700, Duncan wrote:
> I appreciate the distinction between hotplug/coldplug/unplugged that I
> believe you are trying to make, but the possibility does indeed still
> count.

Actually, it does not.  I will explain below where it fits best.

> What happens if a situationally critical pluggable device is plugged in at
> boot?  I don't have a laptop so this particular usual example doesn't
> affect me personally, but I understand it's a big deal for a significant
> segment of the user base.  Some laptop users may use pluggable NICs (wired
> or wireless) and expect the machine to boot to network if they are in at
> boot (coldplugged), yet want the flexibility of booting no-net if it's not
> plugged at boot.  That requires modules and a "coldplug" solution, or it
> won't support either the unplugged at boot option (if the module is
> built-in or loaded unconditionally using modules.autoload) or the plugged
> at boot (coldplug) option (if it's loaded only with hotplug, no coldplug
> script existing).

Adding the module to modules.autoload does not mean it will always load.
It means it will always *try* to load.  There is an important
distinction between the two.

> Personally, I prefer as small a "core" kernel as possible, with only
> keyboard/input and my IDE and fs modules being built-in, to avoid initrd,
> and everything else possible being modularized, including rtc and a few
> other modules I load using modules.autoload and never unload.  Other
> modules (alsa and sound hardware, mainly) get loaded at boot either by
> coldplug or by autoload, but I like the flexibility of being able to
> reload them or simply unload them if need be.

You still haven't given any argument for why "coldplug" is necessary,
since you mention that you could easily use modules.autoload to do this.

> That's one of the good things about Linux and open source in general -- it
> maintains far more admin level choice than typical commercial products, so
> those that want it all built-in can have it that way, while those that
> like slimmed down systems or load all the modules at boot but like the
> flexibility can have it that way as well.  Typical commercial products
> choose one or the other for supportability reasons, regardless of the
> needs or desires of an individual installation/admin.

I totally agree.

> However, I suppose this is getting off topic for the thread..

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Conveying important upgrade messages to user community

[Greg KH]

On Wed, Nov 17, 2004 at 09:41:07AM -0500, Chris Gianelloni wrote:
> 
> Adding the module to modules.autoload does not mean it will always load.
> It means it will always *try* to load.  There is an important
> distinction between the two.

_very_ few modules in 2.6 refuse to load anymore.  Almost all of them
will now load, if you have the hardware for them or not.

Yes, there are still exceptions, but those are exceptions, not the rule,
and are slowly being fixed to not do this.

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Wed, 2004-11-17 at 09:35 -0800, Greg KH wrote:
> _very_ few modules in 2.6 refuse to load anymore.  Almost all of them
> will now load, if you have the hardware for them or not.
> 
> Yes, there are still exceptions, but those are exceptions, not the rule,
> and are slowly being fixed to not do this.

Will the already loaded modules detect a hotplugged device and
initialize it when it is inserted?

If so, then there would be zero harm in loading modules which you do not
*always* need on a machine, such as a USB NIC, as mentioned in this
thread.

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Conveying important upgrade messages to user community

[Greg KH]

On Wed, Nov 17, 2004 at 01:20:51PM -0500, Chris Gianelloni wrote:
> On Wed, 2004-11-17 at 09:35 -0800, Greg KH wrote:
> > _very_ few modules in 2.6 refuse to load anymore.  Almost all of them
> > will now load, if you have the hardware for them or not.
> > 
> > Yes, there are still exceptions, but those are exceptions, not the rule,
> > and are slowly being fixed to not do this.
> 
> Will the already loaded modules detect a hotplugged device and
> initialize it when it is inserted?

Yes.  That is why they always load, for this very reason.  And for the
fact that after a driver is loaded, you can always give it new device
ids through sysfs to have it bind to other, already present devices.

> If so, then there would be zero harm in loading modules which you do not
> *always* need on a machine, such as a USB NIC, as mentioned in this
> thread.

Exactly.  With the exception of additional memory being used, but hey,
memory is cheap these days!  :)

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Conveying important upgrade messages to user community

[Duncan]

Greg KH posted <20041117183350.GB28821@kroah.com>, excerpted below,  on
Wed, 17 Nov 2004 10:33:50 -0800:

>> If so, then there would be zero harm in loading modules which you do not
>> *always* need on a machine, such as a USB NIC, as mentioned in this
>> thread.
> 
> Exactly.  With the exception of additional memory being used, but hey,
> memory is cheap these days!  :)

That's one of the things I was getting at -- the additional LOCKED kernel
memory required by having a module built-in or auto-loaded.  Memory may be
cheap, but it's not FREE (OK, I see that smiley, but still don't know
whether the above is sarcastic or whether the smiley just means keep it
civil), and LOCKED memory is locked memory, that can't be swapped out for
something that might be more immediately useful (even if swap is enabled).

Additionally, anything loaded when it's not needed only means more
complexity and bloat, and more code that can cause a bug or be exploitable
in some way or another.

If it's a kernel module, there really IS reason to not have it loaded
unless it's going to be used.  Whether the reasons justify the hassle
involved is up to the individual site admins.  (Hmm.. must be that smiley
means sarcastic, given the position of the poster re static /dev bloat. <g>)

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[M. Edward Borasky]

On Tue, 2004-11-16 at 15:13 +0000, Daniel Drake wrote:

[hotplug snafu snipped]

Well ... I suspect a fair number of Gentoo users do

emerge sync
emerge -puvD world
emerge -uD world
etc-update

every day more or less automatically. I tend to be a little more
cautious than that, but I missed the hotplug warnings and had to figure
everything out by myself. At that point, the word "coldplug" flashed by
my subliminal vision :). So I must have seen the warning.

How about this:

Whenever you do "emerge sync", you get a list of "release notes" for
everything that has changed since your last sync. I know Portage is
smart enough to do this sort of thing, because it told me I had to
update my /etc/make.profile last night, and it tells me when I need to
update Portage. While you're at it, a list of new packages would be
nice.

I used to do the following:

emerge sync
eupdatedb
mv packages.txt old-packages.txt
esearch -Fn ^ > packages.txt
diff old-packages.txt packages.txt > packages.diff





--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Simon Stelling]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

Hi

M. Edward Borasky wrote:

> Whenever you do "emerge sync", you get a list of "release notes" for
> everything that has changed since your last sync. I know Portage is
> smart enough to do this sort of thing, because it told me I had to
> update my /etc/make.profile last night, and it tells me when I need to
> update Portage. While you're at it, a list of new packages would be
> nice.

I think this is rather a bad solution, because...:

1. to much noise
there are about 10'000 packages in portage, i have installed ~500 of
them. i really don't care about release notes for foo/bar if it isn't in
my system

2. automatics
probably most gentoo-users do their emerge sync with a cron-job or
something similiar, because there is really no need to view the output
of an emerge sync. so this wouldn't help at all

3. emerge sync != emerge package
i am one of these who do their emerge sync at lunch time and then update
the system in the evening, when i have more time.

beside of that, there are also users with limited internet access and
those probably do a emerge sync only if there's a important security fix
in a new version. so what if they installed foo-bar-2.4, a month later
2.6 became stable and in 2.8 there's a important security fix. the
upgrade from 2.4 to 2.6 directly and they wouldn't see the "release
notes" and blame us again ;)

your proposal would work great if every user would do a manual emerge
sync && emerge -uD world every day, but that's not the case.

blubb


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

On Tue, 2004-11-16 at 07:37 -0800, M. Edward Borasky wrote:
> Well ... I suspect a fair number of Gentoo users do
> 
> emerge sync
> emerge -puvD world
> emerge -uD world
> etc-update
> 
> every day more or less automatically. I tend to be a little more
> cautious than that, but I missed the hotplug warnings and had to figure
> everything out by myself. At that point, the word "coldplug" flashed by
> my subliminal vision :). So I must have seen the warning.

You are entirely right about this and it sure would be nice to get users
out of this habit.  Then again, most people come to Gentoo because they
think there really is a dramatic difference between gaim 1.0.2 and gaim
1.0.3 and waiting an extra 3 hours to have the latest and greatest will
simply make them lose all their 'leet points among the other forums
posters.

/me ducks

All kidding aside, a better method for getting messages across
definitely needs to be worked on, but at the same time, how many of you
don't know that we put messages in the ebuilds that you should follow?
How many of you simply ignore them anyway and do an "emerge -uD world"
blindly and don't pay any attention to the nice messages we worked so
hard to put into the ebuilds?  I'm not trying to lay blame on you,
personally, I am just making an observation.

To be honest, the hotplug/coldplug thing caught me off-guard myself when
I first upgraded the hotplug package, simply because I didn't follow my
own advice.  However, I said to myself "Hrrmn... It seems hotplug is
broken.  Perhaps I should read the ChangeLog and see what it says
there?" and all was right in the universe again.

Unfortunately, there really is only so much hand-holding that we can
accomplish as developers and still have time to actually *work* on the
distribution.

> How about this:
> 
> Whenever you do "emerge sync", you get a list of "release notes" for
> everything that has changed since your last sync. I know Portage is
> smart enough to do this sort of thing, because it told me I had to
> update my /etc/make.profile last night, and it tells me when I need to
> update Portage. While you're at it, a list of new packages would be
> nice.

Ehh... that's *way* too much information to present.  I definitely don't
want to see a bunch of Gnome/KDE garbage every time I sync if I only run
fluxbox or windowmaker.

I could see an advantage in having a list of new packages, but it
*definitely* should not be turned on by default.

Wouldn't it be much nicer if users would do something like emerge -vuDpl
world instead and actually get the ChangeLog entries?

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Alexander Gretencord]

On Tuesday 16 November 2004 17:47, Chris Gianelloni wrote:
> All kidding aside, a better method for getting messages across
> definitely needs to be worked on

There already is a proposal, just see Message-Id: 
<200411161508.13153.m.debruijne@hccnet.nl> who pointed this out.

> but at the same time, how many of you don't know that we put messages in the
> ebuilds that you should follow?

Many probably don't want to look at them inside the ebuild, because there 
should be a mechanism to show important information when doing an "emerge 
world", else emerge world has to be removed.

> How many of you simply ignore them anyway and do an "emerge -uD world"
> blindly and don't pay any attention to the nice messages we worked so
> hard to put into the ebuilds?

Many, me included, because I simply can't be bothered to look at the output 
all the time, waiting for the X seconds that I have time to read a msg. I 
start a screen session on the server, look at "emerge world -vp", decide 
which packages to really upgrade, start a merge for them and close my 
terminal. If there is important information, there has to be a way for emerge 
to tell me, without me, waiting for 20 ebuilds to run by, while I stare at 
the screen! And this mechanism should not be "have a logfile somewhere so I 
can read it if I know about it", I at least want to have a message like 
"important information about the last merged ebuilds is available in file 
XXX, have a look at it" beneath my merge. On the other hand, if this is 
possible you can just as easily put the information itself on screen (while 
still saving it to a file, for the case when the screen buffer was too small 
to capture everything).

> However, I said to myself "Hrrmn... It seems hotplug is broken.  Perhaps I
> should read the ChangeLog and see what it says there?" and all was right in
> the universe again. 

Thats what I would do too, however, this is not the right solution to the 
problem from a users/admin perspective. The solution is to give the 
user/admin the tools to be notified of important changes automatically. In a 
way that makes sure that you are really able to view the information.

> Unfortunately, there really is only so much hand-holding that we can
> accomplish as developers and still have time to actually *work* on the
> distribution.

Have a look at the bugreport mentioned in the message I refer to earlier.


Alex

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 4378 bytes --]

On Tue, 2004-11-16 at 18:18 +0100, Alexander Gretencord wrote:
> > but at the same time, how many of you don't know that we put messages in the
> > ebuilds that you should follow?
> 
> Many probably don't want to look at them inside the ebuild, because there 
> should be a mechanism to show important information when doing an "emerge 
> world", else emerge world has to be removed.

I meant the nice little einfo, ewarn, and error stuff that portage spits
out that we insert into the ebuilds.  Nobody expects you to read the
ebuild itself.

> > How many of you simply ignore them anyway and do an "emerge -uD world"
> > blindly and don't pay any attention to the nice messages we worked so
> > hard to put into the ebuilds?
> 
> Many, me included, because I simply can't be bothered to look at the output 
> all the time, waiting for the X seconds that I have time to read a msg. I 
> start a screen session on the server, look at "emerge world -vp", decide 
> which packages to really upgrade, start a merge for them and close my 
> terminal. If there is important information, there has to be a way for emerge 
> to tell me, without me, waiting for 20 ebuilds to run by, while I stare at 
> the screen! And this mechanism should not be "have a logfile somewhere so I 
> can read it if I know about it", I at least want to have a message like 
> "important information about the last merged ebuilds is available in file 
> XXX, have a look at it" beneath my merge. On the other hand, if this is 
> possible you can just as easily put the information itself on screen (while 
> still saving it to a file, for the case when the screen buffer was too small 
> to capture everything).

You "simply can't be bothered" so that means we should all jump to not
only help, but encourage your laziness and apathy?

While I understand everyone's need to have their hand held every second
of the day by the whole of Gentoo, it really is not *our* fault when
*you* do actions that prevent you from reading the messages that we do
give you.

> > However, I said to myself "Hrrmn... It seems hotplug is broken.  Perhaps I
> > should read the ChangeLog and see what it says there?" and all was right in
> > the universe again. 
> 
> Thats what I would do too, however, this is not the right solution to the 
> problem from a users/admin perspective. The solution is to give the 
> user/admin the tools to be notified of important changes automatically. In a 
> way that makes sure that you are really able to view the information.

You mean like piping the output of emerge to mail or sendmail?  That
seems easy enough... or how about redirecting the output to a file?  I
mean, surely that is so hard to do that we need to force this action
upon everyone, right?

My entire point here is that no matter what we do, someone will come up
and complain that it doesn't do what they want it to do.  I have a
simple solution for this.  Do it how you want... you don't need us to do
it for you.

If you are blindly upgrading packages *knowing* that there could be
changes in those packages that would affect you and you do nothing to
even verify that nothing will adversely affect your setup, then no
amount of hand-holding will help you.  I mean that the people that
complain about their systems being broken because they didn't follow the
instructions that we have laid out for them are a vocal minority.  When
changes like this happen, there is usually *very* little repercussions
and almost no bug reports.

Now, with that being said, I will *gladly* add this support to portage
just as soon as somebody decides to start paying me a salary equivalent
to my current one so I can hack on Gentoo all day long just to add a
bunch of little "hold my hand and wipe my ass for me" features rather
than working to add support for new devices and applications.

> > Unfortunately, there really is only so much hand-holding that we can
> > accomplish as developers and still have time to actually *work* on the
> > distribution.
> 
> Have a look at the bugreport mentioned in the message I refer to earlier.

No thanks... I'll leave that up to the portage team and get back to
working on things that I find interesting.

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Conveying important upgrade messages to user community

[Alexander Skwar]

· Chris Gianelloni wrote:

> I meant the nice little einfo, ewarn, and error stuff that portage spits
> out that we insert into the ebuilds.

Which are totally covered by all the other output flying by during a 
normal emerge.

> While I understand everyone's need to have their hand held every second
> of the day by the whole of Gentoo, it really is not *our* fault when
> *you* do actions that prevent you from reading the messages that we do
> give you.

Now, please come on. Do you actually expect anyone to stare at 
at the compilation output for many hourse, just to catch the
message that might be in the output?

Alexander Skwar
-- 
Beggar to well-dressed businessman:
??\x01 "Could you spare $20.95 for a fifth of Chivas?"
________________________________________________________________________



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Conveying important upgrade messages to user community

[Greg KH]

On Tue, Nov 16, 2004 at 08:01:45PM +0100, Alexander Skwar wrote:
> Now, please come on. Do you actually expect anyone to stare at 
> at the compilation output for many hourse, just to catch the
> message that might be in the output?

In this specific case, there were no compile messages output, as the
files are all in bash.

And I agree with Chris, I warned the users in the ebuild, and if they
didn't see it, no matter how many blinking lights, and other bright
shiny ways of reporting the message, people would have missed it.

And in the end, everyone who did stumble accross the issue, learned a
bit more about how the kernel, modules, and userspace interacts and came
away with more understanding.  Which is always a good thing.

Just wait till we make the kernel automatically upgrade from 2.4 to 2.6
:)

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On Tue, 2004-11-16 at 20:01 +0100, Alexander Skwar wrote:
> > I meant the nice little einfo, ewarn, and error stuff that portage spits
> > out that we insert into the ebuilds.
> 
> Which are totally covered by all the other output flying by during a 
> normal emerge.

emerge -q definitely helps, but setting "quiet" should make emerge
*much* more quiet.  

> > While I understand everyone's need to have their hand held every second
> > of the day by the whole of Gentoo, it really is not *our* fault when
> > *you* do actions that prevent you from reading the messages that we do
> > give you.
> 
> Now, please come on. Do you actually expect anyone to stare at 
> at the compilation output for many hourse, just to catch the
> message that might be in the output?

No, but I expect them to have enough sense to look for messages,
especially *knowing* that we give them, at least until a better solution
can be incorporated into portage.  Whining about it won't bring about
change faster and really doesn't help anyone.  If you want to help, put
your money where your mouth is and start submitting patches.  Adding
more useless chatter about the same topics over and over and over gets
really old and gets us all nowhere.

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Alexander Gretencord]

On Tuesday 16 November 2004 19:52, Chris Gianelloni wrote:
> I meant the nice little einfo, ewarn, and error stuff that portage spits
> out that we insert into the ebuilds.  Nobody expects you to read the
> ebuild itself.

As already said: as it stands now, it is easier for me to just look at the 
ebuild itself, than at the ewarn/eerror/einfo stuff, except for the last 
merged build.

> You "simply can't be bothered" so that means we should all jump to not
> only help, but encourage your laziness and apathy?

No.

> While I understand everyone's need to have their hand held every second
> of the day by the whole of Gentoo

That sadly seems to be the attitude of many developers, although most people, 
including me, don't want their hands held.

> it really is not *our* fault when *you* do actions that prevent you from
> reading the messages that we do give you.

Well how about seeing it this way:

It really is not *our* fault, when *you* create a system where we have to 
stare at the screen for a long time to read messages given to us by you.

> You mean like piping the output of emerge to mail or sendmail?

No, I only need the ewarn/einfo/eerror messages, not all the output. Think of 
all the output for an X build ...

> or how about redirecting the output to a file?

Same here, All I'm interested in are the messages, not the compilation stuff. 
That would only be necessary if a build fails.

> I mean, surely that is so hard to do that we need to force this action upon
> everyone, right?

As already said, just presenting all ewarn/einfo/eerror messages at the end of 
a build would suffice, piping that to a file could very well be optional.

> I have a simple solution for this.  Do it how you want... you don't need us
> to do it for you.

As said, have a look at the bug mentioned in the other msg, someone did it, 
just no gentoo developer seems to want to integrate the functionality that 
the community is ready to provide.

> If you are blindly upgrading packages *knowing* that there could be
> changes in those packages that would affect you and you do nothing to
> even verify that nothing will adversely affect your setup, then no
> amount of hand-holding will help you.

I don't do that. I do read the ebuilds to see if there are ewarns in 
there/save the output to scan that file for ewarns. The whole matter is just 
about how reading the messages can be made easier. Software is here to help 
us do our jobs, not to make it harder. And for a great distribution like 
gentoo, why not integrate such a feature into the mainline portage instead of 
having everyone that wants it, patch their portage with each new version?

> Now, with that being said, I will *gladly* add this support to portage
> just as soon as somebody decides to start paying me a salary equivalent
> to my current one so I can hack on Gentoo all day long just to add a
> bunch of little "hold my hand and wipe my ass for me" features rather
> than working to add support for new devices and applications.

The feature was provided by the community a long time ago. Just have a look at 
the bugreport.


Alex

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

On Tue, 16 Nov 2004 21:08:06 +0100 Alexander Gretencord <arutha@gmx.de>
wrote:
| As said, have a look at the bug mentioned in the other msg, someone
| did it, just no gentoo developer seems to want to integrate the
| functionality that the community is ready to provide.

1. This isn't up to any Gentoo developer. There are only four of them
who could commit this.

2. The community provided solutions are inadequate.

3. You *really* don't want every einfo logged. Trust me, I already do
this, and it's messy. einfo wasn't designed to be logged, it was
designed to display a message to the user during a build. It'd be a heck
of a lot easier to go through and convert those few critical messages to
use a function like 'elog' or somesuch.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Alexander Gretencord]

On Tuesday 16 November 2004 21:14, Ciaran McCreesh wrote:
> 1. This isn't up to any Gentoo developer. There are only four of them
> who could commit this.

ok, portage developer :)

> 2. The community provided solutions are inadequate.

...

> 3. You *really* don't want every einfo logged. Trust me, I already do
> this, and it's messy. einfo wasn't designed to be logged, it was
> designed to display a message to the user during a build.

It would be enough to have all the einfos in one place, _after_ merging all 
packages is done for a start.

> It'd be a heck of a lot easier to go through and convert those few critical
> messages to use a function like 'elog' or somesuch.

So we'd have einfo, eerror, ewarn and everyimportanzupgrademessage? :)


Alex

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Bill Kenworthy]

There is already a logging facility that logs to /var/log/emerge.log
that can provide a"place" to log the messages. Why not just print the
messages there so a history is developed - seems the appropriate place
to me.

BillK


On Wed, 2004-11-17 at 03:38 +0100, Alexander Gretencord wrote:
> On Tuesday 16 November 2004 21:14, Ciaran McCreesh wrote:
> > 1. This isn't up to any Gentoo developer. There are only four of them
> > who could commit this.
> 
> ok, portage developer :)
> 
> > 2. The community provided solutions are inadequate.
> 
> ...
> 
> > 3. You *really* don't want every einfo logged. Trust me, I already do
> > this, and it's messy. einfo wasn't designed to be logged, it was
> > designed to display a message to the user during a build.
> 
> It would be enough to have all the einfos in one place, _after_ merging all 
> packages is done for a start.
> 
> > It'd be a heck of a lot easier to go through and convert those few critical
> > messages to use a function like 'elog' or somesuch.
> 
> So we'd have einfo, eerror, ewarn and everyimportanzupgrademessage? :)
> 
> 
> Alex
> 
> --
> gentoo-dev@gentoo.org mailing list
> 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On Wed, 17 Nov 2004 10:51:44 +0800
Bill Kenworthy <billk@iinet.net.au> wrote:

> There is already a logging facility that logs to /var/log/emerge.log
> that can provide a"place" to log the messages. Why not just print the
> messages there so a history is developed - seems the appropriate place
> to me.

No, that's definitely the wrong place. First you'd have the same problem
as currently as messages would be mixed with other stuff, also it's not
guaranteed that you'll even be able to identify the package the message
belongs to (parallel builds). And finally it has the potential to break
several tools using that file for statistics or recovery purposes.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Eldad Zack]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

On Tuesday 16 November 2004 22:14, Ciaran McCreesh wrote:
> On Tue, 16 Nov 2004 21:08:06 +0100 Alexander Gretencord <arutha@gmx.de>
> 3. You *really* don't want every einfo logged. Trust me, I already do
> this, and it's messy. einfo wasn't designed to be logged, it was
> designed to display a message to the user during a build. It'd be a heck
> of a lot easier to go through and convert those few critical messages to
> use a function like 'elog' or somesuch.

I'm all for this (I originally called it "enotice"), but the idea was shot 
done due to the fact that it would take alot of ebuild patching around.
And regarding hairy einfos: a possible workaround could be filtering all the 
standard stuff ("applying x.patch ..."/"libtoolizing") or maybe just 
converting the patching/libtoolizing function to use something like "enolog". 
That would require MUCH less manual labor around the tree if this is 
accepted...



-- 
Eldad Zack <eldad@gentoo.org>
Key/Fingerprint at pgp.mit.edu, ID 0x96EA0A93

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Thomas de Grenier de Latour]

On Wed, 17 Nov 2004 23:59:23 +0200
Eldad Zack <eldad@gentoo.org> wrote:

> On Tuesday 16 November 2004 22:14, Ciaran McCreesh wrote:
> > On Tue, 16 Nov 2004 21:08:06 +0100 Alexander Gretencord
> > <arutha@gmx.de> 3. You *really* don't want every einfo logged.
> > Trust me, I already do this, and it's messy. einfo wasn't
> > designed to be logged, it was designed to display a message to
> > the user during a build. It'd be a heck of a lot easier to go
> > through and convert those few critical messages to use a
> > function like 'elog' or somesuch.
> 
> I'm all for this (I originally called it "enotice"), but the
> idea was shot done due to the fact that it would take alot of
> ebuild patching around. And regarding hairy einfos: a possible
> workaround could be filtering all the standard stuff ("applying
> x.patch ..."/"libtoolizing") or maybe just converting the
> patching/libtoolizing function to use something like "enolog".
> That would require MUCH less manual labor around the tree if
> this is accepted...

I think that most einfos from ebuilds actually worth to be in
logs. The useless ones are in general the ones from eclasses
("applying patch foobar.diff", "updating scrollkeeper", etc.).
What i had done in my bug #37491 patches was logging einfo, and
providing a different command for less important messages that
only worth being lost with the rest of the compilation output.
This way, updating eclasses would be enough to get pretty clean
logs i think.

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Thomas de Grenier de Latour]

On Wed, 17 Nov 2004 23:19:37 +0100
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:

> On Wed, 17 Nov 2004 23:59:23 +0200
> Eldad Zack <eldad@gentoo.org> wrote:
<snip>
> > ("applying x.patch ..."/"libtoolizing") or maybe just
> > converting the patching/libtoolizing function to use something
> > like "enolog". That would require MUCH less manual labor
> > around the tree if this is accepted...
<snip> 
> providing a different command for less important messages that
> only worth being lost with the rest of the compilation output.
> This way, updating eclasses would be enough to get pretty clean
> logs i think.
> 

Oops, i'm basically saying exactly the same as you did. I replied
to your post after reading Ciaran's one only, sorry about that :/

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Conveying important upgrade messages to user community

[Duncan]

Chris Gianelloni posted
<1100623641.17212.108.camel@cgianelloni.nuvox.net>, excerpted below,  on
Tue, 16 Nov 2004 11:47:21 -0500:

> Wouldn't it be much nicer if users would do something like emerge -vuDpl
> world instead and actually get the ChangeLog entries?

Interestingly, I have a variety of e* aliases, including "eplogworld" that
does just that.  (There's also an eplog that does it for an individual
package.)

Unfortunately, -l doesn't work for downgrades, which except for important
packages (including hotplug, I was **NOT** caught unaware by this change),
is the place I'd be most able to use it.  Why is this package wanting to
downgrade?  Is it a security issue or just that someone reported a problem
in my current version that doesn't affect me, and the package was
therefore de-keyworded, but since it's already merged and working fine
here, it's safe to keep?  That sort of info should be in the changelog and
usually is, but -l won't show it because the version difference is
negative.

Could portage be fixed such that -l worked on the absolute value instead,
or in the event of a negative version delta, displayed the last X entries
pertaining to either the installed or the new version?  That would allow
it to catch most downgrade log entries.  Also, printing out any related
entries in package.mask would be quite helpful.

As it is, I often end up loading the various logs and/or package.mask
manually, to see why the downgrade.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]

On Tue, 2004-11-16 at 21:19 -0700, Duncan wrote:
> Unfortunately, -l doesn't work for downgrades, which except for important
> packages (including hotplug, I was **NOT** caught unaware by this change),
> is the place I'd be most able to use it.  Why is this package wanting to
> downgrade?  Is it a security issue or just that someone reported a problem
> in my current version that doesn't affect me, and the package was
> therefore de-keyworded, but since it's already merged and working fine
> here, it's safe to keep?  That sort of info should be in the changelog and
> usually is, but -l won't show it because the version difference is
> negative.
> 
> Could portage be fixed such that -l worked on the absolute value instead,
> or in the event of a negative version delta, displayed the last X entries
> pertaining to either the installed or the new version?  That would allow
> it to catch most downgrade log entries.  Also, printing out any related
> entries in package.mask would be quite helpful.

Actually, that would definitely be something that would be nice to see.
There is already code in portage for this, in a way.  Here's an example:

# emerge drpython
Calculating dependencies
!!! All ebuilds that could satisfy "drpython" have been masked.
!!! One of the following masked packages is required to complete your
request:
- dev-python/drpython-3.6.10 (masked by: package.mask)
# <lucass@gentoo.org> (15 Nov 2004)
# Masking due to dependency on wxpython-2.5

Now, the only problem with this, is this information would never be
displayed unless *all* versions were masked.  If it is a forced
downgrade, this would not be shown.  I'm not sure exactly how one would
go about determining whether or not to show this information.  I guess
some logic would have to be added to have portage display the reason for
it deciding to downgrade a package, whether by a removed keyword or
package.mask.

> As it is, I often end up loading the various logs and/or package.mask
> manually, to see why the downgrade.

As do I.

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Conveying important upgrade messages to user community

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

On Wed, 17 Nov 2004 09:46:11 -0500
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> Actually, that would definitely be something that would be nice to
> see. There is already code in portage for this, in a way.  Here's an
> example:
> 
> # emerge drpython
> Calculating dependencies
> !!! All ebuilds that could satisfy "drpython" have been masked.
> !!! One of the following masked packages is required to complete your
> request:
> - dev-python/drpython-3.6.10 (masked by: package.mask)
> # <lucass@gentoo.org> (15 Nov 2004)
> # Masking due to dependency on wxpython-2.5
> 
> Now, the only problem with this, is this information would never be
> displayed unless *all* versions were masked.

Not really, it's shown when all *matching* versions are masked, so you'd
just have to specify a specific version to emerge. However, it only gets
the information from package.mask so it won't help you with
keyword-masked packages.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Conveying important upgrade messages to user community

[Duncan]

Chris Gianelloni posted
<1100702771.17212.167.camel@cgianelloni.nuvox.net>, excerpted below,  on
Wed, 17 Nov 2004 09:46:11 -0500:

>> Could portage be fixed such that -l worked on the absolute value
>> instead, or in the event of a negative version delta, displayed the last
>> X entries pertaining to either the installed or the new version?  That
>> would allow it to catch most downgrade log entries.  Also, printing out
>> any related entries in package.mask would be quite helpful.
> 
> Actually, that would definitely be something that would be nice to see.
> There is already code in portage for this, in a way.  

[All ebuilds masked example.  Good point!]
 
> Now, the only problem with this, is this information would never be
> displayed unless *all* versions were masked.  If it is a forced downgrade,
> this would not be shown.
> 
>> As it is, I often end up loading the various logs and/or package.mask
>> manually, to see why the downgrade.
> 
> As do I.

Good to see someone else (and in an influential position at that) shares
my frustrations.  Of course, let's note that the present portage changelog
display feature is appreciated and useful as is (thanks, portage team), or
we wouldn't be frustrated at the inability to use it in the case of
downgrades because the feature wouldn't be there to be frustrated about
its absence!  <g>

Is this something I should portage enhancement bug?  I just did a search
and didn't come up with anything that would be a dup, but that may be my
choice of search terms.  Thought I'd ask here if it's been seen before,
tho, since the discussion is already here, before I go posting a new bug
for it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Simon Stelling]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

Hi Daniel

Daniel Drake wrote:
> My question is, how can we improve this situation? Portage really needs 
> a decent messaging system to convey messages like this. It's in the 
> works, right? It seems long overdue now...
> Users suggested making the messages appear at the very end of the emerge 
> process ("* X config files in /etc need updating" style), or an 
> etc-update style system where you read messages and dismiss them once 
> you've seen them, or a system which mails you those ewarn messages.
> I really hope portage will be able to provide functionality something 
> like this soon...

There is a patch to make portage quiet, but most of the users 
complaining about Gentoo beeing 'not working anymore' probably don't 
know how to/want to apply such a patch. This was already discussed 
earlier (see [gentoo-dev] rfc: epause instead of sleep in ebuilds, 
09/01/04). If users would only see the einfo, ewarn, eerrors and so on, 
they probably would read the emerge output. Those who don't at least 
couldn't blame us anymore, because it's really not hard to scroll up and 
read. Those who don't because they're doing the emerge -u world per 
cronjob or so could mail these warnings themself anyway, most (all?) 
crons provide such a service.

> In the meantime, could we have handled this better with the resources 
> available to us right now? How have other people coped with similar 
> changes?

I don't see anything beside a new standard setting in portage. There 
would be solutions, but the problem is that people that would 'install' 
them wouldn't blame you anyway...

greetings

blubb

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]

On Tue, 2004-11-16 at 15:13 +0000, Daniel Drake wrote:
> In the meantime, could we have handled this better with the resources 
> available to us right now? How have other people coped with similar changes?

There's also the option of posting to the many available mailing lists.
gentoo-dev and gentoo-user would be prime examples of places I would
send something likely to affect a ton of people, and the oft-suggested
but rarely used gentoo-announce.

When I moved fonts in X to /usr/share/fonts, I not only had a long
einfo, but it sat there for about 15 seconds and beeped at you. Some
people find this annoying, but I actually don't recall _anyone_ filing a
bug on difficulties with the change (yet).

Part of that may be due to it simply being fixed by running etc-update
and also warning about the deprecated location for a while before
obsoleting it.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Tom Hosiawa]

I use portlog-info ( http://tdegreni.free.fr/gentoo/portlog-info )
every time after emerging world.

It displays in a real nice way all the einfo/ewarn messages in
/var/log/portage. Then after reading all the messages, I remove all
files in /var/log/portage so the next time I emerge world, I only see
new messages.

Maybe this should be added to gentoolkit, or even integrated into
portage itself? That way I could do something like 'emerge --loginfo'
to display all the einfo/ewarn messages in /var/log/portage after
emerging something. Then 'emerge --loginfo --clear' to clear the
contents of /var/log/portage so I'll only see new messages next time.

Tom

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Alexander Gretencord]

On Tuesday 16 November 2004 19:14, Donnie Berkholz wrote:
> When I moved fonts in X to /usr/share/fonts, I not only had a long
> einfo, but it sat there for about 15 seconds and beeped at you.

The only thing that would make me see that info would probably be the fact 
that I would probably merge X as the last package in a long merge, otherwise 
even this 15 seconds of beeping would go unnoticed in the screen session, if 
I were to say merge kde right after that...

> Part of that may be due to it simply being fixed by running etc-update

That might indeed be the case. Actually I think this is probably _the_ 
explanation.

> and also warning about the deprecated location for a while before
> obsoleting it.

I have not merged X for quite a long time now. (ls /var/db/pkg/x11-base: Dec 
21  2003 xfree-4.3.0-r3). Actually I tried to merge x.org a few days ago, but 
it did not compile and I didn't have the time to have a look at it. Too bad 
you don't support XFree anymore in the nvidia ebuilds (a warning that makes 
the build _die_) although x.org does not compile for some ppl (yeah I know 
I'm gonna bugreport as soon as I get the time to try the build again)


Alex

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

On Tue, 2004-11-16 at 19:50 +0100, Alexander Gretencord wrote:
> I have not merged X for quite a long time now. (ls /var/db/pkg/x11-base: Dec 
> 21  2003 xfree-4.3.0-r3). Actually I tried to merge x.org a few days ago, but 
> it did not compile and I didn't have the time to have a look at it. Too bad 
> you don't support XFree anymore in the nvidia ebuilds (a warning that makes 
> the build _die_) although x.org does not compile for some ppl (yeah I know 
> I'm gonna bugreport as soon as I get the time to try the build again)

I think the nvidia thing has been reported and removed.

You might want to figure out something with xorg soon, as xfree will be
removed Jan. 1.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Conveying important upgrade messages to user community

[Michael Sterrett -Mr. Bones.-]

On Tue, 16 Nov 2004, Donnie Berkholz wrote:

> On Tue, 2004-11-16 at 19:50 +0100, Alexander Gretencord wrote:
> > I have not merged X for quite a long time now. (ls /var/db/pkg/x11-base: Dec 
> > 21  2003 xfree-4.3.0-r3). Actually I tried to merge x.org a few days ago, but 
> > it did not compile and I didn't have the time to have a look at it. Too bad 
> > you don't support XFree anymore in the nvidia ebuilds (a warning that makes 
> > the build _die_) although x.org does not compile for some ppl (yeah I know 
> > I'm gonna bugreport as soon as I get the time to try the build again)
> 
> I think the nvidia thing has been reported and removed.

x11-base/opengl-update-1.8.1-r1 still dies if you're using xfree right
now and haven't done the manual "mv /usr/X11R6/include/GL/glext.h
/usr/lib/opengl/xfree/include" that is spit out as the ebuild dies.

Michael Sterrett
  -Mr. Bones.-
mr_bones_@gentoo.org

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Conveying important upgrade messages to user community

[Donnie Berkholz]

On Tue, 2004-11-16 at 11:33, Michael Sterrett -Mr. Bones.- wrote:
> x11-base/opengl-update-1.8.1-r1 still dies if you're using xfree right
> now and haven't done the manual "mv /usr/X11R6/include/GL/glext.h
> /usr/lib/opengl/xfree/include" that is spit out as the ebuild dies.

Yes, it does. I was talking about something added to nvidia's
pkg_setup() that said, if has_version x11-base/xfree, then die.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Nick Rout]

On Tue, 16 Nov 2004 15:13:37 +0000
Daniel Drake <dsd@gentoo.org> wrote:


> 
> My question is, how can we improve this situation? Portage really needs a 
> decent messaging system to convey messages like this. It's in the works, 
> right? It seems long overdue now...

non-developer lurker here: how about (optionally) the user sets an email
address in make.conf and gets emailed really important earth shattering
stuff. maybe a new function in ebuilds like:

eemailwarn "you need to install coldplug....blah blah..."





--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

On Wed, 17 Nov 2004 11:06:42 +1300 Nick Rout <nick@rout.co.nz> wrote:
| On Tue, 16 Nov 2004 15:13:37 +0000
| Daniel Drake <dsd@gentoo.org> wrote:
| > My question is, how can we improve this situation? Portage really
| > needs a decent messaging system to convey messages like this. It's
| > in the works, right? It seems long overdue now...
| 
| non-developer lurker here: how about (optionally) the user sets an
| email address in make.conf and gets emailed really important earth
| shattering stuff. maybe a new function in ebuilds like:
| 
| eemailwarn "you need to install coldplug....blah blah..."

Not all users have an mta installed. Any solution along these lines
would need to support at a minimum these options:
* sending via an mta
* writing to the system log
* writing to a particular file
* displaying all messages post merge
* discarding messages

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On Tuesday 16 November 2004 23:37, Ciaran McCreesh wrote:

> Not all users have an mta installed. Any solution along these lines
> would need to support at a minimum these options:
> * sending via an mta
> * writing to the system log
> * writing to a particular file
> * displaying all messages post merge
> * discarding messages

If setting the email address is a prerequisite I don't think this is an 
issue. Of course alternative courses of action are nice. In any case a 
mta is pretty standard (even if it is ssmtp) as cron needs it and cron is 
really really handy for any unix system (For example for log rotating).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

On Wed, 17 Nov 2004 15:17:29 +0100
Paul de Vrieze <pauldv@gentoo.org> wrote:

> On Tuesday 16 November 2004 23:37, Ciaran McCreesh wrote:
> 
> > Not all users have an mta installed. Any solution along these lines
> > would need to support at a minimum these options:
> > * sending via an mta
> > * writing to the system log
> > * writing to a particular file
> > * displaying all messages post merge
> > * discarding messages
> 
> If setting the email address is a prerequisite I don't think this is
> an issue. Of course alternative courses of action are nice. In any
> case a mta is pretty standard (even if it is ssmtp) as cron needs it
> and cron is really really handy for any unix system (For example for
> log rotating).

Ciaranm is right here for once. Please remember that portage is also
used during bootstrap, also several people (including myself) don't want
emails from portage.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Jeff Smelser]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

On Wednesday 17 November 2004 10:11 am, Marius Mauch wrote:

> Ciaranm is right here for once. Please remember that portage is also
> used during bootstrap, also several people (including myself) don't want
> emails from portage.

Then dont set the option then you dont get the emails. Whats wrong with the 
option being there?

Jeff

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Wed, 17 Nov 2004 09:42:12 -0600
Jeff Smelser <tradergt@smelser.org> wrote:

> On Wednesday 17 November 2004 10:11 am, Marius Mauch wrote:
> 
> > Ciaranm is right here for once. Please remember that portage is also
> > used during bootstrap, also several people (including myself) don't
> > want emails from portage.
> 
> Then dont set the option then you dont get the emails. Whats wrong
> with the option being there?

Please read ciaranms mail again. I've never said that there shouldn't be
a mail option.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

On Wed, 2004-11-17 at 11:06 +1300, Nick Rout wrote:
> non-developer lurker here: how about (optionally) the user sets an email
> address in make.conf and gets emailed really important earth shattering
> stuff. maybe a new function in ebuilds like:
> 
> eemailwarn "you need to install coldplug....blah blah..."

I only see one problem here.  Who would decide what is "earth
shattering" and what isn't?  Personally, I wouldn't include
hotplug/coldplug into this, at all.  In fact, the *only* things I can
think of that I would do this with would be toolchain or portage
related.

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On Wed, 2004-11-17 at 09:23 -0500, Chris Gianelloni wrote:
> On Wed, 2004-11-17 at 11:06 +1300, Nick Rout wrote:
> > non-developer lurker here: how about (optionally) the user sets an email
> > address in make.conf and gets emailed really important earth shattering
> > stuff. maybe a new function in ebuilds like:
> > 
> > eemailwarn "you need to install coldplug....blah blah..."
> 
> I only see one problem here.  Who would decide what is "earth
> shattering" and what isn't?  Personally, I wouldn't include
> hotplug/coldplug into this, at all.  In fact, the *only* things I can
> think of that I would do this with would be toolchain or portage
> related.

I'd say "Anything that if ignored may result in an unusable or
unbootable system" would go in -- that could include hotplug/coldplug if
one has the right (wrong) things built modularly.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Ed Grimm]

On Tue, 16 Nov 2004, Daniel Drake wrote:

> Hi,

<snip>

> My question is, how can we improve this situation? Portage really needs a
> decent messaging system to convey messages like this. It's in the works,
> right? It seems long overdue now...

Just in case it was lost in all of the messages...

The correct fix is a combination of solutions:

1. Use the mailing lists to announce changes that will break things
unless the users take action.

2. Use the newsletter to announce changes that will break things unless
the users take action.

3. Have emerge print a summary of the changes that will break things
unless the users take action that were installed in that run after
emerge finishes running (reducing the emerge output to just this info
would also work.)

4. Have an option, specifiable in /etc/make.conf, to email the output in
3 instead.


Actions three and four should be fairly easy, as someone mentioned a
program that apparently runs over the contents of /var/log/portage, and
produces a list of those changes.  It should be trivial to include that
in portage, or have it installed with portage, and have emerge execute
it after a run that installed things.

Actions one and two should be fairly easy, as everyone writing to this
list has demonstrated the technical competence to do the first, and I'm
sure most of us have demonstrated the technical competence to do the
second - there's a blurb at the end of every newsletter, informing
anyone who cares how to get something added.

Note that I expect that we'll have all of the above in place sometime
before we've hired our tenth full-time developer.  While I don't expect
that we'll have all of them in place before our first full-time
developer, I certainly wouldn't mind.  (I think that, so long as this
remains a part-timer operation, having two of the four options generally
available would suffice.  That is, until the code items for three and
four are complete, the first two really should be used.)

> In the meantime, could we have handled this better with the resources
> available to us right now? How have other people coped with similar changes?

Of course.  Actions one and two do not require any code updates.

Ed

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Conveying important upgrade messages to user community

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

On Wed, 2004-11-17 at 03:21 +0000, Ed Grimm wrote:
> Note that I expect that we'll have all of the above in place sometime
> before we've hired our tenth full-time developer.  While I don't expect
> that we'll have all of them in place before our first full-time
> developer, I certainly wouldn't mind.  (I think that, so long as this
> remains a part-timer operation, having two of the four options generally
> available would suffice.  That is, until the code items for three and
> four are complete, the first two really should be used.)

*APPLAUSE*

Thank you.  This really is the best news I have heard on this.  Perhaps
we need to use gentoo-announce more.  We have several resources at our
disposal, the www.gentoo.org site, the forums announcements, the GWN,
and the -announce mailing list.

I think part of the problem is that some people (myself included) rely
on functionality which is not meant to be relied on, such as using
hotplug to find devices which were plugged in at boot time, and
therefore not *hot plugged* into the machine.

Essentially, many people (once again, myself included) were using an
application in a way in which is what not intended by the upstream
author.  The "unwanted" functionality was removed, with lots of big
warnings, and many people complained.  It happens... big deal.  Let's
learn from it and move on to working on making a better solution for the
future.

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Conveying important upgrade messages to user community

[Daniel Drake]

Hi,

Recently we

--
gentoo-dev@gentoo.org mailing list