Fee Payment Points to validate on test , Flow understanding and known issues before Prod Fee payment  release

Describe the bug in current situation
Fee Payment Points to validate on test , Flow understanding and known issues before Prod release of Fee Payment.  The purpose of this task is to confirm the fixes done on the issues found during dev-integration testing and issues logged ,parked for later moment,
Bugs found , Process flows which need to be tested

[x]  Test Inflight requests with CFR  Fee payment Flow - This is  to replicate the scenarios on existing FOI Requests on PROD. Requested business to create FOI requests at different states(Intake, CFR, Fee Estimate, harms, Review, closed etc.) prior to TEST release for Fee Payment.

[x]  Emailing to Applicant flow : -ve and zero amount payment has no emails to applicant. Decision made with Business

[x] CFR forms  - Amount Paid will be disabled based on the discussions on #3004

[x] Make sure the Amount payment for applicant is exactly the same as latest "Approved" CFR Forms, AND whatever CFR form value which is "in progress" has no impact on the email send using "correspondence log"

[ ] Mobile view / Hand held views for the applicant payments should be appropriate

[x] Information(Logo, Phone, Address, language) indicated on the Receipts, Payment forms, Footer links need to be accurate.

[ ] -ve Balance and Refund amount has no relation as of now. This will be seperate and Refund amount has no influence on the Calculation.

[ ] Validations for Contact Applicant Log Template Options

Fee Estimate Option will be enabled only if below conditions are true

Latest CFR Form should be in approved state
Balance remaining should be > 0
TotalActualDue <=0
States allowed: CFR, OnHold (User can use Fee Estimate option from contact applicant log only in these states)

Contact applicant option is not available for Fee Estimate state.
Outstanding Fee Option will be enabled only if below conditions are true

Latest CFR Form should be in approved state
Balance remaining should be > 0
TotalActualDue > 0
States allowed: OnHold (User can use Outstanding Fee option from contact applicant log only in these states)

[ ]  Known issue1 : OnHold to Response automatic state change for a "Outstanding" email sent from "Correspondence Log" , will be handled at later point or with future user stories for automatic state change. at present escape route is to ask ministry to change the state for IAO to move to Response or will ask dev team to create temp mechanism.

[ ] Known issue2 : Accidently changing a CFR Form with "zero balance" or only electronic page estimate, which the CFR form in Limbo, unless IAO decides to enter a mock value into Actuals and give it back or other BE escape route , Will solve in future #3128

[ ] Known  behavior  : Scroll mouse issue - Digits will unknowingly increase/decrease on CFR form by mistake!

[ ] Known  Issue : CFR history - V1 having wrong values - #EDU-2022-15111213 - Will solve in  future #3129

[ ] Known Issue :  CFR Estimate email communication wont work with requests opened form  Redirect state - Issue already logged! #3063

[ ] Known Issue : Known Issue :  Attachment uploads on Extensions to FOI Requests throws error  , this happens only if we tries to create an extension other than syncing from AXIS. will solve later - #3125

[ ] Known Behavior : Any estimated CFR fee calculation on CFR Form for version greater than  1, should be the sum up value from previous as per current business processes with IAO and ministry  and/or if there are any mistakes in those digits and steps can CAUSE mismatch in Fee calculation. Also, assuming that the errors happening to Balance remaning, with various permutations combinations on CFR forms, has been confirmed by business. Demonstrated to entire team( @lmullane, @m-prodan)   and its confirmed that there is no need for engineering solution for that process as of now!

[ ] Known Issue: Contact Applicant add correspondence button is sometimes clickable even when no templates are selectable - front end only will fix after prod release

[ ] Fixed Issue: Confirmation Modal when user approves CFR form - ensure message is new text and does not reference moving back to in review from approved

[ ] Known Issue: User is able to save new version of CFR form after only selecting reason - need additional validation to ensure user enters some info in the estimates - front end only will fix after prod release

[ ] Known Issue: User is able to send email through contact applicant even after request is closed - will fix after prod release

[ ] Known Issue: Any existing active payment links need to be disabled if request is closed - will fix after prod release #3137

Checked off the first box - Test Inflight requests with CFR Fee payment Flow - This is to replicate the scenarios on existing FOI Requests on PROD. Requested business to create FOI requests at different states(Intake, CFR, Fee Estimate, harms, Review, closed etc.) prior to TEST release for Fee Payment.
I have tested the in-flight requests staged, and ran into minimal issues. I have specific instructions to give to users for requests that are already in the on-hold or fee estimate state, as there are some steps users will need to take if they want to minimize issues.

@abin-aot, tomorrow at standup, let's confirm what we need to QA here.

@lmullane : Nothing more need to be QA'd  since its in prod now. this ticket was created like an MOU on known issues, edge conditions etc before our PROD release. Now most of the flows are known to all, hence known issue can be taken as per the priority and particular flows which cause confusion can handled as per our planning.


[WIP] Updated monitoring deps and moved to cgroup (v2) monitoring for current process.

 Moving to different quite interesting method: https://github.com/efficientgo/e2e/pull/24


acfunlive <IP_ADDRESS>

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

Microsoft Reviewers: Open in CodeFlow

@oxygen-dioxide  what does this 'app' do?  I see it installs, but the only EXE I see is ksbugreport.exe and that does not seem to do anything.  Thanks,.

Acfunlive's installation path is where you run the command prompt. For example, after I cd desktop and install it, it installs on my desktop.


Feature Request - keep comments in generated code

Thanks @LingDong- for your nice little language!
The generated code is really clean and very close to the wax code.
I think it would be really nice if we had the option to keep the comments from wax code in the generated target code.
Not sure if everybody would like this. Maybe an optional compiler flag like --keepComments or a second syntax for comments that should be kept could be introduced?

Hi Quentie,
This project has sparked quite a bit of interest for me, and I've got a separate implementation going, which can target JavaScript, C++ currently.  It's really scratched an itch for me in terms of having a super lightweight language definition that's easy to parse and process, and can target multiple transpilation languages.
It does a fair bit, including some basic DOM integration to allow writing HTML/SVG content into a browser window.  Error handling's not so great at the moment, does have a good test suite though.
If there's interest, I can put it in a public git repo.  Just having a look at how I'm handing comments - currently I strip them to make the code generation phase easier, but I do have a wax language target which can process wax in/wax out for reformatting purposes - and that leaves comments intact, so it can be done.

@jacoblister Would love to see it

Hi @jacoblister this is looking good.

Yeh it's working pretty well.
The approach I've taken is to do a straight syntax translation as much as possible, and have the target language do the heavy lifting in terms of symbol resolution/type conversion etc. As such, the implementation can be very simple (the initial prototype I did was <1000 lines of code).
Ultimately I'd really like to get this running as just in time compiler, and generating native machine code on the fly - but this would involve implementing a symbol table, and a type conversion system.  There's a partial implementation in the file 'symbol.wax', but I wouldn't recommend looking at it - it's horrible.  The JS and C++ targets don't use it, there is a C language target which does, but it's only partially implemented.
The C target is partially implemented, and doesn't support dynamic memory allocation.  I'm able to generate C code from this and compile it with the TinyCC compiler on the fly https://bellard.org/tcc/.  For the JavaScript target, eval() can do this.  I'm using this generated code for audio DSP, which doesn't need a lot of language features.

Just to mention a few extra language features too, check the test_extended directory.
I've deliberately not wanted to add much, as having a core language spec that's so simple is the real attraction, but first class functions are must have to my mind - being able assign a function to a variable, and pass to and return from another function.
func.wax demonstrates this.  This feature is used to register event handlers in the DOM api.
there's also an attempt at GoLang style interfaces using this in 'interfaces.wax' building on this.


Build failure for hls_lfcd_lds_driver package

According to a rebuild of the ROS2 packages in my TurtleBot3 project lead to
an unexpected error in the hls_lfcd_lds_driver package while no changes to the
existing toolchain have been made.
After downloading the WindRiver SDK für the RPI3 in version 1.5 and
checking out the ROS2 branch dashing-release-SR0640-python, I was able
to reproduce the failing build. The build trace showed the following error.
Starting >>> hls_lfcd_lds_driver
Finished <<< message_filters [5.05s]
Starting >>> tf2_ros
--- stderr: hls_lfcd_lds_driver
/work/build/ros2/ros2_ws/src/utils/hls_lfcd_lds_driver/src/hlds_laser_publisher.cpp:189:3: error: expected unqualified-id
  catch (boost::system::system_error& ex)
  ^
/work/build/ros2/ros2_ws/src/utils/hls_lfcd_lds_driver/src/hlds_laser_publisher.cpp:194:1: error: extraneous closing brace ('}')
}
^
In file included from /work/build/ros2/ros2_ws/src/utils/hls_lfcd_lds_driver/src/hlds_laser_publisher.cpp:37:
/work/build/ros2/ros2_ws/src/utils/hls_lfcd_lds_driver/include/hls_lfcd_lds_driver/lfcd_laser.hpp:72:11: warning: private field 'motor_speed_' is not used [-Wunused-private-field]
        uint16_t motor_speed_; ///< @brief current motor speed as reported by the LFCD.
                 ^
1 warning and 2 errors generated.
make[4]: *** [CMakeFiles/hlds_laser_publisher.dir/src/hlds_laser_publisher.cpp.obj] Error 1
make[3]: *** [CMakeFiles/hlds_laser_publisher.dir/all] Error 2
make[2]: *** [all] Error 2
---
Failed   <<< hls_lfcd_lds_driver [5.88s, exited with code 2]
Aborted  <<< tf2_ros [3.97s]

Summary: 75 packages finished [2min 31s]
  1 package failed: hls_lfcd_lds_driver
  1 package aborted: tf2_ros
  9 packages had stderr output: dynamixel_sdk geometry_msgs hls_lfcd_lds_driver nav_msgs rmw_cyclonedds_cpp sensor_msgs std_srvs tf2_msgs turtlebot3_msgs
  1 package not processed
Makefile:84: recipe for target 'turtlebot3.build' failed
make[1]: *** [turtlebot3.build] Error 2
make[1]: Leaving directory '/work/pkg/turtlebot3'
make: *** [Makefile:19: all] Error 1

