[ITP] znc 1.6.0
Hi! I want to package ZNC. Package in distros: https://packages.gentoo.org/package/net-irc/znc https://packages.debian.org/search?keywords=znc http://packages.ubuntu.com/search?keywords=znc https://admin.fedoraproject.org/pkgdb/package/znc/ Also I have several questions: 1) cygport chose to make znc-python to depend on both python and python3, though I want it to depend only on python3. Is there some way to force not to depend on python? 2) I can setup CI, so that on every push to git master new package is pushed, marked as "test". Is it a good idea or not? znc.cygport NAME="znc" VERSION=1.6.0 RELEASE=1 HOMEPAGE="http://znc.in/"; SRC_URI="http://znc.in/releases/archive/znc-${VERSION}.tar.gz"; PKG_NAMES="znc znc-devel znc-perl znc-python" znc_SUMMARY="Advanced IRC bouncer" znc_DESCRIPTION="ZNC is an IRC network bouncer (BNC). It can detach the client from the actual IRC server, and also from selected channels. Multiple clients from different locations can connect to a single ZNC account simultaneously and therefore appear under the same nickname on IRC. It supports SSL secured connections and IPv6." znc_CONTENTS="usr" znc_CATEGORY="Net" znc_devel_SUMMARY="Modules development for ZNC" znc_devel_DESCRIPTION="This package contains tools to build ZNC modules written on C++." znc_devel_CONTENTS="usr/bin/znc-buildmod usr/include usr/lib/pkgconfig" znc_devel_CATEGORY="Net Devel" znc_devel_REQUIRES="znc openssl-devel libicu-devel gcc-g++" znc_perl_SUMMARY="Support for ZNC modules written on Perl" znc_perl_DESCRIPTION="This package contains Perl bindings for ZNC." znc_perl_CONTENTS="usr/lib/znc/modperl.so usr/lib/znc/modperl usr/lib/znc/*.pm" znc_perl_CATEGORY="Net Perl" znc_python_SUMMARY="Support for ZNC modules written on Python3" znc_python_DESCRIPTION="This package contains Python3 bindings for ZNC." znc_python_CONTENTS="usr/lib/znc/modpython.so usr/lib/znc/modpython" znc_python_CATEGORY="Net Python" for exclude in $znc_devel_CONTENTS $znc_perl_CONTENTS $znc_python_CONTENTS; do znc_CONTENTS="--exclude=$exclude $znc_CONTENTS" done # libcrypt-devel is here only because modperl refuses to compile without it DEPEND="zlib-devel openssl-devel libcrypt-devel libsasl2-devel libicu-devel gcc-g++ make pkg-config perl python3" CYGCONF_ARGS="--enable-zlib --enable-openssl --enable-cyrus --enable-charset --enable-perl --enable-python" inherit autotools znc/setup.hint -- category: Net requires: cygwin libgcc1 libicu55 libopenssl100 libsasl2_3 libstdc++6 zlib0 sdesc: "Advanced IRC bouncer" ldesc: "ZNC is an IRC network bouncer (BNC). It can detach the client from the actual IRC server, and also from selected channels. Multiple clients from different locations can connect to a single ZNC account simultaneously and therefore appear under the same nickname on IRC. It supports SSL secured connections and IPv6." -- znc/znc-devel/setup.hint -- category: Net Devel requires: bash znc openssl-devel libicu-devel gcc-g++ sdesc: "Modules development for ZNC" ldesc: "This package contains tools to build ZNC modules written on C++." external-source: znc -- znc/znc-perl/setup.hint -- category: Net Perl requires: cygwin libgcc1 libstdc++6 perl_base znc sdesc: "Support for ZNC modules written on Perl" ldesc: "This package contains Perl bindings for ZNC." external-source: znc --- znc/znc-python/setup.hint -- category: Net Python requires: cygwin libgcc1 libstdc++6 python python3 znc sdesc: "Support for ZNC modules written on Python3" ldesc: "This package contains Python3 bindings for ZNC." external-source: znc -- znc/znc-debuginfo/setup.hint - category: Debug requires: cygwin-debuginfo external-source: znc sdesc: "Debug info for znc" ldesc: "This package contains files necessary for debugging the znc package with gdb." --
Re: [ITP] znc 1.6.0
For some reason the mailing list swallows my messages, so I'm trying to remove cyrillic letters for "wrote"... 19.07.2015 00:07, Alexey Sokolov : > 18.07.2015 22:05, Alexey Sokolov : >> I've put files in the required directory structure to >> http://people.znc.in/~darthgandalf/znc/znc-cygwin/ >> >> 18.07.2015 16:47, Alexey Sokolov : >>> Hi! >>> >>> I want to package ZNC. >>> Package in distros: >>> https://packages.gentoo.org/package/net-irc/znc >>> https://packages.debian.org/search?keywords=znc >>> http://packages.ubuntu.com/search?keywords=znc >>> https://admin.fedoraproject.org/pkgdb/package/znc/ >>> >>> Also I have several questions: >>> 1) cygport chose to make znc-python to depend on both python and >>> python3, though I want it to depend only on python3. Is there some way >>> to force not to depend on python? > The answer to this is "inherit python3" (thanks jturney) > > >>> 2) I can setup CI, so that on every push to git master new package is >>> pushed, marked as "test". Is it a good idea or not? >>> >>> >>> znc.cygport >>> >>> NAME="znc" >>> VERSION=1.6.0 >>> RELEASE=1 >>> HOMEPAGE="http://znc.in/"; >>> SRC_URI="http://znc.in/releases/archive/znc-${VERSION}.tar.gz"; >>> PKG_NAMES="znc znc-devel znc-perl znc-python" >>> >>> znc_SUMMARY="Advanced IRC bouncer" >>> znc_DESCRIPTION="ZNC is an IRC network bouncer (BNC). It can detach >>> the client from the actual IRC server, and also from selected channels. >>> Multiple clients from different locations can connect to a single ZNC >>> account >>> simultaneously and therefore appear under the same nickname on IRC. >>> It supports SSL secured connections and IPv6." >>> znc_CONTENTS="usr" >>> znc_CATEGORY="Net" >>> >>> znc_devel_SUMMARY="Modules development for ZNC" >>> znc_devel_DESCRIPTION="This package contains tools to build ZNC modules >>> written on C++." >>> znc_devel_CONTENTS="usr/bin/znc-buildmod usr/include usr/lib/pkgconfig" >>> znc_devel_CATEGORY="Net Devel" >>> znc_devel_REQUIRES="znc openssl-devel libicu-devel gcc-g++" >>> >>> znc_perl_SUMMARY="Support for ZNC modules written on Perl" >>> znc_perl_DESCRIPTION="This package contains Perl bindings for ZNC." >>> znc_perl_CONTENTS="usr/lib/znc/modperl.so usr/lib/znc/modperl >>> usr/lib/znc/*.pm" >>> znc_perl_CATEGORY="Net Perl" >>> >>> znc_python_SUMMARY="Support for ZNC modules written on Python3" >>> znc_python_DESCRIPTION="This package contains Python3 bindings for ZNC." >>> znc_python_CONTENTS="usr/lib/znc/modpython.so usr/lib/znc/modpython" >>> znc_python_CATEGORY="Net Python" >>> >>> for exclude in $znc_devel_CONTENTS $znc_perl_CONTENTS >>> $znc_python_CONTENTS; do >>> znc_CONTENTS="--exclude=$exclude $znc_CONTENTS" >>> done >>> >>> # libcrypt-devel is here only because modperl refuses to compile without it >>> DEPEND="zlib-devel openssl-devel libcrypt-devel libsasl2-devel >>> libicu-devel gcc-g++ make pkg-config perl python3" >>> CYGCONF_ARGS="--enable-zlib --enable-openssl --enable-cyrus >>> --enable-charset --enable-perl --enable-python" >>> inherit autotools >>> >>> >>> znc/setup.hint >>> -- >>> category: Net >>> requires: cygwin libgcc1 libicu55 libopenssl100 libsasl2_3 libstdc++6 zlib0 >>> sdesc: "Advanced IRC bouncer" >>> ldesc: "ZNC is an IRC network bouncer (BNC). It can detach >>> the client from the actual IRC server, and also from selected channels. >>> Multiple clients from different locations can connect to a single ZNC >>> account >>> simultaneously and therefore appear under the same nickname on IRC. >>> It supports SSL secured connections and IPv6." >>> -- >>> >>> znc/znc-devel/setup.hint >>> -- >>> category: Net Devel >>> requires: bash znc openssl-devel libicu-devel gcc-g++ >>> sdesc: "Modules development for ZNC" >>> ldesc: "This package contains tools to build ZNC modules written on C++." >>> external-source: znc >>> -- >>> >>> znc/znc-perl/setup.hint >>> -- >>> category: Net Perl >>> requires: cygwin libgcc1 libstdc++6 perl_base znc >>> sdesc: "Support for ZNC modules written on Perl" >>> ldesc: "This package contains Perl bindings for ZNC." >>> external-source: znc >>> --- >>> >>> znc/znc-python/setup.hint >>> -- >>> category: Net Python >>> requires: cygwin libgcc1 libstdc++6 python python3 znc >>> sdesc: "Support for ZNC modules written on Python3" >>> ldesc: "This package contains Python3 bindings for ZNC." >>> external-source: znc >>> -- >>> >>> znc/znc-debuginfo/setup.hint >>> - >>> category: Debug >>> requires: cygwin-debuginfo >>> external-source: znc >>> sdesc: "Debug info for znc" >>> ldesc: "This package contains files necessary for debugging the >>> znc package with gdb." >>> -- >>>
SSH key for upload access
Name: Alexey Sokolov Package: znc BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAACAQDslTwsLkcs/oUhq6Vaz+8sRZI2I+4Jg4y7Z1HpZn u9Lcl4+q03WItXSJdhy87U9lqq3EqeRCNEGuAJ+yEEE+nEu0S2UUePm+UYlwmaFenupr0g FK8i/hHeyICqCIjeB6ylNkrKp69mkP6xRXAqxQ8JI4u/eqw+PQ50qKX29AXnuSJ3oiNa1d Lzm+9aiLV1+XmCf8/G+NPMrsgKOLLJaS+la1Yh9d0Nr1P9j68umBTmC17APUje7YKtcBmN eZ1pZLYeyk3CxcoRfLNZIhCRW8JH5HcX6lCsga2yXN3qOqmKkNpkcHf/Bc6Cok5QMaqTxS b6HyKmjeF5u8p6foAbhzT6xMcfvevaqX63qrD06lNJSVBiyMbIETt7e0FpItFVYOWpd0VG JUDYJTNOHhxYRz2SaugFYFWrXOYv9h8IF6sejhY7HZc+ss56hEpdeoMdAT+CsgtuNrCrAG DRt1TK7Ydb5d1bPq3X0tVM6c7yyah1qXru5+iG/kiRz3n6LxtTbSHr7qgC/20NYCg/7FRy xgQvyZAQymNFt8dF3IPpUY4Orr28ahiLznfimi+tcN6+wsj3rJEnyCDabLEdOK+Iba1wXE xZybSJLxyvlfBUwMUmNapNSTpzQb64aEH1OGBWihwfcNKSLoiW+GYbeJS1ON2hvHuknDgs 8umtUc9vLvkz/w== END SSH2 PUBLIC KEY
Re: [ITP] znc 1.6.0
Hi Corinna, 19.07.2015 11:03, Corinna Vinschen : > I think libznc.dll should be called libzncX.dll or cygzncX.dll, with X > being a version number. If there will ever be backward-incompatible > changes in the DLL, the version number should be bumped. Also, is there > a native Windows version of ZNC? If so, the name libznc.dll runs danger > of DLL collision. > Thanks, renamed it to cygznc-1.6.dll. There is a native version, but it's updated not very often, and it uses znc.dll, without "lib" prefix. > For uploading, please send the ssh key per > https://sourceware.org/cygwin-apps/package-upload.html > Done
Re: [ITP] znc 1.6.0
+mailing list back, sorry... > 19.07.2015 17:42, Achim Gratz : >> Alexey Sokolov writes: >>> Thanks, renamed it to cygznc-1.6.dll. >> You seem to have misunderstood. The name of the DLL should be something >> like >> >> cygznc1.dll >> >> where the number indicates the API version. > Is "1" some special number which should be used? > ZNC 1.6.0 is supposed to be ABI-compatible with ZNC 1.6.1 (when it will > be released), so third-party modules compiled against cygznc-1.6.dll > from 1.6.0 should work fine with cygznc-1.6.dll from 1.6.1 without > recompilation. > That's why I chose 1.6 as version number for the filename. > > Also, most of .dll files I see in /bin have "-" before the number, > that's why I've put it here too... > >
Re: [ITP] znc 1.6.0
19.07.2015 20:10, Achim Gratz пишет: > Alexey Sokolov writes: >>> Is "1" some special number which should be used? > > Just some number that gets bumped whenever the ABI changes > (i.e. applications that link against the library would need to be > recompiled). > Well, in that case 1.6 works fine. When 1.7.0 will be released, the filename will be changed to cygznc-1.7.dll. >>> ZNC 1.6.0 is supposed to be ABI-compatible with ZNC 1.6.1 (when it will >>> be released), so third-party modules compiled against cygznc-1.6.dll >>> from 1.6.0 should work fine with cygznc-1.6.dll from 1.6.1 without >>> recompilation. > > I've just looked at Debian and openSUSE and both do not have a ZNC > library? > On Linux the whole program is in /usr/bin/znc executable, and modules (opened via dlopen()) use symbols from it. But it's not possible on Windows, because linker requires all used symbols to be found at build time instead of runtime. So for Windows, most of code needed to be moved to a DLL, which both modules and (now small) znc.exe can link to. >>> That's why I chose 1.6 as version number for the filename. >>> >>> Also, most of .dll files I see in /bin have "-" before the number, >>> that's why I've put it here too... > > You ahould ask Yaakov, but I seem to remember that the preferred way to > name new libraries is now without the hyphen. > Hm, ok... Yaakov, what's the plan?
Re: [ITP] znc 1.6.0
>> Well, in that case 1.6 works fine. When 1.7.0 will be released, the >> filename will be changed to cygznc-1.7.dll. > > No, hang on. The reason for the version-independent number is to allow > keeping the number the same for multiple versions of the package, and > only bump it when an ABI breakage occurs. Consider this scenario with > different versioning schemes: > > znc 1.6 > > --> cygznc1.dll or cygznc-1.6.dll > > znc 1.7 introduces new function znc_foo. Adding functions is no ABI > breakage. > > --> cygznc1.dll or cygznc-1.6.dll > > znc 1.8 removes function znc_bar. ABI breakage; existing modules > using this functions wouldn't load anymore. > > --> cygznc2.dll or cygznc-1.8.dll > > znc 1.9 adds function znc_foobar and a new structure. No ABI breakage. > > --> cygznc2.dll or cygznc-1.8.dll > > znc 2.0 changes parameters to function znc_baz. ABI breakage since > existing modules using this function may crash. > > --> cygznc3.dll or cygznc-2.0.dll > > The first scheme is what most autoconf-based build systems use. > However, openssl, for instance, uses the second scheme. Both is ok, but > in both schemes the ABI version number attached to the DLL name does not > necessarily reflect the actual version number of the base package. Did > I explain it sufficiently? ZNC 1.6.0 --> cygznc-1.6.dll (or cygznc1.6.dll) ZNC 1.6.1 introduces new function znc_foo, no ABI breakage. --> cygznc-1.6.dll ZNC 1.6.2 introduces a new structure and a new function which uses it. No ABI breakage. --> cygznc-1.6.dll ZNC 1.7.0 adds new virtual function to an existing class. Even if API is not broken, ABI is broken. --> cygznc-1.7.dll ZNC 1.7.1 changes some implementation details, but doesn't break ABI. --> cygznc-1.7.dll ZNC 1.8.0 changes order of fields in some struct, breaks ABI. --> cygznc-1.8.dll Since upstream agrees to not break ABI between "patch" versions, I don't see a reason to make the DLL name to not reflect the actual version number. I think this scheme is also used in the package of ICU library (except that they don't guarantee ABI compatibility for C++). >>> You ahould ask Yaakov, but I seem to remember that the preferred way to >>> name new libraries is now without the hyphen. >> >> Hm, ok... >> Yaakov, what's the plan? > > Dunno about Yaakov, but what counts in the first place is to keep track > of the ABI change and only bump the ABI version attached to the DLL name > if a new version of the base package breaks it. The ABI version itself > is mostly maintained by the project's build system. I agree about not breaking ABI without changing the filename. This question was not directly related to ABI, however, but is about hyphen. For consistency with existing libraries, hyphen is needed, I think. But if the policy for new libraries to not use hyphen, I'm fine with that too.
Re: [ITP] znc 1.6.0
You ahould ask Yaakov, but I seem to remember that the preferred way to name new libraries is now without the hyphen. >>> Hm, ok... >>> Yaakov, what's the plan? >> Dunno about Yaakov, but what counts in the first place is to keep track >> of the ABI change and only bump the ABI version attached to the DLL name >> if a new version of the base package breaks it. The ABI version itself >> is mostly maintained by the project's build system. > I agree about not breaking ABI without changing the filename. This > question was not directly related to ABI, however, but is about hyphen. > For consistency with existing libraries, hyphen is needed, I think. But > if the policy for new libraries to not use hyphen, I'm fine with that too. Well, hyphen doesn't harm much anyway, so I'm releasing 1.6.0 now. If hyphen will need to be removed, I'll do it for 1.7.0. Achim and Corinna, thanks for advices!
Re: [ITP] znc 1.6.0
21.07.2015 08:12, Corinna Vinschen пишет: > On Jul 20 19:58, Alexey Sokolov wrote: >>>> Well, in that case 1.6 works fine. When 1.7.0 will be released, the >>>> filename will be changed to cygznc-1.7.dll. > > Assuming 1.7 does not break the ABI. Git master which will eventually become 1.7.0 already has ABI-breaking changes. > The problem here is that modules > built for 1.6 won't run on 1.7, even if the ABI hasn't changed, If it's not changed, it'll be released as 1.6.1 or 1.6.2, especially to not force users to recompile their modules.
Re: [ITP] znc 1.6.0
> I've had a busy day and I'm a little tired, so I'm probably about to > make a fool of myself on a public mailing list. Never mind :-) Three > points on the znc package: > > - Unless I've missed something, all this talk of DLL naming is a > little academic at the moment, as there is no 'dll.a' file to actually > link against. GCC links against .dll (or .so) fine. > - Has anyone tried building this in Cygwin? I tried rebuilding the > 1.6.0-2 release, and couldn't get it to compile without hacking the > 'Makefile.in' files. Even if you generate a 'dll.a', the linker > arguments are in the wrong order. This doesn't matter in Linux, but it > /does/ matter in Cygwin. Does this only build if cross-compiled out of > Fedora? I'm using https://github.com/znc/znc-cygwin to build it on Cygwin. > - Forgive me for being pedantic, but who gave this a GTG? I couldn't > find one on this thread, and yet the package is up on the mirrors. I thought if the package exists in popular distros, no GTG needed?
Re: [ITP] znc 1.6.0
22.07.2015 00:32, Alexey Sokolov пишет: >> I've had a busy day and I'm a little tired, so I'm probably about to >> make a fool of myself on a public mailing list. Never mind :-) Three >> points on the znc package: >> >> - Unless I've missed something, all this talk of DLL naming is a >> little academic at the moment, as there is no 'dll.a' file to actually >> link against. > GCC links against .dll (or .so) fine. > >> - Has anyone tried building this in Cygwin? I tried rebuilding the >> 1.6.0-2 release, and couldn't get it to compile without hacking the >> 'Makefile.in' files. Even if you generate a 'dll.a', the linker >> arguments are in the wrong order. This doesn't matter in Linux, but it >> /does/ matter in Cygwin. Does this only build if cross-compiled out of >> Fedora? > I'm using https://github.com/znc/znc-cygwin to build it on Cygwin. David, how did you try to build it? What was the exact error message? What do you change in Makefile.in to get it working? >> - Forgive me for being pedantic, but who gave this a GTG? I couldn't >> find one on this thread, and yet the package is up on the mirrors. > I thought if the package exists in popular distros, no GTG needed?
Re: [ITP] znc 1.6.0
22.07.2015 09:07, Corinna Vinschen: > On Jul 22 00:32, Alexey Sokolov wrote: >>> I've had a busy day and I'm a little tired, so I'm probably about to >>> make a fool of myself on a public mailing list. Never mind :-) Three >>> points on the znc package: >>> >>> - Unless I've missed something, all this talk of DLL naming is a >>> little academic at the moment, as there is no 'dll.a' file to actually >>> link against. >> >> GCC links against .dll (or .so) fine. > > Without the (non-versioned) .dll.a file in /usr/lib, using -lznc will > fail. This should be part of the -devel package. $ g++ -O2 -std=c++11 -U__STRICT_ANSI__ -D_FORTIFY_SOURCE=2 -include znc/zncconfig.h -L/bin -lznc-1.6 -shared -o alias.so alias.cpp This is roughly what znc-buildmod does when one runs "znc-buildmod alias.cpp", it's provided in the -devel package. And it works. (I've omitted several long flags from that command line, which are irrelevant for this discussion) The current packaged version uses '-L"/bin"' with quotes instead, I need to fix this. >>> - Has anyone tried building this in Cygwin? I tried rebuilding the >>> 1.6.0-2 release, and couldn't get it to compile without hacking the >>> 'Makefile.in' files. Even if you generate a 'dll.a', the linker >>> arguments are in the wrong order. This doesn't matter in Linux, but it >>> /does/ matter in Cygwin. Does this only build if cross-compiled out of >>> Fedora? >> >> I'm using https://github.com/znc/znc-cygwin to build it on Cygwin. >> >>> - Forgive me for being pedantic, but who gave this a GTG? I couldn't >>> find one on this thread, and yet the package is up on the mirrors. >> >> I thought if the package exists in popular distros, no GTG needed? > > Uhm, no. The *votes* are not required, the GTG is. > Oops. Sorry then!
Re: [ITP] znc 1.6.0
23.07.2015 00:03, David Stacey : > On 22/07/2015 00:53, Alexey Sokolov wrote: >> David, how did you try to build it? What was the exact error message? >> What do you change in Makefile.in to get it working? > > Attempting to compile znc-1.6.0-3 with cygport under Cygwin x86. It's > worth saying that my Cygwin installation is about a month old, but that > shouldn't matter. > > cygport ./znc.cygport prep compile > > Nothing out of the ordinary there. This gives the following error: > > configure.ac:255: Something is trying to use the C compiler. Since > this is a C++ project, this should not happen! > autom4te-2.69: /usr/bin/m4 failed with exit status: 1 > > So, for the sake of not falling at the first hurdle, I skipped the > autoreconf step by adding the following lines to znc.cygport: > > src_compile() { > cd ${B} > cygconf > cygmake -j 1 V=1 > } > > I'll leave it to you to have a more detailed poke around as to why > atoreconf is failing. Hm, I'm not sure why autoreconf would do this (works for me though), but autoreconf is not required for ZNC anyway, as release tarballs already have ./configure script. So, for protection against possible broken autoreconfs I'll add such src_compile to znc.cygport. > Anyway, with that in place we get a little > further. The first hint that anything is wrong comes when we try to link > the perl module: > > /usr/lib/gcc/i686-pc-cygwin/4.9.2/../../../../i686-pc-cygwin/bin/ld: > cannot find -lznc-1.6 > > That's because there's no 'libznc-1.6.dll.a' to link against. You need > to add the following to your link command when producing the shared DLL: > > -Wl,--out-implib=libznc-1.6.dll.a > > Again, I'll leave it to you to get this into the Makefile in a nice way. > I'd reiterate what others have said: This should be called libznc#.dll, > where '#' is a number that increments when the ABI breaks. This is our > naming convention; please adhere to it. You should add this 'dll.a' file > to your devel package. For the sake of changing as little of your > Makefiles as possible, I left it as libznc-1.6.dll.a. > > Building again, we don't actually get any further. When linking the perl > module, there are a stack of linker errors: > > modperl.o: In function `ZN10CPerlTimerD2Ev': > /usr/src/debug/znc-1.6.0-3/modules/modperl.cpp:277: undefined > reference to `CTimer::GetModule() const' > > and screenfulls of similar output. This is because your arguments to the > linker are in the wrong order. This doesn't matter on Linux, but it does > on Cygwin. You need to put the '-lznc-1.6' after your object files. This > gets the perl module compiling, and you'll have exactly the same > problems with the python. I gave up at this point; I didn't attempt to > test the binaries produced. > > The problem I have with this is that I see no way that this could ever > have compiled under Cygwin. How are you building this? > https://github.com/znc/znc-cygwin contains all the patches and build scripts. On push, build on AppVeyor is triggered, it spawns 2 Windows VMs. On one VM it installs fresh Cygwin x86, and on another one it installs fresh Cygwin x86_64. Step by step procedure is defined in https://github.com/znc/znc-cygwin/blob/master/appveyor.yml https://ci.appveyor.com/project/DarthGandalf/znc-cygwin/build/0.0.0.0.1-branch-master-build-13/job/ljcyqwn2v0im9aik#L399 contains logs how znc-1.6.0-3.i686 is built. Autoreconf is not failing, modperl builds fine without libznc.dll.a and link to cygznc-1.6.dll directly, linker has every reference defined... I'm surprised why it's not building for you at all. ZNC has been working in Cygwin for years, if compiled from source. Do you have any special CXXFLAGS/LDFLAGS/CXX/etc set in your environment? E.g. -Wl,--as-needed in LDFLAGS might cause the error about having '-lznc-1.6' after object files, and it's not specific to Cygwin. But I agree, order of arguments should be fixed to support --as-needed (in upstream though) I don't know if there are any options which would cause linker to require .dll.a. I can generate libznc.dll.a (or cygznc.dll.a) if you insist, of course. Regarding libznc#.dll: Yes, that number increments when ABI breaks (e.g. from 1.6 to 1.7). If upstream agrees to break ABI simultaneously with changing 2 first digits of version, why name of dll should be different from version? cygssl-1.0.0.dll is not a single number either. > I hope the above doesn't come across as too critical - these comments > are intended to be constructive, and I hope you find them helpful. > Yes, thanks for the comments!
Re: [ITP] znc 1.6.0
23.07.2015 14:24, Ken Brown пишет: > On 7/22/2015 8:57 PM, Alexey Sokolov wrote: >> 23.07.2015 00:03, David Stacey : >>> cygport ./znc.cygport prep compile >>> >>> Nothing out of the ordinary there. This gives the following error: >>> >>> configure.ac:255: Something is trying to use the C compiler. Since >>> this is a C++ project, this should not happen! >>> autom4te-2.69: /usr/bin/m4 failed with exit status: 1 >>> >> Hm, I'm not sure why autoreconf would do this (works for me though) > > I can confirm Dave's experience. It's strange that you don't get the > same failure. The error message is generated by AC_PROG_CC, which is > redefined at the beginning of configure.ac. > > Ken Yes, that message is generated by configure.ac in case if some included macro uses AC_PROG_CC instead of AC_PROG_CXX. But no included macro does that, neither configure.ac nor m4/*. So probably it somehow got included from your system m4 macros. configure.ac:255 is AX_PTHREAD, but it should come from m4/ax_pthread.m4 and it uses C++, not C. Probably autoreconf ignores existence of m4/ directory? David/Ken, may you pastebin (or attach) full output of ./configure, ./configure itself, and config.log? Thanks
Re: [ITP] znc 1.6.0
23.07.2015 06:23, Achim Gratz пишет: >> So, for protection against possible broken autoreconfs I'll add such >> src_compile to znc.cygport. > > As David said, please try to make autoreconf work or at least try to > understand why it doesn't. If you could add a cygcheck to the build > script we might be able to see better what is and is not installed in > your case. cygcheck is already in the build script... https://ci.appveyor.com/project/DarthGandalf/znc-cygwin/build/0.0.0.0.1-branch-master-build-13/job/ljcyqwn2v0im9aik/artifacts >> https://github.com/znc/znc-cygwin contains all the patches and build >> scripts. On push, build on AppVeyor is triggered, it spawns 2 Windows >> VMs. On one VM it installs fresh Cygwin x86, and on another one it >> installs fresh Cygwin x86_64. >> Step by step procedure is defined in >> https://github.com/znc/znc-cygwin/blob/master/appveyor.yml >> >> https://ci.appveyor.com/project/DarthGandalf/znc-cygwin/build/0.0.0.0.1-branch-master-build-13/job/ljcyqwn2v0im9aik#L399 >> contains logs how znc-1.6.0-3.i686 is built. > > Uh. You definitely need to prune the path in Cygwin to get rid of all > the Windows nonsense. Try setting CYGWIN_NOWINPATH as an environment > variable in Windows. Yes, that makes PATH more sane, thanks.
Re: [ITP] znc 1.6.0
23.07.2015 21:49, Alexey Sokolov пишет: > 23.07.2015 14:24, Ken Brown пишет: >> On 7/22/2015 8:57 PM, Alexey Sokolov wrote: >>> 23.07.2015 00:03, David Stacey : >>>> cygport ./znc.cygport prep compile >>>> >>>> Nothing out of the ordinary there. This gives the following error: >>>> >>>> configure.ac:255: Something is trying to use the C compiler. Since >>>> this is a C++ project, this should not happen! >>>> autom4te-2.69: /usr/bin/m4 failed with exit status: 1 >>>> >>> Hm, I'm not sure why autoreconf would do this (works for me though) >> I can confirm Dave's experience. It's strange that you don't get the >> same failure. The error message is generated by AC_PROG_CC, which is >> redefined at the beginning of configure.ac. >> >> Ken > Yes, that message is generated by configure.ac in case if some included > macro uses AC_PROG_CC instead of AC_PROG_CXX. But no included macro does > that, neither configure.ac nor m4/*. > So probably it somehow got included from your system m4 macros. > > configure.ac:255 is AX_PTHREAD, but it should come from m4/ax_pthread.m4 > and it uses C++, not C. > > Probably autoreconf ignores existence of m4/ directory? > > David/Ken, may you pastebin (or attach) full output of ./configure, > ./configure itself, and config.log? Thanks If you add ACLOCAL_FLAGS="-I m4" to znc.cygport, does it fix for you?
Re: [ITP] znc 1.6.0
>> If you add ACLOCAL_FLAGS="-I m4" to znc.cygport, does it fix for you? > > Yes. So why didn't your build require that? I have a hypothesis, but can't prove it without digging autotools sources. My guess is that you have AX_PTHREAD installed in /usr/share/aclocal (or in some other directory which is considered by default), and with bigger #serial than what local m4/ax_pthread.m4 has (17). That's why it doesn't work for you. But probably aclocal still tries local m4/ directory as last resort even if "-I m4" is not provided? That's why it could work for me. By explicitly adding m4/ to include dirs, it looks there earlier. But this is just a guess.
Re: [ITP] znc 1.6.0
22.07.2015 09:07, Corinna Vinschen пишет: > On Jul 22 00:32, Alexey Sokolov wrote: >>> I've had a busy day and I'm a little tired, so I'm probably about to >>> make a fool of myself on a public mailing list. Never mind :-) Three >>> points on the znc package: >>> >>> - Unless I've missed something, all this talk of DLL naming is a >>> little academic at the moment, as there is no 'dll.a' file to actually >>> link against. >> >> GCC links against .dll (or .so) fine. > > Without the (non-versioned) .dll.a file in /usr/lib, using -lznc will > fail. This should be part of the -devel package. FTR, https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html has a good write-up on this.
Re: [ITP] znc 1.6.0
>>> - Forgive me for being pedantic, but who gave this a GTG? I couldn't find one on this thread, and yet the package is up on the mirrors. >>> >>> I thought if the package exists in popular distros, no GTG needed? >> >> Uhm, no. The *votes* are not required, the GTG is. >> > > Oops. Sorry then! > Hi, Is there anything missing for GTG? https://github.com/znc/znc-cygwin/tree/e80164ce0f463177fe8bd0c2adfce9e707495da8 is the latest version with .dll.a (I didn't push to mirrors it yet)
Re: [ITP] znc 1.6.0
03.08.2015 08:59, Corinna Vinschen пишет: > On Jul 30 23:34, Alexey Sokolov wrote: >>>>> >>>>>> - Forgive me for being pedantic, but who gave this a GTG? I couldn't >>>>>> find one on this thread, and yet the package is up on the mirrors. >>>>> >>>>> I thought if the package exists in popular distros, no GTG needed? >>>> >>>> Uhm, no. The *votes* are not required, the GTG is. >>>> >>> >>> Oops. Sorry then! >>> >> >> Hi, >> >> Is there anything missing for GTG? >> https://github.com/znc/znc-cygwin/tree/e80164ce0f463177fe8bd0c2adfce9e707495da8 >> is the latest version with .dll.a (I didn't push to mirrors it yet) > > Oh sorry, I thought you already did push the packages. Can you please > point us to wget'able package files? > I pushed some packages, but the version with .dll.a not yet. I thought that probably I should get GTG before pushing again. http://people.znc.in/~darthgandalf/znc/znc-cygwin/
Perl and crypt.h
Hi Achim, I think perl package should depend on libcrypt-devel on x86_64. Otherwise, here's error while embedding perl: > In file included from > /usr/lib/perl5/5.22/x86_64-cygwin-threads/CORE/op.h:635:0, > from > /usr/lib/perl5/5.22/x86_64-cygwin-threads/CORE/perl.h:3736, > from > /home/q/KVIrc/src/modules/perlcore/libkviperlcore.cpp:68: > /usr/lib/perl5/5.22/x86_64-cygwin-threads/CORE/reentr.h:104:26: fatal error: > crypt.h: No such file or directory > # include > ^ It seems to works without libcrypt-devel on i686 though.
Re: [Attn. Maintainers] Perl 5.26.1
29.09.17 11:06, Yaakov Selkowitz пишет: On 2017-09-26 11:45, Achim Gratz wrote: Aside from the obvious perl-* distribution packages, I've checked for perl content in other packages and found these: biber: BibTeX replacement for users of BibLaTeX (installed binaries and support files) git-svn: Subversion compatibility support for Git version control system git: Distributed version control system grepmail:search mailboxes for mail matching an expression (installed binaries and support files) irssi: Modular text mode IRC client with Perl scripting nginx-mod_http_perl: Web and mail proxy server (installed binaries and support files) nginx-mod_http_perl: Web and mail proxy server po4a:Tools for translating various file formats with gettext (installed binaries and support files) pristine-tar:Regenerate pristine tarballs (installed binaries and support files) sendxmpp:Commandline XMPP (jabber) utility (installed binaries and support files) subversion-perl: A version control system (perl bindings) For future reference, there are more. The following are mine and are ready for upload: gnumeric graphviz hexchat libproxy link-grammar marisa ming openbabel openwsman rxvt-unicode vim xfconf zbar zinnia And the following which belong to others: gdal GraphicsMagick ImageMagick net-smtp openldap texinfo weechat znc It embeds perl and keeps all its files under /usr/lib/znc/; I'll just rebuild it with the updated perl package. Does it needs to be uploaded together with new perl?
Re: [Attn. Maintainers] Reminder: Package updates needed for the pending switch to perl-5.30.1
23.11.2019 17:19, Achim Gratz пишет: > Achim Gratz writes: >> I've already built the new Perl packages and the (almost) full set of >> distributions. I'm waiting for the stage 2 tests of the Perl build to >> finish and will then post a repository link for you to point setup.exe >> to (in addition of the Cygwin mirror) to update your own build systems. >> This time around these are the same packages that will be going live on >> the Cygwin mirrors unless I find an error that needs to be dealt with. >> >> Besides Ken and Andrew, who have already responded, the only other >> packages I don't yet maintain are from Yaakov (mostly Gnome and GUI >> related stuff) and the *Magick wrappers that Marco maintains. There >> should be other packages with captive Perl modules (IIRC SVN and Git). >> Git isn't affected because it sets up @INC itself and doesn't have >> architecture-specific modules. >> >> During the release of Perl-5.26 we've fingered the following: >> >> biber:BibTeX replacement for users of BibLaTeX >> (installed binaries and support files) >> git-svn: Subversion compatibility support for Git version control >> system >> git: Distributed version control system >> grepmail: search mailboxes for mail matching an expression >> (installed binaries and support files) >> irssi:Modular text mode IRC client with Perl scripting >> nginx-mod_http_perl: Web and mail proxy server (installed binaries and >> support files) >> nginx-mod_http_perl: Web and mail proxy server >> po4a: Tools for translating various file formats with >> gettext (installed binaries and support files) >> pristine-tar: Regenerate pristine tarballs (installed binaries >> and support files) >> sendxmpp:Commandline XMPP (jabber) utility (installed binaries >> and support files) >> subversion-perl: A version control system (perl bindings) >> texlive: TeXLive >> >> Again, just like the last time around, noarch packages _should_ keep >> working if the files are moved to the correct directory where Perl-5.30 >> looks for them, but I've not really checked. Since there have been many >> changes in Perl internals, I wouldn't take chances with archful packages >> (anything that comes with a DLL). > > Loooking through further mails from the last major version update for > Perl, it appears that a number of packages have embedded Perl > interpretors. Since we still lack the infrastructure to have multiple > Perl versions installed in parallel, these will also need to be updated > as otherwise they might no longer be able to link into the perl DLL. > The mentioned packages included: > Shall we build it, but not upload yet, or how do you want to manage the atomic update? > gdal > gnumeric > graphviz > hexchat > irssi > libproxy > link-grammar > marisa > net-smp > openbabel > openswan > postgresql > rxvt-unicode > vim > xfconf > zbar > zinnia > znc > > > > Regards, > Achim. >
Re: [Attn. Maintainers] perl-5.30.1 -- prepare for release
08.02.2020 21:53, Achim Gratz пишет: > Achim Gratz writes: >> In preparation of the release, please follow the instructions below to >> upload the packages (re-)created with the new Perl version to the Cygwin >> server. Please be reminded that the new packages should not be "test" >> versions so that setup.exe will offer them automatically when they are >> distributed to the mirrors. >> >> 1. Please do not place the !ready cookie file! When uploading via >> cygport that means using the command "upload-stage" rather than >> "upload". This will ensure that all packages of the update get release >> at the same time and that existing installations can be switched over to >> the new Perl in a single update transaction. >> >> 2. Instead, please put a zero-size !perl cookie file (preferrably at the >> package level). You can either create that file manually (lftp: put >> /dev/null -o pkgname/!perl) or touch that file into >> pkgname/dist/pkgname/ before commanding cygport to do "upload-stage". >> >> 3. Please respond to this mail when you've done the above so that we can >> keep track of what is staged in the upload area. >> >> If any of the above is unclear or you want assistance of any sort, >> please ask. > > I have all of my own / co-maintained packages staged now. > > > The update will wait for: > > subversion-perl > > > Going through the list of packages collected during the 5.26 update we > seem to be missing feedback from the respective maintainers for: > > net-smtp > texinfo > weechat > znc Eh, it was ready a while ago, and I pinged you already about that :) I've uploaded with !perl > git-svn > git > grepmail > nginx-mod_http_perl > po4a > pristine-tar > sendxmpp > > > Yaakov's packages will be updated later unless someone speaks up that > one of them is indispensable: > > perl-Alien-wxWidgets > perl-Cairo > perl-Cairo-GObject > perl-GD > perl-Glib > perl-Glib-Object-Introspection > perl-Gnome2 > perl-Gnome2-Canvas > perl-Gnome2-GConf > perl-Gnome2-Rsvg > perl-Gnome2-VFS > perl-Gnome2-Vte > perl-Gnome2-Wnck > perl-GStreamer1 > perl-Gtk2 > perl-Gtk2-GladeXML > perl-Gtk2-Notify > perl-Gtk2-SourceView2 > perl-Gtk2-Spell > perl-Gtk2-Unique > perl-Gtk2-WebKit > perl-Gtk3 > perl-Pango > perl-SGMLSpm > perl-Win32-GUI > perl-Wx > gnumeric > graphviz > hexchat > libproxy > link-grammar > marisa > ming > openbabel > openwsman > rxvt-unicode > vim > xfconf > zbar > zinnia > > > Regards, > Achim. >
Re: [Attn. Maintainers] perl-5.30.1 -- prepare for release
19.02.2020 17:44, Jon Turney пишет: > On 18/02/2020 19:53, Marco Atzeri wrote: >> Am 16.02.2020 um 16:30 schrieb Jon Turney: >>> On 16/02/2020 08:08, Marco Atzeri wrote: Am 16.02.2020 um 07:55 schrieb ASSI: > Marco Atzeri writes: >>> >>> Perhaps I should just extend the list of special users who are >>> allowed to upload orphaned packages to include all uploaders who also >>> have a sourceware shell account. >>> >>> (since they can upload anything by just moving it directly into the >>> relarea, anyhow) >> >> let me know if you implement it, I see a bit too many >> potentially broken packages by the Perl update > > I have made an update to calm which should extend the list of people who > can upload any orphan package to include everyone who currently: > > * has a sourceware shell account > * that account is a member of the cygwin group > * is currently a package maintainer > > That list of people is: > > Corinna Vinschen > Eric Blake > Jon Turney > Ken Brown > Marco Atzeri > Yaakov Selkowitz Is this list maintained manually (hardcoded), or automatically by calm based on the criteria you described above? > > This list is now also used as the list of people who can 'git push' to > the packaging repository for any package. > > If I've made a mistake and you think your name should (or should not :)) > be on this list, please let me know. > >> https://cygwin.com/ml/cygwin/2020-02/msg00130.html >> >> I am thinking to double check the list and eventually repackage >> some of them but I will prefer not touch too much cygwin-pkg-maint >
Re: git repositories for cygwin packaging - please test
04.08.2019 21:08, Jon Turney пишет: > > While a number of maintainers keep their cygwin packaging under some > sort of version control, there is currently no central collection of > these repositories. > > 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: > > git push cyg...@cygwin.com:/git/cygwin-packages/ > > where is a package name you are listed as a maintainer for > in http://cygwin.com/cygwin-pkg-maint. > > These repositories are lazily created on the first push. > > Since it's intended that these repositories will only contain cygport > scripts, patches, and other packaging files, and to prevent the > accidental committing of upstream archives, pushes containing large > binary files will be rejected. > > These repositories are viewable via gitweb at > https://cygwin.com/git-cygwin-packages/ (URL may be subject to change), > and should be cloneable via anonymous git/http with the URLs shown there. > > Please give this a test, if possible, and report any problems here. I've tried to push the playground branch to cygwin.com:/git/cygwin-packages/znc and the output was full of this: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "", LC_ALL = (unset), LANG = "ru_RU.utf8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "", LC_ALL = (unset), LANG = "ru_RU.utf8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C").
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
> > > > Please note that I can't easily figure out if a package uses an embedded > > Perl interpreter or sets up its own installation paths for Perl modules. > > These packages have previously been determined to fall under that > > category (some may have dropped that dependency in the meantime, but the > > maintainer would hopefully know): > > > znc Alexey Sokolov > Hi This package uses an embedded interpreter. Right now I have technical difficulties, and ETA to resolve them is unknown, so can't upload a new version. The cygport is available at https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/znc.git;a=summary , could you please try to rebuild it with the new perl? SCALLYWAG=deploy worked the last time, so there shouldn't be any difficulties. I won't be able to check if runtime works though.
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
07.02.2021 10:33, Marco Atzeri via Cygwin-apps пишет: > On 07.02.2021 09:35, Achim Gratz wrote: >> Alexey Sokolov writes: >>>>> > >>> >>> Right now I have technical difficulties, and ETA to resolve them is >>> unknown, so can't upload a new version. The cygport is available at >>> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/znc.git;a=summary >>> >>> , could you please try to rebuild it with the new perl? >> >> OK, should be no problem. Marco, can you give me (temporary) co-maint >> over znc, please? > > done > >> Regards, >> Achim. > > Regards > Marco > > Hi, I'm able to upload again, so the temporary co-maint may be removed now. Thanks Achim.
[ITA] argon2
Hi, here's updated argon2 package The old version of the patch also was modifying linux/darwin/etc parts, I skipped those, as deemed irrelevant herediff --git a/Makefile b/Makefile index 837e7f7..769f053 100644 --- a/Makefile +++ b/Makefile @@ -66,6 +66,7 @@ KERNEL_NAME := $(shell uname -s) MACHINE_NAME := $(shell uname -m) LIB_NAME = argon2 +LIB_PFX=lib PC_NAME = lib$(LIB_NAME).pc PC_SRC = $(PC_NAME).in @@ -88,18 +89,19 @@ ifeq ($(KERNEL_NAME), Darwin) PC_EXTRA_LIBS ?= endif ifeq ($(findstring CYGWIN, $(KERNEL_NAME)), CYGWIN) - LIB_EXT := dll - LIB_CFLAGS := -shared -Wl,--out-implib,lib$(LIB_NAME).$(LIB_EXT).a + LIB_PFX = cyg + LIB_EXT := -$(ABI_VERSION).dll + LIB_CFLAGS := -shared -Wl,--out-implib,lib$(LIB_NAME).dll.a PC_EXTRA_LIBS ?= endif ifeq ($(findstring MINGW, $(KERNEL_NAME)), MINGW) - LIB_EXT := dll - LIB_CFLAGS := -shared -Wl,--out-implib,lib$(LIB_NAME).$(LIB_EXT).a + LIB_EXT := .dll + LIB_CFLAGS := -shared -Wl,--out-implib,lib$(LIB_NAME)$(LIB_EXT).a PC_EXTRA_LIBS ?= endif ifeq ($(findstring MSYS, $(KERNEL_NAME)), MSYS) - LIB_EXT := dll - LIB_CFLAGS := -shared -Wl,--out-implib,lib$(LIB_NAME).$(LIB_EXT).a + LIB_EXT := .dll + LIB_CFLAGS := -shared -Wl,--out-implib,lib$(LIB_NAME)$(LIB_EXT).a PC_EXTRA_LIBS ?= endif ifeq ($(KERNEL_NAME), SunOS) @@ -116,7 +118,7 @@ ifeq ($(CC), clang) endif endif -LIB_SH := lib$(LIB_NAME).$(LIB_EXT) +LIB_SH := $(LIB_PFX)$(LIB_NAME)$(LIB_EXT) LIB_ST := lib$(LIB_NAME).a ifdef LINKED_LIB_EXT NAME="argon2" VERSION=20190702 RELEASE=1 LICENSE=CC0-1.0 CATEGORY="Libs" SUMMARY="Password-hashing function library" DESCRIPTION="This is the reference C implementation of Argon2, a password- hashing function that summarizes the state of the art in the design of memory-hard functions and can be used to hash passwords for credential storage, key derivation, or other applications." HOMEPAGE="https://github.com/P-H-C/phc-winner-argon2"; SRC_URI="https://github.com/P-H-C/phc-winner-argon2/archive/${VERSION}/phc-winner-argon2-${VERSION}.tar.gz"; SRC_DIR="phc-winner-argon2-${VERSION}" PATCH_URI="20190702-cygwin-dll.patch" PKG_NAMES="argon2 libargon2_1 libargon2-devel" argon2_CATEGORY="Utils" argon2_SUMMARY=${SUMMARY/library/tool} argon2_CONTENTS="usr/bin/argon2.exe usr/share/doc/" libargon2_1_CONTENTS="usr/bin/cygargon2-1.dll" libargon2_devel_CONTENTS="usr/include/argon2.h usr/lib/libargon2.dll.a usr/lib/pkgconfig/libargon2.pc" src_compile() { lndirs cd ${B} cygmake OPTTARGET=${ARCH_i686+i686}${ARCH_x86_64+generic} } src_install() { cd ${B} dobin argon2.exe cygargon2-1.dll doinclude include/argon2.h dolib libargon2.dll.a dopkgconfig libargon2.pc }
Re: [ITA] argon2
29.09.2023 02:10, Alexey Sokolov пишет: Hi, here's updated argon2 package The old version of the patch also was modifying linux/darwin/etc parts, I skipped those, as deemed irrelevant here https://files.asokolov.org/cygwin/argon2/ is the built binaries