Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Mike Frysinger]

On 22 Jan 2016 12:04, Alexis Ballier wrote:
> On Thu, 21 Jan 2016 18:45:20 +0100 Michał Górny wrote:
> > If I see a package that clearly doesn't build or otherwise simply
> > doesn't work, could not have worked for past 3 years, are you forcing
> > me to waste a time reporting a bug to no maintainer who could fix it?
> 
> sure, don't waste your time and just delete it so that nobody can track
> why it was removed or even attempt to fix it.
> 
> > Because to me, the lack of any open bugs is a clear evidence that
> > the package is not only unmaintained, but also unused.
> 
> lack of open bug means there is no known bug; anything else is pure
> supposition

this.  if anything, it sounds like i need to keep open a trivial bug
for a package to keep people from wrongly proactively tree cleaning.

the # of users of a package is irrelevant.  if there are (real i.e. not
"typo in message" bugs) open, then that's a diff story.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: Add sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf

[Brian Dolbec]

On Sat, 23 Jan 2016 03:45:14 +0800
konsolebox  wrote:

> On Sat, Jan 23, 2016 at 2:05 AM, Brian Dolbec 
> wrote:
> > On Sat, 23 Jan 2016 01:05:12 +0800
> > konsolebox  wrote:
> >  
> >> On Fri, Jan 22, 2016 at 11:30 PM, Duncan <1i5t5.dun...@cox.net>
> >> wrote:  
> >> > konsolebox posted on Fri, 22 Jan 2016 22:10:53 +0800 as
> >> > excerpted: 
> >> >> Hi, I can't find a way to make `emerge --sync` add an option
> >> >> like `-f` to `git pull` when it runs it.  How about adding
> >> >> sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf?
> >> >> We already have sync-rsync-extra-opts for rsync so I think it's
> >> >> fair to add one for git.  
> >> >
> >> > If you have layman installed, you can set repo sync-type to
> >> > laymansync, and layman, in turn, has configuration options that
> >> > allow you to set additional options for git as well as the other
> >> > repo-type fetch commands (bzr, svn, etc).
> >> >  
> >>
> >> Unfortunately I need it for the `gentoo` repo itself.  I do have
> >> layman repos but I update them separately with `layman -S`, and I
> >> don't want them to always get updated together with `gentoo`
> >> everytime I run `emerge --sync`.
> >>  
> >
> > No, the portage sync system controls which repo(s) get synced via
> > the auto-sync setting.  So layman can git sync the gentoo repo like
> > Duncan described without also syncing your manually synced layman
> > repos.  
> 
> Ok I think I follow a bit, but wouldn't it be better to have that
> feature without relying on layman?
> 

Yes, it would be better.  But there are only do many hours we each can
spend on Gentoo.  I have the repoman rewrite as my primary portage work
in progress at the moment.  And this feature is not something I am in
need of...

For those who may wish to add this and/or other features to the sync,
The repos.conf repo definitions are now capable of extra options per
sync type (They don't have to be common to all sync modules). So it is
possible to add this to the git sync module and have specific repo
settings.  We are around and eager to help anyone wishing to contribute
patches :)


-- 
Brian Dolbec 

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Roy Bamford]

On 2016.01.21 17:45, Michał Górny wrote:
[snip]

> 
> If I see a package that clearly doesn't build or otherwise simply
> doesn't work, could not have worked for past 3 years, are you forcing
> me to waste a time reporting a bug to no maintainer who could fix it?
> 
[snip]
> -- 
> Best regards,
> Michał Górny
> 
> 

Michał 

Your statement implies that there is an active search process for broken 
packages.

I did not intend to imply that if you happened across a broken package with no 
bugs, 
you needed to raise a bug to remove it from the tree.

Actively building every package in the tree to discover candidates for removal 
takes a lot more resources than searching bugs to identify potential candidates.

Its the old case of absence of evidence is not evidence of absence.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpFDkyRFS8fc.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Add sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf

[Brian Dolbec]

On Sat, 23 Jan 2016 01:05:12 +0800
konsolebox  wrote:

> On Fri, Jan 22, 2016 at 11:30 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> > konsolebox posted on Fri, 22 Jan 2016 22:10:53 +0800 as excerpted:
> >  
> >> Hi, I can't find a way to make `emerge --sync` add an option like
> >> `-f` to `git pull` when it runs it.  How about adding
> >> sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf?  We
> >> already have sync-rsync-extra-opts for rsync so I think it's fair
> >> to add one for git.  
> >
> > If you have layman installed, you can set repo sync-type to
> > laymansync, and layman, in turn, has configuration options that
> > allow you to set additional options for git as well as the other
> > repo-type fetch commands (bzr, svn, etc).
> >  
> 
> Unfortunately I need it for the `gentoo` repo itself.  I do have
> layman repos but I update them separately with `layman -S`, and I
> don't want them to always get updated together with `gentoo` everytime
> I run `emerge --sync`.
> 

