Re: [ITA] protobuf

> On 15/06/2017 20:53, Achim Gratz wrote: > > > > The protobuf package is orphaned by Reini Urban and hasn't been updated > > in quite a while. The package currently provides version 2.5.0 and API > > version 8, while the current upstream is at version 3.3.1 and API > > version 13. > > all your.

Re: 'cygport dep' is empty for orpie

> > > orpie builds and runs fine. But surprisingly, 'cygport dep' comes back > > > empty: > > > > > > $ cygport orpie.cygport dep > > > $ For the archive, this bug is fixed in cygport 0.24.1.

Re: adopt and update libatomic_ops and libgc

> I added libatomic_ops and libgc to your package list. Gold stars awarded! https://cygwin.com/goldstars/#AL

Re: 'cygport dep' is empty for orpie

> On 2017-05-10 07:03, Andrew Schulman wrote: > > $ cygport orpie.cygport finish all > > ... > >>>> orpie requires: > > $ cygport orpie.cygport dep > > $ grep requires: orpie-1.5.2-3.x86_64/dist/orpie/orpie-1.5.2-3.hint > > requires: > > >

Re: 'cygport dep' is empty for orpie

> > orpie builds and runs fine. But surprisingly, 'cygport dep' comes back > > empty: > > > > $ cygport orpie.cygport dep > > $ > > WFM: > > >>> Packaging orpie-1.5.2-3.x86_64 > >>> Creating binary package(s) > >>> orpie-1.5.2-3.tar.xz > [snip] > >>> Checking packages for missing or

Re: [PATCH cygport 2/3] Don't allow SRC_URI or PATCH_URI to depend on ARCH

> On 02/05/2017 14:31, Andrew Schulman wrote: > >> The values which SRC_URI and PATCH_URI evaluate to should not change > >> depending on ARCH, as this will make the source package arch-dependent > > > > In that case what's the right thing to do when we have arch-

Re: [PATCH cygport 3/3] Update documentation of all and almostall

> 'all of the above' is no longer accurate since the addition of upload etc. In fact, all and almostall are identical. Neither includes finish. See line 627 of /usr/bin/cygport. Both are misnamed IMO since they exclude get and upload.

Re: [PATCH cygport 2/3] Don't allow SRC_URI or PATCH_URI to depend on ARCH

> The values which SRC_URI and PATCH_URI evaluate to should not change > depending on ARCH, as this will make the source package arch-dependent In that case what's the right thing to do when we have arch-specific patches? For example screen has one, for x86_64 only.

Re: [ITA] units

> On 2017-04-25 17:42, Brian Inglis wrote: > > As a long time user of Cygwin and units, both professionally and > > personally, I noticed a new release of units 2.14 was available > > but the package is orphaned. > > I have been nominally maintaining it anyway, but you're welcome to take it.

'cygport dep' is empty for orpie

I'm building orpie 1.5.2 with cygport 0.24.0 and ocaml 4.04.0. cygport script is below. orpie builds and runs fine. But surprisingly, 'cygport dep' comes back empty: $ cygport orpie.cygport dep $ even though /usr/bin/orpie depends on libgsl19, libncursesw10, and libblas0: $ ldd

Re: unison-2.48 build fails with latest ocaml and flexdll (attn: Achim)

> > Then I got a different build error, but > > I'll ask on the unison list about that. > > Is 2.49 a stable version? It seems neither Fedora nor Debian have > packaged it. Hm, you're right. I thought it was the latest beta release, but that's 2.48. Anyway, no need to worry about it here. >

Re: unison-2.48 build fails with latest ocaml and flexdll (ping: Yaakov, Damien)

> On 2017-02-24 12:15, Andrew Schulman wrote: > > So to follow up on this old thread: The commands to make ocaml work again > > in x86_64 are > > > > rebase -b 0x0644 /usr/lib/ocaml/stublibs/dllunix.so > > rebase -b 0x0651 /usr/lib/ocaml/stublibs/dll

Re: [HHITP] mailutils 3.2

> This is a half-hearted ITP for GNU mailutils > (https://www.gnu.org/software/mailutils/mailutils.html). https://cygwin.com/acronyms/#HHITP

Re: are curr: and test: no longer accepted in .hint files?

> > > What's the supported way now to tell calm which versions are previous, > > > current, and test when you need to override the defaults? > > > > I'm assuming you have a recent cygport, which is now generating > > .hint rather than setup.hint files. > > > > It's not helpful to mention

Re: are curr: and test: no longer accepted in .hint files?

> > What's the supported way now to tell calm which versions are previous, > > current, and test when you need to override the defaults? > > I'm assuming you have a recent cygport, which is now generating > .hint rather than setup.hint files. > > It's not helpful to mention specific versions in

Re: are curr: and test: no longer accepted in .hint files?

> On 2017-03-24 11:18, Andrew Schulman wrote: > > I tried adding > > > > curr: 1.7.3.2-1 > > test: 2.0.0-b9-1 > ^ > Hyphens aren't allowed in versions, it messes up the sorting. This > needs to be VERSION=2.0.0; RELEASE=0.1.b9; then the next

Re: unison-2.48 build fails with latest ocaml and flexdll (ping: Yaakov, Damien)

> > A bald xpdf run failed with... > > Cygwin runtime failure: /usr/bin/xpdf.exe: Invalid relocation. Offset > > 0x2fb02bad9 at address 0x100494523 doesn't fit into 32 bits > > I rebased /usr/bin/cygXt-6.dll from 0x0003fb48 down to 0xfb48, > > i.e. > > just turn the first 3 in the

Re: fish 2.5.0-1?

> I have a vague recollection that I might have put the override.hint file > there to work around some other problem (keeping 2.3.1-2 rather than > 2.4b1-1 as prev:?), if that's the case, apologies for the confusion. Yeah, probably. No problem, thanks for the help. Andrew

Re: fish 2.5.0-1?

> On 07/02/2017 16:51, Marco Atzeri wrote: > > On 07/02/2017 17:49, Andrew Schulman wrote: > >> I uploaded fish 2.5.0-1 for x86 and x86_64 on Sunday, Feb. 5. I got a > >> confirmation notice from calm around noon EST. But it hasn't shown up in > >> any of the m

fish 2.5.0-1?

I uploaded fish 2.5.0-1 for x86 and x86_64 on Sunday, Feb. 5. I got a confirmation notice from calm around noon EST. But it hasn't shown up in any of the mirrors yet (at least, the 3 I looked at). Is there just a delay, or some problem that needs to be resolved? Thanks, Andrew

Re: [SECURITY] please withdraw screen 4.5.0 from the Cygwin archives

> On 25/01/2017 13:21, Andrew Schulman wrote: > > Can someone please remove screen 4.5.0-1 from the archive? > > For future reference, you can do this yourself, see [1] > > [1] https://cygwin.com/package-upload.html#deleting If I do that, will the previous release automati

Re: [SECURITY] please withdraw screen 4.5.0 from the Cygwin archives

> On 25/01/2017 13:21, Andrew Schulman wrote: > > Can someone please remove screen 4.5.0-1 from the archive? > > For future reference, you can do this yourself, see [1] > > [1] https://cygwin.com/package-upload.html#deleting Cool, thanks. I hadn't seen that.

[SECURITY] please withdraw screen 4.5.0 from the Cygwin archives

Can someone please remove screen 4.5.0-1 from the archive? screen 4.5.0 has at least one serious security problem [1], and maybe some other bugs too. I doubt Cygwin is affected, since screen doesn't rely on root privileges there. But 4.5.0 is only a minor update and a fix isn't going to be

Re: lftp 4.7.4 build fails with bad gettext version

> On 11/16/2016 1:36 PM, Andrew Schulman wrote: > > Using cygport with no custom src_build function and > > CYGCONF_ARGS="--with-openssl --enable-packager-mode", the build fails with > > a mysterious message about a mismatched gettext version: > > > > A

lftp 4.7.4 build fails with bad gettext version

Using cygport with no custom src_build function and CYGCONF_ARGS="--with-openssl --enable-packager-mode", the build fails with a mysterious message about a mismatched gettext version: ASchulma@LZ77E1AASCHULMA ~/d/c/lftp> cygport lftp.cygport build >>> Compiling lftp-4.7.4-1.x86_64

Re: libargp inconsistent packaging

> On 16/09/2016 11:15, Andrew Schulman wrote: > >> Andrew Schulman writes: > >>> Hi Marco. I think I thought about this in the past, but because the total > >>> size of this package is so small, I decided it wasn't worth the trouble to > >>> split

Re: libargp inconsistent packaging

> Andrew Schulman writes: > > Hi Marco. I think I thought about this in the past, but because the total > > size of this package is so small, I decided it wasn't worth the trouble to > > split it in two. I think that both packages would have to include the doc > > files

Re: libargp inconsistent packaging

> Andrew, > > should be better to create a separate package > libargp-devel for the development portion ? > > > $ cygcheck -l libargp > /usr/bin/cygargp-0.dll > /usr/include/argp.h > /usr/lib/libargp.dll.a > /usr/share/doc/Cygwin/libargp.README > /usr/share/doc/libargp/COPYING >

Re: fish curr and prev are reversed

> On 31/05/2016 09:32, Andrew Schulman wrote: > > RIght now for fish, version 2.3b1-1 is current and 2.3.0-1 is prev. This is > > the > > opposite of what I intended. I expected 2.3b1 to sort before 2.3.0. > > > > AFAIK the last setup.hint that I uploaded didn't

Re: fish curr and prev are reversed

> On May 31 10:46, Achim Gratz wrote: > > Corinna Vinschen writes: > > > I added > > > > > > prev: 2.3.0-1 > > > curr: 2.3b1-1 > > > > > > to all setup.hint files. > > > > That's what calm already does (it sees 2.3b1 like 2.3.1, IIRC). Andrew > > wanted the beta

fish curr and prev are reversed

RIght now for fish, version 2.3b1-1 is current and 2.3.0-1 is prev. This is the opposite of what I intended. I expected 2.3b1 to sort before 2.3.0. AFAIK the last setup.hint that I uploaded didn't include curr: or prev: lines, so this looks to be what calm decided to do. Can someone please fix

Re: [ITA] flex-2.6.1

> On May 19 14:18, Marco Atzeri wrote: > > Built last version with cygport > > > > New HOMEPAGE > >https://github.com/westes/flex/ > > > > to download (remove the index.html's) : > > > > wget -r -np -nH --cut-dirs=0 \ > > http://matzeri.altervista.org/x86/flex/index.html > > wget -r -np -nH

Re: Building from source packages

> * a few packages mistakenly use DEPENDS > > A few packages mistakenly use DEPENDS rather than DEPEND, which is > silently ignored I'm surprised none of them are mine. It confuses me every time that I have to use REQUIRES, but DEPEND instead of DEPENDS. I have to go look it up again once or

Re: [RFC] /etc/shells management (fish, mksh, posh, tcsh, zsh)

> On 2016-05-11 14:06, Yaakov Selkowitz wrote: > > On 2016-05-11 12:09, Andrew Schulman wrote: > >>> Am 10.05.2016 um 20:19 schrieb Andrew Schulman: > >>>> Achim, can you please add /bin/fish and /usr/bin/fish to /etc/shells in > >>>> base-file

pcre2?

fish 2.3 is currently bundling and building its own copy of libpcre2. There's an issue[1] open to unbundle it and use distributions' own versions, but libpcre2 hasn't been packaged for Cygwin yet. Yaakov, are you interested in packaging and maintaining pcre2? It builds fine OOTB for me, and it

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

Thanks for the headsup. > Once you have upgraded to cygport 0.22.0, maintainers MUST email a list > of their package(s) which qualify as noarch AND are already marked > ARCH=noarch or will be with the next release. atool discus stow

Re: Dedup x86/x86_64 --> noarch

> Andrew Schulman writes: > > I feel as though I've once again missed some important discussion about > > package > > maintenance. Your question implies that we can now upload packages with > > arch > > "noarch". Is that true? > > Mean

Re: Dedup x86/x86_64 --> noarch

> After a discussion on IRC about de-duping the noarch content out of > package files (where I was told this would be too difficult), I've just > tried what would happen for two of my packages, maxima and perl. I feel as though I've once again missed some important discussion about package

Re: [ITP] unison2.49

> Andrew Schulman writes: > > I've built and uploaded packages for the next version of unison, unison2.49. > > Please add unison2.49 to the package list with me as maintainer. > > Sorry, but why do you need to make the version part of the package name? > Could you name

[ITP] unison2.49

I've built and uploaded packages for the next version of unison, unison2.49. Please add unison2.49 to the package list with me as maintainer. Thanks, Andrew.

Re: unison-2.48 build fails with latest ocaml and flexdll (ping: Yaakov, Damien)

> A bald xpdf run failed with... > Cygwin runtime failure: /usr/bin/xpdf.exe: Invalid relocation. Offset > 0x2fb02bad9 at address 0x100494523 doesn't fit into 32 bits > I rebased /usr/bin/cygXt-6.dll from 0x0003fb48 down to 0xfb48, > i.e. > just turn the first 3 in the address to

Re: unison-2.48 build fails with latest ocaml and flexdll (ping: Yaakov, Damien)

> Andrew Schulman writes: > >> I'm trying to build unison 2.48.3, which worked fine the last time I tried > >> it, in June 2015. Today the build fails, with "flexdll error: cannot > >> relocate": > >> > >> >>> Compiling uniso

Re: unison-2.48 build fails with latest ocaml and flexdll (ping: Yaakov, Damien)

> I'm trying to build unison 2.48.3, which worked fine the last time I tried > it, in June 2015. Today the build fails, with "flexdll error: cannot > relocate": > > >>> Compiling unison2.48-2.48.3-2.x86_64 > ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml > File "mkProjectInfo.ml",

unison-2.48 build fails with latest ocaml and flexdll

I'm trying to build unison 2.48.3, which worked fine the last time I tried it, in June 2015. Today the build fails, with "flexdll error: cannot relocate": >>> Compiling unison2.48-2.48.3-2.x86_64 ocamlc -o mkProjectInfo unix.cma str.cma mkProjectInfo.ml File "mkProjectInfo.ml", line 1: Error:

Re: [HEADSUP] cygwin htdocs moved from CVS to git

> On Apr 8 05:42, Andrew Schulman wrote: > > > I just did this, but the docs haven't been updated online. Is another step > > > needed to update the working directory on sourceware from the repository? > > > > Sorry, nevermind. > > Nevermind? Uh, yes. Ne

Re: [ITA] ? xgraph-12.1-4

> On 2016-04-02 10:34, Marco Atzeri wrote: > > As Jari seems a reluctant maintainer > > https://cygwin.com/ml/cygwin-apps/2014-06/msg00046.html > > > > I rebuilt xgraph with latest debian patches using cygport. > > > > It solves the 64 bit segfault reported on: > >

Re: [HEADSUP] cygwin htdocs moved from CVS to git

> I just did this, but the docs haven't been updated online. Is another step > needed to update the working directory on sourceware from the repository? Sorry, nevermind.

Re: [HEADSUP] cygwin htdocs moved from CVS to git

> The htdocs repo is now accessible via gitweb: > https://sourceware.org/git/gitweb.cgi?p=cygwin-htdocs.git > > Write access is via ssh, as usual, e.g. > > $ git clone ssh://sourceware.org/git/cygwin-htdocs.git > [...] > $ cd cygwin-htdocs > $ [edit, edit, edit] > $ git commit -a > $

Re: [ITA] wtf-0.0.4-8

> Hi Andrew, > > On Mar 18 11:59, Andrew Schulman wrote: > You forgot your own, see > https://cygwin.com/ml/cygwin-apps/2016-03/msg00054.html Uh, no, I didn't forget! Thanks, but I don't need one. I was just kidding about the script and all. I have fun keeping the gold star

Re: Test via Gmane

> "Am I on?" > (Janis Joplin) > > > Regards, > Aschim. Cool. And it only took about 10 years! Andrew

Re: [ITA] wtf-0.0.4-8

> On Mar 18 10:44, Marco Atzeri wrote: > > to download (remove the index.html's) : > > > > wget -r -np -nH --cut-dirs=0 \ > > http://matzeri.altervista.org/x86/wtf/index.html > > wget -r -np -nH --cut-dirs=0 \ > > http://matzeri.altervista.org/wtf/GraphicsMagick/index.html > > > > find x86

Re: [PLUSH HIPPO and GOLDSTAR] Re: Keep calm

> > >Many problematic usages which were silently ignored, or permitted and > > >required manual intervention to fix, are now reported. > > > > I honestly never thought we would get off of upset. This is incredible, > > thank you! > > > > Corinna, certainly this deserves more than just a gold

Re: Separate packages for completion scripts?

> Seeking opinions from other package maintainers: is it desirable to have > Bash (et al.) completion scripts as part of the main package they're > associated with, or should they be packaged separately? It seems simpler and completely reasonable to me to include the completion scripts as part of

Re: [ITA] astyle

> On 2016-02-23 09:04, Chris Sutcliffe wrote: > > I would like to adopt astyle as it is currently orphaned. > > > > I have built and packaged the latest (2.05.1) release based on the > > last release (2.04) that I packaged. I'm happy to have someone review > > the packaging if anyone is

Re: Removing cygwin32-*, cygwin64-*

> Is anyone using the cygwin32- and/or cygwin64-* cross-compiling > toolchain for anything besides cross-building cygwin itself? I would > like to remove most of these from the distro if at all possible. FWIW, I've tried to cross-compile some of my packages between i386 and x86_64, and it's

Re: [GOLDSTAR] Re: [PATCH setup 0/3] Setup replacement for incver_ifdep

> On Jan 28 19:06, Achim Gratz wrote: > > Jon Turney writes: > > >>> You could read the md5sums into variables instead and just compare the > > >>> resulting strings within bash. Otherwise we'd have to add diffutils to > > >>> the Base category. > > > > > > I've made this change. > > > > Thank

Re: Obsolete dependency report, 2015-Oct-15

> sng[2] Andrew Schulman sng 1.1.0 is now out, and builds OOTB with libpng16. I'm uploading that today, so the dependency on libpng12 will be gone shortly.

Re: Obsolete dependency report, 2015-Oct-15

> > sng[2] Andrew Schulman > > sng 1.1.0 is now out, and builds OOTB with libpng16. I'm uploading that > today, so the dependency on libpng12 will be gone shortly. I mean libpng15.

Re: allowing gmane to post to cygwin-apps

> On Fri, 2015-09-11 at 14:04 -0400, Andrew Schulman wrote: > > > On Sep 1 19:26, Achim Gratz wrote: > > > > Corinna Vinschen writes: > > > > >> I'd say that mail through Gmane is still filtered on Sourceware. > > > > > > > >

Re: Cygport uploading different files to different arch directorys for noarch packages

> I'm seeing what seems to be some very odd behaviour from Cygport when > uploading noarch packages: Cygport uploads all the packages for the > 64-bit architecture, but only the main and source packages for 32-bit > architecture. Thanks for the troubleshooting and detailed report. This is just

Re: [ITA] cygutils

> On Oct 28 19:04, Andrew Schulman wrote: > > > >>>> Corinna is climbing down the vaults to polish goldstars... > > > >>> > > > >>> Awarded! http://cygwin.com/goldstars/#MG > > > >> > > > >> A bit early, thi

Re: [ITA] cygutils

> On Oct 27 20:51, Andrew Schulman wrote: > > > On Oct 26 12:50, Mark Geisert wrote: > > > > I understand that the cygutils package is orphaned. I'd like to take > > > > over > > > > maintenance of that package. Please excuse any stumbling ar

Re: [ITA] cygutils

> Corinna is climbing down the vaults to polish goldstars... > >>> > >>> Awarded! http://cygwin.com/goldstars/#MG > >> > >> A bit early, this one ;) > > > > Oops > > Want me to add a stinkbomb to offset, until he makes good? > > +1 motivational I have the new icon ready to go

Re: [ITA] cygutils

> On Oct 26 12:50, Mark Geisert wrote: > > I understand that the cygutils package is orphaned. I'd like to take over > > maintenance of that package. Please excuse any stumbling around the room as > > I get situated :) . > > > > ..mark > > Corinna is climbing down the vaults to polish

Re: [GOLDSTAR] Re: [PATCH setup 0/3] Setup replacement for incver_ifdep

> On Oct 12 14:16, Jon Turney wrote: > > On 22/09/2015 16:52, Jon Turney wrote: > > >(Further note: autodep is broken in upset. Many package which should have > > >a > > >dependency on _update-info-dir do not have one, and only 19 packages do, > > >so this > > >is not working as intended at the

cygport dep gives a ruby error

= '-sMRFeX -j10 -x4' LOCALAPPDATA = 'C:\Users\andrex\AppData\Local' LOGONSERVER = '\\TIN' MANPATH = '/home/andrex/usr/local/share/man:/usr/local/share/man:/usr/share/fish/man:/usr/share/man:/home/andrex/usr/all/private/share/man:/home/andrex/usr/all/share/man' NAME = 'Andrew Schulman

[ITP] par2

I want to package par2 for Cygwin. par2 is the well-known file verification and repair tool, using Reed-Solomon encoding. It builds OOTB in Cygwin. par2.cygport: NAME=par2 VERSION=0.6.14 RELEASE=1 SUMMARY="File verification and repair tool" DESCRIPTION="par2 is a program for creating and using

Re: allowing gmane to post to cygwin-apps

> On Sep 1 19:26, Achim Gratz wrote: > > Corinna Vinschen writes: > > >> I'd say that mail through Gmane is still filtered on Sourceware. > > > > > > I guess you're right. What we got a while back was to remove the > > > extra-aggressive filters on the cygwin mailing lists, so the spam > > >

Re: [ITA] dmalloc

> On Sep 4 11:57, Jon TURNEY wrote: > > > > Since dmalloc appears to be orphaned, but is occasionally useful, I'd like > > to adopt it. > > It's yours. Please go ahead. Gold star awarded: https://cygwin.com/goldstars/#JTy

Re: allowing gmane to post to cygwin-apps

> On Sep 1 19:26, Achim Gratz wrote: > > Corinna Vinschen writes: > > >> I'd say that mail through Gmane is still filtered on Sourceware. > > > > > > I guess you're right. What we got a while back was to remove the > > > extra-aggressive filters on the cygwin mailing lists, so the spam > > >

allowing gmane to post to cygwin-apps

After years of trying, I finally got the gmane admins to change the status of the gmane.os.cygwin.applications group from "unidirectional", where posting through gmane isn't allowed, to "non-public", which should allow gmane users to post to gmane.os.cygwin.applications and have their posts sent

upload just setup.hint?

I have a package in test, that I want to promote to current. If I just upload the revised setup.hint and !ready, is that enough? Or do I need to re-upload the package .tar.xz files too, and/or bump the version number?

Re: do package updates automatically kill running exes?

On 13/08/2015 20:02, Andrew Schulman wrote: Anyway, that answers my question. If I want to be sure a process from one of my packages exits, I need to put a killall into its preremove script. I've put a pkill . in all scripts that run setup (with the requisite are you sure? y/N

do package updates automatically kill running exes?

I've noticed that when I update a package, the exe's in it get killed. For example, when emacs gets updated, my running emacsen die. Is this something that setup explicitly does, for all packages? Or that some packages do for themselves in a preremove script? Or just a byproduct of replacing a

Re: do package updates automatically kill running exes?

On 13/08/2015 07:19, Andrew Schulman wrote: I've noticed that when I update a package, the exe's in it get killed. For example, when emacs gets updated, my running emacsen die. Is this something that setup explicitly does, for all packages? Or that some packages do for themselves

Re: do package updates automatically kill running exes?

Anyway, that answers my question. If I want to be sure a process from one of my packages exits, I need to put a killall into its preremove script. I've put a pkill . in all scripts that run setup (with the requisite are you sure? y/N). Ugh, both psmisc (killall) and procps (pkill)

Re: [ITA] gnucap

On 8/1/2015 8:29 PM, Achim Gratz wrote: I've rebuilt gnucap 2009-12-07 as release -4 for both architectures to get rid of another 32bit-only package. I do not intend to update the package to a later version since the current maintainers have ripped out autotools just after that release

Re: [ITA] md5deep

On 8/1/2015 8:25 PM, Achim Gratz wrote: I've updated the orphaned md5deep to the latest upstream version 4.4 and compiled for both architectures. That should take another 32bit-only package from the list. Regards, Achim. all your, I update cygwin-pkg-maint

Re: [HEADSUP] Perl update to 5.22.0

Achim Gratz writes: Andrew Schulman writes: Except for John. Sorry, John who? John Turney. Oh, sorry. That's Jon Turney of course. Awarded!

Re: [HEADSUP] Perl update to 5.22.0

With the invaluable help of Yaakov and John on the server side, the mass update of all things Perl is now complete. I would like to thank all maintainers for helping with re-releases of their packages. I don't know if that's my call to make, but I'd like to ask for a round of gold stars

Re: [Attn Maintainer] stow

None of this discussion should detract from the amazing job you've done in pulling this Perl update together. I hope you get several gold stars and/or plush hippos for all your work. Awarded! http://cygwin.com/goldstars/#AG

Re: [Attn Maintainer] stow

Andrew Schulman writes: OK. I missed that thread. For the next time there's a Perl update that requires action from us maintainers, it would help if you put a HEADSUP in the subject line. I've realized just in time that some maintainers don't read all of the cygwin-apps list or even

Re: [Attn Maintainer] stow

Andrew Schulman writes: The idea was that you install the pre-release Perl that was published specifically to facilitate this rebuild. Sorry, where is that? I looked in setup, and the newest test version there is 5.14.4-3. From the thread on the Perl update: OK. I missed

Re: [Attn Maintainer] stow

The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages contain sub-packages that need an update or re-release using Perl

Re: [Attn Maintainer] stow

I mean, seriously, this seems like a lot of dumb work to me. Sorry. OK. Again, not your fault and thanks for maintaining. Andrew

Re: [Attn Maintainer] stow

But okay, I'll rebuild it. So are you asking me to first wait until Perl 5.22 comes out, then rebuild the package and release it afterwards? Or to manually change where the files go, and release the update at the same time as Perl 5.22? The idea was that you install the

Re: [Attn Maintainer] stow

The update to Perl 5.22 is planned for the end of this week. Please notify immediately if you cannot provide the updated packages indicated below by then to your package upload area on cygwin.com. Your following packages contain sub-packages that need an update or re-release using Perl

Re: [ITP] perl-Stow

On 7/22/2015 3:10 PM, Andrew Schulman wrote: Please make me the maintainer of the new perl-Stow package, which is being split off from stow. Thanks, Andrew. Will you have a separate source package or not ? If the source package is the same you don't need a a separate line just

[ITP] perl-Stow

Please make me the maintainer of the new perl-Stow package, which is being split off from stow. Thanks, Andrew.

Re: [ADOPT] iperf 2.0.8

You are the new maintainer Congratulation. Gold star awarded! https://cygwin.com/goldstars/#JJ

Re: [PLUSH HIPPO] Re: [ITA] xdelta

Thanks for taking over YA orphaned, non-64 bit package, btw. This deserves a plush hippo. Andrew? Awarded! https://cygwin.com/goldstars/#MA

Re: upload not working of 32 bit dos2unix.

Hi, Yesterday I uploaded new versions of dos2unix, 32 and 64 bit. Today only the 64 bit version appeared in setup-x86.exe. lftp cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:/x86/release ls dos2unix/ drwxr-sr-x 3 cygwin cygstage 4096 Jul 3 18:10 . drwxrwsr-x 5 cygwin

Re: cygport SSH_KEY variable

According to the documentation of SSH_KEY, You'll need to set this if your private key isn't already loaded into a running ssh-agent(1), and it doesn't have one of the expected file names such as ~/.ssh/id_rsa. But I don't see in the source that cygport checks for one of the expected file

lablgtk2 (was: [ITP] unison2.48)

Right now, I'd like to at least take a look at what you have done so far. OK, pushed to https://github.com/andrex-e-schulman/cygwin-lablgtk2.git. I started with the version in Cygwin ports - the cygport file and two patches. I adjusted the cygport file as follows: * Added

Re: lablgtk2 (was: [ITP] unison2.48)

On Fri, 2015-06-12 at 03:54 -0400, Andrew Schulman wrote: OK, pushed to https://github.com/andrex-e-schulman/cygwin-lablgtk2.git. I started with the version in Cygwin ports - the cygport file and two patches. I adjusted the cygport file as follows: * Added ocaml_lablgtk2_REQUIRES

Re: lablgtk2 (was: [ITP] unison2.48)

OK. So IOW the only thing I probably did that helped was to add DEPEND (but gtkglarea2.0-devel shouldn't be in it). DEPEND= ocaml ocaml-compiler-libs libgtk2.0-devel libgtkgl2.0-devel libgtksourceview2.0-devel libglade2.0-devel librsvg2-devel libgnomeui2-devel

Re: [ITP] unison2.48

I will try to package unison2.48gtk when I get a chance; hopefully within the next few weeks. Thanks for offering to help. It seems a little odd to have different maintainers for the text and GUI versions of Unison, but I think it would be okay. Since I don't use the GUI myself, it would

[ITP] unison2.48

There's a new beta release of Unison, version 2.48. It's incompatible with the previous releases, so we need a new package for it, unison2.48. I have it built and ready to upload. Please add it to the Cygwin package maintainers list, with me as maintainer. Thanks, Andrew

Re: [ITP] unison2.48

On Fri, 2015-06-05 at 12:06 -0400, Andrew Schulman wrote: There's a new beta release of Unison, version 2.48. It's incompatible with the previous releases, so we need a new package for it, unison2.48. I have it built and ready to upload. Please add it to the Cygwin package

Re: [ITP] unison2.48

On Fri, 2015-06-05 at 16:16 -0400, Andrew Schulman wrote: On Fri, 2015-06-05 at 12:06 -0400, Andrew Schulman wrote: BTW do you have any plans to build the GTK GUI versions? Not immediately. The last time I tried was several years ago, and there was some problem with lablgtk

<    1   2   3   4   5   6   7   >