OpenType or TrueType fonts installed
under /usr/share/texmf-dist/fonts/{open,true}type/, non-'Microsoft Corp'
Windows fonts including those labelled 'Microsoft supplied font', .TTF, .ttc,
and .ot[cf], but does cache those in the Windows/Fonts/Deleted subdirectory.
For the font
/texmf-dist/fonts/{open,true}type/,
non-'Microsoft Corp' Windows fonts including those labelled 'Microsoft
supplied font', .TTF, .ttc, and .ot[cf], but does cache those in the
Windows/Fonts/Deleted subdirectory.
For the fonts that come with TeX Live, I thought it should be up to
Corp' Windows fonts
including those labelled 'Microsoft supplied font', .TTF, .ttc, and .ot[cf], but
does cache those in the Windows/Fonts/Deleted subdirectory.
I run the attached permanent postinstall local script to pick up all those fonts
the official script does not, clean up old br
Hi folks,
I recently reviewed all the fonts installed on my system and found that
fontconfig cache does not include TeX OpenType or TrueType fonts installed under
/usr/share/texmf-dist/fonts/{open,true}type/, non-'Microsoft Corp' Windows fonts
including those labelled 'Microsof
On 18/01/2022 16:15, Jon Turney wrote:
On 14/01/2022 09:04, Corinna Vinschen wrote:
On Jan 13 15:13, Jon Turney wrote:
Show a MessageBox warning if we are running on a Windows version which
we have deprecated Cygwin support for:
[..]
Question is, how often should setup show this message
On 14/01/2022 09:04, Corinna Vinschen wrote:
On Jan 13 15:13, Jon Turney wrote:
Show a MessageBox warning if we are running on a Windows version which
we have deprecated Cygwin support for:
- Windows 6.0 (Windows Vista, Windows Server 2008)
- 32-bit Windows
This warning can be disabled with
On 2022-01-17 03:03, Corinna Vinschen wrote:
On Jan 16 17:55, Hamish McIntyre-Bhatty wrote:
This reminds me: It's probably useful for me to support 32-bit even after
Cygwin no longer does for my commercial project(s). Which probably means I
should release said package soon (I couldn't get the re
On Jan 16 17:55, Hamish McIntyre-Bhatty wrote:
> This reminds me: It's probably useful for me to support 32-bit even after
> Cygwin no longer does for my commercial project(s). Which probably means I
> should release said package soon (I couldn't get the rebase to work on
> 32-bit before, will ask
Windows version which
we have deprecated Cygwin support for:
- Windows 6.0 (Windows Vista, Windows Server 2008)
- 32-bit Windows
This warning can be disabled with '--allow-unsupported-windows'.
---
Notes:
Not sure if this is needed, or maybe this is just annoying to the ~3% of
use
On Fri, Jan 14, 2022 at 12:45:06PM +0100, Corinna Vinschen wrote:
> On Jan 14 10:54, Adam Dinwoodie wrote:
> > On Fri, 14 Jan 2022 at 09:05, Corinna Vinschen wrote:
> > > On Jan 13 15:13, Jon Turney wrote:
> > > > Show a MessageBox warning if we are running on a Wi
On Jan 14 10:54, Adam Dinwoodie wrote:
> On Fri, 14 Jan 2022 at 09:05, Corinna Vinschen wrote:
> > On Jan 13 15:13, Jon Turney wrote:
> > > Show a MessageBox warning if we are running on a Windows version which
> > > we have deprecated Cygwin support for:
> > >
On Fri, 14 Jan 2022 at 09:05, Corinna Vinschen wrote:
> On Jan 13 15:13, Jon Turney wrote:
> > Show a MessageBox warning if we are running on a Windows version which
> > we have deprecated Cygwin support for:
> >
> > - Windows 6.0 (Windows Vista, Windows Server
On Jan 13 15:13, Jon Turney wrote:
> Show a MessageBox warning if we are running on a Windows version which
> we have deprecated Cygwin support for:
>
> - Windows 6.0 (Windows Vista, Windows Server 2008)
> - 32-bit Windows
>
> This warning can be disabled with '-
Show a MessageBox warning if we are running on a Windows version which
we have deprecated Cygwin support for:
- Windows 6.0 (Windows Vista, Windows Server 2008)
- 32-bit Windows
This warning can be disabled with '--allow-unsupported-windows'.
---
Notes:
Not sure if this is needed
t; > Just thought I should ask: is there a perferred version of Windows to
> > > > > build packages on, or does it not matter?
> > > > Whatever supported version of Windows you use, I'd say.
> > > >
> > > > > I currently build on Windows
On 01/04/2020 10:36, Corinna Vinschen wrote:
> None at all. Right now we still support all versions since Windows
> Vista, so any breakage building stuff on these systems is the fault
> of the Cygwin core. Other than that, Achim is right, of course :)
>
>
> Corinna
I'
Am 01.04.2020 um 11:36 schrieb Corinna Vinschen:
On Mar 31 18:58, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
On 31/03/2020 17:24, ASSI wrote:
Hamish McIntyre-Bhatty via Cygwin-apps writes:
Just thought I should ask: is there a perferred version of Windows to
build packages on, or does it
On Mar 31 18:58, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 31/03/2020 17:24, ASSI wrote:
> > Hamish McIntyre-Bhatty via Cygwin-apps writes:
> >> Just thought I should ask: is there a perferred version of Windows to
> >> build packages on, or does it not mat
On 31/03/2020 17:24, ASSI wrote:
> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>> Just thought I should ask: is there a perferred version of Windows to
>> build packages on, or does it not matter?
> Whatever supported version of Windows you use, I'd say.
>
>>
Hamish McIntyre-Bhatty via Cygwin-apps writes:
> Just thought I should ask: is there a perferred version of Windows to
> build packages on, or does it not matter?
Whatever supported version of Windows you use, I'd say.
> I currently build on Windows 7, following the tradition
Hi all,
Just thought I should ask: is there a perferred version of Windows to
build packages on, or does it not matter?
I currently build on Windows 7, following the tradition of building on
the oldest supported platform, but I have no idea if this is needed with
Cygwin.
Hamish
want to make it hard for someone to destroy their working XP
> installation, so allowing setup to simply run on XP, which will break it by
> upgrading it to the latest version (which doesn't work on XP), seems
> contraindicated.
>
> When --allow-unsupported-windows is on:
>
installation, so allowing setup to simply run on XP, which will break it by
upgrading it to the latest version (which doesn't work on XP), seems
contraindicated.
When --allow-unsupported-windows is on:
- Don't check the windows version
- Don't read the mirror list from cygwin.com
- Don&#
same machine, there is also a virtual
machine running Windows XP. From that, I can use setup.exe and seamlessly
update cygwin which is then also available in the Windows 7 host
environment. Running setup.exe from Windows 7 directly still fails with the
described symptoms.
There must be something weird
also a virtual
> machine running Windows XP. From that, I can use setup.exe and seamlessly
> update cygwin which is then also available in the Windows 7 host
> environment. Running setup.exe from Windows 7 directly still fails with the
> described symptoms.
>
> There must be someth
I had recently reported that an old network installation problem, that
had been resolved meanwhile, reappeared:
https://cygwin.com/ml/cygwin-apps/2015-12/msg00012.html
As an additional observation, on the same machine, there is also a
virtual machine running Windows XP. From that, I can use
On Jan 8 14:32, Yaakov Selkowitz wrote:
> Yaakov Selkowitz (3):
> propsheet: drop support for Common Controls v4
> nio-ie5: drop unnecessary LoadLibrary call
> Use Winsock 2 throughout
>
> Makefile.am | 2 +-
> nio-ftp.cc | 2 +-
> nio-http.cc | 2 +-
> nio-ie5.cc | 7 ---
>
Yaakov Selkowitz (3):
propsheet: drop support for Common Controls v4
nio-ie5: drop unnecessary LoadLibrary call
Use Winsock 2 throughout
Makefile.am | 2 +-
nio-ftp.cc | 2 +-
nio-http.cc | 2 +-
nio-ie5.cc | 7 ---
propsheet.cc | 45 +--
On Oct 15, 2015, at 2:29 PM, Warren Young wrote:
>
> Achim Gratz noted that my default permissions may be weird because I am
> running with a Microsoft Account rather than a local one.
I just poked a hole in that theory last night: I have a Windows 8 VM at home
that also uses a M
pushed me into, since I upgraded this VM to Windows 10 to test Windows 10.
Might as well use it with its defaults as much as possible, yes? No point
testing a new OS if I’m just going to turn off everything that’s new about it.
[1]: https://cygwin.com/ml/cygwin/2015-10/msg00179.html
On Tue, Feb 25, 2014 at 09:32:20PM +0100, Achim Gratz wrote:
>Corinna Vinschen writes:
>> I'm not sure what you're doing.
>
>I'm making two builds from two Cygwin installations (one 32bit and one
>64bit) with the native toolchain (not cross-compiled). I've had some
>disk space problems that preven
Corinna Vinschen writes:
> I'm not sure what you're doing.
I'm making two builds from two Cygwin installations (one 32bit and one
64bit) with the native toolchain (not cross-compiled). I've had some
disk space problems that prevented installation of the cross compilation
toolchain(s) originally.
On Feb 25 19:58, Achim Gratz wrote:
> Christopher Faylor writes:
> > On Tue, Feb 25, 2014 at 01:13:29PM -0500, Christopher Faylor wrote:
> >>On Tue, Feb 25, 2014 at 07:06:27PM +0100, Achim Gratz wrote:
> >>>Corinna Vinschen writes:
> I added the 8.1 GUID to setup on 2013-11-19 already. Did we
Christopher Faylor writes:
> On Tue, Feb 25, 2014 at 01:13:29PM -0500, Christopher Faylor wrote:
>>On Tue, Feb 25, 2014 at 07:06:27PM +0100, Achim Gratz wrote:
>>>Corinna Vinschen writes:
I added the 8.1 GUID to setup on 2013-11-19 already. Did we have no new
release since then?
>>>
>>>I
>I don't think that version was ever released on cygwin.com.
>
>I'll release a new version ASAP.
Done.
A list of what changed is below.
Hint: It's all Corinna.
cgf
revision 2.844
date: 2013/11/19 21:52:55; author: corinna; state: Exp; lines: +7 -2
*
On Tue, Feb 25, 2014 at 07:06:27PM +0100, Achim Gratz wrote:
>Corinna Vinschen writes:
>> I added the 8.1 GUID to setup on 2013-11-19 already. Did we have no new
>> release since then?
>
>I don't think that version was ever released on cygwin.com.
I'll release a new version ASAP.
cgf
Corinna Vinschen writes:
> I added the 8.1 GUID to setup on 2013-11-19 already. Did we have no new
> release since then?
I don't think that version was ever released on cygwin.com.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terra
On Feb 25 10:56, Yaakov (Cygwin/X) wrote:
> Just noticed that Windows 8.1 compatibility was missing from
> setup*.exe.manifest; patch attached.
>
>
> Yaakov
> 2014-02-25 Yaakov Selkowitz
>
> * setup.exe.manifest: Add Windows 8.1 to compatibility list.
>
Just noticed that Windows 8.1 compatibility was missing from
setup*.exe.manifest; patch attached.
Yaakov
2014-02-25 Yaakov Selkowitz
* setup.exe.manifest: Add Windows 8.1 to compatibility list.
* setup64.exe.manifest: Ditto.
Index: setup.exe.manifest
Hi
A new 64bit version of 'multitail' has been uploaded to a server near you.
o Update to latest upstream release
o Build for cygwin 1.7.19 with gcc-4.8.0
o Added Oracle WebLogic and Oracle GoldenGate logfile highlightning
multitail NEWS:
===
o No NEWS file available
CYGWIN
Hi
New versions of 'libwmf/libwmf027/libwmf-devel/libwmf-doc/gdk-pixbuf2-wmf' have
been uploaded to a server near you.
o Build for cygwin 1.7.19-2 with gcc-4.8.0
CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
If you want to unsubscribe from the cygwin-announce mailing list
On 2/6/2012 6:30 AM, Corinna Vinschen wrote:
6.2 is correct. Have a look into dump_sysinfo() in utils/cygcheck.cc.
It's updated to the latest known state when the W8 test release became
available.
Ah, thanks. I looked at wincap.cc and didn't see anything there, so...
--
Chuck
On Feb 5 16:40, Charles Wilson wrote:
> Call for assistance: can somebody with access to Windows 8 provide
> an appropriate tested patch so that winProductName can recognize
> Windows 8 (various flavors, including Windows Server 8)?
>
> Getting the System Version
> http://msd
Call for assistance: can somebody with access to Windows 8 provide an
appropriate tested patch so that winProductName can recognize Windows 8
(various flavors, including Windows Server 8)?
Getting the System Version
http://msdn.microsoft.com/en-us/library/ms724429%28v=vs.85%29.aspx
has not
David,
On Jul 26 23:47, Yaakov S wrote:
> On Tue, 2010-07-27 at 04:53 +0100, Dave Korn wrote:
> > Try installing libintl2. a2ps.exe depends on that very old version but
> > doesn't mention it explicitly in its setup.hint dependencies. (Probably it
> > used to get pulled in by default anyway by
On 2 June 2010 22:01, Christopher Faylor wrote:
> I'm pretty sure that everyone here knows that ptys don't work well with
> all DOS applications.
PuTTYcyg author Mark Edgar points out a rather simple workaround for
this that hadn't occurred to me before: invoke the problematic
application through
ing to.
I think any solution to this issue should be done as a standalone
wrapper that needs to be invoked explicitly, at least initially. If it
proved itself, it would be worth considering to invoke it
automatically from the Cygwin DLL when a Windows program is spawned.
Andy
On 3 June 2010 21:25, Thomas Wolff wrote:
> Ah, right! I had not noticed this, only that error message are not fixed.
> Something else that *is* fixed this way is e.g.
> cmd /c help
> (which also shows that cmd has a built-in chcp in addition to the
> stand-alone chcp.com that at l
On Thu, Jun 03, 2010 at 07:17:34PM +0100, Andy Koppe wrote:
>On 2 June 2010 21:39, Thomas Wolff wrote:
>> Before making it the only default, however, there's still two issues to
>> consider concerning interoperability with Windows programs:
>>
>> ?? * The known lim
On Thu, Jun 03, 2010 at 02:14:29PM -0600, Warren Young wrote:
>On 6/2/2010 7:02 PM, Christopher Faylor wrote:
>>>
>>> Does mintty currently work around any such problems?
>>
>> I really don't understand the question in light of the observations that
>> there will be problems with some MS-DOS applic
Am 03.06.2010 20:17, schrieb Andy Koppe:
On 2 June 2010 21:39, Thomas Wolff wrote:
...
* Another issue with even those Windows/DOS programs that do work in
general: They assume the Windows ANSI encoding so their output
(and input assumption) will not match the mintty character
On 6/2/2010 7:02 PM, Christopher Faylor wrote:
Does mintty currently work around any such problems?
I really don't understand the question in light of the observations that
there will be problems with some MS-DOS applications if we switch to
mintty because of cygwin's pty implementation.
I'm
On 2 June 2010 21:39, Thomas Wolff wrote:
> Before making it the only default, however, there's still two issues to
> consider concerning interoperability with Windows programs:
>
> * The known limitation with certain Windows (or even DOS) programs
> due to the incompatib
On Wed, Jun 02, 2010 at 03:18:17PM -0600, Warren Young wrote:
>On 6/2/2010 3:01 PM, Christopher Faylor wrote:
>>I'm pretty sure that everyone here knows that ptys don't work well with
>>all DOS applications. I mentioned it when I first proposed making
>>mintty the default. I'm not opposed to two
On 6/2/2010 3:01 PM, Christopher Faylor wrote:
It could be that there is an application
used by thousands that works well in the console window while failing
miserably under a tty/pty.
Does mintty currently work around any such problems?
If so, how hard is it to just keep finding them and work
s.
>Before making it the only default, however, there's still two issues to
>consider concerning interoperability with Windows programs:
>
>* The known limitation with certain Windows (or even DOS) programs
> due to the incompatibility of some of the multiple Windows
fault terminal?
Sounds good to me.
I absolutely support to promote mintty side-by-side as one of two
desktop links.
Before making it the only default, however, there's still two issues to
consider concerning interoperability with Windows programs:
* The known limitation wi
||
defined(__MINGW32__)
+ /* mingw or cygwin-1.5: work around bug in Windows 7, but also
+* employ on XP and above. This means that setup_invisible_console()
+* is now used only on <= Win2k */
+ if (os_version >= 0x0501)
+ {
+ HMODULE lib = GetModuleHa
Alexander Gottwald wrote:
> Surprise!
>
> I did not follow the list very closely so I'm not sure if I'd be able to
> build a working replacement package of run esp. since I still only
> have the 1.5 tree around here.
>
> I'd feel relieved if someone would take over the run package. If that's
>
Corinna Vinschen wrote:
> Ok, so Alexander replied (thanks!) and would like to drop maintainership
> so if you like to take it back, feel free.
OK.
> We need run working for W7 asap, but in the long run, why not have both
> capabilites in one single "run" application?
Mainly to allow for continu
On Aug 9 15:49, Charles Wilson wrote:
> [consolidated reply]
>
> Corinna Vinschen wrote:
> > Oh, right. It won't work quite correctly under 1.5 either. Why do
> > we need a 1.5 aware version again? Anyway, if you look into the
> > patch, you'll see that it is very simple to keep the old code i
Christopher Faylor wrote:
> On Sun, Aug 09, 2009 at 04:43:19PM +0200, Corinna Vinschen wrote:
>> On Aug 9 10:20, Christopher Faylor wrote:
>>> Since we don't have a package maintainer for run, why not just
>>> make this change and release it for 1.7?
>> We don't know yet if we don't have a package
[consolidated reply]
Corinna Vinschen wrote:
> Oh, right. It won't work quite correctly under 1.5 either. Why do
> we need a 1.5 aware version again? Anyway, if you look into the
> patch, you'll see that it is very simple to keep the old code in
> conditionally. What about this one? It only l
On Sun, Aug 09, 2009 at 04:43:19PM +0200, Corinna Vinschen wrote:
>On Aug 9 10:20, Christopher Faylor wrote:
>> On Sun, Aug 09, 2009 at 04:06:24PM +0200, Corinna Vinschen wrote:
>> >--- run-1.1.10.orig/src/run.c 2006-05-22 14:32:43.0 +0200
>> >+++ run-1.1.10/src/run.c2009-08-09 1
On Aug 9 10:20, Christopher Faylor wrote:
> On Sun, Aug 09, 2009 at 04:06:24PM +0200, Corinna Vinschen wrote:
> >--- run-1.1.10.orig/src/run.c2006-05-22 14:32:43.0 +0200
> >+++ run-1.1.10/src/run.c 2009-08-09 16:03:58.0 +0200
> >@@ -349,6 +349,8 @@ int start_child(char*
On Sun, Aug 09, 2009 at 04:06:24PM +0200, Corinna Vinschen wrote:
>On Aug 9 15:58, Corinna Vinschen wrote:
>> On Aug 9 09:42, Charles Wilson wrote:
>> > Corinna Vinschen wrote:
>> > > New patch below.
>> >
>> > ...which only works if run is compiled under cygwin 1.7, not if it is
>> > compiled a
On Aug 9 15:58, Corinna Vinschen wrote:
> On Aug 9 09:42, Charles Wilson wrote:
> > Corinna Vinschen wrote:
> > > New patch below.
> >
> > ...which only works if run is compiled under cygwin 1.7, not if it is
> > compiled as a native app or under cygwin 1.5. I guess it's up to
> > Alexander (or
On Aug 9 09:42, Charles Wilson wrote:
> Corinna Vinschen wrote:
>
> > Actually, it turned out that the entire FreeConsole/AttachConsole
> > stuff is entirely unnecessary. I have a solution now which apparently
> > works for all OSes and it's really very simple. What I didn't realize
> > is that
Corinna Vinschen wrote:
> Actually, it turned out that the entire FreeConsole/AttachConsole
> stuff is entirely unnecessary. I have a solution now which apparently
> works for all OSes and it's really very simple. What I didn't realize
> is that run.exe as a GUI application has no console attach
2009/8/9 Corinna Vinschen:
>> > Having the console creation code in run also has the advantage of
>> > working when starting run from an existing console window. The child
>> > process will run detached from the existing console in an invisible
>> > console window. You can close the original cons
On Aug 9 11:21, Andy Koppe wrote:
> 2009/8/9 Corinna Vinschen:
> > Have you seen the patch? The code duplication is tiny. It's a much
> > simpler solution than in the Cygwin DLL.
>
> But it'll still need changing again when MS break hidden consoles again.
>
> > Having the console creation code
2009/8/9 Corinna Vinschen:
> Have you seen the patch? The code duplication is tiny. It's a much
> simpler solution than in the Cygwin DLL.
But it'll still need changing again when MS break hidden consoles again.
> Having the console creation code in run also has the advantage of
> working when
On Aug 9 10:06, Corinna Vinschen wrote:
> On Aug 8 19:51, Charles Wilson wrote:
> > Anyway - Corinna, I dunno about Alexander/run but I'd like to see the
> > "incredibly simple" patch, for run2.
>
> Well, the patch is dead simple, just look into my original mail. Feel
> free to use it for run2
On Aug 8 19:51, Charles Wilson wrote:
> Anyway - Corinna, I dunno about Alexander/run but I'd like to see the
> "incredibly simple" patch, for run2.
Well, the patch is dead simple, just look into my original mail. Feel
free to use it for run2 as well.
Corinna
--
Corinna Vinschen
On Aug 9 00:14, Andy Koppe wrote:
> 2009/8/8 Corinna Vinschen :
> > are you still with us in some way? There hasn't been a new version of
> > the "run" tool for ages. Now, with the upcoming Windows 7, it's
> > necessary to workaround a bug in W7 in t
2009/8/9 Charles Wilson:
>> Couldn't "run" just do nothing but invoke spawnvp() on the given
>> command? This way, it would rely on the invisible console code in
>> cygwin1.dll, and there'd be no need for duplicating any of that code.
>
> That's a feature, not a bug.
Not saying it's a bug, but an
Andy Koppe wrote:
> 2009/8/8 Corinna Vinschen
>> are you still with us in some way? There hasn't been a new version of
>> the "run" tool for ages. Now, with the upcoming Windows 7, it's
>> necessary to workaround a bug in W7 in terms of creating an inv
2009/8/8 Corinna Vinschen :
> are you still with us in some way? There hasn't been a new version of
> the "run" tool for ages. Now, with the upcoming Windows 7, it's
> necessary to workaround a bug in W7 in terms of creating an invisible
> console. I have experi
Hi Alexander,
are you still with us in some way? There hasn't been a new version of
the "run" tool for ages. Now, with the upcoming Windows 7, it's
necessary to workaround a bug in W7 in terms of creating an invisible
console. I have experimented a lot and came up with
s problem.
>
>General speaking I have not a problem with the behaviour itself, but when
>I use the public-key authentication the Windows Utility "diskpart.exe" does
>not start. It only works when I use password-authentication instead.
>But as diskpart is included in some scripts,
On Jul 22 09:04, Zimmermann, Benjamin wrote:
> 3) When will the next major release of Cygwin (Cygwin 1.7 or so...) be
> released?
Hopefully in 2008.
> 4) Does anybody know if the public-key authentication / own session-feature
> will be solved in Cygwin 1.7?
Yes. By using Cygwin's own LSA
, but when
I use the public-key authentication the Windows Utility "diskpart.exe" does
not start. It only works when I use password-authentication instead.
But as diskpart is included in some scripts, it is mandandory for me to use the
public-key authentication.
I have already search in th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Dr. Volker Zell on 3/23/2008 9:54 AM:
| Hi
|
| I would like to adopt and maintain the 'libwmf' package from Gerrit
P.Haase and split it
| into 'libwmf/libwmf027/libwmf-devel/libwmf-doc/gdk-pixbuf2-wmf' packages.
Uploaded.
- --
Don't wor
All packages builds from source.
setup.hints and packages look fine.
GTG
Gergely Budai
---
Hi
I would like to adopt and maintain the 'libwmf' package from Gerrit P.Haase and
split it
into 'libwmf/libwmf027/
are the setup.hint files:
---
./gdk-pixbuf2-wmf/setup.hint
sdesc: "Windows Metafile library - (GdkPixbuf loader)"
ldesc: "Library and utilities for displaying and converting metafile images."
category: Devel Graphics Libs
requires: cygwin gtk2-
Krzysztof Ostrowski wrote:
> What is the purpose of "00ash.sh", and what kind of system calls does it
> attempt at making? Surely, it must be something very unusual because I've got
The strange thing about this is that 00ash should be totally superfluous
on a new system. And syscalls? It's a sh
On Thu, 13 Dec 2007, Corinna Vinschen wrote:
> On Dec 13 16:13, Jari Aalto wrote:
> > * Thu 2007-12-13 Corinna Vinschen <[EMAIL PROTECTED]>
> > > ...it's still version 1.01. Wouldn't the above change qualify for
> > > a 1.02 release? Just an idea...
> >
> > I'll contact the original author; I fe
On Thu, 13 Dec 2007, Corinna Vinschen wrote:
> On Dec 13 13:06, Jari Aalto wrote:
> >
> > Adoption of package by Chris Rodgers. Note: the category was changed
> > from "Base" to "Util", since this does not seem to be essential package.
>
> This package is in Base for a reason. It is an essential
On Dec 13 16:13, Jari Aalto wrote:
> * Thu 2007-12-13 Corinna Vinschen <[EMAIL PROTECTED]>
> > ...it's still version 1.01. Wouldn't the above change qualify for
> > a 1.02 release? Just an idea...
>
> I'll contact the original author; I feel the upstream number should stay
> in the "official" ve
* Thu 2007-12-13 Corinna Vinschen <[EMAIL PROTECTED]>
* Message-Id: [EMAIL PROTECTED]
> On Dec 13 14:17, Jari Aalto wrote:
>
>> I added these that were missing from main.c::printUsage
>>
>> SeCreateGlobalPrivilege
>> SeCreateSymbolicLinkPrivilege
>> SeImpersonatePrivilege
>> SeIncr
On Dec 13 14:17, Jari Aalto wrote:
> I added these that were missing from main.c::printUsage
>
> SeCreateGlobalPrivilege
> SeCreateSymbolicLinkPrivilege
> SeImpersonatePrivilege
> SeIncreaseWorkingSetPrivilege
> SeRelabelPrivilege
> SeTimeZonePrivilege
> SeTrustedCredMa
* Thu 2007-12-13 Corinna Vinschen <[EMAIL PROTECTED]>
* Message-Id: [EMAIL PROTECTED]
>> This package is in Base for a reason. It is an essential package and
>> used for instance in the openssh config script.
Ok. Fixed.
> Oh, btw. While you're at it, would you mind to add the missing
> user pri
On Dec 13 12:19, Corinna Vinschen wrote:
> On Dec 13 13:06, Jari Aalto wrote:
> >
> > Adoption of package by Chris Rodgers. Note: the category was changed
> > from "Base" to "Util", since this does not seem to be essential package.
>
> This package is in Base for a reason. It is an essential pac
On Dec 13 13:06, Jari Aalto wrote:
>
> Adoption of package by Chris Rodgers. Note: the category was changed
> from "Base" to "Util", since this does not seem to be essential package.
This package is in Base for a reason. It is an essential package and
used for instance in the openssh config scri
Adoption of package by Chris Rodgers. Note: the category was changed
from "Base" to "Util", since this does not seem to be essential package.
sdesc: "Alter Windows user rights and privileges from command line"
ldesc: "Alter Windows user rights and privileges
m I wrong in thinking there's no need at all to be
running anything from outside the newly-installed cygwin tree (and the basic
windows system dirs)?
cheers,
DaveK
--
Can't think of a witty .sigline today
s,
> > >
> > > I'm trying to install Cygwin on Windows Server 2000. I've downloaded
> > > the latest version of Cygwin's setup.exe, started it, got all the
> > > way to the point where downloading of packages begins, but there i
> > > get "
Corinna Vinschen wrote:
> I agree. "legacy" sounds better. What do you think about the symlink
> idea for now?
Okay, fixed thusly.
BrianIndex: ini.h
===
RCS file: /cvs/cygwin-apps/setup/ini.h,v
retrieving revision 2.36
diff -u -p
at most users already are using the right
>> >setup version when 1.7.0 gets released once.
>>
>> I woke up this morning and realized that it shouldn't be called "9x" but
>> rather "legacy". Then it should be slightly clearer that this
>> repository supports older windows and maybe even now-obsolete cygwin
>> features.
>
>I agree. "legacy" sounds better. What do you think about the symlink
>idea for now?
Go for it.
cgf
's/release/release_9x/'.
> >This allows testing and deploying the new setup.exe tool very soon. It
> >has the aditional advantage that most users already are using the right
> >setup version when 1.7.0 gets released once.
>
> I woke up this morning and realized th
1 - 100 of 190 matches
Mail list logo