Looking at code of hlds_laser_publisher.cpp (see below) the formatting of
the try-catch block in the main-method is not correct. As temporary fix I just
used comments to solve the braces-issue. It would be helpful, to solve this
misspelling in a further git patch, so the build does not require two tries.
int main(int argc, char **argv)
{
  rclcpp::init(argc, argv);
  fd = open("/usb2ttyS/1", O_RDWR);
  if (fd < 0) {
        printf("Cannot open %s\n","/usb2ttyS/1");
  }
  auto node = rclcpp::Node::make_shared("hlds_laser_publisher");
  rclcpp::Publisher<sensor_msgs::msg::LaserScan>::SharedPtr laser_pub;
  std::string port;
  std::string frame_id;
  int baud_rate;
  node->declare_parameter("port");
  node->declare_parameter("frame_id");

  node->get_parameter_or<std::string>("port", port, "/usb2ttyS/1");
  node->get_parameter_or<std::string>("frame_id", frame_id, "laser");
  baud_rate = 230400;
  RCLCPP_INFO(node->get_logger(), "Init hlds_laser_publisher Node Main");
  RCLCPP_INFO(node->get_logger(), "port : %s frame_id : %s", port.c_str(), frame_id.c_str());
// MISSING try{ expression
// try {
    hls_lfcd_lds::LFCDLaser laser(port, baud_rate);
    laser_pub = node->create_publisher<sensor_msgs::msg::LaserScan>("scan", rclcpp::QoS(rclcpp::SensorDataQoS()));
    auto scan = std::make_shared<sensor_msgs::msg::LaserScan>();
    while (rclcpp::ok())
    {
      scan->header.frame_id = frame_id;
      laser.poll(scan);
      scan->header.stamp = node->now();
      laser_pub->publish(*scan);
    }
    laser.close();

    return 0;
//  }
// unknown exception to catch
//  catch (boost::system::system_error& ex)
//  {
    //ROS_ERROR("An exception was thrown: %s", ex.what());
//    return -1;
//  }
}

hi @sdoerr20, thanks for reporting it.
We do support the SR0640 VxWorks release with ROS2. Please use VxWorks SDK for Raspberry Pi 3 version 1.4 - https://labs.windriver.com/downloads/wrsdk-vxworks7-raspberrypi3b-1.4.tar.bz2
Is it any particular reason why you have selected the SR0650 SDK?

Hi @razr, I am also took a look at the RPI3 SDK in version, as this is the first
version mentioning a VS code plug-in. We are currently thinking of offering
VS code as second IDE for RTP development.
For completeness I have also tested version 1.4 now with the same result.

thanks, @sdoerr20 for reporting it. Indeed one patch fails to apply. it is fixed now https://github.com/Wind-River/vxworks7-layer-for-ros2/commit/0c9c6905ec3d3a6365056777cceba54bc58a071e

@razr Thanks for the update here. I was able to run the ROS2 build without stopping because of an error message.

I create a turtlebot3 in ros2galactic it's almost done but one small problem is occurred in colcon build --symlink -install
Error:1 package failed:hls_lfcd_lds_driver
Please any one give a solution for this problem


Add queries to Client which are required in React sdk

Adds following queries

profile.getById
profile.getUsers
profile.getTotalGains
profile.getMintFees
escrow.getProtocolAndPlatformFees
proposals.getByServiceId
proposals.getByUser
service.getSerivcePayments
review.getByService

please take a look @pranav-singhal
During review of #1 Romain asked to have no queries in React sdk such that all queries are contained within the Client

Hi @0xRomaim, please review


GNOME 3.38

Progress/status
See this GitHub project for what work is in progress.
Rebase Todo's
Conflicts from https://github.com/NixOS/nixpkgs/commit/e6f5583c6e0d8ea529ace71a1e1d146819a7aa9d (in staging)
Hydra
https://hydra.nixos.org/jobset/nixpkgs/gnome#tabs-evaluations
This is based off https://hydra.nixos.org/build/127581079 2a35f664394b379e0c0785cc769ff6ccc791be39.

The gobject-introspection build fails with:
/build/gobject-introspection-1.66.0/build/tools/g-ir-scanner --output=gir/GLib-2.0.gir --no-libtool --quiet --reparse-validate --add-include-path /build/gobject-introspection-1.66.0/build/gir --add-include-path /build/gobject-introspection-1.66.0/gir --identifier-prefix=G --symbol-prefix=g --symbol-prefix=glib --c-include=glib.h --namespace=GLib --nsversion=2.0 --library=glib-2.0 --library=gobject-2.0 --external-library --pkg=glib-2.0 --cflags-begin -I/nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0 -I/nix/store/6n7zkqbr8fghca2m70f1s1mn813pwzlm-glib-2.66.0/lib/glib-2.0/include -DGLIB_COMPILATION -D__G_I18N_LIB_H__ -DGETTEXT_PACKAGE=Dummy --cflags-end /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/gobject/glib-types.h /nix/store/6n7zkqbr8fghca2m70f1s1mn813pwzlm-glib-2.66.0/lib/glib-2.0/include/glibconfig.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib-unix.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/galloca.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/garray.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gasyncqueue.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gatomic.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gbacktrace.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gbase64.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gbitlock.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gbookmarkfile.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gbytes.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gcharset.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gchecksum.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gconvert.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gdataset.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gdate.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gdatetime.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gdir.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/genviron.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gerror.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gfileutils.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/ggettext.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/ghash.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/ghmac.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/ghook.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/ghostutils.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gi18n-lib.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gi18n.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/giochannel.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gkeyfile.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/glist.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gmacros.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gmain.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gmappedfile.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gmarkup.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gmem.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gmessages.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gnode.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/goption.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gpattern.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gpoll.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gprimes.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gprintf.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gqsort.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gquark.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gqueue.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/grand.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/grcbox.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/grefcount.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/grefstring.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gregex.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gscanner.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gsequence.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gshell.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gslice.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gslist.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gspawn.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gstdio.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gstrfuncs.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gstring.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gstringchunk.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gtestutils.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gthread.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gthreadpool.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gtimer.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gtimezone.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gtrashstack.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gtree.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gtypes.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gunicode.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/guri.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gutils.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/guuid.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gvariant.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gvarianttype.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gversion.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gversionmacros.h /nix/store/kq473bdr42scj0igcsvl3mh9ihn41v58-glib-2.66.0-dev/include/glib-2.0/glib/gwin32.h ../gir/glib-2.0.c
/bin/sh: /build/gobject-introspection-1.66.0/build/tools/g-ir-scanner: not found

[100/163] Compiling C object tests/repository/gitestthrows.p/gitestthrows.c.o
[101/163] Compiling C object tests/repository/gitestrepo.p/gitestrepo.c.o
[102/163] Linking target tests/repository/giteststructinfo
[103/163] Compiling C object tests/repository/gitypelibtest.p/gitypelibtest.c.o
[104/163] Compiling C object tests/scanner/libregress-1.0.so.p/regress.c.o
[105/163] Compiling C object tests/libgimarshallingtests-1.0.so.1.0.0.p/gimarshallingtests.c.o
ninja: build stopped: subcommand failed.

Something is wrong here: https://gitlab.gnome.org/GNOME/gobject-introspection/blob/5a673c1067b779bfbb4632a76340e0fa19305b58/gir/meson.build#L44-52 Though I can't find the culprint - in a cntr, the file g-ir-scanner exists in the reported location.
Help will be appreciated by Meson / Gnome Gurus such as @jtojnar && @worldofpeace . I hope it's OK to contact you here and not in a PM or IRC, I'm just not an IRC kind of guy.

You need to patchShebangs it.

g-ir-scanner is generated during configurePhase apparently, and not during build as I previously thought. I was also expecting /usr/bin/env python3 to work if python is in $PATH, but I guess not. Thanks!

Yeah, there's no /usr/bin/env in the build sandbox IIRC.

Help will be appreciated by Meson / Gnome Gurus such as jtojnar && worldofpeace . I hope it's OK to contact you here and not in a PM or IRC, I'm just not an IRC kind of guy.

PR comments are usually better place to ask about PR anyway, people just sometimes prefer chat form (IRC or Matrix) because they find it more convenient.  But that only works when people are available at the same time :woman_shrugging:
Yeah, patchShebangs is usually the proper solution, though we should check if a correct Python is selected when cross-compiling (see pkgsCross.aarch64-multiplatform.gobject-introspection).

@doronbehar I mentioned in my previous comments that PM's are okay with me, and we also have #nixos-gnome. Comments on here will be preferred though.
We also use the https://github.com/NixOS/nixpkgs/projects/30 gnome-3.38 project. Past examples like https://github.com/NixOS/nixpkgs/projects/24. This is really helpful to coordinate todo's because GitHub adores collapsing PRs like this one so at the end of it all this discussion is going to be hard to retrieve (or recall what was done)

Hmm, looks like gobject-introspection does not even cross-compile today so we can just ignore that.

https://github.com/NixOS/nixpkgs/pull/88222 .

