Re: [gentoo-dev] Packages up for grabs: x11-misc/gmrun

2021-01-17 Thread Piotr Karbowski
Hi,

On 17/01/2021 16.57, Jonas Stein wrote:
> Dear all
> 
> the following packages are up for grabs after dropping
> desktop-misc:
> 
> x11-misc/gmrun
> https://packages.gentoo.org/packages/x11-misc/gmrun

I will grab the gmrun.

-- Piotr.



[gentoo-dev] sys-power/bbswitch up for grabs

2020-12-26 Thread Piotr Karbowski
Hi,

I've been maintaining sys-power/bbswitch in the recent times, however, I
no longer have any hardware where I can even test it. If anyone sees it
fit, feel free to grab it and join other maintainers there. I just
dropped myself out of metadata.xml.

Open bugs:
- https://bugs.gentoo.org/761370
- https://bugs.gentoo.org/613338

-- Piotr.



Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-25 Thread Piotr Karbowski
Hi,

On 25/11/2020 22.57, Georgy Yakovlev wrote:
> systemd-tmpfiles does not depend on any systemd-isms, does not need dbus,
> and is just a drop-in replacement, the only step needed is to emerge the
> package.
> it's a simple single binary + manpage, binary links to libacl and couple other
> system libs.

Can confirm that systemd-tmpfiles works fine on OpenRC systems. Been
using it since end of October.

Two things that are different in terms of interface to opentmpfiles is
that systemd-tmpfiles does not have --dry-run runtime option, and it
will complain if any /usr/lib/tmpfiles.d/*.conf uses /var/run instead of
/run, but that's just an warning.

Regardless, it's just a drop-in replacement, have not noticed any issues.

-- Piotr.



Re: [gentoo-dev] GNU Guix

2020-09-29 Thread Piotr Karbowski
On 29/09/2020 16.02, William Breathitt Gray wrote:
> Cuckoo is a spam bot. The bot assumes the first response will be a user
> pointing out that the link is dangerous. So the bot's response is to
> respond back automatically with an aggressive denial in the hopes that
> more users will continue to click the spam link.

So the day has come when a script has fooled me. Thanks for clarification.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] GNU Guix

2020-09-29 Thread Piotr Karbowski
On 29/09/2020 14.26, Cuckoo's Calling wrote:
> You are so naive and I couldn't stop laughing.

I would appreciate it If you'd refrain from sending such messages to
mailing list, either go into details when you disagree with people or
don't reply at all. Those low level flexing is not welcome here.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Stabilisation of app-admin/ansible-2.10.0

2020-09-15 Thread Piotr Karbowski
Hi,

The current state is that the Ansible in tree is not working due to fact
that it misses core modules.

I'd say 2.10.0 should be masked, as ~arch or stable arch, it does not
work, then revbump to use bundle package, not ansible-base. If
maintainer want to split it into ansible-base + separated ebuilds for
modules, then maintainer should prepare a news item, as the update
replaces working Ansible with something that cannot work by itself, and
there's no interfaces to take in rest of needed parts as by now.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages are up for grabs: zathura and co

2020-08-27 Thread Piotr Karbowski
On 24/08/2020 13.57, Mikle Kolyada wrote:
> dev-libs/girara
> app-text/zathura-ps
> app-text/zathura-pdf-poppler
> app-text/zathura-pdf-mupdf
> app-text/zathura-djvu
> app-text/zathura-cb
> app-text/zathura
> 
> 
> Are for grabs now, I do not use them daily anymore. A separate active
> maintainer needed.
> 
> 

I will take over zathura packages since I use it on daily basis.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-11 Thread Piotr Karbowski
On 11/08/2020 15.38, Joonas Niilola wrote:
> 
> On 8/11/20 11:36 AM, Jaco Kroon wrote:
>> And I've already provided you one use case where udev doesn't work well
>> but eudev does.  I've also mentioned some historic issues I believe
>> should already be fixed but which did bit me in systemd-udev which was
>> never a problem in eudev.
>>
> Your systems seem to diverge a lot from what I'd consider as 'default'.
> You must already make many changes to them.
> 
> Before this thread I didn't even know/remember I was using eudev. It
> works and there doesn't seem to be any global issues related to it.
> However after reading this thread I'm a bit considered about the
> maintenance state of it.
> 
> Switched to udev. Simple as 'emerge -1 sys-fs/udev'. It works, didn't
> notice any difference.
> 
> If musl is a problem, to my knowledge musl has its own stage images, so
> why can't those stages use eudev while other ones defaulting to udev?

For the sake of science, I've also moved one of my systems to
sys-fs/udev and noticed a single incompatibility. There are few ways how
to disable the systemd/udev predictable NIC names, one of them is to
boot with net.ifnames=0, another is to mask rule file that trigger the
rename, as described on wiki[1]

Long story short, on eudev it's 80-net-name-slot.rules, on udev it's
80-net-setup-link.rules

The result was that my system booted without working network, as connman
started to poke around Ethernet interfaces (this is ok, I had
blacklisted eth*, not enp*), which then resulted in switching routing to
Ethernet that failed to get IP from DHCP, even that WiFi had a fully
working Internet access, so more like connman bug. (And yes, I am aware
that net.ifnames=0 will work on both)

This however shows two things: eudev is (no longer) drop-in replacement,
as some interfaces changed in upstream udev, which leads to second
thing, we need to have migration path, because even if(!) Gentoo change
default (I am not a fan of this idea really), then it might lead to
people doing fresh installation or reinstallation, migrating their
configs resulting in not working systems/working in other way that
previous one.

[1] https://wiki.gentoo.org/wiki/Udev#Keep_classic_.27eth0.27_naming

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Piotr Karbowski
Hi,

To summarize

- There's no known bugs in eudev that are not in udev
- There's no bug that would be fixed by switch from eudev to udev
- There's no new feature that would change eudev to udev bring
- Currently musl and glibc profiles uses common eudev, after change we
whould have musl profile users use something that glibc users are not using
- You don't like the original decision to switch to eudev so you want
now to use uno reverse card.
- eudev have single maintainer, but so far it did not had negative
impact on Gentoo

I see no reason to switch to sys-fs/udev by default, up until there's
actually a technical reason behind it. The eudev is a thing because
systemd upstream made it clear that they have no intention into keeping
udev operational unless it runs under systemd, which is quite important
here.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Last-rites: net-p2p/nicotine+

2020-07-18 Thread Piotr Karbowski
Hi,

On 18/07/2020 15.09, Andreas Sturmlechner wrote:
> # Andreas Sturmlechner  (2020-07-18)
> # Stuck on Python 2, depends on deprecated dev-python/pygtk, bug #708162.
> # Needs a maintainer and >=2.0.1 version bump. Masked for removal in 30 days.
> net-p2p/nicotine+
> 

Will pick it up.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-dev-announce] Last rites: */* More Py2 only items

