[gentoo-dev] Re: News item: media-sound/pulseffects "renaming"

[Marek Szuba]

On 2021-07-13 01:01, Marek Szuba wrote:


Title: PipeWire versions of PulseEffects are now media-sound/easyeffects
Author: Marek Szuba 
Posted: 2021-07-16
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: >=media-sound/pulseeffects-5.0.0

In response to the upstream decision to rename PulseEffects to 
EasyEffects we have decided to adopt the new name for versions only 
supporting media-video/pipewire while retaining the old one for versions 
allowing the use of media-sound/pulseaudio.


media-sound/easyeffects is already available in the tree, and all the
PipeWire-dependent ebuilds of media-sound/pulseeffects will be removed
in 7 days. Therefore, users of >=media-sound/pulseeffects-5.0.0 are 
asked to emerge media-sound/easyeffects instead.


Looks like Thunderbird's somehow cocked up the line breaks in the first 
paragraph :-/ For the record, _this_ is what the news item looks like 
(modulo quote marks of course) in my text file.


--
MS



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

[Adam Feldman]

On 6/27/20 1:36 PM, William Hubbs wrote:
> On Sun, Jun 21, 2020 at 10:02:25PM +0200, Andreas Sturmlechner wrote:
>> On Sunday, 21 June 2020 21:27:02 CEST Joonas Niilola wrote:
>>> What's the current trend of attaching news items? It
>>> makes hard to point out enhancements.
>>
>> Indeed, I didn't even look at the previous mail that was sent like that.
> 
> I realize I'm late to this and maybe this is being discussed in another
> thread (I'm catching up), but attaching newsitems is the standard way of
> getting them reviewed; this is not anything new.
> 
> Thanks,
> 
> William
> 

I think the point being made was that the vast majority of news items
are posted as content inlined in the email as opposed to an attached file.

-- 
Thanks,

Adam Feldman
Gentoo Developer
np-hard...@gentoo.org
0x671C52F118F89C67



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

[William Hubbs]

On Sun, Jun 21, 2020 at 10:02:25PM +0200, Andreas Sturmlechner wrote:
> On Sunday, 21 June 2020 21:27:02 CEST Joonas Niilola wrote:
> > What's the current trend of attaching news items? It
> > makes hard to point out enhancements.
> 
> Indeed, I didn't even look at the previous mail that was sent like that.

I realize I'm late to this and maybe this is being discussed in another
thread (I'm catching up), but attaching newsitems is the standard way of
getting them reviewed; this is not anything new.

Thanks,

William



signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

[Piotr Karbowski]

Hi,

On 21/06/2020 22.27, Michał Górny wrote:
> No offense but it sounds a little chaotic to me.

Which is the reasons we do those reviews. Appreciate the suggestions,
just sent revision 2 as the response to the very first email in this
thread, please check how it looks now.

-- Piotr.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item: xorg-server dropping default suid

[Piotr Karbowski]

Title: xorg-server dropping default suid
Author: Piotr Karbowski 
Posted: 2020-06-22
Revision: 2
News-Item-Format: 2.0
Display-If-Installed: x11-base/xorg-server

Starting 2020-07-15, x11-base/xorg-server will default to using the
logind interface instead of suid by default. resulting in better
security by default through running the server as a regular user instead
of root. However, this will require our users to use a logind provider
such as elogind or systemd. The systemd users and those who are not
using systemd but use desktop profiles can stop reading here, as they
already have a logind provider enabled.

Others, who have neither systemd or desktop profiles enabled will be
required to globally enable 'elogind' USE flag and update the system

    # emerge --newuse @world

Afterwards, one will need to re-login, so the PAM can assign a seat. One
can confirm that a seat has been assigned upon login by running:

    $ loginctl user-status

Users who do not wish to use logind interface or have rare hardware that
does not use KMS and because of that, require root privileges to
operate, can manually re-enable 'suid' and disable 'elogind' USE flags
in order to preserve the previous behavior. However, please note that
this is heavily discouraged to run X server as root due to security
reasons. The 'suid' USE flag will remain as optional opt-in for the need
of legacy hardware.




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item: xorg-server dropping default suid

[Robin H. Johnson]

On Sun, Jun 21, 2020 at 09:22:37PM +0200, Piotr Karbowski wrote:
> Hi,
> 
> Please find news item attached.
I feel that this news item should ALSO remind people that consolekit is
deprecated per a news item a few months ago:

News Item v3: Desktop profile switching USE default to elogind

xorg-server[elogind] forces sys-auth/pambase[elogind]
and users who previously had USE='-systemd -elogind' probably have
USE=consolekit set.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

[Philip Webb]

200622 Piotr Karbowski wrote:
> On 22/06/2020 06.03, Philip Webb wrote:
> [...]
>> I don't want to use 'systemd', as I want to run a traditional UNIX version
>> of Linux + KDE (or Fluxbox) for a simple single-user desktop system.
> Then... don't use systemd !  I officially give you my approval for that.
> Read what you quoted in your email, elogind is standalone package.
> Elogind does work normally in the configuration with OpenRC and startx.

Ah, it cb used with 'startx', which is vital for me.

>> So again : Why is running 'xorg-server' as root "heavily discouraged" ?
> It's common sense to run software with the least privileges they require,
> so if new attack vector is discovered,
> perhaps there will be no escalation surface to make use of it.

OK, understood.  It doesn't look as if there's any genuine danger
in continuing to use 'xorg-server' with 'suid' on my single-user system,
but if it really is as straightforward to use 'elogind' instead,
I may decide to change to that method for the reason you offer.

Thanks for your explanation & to all the devs for their unpaid labors.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatcadotinterdotnet

Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

[Piotr Karbowski]

Hi,

On 22/06/2020 06.03, Philip Webb wrote:
[...]
> I don't want to use 'systemd', as I want to run a traditional UNIX version
> of Linux + KDE (or Fluxbox) for a simple single-user desktop system.

Then... don't use systemd? I officially give you my approval for that.
Read what you quoted in your email, elogind is standalone package.

The elogind does work normally in the configuration with OpenRC and startx.

> So i ask again : Why is running 'xorg-server' as root "heavily discouraged" ?
It's common sense to run software with the least privileges they
require, so if new attack vector is discovered, perhaps there will be no
escalation surface to make use of it.

-- Piotr.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

[Philip Webb]

200621 Matt Turner wrote:
> On Sun, Jun 21, 2020 at 4:53 PM Philip Webb  wrote:
>> I've been running xorg-server as root for  > 16 yr  without any problems.
>> AFAIK there are no problems re exploits via I/net browsers,
>> which are started by my user as all such user software always is.
>> What might go wrong, if I continue to 'startx'
>> with 'xorg-server' merged with 'suid -elogind'
>> & without the '.xinitrc' line show above in the Wiki ?
> For the majority of users -- those that use a graphics driver
> with kernel modesetting support -- , X only needs root access
> for a small set of things : accessing the DRM device node,
> accessing the input device nodes and some stuff around VTs.
> The rest of the time, X doesn't need root access.
> With elogind, those bits are handled in a small daemon
> and X no longer needs to run as root.  Most people find that valuable,
> especially with the knowledge that there have been
> a number of security vulnerabilities that would allow arbitrary code
> execution in the xserver over the years [1].

The latest of those was announced in 2018
& all of them seem to involve privilege escalation by local users ;
those marked 'remote' all seem to be via off-site logins.
There doesn't appear ever to have been a genuine remote threat,
so single-user systems have never been threatened by xorg-server as root.

> [1] 
> https://www.cvedetails.com/vulnerability-list/vendor_id-88/product_id-8600/X.org-Xorg-server.html

So i ask again : Why is running 'xorg-server' as root "heavily discouraged" ?

There was a similar issue a few years ago,
when the game Nethack was threatened with removal from Gentoo
due to a security problem which affected only multi-user systems.
Is there any difference in this case of xorg-server ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatcadotinterdotnet

Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

[Matt Turner]

On Sun, Jun 21, 2020 at 4:53 PM Philip Webb  wrote:
>
> 200621 Piotr Karbowski wrote:
> > Title: xorg-server dropping default suid
> ...
> > The Gentoo X11 Team is announcing that starting with 15th of July,
> > the x11-base/xorg-server will no longer default to suid
> > and will default to using logind interface instead.  This change
> > makes xorg-server run as regular user rather than root by default,
> > however those who do not have any logind interface provider
> > -- either systemd or elogind -- will need to enable either
> > to make it possible to run X session as unprivileged user.
> > No action is required from systemd and desktop profile users,
> > since systemd provides logind interface
> > and desktop profile already enables 'elogind' USE flag globally.
> > Rest of the non-systemd users is required to globally enable
> > 'elogind' USE flag and apply it by 'emerge --newuse @world',
> > after which, re-login is required so that PAM can allocate seat.
> > One can confirm that a seat has been assigned upon login by running:
> > $ loginctl user-status
> > Those who for whatever reason want to preserve current state,
> > while heavily discouraged,
> > can still use x11-base/xorg-server with 'suid -elogind'.
>
> Gentoo Wiki says :
>
>   elogind is the systemd project's logind, extracted to a standalone package.
>   It's designed for users who prefer a non-systemd init system,
>   but still want to use popular software such as KDE/Wayland or GNOME
>   that otherwise hard-depends on systemd.
>
>   startx integration : To have an elogind session created
>   when using startx to start the X server (instead of a display manager),
>   add the following to the user's ~/.xinitrc file : FILE ~/.xinitrc
>exec dbus-launch --exit-with-session 
>   WINDOW_MANAGER in the above example needs to be replaced
>   by a window manager or a single application.
>
> I want to use 'startx' to start X , because I don't want to be trapped
> if some problem arises with X or KDE or the login manager
> & I need to change config files or remerge pkgs (etc) to rescue myself.
> With 'startx' I can do all that work from raw TTYs with no problems,
> as I am not forced to go into an X session if I don't want to.

Thank you for actually participating in the discussion, unlike the
last thread about this topic.

> I don't want to use 'systemd', as I want to run a traditional UNIX version
> of Linux + KDE (or Fluxbox) for a simple single-user desktop system.
>
> Why is running 'xorg-server' as root "heavily discouraged" ?
> -- I've been doing that with Gentoo for  > 16 yr  without any problems.
> AFAIK there are no problems re exploits via I/net browsers,
> which are started by my user as all such user software always is.
> What might go wrong, if I continue to 'startx'
> with 'xorg-server' merged with 'suid -elogind'
> & without the '.xinitrc' line show above in the Wiki ?

For the majority of users (those that use a graphics driver with
kernel modesetting support), X only needs root access for a small set
of things: accessing the DRM device node, accessing the input device
nodes, and some stuff around VTs. The rest of the time, X doesn't need
root access but still must run as root for those cases I mention.

With elogind, those bits are handled in a small daemon, and X no
longer needs to run as root. Most people find that to be valuable,
especially with the knowledge that there have been a number of
security vulnerabilities found that would allow arbitrary code
execution in the xserver over the years [1].

Our current default of USE=suid installs /usr/bin/Xorg with the setuid
bit set, allowing it to be run *as root* by any user. This enables
non-root users to execute startx, for example.

I appreciate that Gentoo users are a diverse bunch, to say the least.
This news item is about *defaults*. I'm happy to explain the value of
the new default to people who are genuinely curious but I have no
interest in trying to convince you or anyone else of anything.

You're free to keep the status quo with a single line in
/etc/portage/package.use. The people building and maintaining the
distro think that the new defaults are better defaults for the vast
majority of users, but again they're just defaults.

[1] 
https://www.cvedetails.com/vulnerability-list/vendor_id-88/product_id-8600/X.org-Xorg-server.html

Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

[Philip Webb]

200621 Piotr Karbowski wrote:
> Title: xorg-server dropping default suid
...
> The Gentoo X11 Team is announcing that starting with 15th of July,
> the x11-base/xorg-server will no longer default to suid
> and will default to using logind interface instead.  This change
> makes xorg-server run as regular user rather than root by default,
> however those who do not have any logind interface provider
> -- either systemd or elogind -- will need to enable either
> to make it possible to run X session as unprivileged user.
> No action is required from systemd and desktop profile users,
> since systemd provides logind interface
> and desktop profile already enables 'elogind' USE flag globally.
> Rest of the non-systemd users is required to globally enable
> 'elogind' USE flag and apply it by 'emerge --newuse @world',
> after which, re-login is required so that PAM can allocate seat.
> One can confirm that a seat has been assigned upon login by running:
> $ loginctl user-status
> Those who for whatever reason want to preserve current state,
> while heavily discouraged,
> can still use x11-base/xorg-server with 'suid -elogind'.

Gentoo Wiki says :

  elogind is the systemd project's logind, extracted to a standalone package.
  It's designed for users who prefer a non-systemd init system,
  but still want to use popular software such as KDE/Wayland or GNOME
  that otherwise hard-depends on systemd. 

  startx integration : To have an elogind session created
  when using startx to start the X server (instead of a display manager),
  add the following to the user's ~/.xinitrc file : FILE ~/.xinitrc
   exec dbus-launch --exit-with-session 
  WINDOW_MANAGER in the above example needs to be replaced
  by a window manager or a single application. 

I want to use 'startx' to start X , because I don't want to be trapped
if some problem arises with X or KDE or the login manager
& I need to change config files or remerge pkgs (etc) to rescue myself.
With 'startx' I can do all that work from raw TTYs with no problems,
as I am not forced to go into an X session if I don't want to.

I don't want to use 'systemd', as I want to run a traditional UNIX version
of Linux + KDE (or Fluxbox) for a simple single-user desktop system.

Why is running 'xorg-server' as root "heavily discouraged" ?
-- I've been doing that with Gentoo for  > 16 yr  without any problems.
AFAIK there are no problems re exploits via I/net browsers,
which are started by my user as all such user software always is.
What might go wrong, if I continue to 'startx'
with 'xorg-server' merged with 'suid -elogind'
& without the '.xinitrc' line show above in the Wiki ?

Are there any other Gentoo users who have the same preferences as me ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatcadotinterdotnet

Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

[Michał Górny]

On Sun, 2020-06-21 at 22:09 +0200, Piotr Karbowski wrote:
> Hi,
> 
> Re-sending news item inline.
> 
> ###
> 
> Title: xorg-server dropping default suid
> Author: Piotr Karbowski 
> Posted: 2020-06-22
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: x11-base/xorg-server
> 
> The Gentoo X11 Team is announcing that starting with 15th of July,
> the x11-base/xorg-server will no longer default to suid and will default
> to using logind interface instead. This change makes xorg-server run as
> regular user rather than root by default, however, those who do not have
> any logind interface provider (either systemd or elogind) will need to
> enable either to make it possible to run X session as unprivileged user.

No offense but it sounds a little chaotic to me.  How about something
like:

Starting 2020-07-15 [use ISO dates, please], x11-base/xorg-server will
default to using logind interface instead of suid by default. It will
result in ... [what? better security?] through running the server
as a regular user instead of root. However, this will require our users
to use a logind provider such as elogind or systemd.

> No action is required from systemd and desktop profile users, since
> systemd provides logind interface, and desktop profile already enables
> 'elogind' USE flag globally.
> 
> Rest of the non-systemd users is required to globally enable 'elogind'

The remaining users are ... 'elogind' [or 'systemd'?]

> USE flag and apply it by 'emerge --newuse @world'

Cut sentence here.

> , after which, re-login
> is required so that PAM can allocate seat.

Afterwards, ...

> 
> One can confirm that a seat has been assigned upon login by running:
> 
> $ loginctl user-status
> 
> Those who for whatever reason want to preserve current state, while
> heavily discourage, can still use x11-base/xorg-server with 'suid -elogind'.

'whatever reason' doesn't sound professional.  How about:

Users who do not wish to use logind interface can manually reenable
'suid' flag in order to preserve the previous behavior. However, please
note that this is heavily discouraged... [maybe explain why? also, are
we going to eventually remove it?]

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: News item: xorg-server dropping default suid

[Piotr Karbowski]

Hi,

Re-sending news item inline.

###

Title: xorg-server dropping default suid
Author: Piotr Karbowski 
Posted: 2020-06-22
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: x11-base/xorg-server

The Gentoo X11 Team is announcing that starting with 15th of July,
the x11-base/xorg-server will no longer default to suid and will default
to using logind interface instead. This change makes xorg-server run as
regular user rather than root by default, however, those who do not have
any logind interface provider (either systemd or elogind) will need to
enable either to make it possible to run X session as unprivileged user.

No action is required from systemd and desktop profile users, since
systemd provides logind interface, and desktop profile already enables
'elogind' USE flag globally.

Rest of the non-systemd users is required to globally enable 'elogind'
USE flag and apply it by 'emerge --newuse @world', after which, re-login
is required so that PAM can allocate seat.

One can confirm that a seat has been assigned upon login by running:

$ loginctl user-status

Those who for whatever reason want to preserve current state, while
heavily discourage, can still use x11-base/xorg-server with 'suid -elogind'.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item: xorg-server dropping default suid

[Andreas Sturmlechner]

On Sunday, 21 June 2020 21:27:02 CEST Joonas Niilola wrote:
> What's the current trend of attaching news items? It
> makes hard to point out enhancements.

Indeed, I didn't even look at the previous mail that was sent like that.

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Re: News item: xorg-server dropping default suid

[Joonas Niilola]

Hey,

It has some typos. What's the current trend of attaching news items? It
makes hard to point out enhancements.

-- juippis

On 6/21/20 10:22 PM, Piotr Karbowski wrote:
> Hi,
>
> Please find news item attached.
>
> -- Piotr.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News Item: sys-libs/pam-1.4.0 upgrade

[Mikle Kolyada]

On 20.06.2020 16:55, Mikle Kolyada wrote:
> Attached

A bit fixed, wanted another version to show.

Title: sys-libs/pam-1.4.0 upgrade
Author: Mikle Kolyada 
Content-Type: text/plain
Posted: 2020-06-??
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-libs/pam
Display-If-Installed: sys-auth/pambase

Starting with the 1.4.0 release [1], we don't offer these modules anymore:

* pam_tally and pam_tally2 have been deprecated and replaced 
  by the pam_faillock module
* pam_cracklib has been deprecated and replaced
  by the pam_passwdqc module

These changes affected our basic PAM stack configuration.

You only need to take action if:
* you made manual changes to the PAM stack, or
* you use FEATURES="-config-protect-if-modified" option

If this applies to you, please make sure to either run the etc-update or
dispatch-conf command in order to sync your configuration.

Failure to do this may result in your system becoming inaccessible.

[1] - https://github.com/linux-pam/linux-pam/releases/tag/v1.4.0


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.

[Gordon Pettey]

On Thu, Apr 2, 2020 at 10:27 AM Piotr Karbowski 
wrote:

> while keeping the long sentence, that even it's long, is still beneficial
> to have
>

Split it for grammatical correctness and ease of human parsing.

The only use for those drivers remain in deployments which intentionally
> opt-out of using udev, as both evdev and libinput require udev during
> runtime, however given that upstream has already removed the Linux
>

Replace with "runtime. Given that upstream"

support from xf86-input-keyboard, future X11 releases will no longer
> support xf86-input-keyboard on Linux rendering those installation
>

installations should be plural


> infeasible to use without udev.
>

[gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.

[Piotr Karbowski]

Hi,

On 02/04/2020 17.26, Piotr Karbowski wrote:
> Hi,
> 
> Updated with what Ulm and Soup pointed out, while keeping the long
> sentence, that even it's long, is still beneficial to have. Revision
> bumped to 2, date bumped to tomorrow's.

My apology, s/Soup/Soap/.

-- Piotr.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item: Deprecation and removal of legacy X11 input drivers.

[Piotr Karbowski]

Hi,

Updated with what Ulm and Soup pointed out, while keeping the long
sentence, that even it's long, is still beneficial to have. Revision
bumped to 2, date bumped to tomorrow's.

--- news item below ---

Title: Deprecation of legacy X11 input drivers
Author: Piotr Karbowski 
Posted: 2020-04-03
Revision: 2
News-Item-Format: 2.0
Display-If-Installed: x11-drivers/xf86-input-mouse
Display-If-Installed: x11-drivers/xf86-input-keyboard

The Gentoo X11 Team is announcing the deprecation and future removal of
the legacy X11 input drivers x11-drivers/xf86-input-mouse and
x11-drivers/xf86-input-keyboard. As of 2020-05-01 those input drivers
will be masked for removal.

These drivers have been deprecated for many years, first by
xf86-input-evdev and then by xf86-input-libinput.

The only use for those drivers remain in deployments which intentionally
opt-out of using udev, as both evdev and libinput require udev during
runtime, however given that upstream has already removed the Linux
support from xf86-input-keyboard, future X11 releases will no longer
support xf86-input-keyboard on Linux rendering those installation
infeasible to use without udev.

In order to ensure frictionless upgrade path for future X11 releases, we
have decided to deprecate those drivers that are not in active use by
pretty much any installation of Gentoo.

No action is required from end-users who are already using libinput (or
evdev). To check which driver is in use, one can use

$ grep 'Using input driver' ~/.local/share/xorg/Xorg.0.log

for the systems running xorg-server as regular user (-suid
+elogind/+systemd) or by running

# grep 'Using input driver' /var/log/Xorg.0.log

for those running xorg-server as root.

If however neither libinput or evdev is in use, one should append
'libinput' to the INPUT_DEVICES variable inside /etc/portage/make.conf
while removing 'keyboard' and 'mouse' if present, then update @world
with new USE flags

# emerge -N @world

-- Piotr.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item about interoperability restrictions of >=net-p2p/syncthing-1.2.0

[Marek Szuba]

On 2019-07-18 11:12, Kristian Fiskerstrand wrote:

> Should we be more specific as to how not to enable it here? is it a
> USE-flag? does it require a package mask for newer versions if it is
> always used for the newer ones?

Good point, this should explicitly say "do not emerge new versions". My
own thoughts on the matter have been that since we are now in the
process of stabilising syncthing-1.1.4 (i.e. the latest version which
does not force the use of large blocks) and that I do not intend to push
the 1.2.0 ebuild until stabilisation has been concluded, it would be up
to individual users to mask newer versions should they insist on using
~arch ebuilds.

> Also cluster immediately made me think of server<>client relationship
> and this only affecting server side, which probably doesn't fit well
> with syncthing, but admittedly I don't use it so not familiar with the
> nomenclature.

I guess it is a bit subjective and/or based on one's experience, in my
case "cluster" brings to mind a cluster of peers. Anyway, this is the
wording from the official upstream statement so I would rather not
change it unless there is a good reason for it - like the
Gentoo-specific clarification you have suggested above.

PS. For the record, I have already published this news item (a couple of
hours ahead of schedule I am afraid, I didn't remember the exact time I
submitted the RFC) so I'll include your comments in the second revision.

-- 
MS

[gentoo-dev] Re: News item about interoperability restrictions of >=net-p2p/syncthing-1.2.0

[Kristian Fiskerstrand]

On 7/15/19 1:39 PM, Marek Szuba wrote:

> 2019-07-18-syncthing-update-incompatibility.en.txt
> 
> Title: Syncthing 1.2.0 and newer do not interoperate with 0.14.45 and older
> Author: Marek Szuba 
> Posted: 2019-07-18
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: net-p2p/syncthing
> 
> Starting with version 1.2.0, Syncthing always uses large, variable-sized,
> blocks to index and transfer files larger than 256 MiB [1]. Syncthing
> version 0.14.45 and older will initially appear to accept files scanned
> with large blocks, but will later panic during some internal file
> operations. Do NOT enable large blocks in clusters with devices still
> on v0.14.45 or older, 

Should we be more specific as to how not to enable it here? is it a
USE-flag? does it require a package mask for newer versions if it is
always used for the newer ones?

Also cluster immediately made me think of server<>client relationship
and this only affecting server side, which probably doesn't fit well
with syncthing, but admittedly I don't use it so not familiar with the
nomenclature.

> e.g. Debian Stretch servers using official packages.
> 
> [1] https://docs.syncthing.net/advanced/folder-uselargeblocks.html


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item for review: Change of ACCEPT_LICENSE default (v3)

[Aaron Bauman]

On Thu, May 16, 2019 at 10:45:02AM +0200, Ulrich Mueller wrote:
> Another iteration, due to an upcoming restructuring of the
> linux-firmware package. Only change in v3 is the second line in the
> package.license file which now contains the @BINARY-REDISTRIBUTABLE
> group instead of individual licenses.
> 
> Current plan is that this will go live on next Sunday, 2019-05-19.
> 
> 
> Title: Change of ACCEPT_LICENSE default
> Author: Ulrich Müller 
> Posted: 2019-05-19
> Revision: 1
> News-Item-Format: 2.0
> 
> The default set of accepted licenses has been changed [1,2] to:
> 
>ACCEPT_LICENSE="-* @FREE"
> 
> This means that by default only free software and documentation
> will be installable. The "FREE" license group is defined in the
> profiles/license_groups file in the Gentoo repository. It contains
> licenses that are explicitly approved by the Free Software Foundation,
> the Open Source Initiative, or that follow the Free Software
> Definition.
> 
> The system wide default for the accepted licenses is controlled by
> the ACCEPT_LICENSE variable in /etc/portage/make.conf, or it can be
> specified on a per-package basis in /etc/portage/package.license.
> 
> For example, to allow the app-arch/unrar and sys-kernel/linux-firmware
> packages to be installed, the following lines would have to be added
> to /etc/portage/package.license:
> 
>app-arch/unrar unRAR
>sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
> 
> If you want to revert to the previous default, add the following line
> to /etc/portage/make.conf:
> 
>ACCEPT_LICENSE="* -@EULA"
> 
> This will permit all licenses, except End User License Agreements that
> require reading and signing an acceptance agreement. Note that this
> will also accept non-free software and documentation.
> 
> See GLEP 23 [3] as well as the make.conf(5) and portage(5) man pages
> for the detailed syntax of the ACCEPT_LICENSE variable. Further
> information about licenses can be found in the Gentoo Handbook [4]
> and on the license groups wiki page [5].
> 
> [1] https://projects.gentoo.org/council/meeting-logs/20190210-summary.txt
> [2] https://bugs.gentoo.org/676248
> [3] https://www.gentoo.org/glep/glep-0023.html
> [4] https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage#Licenses
> [5] https://wiki.gentoo.org/wiki/License_groups

lgtm

-- 
Cheers,
Aaron


signature.asc
Description: PGP signature

[gentoo-dev] Re: News item for review: Change of ACCEPT_LICENSE default (v3)

[Ulrich Mueller]

Another iteration, due to an upcoming restructuring of the
linux-firmware package. Only change in v3 is the second line in the
package.license file which now contains the @BINARY-REDISTRIBUTABLE
group instead of individual licenses.

Current plan is that this will go live on next Sunday, 2019-05-19.


Title: Change of ACCEPT_LICENSE default
Author: Ulrich Müller 
Posted: 2019-05-19
Revision: 1
News-Item-Format: 2.0

The default set of accepted licenses has been changed [1,2] to:

   ACCEPT_LICENSE="-* @FREE"

This means that by default only free software and documentation
will be installable. The "FREE" license group is defined in the
profiles/license_groups file in the Gentoo repository. It contains
licenses that are explicitly approved by the Free Software Foundation,
the Open Source Initiative, or that follow the Free Software
Definition.

The system wide default for the accepted licenses is controlled by
the ACCEPT_LICENSE variable in /etc/portage/make.conf, or it can be
specified on a per-package basis in /etc/portage/package.license.

For example, to allow the app-arch/unrar and sys-kernel/linux-firmware
packages to be installed, the following lines would have to be added
to /etc/portage/package.license:

   app-arch/unrar unRAR
   sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

If you want to revert to the previous default, add the following line
to /etc/portage/make.conf:

   ACCEPT_LICENSE="* -@EULA"

This will permit all licenses, except End User License Agreements that
require reading and signing an acceptance agreement. Note that this
will also accept non-free software and documentation.

See GLEP 23 [3] as well as the make.conf(5) and portage(5) man pages
for the detailed syntax of the ACCEPT_LICENSE variable. Further
information about licenses can be found in the Gentoo Handbook [4]
and on the license groups wiki page [5].

[1] https://projects.gentoo.org/council/meeting-logs/20190210-summary.txt
[2] https://bugs.gentoo.org/676248
[3] https://www.gentoo.org/glep/glep-0023.html
[4] https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage#Licenses
[5] https://wiki.gentoo.org/wiki/License_groups


signature.asc
Description: PGP signature

[gentoo-dev] Re: News item for review: Change of ACCEPT_LICENSE default (v2)

[Ulrich Mueller]

Thanks for the feedback on IRC and mailing list. Find v2 below.

Ulrich


Title: Change of ACCEPT_LICENSE default
Author: Ulrich Müller 
Posted: 2019-04-XX
Revision: 1
News-Item-Format: 2.0

The default set of accepted licenses has been changed [1,2] to:

   ACCEPT_LICENSE="-* @FREE"

This means that by default only free software and documentation
will be installable. The "FREE" license group is defined in the
profiles/license_groups file in the Gentoo repository. It contains
licenses that are explicitly approved by the Free Software Foundation,
the Open Source Initiative, or that follow the Free Software
Definition.

The system wide default for the accepted licenses is controlled by
the ACCEPT_LICENSE variable in /etc/portage/make.conf, or it can be
specified on a per-package basis in /etc/portage/package.license.

For example, to allow the app-arch/unrar and sys-kernel/linux-firmware
packages to be installed, the following lines would have to be added
to /etc/portage/package.license:

   app-arch/unrar unRAR
   sys-kernel/linux-firmware linux-firmware no-source-code

If you want to revert to the previous default, add the following line
to /etc/portage/make.conf:

   ACCEPT_LICENSE="* -@EULA"

This will permit all licenses, except End User License Agreements that
require reading and signing an acceptance agreement. Note that this
will also accept non-free software and documentation.

See GLEP 23 [3] as well as the make.conf(5) and portage(5) man pages
for the detailed syntax of the ACCEPT_LICENSE variable. Further
information about licenses can be found in the Gentoo Handbook [4]
and on the license groups wiki page [5].

[1] https://projects.gentoo.org/council/meeting-logs/20190210-summary.txt
[2] https://bugs.gentoo.org/676248
[3] https://www.gentoo.org/glep/glep-0023.html
[4] https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage#Licenses
[5] https://wiki.gentoo.org/wiki/License_groups


signature.asc
Description: PGP signature

[gentoo-dev] Re: News item review v3: Migration required for OpenSSH with LDAP

[Thomas Deutschmann]

On 2018-08-07 01:44, Thomas Deutschmann wrote:
> Title: Migration required for OpenSSH with LDAP
> Author: Thomas Deutschmann 
> Posted: 2018-08-xx
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: net-misc/openssh
> 
> If your sshd authenticates against LDAP, you have to migrate your
> current setup to a new one using sshd's "AuthorizedKeysCommand" option and
> a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey or
> sys-auth/sakcl because beginning with net-misc/openssh-7.7_p1, OpenSSH-LPK
> patch set is deprecated and no longer applies.
> 
> We have created a short migration guide in the Wiki [1] for more details.
> 
> 
> [1] https://wiki.gentoo.org/wiki/SSH/LDAP_migration

Committed.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item review v3: Migration required for OpenSSH with LDAP

[Thomas Deutschmann]

Changes:
 * Incorporated suggestions by Peter Stuge
 * Package sys-auth/sakcl added
 * Last sentence corrected

---
Title: Migration required for OpenSSH with LDAP
Author: Thomas Deutschmann 
Posted: 2018-08-xx
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: net-misc/openssh

If your sshd authenticates against LDAP, you have to migrate your
current setup to a new one using sshd's "AuthorizedKeysCommand" option and
a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey or
sys-auth/sakcl because beginning with net-misc/openssh-7.7_p1, OpenSSH-LPK
patch set is deprecated and no longer applies.

We have created a short migration guide in the Wiki [1] for more details.


[1] https://wiki.gentoo.org/wiki/SSH/LDAP_migration
---


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item review v2: Migration required for OpenSSH with LDAP

[Thomas Deutschmann]

Changes:
 * Incorporated suggestions by Peter Stuge
 * Package sys-auth/sakcl added

---
Title: Migration required for OpenSSH with LDAP
Author: Thomas Deutschmann 
Posted: 2018-08-xx
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: net-misc/openssh

If your sshd authenticates against LDAP, you have to migrate your
current setup to a new one using sshd's "AuthorizedKeysCommand" option and
a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey or
sys-auth/sakcl because beginning with net-misc/openssh-7.7_p1, deprecated
OpenSSH-LPK patch set is deprecated and no longer applies.

We have created a short migration guide in the Wiki [1] for more details.


[1] https://wiki.gentoo.org/wiki/SSH/LDAP_migration
---


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

[Zac Medico]

On 03/11/2018 09:58 PM, M. J. Everitt wrote:
> On 12/03/18 04:53, Duncan wrote:
>> Zac Medico posted on Sun, 11 Mar 2018 19:57:31 -0700 as excerpted:
>>
>>> I really don't want to spend a lot of time making revisions, and I think
>>> "unstable" communicates well enough in this case.
>> Very well then.  With robbat2's already accepted first paragraph changes 
>> it's acceptable as-is.
>>
>> Thanks.  You put an awful lot of work into portage, and I'm sure I'm not 
>> the only one who's thankful there's a steady hand at the portage wheel, 
>> even if it doesn't always come thru.  Your efforts certainly make the 
>> gentoo experience a better one! =:^)
>>
> +1 to that .. particularly through choppy waters lately .. keep up the
> good work!

You're very welcome. Thanks for your praise!
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

[M. J. Everitt]

On 12/03/18 04:53, Duncan wrote:
> Zac Medico posted on Sun, 11 Mar 2018 19:57:31 -0700 as excerpted:
>
>> I really don't want to spend a lot of time making revisions, and I think
>> "unstable" communicates well enough in this case.
> Very well then.  With robbat2's already accepted first paragraph changes 
> it's acceptable as-is.
>
> Thanks.  You put an awful lot of work into portage, and I'm sure I'm not 
> the only one who's thankful there's a steady hand at the portage wheel, 
> even if it doesn't always come thru.  Your efforts certainly make the 
> gentoo experience a better one! =:^)
>
+1 to that .. particularly through choppy waters lately .. keep up the
good work!



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

[Duncan]

Zac Medico posted on Sun, 11 Mar 2018 19:57:31 -0700 as excerpted:

> I really don't want to spend a lot of time making revisions, and I think
> "unstable" communicates well enough in this case.

Very well then.  With robbat2's already accepted first paragraph changes 
it's acceptable as-is.

Thanks.  You put an awful lot of work into portage, and I'm sure I'm not 
the only one who's thankful there's a steady hand at the portage wheel, 
even if it doesn't always come thru.  Your efforts certainly make the 
gentoo experience a better one! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

[Zac Medico]

On 03/10/2018 05:38 PM, Duncan wrote:
> Zac Medico posted on Sat, 10 Mar 2018 15:16:29 -0800 as excerpted:
> 
>> Changes:
>>   * First paragraph rewritten by Robin Johnson 
>>   * Fixes spelling of 'following' reported by Michael Everitt
>>
>>
>> Title: Portage rsync tree verification unstable
>> Author: Zac Medico 
>> Posted: 2018-03-13
>> Revision: 1
>> News-Item-Format: 2.0
>> Display-If-Installed: sys-apps/portage
>>
>> Portage rsync tree verification is being temporarily turned off by
>> default, starting with sys-apps/portage-2.3.24. This permits
>> stabilization of sys-apps/portage-2.3.24 while still working on bugs
>> relating to tree verification [1]: deadlocks [2] & key fetching [3].
> 
>> [...]
> 
> With robbat2's first paragraph rewrite the effect isn't quite as bad
> as that of the first draft, but the title still refers to "unstable",
> which in addition to the intended package-stability meaning, has a
> number of more severe and thus unnecessarily alarming meanings not
> intended here.
> 
> FWIW, being security minded and knowing verification related to
> security, my own first thought was an app instability due to a
> potentially exploitable buffer-overflow... in code dealing with
> verification and thus potentially remotely triggerable during
> verification itself, definitely more alarming than intended!
> 
> Thankfully robbat2's rewrite clarifies in the body now, but
> I still think the title remains overly alarming.
> 
> Maybe "... remains unstable" or "not yet stable", as in:

Well, "unstable" sounds alarming when used to describe a person's
emotional state, but it then context of software I think it's less
alarming. I've found some discussion here:

https://english.stackexchange.com/questions/8351/what-s-the-etymology-of-the-word-unstable-in-the-context-of-software

> Title: Portage rsync tree verification not yet stable
> 
> Or better, refer to the FEATURE flag "rsync-verify" in the title,
> so it's clear it's not a portage/emerge-executable instability,
> and clarify that it's the stable keyword, something like this
> (but might be too long, do those news item short title limits
> still apply?):
> 
> Title: Portage rsync-verify feature not yet stable-keyworded
> 
> Perhaps omit the -keyworded if that's too long:
> 
> Title: Portage rsync-verify feature not yet stable
> 
> Feel free to revise further...

I really don't want to spend a lot of time making revisions, and I think
"unstable" communicates well enough in this case.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

[Duncan]

Zac Medico posted on Sat, 10 Mar 2018 15:16:29 -0800 as excerpted:

> Changes:
>   * First paragraph rewritten by Robin Johnson 
>   * Fixes spelling of 'following' reported by Michael Everitt
> 
> 
> Title: Portage rsync tree verification unstable
> Author: Zac Medico 
> Posted: 2018-03-13
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-apps/portage
> 
> Portage rsync tree verification is being temporarily turned off by
> default, starting with sys-apps/portage-2.3.24. This permits
> stabilization of sys-apps/portage-2.3.24 while still working on bugs
> relating to tree verification [1]: deadlocks [2] & key fetching [3].

> [...]

With robbat2's first paragraph rewrite the effect isn't quite as bad
as that of the first draft, but the title still refers to "unstable",
which in addition to the intended package-stability meaning, has a
number of more severe and thus unnecessarily alarming meanings not
intended here.

FWIW, being security minded and knowing verification related to
security, my own first thought was an app instability due to a
potentially exploitable buffer-overflow... in code dealing with
verification and thus potentially remotely triggerable during
verification itself, definitely more alarming than intended!

Thankfully robbat2's rewrite clarifies in the body now, but
I still think the title remains overly alarming.

Maybe "... remains unstable" or "not yet stable", as in:

Title: Portage rsync tree verification not yet stable

Or better, refer to the FEATURE flag "rsync-verify" in the title,
so it's clear it's not a portage/emerge-executable instability,
and clarify that it's the stable keyword, something like this
(but might be too long, do those news item short title limits
still apply?):

Title: Portage rsync-verify feature not yet stable-keyworded

Perhaps omit the -keyworded if that's too long:

Title: Portage rsync-verify feature not yet stable

Feel free to revise further...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: [News item review] Portage rsync tree verification (v4)

[Duncan]

Michał Górny posted on Sun, 28 Jan 2018 09:58:37 +0100 as excerpted:

> The new verification is intended for users who are syncing via rsync.
> Verification mechanisms for other methods of sync will be provided in
> the future.
> 
> This does not affect users syncing using git and other methods.
> Appropriate verification mechanisms for them will be provided in the
> future.


Sorry I didn't catch this sooner.  Now we have a repeat.  Maybe combine 
the two paragraphs like this:

The new verification is intended for users who are syncing via rsync.  
Users syncing using git or other methods are not affected, and 
verification for them will be provided in the future.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: [News item review] Portage rsync tree verification (v3)

[Duncan]

Michał Górny posted on Sat, 27 Jan 2018 15:26:44 +0100 as excerpted:

> The new verification is intended for users who syncing via rsync.
> Verification mechanisms for other methods of sync will be provided in
> future.


s/in future/in the future/

Thanks for adding that paragraph.  It perfectly addresses the question I 
had about the original. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: [News item review] Portage rsync tree verification

[Duncan]

Michał Górny posted on Thu, 25 Jan 2018 11:04:27 +0100 as excerpted:

> Hi,
> 
> This one would be committed once new sys-apps/portage release is wrapped
> up and hits ~arch.
> 
> ---
> Title: Portage rsync tree verification

Might want to put a paragraph in there saying git sync users can ignore, 
or how they can get gpg signature verification as well if its possible. 
(Sufficient to just link it if it's more involved than a single 
paragraph, since this is primarily for rsync users.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: News Item: Portage Dynamic Deps

[Ulrich Mueller]

> On Wed, 24 Jan 2018, Martin Vaeth wrote:

> Ulrich Mueller  wrote:
>> "Runtime dependencies (RDEPEND). These must be installed and usable
>> before the results of an ebuild merging are treated as usable."
>> https://projects.gentoo.org/pms/6/pms.html#x1-770008.1
>> 
>> IMHO this implies that the dependencies at merge time are the
>> relevant ones

> IMHO this specifies what is relevant when an emerge merging happens.
> Nothing more, nothing less.

Exactly. RDEPEND is to be evaluated at the time before the package is
merged. For PDEPEND it is even clearer: "These must be installed at
some point before the package manager finishes the batch of installs."

> _If_ one would be willing to interpret it to have a meaning also
> _after_ the emerge, then of course the RDEPEND in PMS can refer to
> the only value which is specified in PMS, i.e. that stored in the
> ebuild

... at the time when the package was merged. You cannot rely on
anything else, because the ebuild may be gone in the meantime.

> (and not in any database which is explicitly not specified by PMS).
> In other words: _If_ one puts any unsaid interpretation into that
> sentence, then this can only be dynamic deps.

No. The only thing that PMS doesn't specify is the special format of
the VDB. However, the spec says that variables must keep their values
between phase functions, which includes pkg_prerm() and pkg_postrm().
By this, *some* sort of storage mechanism must exist.

Ulrich


pgpgC4EFl2XHz.pgp
Description: PGP signature

[gentoo-dev] Re: News Item: Portage Dynamic Deps

[Martin Vaeth]

Ulrich Mueller  wrote:
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --pgp+signed++Zg8D+I6sgRUw0D
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
>> On Wed, 24 Jan 2018, Martin Vaeth wrote:
>
>> Rich Freeman  wrote:
>>> 
>>> It would already be broken on any PMS-compliant package manager
>
>> No, it is solely the interpretation of the package manager.
>> PMS does not specify what information is stored in /var/db
>> or how that information is used.
>
> "Runtime dependencies (RDEPEND). These must be installed and usable
> before the results of an ebuild merging are treated as usable."
> https://projects.gentoo.org/pms/6/pms.html#x1-770008.1
>
> IMHO this implies that the dependencies at merge time are the relevant
> ones

IMHO this specifies what is relevant when an emerge merging happens.
Nothing more, nothing less.
_If_ one would be willing to interpret it to have a meaning also _after_
the emerge, then of course the RDEPEND in PMS can refer to the only value
which is specified in PMS, i.e. that stored in the ebuild (and not in
any database which is explicitly not specified by PMS).
In other words: _If_ one puts any unsaid interpretation into that
sentence, then this can only be dynamic deps.

[gentoo-dev] Re: News Item: Portage Dynamic Deps

[Ulrich Mueller]

> On Wed, 24 Jan 2018, Martin Vaeth wrote:

> Rich Freeman  wrote:
>> 
>> It would already be broken on any PMS-compliant package manager

> No, it is solely the interpretation of the package manager.
> PMS does not specify what information is stored in /var/db
> or how that information is used.

"Runtime dependencies (RDEPEND). These must be installed and usable
before the results of an ebuild merging are treated as usable."
https://projects.gentoo.org/pms/6/pms.html#x1-770008.1

IMHO this implies that the dependencies at merge time are the relevant
ones, but not any later changes to the ebuild.

Ulrich


pgpBFJdeNNmzj.pgp
Description: PGP signature

[gentoo-dev] Re: News Item: Portage Dynamic Deps

[Martin Vaeth]

Rich Freeman  wrote:
>
> It would already be broken on any PMS-compliant package manager

No, it is solely the interpretation of the package manager.
PMS does not specify what information is stored in /var/db
or how that information is used.

Re: [gentoo-dev] Re: News Item: Portage Dynamic Deps

[Rich Freeman]

On Tue, Jan 23, 2018 at 8:40 AM, Michael Palimaka  wrote:
> On 01/24/2018 12:15 AM, Michael Orlitzky wrote:
>> On 01/23/2018 07:40 AM, Michael Palimaka wrote:

 Did you come up with a solution how to handle eclass-generated dependency
 changes then?
>>>
>>> No.
>>>
>>> Bug #641346 was filed for clarification about this, but it just got
>>> closed without answering the question or consulting anyone.
>>>
>>> Now, every time we want to make a minor change we need to revbump half
>>> the tree due to a change that has been forced mostly by people not
>>> actually involved in any actual ebuild maintenance.
>>
>> You could always set "--dynamic-deps y" on your machine, and ignore the
>> breakage caused to end users (i.e. the situation last week).
>
> You mean the breakage caused by changing default options without any
> consultation or notification?
>

It would already be broken on any PMS-compliant package manager I
imagine.  The goal is to make the repo and PMS align so that we're not
depending on non-PMS behavior.  Either our ebuild policies ought to
change, or PMS ought to change.  It is dumb to publish a specification
and then deliberately do things that break software that follows that
specification.

-- 
Rich

[gentoo-dev] Re: News Item: Portage Dynamic Deps

[Michael Palimaka]

On 01/24/2018 12:15 AM, Michael Orlitzky wrote:
> On 01/23/2018 07:40 AM, Michael Palimaka wrote:
>>>
>>> Did you come up with a solution how to handle eclass-generated dependency 
>>> changes then?
>>
>> No.
>>
>> Bug #641346 was filed for clarification about this, but it just got
>> closed without answering the question or consulting anyone.
>>
>> Now, every time we want to make a minor change we need to revbump half
>> the tree due to a change that has been forced mostly by people not
>> actually involved in any actual ebuild maintenance.
> 
> You could always set "--dynamic-deps y" on your machine, and ignore the
> breakage caused to end users (i.e. the situation last week).

You mean the breakage caused by changing default options without any
consultation or notification?

Re: [gentoo-dev] Re: News Item: Portage Dynamic Deps

[Michael Orlitzky]

On 01/23/2018 07:40 AM, Michael Palimaka wrote:
>>
>> Did you come up with a solution how to handle eclass-generated dependency 
>> changes then?
> 
> No.
> 
> Bug #641346 was filed for clarification about this, but it just got
> closed without answering the question or consulting anyone.
> 
> Now, every time we want to make a minor change we need to revbump half
> the tree due to a change that has been forced mostly by people not
> actually involved in any actual ebuild maintenance.

You could always set "--dynamic-deps y" on your machine, and ignore the
breakage caused to end users (i.e. the situation last week).

Re: [gentoo-dev] Re: News Item: Portage Dynamic Deps

[Rich Freeman]

On Tue, Jan 23, 2018 at 7:40 AM, Michael Palimaka  wrote:
> On 01/22/2018 09:28 PM, Andreas K. Huettel wrote:
>> Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico:
>>>
>>> According to Gentoo policy, future ebuild dependency changes need to be
>>> accompanied by a revision bump in order to trigger rebuilds for users.
>>> Therefore, you should only need to use --changed-deps=y for a single
>>> deep @world update. After that, if you encounter installed packages with
>>> outdated dependencies in a future deep @world update, then you should
>>> report it as a bug.
>>
>> Did you come up with a solution how to handle eclass-generated dependency
>> changes then?
>
> No.
>
> Bug #641346 was filed for clarification about this, but it just got
> closed without answering the question or consulting anyone.

>From the bug: "I don't see the need for anything further before the
default behavior can be changed in portage, I'm all for it matching
PMS behavior."  (More details in the comment.)

The question was "I would like to ask Council to state more precisely
what needs to be specifically documented before we can stop enabling
dynamic-deps in Portage by default."

So, the answer to the question appears to be "nothing."

That might not be an answer that you like, but it is an answer.  I
can't vouch for who was or wasn't consulted before it was given.

-- 
Rich

[gentoo-dev] Re: News Item: Portage Dynamic Deps

[Michael Palimaka]

On 01/22/2018 09:28 PM, Andreas K. Huettel wrote:
> Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico:
>>
>> According to Gentoo policy, future ebuild dependency changes need to be
>> accompanied by a revision bump in order to trigger rebuilds for users.
>> Therefore, you should only need to use --changed-deps=y for a single
>> deep @world update. After that, if you encounter installed packages with
>> outdated dependencies in a future deep @world update, then you should
>> report it as a bug.
> 
> Did you come up with a solution how to handle eclass-generated dependency 
> changes then?

No.

Bug #641346 was filed for clarification about this, but it just got
closed without answering the question or consulting anyone.

Now, every time we want to make a minor change we need to revbump half
the tree due to a change that has been forced mostly by people not
actually involved in any actual ebuild maintenance.

[gentoo-dev] Re: News Item: GnuCash 2.7+ Breaking Change

[Duncan]

Kristian Fiskerstrand posted on Tue, 16 Jan 2018 15:58:11 +0100 as
excerpted:

> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
>> Given the situation, we have a choice: Remove GnuCash altogether, or
>> press ahead with recommending a version upstream considers unstable.
> 
> Or 3, discuss with upstream to see if they can release an updated
> version as stable branch.

This reminds me very much of the long-time stability situation with 
grub-0.9x vs. 1.9x.  Upstream insisted 0.9x was unsupported, and indeed, 
had abandoned it, such that it was the distros carrying upstream-
unapproved patches, but at the same time, pre-2.0 as 1.9x was still very 
much development-only and not ready for prime-time, according to 
upstream.  Just what were distros and users /supposed/ to do?

Both that and this gnucash thing are bad situations all around, but 
perhaps some lessons can be had.  And agreed that surely the first must 
be to /just/ /ask/ upstream whether they can release something stable 
that's at least based on something still getting maintenance, security 
and otherwise.  Then go from there.  Maybe they'll refuse and we'll have 
to move ahead with the new version regardless of upstream's wishes, but 
we'll never know if we don't ask.

(Of course it can go the other way too, upstream insisting the new 
version is stable even when it's still broken for normal users every 
which way to Sunday.  The kde3/kde4 transition is a prime example of 
that.  I honestly don't know which is worse, but the obvious ideal is a 
sane upstream that doesn't veer to either extreme, or lacking that, at 
least cooperates and provides support when a new at least /semi-/stable 
release is needed as the old is just outdated and broken, security or 
otherwise.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: News item review: python-exec 2.3 reclaims python* symlinks

[Michael Palimaka]

On 21/01/17 20:49, Michał Górny wrote:
> Please review the following news item. It was requested by users.
> Preferably I'd like to commit it today.
> 
>  --
> 
> Title: python-exec 2.3 reclaims python* symlinks
> Author: Michał Górny 
> Content-Type: text/plain
> Posted: 2017-01-21
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed:  Display-If-Installed:  
> The new versions of python-exec (2.3 and newer) are reclaiming multiple
> Python-related symlinks in /usr/bin, most notably /usr/bin/python*. This
> may result in your package manager reporting file collisions.
> 
> The respective symlinks were previously either unowned and created
> dynamically by app-eselect/eselect-python, or installed by it. From now
> on, all Python-related symlinks are installed and handled
> by python-exec. This ensures that they respect the python-exec
> configuration files and variables consistently with regular Python
> packages, and improves their reliability.
> 
> If you are using FEATURES=collision-protect, Portage will reject
> the upgrade. If this is the case, please temporarily switch to
> FEATURES=protect-owned for the upgrade.
> 
> If you are using FEATURES=protect-owned, Portage will verbosely warn
> about the file collisions but will proceed with the upgrade once
> determining no replaced files are owned. Please disregard the warning.
> 
> The potentially colliding files are:
> 
>  * /usr/bin/2to3
>  * /usr/bin/pydoc
>  * /usr/bin/python
>  * /usr/bin/python2
>  * /usr/bin/python3
>  * /usr/bin/python-config
> 
> For more information on python-exec, please see:
> https://wiki.gentoo.org/wiki/Project:Python/python-exec
> 
> 

Thanks for writing this, looks good.

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

On Mon, 1 Aug 2016 14:08:57 +0300 Andrew Savchenko wrote:
> Hi,
> 
> On Wed, 20 Jul 2016 13:13:49 -0400 NP-Hardass wrote:
> > This is the first draft of a news item describing a packaging change for
> > OpenAFS so that we no longer require the DEBUG_RODATA be turned off.
> 
> This is a second try with rewording of the first paragraph, since
> it was suggested that it is a bit awkward.
> 
> Title: OpenAFS no longer needs kernel option DEBUG_RODATA
> Author: NP-Hardass 
> Author: Andrew Savchenko 
> Content-Type: text/plain
> Posted: 2016-07-23
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
> Display-If-Keyword: amd64
> Display-If-Keyword: ~amd64-linux
> Display-If-Keyword: ~sparc
> Display-If-Keyword: x86
> Display-If-Keyword: ~x86-linux
> 
> As a result of bug #127084 [1], it was determined that OpenAFS's
> kernel module required that the kernel's data structures be
> read-write (CONFIG_DEBUG_RODATA=n). With recent OpenAFS versions
> this limitation is no longer required. We tested the latest version
> of OpenAFS with Linux kernels from 3.4 till 4.6, and determined that
> OpenAFS kernel module works fine with CONFIG_DEBUG_RODATA=y.
> 
> Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no
> longer forced in the ebuild. Considering the security implications
> of having CONFIG_DEBUG_RODATA turned off, it is highly advised that
> you adjust your kernel config accordingly.  Please note that the
> default setting for CONFIG_DEBUG_RODATA is "y" and unless you have
> another reason for keeping it disabled, we highly recommend that
> you re-enable CONFIG_DEBUG_RODATA.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=127084

No comments for a week => submitted.

Best regards,
Andrew Savchenko


pgpZO8cqeP0uo.pgp
Description: PGP signature

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

Hi,

On Wed, 20 Jul 2016 13:13:49 -0400 NP-Hardass wrote:
> This is the first draft of a news item describing a packaging change for
> OpenAFS so that we no longer require the DEBUG_RODATA be turned off.

This is a second try with rewording of the first paragraph, since
it was suggested that it is a bit awkward.

Title: OpenAFS no longer needs kernel option DEBUG_RODATA
Author: NP-Hardass 
Author: Andrew Savchenko 
Content-Type: text/plain
Posted: 2016-07-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
Display-If-Keyword: amd64
Display-If-Keyword: ~amd64-linux
Display-If-Keyword: ~sparc
Display-If-Keyword: x86
Display-If-Keyword: ~x86-linux

As a result of bug #127084 [1], it was determined that OpenAFS's
kernel module required that the kernel's data structures be
read-write (CONFIG_DEBUG_RODATA=n). With recent OpenAFS versions
this limitation is no longer required. We tested the latest version
of OpenAFS with Linux kernels from 3.4 till 4.6, and determined that
OpenAFS kernel module works fine with CONFIG_DEBUG_RODATA=y.

Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no
longer forced in the ebuild. Considering the security implications
of having CONFIG_DEBUG_RODATA turned off, it is highly advised that
you adjust your kernel config accordingly.  Please note that the
default setting for CONFIG_DEBUG_RODATA is "y" and unless you have
another reason for keeping it disabled, we highly recommend that
you re-enable CONFIG_DEBUG_RODATA.

[1] https://bugs.gentoo.org/show_bug.cgi?id=127084

Best regards,
Andrew Savchenko


pgptMnUs4dLsk.pgp
Description: PGP signature

Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Ciaran McCreesh]

On Sun, 24 Jul 2016 10:05:23 +0300
Andrew Savchenko  wrote:
> I agree with you, but REPLACING_VERSIONS has nothing to do with
> such recovery.

Yes, it does. Specifically, what we want is for developers to get into
the habit of writing safe, clean code, even if they think they don't
need to care about it in some particular situation because they can't
think of how it would go wrong. It's the same as getting into the habit
of sticking || die on things.

> 1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery
> from hardware crashes forked well long before.

Before this, you could use has_version in pkg_*, and it would tell you
the *old* version of the package that was installed. The phase order
changed a while ago, and broke this, so REPLACING_VERSIONS was the
replacement.

Again, the situation is complicated, there's a lot of messy history
behind this, and if you don't know it all, just do what the spec says
and stop wasting everyone's time by arguing.

> 2) If you will look into the tree, in the absolute majority of cases
> REPLACING_VERSIONS is being used to determine whether informational
> messages should be shown to a user or not. Such messages usually
> include some upgrade hints or howtos; and REPLACING_VERSIONS check
> is required to avoid showing them to unaffected users. It has
> absolutely nothing to do with the error recovery done by PM itself.

Don't get into the habit of writing code that makes unnecessary
assumptions that will come back and screw users over in unexpected
situations. It's easy to do this the right way, so at this point I can
only conclude that you're persisting in trying to do it wrong just to
avoid admitting that you made a mistake from ignorance. It's OK to be
wrong sometimes (and this is why code review exists), but it's not OK
to continue to argue that you were right out of stubbornness.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

Hi,

On Sun, 24 Jul 2016 03:00:40 + (UTC) Duncan wrote:
> Andrew Savchenko posted on Sun, 24 Jul 2016 00:30:39 +0300 as excerpted:
> 
> > Do we ever had such case like multiple versions of the same
> > single-slotted package installed or recorded as installed in the real
> > world? I'm not sure even in this, but I may assume that it may happen
> > one day.
> > 
> > Do we have any proof that PM can recover from such situation,
> > where VDB is a mess and installed files can also be a mess? I'm not sure
> > in this at all.
> > 
> > Do we have any test suits for portage (as the most popular PM
> > implementation) for such cases? I doubt this, I can find none. I'm not
> > sure if such tests are implemented in other PM test suits too.
> 
> Think of how a package is upgraded (by portage, I don't know enough about 
> the others to describe the process for them).  The package is built, then 
> installed to a temporary location, then "qmerged" from the temporary 
> location to the live filesystem, replacing the previous version's files 
> and recording the new one in the installed-package database, then the old 
> version is unmerged and its record removed from the installed-package 
> database.
> 
> What happens if there's a crash in either the qmerge or old-version 
> unmerge steps?
> 
> Right, now there's parts of two versions in the installed-package 
> database, and who knows what files from each on the live filesystem.
> 
> I'm not a portage dev so won't comment on the test suite angle, but 
> portage has been able to handle this with the user simply redoing the 
> upgrade (whether from binpkg or full rebuild) for many years now (singe 
> before I became a gentooer in 2004, I know as I had some faulty hardware 
> at the time and regularly crashed during build and installs, which was 
> likely before REPLACING_VERSIONS was a thing), and given the number of 
> installations out there and the stress of parallel-building some packages 
> while others are installing, the code to handle this is GOING to get 
> regularly tested.

I agree with you, but REPLACING_VERSIONS has nothing to do with
such recovery.

1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery
from hardware crashes forked well long before.

2) If you will look into the tree, in the absolute majority of cases
REPLACING_VERSIONS is being used to determine whether informational
messages should be shown to a user or not. Such messages usually
include some upgrade hints or howtos; and REPLACING_VERSIONS check
is required to avoid showing them to unaffected users. It has
absolutely nothing to do with the error recovery done by PM itself.

