Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
State of the Union
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
saellaven
l33t
l33t


Joined: 23 Jul 2006
Posts: 646

PostPosted: Fri Sep 28, 2018 1:19 am    Post subject: Reply with quote

Anon-E-moose wrote:

The only other option that I really see is going full LFS, and doing it all myself.
Which I did back in the 0.*-2.* kernel days.


Which is exactly what I used to do before coming to Gentoo, which basically allowed me to automate things more, especially across heterogeneous hardware.

Quote:

I do like the ability to easily add and remove packages (and all associated files) so even if I did go LFS I'd probably try and keep something like portage going.


I'm still leaning the way of simply forking Gentoo...

the only problem is, I don't have a ton of time to keep up on new releases. To some degree, I'm perfectly fine stagnating on packages that work (I stayed with gnome 1.x + enlightenment 0.16.x for a LOOOOONG time after gnome 2 nuked a bunch of features that were important to me and didn't add them back until years later), but, I also recognize that I don't have time to be up on every security related release (say openssl) either.


At the end of the day, I maintain that Gentoo needs to
1) make openrc development independent from systemd (ie: williamh needs to be removed as openrc lead since he's the systemd proponent pushing everything)
2) the council needs more diversity of opinion, including user designated members, and needs to actually do their job (ie, if they're going to rule on technical matters, they need to educate themselves before ruling)
3) the council, comrel/proctors/whatever they're calling themselves now, etc need to be exclusive of each other - there's a reason why, if you serve on the Congressional Rules committee, that is the only only committee you can serve on (Appropriations and Ways and Means are also exclusive committees). It's so that one person can manipulate multiple committees into forcing their bidding through.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Fri Sep 28, 2018 2:19 am    Post subject: Reply with quote