Here's what I'm encountering right now:
gtk needs to be patched because of:
$ grep includedir= $(nix-build --no-out-link -A gtk3.dev)/lib/pkgconfig/*
/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/lib/pkgconfig/gail-3.0.pc:includedir=/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev//nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/include
/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/lib/pkgconfig/gdk-3.0.pc:includedir=/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev//nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/include
/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/lib/pkgconfig/gdk-wayland-3.0.pc:includedir=/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev//nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/include
/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/lib/pkgconfig/gdk-x11-3.0.pc:includedir=/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev//nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/include
/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/lib/pkgconfig/gtk+-3.0.pc:includedir=/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev//nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/include
/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/lib/pkgconfig/gtk+-unix-print-3.0.pc:includedir=/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev//nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/include
/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/lib/pkgconfig/gtk+-wayland-3.0.pc:includedir=/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev//nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/include
/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/lib/pkgconfig/gtk+-x11-3.0.pc:includedir=/nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev//nix/store/ic5l0papvxwpfzg94qr4rji0az9cf5yd-gtk+3-3.24.23-dev/include

What I'm pushing, is what's supposed to build. I'm climbing up the dependency chain to gnome's core apps, current goal is gnome-shell.

What I'm pushing, is what's supposed to build. I'm climbing up the dependency chain to gnome's core apps, current goal is gnome-shell.

Cool, I'm just going to commit gnome-initial-setup things today.

@worldofpeace IIRC gnome-tour needed librsvg added too otherwise it fails to load graphics at runtime.

@worldofpeace IIRC gnome-tour needed librsvg added too otherwise it fails to load graphics at runtime.

Will add and look at the main issue again with your observation :+1:

This is as far as I got today:
installed_tests.patch doesn't apply to gjs. And without it the build fails with failing tests.
I created a cachix store and I pushed to it successful compilations such as llvm_7, gtk3, glib and spidermonkey_78. It's at: https://app.cachix.org/cache/gnome3-38 .
Plus, I'm testing the updates with this uncommitted changes: https://gist.githubusercontent.com/doronbehar/702da75b1e1adc40d0c31e748d6e1d77/raw/a41099afe78216cf3fb1894b436058773c71d767/gistfile1.txt .
Going to sleep now :zzz: .

I had @AmineChikhaoui fixup the jobset target and scheduling shares. The eval is currently running, though there isn't much here yet. Thought  it would be a good thing to get out the way while work is in progress. Also just rebased this to nixos-unstable so we don't have possibly broken changes underneath us. Will link the jobset and eval to compare in the OP.

@pbogdan I've pushed basically all of your changes. The only one, which we talked about, was with tracker defaulting to the latest and adding tracker_2. I diff between these branches should reveal mostly all the changes.
Just going to check if it actually evals :grin:

Okay, done for the night :rofl:
We'll find out how much of that actually worked from hydra.

@worldofpeace I hardly believe gjs will build now, and hence most of the core apps up in the dependency. Are we sure we want to change the base to master?

Since we have a hydra job now, there will be no mass rebuild when we merge it to master (if we rebase before merge).

I am thinking of marking individual commits as reviewed using sign-off tags git commit --allow-empty -s --squash <commit>. That way we will see which commits were reviewed during rebase.
Maybe we should also use --squash instead of --fixup for ameliorations so that they do not disappear during rebase (though ideally, everything should be reviewed before autosquash).

Not directly related to the changes here but we may want 3bfdbea8819989c610ef30ae1e0acf7739a74807 in this branch as the test suite if very unreliable.

gexiv2 fails its test suite with:
builder for '/nix/store/lfvbvb1bpky7fcrjj9s5qkmanwld2nwy-gexiv2-0.12.1.drv' failed with exit code 1; last 10 log lines:
  Bail out! ERROR:../test/gexiv2-regression.c:248:test_ggo_xx: assertion failed (error == NULL): Error when getting information for file descriptor: Numerical result out of range (g-io-error-quark, 0)
  --- stderr ---
  **
  ERROR:../test/gexiv2-regression.c:248:test_ggo_xx: assertion failed (error == NULL): Error when getting information for file descriptor: Numerical result out of range (g-io-error-quark, 0)
  -------

which I'm guessing is related to glib changes.

gjs fails its test suite too:
builder for '/nix/store/r59h69hsikzp50jbhikhpc7gbw71p0zb-gjs-1.66.0.drv' failed with exit code 1; last 10 log lines:
  ** Message: 14:29:13.765: Temp profiler file not deleted
  **
  This is an exception 42

  (/build/gjs-1.66.0/build/test/gjs-tests:1840): Gjs-CRITICAL **: 14:29:14.285: Error writing coverage data: Error when getting information for file descriptor: Numerical result out of range

  (test program exited with status code -5)
  -------

Both seem to pass the tests here (Ubuntu machine). Maybe it is file system specific?

Hmm, could be, I use ZFS so maybe that's causing an issue, what FS are you on?

From a quick look these look possibly relevant:

https://gitlab.gnome.org/GNOME/glib/-/issues/2189
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1648

Nix seems to use build directories under /tmp here, which is on ext4 file system.

I'm gonna try the upstream MR to see if it helps.

Looks like applying the MR works (at least as verified by gexiv2 test suite), the MR also links another issue https://gitlab.gnome.org/GNOME/glib/-/issues/2205 specifically related to ZFS.

Verified gjs is happy too with the patch applied. It hasn't been merged upstream though - do we want to apply it as is or wait for upstream to integrate it and/or make a new release?

I would not expect a new release soon so applying https://gitlab.gnome.org/GNOME/glib/-/commit/642baa50fa561f7abfbbfe5ac9a10351a706b95a.patch for now will be probably necessary.

@jtojnar I think we should manage all gnome related patches with git-series, I've done this for https://github.com/NixOS/nixpkgs/blob/169486a538f6f31c42c6e3cfad459e471a9bdf39/pkgs/desktops/gnome-3/core/gnome-initial-setup/0001-fix-paths.patch and other patches for nixpkgs. It in a line similar to how debian uses quilt. I've found it to help me regenerate patches a lot faster https://github.com/git-series/git-series/#overview-of-commands.

Addressed some TODOs in the project. As for SOF / UCM support (https://github.com/NixOS/nixpkgs/issues/98470) I only tested the build to work, but I don't know if it'd actually work for those laptops' users.
As for this card, the last commit I pushed (e3c6822bdd5e684f782e2f8f6961f74eb0007ed5) should do it, but we should set the libexecdir? (@worldofpeace )

As for gnome-tweaks BTW, it seems they have not tagged a new release at https://gitlab.gnome.org/GNOME/gnome-tweaks/-/tags and the master branch still looks like another meson project. (In response to this card)

Addressed some TODOs in the project. As for SOF / UCM support (#98470) I only tested the build to work, but I don't know if it'd actually work for those laptops' users.

Yep,  thanks perfect :+1:

As for this card, the last commit I pushed (e3c6822) should do it, but we should set the libexecdir? (@worldofpeace )

I wanted to check what @jtojnar thought about https://github.com/NixOS/nixpkgs/projects/30#card-45843182.

As for gnome-tweaks BTW, it seems they have not tagged a new release at https://gitlab.gnome.org/GNOME/gnome-tweaks/-/tags and the master branch still looks like another meson project. (In response to this card)

Yeah, not sure about that (might check the ML?), but using buildPythonApplication could still be done.

I wanted to check what @jtojnar thought about NixOS/nixpkgs/projects/30#card-45843182.

Along with https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/202#note_919361, I think it would be best to split the gnome-session-ctl into a separate package – it looks reasonably self-contained.

I decided to split out gnome-session-ctl into its own project https://github.com/nix-community/gnome-session-ctl.
It would be nice if upstream could do this too (it's one executable).
Also updated https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/202 to be a gnome_session_ctl_path option as @jtojnar suggested.

@doronbehar I reverted the gdm commit because it does break things since gnome-shell depends on gdm.
Rather hesitant to downstream patch gdm because we don't have installation flags with meson :frowning:

geary currently fails to build https://github.com/NixOS/nixpkgs/projects/30#card-46211952.

Okay, if you disable geary the gnome test will run and start :+1:

I updated the projects todo's with packages that fail on hydra.

More packages now build (besides meld on Darwin). The main work left as it seems now (I follow the Github's project's TODO) is to decide how to handle GDM and gnome-session-ctl.

gdm is getting better - it now builds with meson with most of the previously configureFlags set in mesonFlags. I assume it's not usable yet, and I haven't got to the bottom of the gnome-session-ctl and gnome-settings-daemon issue, but at least it's a good start.

Did you manage to make it install the configs to $out/etc but read them from /etc at runtime?
It may also need something like this to help it find various dbus- binaries https://github.com/pbogdan/nixpkgs/commit/2514bf231029f59cf7d96141eee4b5ea2d4812da

gdm is getting better - it now builds with meson with most of the previously configureFlags set in mesonFlags. I assume it's not usable yet, and I haven't got to the bottom of the gnome-session-ctl and gnome-settings-daemon issue, but at least it's a good start.

It's fixed already. The only thing left to do was to get upstream to move this tool out. Currently I've made a project at nix-community https://github.com/nix-community/gnome-session-ctl documenting the issue in the README.md and created a buildsystem just for it.

Did you manage to make it install the configs to $out/etc but read them from /etc at runtime?

No. Perhaps we should hard code /etc/ here: https://gitlab.gnome.org/GNOME/gdm/blob/265b152f7a861946e0281e681bb02341b06af1a2/meson.build#L203 while the current sysconfdir is used for installing those files.

It may also need something like this to help it find various dbus- binaries pbogdan@2514bf2

Thanks :) Took it.

No. Perhaps we should hard code /etc/ here: gitlab.gnome.org/GNOME/gdm/blob/265b152f7a861946e0281e681bb02341b06af1a2/meson.build#L203 while the current sysconfdir is used for installing those files.

I think ideally we would need to create a patch to add a sysconfdir_install Meson option like jtojnar said. I'm not too familiar with Meson but adding it looked rather not trivial to me :-(.
I worked around it with this without touching the Meson side of things but I don't think that's something we really want to be doing...

I think ideally we would need to create a patch to add a sysconfdir_install Meson option like jtojnar said. I'm not too familiar with Meson but adding it looked rather not trivial to me :-(.

If this patch won't be upstreamable, what would be the benefit?

If this patch won't be upstreamable, what would be the benefit?

The point is to be able to install files to $out/etc but be able to load them from /etc. Most distros do not have this problem since they install everything to FHS tree.
Alternative option would be to convince GDM to use /share for default config as it is more common to use /etc only for administrator’s configuration overrides these days but I am not sure if it is possible since some of the files in /etc are not config files but scripts.

If this patch won't be upstreamable, what would be the benefit?

The point is to be able to install files to $out/etc but be able to load them from /etc. Most distros do not have this problem since they install everything to FHS tree.

I understand the need for the patch. I only argue that hard-coding /etc/ in config.h or a similar hack should be good enough, vs doing it nicely by patching meson.build with well explained meson options etc. @pbogdan's "hack" is similar to what I prescribed (hardcoding /etc/ here) and looks good to me.

The main point of sysconfig_install is that if we miss some place where sysconfig is used, the installation will fail and let us know. And it is much cleaner to use a patch for that.

The main point of sysconfig_install is that if we miss some place where sysconfig is used, the installation will fail and let us know.

Maybe meson is so awesome that it shouldn't be that hard? @jtojnar it's hard for me to imagine a patch to meson that will (perhaps in future releases?) make the installation fail, and hence notify us that we should update the patch. For instance, with this patch to gdm, it still builds, but I didn't test it in runtime:
diff --git i/data/meson.build w/data/meson.build
index 05a20117..ac953253 100644
--- i/data/meson.build
+++ w/data/meson.build
@@ -11,7 +11,7 @@ foreach file : [ 'Init', 'PreSession', 'PostSession' ]
   )

   install_data(generated_file,
-    install_dir: gdmconfdir / file,
+    install_dir: gdm_install_confdir / file,
     install_mode: 'rwxr-xr-x',
     rename: 'Default'
   )
@@ -20,7 +20,7 @@ endforeach
 install_data('PostLogin',
   rename: 'Default.sample',
   install_mode: 'rwxr-xr-x',
-  install_dir: gdmconfdir / 'PostLogin',
+  install_dir: gdm_install_confdir / 'PostLogin',
 )

 # gdm.conf
@@ -215,6 +215,6 @@ if get_option('gdm-xsession')
       'libexecdir': gdm_prefix / get_option('libexecdir'),
       'XSESSION_SHELL': get_option('solaris')? '/bin/ksh' : '/bin/sh',
     },
-    install_dir: gdmconfdir,
+    install_dir: gdm_install_confdir,
   )
 endif
diff --git i/meson.build w/meson.build
index 7e336bfa..27edc317 100644
--- i/meson.build
+++ w/meson.build
@@ -15,7 +15,9 @@ cc = meson.get_compiler('c')
 # Options
 gdm_prefix = get_option('prefix')

-gdmconfdir = (get_option('sysconfsubdir') == '')? gdm_prefix / get_option('sysconfdir') : gdm_prefix / get_option('sysconfdir') / get_option('sysconfsubdir')
+gdm_install_confdir = (get_option('sysconfsubdir') == '')? gdm_prefix / get_option('sysconfdir') : gdm_prefix / get_option('sysconfdir') / get_option('sysconfsubdir')
+# TODO: Should this be an option?
+gdmconfdir = '/etc'
 dmconfdir = (get_option('dmconfdir') != '')? get_option('dmconfdir') : gdm_prefix / get_option('sysconfdir') / 'dm'
 udev_dir = get_option('udev-dir')
 at_spi_registryd_dir = (get_option('at-spi-registryd-dir') != '')? get_option('at-spi-registryd-dir') : gdm_prefix / get_option('libexecdir')
@@ -23,7 +25,7 @@ lang_config_file = (get_option('lang-file') != '')? get_option('lang-file') : gd
 pam_mod_dir = (get_option('pam-mod-dir') != '')? get_option('pam-mod-dir') : gdm_prefix / get_option('libdir') / 'security'
 dbus_sys_dir = (get_option('dbus-sys') != '')? get_option('dbus-sys') : get_option('sysconfdir') / 'dbus-1' / 'system.d'
 gdm_defaults_conf = (get_option('defaults-conf') != '')? get_option('defaults-conf') : gdm_prefix / get_option('datadir') / 'gdm' / 'defaults.conf'
-gdm_custom_conf = (get_option('custom-conf') != '')? get_option('custom-conf') : gdmconfdir / 'custom.conf'
+gdm_custom_conf = (get_option('custom-conf') != '')? get_option('custom-conf') : gdm_install_confdir / 'custom.conf'
 gdm_runtime_conf = (get_option('runtime-conf') != '')? get_option('runtime-conf') : gdm_custom_conf
 gnome_settings_daemon_dir = (get_option('gnome-settings-daemon-dir') != '')? get_option('gnome-settings-daemon-dir') : gdm_prefix / get_option('libexecdir')
 check_accelerated_dir = (get_option('check-accelerated-dir') != '')? get_option('check-accelerated-dir') : gdm_prefix / get_option('libexecdir')
@@ -284,7 +286,8 @@ summary({
     'logdir': get_option('log-dir'),
     'System DBus': dbus_sys_dir,
     'DM conf': dmconfdir,
-    'GDM conf': gdmconfdir,
+    'GDM Install conf directory': gdm_install_confdir,
+    'GDM Runtime conf directory': gdmconfdir,
     'GDM Screenshot ': gdm_screenshot_dir,
     'GDM Xauth': gdm_xauth_dir,
     'GDM RanOnceMarker': ran_once_marker_dir,

But it's more of an "options' renaming" rather then changing their meaning...

I've rebased because I felt like we were nearing the point of having too many commits.
These are my changes that needed review https://github.com/NixOS/nixpkgs/compare/067716156e9bd760bcd4db4d132f4cd8a8d3da02...81a6702734cc11ccba3f81fd6adb1020311a18b9
The last one is me supplying the changes requested for gdm and things I noticed. Still need to write a GDM meson patch.
Another thing I noticed was the not-delightful shell script to find the path to X (but they still hardcode to wayland!).
The fix committed is the most minimal, but I'm wondering if they could have massively simplified https://gitlab.gnome.org/GNOME/gdm/-/blob/3.38.0/meson.build#L73 by:

Not trying to figure out the perfect directory with crazy directory heuristics
And instead just letting the distributor pass the pathes with a meson option at configure. After all the distributor is going to know best if they have some specific setup.
Then just find_program for X, Xorg, Xserver, and Xsun in the case of the option not being used. I wonder if find_program will make those paths absolute, since they mentioned

# When testing for /usr/X11R6, first check with "! -h" for /usr/X11R6
# and /usr/X11 since they often symlink to each other, and configure
# should use the more stable location (the real directory) if possible.

If upstream really wants the buildsystem to support those environments exactly, then maybe find_program dirs 0 can be used to extend the lookup.
And lastly using fs.parent https://gitlab.gnome.org/GNOME/gdm/-/blob/3.38.0/meson.build#L79 to get the x_path from x_bin.

Okay this needs rebase because conflicts :grin:

I went through all the commits and all the associated upstream changelogs and it looks good, only few small changes were needed. I either pushed them or added them as cards to the project.
The main concern is still the GDM patch for installation sysconfdir. I looked into it a bit and realized it will be even bigger mess than initially expected, since there are so many variables using it. What is worse, writes to /etc actually succeed in the sandbox so we would need to make the directory read-only before installation. I am considering just seding the build.ninja file.
Next, support for Tracker 3 was added to GTK 3 but it requires depending on libtracker-sparql-3.0 instead of using D-Bus API like with Tracker 2. It is disabled by default because of possible symbol clash with apps linking against Tracker 2. https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1945
Then, gnome-screenshot made X11 dependency optional, should we remove it? https://gitlab.gnome.org/GNOME/gnome-screenshot/-/merge_requests/27
Once someone reviews the latest commits, I can rebase it and deal with the meta-squash commits.

The main concern is still the GDM patch for installation sysconfdir. I looked into it a bit and realized it will be even bigger mess than initially expected, since there are so many variables using it. What is worse, writes to /etc actually succeed in the sandbox so we would need to make the directory read-only before installation. I am considering just seding the build.ninja file.

Yeah, I came to a similar conclusion that it's just too interconnected to bother handling. Though the bit needing nuke the path because of that scary script to find X directories is something I wanted to fix for them https://github.com/NixOS/nixpkgs/pull/98316#issuecomment-703216363. I saw a thumbs up, but I was wondering if you had any commentary on the evaluation. Currently I'm a :+1: on the sed to build.ninja.

Next, support for Tracker 3 was added to GTK 3 but it requires depending on libtracker-sparql-3.0 instead of using D-Bus API like with Tracker 2. It is disabled by default because of possible symbol clash with apps linking against Tracker 2. https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1945

I wonder how much bigger that would make gtk3 in terms of closure size? TBH I would've preferred using DBus API like Tracker 2

Then, gnome-screenshot made X11 dependency optional, should we remove it? https://gitlab.gnome.org/GNOME/gnome-screenshot/-/merge_requests/27

I would guess that would make the program non functional in X? I think because we still have the xorg session, and there could be users outside of gnome it would be best to not disable it. Probably just future planning.

tepl got updated again 9 hours ago https://gitlab.gnome.org/GNOME/tepl/-/blob/master/NEWS#L1
Everything else looks good.

Squashed 84d74ae9c9cbed73274b8e4e00be14688ffc93fe..dac8a94b820 → 84d74ae9c9cbed73274b8e4e00be14688ffc93fe..0da72c9a55b.

I went ahead and:
* dropped telepathy from the default session #99531

Yeah, at this point Telepathy is broken for GNOME ecosystem, people gave up on centralised communication platform, only Polari has a semblance of maintained. Only Qt side is still somewhat alive.
Handling it impurely is fine with me to reduce the maintenance effort.

Another thing I noticed was the not-delightful shell script to find the path to X (but they still hardcode to wayland!).
The fix committed is the most minimal, but I'm wondering if they could have massively simplified gitlab.gnome.org/GNOME/gdm/-/blob/3.38.0/meson.build#L73 by:
* Not trying to figure out the perfect directory with crazy directory heuristics
  And instead just letting the distributor pass the pathes with a meson option at configure. After all the distributor is going to know best if they have some specific setup.
  Then just `find_program` for `X`, `Xorg`, `Xserver`, and `Xsun` in the case of the option not being used. I wonder if `find_program` will make those paths absolute, since they mentioned

# When testing for /usr/X11R6, first check with "! -h" for /usr/X11R6
# and /usr/X11 since they often symlink to each other, and configure
# should use the more stable location (the real directory) if possible.

If upstream really wants the buildsystem to support those environments exactly, then maybe find_program dirs 0 can be used to extend the lookup.

Agreed. If I maintained GDM, I would just add a Meson option defaulting to find_program looking up on PATH. I guess we should probe devs on IRC about this.

And lastly using fs.parent gitlab.gnome.org/GNOME/gdm/-/blob/3.38.0/meson.build#L79 to get the x_path from x_bin.

I am vary of using path manipulation for finding dependencies. After all, we have everything in a different prefix. Looks like X_PATH is only used in data/PreSession.in and data/Init.in. And, I suspect, in data/Xsession.in by inheriting the PATH from one of the aforementioned.
But this is a mess. There are many different X.org programs used and it is in /etc so there might be some expectations of user tweaking too so we probably cannot just use resholved or something.
In conclusion, I would prefer not to touch since I do not understand it and do not really want to dig into X.org stuff any more.

I wonder how much bigger that would make gtk3 in terms of closure size? TBH I would've preferred using DBus API like Tracker 2

Will need to measure.

Then, gnome-screenshot made X11 dependency optional, should we remove it? https://gitlab.gnome.org/GNOME/gnome-screenshot/-/merge_requests/27

I would guess that would make the program non functional in X? I think because we still have the xorg session, and there could be users outside of gnome it would be best to not disable it. Probably just future planning.

It is supposed to use GNOME Shell API. It would only make it non-functional outside of GNOME Shell. Not sure if we support that.

Rebased and ready for another round.

Instead of patching build.ninja, I resorted to using DESTDIR :nauseated_face:

About packaging gtk-frdp individually https://gitlab.gnome.org/GNOME/gtk-frdp/-/issues/29. From reading that I was okay as it just being a subproject for connections.

Okay, we can revisit it later.

GDM does not like to start with the following error in the journal:
Oct 13 07:09:35 nixos .gnome-shell-wr[875]: JS ERROR: Error: GSettings schema org.gnome.login-screen not found
                                            _init@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:556:23
                                            _init@resource:///org/gnome/shell/misc/systemActions.js:136:37
                                            getDefault@resource:///org/gnome/shell/misc/systemActions.js:28:22
                                            _init@resource:///org/gnome/shell/ui/status/system.js:18:31
                                            _init@resource:///org/gnome/shell/ui/panel.js:738:24
                                            _ensureIndicator@resource:///org/gnome/shell/ui/panel.js:1065:25
                                            _updateBox@resource:///org/gnome/shell/ui/panel.js:1076:34
                                            _updatePanel@resource:///org/gnome/shell/ui/panel.js:1022:14
                                            _init@resource:///org/gnome/shell/ui/panel.js:831:14
                                            _initializeUI@resource:///org/gnome/shell/ui/main.js:218:13
                                            start@resource:///org/gnome/shell/ui/main.js:159:5
                                            @<main>:1:47
Oct 13 07:09:35 nixos .gnome-shell-wr[875]: Execution of main.js threw exception: Script <main> threw an exception

But it does not look like the line has been touched recently:
https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/b2a2ea7868f37ab614566730c4fd3c15b3814d99/js/misc/systemActions.js#L136
Probably some environment shenanigans again.

It now starts.
g-i-s seems to work but the following appears in logs:
Oct 13 07:29:25 nixos .gnome-initial-[1453]: Could not find signal handler 'webcam_icon_selected'.  Did you compile with -rdynamic?

Various stuff spawned by search providers is buggy:
Oct 13 07:32:08 nixos gnome-terminal-server[1616]: Display does not support owner-change; copy/paste will be broken!

Oct 13 07:32:08 nixos dbus-daemon[1074]: [session uid=1000 pid=1074] Successfully activated service 'org.gnome.Calculator.SearchProvider'
Oct 13 07:32:08 nixos dbus-daemon[1074]: [session uid=1000 pid=1074] Successfully activated service 'org.gnome.Nautilus'
Oct 13 07:32:08 nixos .gnome-calculat[1603]: search-provider.vala:117: Failed to spawn Calculator: Child process killed by signal 9

Oct 13 07:32:09 nixos org.gnome.Epiphany.SearchProvider[1615]: WaylandCompositor requires eglBindWaylandDisplayWL, eglUnbindWaylandDisplayWL and eglQueryWaylandBuffer.
Oct 13 07:32:09 nixos org.gnome.Epiphany.SearchProvider[1615]: Nested Wayland compositor could not initialize EGL

Oct 13 07:32:10 nixos .gnome-photos-w[1612]: Unable to create PhotosTrackerQueue: Failed to load SPARQL backend: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Tracker1 was not provided by any .service files

Oct 13 07:32:10 nixos dbus-daemon[1074]: [session uid=1000 pid=1074] Successfully activated service 'org.gnome.Epiphany.SearchProvider'

Oct 13 07:32:11 nixos .nautilus-wrapp[1601]: Tracker 2 migration: Couldn't run `tracker3`: Failed to execute child process “tracker3” (No such file or directory)
Oct 13 07:32:11 nixos .nautilus-wrapp[1601]: Connecting to org.freedesktop.Tracker3.Miner.Files
Oct 13 07:32:12 nixos .gnome-photos-w[1612]: Unable to create PhotosTrackerQueue: Failed to load SPARQL backend: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Tracker1 was not provided by any .service files

Oct 13 07:32:12 nixos .tracker-miner-[1739]: Unable to find default domain ontology rule /nix/store/myhplz8b34gnvrv06cb6m1584hwhc0fn-tracker-3.0.0/share/tracker3-miners/domain-ontologies/default.rule
Oct 13 07:32:12 nixos kernel: traps: .tracker-miner-[1739] trap int3 ip:7f464feb3bb5 sp:7ffe47d91150 error:0 in libglib-2.0.so.0.6600.1[7f464fe79000+85000]

It seems programs for tracker 2 -> 3 migration need the binary
Oct 13 07:32:11 nixos .nautilus-wrapp[1601]: Tracker 2 migration: Couldn't run `tracker3`: Failed to execute child process “tracker3” (No such file or directory)
Oct 13 07:32:11 nixos .nautilus-wrapp[1601]: Connecting to org.freedesktop.Tracker3.Miner.Files

This probably does not affect us since files created by environment.etc are read only but we should still fix it in case trying to write into read-only path causes an issues. https://discourse.gnome.org/t/gdm-3-38-0-has-bad-bug-for-nvidia-users/4517

gnome-control-center crash: When clicking through panels. After ~10 clicks, different panels triggering it:
Oct 13 19:30:13 nixos gnome-control-center.desktop[1666]: double free or corruption (out)
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007fc74d659528 in __GI_abort () at abort.c:79
#2  0x00007fc74d6b08a8 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fc74d7b97d0 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007fc74d6b7a0a in malloc_printerr (str=str@entry=0x7fc74d7bbd18 "double free or corruption (out)") at malloc.c:5347
#4  0x00007fc74d6b9828 in _int_free (av=0x7fc74d7f09e0 <main_arena>, p=0x7fc71003cae0, have_lock=<optimized out>) at malloc.c:4314
#5  0x00007fc74d6bc71b in tcache_thread_shutdown () at malloc.c:2964
#6  __malloc_arena_thread_freeres () at arena.c:951
#7  0x00007fc74d6bf84c in __libc_thread_freeres () at thread-freeres.c:38
#8  0x00007fc74d7fded3 in start_thread (arg=<optimized out>) at pthread_create.c:491
#9  0x00007fc74d72ed2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Another g-c-c crash when trying to add an outlook account in geary, again non-deterministic.
Oct 13 19:48:11 nixos org.gnome.ControlCenter[2384]: WaylandCompositor requires eglBindWaylandDisplayWL, eglUnbindWaylandDisplayWL and eglQueryWaylandBuffer.
Oct 13 19:48:11 nixos org.gnome.ControlCenter[2384]: Nested Wayland compositor could not initialize EGL
Oct 13 19:48:11 nixos .gnome-control-[2384]: gtk_widget_hide: assertion 'GTK_IS_WIDGET (widget)' failed
Oct 13 19:48:11 nixos .gnome-control-[2384]: g_object_notify_queue_thaw: assertion 'g_atomic_int_get(&object->ref_count) > 0' failed
Oct 13 19:48:11 nixos .gnome-control-[2384]: invalid unclassed pointer in cast to 'GtkWidget'
Oct 13 19:48:11 nixos .gnome-control-[2384]: invalid unclassed pointer in cast to 'CcPanel'
Oct 13 19:48:11 nixos .gnome-control-[2384]: cc_shell_set_active_panel: assertion 'panel == NULL || CC_IS_PANEL (panel)' failed
Oct 13 19:48:11 nixos .gnome-control-[2384]: gtk_widget_show: assertion 'GTK_IS_WIDGET (widget)' failed
Oct 13 19:48:11 nixos .gnome-control-[2384]: gtk_stack_add_named: assertion 'GTK_IS_WIDGET (child)' failed
Oct 13 19:48:11 nixos .gnome-control-[2384]: gtk_widget_show: assertion 'GTK_IS_WIDGET (widget)' failed
Oct 13 19:48:11 nixos .gnome-control-[2384]: Child name 'online-accounts' not found in GtkStack
Oct 13 19:48:11 nixos .gnome-control-[2384]: invalid unclassed pointer in cast to 'CcPanel'
Oct 13 19:48:11 nixos kernel: .gnome-control-[2384]: segfault at 3f8 ip<PHONE_NUMBER>457e73 sp 00007ffec70af518 error 4 in .gnome-control-center-wrapped[44c000+112000]
Oct 13 19:48:11 nixos kernel: Code: 0f 1f 80 00 00 00 00 48 8b 07 48 8b 80 f0 03 00 00 48 85 c0 74 09 ff e0 0f 1f 80 00 00 00 00 31 c0 c3 0f 1f 44 00 00 48 8b 07 <48> 8b 80 f8 03 00 00 48 85 c0 74 09 ff e0 0f 1f 80 00 00 00 00 31
Oct 13 19:48:11 nixos systemd[1]: Started Process Core Dump (PID 2404/UID 0).
░░ Subject: A start job for unit<EMAIL_ADDRESS>has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit<EMAIL_ADDRESS>has finished successfully.
░░
░░ The job identifier is 2179.
Oct 13 19:48:12 nixos gnome-shell[1145]: libinput error: event1  - QEMU QEMU USB Tablet: client bug: event processing lagging behind by 16ms, your system is too slow
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: ![crt] 19:48:12.0786 geary:accounts_name_row_construct: assertion 'default_name != NULL' failed
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: ![crt] 19:48:12.0788 GLib-GObject:g_object_ref_sink: assertion 'G_IS_OBJECT (object)' failed
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: ![crt] 19:48:12.0788 Gtk:gtk_container_add: assertion 'GTK_IS_WIDGET (widget)' failed
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: ![crt] 19:48:12.0789 geary:accounts_add_pane_row_get_validator: assertion 'ACCOUNTS_IS_ADD_PANE_ROW (self)' failed
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: *[wrn] 19:48:12.0790 GLib-GObject:invalid (NULL) pointer instance
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: ![crt] 19:48:12.0790 GLib-GObject:g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: ![crt] 19:48:12.0791 geary:accounts_labelled_editor_row_get_value: assertion 'ACCOUNTS_IS_LABELLED_EDITOR_ROW (self)' failed
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: *[wrn] 19:48:12.0791 GLib-GObject:invalid (NULL) pointer instance
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: ![crt] 19:48:12.0791 GLib-GObject:g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: ![crt] 19:48:12.0896 geary:accounts_labelled_editor_row_get_value: assertion 'ACCOUNTS_IS_LABELLED_EDITOR_ROW (self)' failed
Oct 13 19:48:12 nixos org.gnome.Geary[2362]: ![crt] 19:48:12.0896 Gtk:gtk_widget_grab_focus: assertion 'GTK_IS_WIDGET (widget)' failed
Oct 13 19:48:15 nixos systemd-coredump[2406]: [🡕] Process 2384 (.gnome-control-) of user 1000 dumped core.

#0  0x0000000000457e73 in cc_panel_get_title_widget ()
#1  0x000000000045b106 in set_active_panel_from_id.isra ()
#2  0x000000000045616f in launch_panel_activated ()
#3  0x00007ff3e9c54f82 in g_closure_invoke (closure=0x2b343d0, return_value=0x0, n_param_values=2, param_values=0x7ffec70af7d0, invocation_hint=0x7ffec70af750) at ../gobject/gclosure.c:810
#4  0x00007ff3e9c67ee4 in signal_emit_unlocked_R (node=node@entry=0x7ff3c4012720, detail=detail@entry=0, instance=instance@entry=0x29c5590, emission_return=emission_return@entry=0x0,
    instance_and_params=instance_and_params@entry=0x7ffec70af7d0) at ../gobject/gsignal.c:3738
#5  0x00007ff3e9c7313f in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffec70af9a0) at ../gobject/gsignal.c:3494
#6  0x00007ff3e9c73acf in g_signal_emit (instance=instance@entry=0x29c5590, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3550
#7  0x00007ff3e9d81dcd in g_simple_action_activate (action=0x29c5590, parameter=0x2f0ca60) at ../gio/gsimpleaction.c:225
#8  0x00007ff3e9d805bd in g_action_activate (action=0x29c5590, parameter=0x2f0ca60) at ../gio/gaction.c:397
#9  0x00007ff3e9d76a94 in g_application_exported_actions_activate_action_full (remote=0x2417350, action_name=0x2e6f890 "launch-panel", parameter=0x2f0ca60, platform_data=0x2f87470) at ../gio/gapplication.c:330
#10 0x00007ff3e9d7eb73 in org_gtk_Actions_method_call (connection=<optimized out>, sender=sender@entry=0x7ff3c402cee0 ":1.178", object_path=object_path@entry=0x7ff3c4012590 "/org/gnome/ControlCenter",
    interface_name=interface_name@entry=0x7ff3c4026de0 "org.gtk.Actions", method_name=method_name@entry=0x7ff3c4021fe0 "Activate", parameters=parameters@entry=0x2f87720, invocation=0x2f53eb0,
    user_data=0x29c3330) at ../gio/gactiongroupexporter.c:440
#11 0x00007ff3e9da3093 in call_in_idle_cb (user_data=0x2f53eb0) at ../gio/gdbusconnection.c:4890
#12 0x00007ff3e9b63ade in g_main_dispatch (context=0x23ab9c0) at ../glib/gmain.c:3325
#13 g_main_context_dispatch (context=context@entry=0x23ab9c0) at ../glib/gmain.c:4016
#14 0x00007ff3e9b63e90 in g_main_context_iterate (context=context@entry=0x23ab9c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4092
#15 0x00007ff3e9b63f1f in g_main_context_iteration (context=context@entry=0x23ab9c0, may_block=may_block@entry=1) at ../glib/gmain.c:4157
#16 0x00007ff3e9d797dd in g_application_run (application=0x29d6700, argc=<optimized out>, argv=<optimized out>) at ../gio/gapplication.c:2559
#17 0x00000000004555e4 in main ()

I went through all the default-installed app and except from the minor issues above, and the g-c-c crashes, I did not notice anything broken or errors popping up in the journal.
I moved to the problems to the project. And we can start testing extensions now.

GSConnect now has installed tests and I managed to get every one of them pass except for LAN test. Weirdly, the constructor seems to return undefined.
Running test: gsconnect/backends/testLanBackend.test
1..7
not ok 1 A LAN channel service can be started
# Message: TypeError: local is undefined in /nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js (line 46)
# Stack:
#   error properties: Object({ matches: Function })
#   @/nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js:46:9
not ok 2 A LAN channel service can request and accept channels
# Message: TypeError: local is undefined in /nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js (line 54)
# Stack:
#   error properties: Object({ matches: Function })
#   @/nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js:54:25
not ok 3 A LAN channel service tracks active channels
# Message: TypeError: local is undefined in /nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js (line 79)
# Stack:
#   error properties: Object({ matches: Function })
#   @/nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js:79:9
not ok 4 A LAN channel service produces channels that can transfer packets
# Message: TypeError: localChannel is undefined in /nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js (line 94)
# Stack:
#   error properties: Object({ matches: Function })
#   @/nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js:94:13
not ok 5 A LAN channel service produces channels that can transfer payloads
# Message: Error: Invalid value 'undefined' for property channel in object initializer. in<EMAIL_ADDRESS>(line 504)
# Stack:
#   error properties: Object({ matches: Function })
#   _init@/nix/store/pcn1xm4r1fqh7446s72fykrwhwbhgq93-gnome-shell-gsconnect-43/share/gnome-shell/extensions/gsconnect@andyholmes.github.io/service/core.js:504:15
#   @/nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js:109:35
not ok 6 A LAN channel service can be stopped
# Message: TypeError: local is undefined in /nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js (line 129)
# Stack:
#   error properties: Object({ matches: Function })
#   @/nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js:129:9
not ok 7 A LAN channel service closes active channels when stopped
# Message: TypeError: local is undefined in /nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js (line 137)
# Stack:
#   error properties: Object({ matches: Function })
#   @/nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js:137:9
not ok - An error was thrown outside a test
# TLS support is not available in /nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js (line 17)
not ok - An error was thrown outside a test
# TypeError: local is undefined in /nix/store/sdl5nrklbl23lrmfzc0ccn89chzwlwf6-gnome-shell-gsconnect-43-installedTests/libexec/installed-tests/gsconnect/backends/testLanBackend.js (line 41)
FAIL: gsconnect/backends/testLanBackend.test (Child process exited with code 1)

before merging, please rebase onto staging, this is currently 12k+ rebuilds

Other distros / users are encountering issues with g-c-c as well:

https://bbs.archlinux.org/viewtopic.php?id=259598
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues?label_name[]=1.+Crash

What's a good way for me to help test this on my laptop? Should I wait for the rebease before switching my nixos channel to this branch? (I'm on nixos-unstable)

@srid You could run nixos-rebuild -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/gnome-3.38.tar.gz …. No need to wait for rebase unless you depend on something that is on latest nixos-unstable and not here.
After we do rebase, the branch will not be usable for a while since this PR carries a glib update and the whole user-space will need rebuild. Even now, webkitgtk has not yet been built by Hydra so expect two to six hours of builds, depending on the beefiness of your machine.

Went through hydra logs and the only sort of serious issue I encountered is vips not building: https://hydra.nixos.org/build/128429983/nixlog/3 looks like it might be caused by https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/359#note_922622
Also opened issue for the g-c-c crash https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1161

Also opened issue for the g-c-c crash https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1161

This may sound crazy, but would it help if we'd build g-c-c in a newScope where glib and possibly other libraries will get debug symbols?

I used the following patch, it is not even that much rebuilds. The issue is that the crash happens in some thread where the traceback is not very useful. I am also unable to reproduce the crash if I run the compiled g-c-c on Ubuntu (using https://github.com/guibou/nixGL), nor if I run it under valgrind on NixOS.
diff --git a/pkgs/desktops/gnome-3/apps/cheese/default.nix b/pkgs/desktops/gnome-3/apps/cheese/default.nix
index c4998cc451f..647522f4ae8 100644
--- a/pkgs/desktops/gnome-3/apps/cheese/default.nix
+++ b/pkgs/desktops/gnome-3/apps/cheese/default.nix
@@ -23,7 +23,7 @@
 , gtk-doc
 , adwaita-icon-theme
 , librsvg
-, totem
+# , totem
 , gdk-pixbuf
 , gnome3
 , gnome-desktop
@@ -101,9 +101,10 @@ stdenv.mkDerivation rec {
       --prefix GST_PRESET_PATH : "${gst_all_1.gst-plugins-good}/share/gstreamer-1.0/presets"
       # Thumbnailers
       --prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
-      --prefix XDG_DATA_DIRS : "${totem}/share"
     )
   '';
+      # --prefix XDG_DATA_DIRS : "${totem}/share"
+  separateDebugInfo = true;

   enableParallelBuilding = true;

diff --git a/pkgs/desktops/gnome-3/core/gnome-control-center/default.nix b/pkgs/desktops/gnome-3/core/gnome-control-center/default.nix
index 1300f7a7503..26985dd146e 100644
--- a/pkgs/desktops/gnome-3/core/gnome-control-center/default.nix
+++ b/pkgs/desktops/gnome-3/core/gnome-control-center/default.nix
@@ -152,14 +152,14 @@ stdenv.mkDerivation rec {

     # Fix double free when leaving user accounts panel.
     # https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/853
+    # (fetchpatch {
+    #   url = "https://gitlab.gnome.org/GNOME/gnome-control-center/commit/e80b4b5f58f448c5a3d38721f7bba32c413d46e7.patch";
+    #   sha256 = "GffsSU/uNS0Fg2lXbOuD/BrWBT4D2VKgWNGifG0FBUw=";
+    # })
     (fetchpatch {
-      url = "https://gitlab.gnome.org/GNOME/gnome-control-center/commit/e80b4b5f58f448c5a3d38721f7bba32c413d46e7.patch";
+      url = "https://gitlab.gnome.org/GNOME/gnome-control-center/commit/4a9dcfaee9c40ca9ffbf0b52663cd47a23fd9f40.patch";
       sha256 = "GffsSU/uNS0Fg2lXbOuD/BrWBT4D2VKgWNGifG0FBUw=";
     })
-    (fetchpatch {
-      url = "https://gitlab.gnome.org/GNOME/gnome-control-center/commit/64686cfee330849945f6ff4dcc43393eb1a6e59c.patch";
-      sha256 = "4VJU0q6qOtGzd/hmDncckInfEjCkC8+lXmDgxwc4VJU=";
-    })
   ];

   postPatch = ''
@@ -181,6 +181,12 @@ stdenv.mkDerivation rec {
     done
   '';

+  # mesonFlags = [
+  #   "-Dcheese=false"
+  # ];
+
+  separateDebugInfo = true;
+
   passthru = {
     updateScript = gnome3.updateScript {
       packageName = pname;
diff --git a/pkgs/desktops/gnome-3/misc/geary/default.nix b/pkgs/desktops/gnome-3/misc/geary/default.nix
index 6390b03efa3..546000227af 100644
--- a/pkgs/desktops/gnome-3/misc/geary/default.nix
+++ b/pkgs/desktops/gnome-3/misc/geary/default.nix
@@ -40,6 +40,7 @@
 , appstream-glib
 , libytnef
 , libhandy
+, libstemmer
 , gsound
 }:

@@ -47,15 +48,16 @@ stdenv.mkDerivation rec {
   pname = "geary";
   version = "3.38.1";

-  src = fetchurl {
-    url = "mirror://gnome/sources/${pname}/${stdenv.lib.versions.majorMinor version}/${pname}-${version}.tar.xz";
-    sha256 = "04p8fjkz4xp5afp0ld1m09pnv0zkcx51l7hf23amfrjkk0kj2bp7";
-  };
+  # src = fetchurl {
+  #   url = "mirror://gnome/sources/${pname}/${stdenv.lib.versions.majorMinor version}/${pname}-${version}.tar.xz";
+  #   sha256 = "04p8fjkz4xp5afp0ld1m09pnv0zkcx51l7hf23amfrjkk0kj2bp7";
+  # };
+  src = /home/jtojnar/Projects/geary;

-  patches = [
-    # Longer timeout for client test.
-    ./Bump-client-test-timeout-to-300s.patch
-  ];
+  # patches = [
+  #   # Longer timeout for client test.
+  #   ./Bump-client-test-timeout-to-300s.patch
+  # ];

   nativeBuildInputs = [
     appstream-glib
@@ -88,6 +90,7 @@ stdenv.mkDerivation rec {
     json-glib
     libgee
     libhandy
+    libstemmer
     libpeas
     libsecret
     libunwind
@@ -104,9 +107,9 @@ stdenv.mkDerivation rec {
     glibcLocales # required by Geary.ImapDb.DatabaseTest/utf8_case_insensitive_collation
   ];

-  mesonFlags = [
-    "-Dcontractor=true" # install the contractor file (Pantheon specific)
-  ];
+  # mesonFlags = [
+  #   "-Dcontractor=true" # install the contractor file (Pantheon specific)
+  # ];

   # NOTE: Remove `build-auxyaml_to_json.py` when no longer needed, see:
   # https://gitlab.gnome.org/GNOME/geary/commit/f7f72143e0f00ca5e0e6a798691805c53976ae31#0cc1139e3347f573ae1feee5b73dbc8a8a21fcfa
diff --git a/pkgs/development/libraries/clutter-gtk/default.nix b/pkgs/development/libraries/clutter-gtk/default.nix
index 973ae344dc9..d9a31e29b0c 100644
--- a/pkgs/development/libraries/clutter-gtk/default.nix
+++ b/pkgs/development/libraries/clutter-gtk/default.nix
@@ -26,6 +26,7 @@ stdenv.mkDerivation rec {
       packageName = pname;
     };
   };
+  separateDebugInfo = true;

   meta = {
     description = "Clutter-GTK";
diff --git a/pkgs/development/libraries/clutter/default.nix b/pkgs/development/libraries/clutter/default.nix
index 8a70a872b9e..036f6649e96 100644
--- a/pkgs/development/libraries/clutter/default.nix
+++ b/pkgs/development/libraries/clutter/default.nix
@@ -34,6 +34,8 @@ stdenv.mkDerivation rec {
     };
   };

+  separateDebugInfo = true;
+
   meta = {
     description = "Library for creating fast, dynamic graphical user interfaces";

diff --git a/pkgs/development/libraries/cogl/default.nix b/pkgs/development/libraries/cogl/default.nix
index f2a69e87d85..de4ab0c1024 100644
--- a/pkgs/development/libraries/cogl/default.nix
+++ b/pkgs/development/libraries/cogl/default.nix
@@ -64,6 +64,8 @@ in stdenv.mkDerivation rec {
     };
   };

+  separateDebugInfo = true;
+
   meta = with stdenv.lib; {
     description = "A small open source library for using 3D graphics hardware for rendering";
     maintainers = with maintainers; [ lovek323 ];

We should probably do separateDebugInfo wherever possible at some point

On a live system, the crashes seem to be happening with unknown pattern.

I was initially able to reproduce a crash after leaving the user accounts panel,
then I tried to run with env -u with bunch of env vars unset including LOCALE_ARCHIVE, it did not crash
then I tried running without removing the env vars again, it crashed
then I tried removing LOCALE_ARCHIVE again, it did not crash
then I tried without removing, it did not crash :confused:
then I tried again, made sure g-c-c is not running and still no crash :cat2:
then I tried in different terminal tab in case I accidentally contaminated the environment somehow, it crashed
but when I tried again with LOCALE_ARCHIVE set and then unset, I could not make it crash at all, not even in new terminal windows
I noticed that the backtrace was different, it mentioned pipewire#0  0x00007f61554f666f in on_remote_data () from /nix/store/c5s8bqaf6snq2a4r9zmyvs3vnz3l6al9-pipewire-0.3.7-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so
#1  0x00007f615564be5c in loop_iterate () from /nix/store/c5s8bqaf6snq2a4r9zmyvs3vnz3l6al9-pipewire-0.3.7-lib/lib/spa-0.2/support/libspa-support.so
#2  0x00007f61556bee96 in do_loop () from /nix/store/c5s8bqaf6snq2a4r9zmyvs3vnz3l6al9-pipewire-0.3.7-lib/lib/libpipewire-0.3.so.0
#3  0x00007f617ee0aead in start_thread (arg=<optimized out>) at pthread_create.c:477
#4  0x00007f617ed3bd2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

I could not make it crash even after killing piperwire

So it seems like a very weird heisenbug. I do not know, is the locale archive cached somewhere? Or was the LOCALE_ARCHIVE just a coincidence.

After upgrading Pipewire I can no longer reproduce the crash, I guess we can do a hopefully final rebase after someone double checks my changes.

Great work everyone!

Yep, this cycle had the a lot of people working to get 3.38 compared to the last few :+1:

I thought the g-c-c crash was a sort of blocker..

I could not reproduce the crash after pipewire update.


Add ability for raise_error to create expectations on error attributes

I could not find an easy way to to define an expectation for an error that has multiple attributes (like SystemExit.  Please let me know if I missed something.
This change adds a with_attributes chain to the raise_error matcher (like the existing with_message chain).
Internally, with_attributes uses the have_attributes matcher, so all functionality of that matcher is exposed with with_attributes.
Here is how it works:
expect { raise SystemExit.new(1, 'File not found') }.to(
  raise_error(SystemExit).with_attributes(message: 'File not found', status: 1)
)

or
expect { raise SystemExit.new(1, 'FILE NOT FOUND') }.to(
  raise_error(SystemExit).with_attributes(message: /not found/i, status: 1..255)
)

This change does not change any existing functionality.
I have followed all the directions and the checklist from https://github.com/rspec/rspec-expectations/blob/master/DEVELOPMENT.md

Thanks for taking a stab at implementing this yourself, @jcouball!  As it turns out, RSpec already supports what you're looking for, but with a slightly different syntax.
Since RSpec 3.0, we've supported composable matchers which allow you to pass a matcher as an argument to another matcher -- such as passing have_attributes (or it's noun-phrased alias, an_object_having_attributes) to raise_error:
expect {
  raise SystemExit.new(1, 'File not found')
}.to raise_error(an_object_having_attributes(message: 'File not found', status: 1))

This doesn't check the exception class like your example does, but that's easily rectified by passing a compound matcher expression:
expect {
  raise SystemExit.new(1, 'File not found')
}.to raise_error(an_instance_of(SystemExit).and
                 an_object_having_attributes(message: 'File not found', status: 1))

...or, since class is ultimately just an attribute as well, you can specify the class of the exception as another attribute:
expect {
  raise SystemExit.new(1, 'File not found')
}.to raise_error(an_object_having_attributes(message: 'File not found', status: 1, class: SystemExit))

Our composable matcher support is ultimately more flexible than what your PR adds here (your PR adds support for matching on attributes but the composable matchers allow you to match on anything), so I'm going to close this.
Thanks again!

Thank you, @myronmarston.  Learning this was worth the price of the work I did.  I appreciate you taking the time to give this feedback.
I notice that the failure message is lacking when a composable matcher is used.  The output does not take into account the composed matcher:
RSpec.describe 'expect SystemExit' do
  let(:actual_status) { 99 }
  it 'should be able to expect SystemExit' do
    expect {
      raise SystemExit.new(actual_status, 'File not found')
    }.to raise_error(an_instance_of(SystemExit).and an_object_having_attributes(message: 'File not found', status: 1))
  end
end

Outputs:
...
expected Exception with an instance of SystemExit and an object having attributes {:message => "File not found", :status => 1}, got #<SystemExit: File not found> with backtrace:
...

I would expect the got #<SystemExit: File not found> to include information about the composed matchers.  In this case, I'd expect it to say something like, got an instance of SystemExit with attributes {:message => "File not found", :status => 99} with backtrace: ...
Is this something that I could improve?  Do you know of an example where failure message includes actual values from the composable matchers?

@jcouball that's definitely something that can be improved -- see #759 and #995.


Add button role to New spans

This improves accessibility by adding button role to the +New buttons. This is important hint for browser extensions to find clickable elements. BTW the current DOM structure looks a little bit wired; input element inside label element, but styles rely on this so I'll leave it as it is.

Thank you.


Disallowing '-' in key names causes problems

We're building a chart to deploy a number of sub-charts together. Essentially opensearch and opensearch-dashboards. We've run into an issue.
To do this our values.yaml contains the keys opensearch and opensearch-dashboards to be able to provide values to the sub charts. This all works fine.
However, in our own chart that has these as subcharts, we have templates and we'd like to reference values provided to subcharts so we don't have to define values in multiple places. This fails because in our templates when we do {{ .Values.opensearch-dashboards.key }} it dies because it found a - in a key name.
I'm not sure why there's a restriction on key names not having - in them, its valid in yaml. However, if that remains then chart names should also disallow the '-' character. Or the restriction should be removed it seems.

Here is a thread on this subject and a bit of explanation from ChatGPT :)
https://github.com/helm/helm/issues/2192
In Helm, when you define values in a values.yaml file or through the command line, you might encounter issues accessing values that have keys with dashes (hyphens) in them. This is because Helm templates use Go's text/template package for templating, and the syntax for accessing map values directly in Go templates does not support keys with dashes without using a specific access pattern.
Here's a detailed explanation:
Dot Notation Limitation
In Go templates (and consequently in Helm), when you access a value using the dot notation, you're essentially navigating through the data structure. For example, {{ .Values.myValue }} accesses myValue under Values. However, if the key contains a dash (e.g., my-value), the template engine interprets the dash as a minus operator, leading to a syntax error or unexpected behavior.
Access Pattern for Dashed Keys
To access values with keys that contain dashes, you need to use the index method, which involves specifying the map (or object) and the key as a string. For example, if you have a value defined as:
Copy code
my-values:
  key-with-dash: "example"

You can access it in a Helm template with:
```yaml
{{ index .Values "my-values" "key-with-dash" }}

This approach tells the template engine to look up the key "key-with-dash" within the map .Values["my-values"], effectively bypassing the limitation with the dot notation.
Best Practices
While you can use the index method to access keys with dashes, it's often recommended to avoid such keys when possible. Using camelCase, snake_case, or other naming conventions without special characters can make your templates cleaner and more straightforward to work with.
This explanation should help you understand the limitations regarding accessing values with dashes in Helm and how to work around them using the index method.

Hello,
Thanks for the thorough explanation. This does help clear up the issue. Though it does make it a bit tricky when the '-' is allowed in chart names. I would think that it would be good but probably too late to disallow the - in chart names.
That being said, for anyone else running into the issue where you require a sub chart with a '-' in the name. We were able to work around the issue by aliasing the sub-chart to a name without a subchart. Thus allowing us to provide values to the subchart directly and use those values in our own templates without resorting to using index to access them which although it works isn't how you tend to see chart templates and could throw someone off on what is happening and why.


[Feature]TOP/Hwyla integration

Describe your feature idea
Show informations like connected computers with hwyla/TOP
Additional context

I'm going to close this here as I have no idea what to display with TOP / Hwyla.

I'm going to close this here as I have no idea what to display with TOP / Hwyla.


private dns zone will omit tags when the key containing ":"

we are using api-version "2018-09-01". when creating a private dns zone, the tags will be omited when the key contains :. However,  in other azure service, there is no such behaviour
https://github.com/terraform-providers/terraform-provider-azurerm/issues/6129

any news?

Is it planned to be fixed?
Following resources are having the issue for us:
azurerm_dns_a_record
azurerm_dns_ns_record
azurerm_private_dns_zone
azurerm_private_dns_zone_virtual_network_link

Hello, there is any news about this? Our tagging policy is based on ":"


Add --repos-posix option to force POSIX paths

This is a feature request. I'd be happy to open a PR after getting an OK.
In some cases, on Windows, users might have to work with POSIX paths (i.e. provide POSIX paths and expect POSIX paths). However, providing a POSIX path (as a base path) on Windows results in paths with a POSIX/Windows mix. For example:
$ vcs diff src/ -s --repos
src/ament\ament_cmake (git)
...

This is annoying to have to deal with if we intend to pipe the resulting paths into something else. For a concrete example, see https://github.com/ros-tooling/action-ros-ci/issues/578.
Therefore I am proposing to add a --repos-posix option (as a common argument) that would be just like --repos but converting repo paths to POSIX paths.
Something like:
diff --git a/vcstool/executor.py b/vcstool/executor.py
index 9b0b301..ea36a1f 100644
--- a/vcstool/executor.py
+++ b/vcstool/executor.py
@@ -1,4 +1,5 @@
 import logging
+import pathlib
 import os
 from queue import Empty, Queue
 import sys
@@ -9,12 +10,13 @@ logger = logging.getLogger(__name__)
 logging.basicConfig()

-def output_repositories(clients):
+def output_repositories(clients, force_posix=False):
     from vcstool.streams import stdout
     ordered_clients = {client.path: client for client in clients}
     for k in sorted(ordered_clients.keys()):
         client = ordered_clients[k]
-        print('%s (%s)' % (k, client.__class__.type), file=stdout)
+        path = pathlib.Path(k).as_posix() if force_posix else k
+        print('%s (%s)' % (path, client.__class__.type), file=stdout)

 def generate_jobs(clients, command):

A more "global" alternative could be a --posix option that would affect paths printed by both output_repositories() (for --repos) and output_result()/output_results().

I get the problem with mixed-style paths. Instead of adding an option to control the behavior I would prefer an approach which determines what to do based on the input / environment. No new options means nothing to document / teach to users :wink: Any pull request towards supporting this would be welcome.

Instead of adding an option to control the behavior I would prefer an approach which determines what to do based on the input / environment. No new options means nothing to document / teach to users wink

Fair point! I'll look into it.


Disabled the automatic verification

When the user verificate automaticate remove the verificated role

Yes thats the way to disable it when you disable if any stupid tries to veryficate when they are alredy verificated this check unverificates itself and sends a fancy message.

@danirod

Ok


Drop rust-crypto support

This PR removes rust-crypto and migrates to aes and cbc. The change is motivated by the related work in binwalk, which is needed to add CI support there, due to rust-crypto seems to be outdated and unmaintained state.
The feature compiles without issues, and the logic seems sound to me. However, I haven’t thoroughly tested the functionality yet, so I’d greatly appreciate feedback or further testing from anyone who can help.
Looking forward to your comments!

Without these changes the result of the release.yml ends up link this:
https://github.com/andrewgigena/binwalk/actions/runs/12496255076


Fake wget

Motivation for this change
I found myself needing a mock wget executable for a new package I'm working on to get its configure script working, and I discovered that several ad-hoc solutions for this already exist in the preConfigure phases of a few derivations in nixpkgs.
Having a package for this removes a bit of duplicated code, but I think more significantly it makes life a little easier for authors of future packages that may find this useful (as I do in the package I'm currently working on), and provides a place to document the technique.
Future work
There is a slightly more complex variant of this in xen which, instead of just failing, implements wget in a mock way that copies files from a local cache. It may be useful to expand this at some point to include a behavior along those lines.
Things done

[ ] Tested using sandboxing
(nix.useChroot on NixOS,
or option build-use-chroot in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

The behaviour- of wgets in textadept and handbrake is different -- one of them always succeeds and another one always fails.

:-1: on this. It seems to ad hoc to be generally useful. Probably in most cases where you need a mock wget, you would need it to return some fake data as well.

@rasendubi I think they both ought to fail, though. This is illustrative of why I think we'd be better off with a shared utility rather than ad-hoc solutions.


allow the jakarta version of @Generated instead of the javax one.

all javax modules are being replaced with jakarta, this includes @javax.annotation.Generated. This is replaced by @jakarta.annotation.Generated, allow users to choose which annotation they want on the generated classes.
(I'm also creating a PR for this.)

+1

@joel-costigliola , any reason why the jakarta support doesn't get merged?

just lack of time, the generator is currently in a limbo state because of that ...

Team decision: We will start the development of the next major version with Java 17 as a baseline to better aid records and jakarta support.

FWIW, in JDK 21, javax.annotation.Generated is gone so the generated assertions do not compile.
Manually replacing with @javax.annotation.processing.Generated works, of course, but that's not really what we're going for, is it? 😅

@scordio Any way we can help? We keep writing assertion classes and would rather spend the time more fruitfully here. 😅

Hi @reitzig, I appreciate the offer! 🙂 nothing special where you could help, I'm afraid: I'm upgrading dependencies and aligning the parent POM to the latest version, which already brings a few challenges due to the custom JUnit 4 rules... once this is over, it should be possible to speed up the other topics.
I'll keep you posted.

Additional team decision: we will stick to @javax.annotation.processing.Generated.

I was able to force v3.0.0-M3 on  v2.2.0 of the Maven plugin and can confirm: this is fixed. Thanks!

Very cool, thanks for checking!


Add ability to assign and remove a server capability for multiple servers at a time

I'm submitting a ...

new feature / enhancement request

Traffic Control components affected ...

Traffic Ops
Traffic Portal

Current behavior:
There is no way to apply a server capability to more than one server at a time (in the UI or the API). Using the API is a lot faster than using the UI to mass-assign capabilities, but it would be much easier if both the API and UI supported the ability to assign a server capability to more than one server at a time.
New behavior:
Add the ability to mass-assign (and mass-remove) a server capability to more than one server at a time. This should probably be a new TO API route. When in Traffic Portal, going to Configure > Server Capabilities > select server capability  > View servers should be similar to how DS-server assignments are handled in TP (i.e. Services > Delivery Services > select delivery service > More > Manage servers > More > Assign servers. The way you can type in the search bar to filter across all fields would be similarly useful in the case of mass-applying server capabilities.
Minimal reproduction of the problem with instructions:
Configure > Servers > select server > More > manage capabilities > +

This was earlier linked to https://github.com/apache/trafficcontrol/pull/6996 and https://github.com/apache/trafficcontrol/pull/7020. However, those PRs are for adding the ability to add/remove multiple capabilities to a single server. What this issue talks about is the ability to add/ remove a capability to multiple servers at the same time.

@srijeet0406, You are right. I created a new feature request (#7078) for #6996 and #7020.


Support for subflows

An activity to support the invocation of flows. One thing to consider is the input & output of the flow is dynamic, hence the UI will need to introspect the flow input/output to construct the UI elements for mapping since it would not be metadata driven, as is the case with traditional activities.

resolved in TIBCOSoftware/flogo-lib#127


Browse datasets by topics – Increase visibility of "Back to Datasets" Button

Back to Dataset-Button should be more prominent

Are you sure about this ? I find it weird to have two primary buttons there, maybe the background-color of the back button could be a bit muted ?

Yes your right, we have to introduce secondary buttons. We didn't have them so far in the design components

Change button to grey #757575 according to CI Guidelines.


Ansible 2.8 compatibility

TASK [TypistTech.trellis-newrelic-php : Template New Relic .ini file out to mods-available] ***
task path: /xxx/trellis/vendor/roles/TypistTech.trellis-newrelic-php/tasks/ini.yml:19
System info:
  Ansible 2.8.7; Darwin
  Trellis 1.3.0: December 7th, 2019
---------------------------------------------------
AnsibleUndefinedVariable: 'dict object' has no attribute 'iteritems'
fatal: [<IP_ADDRESS>]: FAILED! => {
    "changed": false
}

Maybe the issue is python3

it is python3

see https://stackoverflow.com/a/13998534


Tiny Docker Image

Reduce the Docker image size from 1.5GB to 38.03.MB.
Uses alpine:3.5 as a base container.

This is rather nice; and it looks like it just builds on Quay. Right now we mount in /data for datafiles and config; this can clearly still do that, but overall I'll request a matching change for the docs on how to use this Docker image. As for the image itself, it looks good :)

Should I list myself as the maintainer?

If you intend to maintain it, sure :) My only ask is that you file a bug if you decide not to do so anymore.

Yeah man, I don't mind at all. Just wanted to verify.

I've updated the container documentation as per your request @barakmich.
Also, I split up the container into a general use container (~40MB) and the quickstart container (~600MB). The quickstart container has the 30kmovidata preloaded.
To get started with Cayley, all you need to do is run:
docker run -it --rm -p 64210:64210 sugarush/cayley-quickstart

New CLI is merged, so we can revive this one. @psev are you still interested in maintaining this image, or should I rewrite it?

Closing in favor of https://github.com/cayleygraph/cayley/pull/637


[SELF-HOSTED] Error migrations when upgrading from 1.2.0 into 1.2.1

Describe the problem
INSERT INTO "migrations"("timestamp", "name") VALUES ($1, $2)',
parameters: [<PHONE_NUMBER>153, 'Configs1727747249153' ],
driverError: error: duplicated key violating constraint key « PK_8c82d7f526340ab734260ea46be » id 36 already exists (migration name: ActivationEnabled1722529827161
'ALTER TABLE "activations" ADD "enabled_at" TIMESTAMP WITH TIME ZONE',
driverError: error: column « enabled_at »from relation « activations » already exists
Additional information

Grist version: 1.2.0
Grist instance URL: self hosted
SSO solution used and its version (if relevant):
S3 storage solution and its version (if relevant):
Docker version (if relevant):
NodeJS version (if relevant):
Redis version (if relevant):
PostgreSQL version (if relevant):

Do you think you could read out the migrations table in your home DB? On a default installation, this would be a persisted file called home.sqlite3. You could read it out with a tool such as sqlite3:
paulfitz@entwash:/tmp/example$ sqlite3 home.sqlite3 "select * from migrations"
1|1536634251710|Initial1536634251710
2|1539031763952|Login1539031763952
3|1549313797109|PinDocs1549313797109
...
30|1678737195050|ForkIndexes1678737195050
31|1682636695021|ActivationPrefs1682636695021
32|1685343047786|AssistantLimit1685343047786
33|1701557445716|Shares1701557445716
34|1711557445716|Billing1711557445716
35|1713186031023|UserLastConnection1713186031023
36|1722529827161|ActivationEnabled1722529827161
37|1727747249153|Configs1727747249153
38|1729754662550|LoginsEmailsIndex1729754662550

I just tried a full replication, running a container based on the Grist docker image tagged 1.2.0, and then switching to 1.2.1. The migrations table seemed to update in an orderly fashion, with two more rows getting added:
paulfitz@entwash:/tmp/test$ diff /tmp/v1.2.0 /tmp/v1.2.1
36a37,38
> 37|1727747249153|Configs1727747249153
> 38|1729754662550|LoginsEmailsIndex1729754662550

The id 36 already exists (migration name: ActivationEnabled1722529827161) message in your output troubles me, it reads like for some reason the ActivationEnabled migration is being run again.

home.sqlite3 is replaced by PostgreSQL database. The migrations table have already a line with id 36 and name ActivationEnabled1722529827161. So it was already enabled. I had to delete this record and remove the enable_at column in activations table before pull grist 1.2.1 docker image.

Hmm. Not sure why it would attempt to run ActivationEnabled1722529827161 again if the migrations log clearly showed it had already run. Haven't seen that happen before. Will leave this issue open in case others have a similar problem and this encourages them to report it.


structured comment name too long tot_nitro_content_meth

Current term details
The length of structured comment names is supposed to be limited to 20char.
Term name - total nitrogen content method
Term ID - [if known] MIXS:0000338
Structured comment name - tot_nitro_content_meth
Definition - Reference or method used in determining the total nitrogen
Package(s) - Soil

Suggested update(s)
Structured comment name - tot_nitro_cont_meth

Additional context
there is a related term "total nitrogen content" which has the structured comment name "tot_nitro_content", it might seem reasonable to shorten "content" to "cont" in that structured comment name also?

this issue didn't get pulled into the mixv6 project so got missed, it needs addressing in v7

Has this issue been fixed yet?

yes it appears to have been fixed by shortening content to cont  "tot_nitro_cont_meth" see https://genomicsstandardsconsortium.github.io/mixs/0000338/

Discussion at TWG today.
Is this still a requirement for INSDC? It was required because of flat files, which are no longer a thing. Well, they still are, but they working to decouple the metadata
Assigned to @Woolly-at-EBI to investigate and respond in this thread.