Hi,
Products Available:
JP54, D2 GAS OIL, D6 VIRGIN FUEL OIL LNG/LPG, EN 590, MAZUT M100 GOST–10585,
JETFUEL A1 91/91, RUSSIAN PETROLEUM COKE.
Delivery:
Vessel take over (VTO), Tank Take Over (TTO), Vessel to Vessel (VTV), Vessel to
Tank (VTO), FOB/Dip & Pay, CIF
Inspection:
SGS test
On Mon, 22 Jul 2019 23:20:42, Yaakov Selkowitz wrote:
The following packages have been uploaded to the Cygwin distribution:
* curl-7.65.3-1
* libcurl4-7.65.3-1
* libcurl-devel-7.65.3-1
* libcurl-doc-7.65.3-1
It seems the previously reported issue remains:
$ curl -V
curl 7.65.3
On Jul 23 19:07, Jon Turney wrote:
> On 23/07/2019 17:54, Corinna Vinschen wrote:
> > Hi Ken,
> >
> > On Jul 23 16:12, Ken Brown wrote:
> > > According to POSIX, "The getpgrp() function shall always be successful
> > > and no return value is reserved to indicate an error." Cygwin's
> > >
On 23/07/2019 17:54, Corinna Vinschen wrote:
Hi Ken,
On Jul 23 16:12, Ken Brown wrote:
According to POSIX, "The getpgrp() function shall always be successful
and no return value is reserved to indicate an error." Cygwin's
getpgrp() is defined in terms of getpgid(), which is allowed to fail.
On 23/07/2019 16:42, Ken Brown wrote:
On 7/23/2019 9:51 AM, Jon Turney wrote:
On 22/07/2019 15:59, Ken Brown wrote:
With the test version of gdb, attempting to debug bash fails as follows:
$ gdb bash
GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
[...]
Reading symbols from bash...Reading symbols from
On Jul 23 18:59, Corinna Vinschen wrote:
> On Jul 23 18:54, Corinna Vinschen wrote:
> > Hi Ken,
> >
> > On Jul 23 16:12, Ken Brown wrote:
> > > According to POSIX, "The getpgrp() function shall always be successful
> > > and no return value is reserved to indicate an error." Cygwin's
> > >
On Jul 23 18:54, Corinna Vinschen wrote:
> Hi Ken,
>
> On Jul 23 16:12, Ken Brown wrote:
> > According to POSIX, "The getpgrp() function shall always be successful
> > and no return value is reserved to indicate an error." Cygwin's
> > getpgrp() is defined in terms of getpgid(), which is allowed
Hi Ken,
On Jul 23 16:12, Ken Brown wrote:
> According to POSIX, "The getpgrp() function shall always be successful
> and no return value is reserved to indicate an error." Cygwin's
> getpgrp() is defined in terms of getpgid(), which is allowed to fail.
But it shouldn't fail for the current
The following packages have been uploaded to the Cygwin distribution:
* meson-0.50.1-1
Meson is an open source build system meant to be extremely fast. It
generates files for various backends including Ninja, Visual Studio, and
Xcode. Meson does not generate Makefiles, relying solely on
The following packages have been uploaded to the Cygwin distribution:
* meson-0.50.1-1
Meson is an open source build system meant to be extremely fast. It
generates files for various backends including Ninja, Visual Studio, and
Xcode. Meson does not generate Makefiles, relying solely on
This patch makes getpgrp() conform to POSIX. I have some qualms about
it because getpgrp() will now return 0 in cases where it would
previously return -1. I don't know if this is likely to break any
applications.
The patch fixes the problem reported here:
On 7/23/2019 9:51 AM, Jon Turney wrote:
> On 22/07/2019 15:59, Ken Brown wrote:
>> With the test version of gdb, attempting to debug bash fails as follows:
>>
>> $ gdb bash
>> GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
>> [...]
>> Reading symbols from bash...Reading symbols from
>>
> On 7/22/2019 12:59 PM, Eliot Moss wrote:
> On 7/22/2019 12:50 PM, Andy Hall wrote:
> > This behavior of join surprised me:
> >
> > $ join -1 3 <(echo a b col3 c d | unix2dos) <(echo col3 f2 f3 f4 f5)
> > f2 f3 f4 f5
> >
> > Join parses the input line well enough to execute the join, but the
On 22/07/2019 15:59, Ken Brown wrote:
With the test version of gdb, attempting to debug bash fails as follows:
$ gdb bash
GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
[...]
Reading symbols from bash...Reading symbols from
/usr/lib/debug//usr/bin/bash.exe.dbg...done.
done.
(gdb) r -c ls
Starting
On 23/07/2019 14:03, Brian Inglis wrote:
What about mtr-ncurses and mtr-gtk packages and primary mtr... exes?
I have to look into whether there is any significant difference between
mtr-packet exes also requiring renaming.
Then a postinstall symlink(s) creation or update-alternatives run to
On July 22, 2019 9:51 PM Andy Hall wrote:
>This behavior of join surprised me:
>
>$ join -1 3 <(echo a b col3 c d | unix2dos) <(echo col3 f2 f3 f4 f5)
> f2 f3 f4 f5
See if this reduces your surprise somewhat:
$ join -1 3 <(echo a b col3 c d | unix2dos) <(echo col3 f2 f3 f4 f5) | cat -A
--
On Mon, 2019-03-25 at 16:13 -0400, Yaakov Selkowitz wrote:
> Michael,
>
> I am currently working through the rebuild of my Python module packages
> and now have some rebuilds blocked by python-paramiko. If you could
> please rebuild paramiko and its deps which you maintain with today's
> cygport
On 2019-07-22 07:43, Henning wrote:
> On 21/07/2019 20:27, Brian Inglis wrote:
>> Built with gtk2.0-devel installed now requires libgdk_pixbuf2.0_0
>> libglib2.0_0
>> libgtk2.0_0 which probably drags a lot of X in.
>> Is there a standard way to offer subpackages with and without X in these
>>
On 2019-07-22 05:36, Jon Turney wrote:
> On 21/07/2019 19:27, Brian Inglis wrote:
>> On 2019-07-21 12:10, Brian Inglis wrote:
>>> On 2019-07-21 06:59, Jon Turney wrote:
Not sure what you intend, so either (i) explicitly configure
--without-gtk, or
(ii) add the needed gtk devel
Greetings, Andy Hall!
> This behavior of join surprised me:
> $ join -1 3 <(echo a b col3 c d | unix2dos) <(echo col3 f2 f3 f4 f5)
> f2 f3 f4 f5
> Join parses the input line well enough to execute the join, but the
> presence of the DOS line endings suppresses the
> output of fields from the
20 matches
Mail list logo