saellaven wrote:
At the end of the day, I maintain that Gentoo needs to
1) make openrc development independent from systemd (ie: williamh needs to be removed as openrc lead since he's the systemd proponent pushing everything)

Give all the other init implementations in the tree to more responsible people too. WH took them all over and left them to bitrot because they're not "his".
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6098
Location: Dallas area

PostPosted: Fri Sep 28, 2018 9:51 am    Post subject: Reply with quote

(being discussed on another thread)

I don't understand why Hubbs removed tmpfiles support from <openrc 23 only to add it back with openrc 23 by way of another package.
That was stupid and just more work for maintainers. Then it required a virtual, that's 2 packages.
It's not like systemd uses the opentmpfiles package anyway, it does it all on it's own.

Just one example of his incompetence.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6098
Location: Dallas area

PostPosted: Fri Sep 28, 2018 1:48 pm    Post subject: Reply with quote

Ant P. wrote:
saellaven wrote:
At the end of the day, I maintain that Gentoo needs to
1) make openrc development independent from systemd (ie: williamh needs to be removed as openrc lead since he's the systemd proponent pushing everything)

Give all the other init implementations in the tree to more responsible people too. WH took them all over and left them to bitrot because they're not "his".


Unfortunately every change done to openrc since Hubbs took it over has been to mirror what systemd does, even when it makes no sense to do those things for openrc.

The problem with following systemd is that systemd doesn't care about anything else but their own little world, which is all well as far as it concerns systemd,
but it's not so well when software like openrc starts basing their way of doing things on systemd.

What next? binary logging for openrc? mandatory network managment? whatever brain-dead idea gets implemented in systemd?
This is a long term recipe for failure, well unless the idea is to so pollute openrc and other alternative inits, that people walk away from it.

I didn't realize that Hubbs took over the other init packages. :roll:
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 318

PostPosted: Fri Sep 28, 2018 2:08 pm    Post subject: Reply with quote

Anon-E-moose wrote:
(being discussed on another thread)

I don't understand why Hubbs removed tmpfiles support from <openrc 23 only to add it back with openrc 23 by way of another package.
That was stupid and just more work for maintainers. Then it required a virtual, that's 2 packages.
It's not like systemd uses the opentmpfiles package anyway, it does it all on it's own.


I would have thought it makes sense to split out the code so that it could be used by others - including other init systems, I don't know what the trade-off between a separate package is ...
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6098
Location: Dallas area

PostPosted: Fri Sep 28, 2018 2:50 pm    Post subject: Reply with quote

Splitting it out is ok, just 2 more packages to take of.
The only thing I see changed is that init.d/conf.d files have changed names and tmpfiles.sh changed to tmpfiles and got put in /bin
so in an ebuild instead of (/lib/rc/sh/)tmpfiles.sh --create <conf file> you have (bin/)tmpfiles --create <conf file>

But in looking at s6 (for example) it doesn't seem to have tmpfiles implemented or called, same for runit.

This is from tmpfiles.eclass
Code:
        ewarn "Warning: tmpfiles.d not processed on ROOT != /. If you do not use"
        ewarn "a service manager supporting tmpfiles.d, you need to run"
        ewarn "the following command after booting (or chroot-ing with all"
        ewarn "appropriate filesystems mounted) into the ROOT:"
        ewarn
        ewarn "  tmpfiles --create"
        ewarn
        ewarn "Failure to do so may result in missing runtime directories"
        ewarn "and failures to run programs or start services."

_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2284
Location: Adendorf, Germany

PostPosted: Fri Sep 28, 2018 4:42 pm    Post subject: Reply with quote

Anon-E-moose wrote:
The problem with following systemd is that systemd doesn't care about anything else but their own little world, which is all well as far as it concerns systemd,

Hear, hear!

We had to revert a systemd-world change in elogind to stay compatible with non-systemd based distros which might to things differently:
Support system_bus_socket to be found in /var/run/dbus (again, as that was the rule until systemd-237.)

At the end of the day such changes do not make me angry or anything. systemd is meant to "run the show", so they have the (unholy) freedom to re-define things as they see fit. Some of these changes might make sense, others are to strengthen their "business model" and the rest exist for they own sake, maybe to justify their existence.
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1816

PostPosted: Mon Oct 08, 2018 5:06 pm    Post subject: Reply with quote

Anon-E-moose wrote:
I was shocked to run emerge world this morning and see that dbus along with perls NET-DBus was trying to be installed (along with a couple of xml files) on my system.
So I ran it with -t to see what was pulling it in ... and found out xdg-utils was doing it.
So I looked at the ebuild, sure enough they "required it"
I then downloaded the tarball to see what was going on and the only reason for it is xscreensaver (full of dbus calls :roll: )

Wow. I just ran into this today with the upgrade to x11-misc/xdg-utils-1.1.3-r1. I'm going to make an overlay change like the one you made. What has me totally confused that I've always used xscreensaver without dbus with no problem at all. I see some mention of xdg-screensaver, yet I don't even see a package in portage for that(?).

This whole situation is out of control. I don't get a chance to update as often as I used to and every time seems to have more of this bullshit. One example is virtual/tmpfiles. So far I'd yet to get bitten by that (I'm running sys-apps/openrc-0.17 out of my overlay), but today I had to add virtual/tmpfiles-0 to /etc/portage/profile/package.provided, because of this change quietly made to mysql-init-scripts-2.2-r3.ebuild:
Code:
diff mysql-init-scripts-2.2-r3.ebuild ~/tmp/mysql-init-scripts-2.2-r3.ebuild
6c6
< inherit systemd s6
---
> inherit systemd s6 tmpfiles
47c47
<    systemd_dotmpfilesd "${FILESDIR}/mysql.conf"
---
>    dotmpfiles "${FILESDIR}/mysql.conf"

I'm not sure how much longer I can take all this shit. The supposed systemd "choice" in Gentoo is getting a little like "I'm not going to move into your apartment...I'm just going to store all my shit there." </rant>.

Anyway...if someone can clarify the xscreensaver mess...again I've never needed dbus for that before. I also have no need for programs to communicate with xscreensaver.

Tom
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6098
Location: Dallas area

PostPosted: Mon Oct 08, 2018 5:24 pm    Post subject: Reply with quote

From another thread https://forums.gentoo.org/viewtopic-p-8266338.html#8266332 (it's a summary of what I've found, but the whole thread is about opentmpfile)
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1816

PostPosted: Mon Oct 08, 2018 5:39 pm    Post subject: Reply with quote

Thanks for that! I just added that symlink which I hadn't done. I'm still confused on the whole xscreensaver / dbus thing.

Thanks again!
Tom
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6098
Location: Dallas area

PostPosted: Mon Oct 08, 2018 5:56 pm    Post subject: Reply with quote

Dbus was ALWAYS REQUIRED to make xdg-screensaver work, but it wasn't a hard requirement in the ebuild, with the latest xdg-utils ebuild they added the dbus hard requirement.

IF you are NOT using xscreensaver, in conjunction with something like the DE (gnome, kde, etc) using it for shutdown purposes where it has to interact with the xsreensaver, you'll probably never use xdg-screensaver.

There should be a flag to turn it off, IMO, but I'm not getting into arguments with the devs that deal with that ebuild, not worth my time.

Edit to add: for me, I don't have xdg-utils installed (I added it to package.provided) , if I did I would copy xdg-utils ebuild to my local directory and remove the dbus requirement.

I don't think you need these three, as they aren't in the 1.1.1 ebuild
Code:
dev-perl/Net-DBus
dev-perl/X11-Protocol
sys-apps/dbus

_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1816

PostPosted: Mon Oct 08, 2018 8:34 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Dbus was ALWAYS REQUIRED to make xdg-screensaver work, but it wasn't a hard requirement in the ebuild, with the latest xdg-utils ebuild they added the dbus hard requirement.

IF you are NOT using xscreensaver, in conjunction with something like the DE (gnome, kde, etc) using it for shutdown purposes where it has to interact with the xsreensaver, you'll probably never use xdg-screensaver.

There should be a flag to turn it off, IMO, but I'm not getting into arguments with the devs that deal with that ebuild, not worth my time.

OK...I can see where I was confused there. I was thinking that xdg-screensaver was a package when it's just a program provided by xdg-utils. I've created an ebuild that excludes that dbus stuff based on the dbus USE. I agree that the ebuild SHOULD make that optional...pretty silly.

Interestingly, I use xscreensaver on my MythTV frontend and always have. I've also never had any ebuild require xdg-utils at all. I even have my mythtv ebuild altered so as to remove the dbus requirements. While MythTV does in fact need to control the screen saver (for example, disabling while you're watching stuff), it does so using xscreensaver-command in the absence of the dbus stuff apparently...and all seems to work just fine.

This battle is getting really annoying for sure. Thanks for the clarifications!

Tom
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1816

PostPosted: Mon Oct 08, 2018 9:18 pm    Post subject: Reply with quote

You know, the more I look at this the more it all starts making sense. I'm now recalling that everything around that xdg-utils is all tied into everything that the freedesktop.org folks consider to be an "application". That's actually one of the few things I ever run into on my system that never makes sense...like default applications etc. What a total cluster ****.

Thanks God I'm at least using palemoon instead of FF. From what I've seen recent versions of FF have completely broken the ability to use plain old /usr/bin/whatever paths as a means of opening a file, and only appear to recognize whatever this bullshit considers to be an "application". Even using palemoon I had to jump through hoops to get it to properly open magnet link URLs in vuse for example. What a mess.

Tom
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6098
Location: Dallas area

PostPosted: Mon Oct 08, 2018 9:23 pm    Post subject: Reply with quote

Yep, xdg is from the friendly folks :roll: at freedesktop.org :lol:
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Mon Oct 08, 2018 11:45 pm    Post subject: Reply with quote

xdg-screensaver uses the perl DBus code to check what to call... and then uses the dbus-send binary to call it. Why not just one or the other? Preferably neither, but...
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 8936

PostPosted: Tue Oct 09, 2018 11:47 am    Post subject: Reply with quote

Anon-E-moose wrote:
There should be a flag to turn it off, IMO, but I'm not getting into arguments with the devs that deal with that ebuild, not worth my time.

Someone else did that for you: https://bugs.gentoo.org/668156
Back to top
View user's profile Send private message
berferd
Tux's lil' helper
Tux's lil' helper


Joined: 13 May 2004
Posts: 117

PostPosted: Mon Oct 15, 2018 3:38 am    Post subject: Reply with quote

NeddySeagoon wrote:
...It wouldn't really be a fork, just an overlay or two...


Openrc would have to be forked, at the very least. I suspect baselayout would have to be forked too to remove the opentmpfiles nonsense. Does /tmp on a ramfs even make sense in the world of NVMe flash storage?

I ran Funtoo for years. Most of the user base and devs at the time ran unstable, and I'm a fan of running stable. I kept running into issues no one else had.

I also found it impossible to join their forum or bug tracker. This combined with the above made it a very frustrating experience.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Mon Oct 15, 2018 4:26 am    Post subject: Reply with quote

/run/ needs to be on *something* writable, because the things that mount the root filesystem need somewhere to put state (all versions of openrc, udev, autofs, blkid, dhcp stuff if it's nfs). Everyone has tmpfs.
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 783
Location: usually offline

PostPosted: Tue Oct 16, 2018 12:38 pm    Post subject: Reply with quote

Whenever I seem to have an issue with OpenRC, I go looking at how systemd does it and how to resolve those issues. Voila… those same solutions help resolve my OpenRC issues. Maybe we should just merge OpenRC with systemd and let the same devs run things. I wonder where OpenRC wants to go?

I don't use any DE and I'm not really concerned about where DEs want to go. Having seen how it works, I want to be in the runit camp, which I find is smaller and more efficient. OpenRC just wants to keep growing it seems to add yet more features and be like systemd. My next systems will probably not be OpenRC. Why does Gentoo have to be OpenRC?
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey


Last edited by josephg on Thu Oct 18, 2018 2:16 pm; edited 1 time in total
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 8936

PostPosted: Tue Oct 16, 2018 12:45 pm    Post subject: Reply with quote

josephg wrote:
Whenever I seem to have an issue with OpenRC, I go looking at how systemd does it and how to resolve those issues. Voila… those same solutions help resolve my OpenRC issues.

Eh what? Can you cite an example?
Back to top
View user's profile Send private message
saellaven
l33t
l33t


Joined: 23 Jul 2006
Posts: 646

PostPosted: Tue Oct 16, 2018 3:05 pm    Post subject: Reply with quote

josephg wrote:
Whenever I seem to have an issue with OpenRC, I go looking at how systemd does it and how to resolve those issues. Voila… those same solutions help resolve my OpenRC issues. Maybe we should just merge OpenRC with systemd and let the same devs run things. I wonder where OpenRC wants to go?


the same dev, williamh, IS running things... into the ground... because his priority is crippling openrc to have the same flaws as systemd, so that systemd doesn't look like they made arbitrary choices that are poorly conceived, inflexible and inferior.

he also abused his position on the Council and the goodwill and naivety of the other Council members to ram through his agenda of crippling openrc.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6098
Location: Dallas area

PostPosted: Tue Oct 16, 2018 3:29 pm    Post subject: Reply with quote

saellaven wrote:
to ram through his agenda of crippling openrc.


And thus the reason so many have stayed with older versions of openrc.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 783
Location: usually offline

PostPosted: Tue Oct 16, 2018 10:25 pm    Post subject: Reply with quote

asturm wrote:
josephg wrote:
Whenever I seem to have an issue with OpenRC, I go looking at how systemd does it and how to resolve those issues. Voila… those same solutions help resolve my OpenRC issues.

Eh what? Can you cite an example?

Yes, I can cite one example: See this thread?
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1816

PostPosted: Thu Oct 18, 2018 12:23 am    Post subject: Reply with quote

josephg wrote:
asturm wrote:
josephg wrote:
Whenever I seem to have an issue with OpenRC, I go looking at how systemd does it and how to resolve those issues. Voila… those same solutions help resolve my OpenRC issues.

Eh what? Can you cite an example?

Yes, I can cite one example: See this thread?
Holy crap. Let me get this straight. A post about OpenRC being broken so as to observe systemd bullshit that that has nothing to do with OpenRc...and the fact that you may have worked around it(?)...proves that systemd somehow "fixed" OpenRC? I'd call that the most circular logic I've ever heard but it'd be an insult to circular logic. Then again it's typical systemd logic...taking credit for fixing the shit you break...that's SOP in systemd land.

This is why I, like others, run sys-apps/openrc-0.17 out of my overlay...because it just plain works and I have no need in the world to screw with it.

Tom
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Thu Oct 18, 2018 6:24 am    Post subject: Reply with quote

tld wrote:
Holy crap. Let me get this straight. A post about OpenRC being broken so as to observe systemd bullshit that that has nothing to do with OpenRc...and the fact that you may have worked around it(?)...proves that systemd somehow "fixed" OpenRC?

tld ... in josephg's defence, I don't think that was what they were arguing, if you read the original post they are questioning why that happens to be the case.

best ... khay
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 6 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum