17:16 < darkside_> no clue, I was wondering what Betelgeuse meant 17:16 < ssuominen> Copying it over to metadata/news with the directory and .txt doesn't seem to work. 17:17 < Betelgeuse> ssuominen: /usr/portage/metadata/news/timestamp.chk 17:18 < ssuominen> Still nothing 17:21 < ssuominen> Changed the timestamp to next day, added the directory and the .txt 17:21 < ssuominen> Tried --metadata too, but no-go 17:23 < Betelgeuse> ssuominen: try emerge --pretend 17:23 < Betelgeuse> ssuominen: GLEP 42 says when the PM should show things 17:28 < ssuominen> 2009-21-10-default-linux/2009-21-10-default-linux.en.txt and the date in timestamp.chk is tomorrow 17:31 < Betelgeuse> ssuominen: read Portage code and it only happens on sync 17:32 < Betelgeuse> writing a bug GLEP 42 http://www.gentoo.org/proj/en/glep/glep-0042.html says: Checks for new news messages should be displayed: * After an emerge sync * After an emerge --pretend * Before an emerge <target> (which may also include a red warning message) So check for new items should be done more often. Reading Portage code i see it being hit only when syncing. Ciaran: please confirm that my interpretation of GLEP 42 is correct.
Yup. 42's worded that way because some people sync on a cron and don't look at the output. It's supposed to be pretty hard to avoid seeing news items.
(In reply to comment #0) > GLEP 42 http://www.gentoo.org/proj/en/glep/glep-0042.html says: > Checks for new news messages should be displayed: > > * After an emerge sync > * After an emerge --pretend > * Before an emerge <target> (which may also include a red warning message) Looking at the code, all of these cases appear to be covered (the display_news_notification function is called in 3 different places). It seems like something else must have gone wrong. I guess I'll have to try to reproduce the issue with your news item and same version of portage?
It seems like this is why it's not working: Display-If-Profile: default-linux The existing code only does not work for partial profile paths (it only compares the whole path).
Mmm, 42 says "exact" on the profile match, so parents are ignored. As I recall, this was because we wanted to be able to deprecate not using a particular subprofile, for example when adding in desktop/ and server/ things.
Maybe we should accommodate both behaviors by adding a /* operator or something like that.
Probably. I think there were some other things wanted for GLEP 42 too... News items aren't currently part of PMS's domain, though. So far as I know, doing a 1.1 news item format would require either a change of ownership or a second GLEP.
(In reply to comment #6) > Probably. I think there were some other things wanted for GLEP 42 too... > Yes for example one often used is something like Display-If-Visible for catching when people can upgrade to something. > News items aren't currently part of PMS's domain, though. So far as I know, > doing a 1.1 news item format would require either a change of ownership or a > second GLEP. > I have no problem rolling news items to PMS but we can also do a new GLEP for news item format 1.1.
(In reply to comment #7) > (In reply to comment #6) > > Probably. I think there were some other things wanted for GLEP 42 too... > > > > Yes for example one often used is something like Display-If-Visible for > catching when people can upgrade to something. > > > News items aren't currently part of PMS's domain, though. So far as I know, > > doing a 1.1 news item format would require either a change of ownership or a > > second GLEP. > > > > I have no problem rolling news items to PMS but we can also do a new GLEP for > news item format 1.1. Let's do a new GLEP instead with some simplications to the format. Where and how do we want to collect ideas?
I'm not sure that the format can be simplified without losing support for some of the initial requirements... Display-If-Visible, for example, won't work when the user changes configuration files to unmask something. If you wanted that to work, you'd have to force the package manager to rescan news items before every operation, which is a) expensive and b) not going to work because it won't have write permission to the news files anyway.
Is this still an issue, given that we have News-Item-Format 2.0 by now?