2020-06-29 Thread Piotr Karbowski
On 29/06/2020 02.35, Aaron Bauman wrote:
> [...]
> net-dns/maradns

There's single python script that can work with Python3 (at least in new
version) that does that can just use any Python version.

I see that it did not got update for over a year, will take it over now and push
update tomorrow, then drop your mask on this package.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


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

2020-06-22 Thread 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

2020-06-22 Thread 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


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

2020-06-22 Thread 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


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

2020-06-21 Thread 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


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

2020-06-21 Thread Piotr Karbowski
Hi,

Please find news item attached.

-- Piotr.
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] Packages up for grabs

2020-05-27 Thread Piotr Karbowski
Hi,

On 27/05/2020 01.31, Brian Dolbec wrote:
> * dev-python/boto3
> * dev-python/botocore

Do you mind if I join you on those? I use them a lot, and I planned to
comaintain awscli since Patrick is the only one current maintainer of
those, boto3 is vital part of it too.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.

2020-05-26 Thread Piotr Karbowski
Hi,

On 26/05/2020 09.23, Philip Webb wrote:
> 200526 Piotr Karbowski wrote:
>> On 26/05/2020 00.34, Philip Webb wrote:
>>> I'ld rather you didn't.
>> You didn't provided any rationale for that.
> 
> I thought I did (smile).
> 
>> Running X as root is anti-pattern, especially nowadays
>> when so little effort is required to not have to run it as root.
> 
> I've never run X as root : it's not the UNIX way.

I am not sure if you're trolling me here, or you genuinely not
understand that regardless of what user you execute `startx` on, if Xorg
have suid, it will start as root.

