[gentoo-dev] News item for Radicale upgrade

[Christopher Head]

Hello,
I have filed a pull request
 to add Radicale 2.1.8 to
the tree. Migrating from Radicale 1 to 2 requires running a database
export command using Radicale 1, i.e. *before* upgrading, as Radicale 2
can’t read version 1’s storage format. Please see below my proposed
news item to go along with this version bump. Note that I am not a
developer and am therefore unable to commit this myself; I would
appreciate that it be reviewed and then whoever accepts my pull request
also add this news item at the same time. Because of this, I have set
the Posted date to today, as I can’t predict when it will actually be
posted; I ask that the committer please revise the date accordingly.
Thank you!

Title: Radicale 2 requires pre-install migration
Author: Christopher Head 
Posted: 2018-03-01
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: http://radicale.org/1to2/
-- 
Christopher Head


pgplBBA2idDBJ.pgp
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] cmake-utils.eclass: Override CMAKE_INSTALL_{INFO,MAN}DIR

[Michał Górny]

Provide an explicit override for CMAKE_INSTALL_INFODIR
and CMAKE_INSTALL_MANDIR to force Gentoo standards for those locations.
This is needed for Gentoo/FreeBSD where CMake defaults to /usr/info
and /usr/man; while PMS specifies /usr/share/info and /usr/share/man
via econf & do* helpers.
---
 eclass/cmake-utils.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index b9f69a824b14..636927d66491 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -602,6 +602,8 @@ cmake-utils_src_configure() {
SET (CMAKE_GENTOO_BUILD ON CACHE BOOL "Indicate Gentoo package 
build")
SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library path 
suffix" FORCE)
SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output 
directory for libraries")
+   set (CMAKE_INSTALL_INFODIR "${EPREFIX}/usr/share/info" CACHE 
PATH "")
+   set (CMAKE_INSTALL_MANDIR "${EPREFIX}/usr/share/man" CACHE PATH 
"")
_EOF_
[[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo 'SET 
(CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make" FORCE)' >> 
"${common_config}"
 
-- 
2.16.2

[gentoo-dev] Make it easier to check upper bounds with repoman.

[crocket]

https://github.com/gentoo-haskell/gentoo-haskell/issues/669 led me to
https://bugs.gentoo.org/555266

In other words, since repoman doesn't warn a repository manager about upper
bound violations, the manager often breaks dependencies.
It is often a problem with haskell overlay.

Do developers oppose https://bugs.gentoo.org/555266 ?
What do you think of the issue?

Re: [gentoo-dev] about non-ebuild files in the tree (and verification thereof)

[Michał Górny]

W dniu śro, 28.02.2018 o godzinie 16∶10 +0100, użytkownik Fabian Groffen
napisał:
> Hi,
> 
> I'm working on a verification implementation of
> https://www.gentoo.org/glep/glep-0074.html and ran into the following
> scenario that I don't know if it's right or wrong:
> 
> Consider net-misc/srf-ip-conn-srv
> % ls
> files  Manifest  metadata.xml  srf-ip-conn-srv-.ebuild
> srf-ip-conn-srv.pid
> % cat Manifest
> DIST jsmn-35086597a72d.tar.gz 11056 
> DIST srf-ip-conn-140c9b8a8619.tar.gz 112882 
> 
> Notice that there is a .pid file in the ebuild dir, checked in git,
> which even contains what appears to be a pid.  It isn't used from the
> ebuild as far as I can tell.  Apart from being odd, this is actually
> irrelevant.
> 
> In an rsync checkout of the gentoo-x86 tree, I see in the Manifest for
> this package a DATA entry for the .pid-file.  Hence, verification with
> both gemato as well as my own implementation succeed because the
> .pid-file is acknowledged.
> 
> Now in a rsync checkout of the Prefix tree, where my own implementation
> also runs the fat manifest creation, this entry is not present, because
> I always believed only metadata.xml, ChangeLog* and *.ebuild files were
> allowed.
> 
> Now I'm confused as to whether this is the case or not, I can't find a
> GLEP or anything, but repoman also is as happy as it can be on this odd
> file (I thought it used to complain about stray/unadded files).
> 
> Does anybody know or have a pointer to what the policies on files in our
> ebuild dirs actually is?
> 

I'm going to have the usual answer here: it was not rejected because
nobody predicted such a thing could happen. Since ebuilds do not have
a clear way of accessing this file, there is no clear reason why anyone
would try to add such a file.

Plus, given it's a special location (again, not accessible directly to
ebuilds) there's the argument of forward compatibility others mentioned.

-- 
Best regards,
Michał Górny