3) I also had a broken hardware (faulty memory) for a few years and
portage and other software recovered quite fine despite numerous
segfaults. So I have the experience :)

Best regards,
Andrew Savchenko


pgpUv30f2tv3O.pgp
Description: PGP signature

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Duncan]

Andreas K. Huettel posted on Sun, 24 Jul 2016 00:04:53 +0200 as excerpted:

> 1) If a package only ever had one slot, it cannot ever have two versions
> installed at the same time. That guarantee (of only ever one slot) can
> be given for the portage tree (sic). Obviously it doesn't work for
> overlays,
> but there are many things we don't care about for overlays. [A]

This is incorrect.  It arguably /might/ be correct if systems were 
guaranteed never to crash in the qmerge or old-version unmerge phases, 
but... the package manager must be able to deal with and recover from 
such crashes, and portage has done so for well over a decade, at least.  

(When I became a gentooer in 2004 I had faulty hardware, and the system 
would regularly crash during merges, sometimes repeatedly.  When I 
rebooted, all I had to do was restart the merge, and portage could pick 
up the pieces and deal with it, even back then.)

> 2) If a package manager leaves two versions of a non-slotted package
> "installed" somehow, that package manager is fundamentally broken and
> its author should forever refrain from specifying anything. It's not our
> job to work around Paludis failure modes. [B]