>> You can either enable elogind
> 
> Why would anyone want to abandon the long-successful UNIX method
> & adopt some complex replacement ?

I wouldn't call running X as root to be long successful UNIX method.
Back in the days there was no way to ran X without root, now there is.

>> or you can enable suid if you want to preserve your status quo,
>> we're talking here about defaults
>> that user can change if he has a reason to do so.
> 
> Yes, this is a regular problem which is unavoidable :
> what should the default be ? -- I want the default to be
> what it's always been & what matches basic UNIX principles.
> I can add 'suid' to 'xorg-server' in  package.use ,
> but why should I have to ? -- over to you for a rationale (smile).

I am not sure what kind of UNIX principles you're speaking about, the
default should be reasonable, running X as root is not, if someone want
to go against common sense and run X as root, he can do so, with
defaults to not run it as root.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.

2020-05-26 Thread Piotr Karbowski
Hi,

On 26/05/2020 00.34, Philip Webb wrote:
> I'ld rather you didn't.

You didn't provided any rationale for that. Running X as root is anti
pattern, especially nowadays when so little effort is required to not
have to run it as root.

You can either enable elogind, or you can enable suid if you want to
preserve your status quo, we're talking here about defaults that user
can change if he has a reason to do so.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.

2020-05-25 Thread Piotr Karbowski
Hi,

For years the xorg-server in Gentoo was defaulting to be running with
suid, even those that does not really require it, like systemd users and
those who runs elogind still end up with X as uid 0 because of +suid
default.

Times has changed, we now have +elogind in desktop profile, xorg-server
can no longer work without udev (due to input drivers), so there's no
real benefit for defaulting to suid.

There are 3 common ways the xorg-server is started:

- via XDM of some sort, usually forked as root, does not require suid,
systemd or elogind.
- via better XDM that can into logind interface, started as regular user
thanks to logind interface provided by either systemd or elogind.
- via `startx`, if systemd or elogind are present, can work without
suid, without them, suid is required.

Flipping current '+suid (-)elogind' as *default* USE flags on ebuild
level into '+elogind (-)suid' will not affect first two use cases, and
affect only 3rd one if neither systemd is used, or elogind is enabled.

What I'd like to go with is to enable elogind and disable suid on ebuild
level. The systemd profiles have use.mask for elogind, meaning it's not
a problem for them. and those who do not want to use any logind provider
can still opt-out out of it and go back to use suid. It shouldn't really
affect most of the users in any negative way, if anything, it will make
more users to not run Xorg as root, which is a positive aspect.

The alternative way would be to enable elogind on default profile,
however it would also affect those who run headless Gentoo, of which a
lot refuse to use any login manager.

So, dear people of Gentoo, what do you think about turning the current
possible opt-out of Xorg as root into possible opt-in for running Xorg
as root? People still will have a choice, just the defaults will be more
sane.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: x11-drivers/xf86-input-{keyboard,mouse}

2020-05-03 Thread Piotr Karbowski
# Piotr Karbowski  (2020-05-03)
# Obsolete input drivers, use x11-drivers/xf86-input-libinput
# or x11-drivers/xf86-input-evdev instead.
# Removal in 30 days.
x11-drivers/xf86-input-keyboard
x11-drivers/xf86-input-mouse

For more information see
https://gitweb.gentoo.org/data/gentoo-news.git/tree/2020-04-03-deprecation-of-legacy-x11-input-drivers/2020-04-03-deprecation-of-legacy-x11-input-drivers.en.txt

-- Piotr.



signature.asc
Description: OpenPGP digital signature


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

2020-04-02 Thread 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.

2020-04-02 Thread 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] News item: Deprecation and removal of legacy X11 input drivers.

2020-04-01 Thread Piotr Karbowski
Title: Deprecation and removal of legacy X11 input drivers.
Author: Piotr Karbowski 
Posted: 2020-04-02
Revision: 1
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 fraction-less 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 that still runs 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
and update @world with new USE flags

# emerge -N @world




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-18 Thread Piotr Karbowski
Hi,

On 18/12/2019 22.08, Michał Górny wrote:
> I know that's an unhappy idea but maybe it's time to include CMake
> in stage3.  Then it would be just a matter of temporarily enabling
> bundled libs for stage builds, I guess.

Not sure what's unhappy about it, but I like the idea, it will be
painless for new users with rather limited cost of ownership on Gentoo side.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers

2019-10-21 Thread Piotr Karbowski
Hi,

I'd like to bring the topic of defining default policy to do changes to
packages within ::gentoo that one does not maintain.

This topic goes back from time to time on #gentoo-dev, and as I was
told, it was originally sent to gentoo-dev mailing list by robbat2 (I
failed to find this in archive, so if anyone have copy of it, please share).

Current policy is to never touch ebuild that one did not claim as
maintainer unless maintainer of said package allowed you to do so.

This is a bit unhealthy, especially when some developers that maintain
packages are out of reach, or the patches to update ebuild just rot on
the bugzilla and are not taken in by maintainers.

What I'd like to end with would be to set a policy that allows any
developer with write access to ebuilds tree do changes that are small in
scope, like a minor bug fixes, adding missing flags, version bumps,
anything, that does not require complete overhaul of ebuild, with the
option to set in metadata.xml that policy for specified package is to
deny anyone but maintainers from doing changes.

The packages that would require a flag to prohibit non-maintainers from
doing changes would of course be those of toolchain, or other big in
user base packages that are in very good shape, as in gnome packages,
kde packages, X11 packages and so on.

Of course, the policy would also define, that if there are any bug
introduced by changes that non-maintainer made, it's responsibility of
those who did the change in first place to fix it and clean any mess
that it has created.

I personally am fine with others doing changes to packages I own, as
long as they won't break anything and I do know from the discussion on
#gentoo-dev, that there are others who have similar opinion about it.

Those who feel territorial and those who believe only maintainers should
maintain specified packages can just set the flag in metadata.xml and
continue with the current state of things for their packages.

The reason why I would like to get default policy to allow-all is that I
do not believe most of developers would want to go around all the
packages they own and set it manually to allow others doing changes even
if they're fine with others touching those packages.

What do you think folks?

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

2019-09-29 Thread Piotr Karbowski
Hi,

On 29/09/2019 11.56, Michał Górny wrote:
> WDYT?

You mean using HTTPS-only mirrors in 3rdparty mirrors? I am on board
with that.

Ideally, we would switch all of Gentoo resources to HTTPS too. I had a
short discussion about it in #-infra where I was looking for distfiles
and stage3 snapshots mirror roundrobin that is https enabled, this of
course require a huge changes and it unlikely come anytime soon, but for
what's it worth, I think no official Gentoo resource should default to
non encrypted HTTP, and the only http enabled traffic should be a 301
HTTP redirect to https address.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] dev-python/fabric up for grabs

2019-05-11 Thread Piotr Karbowski
On 11/05/2019 18.00, Virgil Dupras wrote:
> Although I don't use it anymore because I find it too heavy for my
> needs, Ansible is generally seen as a good replacement.

FWIW Ansible does not seems that heavy when you realize that you can put
a exec bit on a playbook, set shebang to ansible-playbook, set it to
being a locally executed and define tasks within playbook itself, like:

#!/usr/bin/env -S ansible-playbook -i localhost,

- name: playbook
  gather_facts: false
  connection: local
  hosts: localhost
  tasks:
- name: foo
  debug:
msg: 'blah'

Gets the job done really well.

-- Piotr.



Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Piotr Karbowski
Hi,

For time being the IUSE has been reverted to the old +suid, elogind is
now opt-in and not enabled by default. This preserves the old,
working-for-everyone-everywhere default flags.

-- Piotr.


pEpkey.asc
Description: application/pgp-keys


Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Piotr Karbowski
Hi,

On 22/03/2019 21.47, Andreas Sturmlechner wrote:
> Therefore, not one single package, unless it hard-depends on exactly-one-of ( 
> elogind systemd ) should enable elogind by default at this time. Doing so now 
> only makes people switch it off globally either before or after they are 
> facing 
> runtime issues.
> 
> Let's fix the remaining bugs, create a proper news item in advance, and then 
> switch over desktop profiles to elogind as the new default.

So, what you propose is to go IUSE="+suid elogind" on xorg-server for
now, until elogind has full blown support, and then enabling +elogind in
desktop profile?

