Page MenuHomePhorge

Phorge
PublicGeneral discussions about Phorge.

Gracie mille

THYDUX joined the room.

Hi and welcome.

Sep 4th, 2024

https://we.phorge.it/p/THYDUX/ looks like a spammer based on their last acitivity.

Disabled

Sep 5th, 2024

Does anybody know the origin of this code? https://secure.phabricator.com/D20774

I probably need some help to write some documentation "in the style of Phabricator" but without exxagerating .

Sep 6th, 2024

What is the question about D20774 in upstream? I vaguely recall that happening. Removed the shared repository libphutil, used by both arcanist and phab

(I cannot access https://we.phorge.it/D20774 and maybe that is totally fine. Just saying.)

Ah damn, that's on the old instance - sorrrrrry, ignore my last comment!

Thanks speck. I was trying to blame this https://secure.phabricator.com/D20774 - because I was not able to find its origin - that is this \o/ https://secure.phabricator.com/D20773 (lol - it was quite evident from the commit msg)

I was talking with Andre. Who pay the bills of phorge VPS and domain? Can we donate something to this person? or at least say "thank you" to the right person. lol

BTW since "phorge.it" "seems Italian" to some people because of that ".it" lol, if we need a quick fiscal sponsor, I would be glad to offer Italian Linux Society; so, to expose PayPal and bank donations, and cumulate an amount to pay bills for this project. Feasible to propose to my board if there is interest. It is not the most nonsensical thing we have done.

The VPS is out of my Linode account. The it domain was originally registered by @deadalnix (EU-based and was eligible to make the initial domain purchase) although I believe that @avivey is mostly the one who maintains that nowadays

The VPS is cheap though, don't worry about that

Sep 7th, 2024

Uh thanks! Hoping to be useful I've wrote down these here so I don't ask again tomorrow because of my short memory lol Internal Documentation

Ah, thanks! I was curious and wondering, don't want the site to go down without a warning, I'd rather throw some money in before that :D

Sep 24th, 2024

At this point user Wikivu won a cute spam ban I guess

Should his account be disabled?

Oct 1st, 2024

yes please

Oct 2nd, 2024
songnguxyz joined the room.

@Wikivu is disabled

Oct 8th, 2024

I've heard no complaints about the latest RC, so I guess that means it's safe to promote? It's been about 6 weeks...

Oct 9th, 2024

hey I would like to do some more advanced things with queries than I think is currently possible for example I would like a differential dashboard which queries for reviewers: packages(viewer()) and I would like to do things like filter out revisions which have been approved by viewer(). please let me know if there is currently a way to do this. I think the current query language is relatively limiting but I may not be aware of all the quirks

Oct 10th, 2024

I'll try to find the code I used to make T15512#15803 - IIRC, the language will allow for that, but it needs a new class for each function (packages()) times each possible-argument (viewer()); And possibly, each indirection requires a synchronized call to the DB to be resolved, so reviewers: members(projects(viewer())) will:

  • get viewer() for free,
  • round trip for projects(),
  • another one for members(),
  • and then build the real query (reviewers in (%Ls)) and run that.

"DB Round-trip" is, arguably, the slowest part in the Phorge experience, and we don't have a good way to optimize this particular flow. And once you allow users to nest queries arbitrarily, they will.

Oct 11th, 2024

yea was having a little look at the code and it feels like its not the easiest thing to implement. I tried patching a few things to add a new function which I think would work something like viewerpackages() but obviously that isn't terribly flexible

I think exactviewer() for responsible users and viewerpackages() for reviewers would be all that I would require for my needs

oh also something like waitingonviewer() too for status

maybe i can explain what Im trying to do to avoid xy problem. I want a dashboard for differential reviewers which shows the most important things to do and displays nothing the viewer doesn't need to do. This includes revisions the viewer has written (currently on the right) and revisions they need to review on the left. Revisions they have already approved or which another all packages which they are owners of have already been approved should not appear on the left. Revisions they are explicitly requested reivewer of should appear above ones they are implicit on (through an owners package). on the right (for revisions the viewer is an author of) first should contain approved, then changes required, then other revisions

You can use custom Bucket function for sorting revisions based on action/category - that's what the Active Revisions (default) page in Differential currently does (DifferentialRevisionRequiredActionResultBucket). Using custom bucketing is nice because you can make sure each revision shows up only once. On the other hand, you'll need to craft a single query that returns ~all the interesting revisions (You can probably filter some out in the code, though).

You can easily(ish) use Dashboard to control the layout; Make a Query Panel for each part, place them in the right place, etc.

I think this (waitingonviewer?) cannot be expressed using query alone:

  • (Hide) Revisions that are in "need review" status, but not from me/any of my packages/projects.

and it's probably better to implement this as a Bucket then as a Reviewers function.

Using Dashboard, you can use 2 different queries for "explicitly requested" vs package/project - use the | Responsible User as viewer() or exact(username)[1] to separate them. Alternatively, a Bucketing function that's similar to what you're asking can probably be added upstream.

[1] There's no exact(viewer()), and also no packages(viewer()), but I think it would be reasonable to add something like that (because viewer() is free). Need to dig more to see if it's hard.

Oct 14th, 2024

Who have permission to promote the latest RC to stable? I don't see objections in chat, so I guess we should proceed.

Oct 15th, 2024

@avivey it looks like we have got viewerprojects() would it be the case of just adding `

diff --git a/src/applications/project/typeahead/PhabricatorProjectOrUserFunctionDatasource.php b/src/applications/project/typeahead/PhabricatorProjectOrUserFunctionDatasource.php
index 6a6bc25ee0..11d78ffa5b 100644
--- a/src/applications/project/typeahead/PhabricatorProjectOrUserFunctionDatasource.php
+++ b/src/applications/project/typeahead/PhabricatorProjectOrUserFunctionDatasource.php
@@ -17,6 +17,7 @@ final class PhabricatorProjectOrUserFunctionDatasource
       new PhabricatorPeopleDatasource(),
       new PhabricatorProjectDatasource(),
       new PhabricatorProjectMembersDatasource(),
+      new PhabricatorProjectLogicalViewerDatasource(),
       new PhabricatorProjectUserFunctionDatasource(),
     );
   }

and doing something similar for viewerpackages()

Yeah, it could be that easy...

(My home internet was fixed, so I'll to the stable today.)

I've promoted to Stable!

Oct 17th, 2024

Woohoo! Thank you @avivey!

Oct 18th, 2024

Would anyone have opinions or recommendations how to proceed with slowly updating the PHPMailer copy (see D25723 for a first step)? We have quite some bitrot in upstream code copied into Phorge decades ago. If everyone's too busy or too uninterested or too "this is a PITA to test" (all of that is legitimate!), what could I do? Deploy on my own production instance and let it run for a few weeks and ping again here with "This works in downstream", maybe?

(File under: "Classic problems in understaffed volunteer FOSS projects")

Also, if someone is willing to rubberstamp D25813, D25814, D25816 that would be cool

Ah, thanks!

I was gonna try applying D25723 to my personal instance to help test, but I shoulda read Next Up because I first updated to latest master and ran into You are running PHP version '7.2.24-0ubuntu0.18.04.17', which is older than the minimum version, '7.2.25, whoops, well good reminder to finally upgrade that server from Ubuntu 18.04 😅

Oct 19th, 2024

@keithzg: Thanks! Uhm, I went for 7.2.25 (emphasis on .25) simply because Wordpress also does now: https://we.phorge.it/T15047#19338. You can lower the "$required_version" in support/startup/PhabricatorStartup.php without any problems as long as it is 7.2.something

Oct 20th, 2024

@aklapper Ah yeah in my scenario it was a good reminder to finally upgrade that server, 18.04 has been out of extended-but-free support since June 2023, and sits abandoned on 7.2.24 if strictly sticking to the official repos and unpaid support. That seems like kinda an arbitrary version for Wordpress to peg to, I wonder if it was literally to avoid having to support stock Ubuntu 18.04, hah! (I don't see anything special about it at https://www.php.net/ChangeLog-7.php#7.2.25 and funny enough https://wordpress.org/about/requirements/ still lists it as "7.2.24+", I wonder if they're distracted ;))

Oct 24th, 2024

Would anyone be willing to review and rubberstamp D25831 and D25832? Same game as rPdb61eb20. TIA!

Oct 29th, 2024

Also, if anyone feels like harvesting some low-hanging cleanup fruits, I'd welcome reviews in https://we.phorge.it/differential/?ids=25749,25751,25752,25787,25742#R - thanks! :)

Nov 2nd, 2024

Lol D25363 is ready since 2023 but today is state of the art, I really don't know how to further improve test plan lol

Crossing fingers that I find time to test it in the next two weeks when I took some workdays off. If not please gently slap me

Nov 3rd, 2024

Done, sorry

Nov 11th, 2024

Phorge Horoscope:
Aries: Your bold energy is needed! Dive into D25363 and share your insights. Your Calendar experience will inspire others! lol

Nov 14th, 2024

Taurus: Your practical nature to "seems good to me" will serve you well as you review the patch. Take your time, and carefully consider each line. The Test Plan will pay off in the long run D25823

Nov 15th, 2024

re: T15956, there's also a secondary bug report I'd like to file since they're 2 different systems, but I'd like to ask before making them separate:
When attaching a file via the upload button or pasting when in a proper Conpherence room, if you reload the page, the metadata is lost & upon submission, files are not attached.

(2 different systems being, ConpherenceDurableColumnView (persistent chat) vs. what i assume is PhabricatorRemarkupControl)

Nov 21st, 2024
meeshu joined the room.

Hey I have a question regarding the status of the Facts application, where is the best place to ask that?

Nov 22nd, 2024

I think the answer is, propose a patch :D or at least a task

This is mostly from a user perspective as I would like to use Facts. I am not a developer (I joined with the aim to contribute to the infra side of things such as T15025 and Q148 since that is more my area) so don't think I can contribute in that way. I have done all the searching I can but I cannot find a way to create a chart in Facts, should I be able to do that currently, or is it still being developed?

If you want something simple to copy I can suggest to look at this example
https://we.phorge.it/fact/chart/IjqAU8i23.7S/
https://we.phorge.it/source/phorge/browse/master/src/applications/fact/engine/PhabricatorDemoChartEngine.php

This component is surely not plug&play, but at least you can play :D

Other Facts hacky things in that directory

Awesome, I will have a play, thanks :)

This is why I have trust issues

CVE-2024-48990 https://www.qualys.com/2024/11/19/needrestart/needrestart.txt

the Python adapter of needrestart takes a user-space envvar (PYTHONPATH) and just runs it as root when you run apt upgrade.

Dec 1st, 2024

@avivey wow that's terrible

easy fix: sudo apt remove needrestart

Dec 3rd, 2024

Could someone accept the regression fix in https://we.phorge.it/D25839 ? Reporter says that it works for him. TIA!

Looks like the user hid it from the world

This user, so probably spammer 🌈 https://we.phorge.it/p/3tayesh/

(author was aklapper)

fixed for now.

There's exactly one other hidden revisions (Out of 845), although there are 2 that are only visible to Trusted Contributors.
The hidden one is D25604.

Yeah you discovered D25604, was ancient private stub who is D25363 since last hot July 2023

I think it could be nice to introduce a permission such like "has verified email". So we can set that as default Edit permission, for most things, I think

Maybe we just require all accounts to verify email. I just disabled about 10 unverified all with names and emails that look like garbage

"has verified email" is basically existing auth.require-email-verification ?

Dec 4th, 2024

Yeah, it'll just prevent anyone with Microsoft as their email host from registering -- Outlook has historically liked to eat our emails instead of delivering them. Perils of self-hosted email :-/

@aklapper: is it a question to me? <3 I was thinking that it could be nice to be able to:

  • keep registration without verification (false in auth.require-email-verification)
  • but have most edits with mandatory email verification (so, a new policy I guess)

I think the answer is "maybe yes but too complicated lol"

BTW maybe Microsoft is discarding our emails also because of this T15036: Phorge upstream mail should not use @upstream.phorge.dev addresses