Re: [ITP] chicken-4.9.0.1
On 12/10/2014 7:28 AM, Marco Atzeri wrote: On 12/10/2014 12:25 PM, Christian Kellermann wrote: Dear List, I am a core developer of the CHICKEN scheme system. We have supported building and running CHICKEN on cygwin for almost a decade now. However I noticed that the current cygwin package has been outdated for years. As the previous maintainer is missing from at least 2011... I'm still here, just _extremely_ rarely and sporadically. Life and a real job has pulled me away from hobby programming for some time now, so I'm happy to let Christian take over. (Not that programmer isn't a real job, it's just not _my_ real job.) best regards, Nate Thern
Re: [ITP] chicken-4.9.0.1
On 1/26/2015 12:32 PM, Christian Kellermann wrote: * Marco Atzeri marco.atz...@gmail.com [150110 11:00]: Christian, any problem with the instructions ? Sorry, none. It seemed that my initial mail for the SSH key has been lost. I have uploaded the packages as stated in the instructions and added my mail in the !email file. I hope all goes well. Every fine. What lists do I have to monitor to adjust the packages to potential infrastructure changes? I'd like to be a good cygwin citizen... Tthis one for discussion/communication between package maintainers and the general one for possible feedback of users Thanks for your help again! Kind regards, Christian Regards Marco
[ATTN maintainers] cocom gnubg nettle parrot rakudo
These are the last packages depending on libgmp3 (on 32bit only). Could these either be recompiled or dropped so that the old gmp library can be removed? I really don't want to compile it again with gcc-4.9.2 for just this handful of packages. Both parrot and rakudo are only available on 32bit and rather old. The package libppl also depends on libgmp3, but is now obsolete since the version of gcc using it has been retired. Another obsolete library is libmpc1 and all the 0.x versions of it. Could somebody with direct access to sourceware delete the cruft, please? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: Setup patch to keep test version if test version installed
On Jan 26 11:45, Corinna Vinschen wrote: On Jan 26 11:15, Achim Gratz wrote: Corinna Vinschen writes: No, no. Thanks for noticing! I was sure that the comparison operators are comparing using compareVersions() under the hood so I didn't check. How embarrassing. Now I see that they only do a casecompare, as you said. That's arguably a bug in the comparison operator implementation, so maybe we should fix that instead? I'm not so sure in which scenarios the operators are used. In those scenarios the caasecompare might be the right thing to do. Btw., while playing with my patch, I found that setup has a bug. I first thought this is my patches fault, but the current release of setup already shows this behaviour: Consider the cygwin package: Installed: 1.7.34-004 Curr: 1.7.33-1 Test: 1.7.34-005 When I enter the chooser dialog, the New version is set to 1.7.33-1. Now I click on the version number multiple times: 1.7.33-1--click--Keep --click--1.7.34-005 --click--Uninstall --click--Keep Huh? --click--1.7.34-005 --click--Uninstall --click--Keep Where's 1.7.33-1? --click--1.7.34-005 --click--Uninstall --click--Keep Argh. Where does *this* occur? I guess the above needs fixing before I apply any changes to the default selection :((( I checked in code which fixes this issue, which simplifies the package choosing algorithm when clicking on the package line, and which implements the default package in a way which never downgrades a package without the user's explicit consent by choosing the lower package version manually. This is much more in line with the update mechanism in Linux package managers. I uploaded test builds of this setup to cygwin.com: https://cygwin.com/setup-test-x86.exe https://cygwin.com/setup-test-x86_64.exe Please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpkCQMBcX3O6.pgp Description: PGP signature
Re: [ATTN maintainers] cocom gnubg nettle parrot rakudo
On Jan 26 18:46, Achim Gratz wrote: These are the last packages depending on libgmp3 (on 32bit only). Could these either be recompiled or dropped so that the old gmp library can be removed? I really don't want to compile it again with gcc-4.9.2 for just this handful of packages. Both parrot and rakudo are only available on 32bit and rather old. The package libppl also depends on libgmp3, but is now obsolete since the version of gcc using it has been retired. Another obsolete library is libmpc1 and all the 0.x versions of it. Could somebody with direct access to sourceware delete the cruft, please? Dunno about the other packages, but cocom is a build requirement for Cygwin. We can rebuild it, but not remove it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpEfW4QGNnvv.pgp Description: PGP signature
Re: [ITA] _autorebase
On Jan 24 16:32, Achim Gratz wrote: Corinna Vinschen writes: Marco, Achim, Yaakov? Anybody of you here? I mean, hey, how are we going to go forward if nobody even bothers to reply? :( I just came back from a business trip halfway around the world. Sorry, but we can't allow these alleged business trips anymore. ;) This list is still blocked when trying to reply from Gmane, so I usually can't answer here when I'm not home. I have no idea if that could be changed and if so, how. I guess a short PM would be in order if you want to chime in in a case like this. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgprqOXIIfkHs.pgp Description: PGP signature
Re: [ATTN maintainers] cocom gnubg nettle parrot rakudo
On Jan 26 18:46, Achim Gratz wrote: These are the last packages depending on libgmp3 (on 32bit only). Could these either be recompiled or dropped so that the old gmp library can be removed? I really don't want to compile it again with gcc-4.9.2 for just this handful of packages. Both parrot and rakudo are only available on 32bit and rather old. Are these still in use and maintained upstream? If so, any takers? If not we're going to remove them. The package libppl also depends on libgmp3, but is now obsolete since the version of gcc using it has been retired. Removed. Btw., do we still need the obsolete ppl-devel? Another obsolete library is libmpc1 and all the 0.x versions of it. Removed. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbuV4p1ud7I.pgp Description: PGP signature
SSH key for upload access
Name: Klaus Grue Package: logiweb BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by grue@tyr from OpenSSH B3NzaC1yc2EDAQABAAABAQCbJXn+fIvcirRonnL7tmKDXR05MQRriPhB+6mvcd yYO6t86otqeKssRqGDrK3J1Y3WZC28r+h2sk0w+7j/4tO90HL8Hei+cTF7pBJvuXLanE1r 8pezJnqiTSFndd2upkrES9arDiINve1B/hObXeiKk6E7ZI6/kpSjdNGPH5KLR6EARBagxp c4KfdZ0CtXZZ8THhVkIGDdq6dRyoHX3FcgIapuuHhmNA9YcLyZAVYuen1DHeeqyHFs7k0K Nn0LLygvrDaTg90MaYSMt7UpT8sy+yZD8jm7AqHUpOswqMaCnjpMjHnIlP327hMjltDxs6 3CfjoXbmHGMCf1fLFgVdjf END SSH2 PUBLIC KEY
readline package rename question
I'm attempting to upload a new version of readline 6.3. However, the 32-bit version named the devel package 'readline' 6.1 (the release/readline/setup.hint describes a direct package for headers and such, and release/readline/libreadline7/setup.hint describes the dlls), while the 64-bit version 6.2 (still sitting at the version built by Yaakov when 64-bit first came out) chose a different layout (release/readline/setup.hint contains only 'skip:', release/readline/libreadline7/setup.hint is identical, and release/readline/libreadline-devel/setup.hint contains the headers and such). I'd like to unify the naming, and like the idea of libreadline-devel (instead of plain 'readline'). For 64-bit, this is easy - just stick with the naming we've always used. But for 32-bit, it means I'd want the existing name of 'readline' to use 'requires: libreadline-devel' so that people get the upgraded package. How do I do that? Do I have release/readline/setup.hint contain just 'skip:' as in 64-bit, and then add release/_obsolete/readline/setup.hint that has the right 'requires: libreadline-devel', or does that throw off upset to have two different locations containing a setup.hint for readline? Also, I probably want to leave readline 6.3 in test until I have the matching bash 4.3 built and tested with it (it's a core enough library that I don't want to destabilize the distro by promoting my new build to current too soon). What implications does this have to the readline-libreadline-devel rename? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ATTN maintainers] cocom gnubg nettle parrot rakudo
Corinna Vinschen writes: Removed. Btw., do we still need the obsolete ppl-devel? By now everybody should have switched to libppl-devel via dependency, so I think this can also go now. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: I checked in code which fixes this issue, which simplifies the package choosing algorithm when clicking on the package line, and which implements the default package in a way which never downgrades a package without the user's explicit consent by choosing the lower package version manually. This is much more in line with the update mechanism in Linux package managers. You may have solved a long-standing problem. Let's see if everything else still works... :-) BTW, if you switch one package to test (or prev), then all packages belonging to the same source package must be switched to the same state. I'm currently doing this with an external tool via setup.ini rewrites, but setup.exe should be taught how to do that for manual intervention. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ATTN maintainers] cocom gnubg nettle parrot rakudo
Corinna Vinschen writes: Dunno about the other packages, but cocom is a build requirement for Cygwin. We can rebuild it, but not remove it. The or dropped was targeted at rakudo and parrot, as the other packages have active maintainers. But if somebody adopts them and also provides them for 64bit nobody would complain either. Sorry if that hasn't been clear. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [ATTN maintainers] cocom gnubg nettle parrot rakudo
On 1/26/2015 9:59 PM, Corinna Vinschen wrote: On Jan 26 18:46, Achim Gratz wrote: These are the last packages depending on libgmp3 (on 32bit only). Could these either be recompiled or dropped so that the old gmp library can be removed? I really don't want to compile it again with gcc-4.9.2 for just this handful of packages. Both parrot and rakudo are only available on 32bit and rather old. Are these still in use and maintained upstream? If so, any takers? Both seem active http://rakudo.org/ a compiler like for perl http://www.parrot.org/ is a virtual machine for dynamic languages (as perl and ruby ) Not my area Regards Marco
Re: Setup patch to keep test version if test version installed
On Jan 25 18:20, Corinna Vinschen wrote: Example: foo-1.22-1 is installed foo-1.23-1 is curr foo-1.24-1 is test == Setup chooses 1.23-1 as default. User installs 1.24-1. Next Setup run: foo-1.24-1 is installed foo-1.23-1 is curr foo-1.24-1 is test == Setup chooses 1.24-1 as default. Maintainer releases a new test version: foo-1.24-1 is installed foo-1.23-1 is curr foo-1.24-2 is test == Setup chooses 1.24-2 as default. Maintainer releases test version as curr version: foo-1.24-2 is installed foo-1.24-2 is curr == Setup chooses 1.24-2 as default. Maintainer releases new test version: foo-1.24-2 is installed foo-1.24-2 is curr foo-1.25-1 is test == Setup chooses 1.24-2 as default. Another case occured to me a few minutes ago. What if the test version gets removed, without updating curr? foo-1.24-1 is installed foo-1.23-1 is curr no test version Now what? Right now, Setup pulls the user back to curr, so 1.23-1 will be preselected. This is more or less equivalent to `yum distro-sync' on Fedora. What would make more(?) sense is sticking to installed instead, because the version number is higher than the curr version. This behaviour would reflect the behaviour of `yum update'. What do you think? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2x0wQCTKSX.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: No, no. Thanks for noticing! I was sure that the comparison operators are comparing using compareVersions() under the hood so I didn't check. How embarrassing. Now I see that they only do a casecompare, as you said. That's arguably a bug in the comparison operator implementation, so maybe we should fix that instead? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: What if the test version gets removed, without updating curr? Then there presumably was a good reason to pull that test version. What would make more(?) sense is sticking to installed instead, because the version number is higher than the curr version. This behaviour would reflect the behaviour of `yum update'. With test releases that get pulled I think it really is correct that the default reverts back to curr. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: Setup patch to keep test version if test version installed
On Jan 26 11:20, Achim Gratz wrote: Corinna Vinschen writes: What if the test version gets removed, without updating curr? Then there presumably was a good reason to pull that test version. What would make more(?) sense is sticking to installed instead, because the version number is higher than the curr version. This behaviour would reflect the behaviour of `yum update'. With test releases that get pulled I think it really is correct that the default reverts back to curr. Really? Here's what I'm doing on Linux: The latest upstream release 1.24 adds a feature I need. The official package version 1.23-44 is obviously still missing this feature, so I build my own rpm with the upstream version 1.24-0 and install that: Official: 1.23-44 Installed: 1.24-0 The official package gets updated to 1.23-47. What I'm expecting now is that the update does NOT update my package, and that's what yum or apper will do. They will leave my higher version alone: Official: 1.23-47 Installed: 1.24-0 Now the official version is pulled up to the next upstream version. The new package is 1.24-3. This time the version number is higher, so yum or apper will update: Official: 1.24-3 Installed: 1.24-3 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpD7JrBK7XoP.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Mon, 2015-01-26 at 10:58 +0100, Corinna Vinschen wrote: On Jan 25 18:20, Corinna Vinschen wrote: Example: foo-1.22-1 is installed foo-1.23-1 is curr foo-1.24-1 is test == Setup chooses 1.23-1 as default. User installs 1.24-1. Next Setup run: foo-1.24-1 is installed foo-1.23-1 is curr foo-1.24-1 is test == Setup chooses 1.24-1 as default. Maintainer releases a new test version: foo-1.24-1 is installed foo-1.23-1 is curr foo-1.24-2 is test == Setup chooses 1.24-2 as default. Maintainer releases test version as curr version: foo-1.24-2 is installed foo-1.24-2 is curr == Setup chooses 1.24-2 as default. Maintainer releases new test version: foo-1.24-2 is installed foo-1.24-2 is curr foo-1.25-1 is test == Setup chooses 1.24-2 as default. These all make sense to me. Another case occured to me a few minutes ago. What if the test version gets removed, without updating curr? foo-1.24-1 is installed foo-1.23-1 is curr no test version A similar question would arise if 1.24-1 had been curr, then pulled for some reason and not replaced immediately with a 1.24-2. (In such a case on Fedora, the downgrade would be forced through an epoch bump.) Also relevant would be the case where a newer version of a package is installed from a third-party repository (e.g. cmake in Ports), then in a subsequent run, the download cache was removed and said repository is not selected. Now what? Right now, Setup pulls the user back to curr, so 1.23-1 will be preselected. This is more or less equivalent to `yum distro-sync' on Fedora. What would make more(?) sense is sticking to installed instead, because the version number is higher than the curr version. This behaviour would reflect the behaviour of `yum update'. What do you think? Unfortunately the answer depends on the scenario. Would it be feasible to support both modes in setup? Yaakov
SSH Key for upload access
Name: Christian Kellermann Package: chicken BEGIN SSH2 PUBLIC KEY Comment: 5012-bit RSA, converted by ckellerm@devpool08 from OpenSSH B3NzaC1yc2EDAQABAAACcwykoG217tPyg4XiJl1Aar2q//xTCFukpgQKC2UW4Z gq++bvwh5TNioceh3UEbFZkgzZ3IXiAhYStb/1sTAmytU2AQv+uaCvZMV5u7tnBc5kATxX TsTp4PjwbrVnQ6J08k1BzUKCds+ftIIZBmEDodSON0NCXkvi0kiPKRlZ/UDliO/jtPBFx2 dnd/Ek7Duybg3yHvEXqg1GT7RP81U9UjzJzwjucs6e4k7QYnVhB4pP1u8nUAIwpu03U4ae ubepdWafMgFIP9eLwPJMRmxDpvovH3GKqmXvDkK5Qlq98185viJGXWMwL5mUA7j+2qImGE FSbTQUMf1hlwNcHjV0DpW6KaTZeiEkSV99hJ2HaPg1hajrJ3X/l7CHMxnoVnGEk/mvCwL/ 8e65xlCNwcgFHylfnSpDgT4hRHNK4+m439kLKooqXS0VW6inoTpYnYCYmfxp5bq53O9NM5 mpKxMwNXJ6O+N6vT3CB4schqUNPa/t0nTw20dA88kcJSiHniSxWn8yz7Uv6L8x2o0zb00L J75iUl/th7ZnFIOacJA0gqeD1o4feR2imMDVmMyGxv81JihfxRHYQVqyNsLrY7bh/7k6nV ieEEHfkuoM+R5kKKlLO62wwOGn9ms6LPaWfP5mRB8iNvhJLLHEBGqDTGtBL8WOC3HJ7Mn+ byy6W9s2XZrttAaAuLP7Jvqgy3k80E9ltiPlYpwRGXt7pKiUketDuyXjCnNSlhjHcUznwI 6/VsREtWdPnqrUx2oEz3EwCpr4ajBcxoeHygqzDPNME/048T2ZSr8qOgq6GPuNcGG1mNEB nP+wBBpmkXVrJ1hbcVvmPrTcTw== END SSH2 PUBLIC KEY
Re: Setup patch to keep test version if test version installed
Hi Achim,
On Jan 25 19:42, Achim Gratz wrote:
Corinna Vinschen writes:
Instead of always defaulting to the curr version, Setup now checks if
the installed version of a package is higher than the curr version of
the package. If so, and if a test version exists for this package, it
will choose the test version by default. A welcome side effect of this
is, if the test version becomes the curr version, the installed version
will not be higher than curr, thus the curr version will be chosen
again.
I'd say that's good enough for now.
Index: package_meta.h
===
RCS file: /cvs/cygwin-apps/setup/package_meta.h,v
retrieving revision 2.42
diff -u -p -r2.42 package_meta.h
--- package_meta.h 25 Jul 2013 12:03:49 - 2.42
+++ package_meta.h 25 Jan 2015 17:16:30 -
@@ -94,6 +94,8 @@ public:
{
if (t == TRUST_TEST exp)
return exp;
+else if (curr installed exp)
+ return exp;
else if (curr)
return curr;
else
I'd prefer to re-arrange the tests to something along the lines of
--8---cut here---start-8---
if (exp)
{
if ( (t == TRUST_TEST) ||
(curr installed) )
--8---cut here---end---8---
Nnnno. I was planning to rearrange the code slightly and to add
comments to explain what the code does. Every time I'm looking into
setup I'm desperately missing comments. Roberts C++ class system is a
teeny little bit confusing for my taste :}
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpgMxtkL0dO0.pgp
Description: PGP signature
Re: Setup patch to keep test version if test version installed
Hi David, On Jan 25 23:46, David Stacey wrote: On 25/01/15 17:20, Corinna Vinschen wrote: Instead of always defaulting to the curr version, Setup now checks if the installed version of a package is higher than the curr version of the package. This sounds like a great idea - providing that the logic to compare two version numbers is sufficiently clever. Looking at operator() in package_version.cc, it appears as though this is performing simple string comparison on the version numbers. This would fail in a number of cases. A real example from setup.ini: package: at-spi2-atk curr: 2.10.2-1 prev: 2.8.1-1 A simple string comparison would prefer prev over curr! In your patch, maybe it could be better to call packageversion::compareVersions() rather than use operator(). I'm not terribly familiar with the setup code, so please excuse me if I'm mistaken, got lost in the code, or am completely barking up the wrong tree. No, no. Thanks for noticing! I was sure that the comparison operators are comparing using compareVersions() under the hood so I didn't check. How embarrassing. Now I see that they only do a casecompare, as you said. I'll fix that in my code and check it in. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYVMrk89drn.pgp Description: PGP signature
Re: SSH Key for upload access
On Mon, 2015-01-26 at 11:31 +0100, Christian Kellermann wrote: Name: Christian Kellermann Package: chicken Updated cygwin-pkg-maint and installed your key. -- Yaakov
Re: [ITP] chicken-4.9.0.1
* Marco Atzeri marco.atz...@gmail.com [150110 11:00]: Christian, any problem with the instructions ? Sorry, none. It seemed that my initial mail for the SSH key has been lost. I have uploaded the packages as stated in the instructions and added my mail in the !email file. I hope all goes well. What lists do I have to monitor to adjust the packages to potential infrastructure changes? I'd like to be a good cygwin citizen... Thanks for your help again! Kind regards, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease.
Re: Setup patch to keep test version if test version installed
On Jan 26 11:15, Achim Gratz wrote: Corinna Vinschen writes: No, no. Thanks for noticing! I was sure that the comparison operators are comparing using compareVersions() under the hood so I didn't check. How embarrassing. Now I see that they only do a casecompare, as you said. That's arguably a bug in the comparison operator implementation, so maybe we should fix that instead? I'm not so sure in which scenarios the operators are used. In those scenarios the caasecompare might be the right thing to do. Btw., while playing with my patch, I found that setup has a bug. I first thought this is my patches fault, but the current release of setup already shows this behaviour: Consider the cygwin package: Installed: 1.7.34-004 Curr: 1.7.33-1 Test: 1.7.34-005 When I enter the chooser dialog, the New version is set to 1.7.33-1. Now I click on the version number multiple times: 1.7.33-1--click--Keep --click--1.7.34-005 --click--Uninstall --click--Keep Huh? --click--1.7.34-005 --click--Uninstall --click--Keep Where's 1.7.33-1? --click--1.7.34-005 --click--Uninstall --click--Keep Argh. Where does *this* occur? I guess the above needs fixing before I apply any changes to the default selection :((( Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSAvEd4O11S.pgp Description: PGP signature
Re: SSH key for upload access
On Mon, 2015-01-26 at 22:11 +, Klaus Ebbe Grue wrote: Name: Klaus Grue Package: logiweb Key installed. -- Yaakov
Re: [HEADSUP] Dropping libopenssl098 from distro
Just a quick update on the libopenssl098 frontier: On Jan 14 15:13, Corinna Vinschen wrote: it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. The problem is that we still have packages requiring libopenssl098. These need rebuilding or removing. The following packages need simple rebuilding: suite3270 Peter A. Castro Peter, any progress? The following packages have dependecies of their own, so they can't go away until the dependent packages have been rebuilt: libarchive2 Yaakov Selkowitz required by: gvfsYaakov Selkowitz libgxps2Yaakov Selkowitz gvfs and libgxps2 should be rebuilt to link against libarchive13. This needs the GNOME 3.14 update which will take some time. libpq Marco Atzeri required by: clisp Ken Brown xemacs Dr. Volker Zell These are in the works. libsasl2David Rothenberger required by: libopenldap2_3_0 Both of these packages can be removed automatically when clisp and xemacs are rebuilt. So the situation is grave, but not hopeless. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpp9KipVZmwA.pgp Description: PGP signature
Re: [ATTN maintainers] cocom gnubg nettle parrot rakudo
On Mon, 2015-01-26 at 18:46 +0100, Achim Gratz wrote: These are the last packages depending on libgmp3 (on 32bit only). Could these either be recompiled or dropped so that the old gmp library can be removed? I really don't want to compile it again with gcc-4.9.2 for just this handful of packages. cocom is mine, and I have added it to my update queue. -- Yaakov
