Re: [gentoo-dev] bash-4.4 - call for testers
The only reason I haven't been testing this for many months system-wide is it's in the same slot as 4.3, and it still is. Is it not possible to separate them?
[gentoo-dev] Packages up for grabs from sci-geosciences category
Hi, Continuing my efforts not to be listed as a maintainer for packages I don't really care about: There are a bunch of packages in the sci-geosciences category that I maintained a long time ago when I was active in the openstreetmap community. All of them are listed with the sci-geosciences project as a maintainer as well, so I'll just remove myself and leave the project maintainership in a few days. But if anyone wants to jump in feel free to take the packages (just remove me and add yourself in that case). sci-geosciences/gebabbel Frontend for the tool gpsbabel. Strangely enough we have 0.4, while upstream seems only to have 0.3. There are no open bugs, so it seems a relatively stress free package and it can probably just stay the way it is. sci-geosciences/gpscorrelate Tool to add gps coordinates based on gpx tracks. No open bugs, latest version, so it seems stress free and can probably stay without a dedicated maintainer. sci-geosciences/josm The Java OpenStreetMap editor. It was the standard way of editing openstreetmap in the past, but since the web editor got much betters I think it's relevance is smaller these days. nixphoeni has done the last version bumps, I already asked him directly if he wants to take over maintainership. sci-geosciences/mkgmap Tool to create garmin maps from openstreetmap data. I don't have any garmin device any more. This is many years behind upstream and whoever wants to take it will probably have to face some complicated java-dependency-management issues, see here: https://bugs.gentoo.org/show_bug.cgi?id=402943 If nobody wants to take it we may want to last-rite this. Upstream provides precompiled jar versions, it probably makes more sense that people use those instead of our heavily outdated ebuild. sci-geosciences/osm2mp This is probably deprecated. It turns openstreetmap data into a format called mp which was used by mkgmap (see previous). Later versions of mkgmap were directly capable of using osm data, therefore that use case is gone. However not sure if there are other uses of mp. Anyway, no open bugs, so it seems trouble free and may just stay if there is any use of it. sci-geosciences/osmosis Command line tool to interact with the osm api. Similar problem as mkgmap with complex java dependency stuff. Years behind upstream, see: https://bugs.gentoo.org/show_bug.cgi?id=402945 As with mkgmap I'd recommend last-riting this if no maintainer steps in to tackle this. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
[gentoo-dev] Changes coming to libmysqlclient.so providers
My fellow developers,
I've previously asked that packages which link to libmysqlclient.so be
moved to virtual/libmysqlclient as a {,R}DEPEND. There are some which
have done so but many have not.
There are major changes coming with MariaDB 10.2 and MySQL 5.7 so either
the devs will have to do it or users will have to rely on either
revdep-rebuild or @preserved-rebuild.
MySQL 5.7 is moving to libmysqlclient.so.20 and MariaDB is providing
libmariadbclient.so (LGPL).
For packages that still depend on virtual/mysql but really only need to
link to libmysqlclient.so, change to virtual/libmysqlclient:= to help
users with rebuilds.
A few packages, dev-db/myodbc comes to mind, will need certain slots of
virtual/libmysqlclient that I have yet to finalize.
In addition, some packages will break if they depend on private APIs
exposed in previous libmysqlclient.so's as upstreams are tightening down.
Thank you,
Brian
MySQL Team Lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] New USE_EXPAND: LLVM_TARGETS
Ühel kenal päeval, K, 28.09.2016 kell 08:39, kirjutas Michał Górny: > On Wed, 28 Sep 2016 08:31:06 +0200 > Marek Szuba wrote: > > > > > On 2016-09-27 22:51, Raymond Jennings wrote: > > > > > > > > Doesn't VIDEO_CARDS factor in on xorg-server's video driver > > > selection? > > It does. Which is why with the way things are now, and which > > Michał's > > proposal should improve, someone with an amdgpu-compatible card > > will > > still have xf86-video-ati lying around - VIDEO_CARDS=radeon will > > pull it in. > > Also note there's VIDEO_CARDS=amdgpu for newer cards, to increase > your > confusion. And the LLVM target is probably needed for > VIDEO_CARDS=radeonsi and newer, not by VIDEO_CARDS=radeon. Though it > may be needed for OpenCL. As discussed on IRC, I think the amdgpu target should be enabled via video_cards_radeonsi, because the only consumer of that target that pulls it in is currently mesa[video_cards_radeonsi], so users don't need to go fiddling with yet another USE_EXPAND when they already set VIDEO_CARDS="radeonsi" or similar anyways in their make.conf. I don't quite understand the rest of the LLVM_TARGETS proposed. Seems like all the rest of them would be use.masked and unmasked in specific arch profiles? It seems that once you remove AMDGPU from the equation by keeping it behind VIDEO_CARDS, all the rest are CPU specific stuff, not GPU, so less mixing things up in a way; though with completely unhelpful llvm_targets.desc I don't know if any of the others might not be something else (like BPF, Hexagon, Lanai, MSP430 and more) And yes, the existing VIDEO_CARDS=radeon* stuff is rather confusing in mixing up GL driver names, DRM backend names and more, but a separate issue that I'm thinking on how to clean up and working with the rest of the x11 team towards something. Meanwhile llvm[video_cards_radeonsi] would make sure those that need it, already have it if they enable the thing they need to get it from mesa globally, and won't need to fiddle with other flags too. And yes, it's currently llvm[video_cards_radeon] in old versions of llvm, and that's not accurate anymore since a while imho, and should be converted to video_cards_radeonsi as well. Mart