Not if it's the hardware that's broken, not the PM.  A good PM must be 
able to recover from the crash, and sort things out from it on a second, 
or third or tenth, attempt to actually get the upgrade done, this time 
/without/ crashing part way thru.

And broken ebuilds that can't deal with the situation don't help matters 
at all. =:^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Duncan]

Andrew Savchenko posted on Sun, 24 Jul 2016 00:30:39 +0300 as excerpted:

> Do we ever had such case like multiple versions of the same
> single-slotted package installed or recorded as installed in the real
> world? I'm not sure even in this, but I may assume that it may happen
> one day.
> 
> Do we have any proof that PM can recover from such situation,
> where VDB is a mess and installed files can also be a mess? I'm not sure
> in this at all.
> 
> Do we have any test suits for portage (as the most popular PM
> implementation) for such cases? I doubt this, I can find none. I'm not
> sure if such tests are implemented in other PM test suits too.

Think of how a package is upgraded (by portage, I don't know enough about 
the others to describe the process for them).  The package is built, then 
installed to a temporary location, then "qmerged" from the temporary 
location to the live filesystem, replacing the previous version's files 
and recording the new one in the installed-package database, then the old 
version is unmerged and its record removed from the installed-package 
database.

What happens if there's a crash in either the qmerge or old-version 
unmerge steps?

