[SOLVED] How to deal with wiki rejections

loh.tar · 2024-02-29 18:48:34

"not a place of self promotion"? I'm not amused!

From my point of view ist the wiki the place to find answers. So whats wrong to advertise my little script there? There is no similar software listed, that had surprised me when I was looking for such piece of code.

When an AUR package is mandatory to be listed there, OK. But there are a couple of broken AUR links and I guess no one cares. I have not made a AUR because its very simple to install but not so easy to setup. So a package is no big improvement.

https://wiki.archlinux.org/index.php?ti … did=801675

Edit: Strictly speaking, the thread is not resolved, because the original reason for opening it was something else, but i'll leave it at that. Now that my entry in the wiki has been accepted, I was asked to mark it as solved. So i changed the title from "My new little contribution was undone, ok but not the wording"

Last edited by loh.tar (2024-03-17 08:06:06)

ayekat · 2024-02-29 23:01:56

loh.tar wrote:

From my point of view ist the wiki the place to find answers. So whats wrong to advertise my little script there?

It's a place to find answers related to Arch Linux, so it's probably fair to expect a PKGBUILD or similar.
If you have trouble writing a PKGBUILD yourself, you may also ask for help in the PKGBUILD requests forum.

I would also first post to the Community Contributions forum. This gives you some feedback on your application from the community, and consequently whether it's considered noteworthy enough to be added to the Wiki.

But there are a couple of broken AUR links and I guess no one cares.

Broken links means there was at least a PKGBUILD at some point. That's a Wiki article cleanup issue if anything, not an argument to add more entries without a PKGBUILD.

I have not made a AUR because its very simple to install but not so easy to setup. So a package is no big improvement.

A package is always valuable.
The readme in your Git repo explains how to install an executable, a config file, two service files and one timer unit file. That's not something I would want on my system without properly packaging it.

A package also covers dependencies. While your readme states it doesn't have any, your script is written in bash (bash) and calls various of its builtins and/or coreutils commands (coreutils), ping (iputils), pgrep (procps-ng), grep (grep), find (findutils) and systemctl (systemd). Optionally also smbstatus.
systemctl being called also contradicts with the "not a hard dependency" statement in the readme, because it fulfils your script's primary purpose: suspending.

(coincidentally, Arch Linux's weird packaging policy relieves you from having to state any of those dependencies, but… in a distro-agnostic upstream readme, they should probably still at least be mentioned)

Last edited by ayekat (2024-02-29 23:10:25)

Trilby · 2024-02-29 23:31:19

ayekat wrote:

coincidentally, Arch Linux's weird packaging policy relieves you from having to state any of those dependencies

What? That's false. A couple of those are in base-devel, but the rest would have to be listed as dependencies.

loh.tar · 2024-03-01 08:06:29

Thanks you for your detailed reply. Actually i didn't want to discuss the project here, but of course I won't ignore the hints now.

...your readme states it doesn't have any, your script is written in bash (bash) and calls various of its builtins and/or coreutils commands (coreutils), ping (iputils), pgrep (procps-ng), grep (grep), find (findutils) and systemctl (systemd). Optionally also smbstatus.

Good point, will update the readme

systemctl being called also contradicts with the "not a hard dependency" statement in the readme, because it fulfils your script's primary purpose: suspending.

No, you can config to use any other suspend command

The readme in your Git repo explains how to install an executable, a config file, two service files and one timer unit file. That's not something I would want on my system without properly packaging it.

That's kind of the root why I didn't have made a PKGBUILD. There a some possibilities to setup and use this tool. But of cause could I have made it the way I like it.

AUR or not. I still think that there is no harm but a plus to have it listed in the wiki. And I'm still annoyed about the wording which is the reason for this thread.

ayekat · 2024-03-01 10:20:31

Trilby wrote:

What? That's false. A couple of those are in base-devel, but the rest would have to be listed as dependencies.

But they are all listed in base.

Opening a bug report against a package for missing dependencies like sed or grep will simply result in bug wranglers closing them as wontfix, noting that they're pulled in by base and that base is expected to be installed on every Arch Linux system.
My conclusion from that is that Arch allows omitting these dependencies (not that I agree with it, but I found my own ways to deal with this nonsense). If my conclusion is wrong, I'd be happy to know.

loh.tar wrote:

No, you can config to use any other suspend command

Ah, sorry, I missed the part where it sources the config file. Yeah, could potentially lead to $SuspendCommand being overwritten.

That's kind of the root why I didn't have made a PKGBUILD. There a some possibilities to setup and use this tool.

Why is the fact that all these files have to be placed in the system a reason against packaging it?

Also, quickly going through your code (I might have missed a few things again), it seems like your script does set some default config options. And your readme tells the user that your script will exit if not properly configured.
That is acceptable IMO, packaging doesn't mean that it has to be usable right out of the box. Installing an empty/comments-only config file is fine. Installing systemd unit files is fine (even if the user does to use them).

On the wording: It's a Wiki edit, there's limited room for explanation, so some comments might come across as a bit blunt.
If you disagree with the edit itself, you can also use the discussion page in the Wiki. After all, there is no guarantee that the Wiki editors read these forum posts.
But again, the common approach so far has been to post in the Community Contributions section and get some feedback there.

Last edited by ayekat (2024-03-01 10:21:58)

Trilby · 2024-03-01 14:42:26

ayekat wrote:

But they are all listed in base.

And? Base-devel packages are not to be listed as makedepends but this is specific 1) to base-devel, not base, and 2) only for makedepends not run-time dependencies. All direct run-time dependencies must be listed. This is quite clearly covered in the PKGBUILD page of the wiki. Further the arch package guidelines explicitly (and even in bold) says "Do not rely on transitive dependencies...".

