Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal
> On Tue, 19 Sep 2017, Paul Varner wrote: > set and uninstall gentoolkit-dev. This will then allow the installation of > >=app-portage/gentoolkit-0.4.0 One tiny correction: There should be a full stop at the end of the sentence. Ulrich pgp4HQJd5oUqS.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal
Am Dienstag, 19. September 2017, 19:10:23 CEST schrieb Paul Varner: > emerge --deselect app-portage/gentoolkit-dev > emerge --depclean app-portage/gentoolkit-dev > why deselect it first? From man emerge, --depclean: "When given one or more atoms, it will unmerge matched packages that have no reverse dependencies." /martin
Re: [gentoo-dev] Re: glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...
Am Dienstag, 19. September 2017, 22:38:17 CEST schrieb Luca Barbato: > > REQUIRED_USE="^^ ( sunrpc libtirpc ntirpc )" > > If rpc support is optional with useflag rpc, then this becomes > > REQUIRED_USE="rpc? ( ^^ ( sunrpc libtirpc ntirpc ) )" > > > > Since the three options are coinstallable I see no problems with a package > > only supporting a subset, but I have no clue how this interacts at > > runtime. > > If they aren't ABI-compatible you would expect explosions once you link > two libraries linked to the two different implementation (assuming they > aren't macro-mangling everything). Yep. So, apart from requiring "use the same implementation everywhere", i.e. set the flag globally, and stating "if you micromanage, you have to contain the explosions yourself" - is there anything else we can realistically do? > We could check if the other libc could be switched to the external > provider and play the lazy card and just always force an external > implementation. Two or three implementations doesnt make that much of a difference anymore... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice)
Re: [gentoo-dev] Re: glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...
Dnia 20 września 2017 10:23:42 CEST, "Andreas K. Huettel" napisał(a): >Am Dienstag, 19. September 2017, 22:38:17 CEST schrieb Luca Barbato: >> > REQUIRED_USE="^^ ( sunrpc libtirpc ntirpc )" >> > If rpc support is optional with useflag rpc, then this becomes >> > REQUIRED_USE="rpc? ( ^^ ( sunrpc libtirpc ntirpc ) )" >> > >> > Since the three options are coinstallable I see no problems with a >package >> > only supporting a subset, but I have no clue how this interacts at >> > runtime. >> >> If they aren't ABI-compatible you would expect explosions once you >link >> two libraries linked to the two different implementation (assuming >they >> aren't macro-mangling everything). > >Yep. So, apart from requiring "use the same implementation everywhere", >i.e. >set the flag globally, and stating "if you micromanage, you have to >contain >the explosions yourself" - is there anything else we can realistically >do? dev-libs/foo[sunrpc=,tirpc=...]? > >> We could check if the other libc could be switched to the external >> provider and play the lazy card and just always force an external >> implementation. > >Two or three implementations doesnt make that much of a difference >anymore... -- Best regards, Michał Górny (by phone)
[gentoo-dev] Packages up for grabs
Due to lack of time, the following packages, which currently list me as mainainer, are up for grabs: - dev-libs/poco: needs a version bump and has some open bugs. At least some of those might have been fixed in newer versions. - dev-java/commons-compress: Needs a version bump, which requires additional dependencies -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On Wed, 20 Sep 2017 12:08:01 +0200 Thomas Sachau wrote: > - dev-java/commons-compress: Needs a version bump, which requires > additional dependencies You may as well just stick this one under j...@gentoo.org. -- James Le Cuirot (chewi) Gentoo Linux Developer
[gentoo-dev] Last rites: media-libs/herqq
# Michael Palimaka (21 Sep 2017) # Requires dead Qt 4. Dead upstream. # Masked for removal in 30 days. media-libs/herqq
[gentoo-dev] Re: glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...
Andreas K. Huettel posted on Tue, 19 Sep 2017 14:53:20 +0200 as excerpted: > Am Dienstag, 19. September 2017, 07:06:24 CEST schrieb Duncan: >> Andreas K. Huettel posted on Mon, 18 Sep 2017 11:56:30 +0200 as >> excerpted: >> > It may not always be obvious where this is needed, since >> > net-libs/libnsl is already pulled in deep in the dependency tree (my >> > @system chroot has it). >> >> FWIW, while it may be deep in the @system dependency tree, I don't have >> libnsl installed here > > Do you run glibc-2.26 already? I hope not, because it's >>unkeyworded<< > and I'm still changing things without warning there... :) [*] > > With any other glibc, it's part of sys-libs/glibc. > > And you will need it, because part of dev-lang/python links to it (for > us) unconditionally. Thanks for the clarification. I'm still on glibc-2.25-r5 here (Having read the thread as it developed I seem to have forgotten the bit about it being included in 2.25 by the time I replied, so the clarification is very helpful. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal
On 9/20/17 2:49 AM, Martin Gysel wrote: Am Dienstag, 19. September 2017, 19:10:23 CEST schrieb Paul Varner: emerge --deselect app-portage/gentoolkit-dev emerge --depclean app-portage/gentoolkit-dev why deselect it first? From man emerge, --depclean: "When given one or more atoms, it will unmerge matched packages that have no reverse dependencies." Mainly as an extra precaution. However, just --depclean should work. This is the update with the typo pointed out by ulm corrected and changing the command to just be depclean. Regards, Paul Title: app-portage/gentoolkit-dev deprecation and removal Author: Paul Varner Posted: 2017-09-19 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: app-portage/gentoolkit-dev The app-portage/gentoolkit-dev package has been deprecated and the ebump, ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0 package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable, users will need to take action since gentoolkit-dev and those versions of gentoolkit block each other. In order to upgrade to the new version of gentoolkit, you will need to resolve the blocks. The following command will remove gentoolkit-dev from your world set and uninstall gentoolkit-dev. This will then allow the installation of >=app-portage/gentoolkit-0.4.0. emerge --depclean app-portage/gentoolkit-dev Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev releases will be masked for removal and subsequent tree-cleaning.
[gentoo-dev] sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected
Greetings, So, I filed bug #631468 regarding sys-libs/ncurses's ebuild deleting *.dll.a files unconditionally if USE=static-libs is not set; this is a problem as mingw-w64 uses these files at link time (-lncurses needs libncurses.dll.a to link and libncurses6.dll at runtime). arfrever suggests I send a mail here, as there are other packages which may be affected by this issue and perhaps a more generalized fix is required instead of an explicit fix in sys-libs/ncurses and other ebuilds that may require it. Thoughts? Regards, Marty
Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist
On Tue, 19 Sep 2017 14:44:44 +0100 Tony Vroon wrote: > We have similar workflow issues with this, and as a consequence our > software team has asked me to step up. I can present an at least vaguely > maintainable ebuild on: > https://bugs.gentoo.org/572824 > > I am aware that some of the patches are rather large, so I will pack > them up into an Asterisk-style patchset that is downloaded from the mirrors. > For the avoidance of doubt, I am not proposing to remove the > package.mask entry but I am looking to prevent package removal. Most excellent :) >>> www-client/phantomjs-2.1.1 merged :D pgpccxllradi7.pgp Description: OpenPGP digital signature