No, the portage sync system controls which repo(s) get synced via the
auto-sync setting.  So layman can git sync the gentoo repo like Duncan
described without also syncing your manually synced layman repos.

-- 
Brian Dolbec 

[gentoo-dev] Re: [PATCH 07/15] cmake-utils.eclass: replace replace comment_add_subdirectory with a namespaced version

[Michael Palimaka]

On 01/22/2016 03:29 AM, Michał Górny wrote:
> Dnia 20 stycznia 2016 11:43:05 CET, Michael Palimaka  
> napisał(a):
>> ---
>> eclass/cmake-utils.eclass | 15 +--
>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>> index 1de863f..e8b24bd 100644
>> --- a/eclass/cmake-utils.eclass
>> +++ b/eclass/cmake-utils.eclass
>> @@ -250,11 +250,11 @@ _generator_to_use() {
>>  echo ${generator_name}
>> }
>>
>> -# @FUNCTION: comment_add_subdirectory
>> +# @FUNCTION: cmake_comment_add_subdirectory
>> # @USAGE: 
>> # @DESCRIPTION:
>> # Comment out an add_subdirectory call in CMakeLists.txt in the current
>> directory
>> -comment_add_subdirectory() {
>> +cmake_comment_add_subdirectory() {
>> if [[ -z ${1} ]]; then
>> die "comment_add_subdirectory must be passed the directory name to
>> comment"
>> fi
>> @@ -265,6 +265,17 @@ comment_add_subdirectory() {
>> fi
>> }
>>
>> +# @FUNCTION: comment_add_subdirectory
>> +# @USAGE: 
>> +# @DESCRIPTION:
>> +# Comment out an add_subdirectory call in CMakeLists.txt in the
>> current directory
>> +# Banned in EAPI 6 and later - use cmake_comment_add_subdirectory
>> instead.
>> +comment_add_subdirectory() {
>> +has "${EAPI:-0}" 2 3 4 5 || die "comment_add_subdirectory is banned
>> in EAPI 6 and later - use cmake_comment_add_subdirectory instead"
>> +
>> +cmake_comment_add_subdirectory "$@"
>> +}
>> +
>> # @FUNCTION: cmake-utils_use_with
>> # @USAGE:  [flag name]
>> # @DESCRIPTION:
> 
> Enough to 'replace' once :-P (commit message).
> 

Thanks, fixed.

[gentoo-dev] Re: Herd up for grabs: net-dialup

[Michael Palimaka]

On 01/21/2016 04:32 AM, Mike Frysinger wrote:
> On 17 Jan 2016 21:57, Lars Wendler wrote:
>> I am going to take the following packages:
>>
>> net-dialup/mingetty
>> net-dialup/ppp
>> net-dialup/rp-pppoe
>>
>> I think that I might not be the perfect maintainer for these packages
>> (especially for ppp) so if anyone else wants to maintain these, feel
>> free to add yourself as well.
> 
> how about moving those to base-system@ ?
> 
> for the low level serial ones, we can move them to embedded since they
> get way more use there nowadays than w/dialup modems.
> app-misc/ckermit
> net-dialup/lrzsz
> net-dialup/minicom
> net-dialup/picocom
> net-dialup/xc
> -mike
> 

Thanks, I've taken care of these changes.

[gentoo-dev] Re: [PATCH 15/15] cmake-utils.eclass: update copyright year

[Michael Palimaka]

On 01/22/2016 03:32 AM, Michał Górny wrote:
> Dnia 20 stycznia 2016 11:43:13 CET, Michael Palimaka  
> napisał(a):
>> ---
>> eclass/cmake-utils.eclass | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>> index 70b70e2..9e8e71e 100644
>> --- a/eclass/cmake-utils.eclass
>> +++ b/eclass/cmake-utils.eclass
>> @@ -1,4 +1,4 @@
>> -# Copyright 1999-2015 Gentoo Foundation
>> +# Copyright 1999-2016 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Id$
>>
> 
> Now I'm being picky but this should have happened in the first commit.
> 
> 

I'll squash this into the first commit.

Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Aaron W. Swenson]

On 2016-01-22 11:51, Ian Stakenvicius wrote:
> The eclasses look good to go for me -- i've built an ebuild for pl/R
> using them and it works as expected (and it's nice to not have to
> define PG_CONFIG et. al. myself too).
> 
> Can the eclasses be migrated to the tree soon?

I wanted to test the eclass against pgTAP as well with the default
functions, but have been struggling the past couple days with getting my
machine up to date.

I would like some feedback on the documentation/comments in the
eclass. I'm certain it could be improved. Though, if you were able to
follow them (not a slight, just you were the first to follow them), I
might have done good enough.

> Also of note, it will be important to stabilize soon the ~arch
> versions of postgresql that have the install_bin path patched;
> otherwise if portage is, say, reinstalled with a different python
> selection between when postgres is emerged and one of these new
> postgres-multi packages are emerged, installation fails.

Oh, yes, I think we can move towards stabilization as soon as my
Internet is back up.


signature.asc
Description: Digital signature

[gentoo-dev] Re: Herd up for grabs: xbox

[Michael Palimaka]

On 01/18/2016 08:38 PM, Alexis Ballier wrote:
> On Sun, 17 Jan 2016 17:47:54 +0100
> Michał Górny  wrote:
> 
> 
>> media-tv/kodi: 
>> media-tv/xbmc: 
> 
> you can add video herd for these two if vapier is ok with that i think
> 
> 

Thanks, I've taken care of this.

Re: [gentoo-dev] Re: Herd likely up for grabs: kernel-misc

[Joshua Kinard]

On 01/20/2016 14:48, Duncan wrote:
> Mike Frysinger posted on Wed, 20 Jan 2016 13:40:04 -0500 as excerpted:
> 
>> if base-system@ isn't going to maintain it, we'll punt it from the herd
>> -mike
> 
> Umm, you mean project, right?  Because the whole discussion here is part 
> of getting rid of herds.  =:^)
> 

Somewhere in my archives, I have the e-mail proposing the creation of herds.

...

I feel old now.


--J

[gentoo-dev] Add sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf

[konsolebox]

Hi, I can't find a way to make `emerge --sync` add an option like `-f`
to `git pull` when it runs it.  How about adding sync-git-extra-opts
or sync-git-pull-extra-opts to repos.conf?  We already have
sync-rsync-extra-opts for rsync so I think it's fair to add one for
git.

-- 
konsolebox

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/22/2016 03:04 PM, Dirkjan Ochtman wrote:
> Third attempt.
> 

..

> 
> Remaining question: how do get the timing of the news item to line
>  up with the stabilization? Or do we just start by sending out the
>  news item, then file the stabilization bugs so that people at 
> least have advance notice?

Advanced notice, please


- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWojqUAAoJECULev7WN52FXD0IAKoAhGIB27lbYsWORQ6H8AMC
hStsuzOL4cYnWp/YJT2j31dCIZvnzt9dRByIYkZn+roPv3Cl1ij+TA2TGaLg8t5s
QGr2ASA4kYle8DIU2WmeR0VxBsv0QaHqVbY9YkT7++a2EkqaQAXBuoJIIZeMKvCI
6WiXj/rX2/9ORm7lIkwahp5ClbHMlCqxY4qUOurK+ki9TUDhDN6DnYrLQDG/+y88
aB6XbUqR2CCMc46QiKox+h1HxKf6poqSwBvDMUwWTsl5TBT1mVXh5PMemRBwhLN4
pRLexBhaCrMv3IdKmD20CrGtKGt3uw2FxRkMI8iJKR6BCeRV1JNL9BuHyDJVAd4=
=mE3l
-END PGP SIGNATURE-

Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The eclasses look good to go for me -- i've built an ebuild for pl/R
using them and it works as expected (and it's nice to not have to
define PG_CONFIG et. al. myself too).

Can the eclasses be migrated to the tree soon?

Also of note, it will be important to stabilize soon the ~arch
versions of postgresql that have the install_bin path patched;
otherwise if portage is, say, reinstalled with a different python
selection between when postgres is emerged and one of these new
postgres-multi packages are emerged, installation fails.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlaiXiMACgkQAJxUfCtlWe0DUAD/Xj9R3KTYHUBMaXdLioxNtP+N
yzx0Fy3y+eGBpGj0i6wBAOqi/oeRWAOINcl+RNfval46qr2R7Wr9ago2V1eqT+R0
=t7kM
-END PGP SIGNATURE-

[gentoo-dev] Re: Add sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf

[Duncan]

konsolebox posted on Fri, 22 Jan 2016 22:10:53 +0800 as excerpted:

> Hi, I can't find a way to make `emerge --sync` add an option like `-f`
> to `git pull` when it runs it.  How about adding sync-git-extra-opts or
> sync-git-pull-extra-opts to repos.conf?  We already have
> sync-rsync-extra-opts for rsync so I think it's fair to add one for git.

If you have layman installed, you can set repo sync-type to laymansync, 
and layman, in turn, has configuration options that allow you to set 
additional options for git as well as the other repo-type fetch commands 
(bzr, svn, etc).

Tho AFAIK, that's global, so any git-type repo that is set to laymansync 
in repos.conf, will use layman's additional options settings.  You could, 
however, set only the desired repos to laymansync type, while setting the 
others to git sync type, so portage will fetch the one set using normal 
options with layman fetching the others using its customized options.

Unfortunately, the laymansync sync-type doesn't seem to be well 
documented, either in the layman manpage or in the portage manpage (which 
covers repos.conf).  You have to have come across it via google or one of 
the layman discussions on the wiki or mailing lists, etc, which is why I 
knew about it.

But do be aware, laymansync only works with layman installed.  If it's 
not installed and sync-type is set to laymansync, attempts to sync will 
error out with unknown sync-type errors.

-- 
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