Last edited by Trilby (2024-03-01 14:45:39)

loh.tar · 2024-03-01 15:18:03

Why is the fact that all these files have to be placed in the system a reason against packaging it?

To be honest: Kind of laziness. I had spend already too much time in this script, added stuff which may nice but are not really important to work for me. I wanted a break to get it out of my mind now. There are always litte things to do this way or an other way. And that also true for these packaging. Making decisions are not my strength. But with your encouragement I may do it.

On the wording: It's a Wiki edit, there's limited room for explanation, so some comments might come across as a bit blunt.

I don't expect a long explanation. Just, "pls add it to AUR and your a welcome" would be enough. But the other saying is completely unacceptable.

I have two other projects listed there. One day was it removed (or marked? dunno) with the comment "not maintained". What? Would be nice to ping me before doing so. Just because there was no activity don't mean I'm already dead or have it abandoned.

ayekat · 2024-03-02 19:00:31

Trilby wrote:

And? Base-devel packages are not to be listed as makedepends but this is specific 1) to base-devel, not base, and 2) only for makedepends not run-time dependencies. All direct run-time dependencies must be listed.

I was never talking about makedepends or base-devel. Yes, there is an explicitly documented policy about them. But I'm not talking about them.

I am also not talking about transitive (runtime) dependencies.

I'm talking about direct runtime dependencies, and some Arch Linux packagers deliberatly omitting runtime dependencies there if they happen to be in base. No, there is no explicitly written policy for that, yes, but that doesn't matter at all if bug reports get rejected with exactly that argument, that all of the base group (or now the base metapackage) is expected to be installed on your system.

--edit ~~I would love to link to the Flyspray bug in question, but it appears the read-only archive/static site seems to just redirect to GitLab now. If I find it again, I'll link it here.~~ https://bugs.archlinux.org/task/55635
--edit2 But also, I don't wanna open this can of worms again. I wrote a overly wordy, ranty blog post about what happened, and I've found my own way around this issue. I'm not looking to start another beef with Arch Linux.

Last edited by ayekat (2024-03-02 19:06:10)

loh.tar · 2024-03-02 19:51:28

I have not yet something pushed, bud done local.
May I ask how to deal with namcap warnings? Other PKGBUILD of mine not even have bash listed, IIRC because it is in base. But now namcap require bash, fine. But warn about all other stuff. I tend to ignore these warnings because of your posts above.

$ namcap auto-suspend-0.8-1-any.pkg.tar.zst 
auto-suspend W: Dependency included, but may not be needed ('iputils')
auto-suspend W: Dependency included, but may not be needed ('grep')
auto-suspend W: Dependency included, but may not be needed ('procps-ng')
auto-suspend W: Dependency included, but may not be needed ('findutils')

Here a snip from PKGBUILD

...
# namcap warn nothing of these are needed, only bash is fine
depends=('bash' 'iputils' 'grep' 'procps-ng' 'findutils')
# optdepends=() # No systemd or samba, there is no benefit to install explicit
...

wiki says to keep the PKGBUILD clean as possible, but I would like to keep these hints.
Thanks and good night.

Trilby · 2024-03-02 21:22:55

namcap is unable to detect what external binaries are called by a script - those "Dendency included..." warnings are false alarms.

loh.tar · 2024-03-03 10:26:06

Puh, ok. I Hope all is fine: https://aur.archlinux.org/packages/auto-suspend

To my surprise is there some other daemon listed, hm. Can't remember to find that, perhaps is it not in the wiki...

My intend with this thread was, that some admin went by and says something like, "I'm sorry for your harm, archlinux.org oppose all forms of hate speech. We will once again sensitize our team to this issue"

But now I have finally complete this project with your help. Thanks to both of you.

And please try not to end your discussion about packaging regulations here, even if it is not entirely unrelated to the package I have now created.

loh.tar · 2024-03-16 07:45:04

Too bad, once again refused
No idea why it is in "in unrelated sections" and not a"proper description". The name says it all, then a reference to bash, nothing to compile or so.

seth · 2024-03-16 09:33:38

Because https://github.com/loh-tar/auto-suspend isn't a system monitor.
It monitors the system but its actual purpose is to conditionally S3 the system, no?

loh.tar · 2024-03-16 11:24:41

Thanks for the input!

Um, yes.

So "system monitor" is a fixed term for something completely different? Fine. But still no idea what may missing in the description. I don't think it's appropriate to give long explanations of exactly how it works.