Right, now there's parts of two versions in the installed-package 
database, and who knows what files from each on the live filesystem.

I'm not a portage dev so won't comment on the test suite angle, but 
portage has been able to handle this with the user simply redoing the 
upgrade (whether from binpkg or full rebuild) for many years now (singe 
before I became a gentooer in 2004, I know as I had some faulty hardware 
at the time and regularly crashed during build and installs, which was 
likely before REPLACING_VERSIONS was a thing), and given the number of 
installations out there and the stress of parallel-building some packages 
while others are installing, the code to handle this is GOING to get 
regularly tested.

This needs to continue to work, thus the PMS rules, and ebuilds that are 
unprepared to deal with it aren't going to help.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Jonathan Callen]

On 07/21/2016 01:12 AM, Michał Górny wrote:
> On Thu, 21 Jul 2016 00:22:36 +0300
> Andrew Savchenko  wrote:
> 
>> On Wed, 20 Jul 2016 15:12:01 -0400 Michael Orlitzky wrote:
>>> On 07/20/2016 01:13 PM, NP-Hardass wrote:  
 Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2

 ...

 Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
 forced in the ebuild.   
>>>
>>> Might not that version bound might backfire if someone upgrades before
>>> reading the news? People who pull from git often don't necessarily get
>>> the news in a timely fashion.
>>>
>>> Would it be simpler to ewarn in the ebuilds (for e.g. a year) if
>>> DEBUG_RODATA=n?  
>>
>> We already do this in openafs-kernel-1.6.18.2.ebuild:
>>
>> if use kernel_linux && [[ ${REPLACING_VERSIONS} < "1.6.18.2" ]]; then
> 
> Few important QA notes:
> 
> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
> false,
> 
> 2. REPLACING_VERSIONS can have more than one value,
> 
> 3. Finally, '' < 1.6.18.2 gives true, so it is also printed for initial
> install.
> 