I am not a big fan of that, but for sure, that would address the issues,
however I am really worried about what to do later with xorg-server. I
*really* do not want suid to be enabled there by default permanently, if
we go the following route, do you think it's feasible to then still
default to +elogind -suid on xorg-server? I understood now that
consolekit clash with elogind, but maybe it's something to handle on
consolekit level, to block elogind from being installed?

This way the users of default profile would defaults to elogind on
xorg-server, and if they desire to use consolekit, they will need to add
-elogind for xorg-server, and adding +suid if they do not use DM that
starts X for them as root.

-- Piotr.


pEpkey.asc
Description: application/pgp-keys


Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Piotr Karbowski
Hi,

On 22/03/2019 21.43, Brian Evans wrote:
> What are the implications, if any, of using DMs which are not aware of
> {,e}logind?  Do they work without modification?

My understanding is that such DMs, like lightdm, fork X as root anyway,
so there's no implication here, regardless if you have -elogind or
+elogind on xorg-server. Even more, you can have -suid -elogind -systemd
on xorg-server for lightdm and it will work, as again, it starts as root.

The relation between xorg-server and elogind is that pam_elogind.so
provides user upon login with variables like $XDG_VTNR, that Xorg then
uses, when you start X as user, to start X on the very same virtual
terminal that one logged in, and then, elogind (started via dbus or
manually) pass the SETMASTER ioctl.

-- Piotr.


pEpkey.asc
Description: application/pgp-keys


[gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Piotr Karbowski
Hi,

I'd like to discuss here the current state of elogind integration as a
whole, and the follow-up work that is now required, after I've put a
default on local USE flag +elogind on xorg-server while dropping default
suid flag in my commit yesterday.

The motivation on the changes was to follow up the removal of default
+suid that happened in November last years, that sadly had to be
reverted. Now with elogind integration, non-systemd users got all that
they need to run Xorg as a unprivileged user.

The status of xorg-server at this very moment is that it no longer
defaults to be merged with suid, however, now it defaults to +elogind.
This have the following implications:

- User will be prompted that pambase requires +elogind, which is not
enabled by default -- meaning that simple `emerge xorg-server` will
prompt user to add package.use entry. This could be solved by always
having the elogind bits enabled, the same way a gnome-keyring is, so the
pam_elogind.so is used if present. This shouldn't have any negative
effect on for instance systemd users, as systemd cannot be installed at
the same time as elogind.

- systemd users that does not use systemd profiles will be required to
alter package.use or make.conf USE flags definition to drop -elogind
there, as otherwise xorg-server will refuse to be merged due to
at-most-one-of ( elogind systemd ) condition there. However those
systemd users that do use systemd profiles will not run into any things
to do, as systemd's use.mask have elogind there.

- The desktop profiles enables +consolekit, which conflicts with elogind
-- the users of those profiles will need to adjust USE flags.

- OpenRC/non-systemd users are now able to run X without suid, as
elogind is the entity that wraps the SETMASTER, no more "ioctl
permission denied" on starting X as unprivileged user.

After speaking with some of you on #-dev and #-desktop I know that the
opinions on that vary, arguably enabling elogind local USE flag on
xorg-server was somewhat ahead of time, leaving some users in
unfavorable position where the xorg-server installation will require
them to manually modify package.use/make.conf.

Some of the ideas that were pointed on IRC (forgive me if I missed some):

- We should go back to +suid -elogind default.
- We should actually NOT put suid on Xorg if USE="suid elogind" but put
suid bit with USE="suid -elogind".
- We should only ever enable elogind in desktop profiles.

Personally I'd like to stay without enabling suid by default on
xorg-server, as otherwise hardly anyone will ever drop the suid from it,
which would be a big step back. Gentoo tried to drop suid from
xorg-server a handful of times, let's make the current one a final one :)

I'd like to propose doing the following:

- Keywording elogind on missing archs
- Making elogind a global USE flag
- Switching desktop profiles to elogind from consolekit while still
preserving -suid +elogind on xorg-server for those that does not use
desktop profiles (systemd profiles users not affected)
- Making pambase always install the configuration for pam_elogind.so,
the same way it does for pam_gnome_keyring.so at this very moment,
effectively removing elogind USE flag from it.

What do you all think about?

-- Piotr.


pEpkey.asc
Description: application/pgp-keys