User Details
- User Since
- Jul 21 2017, 8:29 AM (333 w, 14 h)
- Availability
- Available
- LDAP User
- Hawkeye7
- MediaWiki User
- Hawkeye7 [ Global Accounts ]
Today
Yesterday
When I try to use the admin console (https://toolsadmin.wikimedia.org/tools/id/milhistbot/repos/create) to create a new repository it says:
No GitLab accounts found for tool maintainers.
Tue, Nov 28
As you say, the biggest obstacle is that there is no dotnet buildpack available.
Mon, Nov 27
Using a dotnet buildpack is fairly simple. eg.:
$ pack build liftwing --buildpack paketo-buildpacks/dotnet-core --builder paketobuildpacks/builder:base --env BP_DOTNET_PROJECT_PATH=./Liftwing
$ docker run liftwing "Hanford Engineer Works" 2>/dev/nul
Setting ASPNETCORE_URLS=http://0.0.0.0:8080
FA
Wed, Nov 22
@komla Sorry, I was away and did not see your comment until now. A build pack will not work for me they way you are trying. I have multiple C# projects in the one git repository. It was never intended to be built in this manner. It will simply give you an error telling you that it does not know what project to build, and there is no workaround for this.
Sun, Nov 19
Tool has been migrated to using the kubernetes containers. However the task to create a proper dotnet build environment is still outstanding
Dec 8 2022
Best practice for containers is for each app to have its own. It is regarded as an error to use them like virtual machines. See https://cloud.google.com/architecture/best-practices-for-building-containers
Dec 7 2022
An alternative would be to install the latest version of dotnet
Oct 20 2022
Confirmed that my executables run on the docker container.
Oct 19 2022
Well done.
Oct 18 2022
The documentation says: "The package ca-certificates-mono should be installed to get SSL certificates for HTTPS connections. Install this package if you run into trouble making HTTPS connections."
I have edited the request. I created it as a feature, not a bug report.
Oct 17 2022
We use Rocky 9 here. All software here is patched an kept up to date due to the threat from foreign-government-sponsored hackers and ransomware attacks.
You're quite right; MIME::Lite is not available on the Grid. We never needed it there because we had sendmail and later exim.
I do have a workaround: I could use Net::SMTP. This is a low-level module, but it is included with a standard Perl 6.32 install.I have tested this with the tf-perl532 image. Using it would require me to write an new email wrapper for my bots to use. Currently my wrapper supports sendmail, exim and MIME::Lite.
Oct 16 2022
Perl has a mail module, MIME::Lite, but while it is available on the Grid, it has not been provided in the Kubernetes image.
I've created a new feature suggestion T320904.
MIME::Lite is not installed on perl532-tf so no ability to send mail from that container
Garbage. The change to the documentation does not explain how to send an email if there is no sendmail, no exim, no MIME::Lite.
Not working. exim does not seem to work inside kubernetes containers. So I am not being informed if there is a problem. May have to revert.
Oct 14 2022
Having the same problem as Ghuron
No good. Does not have msbuild.
Oct 9 2022
All my Perl jobs are now migrated to Kubernetes. That leaves only the four C# ones.
How do you create an interactive shell on this container?
Oct 8 2022
Running a web service would require a an external web server. It is not part of mono.
Oct 7 2022
I guess this means that this can be closed, as I have a workaround of using the Ross Mallett account.
Does the move to gitlab mean that we can use ssh again instead of https?
It clearly shows Ross Mallett and Hawkeye7 are the same identity.
I can apparently log in as Ross Mallett. No idea why that account was used.
I am there as Ross Mallett, but that is not my gitlab account, Hawkeye7 is.
Yes, it has moved to Gitlab so now I cannot upload to it. :(
I am not a member of my own project :(
I've updated four of the Perl jobs to run with the tf-perl532 image. If they run okay, I will convert the other jobs. But the C# jobs cannot be converted until a C# image is made available.
No access to my own project.
Not working. And my profile has a bum email with a spelling error in it. Cannot correct it. Cannot do a push with gitlab. Please migrate back.
The tool contains scripts written in Perl; these should be okay for now, but I switched away from them when WMF started talking about OpenAuth, which the Perl MediaWiki::Bot does not support. These I can migrate right now.
Something has gone wrong. My attempt to do a git push results in fatal: unable to access 'http://phabricator.wikimedia.org/source/tool-milhistbot.git/': The requested URL returned error: 403.
This is not currently possible. There is an outstanding request T311466 for the required docker image.
Aug 14 2022
Aug 7 2022
Aug 3 2022
Jun 29 2022
Closed but not resolved
Yes, I could do that but it is not my preferred option because:
(1) The module is currently available on the grid
(2) It defeats the purpose of having a perl container
My bots uses one Perl module that is not installed:
File::Slurp
Jun 28 2022
msbuild is packaged with the latest release, so if you install the latest stable version (6.12.0)
(which you can get from https://www.mono-project.com/download/stable/#download-lin-debian)
it will be there!
Jun 27 2022
Is there any way to test it?
It is there on the job grid and is used by my Perl bots.
A Perl container would need to have MediaWiki::Bot
Damn. msbuild is not installed on tools-sgebastion-10. So my Bots cannot be maintained.
Jun 26 2022
Jun 7 2022
Okay. I have figured this out. Can close now.
It looks like tools-sgebastion-10 is an obsolete server that needs to be decommissioned. How do you force it to login to a working server?
Jun 6 2022
rmallett@tools-sgebastion-07:~$ mono --version
Mono JIT compiler version 5.12.0.226 (tarball Thu May 3 09:49:46 UTC 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: supported, not enabled.
GC: sgen (concurrent by default)
rmallett@tools-sgebastion-07:~$ which msbuild
/usr/bin/msbuild
rmallett@tools-sgebastion-07:~$
My Bots are written with a C# API. Still working so long as mono is present, but changing them will be difficult. Can rtebuild on the Linux machine here, but no assurance that iut is running the same version of mono.
No. xbuild does not contain the libraries that I need. Cannot build with xbuild. Need to have mono restored.
rmallett@tools-sgebastion-10:~/tool-milhistbot/mono$ xbuild AutoStub.csproj
rmallett@tools-sgebastion-10:~$ which mono
/usr/bin/mono
rmallett@tools-sgebastion-10:~$ which msbuild
rmallett@tools-sgebastion-10:~$ uname
Linux
rmallett@tools-sgebastion-10:~$ uname -a
Linux tools-sgebastion-10 4.19.0-20-cloud-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux
rmallett@tools-sgebastion-10:~$ hostname
tools-sgebastion-10
rmallett@tools-sgebastion-10:~$ dnsdomainname
tools.eqiad1.wikimedia.cloud
rmallett@tools-sgebastion-10:~$
mono is in /usr/bin/mono, and msbuild should be there too. Except that it is missing again. What is going on?
Toolforge. tools-sgebastion-10.
Jun 2 2022
Hmmm. It is back now. Possibly a upgrade?
Dec 1 2021
Okay, I have over to using https.
Nov 26 2021
It seems that I do have a gitlab.wikimedia.org account, so the project could be moved there, although it says that it is still under construction.
HTTPS is for web pages. I am dealing with software, not web pages.
Nov 25 2021
I'm not sure I understand what is proposed here... If Phabricator is not the authoritative place to host repositories, then what is? How is it proposed that I maintain my sources without git?
Nov 3 2020
May 11 2019
Apr 28 2019
Apr 22 2019
Apr 11 2019
Apr 4 2019
Thanks for your assistance. Much appreciated. I tried the ssh initially, but it did not work. Now that the ssh key and VCS password are set, it works!
I tried adding an ssh key here on Phabricator with settings -> SSH Public Keys.
Apr 3 2019
It is tool-milhistbot.
Apr 2 2019
Repo created okay.
Mar 26 2019
I don't understand any of this, but it still isn't working.
Oct 14 2018
Not-great behaviour is not bad behaviour, and the risk involved in changes like this is high. Such changes need to be very carefully considered and tested. The risk to reward ratio is too high.
If there was no change to the MediaWiki software that caused a problem then there is no need for this change.
Oct 13 2018
Can we please revert the offending change?
Jun 12 2018
I have tried the workaround and am still having this problem. My Phabricator account is linked to both my LDAP account and my Mediawiki account but I am still getting this error.