If you want to do a package version comparison, you probably want to use
the function version_is_at_least() in versionator.eclass.  The primary
version comparison function in that eclass was written to be a complete
implementation of the version comparison algorithm in PMS.  Maybe
eventually we'll get a version comparison function in PMS so we won't
have to resort to the wonderfully complex bash functions in that eclass :).

-- 
Jonathan Callen



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item: upgrading to Plasma 5

[Nikos Chantziaras]

On 03/04/16 20:34, Michael Palimaka wrote:

Hi,

KDE team intends to stabilise Plasma 5 shortly, so please review the
accompanying news items.


There's many packages that warn me about not having KDE installed when 
upgrading to Plasma 5. It's in a quite accusatory tone even:


  WARNING! Your system configuration does not contain
  "kde-apps/kdebase-runtime-meta".
  With this setting you are unsupported by KDE team.
  All missing features you report for misc packages will be
  probably ignored or closed as INVALID.

I think should be fixed, or if not then at least be addressed in the 
news item because I find the warning very confusing.

Re: [gentoo-dev] Re: News item: upgrading to Plasma 5

[M. J. Everitt]

On 07/04/16 01:45, Jonathan Callen wrote:
> On 04/06/2016 07:46 AM, M. J. Everitt wrote:
>
> > In the event you're not explicitly using a desktop or KDE desktop
> > profile, can you provide a summary of the changes that should be
> > made manually when switching the the kde-plasma/* ebuilds please? I
> > can probably handle a display manager change over a network of
> > systems, but making a sensible transition to Plasma5 over many
> > systems could be a trial if a small step is overlooked Thanks!
>
> > Michael/veremit.
>
>
>
> The list of things that the plasma profiles add to the system can be
> found in ${PORTDIR}/profiles/targets/desktop/plasma/.  The
> make.defaults and package.use in there show which USE flags a default
> plasma install would need (in addition to the standard desktop profile
> and the flags enabled by default in the ebuilds).  Note that most of
> the changes are either a) disabling things in some old KDE 4 stuff
> that hasn't been ported completely, to just have the bits still
> required on a mostly-ported system, and b) choosing which
> implementation (Qt4/Qt5) on packages that require you to choose (the
> profile ends up enabling USE="qt4 qt5" for most packages, this turns
> off one of them for some packages).
>
Thanks, I'll dig over those and see if the wiki page can be tweaked
slightly :)

MJE



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item: upgrading to Plasma 5

[Jonathan Callen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/06/2016 07:46 AM, M. J. Everitt wrote:
> 
> In the event you're not explicitly using a desktop or KDE desktop 
> profile, can you provide a summary of the changes that should be
> made manually when switching the the kde-plasma/* ebuilds please? I
> can probably handle a display manager change over a network of
> systems, but making a sensible transition to Plasma5 over many
> systems could be a trial if a small step is overlooked Thanks!
> 
> Michael/veremit.
> 
> 

The list of things that the plasma profiles add to the system can be
found in ${PORTDIR}/profiles/targets/desktop/plasma/.  The
make.defaults and package.use in there show which USE flags a default
plasma install would need (in addition to the standard desktop profile
and the flags enabled by default in the ebuilds).  Note that most of
the changes are either a) disabling things in some old KDE 4 stuff
that hasn't been ported completely, to just have the bits still
required on a mostly-ported system, and b) choosing which
implementation (Qt4/Qt5) on packages that require you to choose (the
profile ends up enabling USE="qt4 qt5" for most packages, this turns
off one of them for some packages).

- -- 
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXBa21AAoJEEIQbvYRB3mgmK8P/RnRjGjDjrrnrEiNW+0AQcpX
Wjsa47kEu7GenNQjJMg3RLDGYAXr2WlPVxXWJ6dSmd81Ja+36tWV5/pYj7XDGFOo
Pq7KSLBnS3aEHYjkMybikVhtOWbqV00sf/s3ApVopiivgvmiw2G40RsL7SA9DvZk
BkFkojt99XZ2K+v5sLUtAN7eGWbtCw7fgncCxpTxvcXgp9JK3Pp+VZOUidtTtfSy
7POdYdq/wgycoxRoZatSOYFsg8iQHoRRHxnq7wJsAsPCTkVVa0eghp/c6jAwa8Ja
23jrbk1u3hy84OJLD7Y3Z598Jj91HGEPWGdZ52yw1/1z6QvvaJ8DZP18T69cK6lC
Gjzu6xEGKSxaDILoQu/c98+qzvhdesgY5p6YGGa+UYQ/BCI4fia4fLEsx2nt7SDk
9USx42yRfN5rOo+B42Ii6LOhUQZ6+xQlBcQ3aFArHoZCfmxFuxHOnuOvAZ3rFRGo
A4tXcXI5nCf3VCns5+ONjocZI0fjDpvwY0fD2hgUi0AD1YYszcvW7UHpthRPZngm
9P/b1FACeE3j0fNbe6oZUS/LSPDW1GE1qh5yiJXgPyiqFxJkPi0cBoi4F9SRI1WC
fPtlOOkaFaZSTU/4OwGAwNDyFrtPTeA4JhZMPsVzykOd5mnAvEIRab1V3sG+MsUU
W83URmFaK3nQWlDfCzQ3
=aCfR
-END PGP SIGNATURE-

[gentoo-dev] Re: News item: upgrading to Plasma 5

[Michael Palimaka]

On 04/04/16 07:57, Richard Yao wrote:
> On Mon, Apr 04, 2016 at 03:34:07AM +1000, Michael Palimaka wrote:
>> Hi,
>>
>> KDE team intends to stabilise Plasma 5 shortly, so please review the
>> accompanying news items.
>>
>> Regards,
>>
>> Michael
>>
>> Title: KDE Plasma 5 Upgrade
>> Author: Michael Palimaka 
>> Content-Type: text/plain
>> Posted: 2016-04-02
>> Revision: 1
>> News-Item-Format: 1.0
>> Display-If-Installed: kde-base/plasma-workspace:4
>>
>> KDE Workspaces 4.11 has reached end of life and is no longer supported
>> by upstream. It is therefore recommended for all users to upgrade to
>> KDE Plasma 5.
> 
> Did you mean 4.14? 4.11 should have been EOL a long time ago.

There is no KDE Workspaces 4.14. It continued on as 4.11.xy while the
rest of KDE bumped to 4.13 and then 4.14.

Re: [gentoo-dev] Re: News item: upgrading to Plasma 5

[Mike Gilbert]

On Mon, Apr 4, 2016 at 1:55 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Michael Palimaka posted on Mon, 04 Apr 2016 05:23:03 +1000 as excerpted:
>
>> The default in KDE 4 was KDM, with lightdm and sddm also supported.
>>
>> We included information about migrating away from KDM because it's no
>> longer developed or supported and in some cases fails to work with
>> Plasma 5 at all.
>>
>> lightdm continues to work fine with Plasma 5 so there's no special need
>> to replace it.
>
> For clarity, then, why not add a single sentence similar to this (reword
> if appropriate):
>
> KDE 4 also supported lightdm and sddm, and users configured to use those
> display managers can continue to use them without reconfiguration.

You could also use XDM or GDM to launch KDE, but I don't think there's
any need to state that in this news item. We only need to make a
suggestion for people using the obsolete KDM.

[gentoo-dev] Re: News item: upgrading to Plasma 5

[Duncan]

Michael Palimaka posted on Mon, 04 Apr 2016 05:23:03 +1000 as excerpted:

> The default in KDE 4 was KDM, with lightdm and sddm also supported.
> 
> We included information about migrating away from KDM because it's no
> longer developed or supported and in some cases fails to work with
> Plasma 5 at all.
> 
> lightdm continues to work fine with Plasma 5 so there's no special need
> to replace it.

For clarity, then, why not add a single sentence similar to this (reword 
if appropriate):

KDE 4 also supported lightdm and sddm, and users configured to use those 
display managers can continue to use them without reconfiguration.


Also, a word for users who can't use a desktop/* profile at all, because 
they are for instance using a no-multilib (or x32 or hardened or 
whatever) profile and the desktop profiles aren't available as options 
there, would be appropriate.  Because right now you (as the gentoo/kde 
project) are pretty much leaving these users who can't or simply don't 
want to use the plasma profile, for whatever reason, to their own devices 
out in the unguided cold.

Tho in the news item I'd suggest simply referring them to the upgrade 
guide, and ensure the subject is covered in more detail there.  
Unfortunately, it's not covered there at all, ATM.

That "more detail" in the upgrade guide could be to simply say to check 
the USE flags in (default path)
/usr/portage/profiles/targets/desktop/plasma/make.defaults, and consider 
setting similar USE flags manually.  And similarly the package.use file 
in the same location, for individual packages.

Whether and how you want to describe the effect of policykit in 
use.force, since these users will obviously not be getting that force as 
they can't use that profile, is up to you.  It's already in the 
make.defaults USE list as covered above.  Maybe that's enough.


Meanwhile, one final sentence referring back to the upgrade guide if 
there are problems may also be useful:

The upgrade guide contains further troubleshooting and solutions hints, 
should you run into problems.


(Much as I hate servantware such as skype, the hint on that may well be 
totally unintuitive for many of its gentoo/kde users, for instance.  BTW, 
is that still valid advice given the plasma-desktop sni embedding, now?)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: News item: upgrading to Plasma 5

[Michael Palimaka]

On 04/04/16 05:06, Rich Freeman wrote:
> On Sun, Apr 3, 2016 at 1:34 PM, Michael Palimaka  
> wrote:
>>
>> If you normally use KDM to launch Plasma, note that it is no longer
>> supported.
>> Upstream recommends x11-misc/sddm instead which is pulled in by
>> plasma-meta by
>> default. To switch, edit /etc/conf.d/xdm and update DISPLAYMANAGER.
>>
> 
> Didn't we previously recommend using lightdm?  I'm sure migrating is
> trivial but perhaps some kind of note about this might be useful?  I
> suspect that the instructions for migrating from lightdm->sddm are the
> same as kdm->sddm.
> 

The default in KDE 4 was KDM, with lightdm and sddm also supported.

We included information about migrating away from KDM because it's no
longer developed or supported and in some cases fails to work with
Plasma 5 at all.

lightdm continues to work fine with Plasma 5 so there's no special need
to replace it.

[gentoo-dev] Re: News item: upgrading to Plasma 5

[Michael Palimaka]

On 04/04/16 04:48, Mike Gilbert wrote:
> On Sun, Apr 3, 2016 at 1:34 PM, Michael Palimaka  
> wrote:
>> Hi,
>>
>> KDE team intends to stabilise Plasma 5 shortly, so please review the
>> accompanying news items.
> 
> Very exciting, nice work!
> 
>> If you normally use KDM to launch Plasma, note that it is no longer
>> supported.
>> Upstream recommends x11-misc/sddm instead which is pulled in by
>> plasma-meta by
>> default. To switch, edit /etc/conf.d/xdm and update DISPLAYMANAGER.
> 
> That only works for OpenRC users. systemd users should run the
> following after installing sddm to adjust the display-manager.service
> symlink:
> 
> systemctl reenable sddm.service
> 
> 

I was hoping someone would chime in with the systemd command. :)

I have updated that paragraph to read:

If you normally use KDM to launch Plasma, note that it is no longer
supported.
Upstream recommends x11-misc/sddm instead which is pulled in by
plasma-meta by
default. OpenRC users should edit /etc/conf.d/xdm and update DISPLAYMANAGER.
Systemd users should run: systemctl reenable sddm.service

[gentoo-dev] Re: News item: upgrading to Plasma 5

[Michael Palimaka]

On 04/04/16 04:34, Ulrich Mueller wrote:
>> On Mon, 4 Apr 2016, Michael Palimaka wrote:
> 
>> News-Item-Format: 1.0
>> Display-If-Installed: kde-base/plasma-workspace:4
> 
> Slot dependencies in Display-If-Installed are not allowed in news item
> format 1.0. You should use format 2.0 (which allows EAPI 5 dependency
> specifications) if you need them.
> 
> Ulrich
> 

Thanks, we don't actually need the slot dependency so I just dropped it.

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/27/2016 03:17 PM, Dirkjan Ochtman wrote:
> On Fri, Jan 22, 2016 at 3:20 PM, Kristian Fiskerstrand
>  wrote:
>> Advanced notice, please
> 
> Committed 2016-01-27-upgrading-to-apache-2_4 to news.
> 
> Time to request stabilization?

I'm not aware of any formal policy on it, but from perspective of a
sysadmin I'd say anything starting a week from now should be fine.

(Although my normal maintenance window this week is affected by FOSDEM
unless there are security critical patches.. but at least gives time
to get the news :) )

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWqNK5AAoJECULev7WN52FrlkH/1jlyemX/mCwwQ6YWpLOFMp6
0srq7x2qjEW8SDl8osd6tNv9foN6zzbiSerlVjXCx5qCzQkYdw67+YmYvedzrwg3
Gp6xuu9A4OvYH9Yh3Xn1kcLFcnwstUotSJJ0E/ct8BQMgQRAZI4gabo8EmrqPeHX
MNMOOF10z0ABXugxYWAgK0nFhy6IKF9nPmxCGzObGlg+oZIAa4lreb2nprb8D1WC
WjSr0GZxX4hQRxxKnwYRvT+gSFzIhLzu+EAq5VWKdETR9ali7fNNfDbj1fE00OEM
4vCS3JEF7ob1KwVEgWqLTcpgxuFBJPqk6vFaS0IPlMYCUjEtXeiTMtIU32cq1bw=
=2XWG
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Dirkjan Ochtman]

On Fri, Jan 22, 2016 at 3:20 PM, Kristian Fiskerstrand  wrote:
> Advanced notice, please

Committed 2016-01-27-upgrading-to-apache-2_4 to news.

Time to request stabilization?

Cheers,

Dirkjan

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/22/2016 03:04 PM, Dirkjan Ochtman wrote:
> Third attempt.
> 

..

> 
> Remaining question: how do get the timing of the news item to line
>  up with the stabilization? Or do we just start by sending out the
>  news item, then file the stabilization bugs so that people at 
> least have advance notice?

Advanced notice, please


- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWojqUAAoJECULev7WN52FXD0IAKoAhGIB27lbYsWORQ6H8AMC
hStsuzOL4cYnWp/YJT2j31dCIZvnzt9dRByIYkZn+roPv3Cl1ij+TA2TGaLg8t5s
QGr2ASA4kYle8DIU2WmeR0VxBsv0QaHqVbY9YkT7++a2EkqaQAXBuoJIIZeMKvCI
6WiXj/rX2/9ORm7lIkwahp5ClbHMlCqxY4qUOurK+ki9TUDhDN6DnYrLQDG/+y88
aB6XbUqR2CCMc46QiKox+h1HxKf6poqSwBvDMUwWTsl5TBT1mVXh5PMemRBwhLN4
pRLexBhaCrMv3IdKmD20CrGtKGt3uw2FxRkMI8iJKR6BCeRV1JNL9BuHyDJVAd4=
=mE3l
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Lars Wendler]

Hi Dirkjan,

make it part of the news item please.

Kind regards
Lars

On Wed, 20 Jan 2016 13:16:19 +0100 Dirkjan Ochtman wrote:

>On Wed, Jan 13, 2016 at 6:13 PM, Dirkjan Ochtman 
>wrote:
>> After what feels like ages, we're just about ready to stabilize
>> apache-2.4. Since this is a major upgrade that in many cases require
>> configuration changes, we wanted to do a news item. After some
>> discussion with Lars (Poly-C), here's an initial attempt at a
>> draft.  
>
>I'm currently attempting this upgrade on a stable system I run. It
>mostly just works, although I run into trouble when trying to load
>modules that are not part of www-server/apache (e.g. mod_wsgi). I
>resolved this by reemerging all packages listed in `equery b
>/usr/lib/apache2/modules/*`, but maybe there's a different way? Should
>this be in an elog message, or part of the news item?
>
>Cheers,
>
>Dirkjan
>



-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpHvwXWc7nfa.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Paul Varner]

On 01/21/2016 06:52 AM, Lars Wendler wrote:
> Hi Dirkjan,
>
> make it part of the news item please.
>
> Kind regards
> Lars
>
> On Wed, 20 Jan 2016 13:16:19 +0100 Dirkjan Ochtman wrote:
>
>> On Wed, Jan 13, 2016 at 6:13 PM, Dirkjan Ochtman 
>> wrote:
>>> After what feels like ages, we're just about ready to stabilize
>>> apache-2.4. Since this is a major upgrade that in many cases require
>>> configuration changes, we wanted to do a news item. After some
>>> discussion with Lars (Poly-C), here's an initial attempt at a
>>> draft.  
>> I'm currently attempting this upgrade on a stable system I run. It
>> mostly just works, although I run into trouble when trying to load
>> modules that are not part of www-server/apache (e.g. mod_wsgi). I
>> resolved this by reemerging all packages listed in `equery b
>> /usr/lib/apache2/modules/*`, but maybe there's a different way? Should
>> this be in an elog message, or part of the news item?
>>
The simple command to do this is: emerge -av1 /usr/lib/apache2/modules
--exclude=www-servers/apache

Regards,
Paul

[gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Dirkjan Ochtman]

On Wed, Jan 13, 2016 at 6:13 PM, Dirkjan Ochtman  wrote:
> After what feels like ages, we're just about ready to stabilize
> apache-2.4. Since this is a major upgrade that in many cases require
> configuration changes, we wanted to do a news item. After some
> discussion with Lars (Poly-C), here's an initial attempt at a draft.

I'm currently attempting this upgrade on a stable system I run. It
mostly just works, although I run into trouble when trying to load
modules that are not part of www-server/apache (e.g. mod_wsgi). I
resolved this by reemerging all packages listed in `equery b
/usr/lib/apache2/modules/*`, but maybe there's a different way? Should
this be in an elog message, or part of the news item?

Cheers,

Dirkjan

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Aaron W. Swenson]

On 2016-01-17 19:18, Dirkjan Ochtman wrote:
> Second attempt!
> 
> ===
> 
> Title: Upgrading Apache from 2.2 to 2.4
> Author: Dirkjan Ochtman 
> Content-Type: text/plain
> Posted: 2016-01-17
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: www-servers/apache
> 
> With the 2.4 branch released by upstream almost 4 years ago, stable
> Gentoo systems will soon be upgraded from apache 2.2 to apache 2.4.
> When upgrading, chances are some configuration changes have to be
> made. Upstream has a handy guide:
> 
> https://httpd.apache.org/docs/2.4/upgrading.html
> 
> For more information on all the new features, start here:
> 
> https://httpd.apache.org/docs/trunk/new_features_2_4.html
> 
> ===
> 
> A bit more concise and less personal. Better?
> 
> Cheers,
> 
> Dirkjan
> 

I think the use of "chances" here depresses the importance of
configuration changes.

This is debatable, but I think it should be "there are some
configuration changes that must be made."

Primarily in regards to the Order directive being (re)moved to an
optional module.


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/17/2016 10:18 AM, Dirkjan Ochtman wrote:
> Second attempt!
> 
> ===
> 
> Title: Upgrading Apache from 2.2 to 2.4 Author: Dirkjan Ochtman
>  Content-Type: text/plain Posted: 2016-01-17 
> Revision: 1 News-Item-Format: 1.0 Display-If-Installed:
> www-servers/apache
> 
> With the 2.4 branch released by upstream almost 4 years ago,
> stable Gentoo systems will soon be upgraded from apache 2.2 to
> apache 2.4. When upgrading, chances are some configuration changes
> have to be made. Upstream has a handy guide:
> 
> https://httpd.apache.org/docs/2.4/upgrading.html
> 
> For more information on all the new features, start here:
> 
> https://httpd.apache.org/docs/trunk/new_features_2_4.html
> 
> ===
> 
> A bit more concise and less personal. Better?
> 
> Cheers,
> 
> Dirkjan
> 

Looks excellent!

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWnOVvAAoJEAEkDpRQOeFwz48QAMmRq40+TZhvekUuDnFfDP4c
0cl4p9gWvKNVpesuQf7fR8CZ13mHiu1JyHzgmb03Rk3WTbE4LiFj8uUz6p/fLoDk
8F2Zn7ZypXIw5GWZvWzw7BVx69NHF5hMLJMAJq5kj42LwGBewcYHRWaT1mPan3pb
4EtT9Mr8MJe4hp6RcRqSauJ0+TX12TZhv1y07SaWGoDAqUBpu+Iny8r/ObsQciql
nEbRQfOAQvg9vd5vxJsMqVvTrY9Q8h7TZ+iEUDWDWD7FGdVEbXbJZ3QQ1WqK+R4K
v2Jup+I2MD8fe2R9cXQzdh/vh4vrmSmsh7g1UScXeHRtO8ADRYy3ssCav+4RMBQ9
Cs9Q6iLnkvCrKsiHfpNTfcvx4hYrlzOIpFZHYJ3N6+Yafw5v17H3EE3qgtbIbZFL
B2UDDQ14CSjYo/oIG6DLBmgTIXidFHv4PljCgwB2sV3Gnh/Rk2zeDoil0JVNG8WB
weycIKebgcRlk5eWlz+iLKn+1DonPfaSkTxG+v0hRETEV9xd0XeTuT57QkMckXaz
h/R7XKe3KhMbb641tBOjZmRWZAJLUiRjgcqY+ztUj2hHZj2kXkpy1eLC0/PSvCFr
30dk+REHrM8pkQochK+EmmTelFPibUvEuANMU2ZMGdh0W/Mm/je75HGa2VRNP8o1
8Po3JXLXD4Qgng+N6Cx0
=TtSV
-END PGP SIGNATURE-

[gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Dirkjan Ochtman]

Second attempt!

===

Title: Upgrading Apache from 2.2 to 2.4
Author: Dirkjan Ochtman 
Content-Type: text/plain
Posted: 2016-01-17
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: www-servers/apache

With the 2.4 branch released by upstream almost 4 years ago, stable
Gentoo systems will soon be upgraded from apache 2.2 to apache 2.4.
When upgrading, chances are some configuration changes have to be
made. Upstream has a handy guide:

https://httpd.apache.org/docs/2.4/upgrading.html

For more information on all the new features, start here:

https://httpd.apache.org/docs/trunk/new_features_2_4.html

===

A bit more concise and less personal. Better?

Cheers,

Dirkjan

[gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Duncan]

Dirkjan Ochtman posted on Wed, 13 Jan 2016 18:13:41 +0100 as excerpted:

> Display-If-Installed: www-servers/apache

Can't that be made 

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Dirkjan Ochtman]

On Thu, Jan 14, 2016 at 10:53 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Display-If-Installed: www-servers/apache
>
> Can't that be made  2.4 need a news item about something they've already taken care of?

This makes sense to me, though I imagine it could be annoying if
people (stupidly, but whatever) postpone reading their news items
until after the upgrade. Is this a canonical approach? Would like some
feedback from the experts, here!

Cheers,

Dirkjan

[gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
> Hi!
> 
> 
> Better late then never.  Posting 72 hours from now the earliest as
>  advised by GLEP 42.  Feedback welcome as usual.

Do you have any timeline in place for the change happening in tree (in
particular for stable users).

> 
> Without updating APACHE2_OPTS, websites could end up serving PHP 
> code (include configuration files with passwords) unprocessed to 
> website visitors!
> 

Such a change should really be avoided if possible. Would it be
possible to have a conditional approach where either one can be used,
or maybe set the new variable/defin if the old one is used?

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWijA1AAoJECULev7WN52F/aQH/0JxIUbwzpXsY3canje+A/oo
IsfgksJIZOq3cRZNwNvnE+BBMyuQlGaJ6auuIp+er9VNwjYk2Qiq7tzAanEdVeq9
A6h+eWYu/jTI57op9n7h5k6Jy7fMU1G/YfH6KfDHaoV/mIZFjpTND3v97OvB+uAc
6jt0234PYHjFsSwyOnYZ3/p+P9GELAhGAQQWaDhh5RDdKPfpEULiVpniWbnbTFBq
evQ2dKRw6cifBfyUYcLsGstdtPsqzbjETNOeWSNLwgMMpCh7xViaTnJ1T+9rqK1L
9Jb1+xCuy7Nj6T4mbZZaDZXuGdJm9KgpzplpRR1ivv0FudwgHAbFJ8QyykjvOMA=
=KViT
-END PGP SIGNATURE-

[gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Rich Freeman]

On Mon, Jan 4, 2016 at 3:41 AM, Kristian Fiskerstrand  wrote:
>
> On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
>> Hi!
>>
>>
>> Better late then never.  Posting 72 hours from now the earliest as
>>  advised by GLEP 42.  Feedback welcome as usual.
>
> Do you have any timeline in place for the change happening in tree (in
> particular for stable users).

++

In particular we should avoid both of these scenarios:
1. Stable users make a change now which breaks their existing config
(because the change isn't deployed to stable yet).
2. Stable users get the news item today, and the change six months
later after they've forgotten about it.

I'm not sure whether either applies in this case.

-- 
Rich

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/04/2016 09:41 AM, Kristian Fiskerstrand wrote:
> On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
>> Hi!



> 
> Such a change should really be avoided if possible. Would it be 
> possible to have a conditional approach where either one can be 
> used, or maybe set the new variable/defin if the old one is used?
> 

Maybe I'm thinking things too difficult, why not just define both -D
PHP and -D PHP5 in the transition period and suggest this config for
any change?

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWinPkAAoJECULev7WN52FFkYH/2f9v5dnKeS4nX3mP+ZnzwkY
YpV2W0l8WNN1ZHfM4nsf/zKPw7eJqYFFryaYYtiNebvN37SpjaqdCrn78l1/mJYI
JfKH6Aj7QNi3LuGR0B30yKhDMF6Q5Yu56rtXuweHCdX25zOoTkQAQ8S5n9OOLORP
DP4J0hgc+HQZrMkZMUZGTrToFX91ffQazE/e/ryXROCNO/g8vZBpbCbTC6PuSpMp
z5foF2sD4cfcccvVf0vG4NKwIhFqYPZkvMM8/yYbuj61ZGGf0HtCXBpK4fNLgQKc
nKqVUzKY69YY76oi2sS+GDmEPQohCMTzSdhQztNXGKrTmzz5tccVnqCMlLd8kn4=
=0KpH
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/04/2016 02:30 PM, Kristian Fiskerstrand wrote:
> On 01/04/2016 09:41 AM, Kristian Fiskerstrand wrote:
>> On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
>>> Hi!
> 
> 
> 
> 
>> Such a change should really be avoided if possible. Would it be 
>> possible to have a conditional approach where either one can be 
>> used, or maybe set the new variable/defin if the old one is
>> used?
> 
> 
> Maybe I'm thinking things too difficult, why not just define both
> -D PHP and -D PHP5 in the transition period and suggest this config
> for any change?
> 

And while at it, in additional to news item, this should likely follow
a few version upgrades as elog messages before actually being
implemented anywhere

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWin+hAAoJECULev7WN52FNGYIAIK5xZEaBvUzR9YCyzSphnI/
ymh6i+wUnzcCjX4TYpC5c05yp3nzLTXvKsaNFuMos43ZqhjTG6hny72waIZ5RRmM
KI1XORRItoOHiat6xuYrOg8S9vf881AJnS/w6XhRVkL1MrtGLrUbV2De/5Z7V1PU
3j0M702inkbPHoV3JfRv97ZZmupazCSj7rfrrwcvUFqjKFZNFU4zK76rAwRXYfSk
ZKC7MSAx6lfhcNmy8boUoFMnFwyimkI06hN8ZhaosexkSYqT5HeOUMrX2bpKtXF/
69Ky3bd8Vs8/f9WTqtjf3GJC/iBs1/gpxgSu7/hpy69yFoffLE9VsKe1xHSd3n4=
=C5MO
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Brian Evans]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/4/2016 3:41 AM, Kristian Fiskerstrand wrote:
> On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
>> Hi!
> 
> 
>> Better late then never.  Posting 72 hours from now the earliest
>> as advised by GLEP 42.  Feedback welcome as usual.
> 
> Do you have any timeline in place for the change happening in tree
> (in particular for stable users).
> 
> 
>> Without updating APACHE2_OPTS, websites could end up serving PHP
>>  code (include configuration files with passwords) unprocessed to
>>  website visitors!
> 
> 
> Such a change should really be avoided if possible. Would it be 
> possible to have a conditional approach where either one can be
> used, or maybe set the new variable/defin if the old one is used?
> 
> 

The problem is really two-fold with the new eselect-php.

For future compatibility (to not have this happen again with say
PHP8), the PHP team changed the symlink created by eselect to be
libphp.so instead of the current libphp${MAJOR}.so.

The user must also reselect with `eselect php set X`, even for the
current PHP versions and not just 7.

mjo explored the option of "Define PHP" but
that is apache-2.4+ only.

If we wanted a "compatibility" layer, it would be the same section
repeated until 2.4 was the only version available.  That might confuse
users even more.

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJWioraAAoJENH3ge/59KO2wNUQAKThJz1QBjOvOmi0ClluVxt8
Lt0fbibQXIgZScJy5zqeOwX3EAUDqBST8sonNhJ8uQT4qbU8gwdYK6vhoDbJS0sX
oNzbdwxumSwNBsi4UCl/D0Dj+XefgIyvmgGBZ0RA8t0x8Ls3uQB6DWI1f36Z3wAs
ULqJc38+d1e5pmNu3jpc5tvG2ybvaVVGbWmNiOI8rafFV12KIsRMDHdDCG4DpkQD
bmWLYTv44Nt5nSY2wmLQQAV57kB2PsaaT0qlQciVhKiqOUA+qlmI0dtM3LLSNitK
dqKWNj7WTQFBM1SLHXD0s4CQk9XhFB9E07zelcB5zuC9XeYj1mbrn9aEtfl5lfVs
hHHJQ97MG3u/XwPTHY04J6wfoaQW4dwaQd74Pz48qJ2DqSW9HV8UTS2enF5cuZok
mFfd+xexHvcz45jyz83BtXM4mRWdHBDdy/3fYEvN12wVgU4hQcjDTKKPwpO3Btsb
uyCar+SgoHoRIEQhfDytnT0Idte2GifCysPq7hG12j+efwT7pt0XXk+TZQaH/opZ
FWRzOvjXZXd41M3RQ7H5D+KXrKV3uY4mE41rceEUXrw9PQrueg6Cw5ujK/opawrv
a8qonCtx7LZrEzYLagCYEBDPdgvxHWzIBb0vdgYoRVzSRwoJiAA66dbRuqC7s34G
JM84VqrtPsaCktCq6vw3
=/gh0
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Peter Stuge]

Kristian Fiskerstrand wrote:
> Maybe I'm thinking things too difficult, why not just define both -D
> PHP and -D PHP5 in the transition period and suggest this config for
> any change?

Because it mostly just defers the problem.

If the desire is to move away from PHP5 then I would suggest to force
a failure when starting Apache, if PHP5 is defined when PHP is required.

Ie. fail closed.

I can be talked into supporting the idea to only print a warning when
PHP5 is set and to not fail (no source served) for some period of
time until which the forced failure starts, if PHP5 is still set.

Don't fail open, fail closed. Since manual interaction is required
some people will forget or overlook it, and will get a failure.

I would introduce the failure right away, but maybe a warning will
make some happy who would otherwise have gotten a failure.


//Peter

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Rich Freeman]

On Mon, Jan 4, 2016 at 9:20 AM, Kristian Fiskerstrand  wrote:
>
> And while at it, in additional to news item, this should likely follow
> a few version upgrades as elog messages before actually being
> implemented anywhere
>

I don't want to be too prescriptive with the solutions.  However,
clearly /some/ kind of orderly transition is necessary.  News before,
an elog, etc.  And that news needs to be timely - not 12 months before
stable mysteriously breaks one day, unless it is safe to make the
change before the update.  I'd leave it up to the maintainer to decide
whether it is more work to coordinate the timing around all the
communications or to have a more graceful transition so that the
timing isn't as critical.

-- 
Rich

Re: [gentoo-dev] Re: News item: GRUB security update

[Dale]

Rich Freeman wrote:
> On Sat, Dec 19, 2015 at 8:24 AM, Tobias Heinlein  
> wrote:
>> Hi,
>>
>> On 18.12.2015 21:06, Mike Gilbert wrote:
>>> Hi, please review the news item below.
>> thanks for drafting this news item. However, the usual way to inform
>> users about security flaws is by sending a GLSA. :)
>>
>> Based on your news item, we have drafted a GLSA now. It's currently
>> pending review by one other member of the security team and we will send
>> it in a few hours.
>>
> << SNIP >>
> 2.  Users probably don't regularly read GLSAs, since for the most part
> it just tells them to update packages they've probably already
> updated.  How do we make ones that actually have instructions beyond
> updating stand out?
>
> I know I stopped reading GLSAs ages ago, because they tended to tell
> me to update to a package I had updated to a week before, and when
> they said something else 90% of the time it was because there was an
> error in the GLSA (usually this happened with subslots and the GLSA
> just said  of ranges that were vulnerable vs fixed).  Granted, I have caught one
> or two episodes over the years where the actual package might not have
> been completely addressed and an older slot needed fixing.
>
> I guess my point isn't that GLSAs are a bad thing, but users need a
> really high S/N ratio if we want them to pay attention.  We need to
> separate the mundane from the important.
>


+1.  Given all the changes that have been done, I don't even know how to
read them any more because I stopped a long time ago. 

I might add, I also don't read blogs about this sort of thing.  About
the only time I read a blog is if it is linked to here or on -user. 
Other than that, rarely if ever. 

All things considered, if it isn't a news item or something I follow on
this list, I may never know about it.  I really depend on the news
items.  Just keep the noise down or folks will start to ignore them too,
although y'all are good at it only telling us about things that affect us.

Dale

:-)  :-) 

Re: [gentoo-dev] Re: News item: GRUB security update

[Mike Gilbert]

On Sat, Dec 19, 2015 at 8:44 AM, Rich Freeman  wrote:
> On Sat, Dec 19, 2015 at 8:24 AM, Tobias Heinlein  
> wrote:
>> Hi,
>>
>> On 18.12.2015 21:06, Mike Gilbert wrote:
>>> Hi, please review the news item below.
>>
>> thanks for drafting this news item. However, the usual way to inform
>> users about security flaws is by sending a GLSA. :)
>>
>> Based on your news item, we have drafted a GLSA now. It's currently
>> pending review by one other member of the security team and we will send
>> it in a few hours.
>>
>
> The only concerns I have with this approach are:
> 1.  In this case timing is fine, but sometimes GLSAs have a
> significant delay, especially when minor archs are involved in
> stabilization.
> 2.  Users probably don't regularly read GLSAs, since for the most part
> it just tells them to update packages they've probably already
> updated.  How do we make ones that actually have instructions beyond
> updating stand out?
>
> I know I stopped reading GLSAs ages ago, because they tended to tell
> me to update to a package I had updated to a week before, and when
> they said something else 90% of the time it was because there was an
> error in the GLSA (usually this happened with subslots and the GLSA
> just said  of ranges that were vulnerable vs fixed).  Granted, I have caught one
> or two episodes over the years where the actual package might not have
> been completely addressed and an older slot needed fixing.
>
> I guess my point isn't that GLSAs are a bad thing, but users need a
> really high S/N ratio if we want them to pay attention.  We need to
> separate the mundane from the important.

I had that same thought when keytoaster first replied to this.

Realistically, I suspect very few Gentoo users are using
authentication in GRUB. Those who do are certainly more security
conscious than the average user, and more likely to read GLSAs and
other security announcements.

I think the pkg_postinst message and the GLSA are sufficient coverage
for this issue.

[gentoo-dev] Re: News item: GRUB security update

[Tobias Heinlein]

Hi,

On 18.12.2015 21:06, Mike Gilbert wrote:
> Hi, please review the news item below.

thanks for drafting this news item. However, the usual way to inform
users about security flaws is by sending a GLSA. :)

Based on your news item, we have drafted a GLSA now. It's currently
pending review by one other member of the security team and we will send
it in a few hours.

Thanks!

Cheers,
Tobias



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item: GRUB security update

[Rich Freeman]

On Sat, Dec 19, 2015 at 8:24 AM, Tobias Heinlein  wrote:
> Hi,
>
> On 18.12.2015 21:06, Mike Gilbert wrote:
>> Hi, please review the news item below.
>
> thanks for drafting this news item. However, the usual way to inform
> users about security flaws is by sending a GLSA. :)
>
> Based on your news item, we have drafted a GLSA now. It's currently
> pending review by one other member of the security team and we will send
> it in a few hours.
>

The only concerns I have with this approach are:
1.  In this case timing is fine, but sometimes GLSAs have a
significant delay, especially when minor archs are involved in
stabilization.
2.  Users probably don't regularly read GLSAs, since for the most part
it just tells them to update packages they've probably already
updated.  How do we make ones that actually have instructions beyond
updating stand out?

I know I stopped reading GLSAs ages ago, because they tended to tell
me to update to a package I had updated to a week before, and when
they said something else 90% of the time it was because there was an
error in the GLSA (usually this happened with subslots and the GLSA
just said 

[gentoo-dev] Re: News item: GRUB security update

[Kristian Fiskerstrand]

On 12/19/2015 02:44 PM, Rich Freeman wrote:
> On Sat, Dec 19, 2015 at 8:24 AM, Tobias Heinlein  
> wrote:
>> Hi,
>>
>> On 18.12.2015 21:06, Mike Gilbert wrote:
>>> Hi, please review the news item below.
>>


..

> 
> I guess my point isn't that GLSAs are a bad thing, but users need a
> really high S/N ratio if we want them to pay attention.  We need to
> separate the mundane from the important.
> 

This sounds like something that might be appropriate for gentoo blog  of
some sort (GWN on a more ad-hoc basis?) linking to the GLSA. Even a blog
in private blog as part of Planet Gentoo would likely work (but official
blog would work nicer).

-- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News Item: Future Support of hardened-sources Kernel

[Duncan]

Anthony G. Basile posted on Tue, 20 Oct 2015 05:34:33 -0400 as excerpted:

> On 10/20/15 4:45 AM, Rich Freeman wrote:
>> On Tue, Oct 20, 2015 at 4:23 AM, Daniel Campbell 
>> wrote:
>>> However, does this mean the hardened kernel package must stay in ~arch
>>> since it's technically the testing version? Or would we keyword it
>>> based on our own findings of stability?
>> I'd recommend that the team does whatever adds the most value.  If it
>> doesn't want to do QA on released versions then I suggest it all stay
>> as ~arch.  If you're going to do your own QA I don't see why you can't
>> mark versions as stable - just make it clear to users what stable
>> means.
>>
>> BTW, while they're only tracking the most recent stable branch of the
>> kernel, they ARE tracking a stable branch, and not mainline.
>>
> I have been marking hardened-sources based on the grsecurity testing
> patches as stable since forever and will continue with the same
> practice.  "Testing" means they add new features there first and those
> new features can break stuff.  We identify breakage in bug reports and
> hold back to versions that are known to work until upstream fixes the
> broken features.  It works pretty good in practices and most users of
> hardened-sources already know this. What they may not know is that the
> 3.x is no longer public.

And FWIW, ~arch vs stable in gentoo has always been relative not 
necessarily to what upstream considers testing vs stable, but rather, to 
the general stability of the ebuild (and patches, etc) specifically in 
/gentoo/.

Of course there has been quite some maintainer leeway in that, and often 
the maintainer will choose to follow upstream stability guidance when 
choosing versions to stabilize, but that isn't necessarily the case.  
Strictly speaking, it has /always/ been about gentoo-level, not upstream-
level, stability.

So particularly in cases like this where upstream official testing is all 
that upstream makes available, any gentoo stable indicator must /clearly/ 
be based on gentoo-level stability, /maybe/ based partly on the opinions 
of other distros shipping it, but obviously not based on upstream's 
classification, since they don't even make a stable classified version 
available to the general FLOSS community.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: news item: OpenRC 0.18 changes to localmount and netmount

[Duncan]

William Hubbs posted on Mon, 28 Sep 2015 17:58:19 -0500 as excerpted:

> Title: OpenRC-0.18 changes to localmount and netmount

$ echo "OpenRC-0.18 changes to localmount and netmount" | wc -c
47

I know there was some discussion about lifting the glep-42 title limit of 
44 chars, but AFAIK discussion is where it remained.

What about omitting the three chars "to " (including the space) and 
reordering, like so:

OpenRC-0.18 localmount and netmount changes

wc -c says 44 for that. =:^)

Otherwise, looks reasonable here. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: news item: libvirt-1.2.19 init script upgrades

[Duncan]

Matthias Maier posted on Fri, 11 Sep 2015 16:22:27 -0500 as excerpted:

> Title: libvirt-1.2.19 init script changes
...
> OpenRC Users:

I'm not a libvirt (neither openrc, now) user, but it looks good here in 
terms of general clarity/spelling/grammar, and you didn't hit the 
commonly hit title-too-long bug. =:^)

The only very minor nit I can /possibly/ find is that message opening...

OpenRC users:

That's arguably slightly confusing as it makes the news appear to be 
about openrc, but then the rest of it talks about libvirt.

If you're a perfectionist, there's a possible argument for making that...

OpenRC libvirt users:

But arguably it's fine as-is.  I doubt I'd miss the libvirt just reading 
it, and only saw it here because I was /trying/ to be picky! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: News item review: SquashDelta syncing support

[Martin Vaeth]

Brian Dolbec dol...@gentoo.org wrote:
 Martin Vaeth mar...@mvath.de wrote:

 However, currently this does not play nicely with squashdelta:
 You have to undo the mounting of squashdelta and have to use
 different command (e.g. squashmount) afterwards.

 No, that is not correct [...]
 2) /etc/portage/repo.postsync.d

I know about this hook, but this is not what I meant.

What I meant is the possibility to *replace* the automatic
mounting of portage by a different command (for instance,
a possibility to *avoid* that portage mounts/umounts
automatically but expects this to happens in this hook).

I give reasons for this below.

(This discussion belongs actually to portage-devel mailing
list or to some bug, but now I feel the necessity to clarify
the misunderstanding.)

It is not only inefficient and hackish (with possible problems
in case of unexpected situations like a SIGINT or other signal
at a bad time) if two programs/scripts fight about mounts
and undo each others' mounts. It also causes severe difficulties
in connection with overlayfs/aufs/...:

With these filesystems, you must create two (in case of
overlayfs even three) auxiliary directories, and in this
situation, it might be natural to choose these as
temporary direcories (e.g. generated in /tmp with unique names);
to understand the following explanation note also that two
of these directories (the squash filesystem and the overlay
filesystem) should normally always be mounted/umounted
together.

Now if portage umounts only the overlay directory,
the information about the temporary directory names is lost
(leaving possibly quite a bit data in /tmp undeleted
forever), and the second necessary umount does not
happen and is hard to do later on: It prevents the
space of the old squash file from actually being freed
(and this mount is hard to find later on: It is a mount
of a deleted file on an unknown temporary directory.
Of course, one could try to find this mount by some heuristic,
but this is extremely hackish, and the heuristic might find
some other squash file which the user has mounted similarly
for some other reason.)

In case of the mentioned squashmount tool, the situation
is better, because squashmount is rather complex and e.g.
stores/manages the names of temporary directories independently.
However, users might also want to use less sophisticated tools
than squashmount (and also squashmount has no easy solution
for random remounts of the mount points it manages, because
it is almost impossible to write a generic such solution.)

In any case, it is rather hackisch to write a lot of additional
code to undo an actually undesired umounting+mounting:
The clean solution appears to be to not do the undesired
(in this situation) umounting+mounting in the first place but
to execute *only* the actually desired (u)mount command(s)
instead.

Re: [gentoo-dev] Re: News item review: SquashDelta syncing support

[Brian Dolbec]

On Mon, 18 May 2015 05:48:59 + (UTC)
Martin Vaeth mar...@mvath.de wrote:

 Rich Freeman ri...@gentoo.org wrote:
  Downsides include:
  2.  Impossible to tweak ebuilds without setting up an overlay.  This
  might be annoying for devs/etc.
 
 It is still possible to setup a read-writable portage tree
 (using overlayfs/aufs/unionfs-fuse/... e.g. using the squashmount
 tool from the mv overlay).
 
 However, currently this does not play nicely with squashdelta:
 You have to undo the mounting of squashdelta and have to use
 different command (e.g. squashmount) afterwards.
 Although this can probably be done e.g. in eix-sync with hooks,
 I hope that in the near future there will be a possibility to
 combine these methods more conveniently.
 
 Currently, I made only some remarks in comment #3 of bug 549716,
 because it seems that the sync module mechanism is currently
 lacking the infrastructure for adding custom data (like hooks) to
 a module.
 
 

No, that is not correct, the new sync system also introduced a new
native portage postsync hook system.

1) /etc/portage/postsync.d/...  runs each script once at the completion
of all repos that were synced. (no arguments passed in)

2) /etc/portage/repo.postsync.d  runs each script at the end of each
repo that is synced.  Each script can determine if it needs to run or
simply exit.  Each script is called with 3 arguments  the repo name,
the url link it was synced to and the path to the repo.

Using that information you could easily add a postsync hook there
looking for the gentoo repo argument. And if not exit.  If it is the
gentoo repo, call your squashmount script to remount it your way.

See the example script in that directory.

-- 
Brian Dolbec dolsen

[gentoo-dev] Re: News item review: SquashDelta syncing support

[Duncan]

Michael Orlitzky posted on Sat, 16 May 2015 20:45:08 -0400 as excerpted:

 On 05/16/2015 06:00 PM, Michał Górny wrote:

 Do we need a news item for this at all? Everything is backward
 compatible and most people don't need to do anything at all in
 response to the news.
 
 No, we don't. But news items are good way to tell people that something
 is happening. Look at Funtoo. Their users are happy because developers
 announce stuff rather than expecting them to watch for random things
 happening.
 
 
 Ok, just keep in mind that you force thousands of people to type
 `eselect news read new` on all of their machines when you post a feature
 announcement.

That's a good point, and a rather persuasive argument to include the the 
benefits/down-sides are sections already suggested elsewhere. =:^)

IOW, without a benefits/negatives section, you are absolutely correct, 
there's no obvious reason to post this as a news item as it simply forces 
a bunch of people to read news and wonder why they should care.

But with that benefits/negatives section added, it should become a useful 
news item, that even people who don't choose to switch to squashdelta 
should appreciate, as it keeps them informed of changes and allows them 
to make informed decisions based on them. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

[gentoo-dev] Re: News item review: SquashDelta syncing support

[Duncan]

Michał Górny posted on Sun, 17 May 2015 05:47:15 +0200 as excerpted:

 Dnia 2015-05-16, o godz. 20:38:36 Michael Orlitzky m...@gentoo.org
 napisał(a):
 
 On 05/16/2015 06:01 PM, Michał Górny wrote:
 
  We have gentoo-announce@g.o and gentoo-user@g.o too!
  
  That's gentoo-dev-announce. 'dev' is the key part. And gentoo-user@
  is doubtedly used by sysadmins.
  
  
 This one:
 
 https://archives.gentoo.org/gentoo-announce/
 
 First time I hear about it. Looks to be used primarily for GLSAs.
 I wonder if anyone actually uses it.

Answering the does anyone actually use it bit...

I'm subscribed (via gmane) and scan new message subjects, at least, 
reading messages when they (might) pertain.

Tho the GLSAs are of questionable usefulness here, since I'm on ~arch and 
update regularly enough that announced affected versions are usually 
ancient history on my boxen.  I think I've actually seen one or two that 
applied to me... in over a decade on gentoo.

But I still subscribe and at least scan titles, as for me it's part of 
being a good admin, just in case, both for the GLSAs, and in case there's 
anything else of importance posted.

Of course if the announce list was actually used for announcements other 
than GLSAs, it'd definitely enhance its general usefulness.  So please do 
start announcing stuff there -- IMO, anything fit for the front page is 
fit for the general announce list as well! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

[gentoo-dev] Re: News item review: SquashDelta syncing support

[Martin Vaeth]

Rich Freeman ri...@gentoo.org wrote:
 Downsides include:
 2.  Impossible to tweak ebuilds without setting up an overlay.  This
 might be annoying for devs/etc.

It is still possible to setup a read-writable portage tree
(using overlayfs/aufs/unionfs-fuse/... e.g. using the squashmount
tool from the mv overlay).

However, currently this does not play nicely with squashdelta:
You have to undo the mounting of squashdelta and have to use
different command (e.g. squashmount) afterwards.
Although this can probably be done e.g. in eix-sync with hooks,
I hope that in the near future there will be a possibility to
combine these methods more conveniently.

Currently, I made only some remarks in comment #3 of bug 549716,
because it seems that the sync module mechanism is currently
lacking the infrastructure for adding custom data (like hooks) to
a module.

Re: [gentoo-dev] Re: news item: nfsmount renamed nfsclient

[William Hubbs]

All,

here is the third iteration of this news item. Unless there are
objections, this will go in the tree  sometime after 13:00 utc on
2015-02-02.

William

Title: nfs service changes
Author: William Hubbs willi...@gentoo.org
Content-Type: text/plain
Posted: 2015-02-02
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: net-fs/nfs-utils-1.3.1-r1

The upgrade to nfs-utils-1.3.1-r1 includes significant service changes
both for OpenRC and systemd users.

OpenRC users:

The OpenRC service which handled mounting nfs file systems has been
changed to only start the nfs client daemons and renamed to nfsclient.
Because of this change, if you use OpenRC and mount nfs file systems,
you need to perform the following steps:

Add nfsclient to the runlevel nfsmount was in before. For example, if
nfsmount was in the default runlevel, run this command:

rc-update add nfsclient default

If you use a permanent network connection to the server, make sure
netmount is in the same runlevel as nfsclient. If not, it is recommended
that net-fs/autofs be set up to handle your network mounts.

Systemd users:

The nfs systemd units have been renamed.  If you are exporting nfs
mounts, you should enable the rpcbind and nfs-server services.  If you
are mounting nfs mounts systemd should automatically detect this and
start the nfs-client service.

More Information:

The following wiki page has more information about nfs file systems:

http://wiki.gentoo.org/wiki/NFSv4


signature.asc
Description: Digital signature

[gentoo-dev] Re: news item: nfsmount renamed nfsclient

[Duncan]

William Hubbs posted on Sun, 01 Feb 2015 17:16:30 -0600 as excerpted:

 here is the third iteration of this news item. Unless there are
 objections, this will go in the tree  sometime after 13:00 utc on
 2015-02-02.

LGTM. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

Re: [gentoo-dev] Re: news item: nfsmount renamed nfsclient

[William Hubbs]

All,

here is the latest iteration of this news item, with input from both
rich0 and radhermit.

If this is what we accept, someone might want to update the wiki and add
a wiki page about autofs setup if it isn't there already.

Let me know what you think.

William

Title: nfs service changes
Author: William Hubbs willi...@gentoo.org
Content-Type: text/plain
Posted: 2015-02-02
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: net-fs/nfs-utils-1.3.1-r1

The upgrade to nfs-utils-1.3.1-r1 includes significant service changes,
both for OpenRC and systemd users.

The nfs systemd units have been renamed.  If you are exporting nfs
mounts, you should enable the rpcbind and nfs-server services.  If you
are mounting nfs mounts systemd should automatically detect this and
start the nfs-client service.

The OpenRC service which handled mounting nfs file systems has been
changed to only start the nfs client daemons and renamed to nfsclient.
Because of this change, if you use OpenRC and mount nfs file systems,
you need to perform the following steps:

Add nfsclient to the runlevel nfsmount was in before. For example, if
nfsmount was in the default runlevel, run this command:

rc-update add nfsclient default

If you use a permanent network connection to the server, make sure
netmount is in the same runlevel as nfsclient. If not, it is recommended
that net-fs/autofs be set up to handle your network mounts.

For more information on NFS file systems, see the following URL:

http://wiki.gentoo.org/wiki/NFSv4


signature.asc
Description: Digital signature

[gentoo-dev] Re: news item: nfsmount renamed nfsclient

[Duncan]

William Hubbs posted on Sat, 31 Jan 2015 15:25:31 -0600 as excerpted:

[Proposed news item body excerpted below...]

 The upgrade to nfs-utils-1.3.1-r1 includes significant service changes,
 both for OpenRC and systemd users.

Good opening. =:^)  Or optionally, to get rid of that comma (it looks 
fine to me either way but some people seem to dislike unnecessary 
commas)...


The upgrade to nfs-utils-1.3.1-r1 includes significant service changes 
for both openrc and systemd users.


 The nfs systemd units have been renamed.  [...]
 
 The OpenRC service which [...]

I'd suggest prefixing the two separate init-system sections with the init 
system they apply to, and putting openrc first even if it's longer, since 
it /is/ the gentoo default, like so:


OpenRC: The OpenRC service which [...]

Systemd: The nfs systemd units [...]


 For more information on NFS file systems, see the following URL:
 
 http://wiki.gentoo.org/wiki/NFSv4

More information similarly...


More information:  For more information on NFS [...]


That way, people can quick-scan to the bits that apply to them, and 
putting openrc first will hopefully help avoid at least some of the 
systemd politics.  (In the absence of specific council decision to that 
effect, Gentoo needs no more rumors that openrc is being deprioritized or 
isn't going to be the default any longer, and systemd first could 
arguably look that way to some.)

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

[gentoo-dev] Re: news item: nfsmount renamed nfsclient

[Rich Freeman]

On Fri, Jan 30, 2015 at 7:57 PM, Rich Freeman ri...@gentoo.org wrote:
 On Fri, Jan 30, 2015 at 5:22 PM, William Hubbs willi...@gentoo.org wrote:

 this is covered in the nfs-utils-1.3.1-r1 ebuild by ewarns; however, qa
 asked me to write a news item as well, so here it is.


 There was a similar change in the systemd units (also mentioned in the
 ewarns).  It might make sense to add this to the news item as well.
 nfs-client is likely to be automatically handled by systemd when it
 detects an nfs mount, but nfs-server and rpcbind need to be manually
 enabled if you're running a server (that is from memory).  If you need
 me to do some confirmation on what is needed let me know.


Suggested changes attached.  Some notes:

1.  Changed title to remove the specifics, since there are several
renames when you include systemd
2.  Removed the Display-if-Installed for openrc.  Since the headers
are combined with OR as defined in the GLEP adding openrc without a
version restriction makes filtering on nfs-utils pointless.  Everybody
is going to have openrc installed anyway until we fix the functions.sh
issue.  But, if we do keep openrc then we should add systemd to the
list.
3.  Fixed the revision number.
4.  Added a systemd paragraph, and tweaked the others just slightly to
make it clear what applies to which.

-- 
Rich
Title: nfs service name changes
Author: William Hubbs willi...@gentoo.org
Content-Type: text/plain
Posted: 2015-02-02
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: net-fs/nfs-utils-1.3.1-r1

When you upgrade to nfs-utils-1.3.1-r1, you must also upgrade to
openrc-0.13.8.

As part of this upgrade, the OpenRC service that handles mounting nfs
file systems has been renamed to nfsclient instead of nfsmount, because
it starts the nfs client daemons only, and netmount now mounts the file
systems.

If you mount nfs file systems and are using OpenRC, you should add
nfsclient and netmount to the same runlevel nfsmount was in before.

The nfs systemd units have also been renamed.  If you are exporting nfs
mounts you should enable the rpcbind and nfs-server services.  If you
are mounting nfs mounts systemd should automatically detect this and
start the nfs-client service.

If you are using OpenRC, for more information on NFS file systems, see
the following url:

http://wiki.gentoo.org/wiki/NFSv4

[gentoo-dev] Re: news item: nfsmount renamed nfsclient

[Rich Freeman]

On Fri, Jan 30, 2015 at 5:22 PM, William Hubbs willi...@gentoo.org wrote:

 this is covered in the nfs-utils-1.3.1-r1 ebuild by ewarns; however, qa
 asked me to write a news item as well, so here it is.


There was a similar change in the systemd units (also mentioned in the
ewarns).  It might make sense to add this to the news item as well.
nfs-client is likely to be automatically handled by systemd when it
detects an nfs mount, but nfs-server and rpcbind need to be manually
enabled if you're running a server (that is from memory).  If you need
me to do some confirmation on what is needed let me know.

-- 
Rich

[gentoo-dev] Re: news item: nfsmount renamed nfsclient

[Duncan]

William Hubbs posted on Fri, 30 Jan 2015 16:22:38 -0600 as excerpted:

 this is covered in the nfs-utils-1.3.1-r1 ebuild by ewarns; however, qa
 asked me to write a news item as well, so here it is.
 
 Let me know what you think.
 
 Thanks,
 
 William
 
 Title: nfsmount service renamed nfsclient
 Author: William Hubbs willi...@gentoo.org
 Content-Type: text/plain
 Posted: 2015-02-02
 Revision: 2

Repeating a comment I've seen for other news items:

The Revision header is intended for machine-parsing use AFTER original 
release, in case an earlier release needed corrected and thus a revision 
other than 1.

As such, it should always be Revision: 1 when first released, and thus 
for all pre-release review postings, unless there has actually been a 
previous release and the review posting is actually reviewing a 
correction-revision of a previously released news item found to be in 
actual need of revision after release.

For those familiar with the news and mail header RFCs, think of the 
Revision header value greater than one as a Supersedes.  If the original 
was never released, there's nothing to supersede, and revision should 
always be 1.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman