Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
Hi, On 31/05/2023 13.43, Andrey Grozin wrote: Hello *, wxGTK:3.2-gtk3 is now stable. But there are 98 ebuilds depending on wxGTK:3.0-gtk3 and only 22 ebuilds depending on wxGTK:3.2-gtk3 in the tree. Probably, in a vast majority of cases 3.0 can be simply replaced by 3.2 without any negative consequences. What could be a reasonable way to organize the transition 3.0 -> 3.2 in the tree? File a zillion bugs? The fact that this dependence is written in a special syntax WX_GTK_VER="3.0-gtk3" makes such a transition more difficult. Unlike the normal dependency syntax, it is not possible to write something like x11-libs/wxGTK:*= This is unfortunate. The 3.0 -> 3.2 transition absolutely requires to edit ebuild texts, unlike :*= where the same ebuild can work with different slots (just a recompilation is sufficient for transition). This fact makes it impossible for an ebuild to work with both slots. In a majority of cases, I suppose, it would be desirable to allow an ebuild to work with any of these 2 slots, without a necessity to edit it. But, alas, this is not possible. Andrey There's at least a few project that will not work with new wxGTK, out of what I know that is in tree the SuperSlicer and the PrusaSlicer that in the version currently in tree requires wxGTK 3.0. The newer version of PrusaSlicer actually requires wxGTK 3.1 and does not work well with 3.2, unless the wxGTK 3.2 is built with '--disable-glcanvasegl', but this is not interfaced as USE flag and I doubt ever will be. Filling bugs might be the way to go, but please keep in mind that some software might be borderline impossible to switch to new wxGTK therefore a 3.0 would need to stay in tree for extended period of time. -- Piotr.
[gentoo-dev] net-misc/axel: up for grabs
Hi, The net-misc/axel is up for grabs. There are no open bugs and the in-tree version is the latest. To the best of my knowledge there's nothing pending around axel to update or fix I however no longer use it, perhaps someone else would like to take it over. Dropped to m-n. -- Piotr.
Re: [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with
On 12/12/2022 23.06, Sam James wrote: It's unusual to have discussion about a single package on the mailing lists. I tend to keep an eye on PAM bugs because I maintained pambase. Bugs are the primary method of discussing changes to packages. You really came strong on this one. I did explain why it went to mailing list, that very few people would notice bug on undeclared maintainer-needed package, unlike mailing list, assigning it to zlogene and hoping for few people to catch it up, yet you still zealously challenge it. I feel really burnt out from this exchange and I see that you already base-system'd the sys-libs/pam tactically preventing me joining and introducing changes, last time I wanted join base-system there was push back and I was informed that only invited members can join. Do your thing Sam, I will step back now and will take note to throw ideas into void of bugzilla next time. -- Piotr.
Re: [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with
Hi, On 12/12/2022 06.52, Robin H. Johnson wrote: Please do file a bug tracking this proposal, and reference the discussion thread. On Sun, Dec 11, 2022 at 09:28:14AM +0100, Piotr Karbowski wrote: What I'd like to do is to bump the limits.conf we ship with pam to following * hard nproc 16384 * soft nproc 16384 * hard nofile 16384 * soft nofile 16384 Those are still reasonable defaults that are much more suitable the modern systems. I can only see benefits in it and am unable to think about the potential drawbacks of bumping *defaults*. Drawbacks: - The "*" would apply it to all users on a system, not just the interactive ones, and reduce overall security posture. - Does this also need a sysctl change for raising fs.file-max? With those in mind, how can we deploy these defaults for interactive users, while still trying to maintain the good security posture overall? - Is using "@users" instead of "*" good enough? (I think yes) - Should it be limited to shiny logins on X or should it also take effect via remote logins? (conceptually yes, but I don't see a way to do it today within the scope of only pam_limits**) ** The closest other solution I can find is using a distinct limits.conf for interactive logins, selected via pam.d trickery, and I don't like that proposal. Since both you and Sam requested bug[1], so be it -- though I still find it excessive and I do not remember any other case where discussion about change in package were tracked in bug, I just hope it will not branch discussion to be in two places, navigating it would be difficult. Looks like I have some backtracking to do. I pulled off latest stage3 and seems like the limits.conf there have no entries by default, I do however have the nproc limit there on 2 old gentoo systems dating back into 2009, perhaps at some point limits.conf have it and I do not remember adding it there, so either it could be default at some point in time, or I added it and forgot, with the later being more likely. Apologies for confusion. Regardless I'd like to continue the discussion about the new Gentoo's defaults. Which makes the current defaults being inherited from kernel, though pid 1 to all the children, which are For the 32bit x86: limitsoft hard nproc6409564095 nofile 1024 4096 And for the 64bit x86 limitsoft hard nproc256819 256819 nofile 1024 4096 The fs.file-max does not need any change, on 32bit x86 it's 1636118 and on 64bit x86 it's 6574089 What I propose here is to significantly bump the limit of open files per user, and limit the number of PIDs per user to 16k. If anything, the current defaults allow you to make a DoS by forkbomb, the current defaults are neither secure nor make sense in 2022. Linux kernel is full of defaults that beg to be updated, among others, vm.swappiness makes absolute no sense in its current defaults either. As for the remote logins, local logins and X sessions -- I see no value in having different limits across those. [1] https://bugs.gentoo.org/885589 -- Piotr.
Re: [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with
Hi, On 11/12/2022 13.46, Sam James wrote: You should still file a bug for two reasons: 1. Paper trail 2. sys-auth/pambase has another maintainer who*is* active :) As for the question in your post, I'll have a think. Thanks! I am not against creating a bug, I do see it however as inefficient in this very case. I do know however if I were to create bug and assign it to current single pam maintainer, it would hardly get noticed by other people, greatly reducing the feedback. Changing defaults will affect vast majority of Gentoo users, so gentoo-dev ml was the place I choosen. I didn't realized that you are maintainer of pambase, though the /etc/security/limits.conf belongs to sys-libs/pam that has only zlogene. I did mail zlogene regarding another package recently and got no response, thus pam itself seems maintainer-needed to me, and because of it a candidate for me to join as another maintainer and do the changes. I do not think it would make much sense for me to then create bug for myself to make this change of defaults, paper trail would be the commit subject and message itself, or perhaps I did not understood of what you meant here by paper trail, would appreciate clarification. It would be great if you were interested in joining pam itself, and I am interested to also joining pambase, since those are so co-dependent it does not make sense to have split maintainers there. -- Piotr.
[gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with
Hi,
I'd like to touch base on the topic of pam_limits and the defaults that
we ended up with in Gentoo.
Currently on default system installation without any modification to
/etc/security/limits.{conf,d/*} user will end up with limit o 1024 of
file descriptors and 4096 limit of threads.
Most of limits.conf makes a lot of sense on systems that are meant to be
used remotely by many people simultaneously and have much less of
importance on single user desktop systems.
Recently I've been haunted by random and and not reproducible failures
of random applications during runs with ffmpeg's libsvtav1 integration.
Having a 4 instances of ffmpeg with was enough to get me random
failures, terminals not to open, up until I actually seen in shell
'cannot allocate resource' while trying to run a script.
Turns out, I was running over the limit of 4096 threads, as nproc
somewhat suggests this is limit of processes, it is actually a limit of
PIDs, and every thread gets its own pid.
I have strong opinion on this one, that users that runs multi users
systems will be well aware of the need to tune limits.conf of
pam_limits, while the users that will actually suffer are the regular
Joe that just uses Gentoo as a single user system.
What I'd like to do is to bump the limits.conf we ship with pam to following
* hard nproc 16384
* soft nproc 16384
* hard nofile 16384
* soft nofile 16384
Those are still reasonable defaults that are much more suitable the
modern systems. I can only see benefits in it and am unable to think
about the potential drawbacks of bumping *defaults*.
Any thoughts?
Unless there's strong opposition to not bump those 1024/4096 current
defaults, I'd like to bump those limits. Normally I'd create a bug and
assign it to maintainer, however our sys-libs/pam maintainer has not
been seen in last half a year, so I'd end up joining as co-maintainer
there in the result.
-- Piotr.
[gentoo-dev] Package up for grabs -- net-ftp/proftpd
Hi, net-ftp/proftpd is up for grabs. There's a handful of bugs open for proftpd and pending version bump. Dropped myself out of maintainers as rclone serve sftp has long replaced proftpd's mod_sftp for me and it's been quite a while since I last time used it, unfortunately I was the very only maintainer on this package, it now sits as maintainer-needed, hopefully someone who still uses it will step up and takes it over. -- Piotr.
Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
Hi,
On 23/11/2022 08.38, Michał Górny wrote:
Hello, everyone.
TL;DR: I'd like to add sys-meta/{cpio,sh,tar} to install and control
(via USE flags) /bin/{cpio,sh,tar} symlinks.
I am very much in favour to have a package that controls those symlinks.
What is not immediately clear to me is what would that mean for eselect
in long run. Is it so that you'd like to keep eselect around and alive
parallel to those sys-meta category packages, or would there be push to
eventually get rid of most of eselect and where possible switch to sys-meta?
-- Piotr.
Re: [gentoo-dev] Disturbing state of arch testing in Gentoo
Hi, On 06/11/2022 09.15, Michał Górny wrote: On top of that, it seems that most of it still relies on proprietary software and we have no clue how*exactly* it works, and it's really, really hard to get a straight answer. I never understood how it become socially acceptable in open source project that Gentoo is that one of the important automation that does tinderboxing is closed source and gate kept, meaning no one can on their own reproduce the failures, which is utterly annoying when your normal testing just works, yet their testing methodology is a secret. I would be in favour of stepping up the social contract and actually prohibiting this kind of things, we had that before too, the nattka you mgorny wrote is replacement for old bugzilla bot that was ... closedsource and perished, though nattka now have way more features than the old thing ever had. -- Piotr.
Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?
On 29/10/2022 22.35, Piotr Karbowski wrote: On 29/10/2022 21.01, Matt Turner wrote: lld isn't a dependency of llvm; it's the same reason why llvm:N doesn't depend on clang:N. That's fair. Still a bit of a bummer that we cannot guarantee a frictionless support for clang-based kernels, in a sense that your system could pull new update of llvm and clang, but will not automatically add new slot for lld, which means unless you manually install lld:NEW_SLOT your 'make LLVM=1' will fail, as it will pick wrong LD from another clang version. Disregard, as long as you have lld in world file or any set, it will be updated. In my case I only had firefox that explicit pulled in slot 14. PEBKAC. -- Piotr.
Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?
On 29/10/2022 21.01, Matt Turner wrote: lld isn't a dependency of llvm; it's the same reason why llvm:N doesn't depend on clang:N. That's fair. Still a bit of a bummer that we cannot guarantee a frictionless support for clang-based kernels, in a sense that your system could pull new update of llvm and clang, but will not automatically add new slot for lld, which means unless you manually install lld:NEW_SLOT your 'make LLVM=1' will fail, as it will pick wrong LD from another clang version. -- Piotr.
Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?
On 29/10/2022 18.22, Matt Turner wrote: Have you seen these commits? I did not, thanks. Seems like the solution. Is there a reason why llvm:N do not pull in lld:N in that case? -- Piotr.
[gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?
Hi,
The state for this very moment is that we can have many versions of llvm
around, however we can at most have only one ld.lld installed. Usually
matching the lowest version of clang installed.
THis leads to build failures if one attempts to build some (but not all)
software, Linux kernel being one of them.
Currently if one have installed clang in 15 and 14 version, and ld.lld
in 14, and attempt to build Linux kernel with simple 'make LLVM=1' it
will fail on the mismatch between clang and ld.lld with "Opaque pointers
are only supported in -opaque-pointers mode".
This can be easily handled by doing 'make LLVM=1 CC=clang-14'.
Now, the problem is with kernel modules that are in ::gentoo. One of the
examples is ryzen_smu that has github's PR to support kernels built with
clang and lto enabled.
I might be not really up to the speed with llvm in gentoo, but it
appears to me we have no interface to get matching clang+lld paths that
could be callable like ts-getCC is. Setting CC=${CHOST}-clang when
kernel's config has LLVM toggled will result in crash due to ld.lld
mismatch, easy workaround would be to set $PATH before calling emerge so
it would first find the matching 14 version, however emerge will build
its own $PATH, ignoring whatever we provided there.
Which means one would either need to write a code in ebuild to get lld
version and then set CC to ${CHOST}-clang-${LLD_MAJOR_VERSION} or have
similar code in /etc/portage/bashrc, neither of which are particularly
appealing to me even though it's rather simple to get the version out of
ld.lld.
Before I invent such a atrocious code in ebuild, do you perhaps have any
solution that is somewhat more reasonable than ebuild doing backflips to
figure out working toolchain combination?
-- Piotr.
[gentoo-dev] Up for grabs: x11-terms/xterm
Hi, x11-terms/xterm is looking for a new home, feel free to grab it. -- Piotr.
[gentoo-dev] Last-rites: dev-python/ssh2-python
# Piotr Karbowski (2022-09-25) # No package in tree depends on dev-python/ssh2-python. Masked for removal. # Removal on 2022-10-25. dev-python/ssh2-python
[gentoo-dev] Package up for grabs: net-dns/maradns
The net-dns/maradns is looking for a new maintainer. Initially when I took it over I did some much needed refresh around the fact that maradns is split into maradns, deadwood and duende, however soon after that I stopped using maradns and failed to maintain the package in a good shape. There's version bump pending as well as some bugs. Feel free to take it over, otherwise we might need to remove it from tree. -- Piotr.
[gentoo-dev] Last rites: dev-python/jikanpy
# Piotr Karbowski (2022-06-26) # Abandoned upstream, depends on API that no longer exists. # Removal on 2022-07-26. dev-python/jikanpy
[gentoo-dev] Last rites: net-misc/realtek-r8152
# Piotr Karbowski (2022-03-25) # Abandoned upstream, officialy limited to kernel 5.6, # no longer builds with kernel >=5.14. Use kernel's # CONFIG_USB_RTL8152 and CONFIG_USB_USBNET since 5.13. # Removal on 2022-04-25. net-misc/realtek-r8152
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On 18/01/2022 00.24, Georgy Yakovlev wrote:
Hi,
I've been approached multiple times with that request, and a lot of
time I see new users completely destroyed by rust build time and disk
space requirements.
WDYT about switching order of rusts in a virtual?
RDEPEND="|| (
~dev-lang/rust-${PV}
~dev-lang/rust-bin-${PV}
)"
becomes
RDEPEND="|| (
~dev-lang/rust-bin-${PV}
~dev-lang/rust-${PV}
)"
Existing installs should be unaffected ofc.
But portage may prefer to depclean rust and not rust-bin if both are
present.
Users who wish to use source version at all times can just add it to
world file.
I see both positives and negatives of doing that, but would like to
reach out to community first.
I would prefer to have source based one first.
Ideally we'd have some way to mark binary packages with new EAPI and
have FEATURES flag like 'prefer-binary' and go with -bin in case there's
|| ( ) dependencies list, regardless of the original order in virtual.
This way everyone could be happy and not choose one workflow over another.
-- Piotr.
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
On 04/01/2022 20.18, Michael Orlitzky wrote: On Tue, 2022-01-04 at 19:26 +0100, Piotr Karbowski wrote: And none of which happens unless you intentionally trigger it. ... Sure, acl and how chmod manipulate mask on ACL-enabled entities is not very simple, but nothing will break by itself just because you have acl support enabled, you would need to try very hard to run into problems. Even if you're right, and if no other tools invoke tar, and the user is smart enough not to copy/paste commands from the web, and if no other archivers can extract ACLs when invoked directly or indirectly... you're still burdening the user to either have faith that this is all true, or to verify it himself. Repeat the argument for other flags like ipv6, and you wind up requiring either a lot of faith, or a lot of diligence, both of which are antithetical to basic principles of security. You may not buy the argument, but it's why people disable this stuff, and the ability to disable it is why a lot of our users user Gentoo to begin with. I was challenging here your opinion that most people should disable acl support. And what I showed is that, by keeping it enabled, does not bring on you potential problems beside possible security issues in the code that you keep around and not want to have around. Sure, there are valid reasons to strip things from kernel, I've seen some tor nodes running kernel without input devices all out of initramfs, such usecase do make sense. However I am strongly against opinion that most people should not enable acl, unless you have 16 MB NOR flash storage and every kB of kernel image counts, but then it's unlikely that you'd use gentoo there in the first place, since bundling headers and whole toolchain would east a lot of storage. I know there are people who love to disable things, there are even people who says that pam is bloatware and strip it, or people who, security reason as they claim, refuse to use logind provider (elogind or systemd) and instead choose to run Xorg as root. -- Piotr.
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
Hi, On 04/01/2022 18.35, Michael Orlitzky wrote: On Tue, 2022-01-04 at 12:03 -0500, Mike Gilbert wrote: I disagree with the claim that "most people" should disable ACL support at build time. That just gives you partially functional tools. The ACL behavior can generally be controlled using runtime options. I understand why people would disagree in this case, but isn't that a an argument for having the flag? There are plenty of great uses for ACLs, but unless you're extremely knowledgeable, they also add a million new ways to compromise your system. For example, if you untar a file with a default-ACL'd directory in it and don't notice the little plus sign, you might wind up unknowingly creating world-writable files. Even if you do notice the ACL, you have to be an expert in the interaction between umask, permission bits, the ACL mask, effective permissions, conflicting ACLs, and all of the tools you're using to understand what will actually happen or how to properly fix it. It's not something normal people can handle. And none of which happens unless you intentionally trigger it. 1. To have ACL break things on new (extracted) files you'd first need to have default ACL set on parent directory where you extract to -- otherwise they won't be carried and no problem 2. unless you add --acl to both create and extract, no acl will be added to tarball and/or extracted onto system Running 'tar --acl ...' or 'setfacl -d ...' does not happen by accident and argument that you should disable acl to not run into issues with above does not make much sense. Sure, acl and how chmod manipulate mask on ACL-enabled entities is not very simple, but nothing will break by itself just because you have acl support enabled, you would need to try very hard to run into problems. -- Piotr.
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
Hi, On 04/01/2022 18.03, Mike Gilbert wrote: On Tue, Jan 4, 2022 at 12:31 AM Michael Orlitzky wrote: On Tue, 2022-01-04 at 03:38 +, Sam James wrote: ACL is kind of similar to what Ionen said for PAM, i.e. sometimes people may want to turn it off and it makes sense to expose this option for those who do, but we don't need to try support it. This is another important one. It has security implications, is highly confusing, requires kernel support, and is nonstandard as a USE flag and as an implementation. Most people should have it off to avoid surprises, but disabling it in the kernel can make the userland software complain when explicitly built with ACL support. I disagree with the claim that "most people" should disable ACL support at build time. That just gives you partially functional tools. The ACL behavior can generally be controlled using runtime options. Also, you might be able to get away with disabling ACL support on a server, but desktop users will want ACL support enabled to get properly functioning udev rules. I second this. As far as Desktop is concerned acl is basic feature that should be there along with extended attributes, for example, I am pretty sure systemd-login will use acl to grant access to inputs in /dev for the logged user. acl is as much needed as support for multiple users (CONFIG_MULTIUSER), and it also needs support on kernel level, because without this symbol hardly anything will work for you. What I mean here is that argument 'needs support in kernel' is not a problem, because everything does need a support in kernel. Try to boot without CONFIG_FUTEX as example, it can be disabled so you could say that it needs support in kernel in a way to constitute that this is something bad and thus should be avoided. -- Piotr.
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
Hi, On 03/01/2022 18.16, Alec Warner wrote: I'm trying to understand your principles here. Like on what basis do you remove or add flags (in general). My principals is to end-user experience over exposing as much as possible as USE flags. A real life example media-sound/deadbeef The .mp3 support can either use libmad or libmpg123. The first one is dead upstream, while code work currently with it, because it is dead, I rather avoid some setups where users setup +mad instead of +mpg123 that are mutually exclusive and run into some issues, like crashes, that would waste a lot of time on debugging it, so I made it that mp3 depends on libmpg123 without option for libmad. Some overlay-provided ebuilds for it do have option for libmad, I decided to not include it. If you'd decide to give user a choice, you would make it as USE flag, but from end-user perspective it does not provide any benefit, and from maintainer perspective it's better to reduce error surface. Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam shared, does not make sense to be togglable. -- Piotr
Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
Hi, On 02/01/2022 01.03, Scott Ellis wrote: Your `ipv6` USE flag hits home - I don't use IPv6, nor do I want to have IPv6 support built into things (just another potential "thing" that I have to secure, or errors/warnings I need to suppress since I run an IPv6-less kernel). If there needs to be a path to culling USE flags, perhaps looking to which flags actually cause packages to pull in additional dependencies (vs solely enable/disable a feature) would be a better place to start? And here I am having a deja vu, an associate of mine who happens to use Gentoo also intentionally runs without IPv6. When we were traveling out of country he was unable to use WIFI hotspot that I was connected to, turns out, it was IPv6-only hotspot with NAT64 gateway. I had internet access, he had rant about why IPv6-only networks are abomination and that he never seen a network like it. He won nothing, and neither do you win anything running without IPv6 support. -- Piotr.
[gentoo-dev] Rationalizing USE flags by narrowing the scope of them.
Hi, I'd like to get some insight how others see the concept of narrowing the scope of USE flags in Gentoo. Taking a quote from devmanual: > USE flags are to control optional dependencies and settings which the user may reasonably want to select. I'd like to focus on the 'reasonably want' here. While it is commonly agreed on that we interface as USE flags only things that make sense to be togglable, it is not always the case. It is not uncommon to see packages that puts every possible option as USE flag which hardly benefit anyone in some cases. It creates artificial choice of USE flag that makes as much sense as building and trying to use solar-powered night vision googles. Possible to be engineered, but makes absolute no sense to exist, yet, there will be someone who will go with it and then things will not work in desired way, bugs will be reported, effort will be wasted on investigation and patching things up. As example I'd like to use 'ipv6' USE flag, at the moment of writing this email there's 351 ebuilds in tree that expose ipv6 as USE flag, allow it to be disabled. The thing is, it's 2022, and it does not make any sense to *not* support IPv6, even if one does not connect to any network with IPv6, there's no harm to just have it there. While I am all for choice, I am for choice on things that do make sense. For instance, Linux kernel can be built with CONFIG_MULTIUSER=n, someone could argue that since Linux kernel, that is user-configured in Gentoo, can be built without support for other than UID 0, then Gentoo should support it. One of the extreme examples of not supporting something that does not make sense to be supported. Beside 'ipv6', there are other USE flags that I have on mind. 'pam' being another of them. Whats your view on it? -- Piotr.
[gentoo-dev] Last rites: dev-python/pytaglib
# Piotr Karbowski (2021-12-19) # No package depends on those bindings anymore. # Removal in 30 days. dev-python/pytaglib
Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/glibc-2.34-r2.ebuild#L643 Would you see something like this on more ebuilds, postgres, mysql, elasticsearch, or have proper FEATURE flag for it instead? It's all cool and giggles until you realize that even such random variable is not even prefixed with PORTAGE_ or anything, meaning it could be taken out of shell and meant for entirely different thing. -- Piotr.
Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
Hi, On 25/11/2021 16.50, Pacho Ramos wrote: As a side note, maybe ebuild should add sanity checks (like those from glibc) to prevent downgrades, otherwise people could still accidentally hit the issue You might have valid use cases to downgrade mysql, if you are okay not preserving data. I'd assume it's a common knowledge that downgrade of any data store, be that database or likes like elasticsearch, will corrupt the data. To make it actually useful I think we'd need new EAPI feature 'downgrade-protection', that unless is explicit ignored like --ignore-downgrade-protection mysql, it would prevent it from happening. -- Piotr.
Re: [gentoo-dev] Call for testing from toolchain team: glibc-2.34
Happy to report that everything works fine with sys-libs/glibc-2.34-r1, I have rebuilt whole @world (1300+ packages) without a single failure, thought I did it without FEATURES=test. I can sign off this glibc as good enough to go into ~arch. -- Piotr.
Re: [gentoo-dev] Re: johu's packages up for grabs
On 10/10/2021 15.54, Piotr Karbowski wrote: > Hi, > > > On 10/10/2021 09.23, Joonas Niilola wrote: >> Hey, >> >> due to inactivity the following packages are now up for grabs: >> app-admin/calamares >> app-admin/profile-cleaner >> app-crypt/zulucrypt >> app-doc/zsh-lovers >> app-misc/screenfetch >> dev-cpp/websocketpp >> dev-libs/qtkeychain >> dev-vcs/gti >> media-sound/lollypop >> net-im/discord-bin >> net-misc/sshpass >> net-vpn/openfortivpn >> sys-apps/daemonize >> sys-fs/fuse-zip >> x11-apps/luit >> x11-misc/compton >> x11-misc/fpm2 >> x11-misc/obconf >> x11-misc/sxhkd >> x11-terms/xterm >> x11-wm/bspwm > > Took compton under myself and added x11 project into xterm since it's > kind of default/fallback terminal for xorg. > > -- piotr. > I was not aware compton is to be dropped from tree. Ignore my takeover and drop it as you see fit. -- piotr.
[gentoo-dev] Re: johu's packages up for grabs
Hi, On 10/10/2021 09.23, Joonas Niilola wrote: > Hey, > > due to inactivity the following packages are now up for grabs: > app-admin/calamares > app-admin/profile-cleaner > app-crypt/zulucrypt > app-doc/zsh-lovers > app-misc/screenfetch > dev-cpp/websocketpp > dev-libs/qtkeychain > dev-vcs/gti > media-sound/lollypop > net-im/discord-bin > net-misc/sshpass > net-vpn/openfortivpn > sys-apps/daemonize > sys-fs/fuse-zip > x11-apps/luit > x11-misc/compton > x11-misc/fpm2 > x11-misc/obconf > x11-misc/sxhkd > x11-terms/xterm > x11-wm/bspwm Took compton under myself and added x11 project into xterm since it's kind of default/fallback terminal for xorg. -- piotr.
Re: [gentoo-dev] Packages up to co-maintenance
Hi, On 02/07/2021 11.15, Marek Szuba wrote: > On 2021-07-02 10:12, Sergei Trofimovich wrote: > >> app-misc/mc >> dev-util/ltrace >> media-fonts/terminus-font >> media-libs/aalib > > Will attach myself to these four. > I will join you on the following: net-ftp/proftpd app-misc/mc x11-misc/xclipmedia-fonts/terminus-font -- Piotr.
Re: [gentoo-dev] Packages up for grabs: x11-misc/gmrun
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
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
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
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
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
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
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
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
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+
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
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
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
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
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
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
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
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.
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.
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.
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}
# 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.
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.
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.
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
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
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)
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
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.
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.
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.
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.
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
