Re: git repositories for cygwin packaging - please test
On 8/23/2020 5:01 PM, Jon Turney wrote: On 27/05/2020 23:27, Jon Turney wrote: On 04/08/2019 21:08, Jon Turney wrote: To remedy this lack, using the same ssh key you use for sftp package upload, package maintainers can now also push to git repositories, like so: Package maintainers may have noticed that the output from pushing to these git repositories now includes a line like: "remote: scallywag: build nnn queued" This is a *prototype* of a system to automatically build the packages, where the results appear (some time later) at [1] (URL subject to change) [1] https://cygwin.com/cgi-bin2/jobs.cgi Currently, many packages will fail to build correctly due to: I now have built an (opt-in) system which fetches the packages built by this into your upload area and triggers calm to process them, which I'm looking for a volunteer to test. I'd be willing to give it a try the next time I have something to upload. I'm actually almost ready for a test release of doxygen. Unfortunately, the 32-bit scallywag build of doxygen consistently fails with an ld crash, even though I can build it locally. So I can't use it for this test. How does the opt-in process work? Is it per package? Is it easy to opt-out again temporarily? Currently, these packages are built using 'cygport all-test', and so will always be marked test: One possible issue is that a git commit doesn't have to change VERSION or RELEASE, so this can build packages which are then immediately rejected by calm, as that PVR already exists. Does calm delete them after rejecting them or does the maintainer have to do that? I'm not sure if that's a real problem, or what the workflow should look like in regards to that. I don't see it as a real problem, as long as all it means is that I get an email from calm. But if I also have to manually delete the packages from my upload area, that could be annoying. Ken
Re: [PATCH] doc: Various fixes to makedocbook for python3.8
On 8/25/2020 11:50 AM, Jon Turney wrote: On 24/08/2020 13:58, Ken Brown via Cygwin-apps wrote: On 8/24/2020 6:31 AM, Marco Atzeri via Cygwin-apps wrote: Any preference ? For the last option I will use alternatives It should default to python3. Fedora performs this via an extra package python-unversioned-command, containing just a symlink /usr/bin/python -> ./python3 as well as a man page symlink /usr/share/man/man1/python.1.gz -> ./python3.1.gz. We could just do the same, no? Seems like a good idea. I think it's time to make python point to python3. I suggest setting /usr/bin/python -> python3 But we'd also need to audit that all packages that containing python scripts either: - use a shebang which names python and work with python3 - use a shebang which explicitly names python2 or python3 We could start with a HEADSUP to maintainers asking them to check their python scripts whose shebangs name python. For those scripts whose maintainers don't respond, we could simply change the scripts to name python2. Do you have any idea roughly how many scripts we're talking about? Ken
Re: New SSH key for upload access
On Tue, Aug 25, 2020 at 7:36 PM Marco Atzeri via Cygwin-apps wrote: > On 25.08.2020 17:34, Jon Turney wrote: > > On 25/08/2020 15:14, Michael Wild via Cygwin-apps wrote: > >> Name: Michael Wild > >> Packages: tmux, python-bcrypt, python-nacl, python-paramiko, ssh-pageant > > >> --- END SSH2 PUBLIC KEY --- > > > > This doesn't look like a key export made with 'ssh-keygen -e', so I had > > to import it manually, hopefully correctly. > > > > Done. > > Michael, > I recently updated python-bcrypt, > and I built but not uploaded yet python-nacl > > are you planning to upload python-paramiko ? > > Regards > Marco > Hi Marco Sorry, I was AWOL for some time, work was just overwhelming and Cygwin was basically useless with the corporate spyware... Now I changed employer and I intend picking things up again. Yes, I intend to update paramiko, and its dependencies, also for Python 3.7 and 3.8. Kind regards Michael
Re: [ITP] python-getdevinfo
Okay, I have updated the packages (same location:
https://www.hamishmb.com/files/cygwin-temp/). It should now handle fork
errors better.
If it fails again, please post the full output from the test command so
I can see what version(s) of Python the tests are failing on. It might
be useful for someone else to have a go as well - would be good to know
multiple people can reproduce this issue as I have still had no luck
doing that.
Thanks for your patience,
Hamish
On 21/08/2020 16:33, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 20/08/2020 07:01, Marco Atzeri via Cygwin-apps wrote:
>> On 19.08.2020 13:22, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>>> On 19/08/2020 06:53, Marco Atzeri via Cygwin-apps wrote:
something looks wrong on test
==
ERROR: test_get_info (tests.getdevinfo_tests_cygwin.TestGetInfo)
Test that the information can be collected on this system without error
--
Traceback (most recent call last):
File
"/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/src/getdevinfo-1.1.0/getdevinfo/tests/getdevinfo_tests_cygwin.py",
line 218, in test_get_info
cygwin.get_info()
File
"/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py",
line 101, in get_info
get_device_info(disk)
File
"/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py",
line 135, in get_device_info
cmd = subprocess.run([SMARTCTL, "-i", host_disk, "-j"],
stdout=subprocess.PIPE,
File "/usr/lib/python3.8/subprocess.py", line 489, in run
with Popen(*popenargs, **kwargs) as process:
File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.8/subprocess.py", line 1637, in
_execute_child
self.pid = _posixsubprocess.fork_exec(
BlockingIOError: [Errno 11] Resource temporarily unavailable
--
Ran 23 tests in 0.679s
FAILED (errors=1)
NOTE: These tests won't work correctly without administrator
privileges.
$ id
uid=197609(Marco) gid=544(Administratoren)
groups=544(Administratoren),197121(Kein)
>>>
>>> Unfortunately I have not been able to reproduce this issue on my end
>>> with either 32-bit or 64-bit Cygwin. What happens when you run
>>> "/usr/sbin/smartctl.exe -i /dev/sda -j" (assuming /dev/sda is a disk
>>> that Cygwin sees)? Note that the output may include the drive serial
>>> number - make sure to blank it out if you post the output here.
>>>
>>> If this is on 32-bit Cygwin, this looks like the good old fork bug to
>>> me, seeing as you're getting "11 Resource temporarily unavailable" when
>>> attempting to fork. I can't remember what worked to fix that for me the
>>> last time I had it, might have been antivirus software exceptions. I
>>> would say that maybe some packages need updating, but given you've been
>>> releasing packages in the last few days, I highly doubt your Cygwin
>>> install is out of date.
>>>
>>> If the smartctl command works, could you try running the tests again
>>> please?
>>>
>>> Hamish
>>>
>> /usr/sbin/smartctl.exe -i /dev/sda -j
>>
>> {
>> "json_format_version": [
>> 1,
>> 0
>> ],
>> "smartctl": {
>> "version": [
>> 7,
>> 1
>> ],
>> "svn_revision": "5022",
>> "platform_info": "x86_64-pc-cygwin-w10-b19041",
>> "build_info": "(cygwin-7.1-1)",
>> "argv": [
>> "smartctl",
>> "-i",
>> "/dev/sda",
>> "-j"
>> ],
>> "exit_status": 0
>> },
>> "device": {
>> "name": "/dev/sda",
>> "info_name": "/dev/sda",
>> "type": "ata",
>> "protocol": "ATA"
>> },
>> "model_family": "Seagate Mobile HDD",
>> "model_name": "ST1000LM035-1RK172",
>> "serial_number": "WL10S143",
>> "wwn": {
>> "naa": 5,
>> "oui": 3152,
>> "id": 2907615223
>> },
>> "firmware_version": "RSM7",
>> "user_capacity": {
>> "blocks": 1953525168,
>> "bytes": 1000204886016
>> },
>> "logical_block_size": 512,
>> "physical_block_size": 4096,
>> "rotation_rate": 5400,
>> "form_factor": {
>> "ata_value": 3,
>> "name": "2.5 inches"
>> },
>> "in_smartctl_database": true,
>> "ata_version": {
>> "string": "ACS-3 T13/2161-D revision 3b",
>> "major_value": 2032,
>> "minor_value": 31
>> },
>> "sata_version": {
>> "string": "SATA 3.1",
>> "value": 127
>> },
>> "interface_speed": {
>> "max": {
>> "sata_value": 14,
>> "string": "6.0 Gb/s",
>> "units_per_second": 60,
>> "bits_per_unit": 1
>> },
>>
