Yaakov (Cygwin/X) wrote:
On 23/12/2009 21:42, Dave Korn wrote:
Christopher Faylor wrote:
On Thu, Dec 24, 2009 at 01:58:48AM +, Dave Korn wrote:
Yaakov (Cygwin/X) wrote:
On 23/12/2009 14:53, Christopher Faylor wrote:
Of course, there has been at least one package update since I sent
Christopher Faylor wrote:
Can we hold off on new package uploads for a couple of days to allow the
mirrors some time to stabilize? I was thinking that we could resume uploads
after Christmas.
Thanks, that answers my unasked question; I was wondering whether a freeze
might be in order and
Christopher Faylor wrote:
On Wed, Dec 23, 2009 at 03:34:20PM -0500, Charles Wilson wrote:
Christopher Faylor wrote:
Can we hold off on new package uploads for a couple of days to allow the
mirrors some time to stabilize? I was thinking that we could resume uploads
after Christmas.
OK. I had
Yaakov (Cygwin/X) wrote:
On 23/12/2009 14:53, Christopher Faylor wrote:
Of course, there has been at least one package update since I sent this
message too so a cow has crashed through the barn wall.
EIEIO? :-)
Nah, wrong arch! :-)
cheers,
DaveK
Christopher Faylor wrote:
On Thu, Dec 24, 2009 at 01:58:48AM +, Dave Korn wrote:
Yaakov (Cygwin/X) wrote:
On 23/12/2009 14:53, Christopher Faylor wrote:
Of course, there has been at least one package update since I sent this
message too so a cow has crashed through the barn wall.
EIEIO
Yaakov (Cygwin/X) wrote:
Woops, just spotted a discrepancy:
In libelf0/setup.hint, libgcc1 is missing from requires:.
When I build those packages from source, there is no dependency on libgcc:
ad...@ubik /tmp/libelf/release/libelf0-0.8.13-1
$ cygcheck inst/usr/bin/cygelf-0.dll
Hi all,
libelf(*) is a requirement for supporting LTO in the upcoming GCC 4.5.0 (and
beyond), and I needed to build myself a local copy so I could test that, so I
figured I might as well package it properly while I was at it.
http://packages.debian.org/search?keywords=libelf
It's
Yaakov (Cygwin/X) wrote:
For your own convenience, I would strongly suggest
MAKEOPTS should not be used to
Same goes for SIG
Thanks, I don't know much about the detailed usage of quite a few of the
cygport variables. (There isn't any other significant documentation beyond
the contents
Yaakov (Cygwin/X) wrote:
Actually, you need to add an explicit --enable-compat, otherwise
whenever you need to roll the next version/release, it will see gelf.h
and libelf.h present (from this release) and default to DO_COMPAT=no
to avoid overwriting them (for fear they are libc headers).
Yaakov (Cygwin/X) wrote:
On 20/12/2009 20:02, Dave Korn wrote:
Because GCC needs everything else in libelf, in particular the functions,
not just the #defines, so I wanted it all to come from one nice
consistent source.
Right, but if Cygwin's headers are missing something then they should
Corinna Vinschen wrote:
Btw., is setup finished for the 1.7.1 release with this patch or is
there more to come?
Can't speak for cgf, but from my side, I've got all my new features done. I
just discovered YA loop-retrying-forever-in-unattended mode bug, which I'll
spin up a patch for
Corinna Vinschen wrote:
On Dec 16 14:24, Dave Korn wrote:
Does this symptom suggest any possibilities to anyone?
Unfortunately not. It's really officially the NULL SID. The NULL SID
ACE is created when at least one of the special SUID, SGID or VTX bits
are set in the permissions.
Ah
Thomas Wolff wrote:
Current Directory: h:\
User has NO backup/restore rights
Could not open Service control manager
source: network install
root: H:\cygwin17 binary user
filemanip:NtCreateFile - C03A
\??\H:\cygwin17\etc\setup\installed.db
io_stream_cygfile:
Thomas Wolff wrote:
Dave Korn wrote:
Thomas Wolff wrote:
Selected local directory: H:\cygwin17p1
mkdir:NtCreateFile - C022
mbox note: Couldn't create directory H:\cygwin17p1, sorry. (Is drive
full or read-only?)
So that's coming from here:
status = NtCreateFile (dir
Thomas Wolff wrote:
Selected local directory: H:\cygwin17p1
mkdir:NtCreateFile - C022
mbox note: Couldn't create directory H:\cygwin17p1, sorry. (Is drive full or
read-only?)
So that's coming from here:
status = NtCreateFile (dir,
Corinna Vinschen wrote:
cvs -d :pserver:anon...@cygwin.com:/cvs/cygwin-apps setup
CC=gcc-3 configure
make 'CFLAGS=-g'
So I don't need to switch set-gcc-default-3.sh, thanks.
Actually, I already checked out and compiled (after installing a
bunch of dependencies) over night after cgf's
Christopher Faylor wrote:
On Thu, Dec 10, 2009 at 08:19:50PM +, Dave Korn wrote:
Corinna Vinschen wrote:
cvs -d :pserver:anon...@cygwin.com:/cvs/cygwin-apps setup
CC=gcc-3 configure
make 'CFLAGS=-g'
So I don't need to switch set-gcc-default-3.sh, thanks.
Actually, I already checked
Hi all,
In between bikeshedding with one hand, I have still been writing code with
the other :) so anyway, here's the final version of the local package dir page
browser and error-handling improvements fix; I'll hold off on committing it
overnight while I try some more to break it and to
JonY wrote:
On 11/22/2009 12:17, Eric Blake wrote:
Release a single -2 for just one of the two versions (your choice of
whether it is for 1.5 or for 1.7); but do NOT do a -2 for both 1.5 and
1.7, or we are right back to the complaint. In future builds, if you want
to continue supporting
Charles Wilson wrote:
Dave Korn wrote:
If you build and package exactly the same sources in exactly the same way
under 1.5 and 1.7, I would by default expect them to be released with the
same
version numbers. Nothing is actually going to conflict, is it?
But the configure checks
[ I'm finishing up the local package directory browse improvements, and
spotted this one in the process. ]
Steps to reproduce:
- Fire up completely clean VM or other system with no traces of cygwin on it.
- Run setup.exe and set it to Install from local package dir.
- Click through.
- After
Thomas Wolff wrote:
ext Corinna Vinschen wrote:
Are you sure the share permissions are sufficient? In contrast to the
1.5 setup, the 1.7 setup tries to create files and directories with
explicit ACLs.
On the H: drive, I have full access according to the Windows
properties dialog.
On the
Thomas Wolff wrote:
Dave Korn schrieb:
...
Say, has anyone checked it's still possible to install to a FAT fs
using the
latest setup.exe? I might try digging up a pen drive later tonight
and see
what happens.
Works (FAT32 @ USB).
Thanks for testing :)
cheers,
DaveK
Christopher Faylor wrote:
On Wed, Nov 04, 2009 at 12:57:05PM -0500, Christopher Faylor wrote:
On Wed, Nov 04, 2009 at 06:05:27PM +, Dave Korn wrote:
Christopher Faylor wrote:
Why not add a new option entirely or some sort of different syntax for
categories like Net: or something?
I
Yaakov (Cygwin/X) wrote:
1) Shouldn't the DLLs be linked with -Wl,--enable-auto-image-base? (Why
this isn't the binutils default already, I really don't know.)
It's in the compiler's link spec, turned on automatically when you use
-shared or -mdll, so anything that uses the gcc driver to
Charles Wilson wrote:
In setup-1.7, on the Select Local Package Directory page, it says:
Select a directory where you want Setup to store the installation files
it downloads. The directory will be created if it does not already
exist.
So, I type in a directory name:
C:\TEMP\cygwin17
Corinna Vinschen wrote:
any reason that you didn't check this in already?
Been busy. I'll get on with it, but could someone who has an NT4 system
please make a mental note to check setup.exe still works there sometime in the
not-too-distant, just in case? TIA!
cheers,
DaveK
Corinna Vinschen wrote:
On Nov 4 15:31, Dave Korn wrote:
Corinna Vinschen wrote:
any reason that you didn't check this in already?
Been busy. I'll get on with it, but could someone who has an NT4 system
please make a mental note to check setup.exe still works there sometime
Corinna Vinschen wrote:
On Nov 3 14:10, Christopher Faylor wrote:
On Tue, Nov 03, 2009 at 06:56:33PM +0100, Corinna Vinschen wrote:
On Nov 3 12:37, Christopher Faylor wrote:
http://cygwin.com/ml/cygwin/2009-09/msg00752.html
I looked into this briefly back then and I don't think I saw any
Christopher Faylor wrote:
Why not just subscribe to the appropriate cvs list? You'll see relevant
changes there.
Forgetfulness its existence is really the only reason.
We have this tradition over on GCC and binutils, and they have -cvs lists
too; I think that it's probably because
Christopher Faylor wrote:
On Wed, Nov 04, 2009 at 04:11:42PM +, Dave Korn wrote:
Christopher Faylor wrote:
Why not just subscribe to the appropriate cvs list? You'll see relevant
changes there.
Forgetfulness its existence is really the only reason.
We have this tradition over on GCC
Hi all,
In unattended mode, setup.exe automatically answers yes to all message
boxes. If the message box is asking whether to retry an incomplete download,
and the reason for the incomplete download is something non-transient, like
the localhost or the mirror going offline, or a file is
Hi again!
During the recent rejig of settings handling, the command-line -l option
(aka --local-package-dir) got borked. This patch restores it, but it might
not be quite what's wanted, because it changes the semantics slightly; that's
just the way I happened to want it to work for the
Hello perverts and non-perverts alike!
Having recently become a pervert, oops I mean provider, I wanted to provide
a full turnkey installation on a DVD for offline use, and to avoid confusing
any cygn00bs among them, I wanted it to have a setup.exe that would just
install from the provided
Are we having fun yet?
This patch makes the local package dir browsing experience nicer. (It also
rolls up the previous patch about fixing the localdir option, sorry for being
lazy; just ignore that very first hunk for the moment. I could have manually
chopped it out but then the line
Last but not least,
I found myself wanting to run setup in unattended mode to install absolutely
everything, so I figured the nicest solution was to allow the -p option to
accept category names as well as package names, so that I could use -p All.
The attached patch does just that.
Dave Korn wrote:
Christopher Faylor wrote:
FWIW, I'll send you a bottle of champagne on the day that we have
excessive traffic issues in cygwin-apps-cvs.
Well, let's see if I can't unleash a minor flood sometime in the next day or
two anyway ... now posting!
HOWZAT?!(*)
cheers
Christopher Faylor wrote:
I think the original semantics are quite a bit less surprising and the option
should be checked first.
Figured that might be the case, so here it is the other way.
* localdir.cc (LocalDirSetting::LocalDirSetting): Restore -l option.
OK now?
cheers,
Christopher Faylor wrote:
Unfortunately, no, I don't think so. I like the idea but I don't like
overloading
-p as it could cause confusion.
Do we actually have any packages that have the same names as categories? I
guess we might do one day even if we don't now, but I didn't see the
Christopher Faylor wrote:
I think so but maybe Corinna should ok this since I assume that it changes
her recently checked in change.
Yes, it reverts part of it:
It also resolves the what-to-do-when-the-directory-doesn't-exist problem
slightly differently. I didn't want to just
Thomas Wolff wrote:
I wanted to install 1.7 on another machine, target directory
H:\cygwin, but it failed with the attached error.
Handy hint for next time: Did you know you can copy and paste most windows
popup error dialogs? Just press Ctrl+C while the dialog is selected, and then
when
Corinna Vinschen wrote:
On Nov 4 17:47, Dave Korn wrote:
Overall I think this is a much more friendly user experience. OK for head?
In theory, yes, with two tweaks...
Index: localdir.cc
[...]
@@ -213,6 +252,12 @@ LocalDirPage::OnNext ()
return IDD_CHOOSE
[ I've got a few patches in the pipeline that I'll be able to send upstream
shortly. This one needs some thorough testing, so I'm throwing it over the
wall early to give some advance notice and ask for help. ]
This fixes the CoCreateInstance failed with error XXX, Setup will not be
able to
Dave Korn wrote:
I don't think the choice of threading model
matters much to setup.exe; we only use COM for shell functions and common
control dialogs, none of which we're doing in a parallelized or multi-threaded
fashion, so the serialisation between threads within setup.exe implied
Charles Wilson wrote:
Dave Korn wrote:
However because of the scary comment about win7, I think this must be a
slightly hairy and not necessarily entirely backward-compatible area. I've
tested it on XP and 2k; can anyone help out by checking it on any of
NT/2k3/Vista/2k8/W7 for me? I
Dave Korn wrote:
Charles Wilson wrote:
Windows Vista SP2: it did create the shortcuts.
However, on exit
I think that's a
I forgot to say thanks! Thanks for testing my patch Chuck!
cheers,
DaveK
Hello, sailor!
Charles Wilson wrote:
And now for something completely different:
By something completely different, you mean posting an ITP to the announce
list?
NFrotz is a z Z-Machine interpretor (virtual machine) for text mode
interactive games. It is an ncurses-based synthesis of
Charles Wilson wrote:
Although it doesn't actually need any votes, just a GTG.
setup.hint:
requires: libncurses9 diffutils
That should mention libgcc1, for completeness. And possibly even 'wget',
since the zork-config script relies on that. I see you've got diffutils and I
think it's
Just noticed this on my local mirror:
Index of /pub/cygwin/release-2/perl/perl-Error
Icon Name Last modified Size Description
[DIR] Parent Directory -
[ ] md5.sum 13-Oct-2009 15:02
Dave Korn wrote:
Fergus wrote:
Downloaded from two different mirrors this file has md5sum
479d8f95c1306486af1adcb5a2ad54b1
but setup-2.ini gives
c3887f0ef36cc78c51c54abca9b4425a
The file size 15536137 is correct.
Yes indeed. Looks like fallout from:
http://cygwin.com/ml/cygwin
Christopher Faylor wrote:
PLEASE don't tinker with the release directories, especially in an
attempt to fix my packages.
Understood, sorry, won't do that again. The original md5.sum is in my ~/ if
you need it for anything. The time stamp reads Jul 5 02:01 which I think
is the only
Dave Korn wrote:
BTW, before jumping clumsily in with my dirty great size 9s, I did also
download the -src tarball with the dubious checksum and verify it (by diffing
against a recent cvs checkout) to make sure it hadn't *actually* been tampered
with; I didn't spot any suspicious insertions
Yaakov (Cygwin/X) wrote:
On 27/09/2009 19:09, Dave Korn wrote:
4.3.4-1 will be ready to upload as soon as I've finished updating the
README, run the cygport packaging step, and test-installed the packages.
Did you miss this:
http://cygwin.com/ml/cygwin-apps/2009-08/msg00046.html
Corinna Vinschen wrote:
If 4.3.4-2 comes really, *really* soon, then it's ok.
Yep, you see how limited the to-do list is in the announcement post; I'm not
going to extend that any unless something critical turns up in the next 48-72
hours.
cheers,
DaveK
Chris Sutcliffe wrote:
After 4.3.4-2 is out, any chance we can work on getting a mingw cross
compiler out so that we can put -mno-cygwin out of it's misery?
Yes, now the compiler is stable that can be the next big thing I get on with.
cheers,
DaveK
Corinna Vinschen wrote:
Does the new gcc version now set the TSAWARE flag by default? That
would be quite important, so that at leats new applications run on a
Terminal Server right from the start. Especially bash is an important
candidate.
Arrgh. No, it doesn't. Blast, knew I was
Dave Korn wrote:
4.3.4-1 will be ready to upload as soon as I've finished updating the
README, run the cygport packaging step, and test-installed the packages.
Glad I did that. It doesn't work on 1.5, owing to it having detected the
availability of stpcpy() in 1.7 and linked against
Evening all,
4.3.4-1 will be ready to upload as soon as I've finished updating the
README, run the cygport packaging step, and test-installed the packages.
With this release, I'm planning to throw the switch that makes gcc-4 now the
default system compiler. This is a last call in case
Charles Wilson wrote:
Dave Korn wrote:
With this release, I'm planning to throw the switch that makes gcc-4 now
the
default system compiler. This is a last call in case anyone thinks there is
any reason not to do so, such as anything that isn't working right or
anything
I've forgotten
Christopher Faylor wrote:
People have complained about the final setup.exe page which asks about
creating an icon, etc. What's the best way to stop that page from
showing up every time you run setup.exe? Should it only be asked on the
very first installation (easy) or should there be a Don't
Hi gang,
There are a couple of places where setup can bomb if you blow away your
stored settings (cached mirror list or last mirror), as it gets a null pointer
on trying to read them back; both strtok and the std::string(const char *)
ctor blow up on this. Attached patch trivially
Something I noticed while answering a post on the main list this morning.
http://sourceware.org/cygwin-apps/package-server.html still refers to the
old mirrors.txt file, which is no longer extant. This patch updates it to
refer to the canonical mirrors.lst file instead.
*
Eric Blake wrote:
According to Dave Korn on 9/2/2009 10:07 PM:
If we turn on SSE in the distro, we block anyone using Pentium2 or early
(pre-XP) Athlon CPUs from using Cygwin. I think that might be a step too
far.
Recent glibc has started providing function overloads, where the library
Brian Ford wrote:
On Wed, 2 Sep 2009, Marco Atzeri wrote:
I have no clue if -march=pentium4 is acceptable for AMD cpu's.
FWIW, we have been using -march=pentium4 -mfpmath=sse successfully in a
very large software project since November 2003 without incident. We have
run on AMD Opterons
Corinna Vinschen wrote:
On Aug 24 11:20, Yaakov S wrote:
On 24/08/2009 06:22, Corinna Vinschen wrote:
If it's a prerequisite for GNOME, just go ahead.
Thank you. How should I proceed with my other prereqs?
Same procedure as every year, James(*).
Try to take over the world?
cheers,
Hi gang, and Chuck in particular,
Ralf Wildenhues wrote:
Hello everyone,
I will reply to this message with a number of patches that contain the
heart of the switch to newer autotools.
Ralf's posting patches to get GCC and /src switched over to new autotools.
Do you have some spare
Yaakov (Cygwin/X) wrote:
On 13/08/2009 09:56, Dave Korn wrote:
Heh, yes. I was nearly done with building 4.3.3-1 and just needed to give
it some testing when they release 4.3.4, so I'll spin that one instead.
I've been ever so busy trying to get patches into upstream GCC before the
end
Yaakov (Cygwin/X) wrote:
On 14/08/2009 08:13, Dave Korn wrote:
Dunno. Which installed .la files are you referring to?
Since libtool now treats the GCC libraries (except libgcc) like any
other libtoolized library, meaning that, e.g. the full path to
libstdc++.la is included
Ralph Hempel wrote:
Nathan Thern wrote:
And me! I use the command-line options. Furthermore, they're really,
really important to me; so important you could, like, count me as two
people. That would make SIX people in the world that use the
command-line options to setup.exe.
OK, a little
Chris Sutcliffe wrote:
I believe I've addressed all the outstanding issues. I've uploaded
new versions of the files:
---
wget http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.34-1.tar.bz2 \
http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.34-1-src.tar.bz2 \
Christopher Faylor wrote:
On Tue, Jul 28, 2009 at 11:38:32AM -0400, Chris Sutcliffe wrote:
?GTG, and I was just about to upload it, when I realised:
I'm not sure if this needs a vote or not, since it is included in Debian:
http://packages.debian.org/unstable/main/cppcheck
?Argh. ?Unstable
Dave Korn wrote:
Christopher Faylor wrote:
On Tue, Jul 28, 2009 at 11:38:32AM -0400, Chris Sutcliffe wrote:
It's status is 'Approved' but creation date states 'Not yet
implemented' so I don't know what that means.
It means that we don't have to go through the vote. Let's just go ahead
Christopher Faylor wrote:
I've been talking about changing the format of setup.hint files to use
a real markup language. Maybe this would be the time to do that.
Seems a bit overkill for this particular job to me. I was thinking of
something more along these lines (for the pre-chooser
Hi gang,
setup/ChangeLog:
* README: Updated configure options with precise GCC version to use,
and add CC_FOR_BUILD (needed by libgpg-error).
Makes sense to everyone? (CC_FOR_BUILD defaults to just 'cc' if you don't
set it; it's utterly non-critical which version of GCC
Eric Blake wrote:
According to Dave Korn on 7/22/2009 2:34 PM:
Makes sense to everyone? (CC_FOR_BUILD defaults to just 'cc' if you don't
set it; it's utterly non-critical which version of GCC is used, however, so I
didn't bother to add a version suffix to that one.)
+ --build=i686
Christopher Faylor wrote:
Please let me know (via cygwin-apps of course) if there are problems
with this code. It's a pretty big rewrite so I could have easily gotten
something wrong.
Quick smoke-test passes here. Gotta go out soon so will test more later.
Might be nice to keep a
Corinna Vinschen wrote:
On Jul 1 09:01, Dean Scarff wrote:
Upstream release.
Built for cygwin 1.7.
There are a couple of relevant packaging conventions that I've noticed
discussed on this list and in practice that contradict
http://cygwin.com/setup.html yet haven't had an official
Corinna Vinschen wrote:
Can you add debug code which checks the return code of the
CoInitializeEx call in main.cc line 164? Maybe that's already going
wrong.
Unfortunately no. Happy return code zero. I'm a security dork, so I
wondered if maybe something I've disabled was breaking it, so
Federico Hernandez wrote:
A new package task-1.7.1-1 is ready for upload after getting a GTG
from Dave Korn (THX for all the help, BTW).
Ping? I could upload this myself, but I figured it's better when someone
other than the reviewer gives it a cursory glance over in the course of
uploading
Corinna Vinschen wrote:
On Jul 1 17:04, Dave Korn wrote:
Federico Hernandez wrote:
A new package task-1.7.1-1 is ready for upload after getting a GTG
from Dave Korn (THX for all the help, BTW).
Ping? I could upload this myself, but I figured it's better when someone
other than
So I uploaded the 1.5 version of task and it of course appeared in release-2
as well. Since we don't actually want to jump the gun, I've rm'd the
release-2 versions, but it's possible they might have made it to some of the
mirrors.
Frederico, when we get the 1.7 version ready, you may need
Dave Korn wrote:
So I uploaded the 1.5 version of task and it of course appeared in release-2
as well. Since we don't actually want to jump the gun, I've rm'd the
release-2 versions, but it's possible they might have made it to some of the
mirrors.
Arg, that's made it worse. rm'ing
Dave Korn wrote:
Dave Korn wrote:
So I uploaded the 1.5 version of task and it of course appeared in
release-2
as well. Since we don't actually want to jump the gun, I've rm'd the
release-2 versions, but it's possible they might have made it to some of the
mirrors.
Arg, that's made
Christopher Faylor wrote:
Under the assumption that there is supposed to be no version of task in
1.7, I've removed the directory (again) and confirmed that setup-2.ini
has no downloadable package available.
Thanks.
However, I don't really
understand why the 1.5 version of task won't
KARR, DAVID (ATTCINW) wrote:
It chugged for a bit, last
displaying Uninstalling emacs-el, then reported setup.exe has
encountered After dismissing the dialog, I looked at /etc/setup
again, and the corrupted emacs-el.lst.gz was there again.
I'm sending this here just to remind us
Christopher Faylor wrote:
On Wed, Jul 01, 2009 at 08:51:34PM +0100, Dave Korn wrote:
Christopher Faylor wrote:
However, I don't really understand why the 1.5 version of task won't
work on 1.7. Having a newer version of something in 1.5 sounds like a
nice recipe for confusion when 1.7 goes
Christopher Faylor wrote:
I've already got a basic method set up to allow individuals access to
their packages based on an ssh key.
This is a really good thing, it helps close the chain of trust.
cheers,
DaveK
Warren Young wrote:
If contributors get some sort of basic ssh access as well as scp, they
can just manage their own .ssh/authorized_keys file.
sourceware.org has a ton of automated script access for key management.
cheers,
DaveK
Christopher Faylor wrote:
Could you make sure that this is properly indented?
I changed the indentation and the whole patch stopped working! :-O
Heh, actually no. I found there's another code path there somewhere that
has the same problem. The patch works fine unless you enter some text
Federico Hernandez wrote:
Apart from the fixed packages of task fro cygwin-1.5 I have now also
uploaded packages for cygwin-1.7.
So you can find the packages for the review and upload under
cygwin-1.5)
http://taskwarrior.org/download/cygwin/setup.hint
Looks fine.
Dave Korn wrote:
Federico Hernandez wrote:
cygwin-1.7)
http://taskwarrior.org/download/cygwin/1.7/setup.hint
http://taskwarrior.org/download/cygwin/1.7/task-1.7.1-1-src.tar.bz2
http://taskwarrior.org/download/cygwin/1.7/task-1.7.1-1.tar.bz2
Urrgh. I see you noticed a problem
Federico Hernandez wrote:
Great news about the task package for 1.5. As you have mentioned that
it is GTG - will you upload it then and when. I just ask so that the
upstream prpject could inform users about this.
http://cygwin.com/setup.html#submitting
The normal procedure (see Package
Dave Korn wrote:
I'll try a build using autoconf-2.61 instead of -2.63 and see if that makes
any difference.
ROFL. I tried it with autoconf-2.59 and got this error:
Compiling task-1.7.1-1
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf
Dave Korn wrote:
Perhaps there's actually a problem with task's makefiles or configury not
understanding --docdir=/usr/share/doc/task correctly?
This is task-1.7.1/Makefile.am:
SUBDIRS = src
EXTRA_DIST = task_completion.sh doc/man1/task.1 doc/man5/taskrc.5
man1_MANS = doc/man1/task.1
Dave Korn wrote:
Perhaps there's actually a problem with task's makefiles or configury not
understanding --docdir=/usr/share/doc/task correctly?
This is task-1.7.1/Makefile.am:
SUBDIRS = src
EXTRA_DIST = task_completion.sh doc/man1/task.1 doc/man5/taskrc.5
man1_MANS = doc/man1/task.1
Dave Korn wrote:
[ a duplicate post]
Oops. Sorry for the dup everybody. I blame it on Thunderbird's somewhat
confused status-reporting:
http://img188.imageshack.us/img188/5273/messagesuccessfullyfail.png
cheers,
DaveK
Federico Hernandez wrote:
I think you should replace to do list by to-do list or maybe TO-DO
list throughout :-)
You know, I/we had the capitalized TO-DO version first. And while
submitting it to Ubuntu/Debian then encouraged us to change it to to
do. So I guess there are endless ways of
Andrew Schulman wrote:
So, if there's no compelling reason to keep the search case-sensitive, I
will change it to case-insensitive.
Yes, please.
Seconded. Entirely sensible.
cheers,
DaveK
Mark Harig wrote:
1. Start setup-1.7.exe. Click on 'Next ' button until the
'Select Packages' dialog window is displayed.
2. By default, setup displays the Select Packages window
maximized. Click on the 'Restore Down' button in the
right-hand corner to reduce the size of the
Christopher Faylor wrote:
Yes. Thanks for doing this. I hate working with this rc stuff. I used
to use Visual C++ to lay out the dialogs but, somewhere along the line,
my installation bit-rotted.
Well, adding those #defines is probably the final kiss of death for ever
being able to edit
101 - 200 of 528 matches
Mail list logo
