[09:00:17] !log tools.stewardbots Restarted SULWatcher bots. [09:00:19] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stewardbots/SAL [09:01:57] !log tools.stewardbots Restarted StewardBot. [09:01:58] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stewardbots/SAL [11:08:47] !log Deployment-prep maurelio@deployment-deploy01 foreachwiki extensions/AbuseFilter/maintenance/normalizeThrottleParameters.php --dry-run | T209565 [11:08:48] hauskatze: Unknown project "Deployment-prep" [11:08:48] T209565: Dry run for normalizeThrottleParameters.php - https://phabricator.wikimedia.org/T209565 [21:05:50] Hi Dvorapa, zhuyifei1999_ was looking for you and wanted me to tell you this when you are here: Am I understanding it correctly that you want to hardlink every single file in pywikibot repo? I don't see how that gives less of a burden than syncing symlinks. And yes, /proc/sys/fs/protected_hardlinks has a default value of 1. For reasoning see kernel [21:05:50] Documentation/sysctl/fs.txt [21:06:09] Dvorapa: um hi [21:06:14] zhuyifei1999_: Yes, I want to create hardlink for every single file [21:06:22] (hi :) ) [21:06:36] so what is the benefit of that instead of symlinks for ever file? [21:06:39] *every [21:06:57] Because I want to replace some files with mine (e.g. cosmetic_changes) [21:07:23] so keep the non-replaced versions symlinks? [21:07:36] It would be possibly better to write some background for user_cosmetic.py, but I don't have time currently [21:08:55] no, to make replaced versions work, you need hardlinks at least for pwb.py (and perhaps some other files/scripts that use cosmetic_changes) [21:09:29] fix that in pywikibot? [21:09:46] it should not care whether a target script is a symlink or a regular file [21:10:59] When using symlinks, it just uses files in /shared/pywikibot/core and my cosmetic_changes are ignored [21:11:48] why? [21:11:55] I mean, that should not happen [21:12:09] This is a standard behavior or not? [21:12:25] no [21:12:33] Maybe it would not work even with hardlinks? [21:12:44] Then this is a bug in Pwb? [21:12:46] symlink should behave as if it is transparent [21:12:56] hardlinks is just regular file [21:13:04] i.e. an inode having two names [21:14:13] So when symlinking all Pywikibot files and replacing cc.py, template.py ... it should use my versions? [21:14:31] not depending whether it is symlink/hardlink? [21:15:03] that should be the ideal behavior [21:16:00] Yes, should be, but it is not working currently [21:16:47] let me test [21:17:14] Try it :) (I've tried it already with no success) [21:18:12] Anyway adding user_cosmetic.py and adding my template.py changes to Pywikibot core and other changes in my repo would be of course the better option [21:22:02] hmm, python indeed tries to readlink the symlink [21:30:56] Dvorapa: try having just pwb.py as 'regular file' [21:32:23] some weird inconsistency in python: [21:32:26] https://www.irccloud.com/pastebin/803pLDOH/ [21:33:21] the real path of the 'entry point' affects sys.path [21:33:27] I see, this could work [21:33:29] and argv[0] [21:33:47] but other imports do not get resolved [21:41:02] mmm, using python script.py and avoiding python pwb.py script what this approach reminds me? :D typical Toolforge issues with Pywikibot years old? [21:41:58] But this is not Toolforge bug fortunately [22:03:19] !log tools.lexeme-forms deployed b0f39bb09b (API to match lexemes to templates) [22:03:20] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [22:36:06] I will let you know when I see Dvorapa and I will deliver that message to them [22:36:06] @notify Dvorapa I'd say it's a python bug