So my slogan on the project page isn't ideal either. Stupid thing. Any ideas for a better slogan that would also suffice in the wiki?

seth · 2024-03-16 14:46:46

https://wiki.archlinux.org/title/Category:Monitoring
https://wiki.archlinux.org/title/List_o … own_timers

Your tool frequently suspends the system when there're no active tasks, correct?

loh.tar · 2024-03-16 15:40:06

Yes. There is no specific time configured, but looked for some activities.

seth · 2024-03-16 15:40:48

So that would describe your tool, no?

loh.tar · 2024-03-16 15:52:50

Sure...So, that may enough? And which category? Is it a timer?

Edit:
Could the wiki admins have this in mind?
https://wiki.archlinux.org/title/Power_ … pace_tools in mind.
If so, why not mention this...

Last edited by loh.tar (2024-03-16 16:24:00)

seth · 2024-03-16 16:23:57

seth wrote:

https://wiki.archlinux.org/title/List_o … own_timers

Edit: while not exactly a timer it's effectively to schedule poweroffs/suspends (just not based on time but condition)

Last edited by seth (2024-03-16 16:24:50)

loh.tar · 2024-03-16 16:32:13

But it was in that category... (?)
"1) don't promote your software in unrelated sections"

Edit: while not exactly a timer it's effectively to schedule poweroffs/suspends (just not based on time but condition)

OK, may I comment the new change with "Seth is fine with this"?

seth · 2024-03-16 16:41:26

No, you put it into the monitoring section, not the shutdown timers.
And you cannot sign-off with my name - I'd have to comment on the actual change and the users maintaining the particular wiki page will have the final word no matter what.

Make sure to accurately describe the tool and in doubt you should discuss this on the discussion page of the relevant wiki - not here.

loh.tar · 2024-03-16 16:49:33

I had put in both, an the rejection sounds to me that both are wrong.

"A bash script to schedule shutdowns/suspensions based on configured conditions" good?

What do you think about the Power_management page, linked above?

Edit:

in doubt you should discuss this on the discussion page of the relevant wiki - not here.

Guess these talk button is that. Will try that.

Last edited by loh.tar (2024-03-16 17:13:19)

seth · 2024-03-16 17:12:23

The rejection message was unspecific, one category is unrelated for sure.
"bash script" is less important, "Shut down or suspend the system when no longer busy with configurable tasks" or so. Again: you'll have to sort that out in the wiki discussion page. Not here.

loh.tar · 2024-03-17 06:11:20

After a quick email inquiry, they said that the timer is section is ok, if I not call it a monitor in the description. No problem. Hope is now fine.

Thanks for your help and patience.

seth · 2024-03-17 07:39:08

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#1 2024-02-29 18:48:34

[SOLVED] How to deal with wiki rejections

#2 2024-02-29 23:01:56

Re: [SOLVED] How to deal with wiki rejections

#3 2024-02-29 23:31:19

Re: [SOLVED] How to deal with wiki rejections

#4 2024-03-01 08:06:29

Re: [SOLVED] How to deal with wiki rejections

#5 2024-03-01 10:20:31

Re: [SOLVED] How to deal with wiki rejections

#6 2024-03-01 14:42:26

Re: [SOLVED] How to deal with wiki rejections

#7 2024-03-01 15:18:03

Re: [SOLVED] How to deal with wiki rejections

#8 2024-03-02 19:00:31

Re: [SOLVED] How to deal with wiki rejections

#9 2024-03-02 19:51:28

Re: [SOLVED] How to deal with wiki rejections

#10 2024-03-02 21:22:55

Re: [SOLVED] How to deal with wiki rejections

#11 2024-03-03 10:26:06

Re: [SOLVED] How to deal with wiki rejections

#12 2024-03-16 07:45:04

Re: [SOLVED] How to deal with wiki rejections

#13 2024-03-16 09:33:38

Re: [SOLVED] How to deal with wiki rejections

#14 2024-03-16 11:24:41

Re: [SOLVED] How to deal with wiki rejections

#15 2024-03-16 14:46:46

Re: [SOLVED] How to deal with wiki rejections

#16 2024-03-16 15:40:06

Re: [SOLVED] How to deal with wiki rejections

#17 2024-03-16 15:40:48

Re: [SOLVED] How to deal with wiki rejections

#18 2024-03-16 15:52:50

Re: [SOLVED] How to deal with wiki rejections

#19 2024-03-16 16:23:57

Re: [SOLVED] How to deal with wiki rejections

#20 2024-03-16 16:32:13

Re: [SOLVED] How to deal with wiki rejections

#21 2024-03-16 16:41:26

Re: [SOLVED] How to deal with wiki rejections

#22 2024-03-16 16:49:33

Re: [SOLVED] How to deal with wiki rejections

#23 2024-03-16 17:12:23

Re: [SOLVED] How to deal with wiki rejections

#24 2024-03-17 06:11:20

Re: [SOLVED] How to deal with wiki rejections

#25 2024-03-17 07:39:08

Re: [SOLVED] How to deal with wiki rejections

Board footer