Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/04/2015 09:56 AM, Andrew Savchenko wrote:
> On Sun, 1 Nov 2015 14:53:20 +0100 hasufell wrote:
>>>> You shouldn't use rsync anymore, it is inherently insecure. The git
>>>> tree is _properly_ gpg signed so you can verify it's correctness.
>>>>
>>>> With the following portage configuration/hooks, any user can run the
>>>> tree directly from git:
>>>> https://github.com/hasufell/portage-gentoo-git-config
>>>
>>> More secure by fetching metadata cache via rsync ?
>>> Better by running egencache after each sync ?
>>> I don't think so.
>>>
>>
>> Yes it is.
> 
> No, it is not. The whole git tree is insecure and no better than
> rsync or CVS in terms of data security because SHA1 is vulnerable.
> 

Another one who is confusing _any_ collision with _preimage attack_ ;)

Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/04/2015 05:33 PM, Chí-Thanh Christopher Nguyễn wrote:
> hasufell schrieb:
>> On 11/04/2015 09:56 AM, Andrew Savchenko wrote:
>>> No, it is not. The whole git tree is insecure and no better than
>>> rsync or CVS in terms of data security because SHA1 is vulnerable.
>>>
>> Another one who is confusing _any_ collision with _preimage attack_ ;)
> 
> While Andrew's view is very pessimistic here, yours is decidedly
> optimistic.
> 
> There is no known computationally feasible preimage attack against MD5,
> still that hash function is broken in serious ways with attacks already
> having real-world consequences.
> 
> It would be quite naïve to assume that SHA1 will remain secure until a
> preimage attack is found.
> 

I didn't. Numerous crypto-analysts have already expressed that SHA-1 is
not future-proof.

However, saying "it is vulnerable" is simply exaggeration and suggests
people should do the math before posting such things.

We already had that discussion before the git migration and it is quite
pointless. If you want to improve the situation, go talk to git upstream
and send patches.

Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/04/2015 05:44 PM, Chí-Thanh Christopher Nguyễn wrote:
> hasufell schrieb:
> 
>> If you want to improve the situation, go talk to git upstream
>> and send patches.
> 
> Or do what Andrew suggested should happen.
> 
> 

If you want to break the whole git workflow yes. Good suggestion.

Re: [gentoo-dev] Re: ChangeLog

[hasufell]

On 11/03/2015 04:04 PM, Chí-Thanh Christopher Nguyễn wrote:
> Matt Turner schrieb:
>> The git transition had been 9 years in the making and has massively
>> improved Gentoo development. Look at the graph of contributions per
>> month: https://www.openhub.net/p/gentoo
> 
> I'd like to point out that some stuff that has previously been done in a
> single commit is now several commits (e.g. bump + removal of old
> version).

1. not all developers do that and I'd go so far to say that we shouldn't
dictate these detail too much. It has advantages, yes, but it doesn't
really break anything.

2. if you follow the github PRs you will clearly notice that people have
started to actively contribute in a way that wasn't possible on bugzilla
in the same way... there are no hard numbers, but as someone who had
been following the maintainer-wanted/needed aliases, I am pretty sure
the amount of contributions has increased considerably. You can also ask
the proxy-maintainers team, which has all hands full merging PRs.

So yes, git has improved the number of collaborations. It's hard to not
notice, unless you really don't want to notice.

Re: [gentoo-dev] Depending on a range of slots

[hasufell]

On 11/02/2015 09:51 PM, Michael Orlitzky wrote:
> On 11/02/2015 02:48 PM, Ciaran McCreesh wrote:
>> On Mon, 2 Nov 2015 14:33:57 -0500
>> Michael Orlitzky  wrote:
>>> Followup question, which of these is less dumb?
>>>
>>> Option 1: berkdb? ( >=sys-libs/db-4:*  >
>> This doesn't mean what you think it means. A user who has db-3 and db-7
>> installed satisfies that dependency.
>>
> 
> Indeed, thanks.
> 

That's an interesting pitfall. I am pretty sure we have this kind of
syntax a lot in the tree. Might make sense to document it.

Re: [gentoo-dev] Re: ChangeLog

[hasufell]

On 11/02/2015 10:54 PM, Dale wrote:
> Ciaran McCreesh wrote:
>> On Mon, 2 Nov 2015 14:00:18 -0600
>> Dale  wrote:
>>> Rich Freeman wrote:
 On Mon, Nov 2, 2015 at 1:08 AM, Dale  wrote:
> Then perhaps all this should have been worked out BEFORE switching
> to github?
 We didn't switch to github.
>>> Then why are people saying to use git to look at the logs?   I don't
>>> want to use git.
>> git != github...
>>
>>> I liked being able to go to the tree and look at the
>>> change logs when I needed to which is sometimes often.
>> I think you have a technology comprehension problem here, rather than a
>> technology problem. The problem is your workflow, not the tools.
>>
> 
> What I understand is this.  The logs since github started being used are
> no longer updated like they used to be.  I realize that git is a command
> but it seems that git gets its info from github since the logs are no
> longer downloaded when I sync the tree.

No. You should really read some tutorials/introductions on git to
understand how it works and this ML isn't the place for that. It's not
like SVN, so you don't even need an internet connection for the tree to
work (e.g. if you've copied it via USB even). Github is totally
unrelated here.

Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/01/2015 01:16 PM, Patrick Lauer wrote:
> Ahoi,
> 
> I'm getting mildly very irritated with the lack of easily accessible
> ChangeLogs for our packages.
> 
> Apparently updating them stopped some time in August, so now there are
> some outdated ChangeLogs that don't really serve any purpose, and the
> easiest way for users to figure out why something changed is to yell at
> the clumsy gitweb.g.o interface. So instead of grep we now need lots of
> patience.
> 
> This does not look reasonable to me.
> 
> Can we please either properly remove ChangeLogs and tell people to not
> be curious about changes, or make them useful again?
> 


ChangeLogs are a deprecated and unreliable method of the times we were
still on CVS. E.g. some people didn't find it useful to add ChangeLog
entries when they did large eclass changes. This problem is gone now.

git log -- app-misc/foo
or
git log -- eclass/autotools.eclass

will give you _any_ commit that has touched that file/directory, even if
it was part of a huge mass commit.

There's really not much ChangeLogs add for you here, except duplicating
git functionality. It's more useful to familiarize yourself with git
log. There's no reason to depend on the gitweb interface.

If you want the history from before the migration to work with that as
well, you can use this method:
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Grafting_Gentoo_History_Onto_the_Active_Repo

Also see
https://www.atlassian.com/git/tutorials/git-log/filtering-the-commit-history

Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/01/2015 02:47 PM, Alexis Ballier wrote:
> On Sun, 1 Nov 2015 14:33:07 +0100
> hasufell <hasuf...@gentoo.org> wrote:
>>>>
>>>> git log -- app-misc/foo
>>>> or
>>>> git log -- eclass/autotools.eclass
>>>>
>>>> will give you _any_ commit that has touched that file/directory,
>>>> even if it was part of a huge mass commit.  
>>>
>>>  $ cd /usr/portage/app-admin/rex/; git log
>>> fatal: Not a git repository (or any of the parent directories): .git
>>>
>>> sooo ... ???
>>>   
>>
>> You shouldn't use rsync anymore, it is inherently insecure. The git
>> tree is _properly_ gpg signed so you can verify it's correctness.
>>
>> With the following portage configuration/hooks, any user can run the
>> tree directly from git:
>> https://github.com/hasufell/portage-gentoo-git-config
> 
> More secure by fetching metadata cache via rsync ?
> Better by running egencache after each sync ?
> I don't think so.
> 

Yes it is. You have the option of generating it yourself (only takes
long for the first time) or fetch it from the following gentoo mirror
instead https://github.com/gentoo-mirror/gentoo

We might adjust those hooks to do that.

>> At some point, rsync schould be deprecated completely.
> 
> 
> Considering the original plan was to have changelogs auto-generated
> from git and still serving the tree via rsync, where's the relevant
> discussion and decision about this?
> 
> There's no technical reason for not doing this *today*, the only reason
> not to is the lack of decision and concrete plan on how to properly
> serve what is in the rsync'ed tree and not in gentoo.git.
> 
> 
> Until then, we are serving outdated and useless changelogs via rsync
> and Patrick's point still holds: Either remove them or serve proper
> ones.
> 

+1 for removing.

Re: [gentoo-dev] Gentoo-hosted code review

[hasufell]

On 11/01/2015 06:44 PM, Michael Palimaka wrote:
> There's been a lot of discussion about relying on GitHub for pull
> requests and code review and such, so I have set up a Phabricator
> instance against gentoo.git to see how a free alternative might work.
> 
> Here's a few examples of how things could work:
> 
> General post-commit review:
> http://phabricator.astralcloak.net/rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca
> 
> Tracking commits with issues that need attention:
> http://phabricator.astralcloak.net/audit/query/open/
> 
> Pre-commit review: http://phabricator.astralcloak.net/D1
> 
> Phabricator also has all sorts of fancy (optional) features that could
> be useful for collaborative development (see http://phabricator.org/ for
> more info).
> 
> What do you think?
> 
> 

phabricator is horrible. I'll definitely use it less (if at all) than
bugzilla.

Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/01/2015 02:51 PM, Мисбах-Соловьёв Вадим wrote:
>> You shouldn't use rsync anymore, it is inherently insecure. The git tree
>> is _properly_ gpg signed so you can verify it's correctness.
>>
>> With the following portage configuration/hooks, any user can run the
>> tree directly from git:
>> https://github.com/hasufell/portage-gentoo-git-config
>>
>> At some point, rsync schould be deprecated completely.
> 
> Nice try, but sometimes (say, in case of very unstable internet connection) 
> it is IMPOSSIBLE to properly sync git repo (because it tries to fetch all the 
> queue (between local HEAD and remote one) in a row, from the exactly same 
> place every time it fails), while it still possible to sync tree by rsync, 
> because it only fetches differences and do not drop properly downloaded files.
> 
> Do NOT (!) assume flawless shiny 40Gbit internet everywhere in the world. 
> Stop being so selfish and thinking only from position of the developer. 
> Always do imagine you as the gentoo user in the worst possible case.
> Please.
> 

git clone --depth=1 (you can also put that into your repos.conf, the
option is called 'sync-depth'). --depth is also available for regular pulls.

And thanks for calling me selfish for trying to make it possible for
users to directly use a git checkout as the local tree. I appreciate it. :)

Re: [gentoo-dev] ChangeLog

[hasufell]

On 11/01/2015 02:28 PM, Patrick Lauer wrote:
>>
>> ChangeLogs are a deprecated and unreliable method of the times we were
>> still on CVS. E.g. some people didn't find it useful to add ChangeLog
>> entries when they did large eclass changes. This problem is gone now.
> ... ?!??!#??$>@%%*%**%@!!!
> 
> From the point of view of a user ChangeLogs are VERY VERY USEFUL.
> 
> Why would you claim they are deprecated?

Because they are unreliable and we have a better method.

>>
>> git log -- app-misc/foo
>> or
>> git log -- eclass/autotools.eclass
>>
>> will give you _any_ commit that has touched that file/directory, even if
>> it was part of a huge mass commit.
> 
>  $ cd /usr/portage/app-admin/rex/; git log
> fatal: Not a git repository (or any of the parent directories): .git
> 
> sooo ... ???
> 

You shouldn't use rsync anymore, it is inherently insecure. The git tree
is _properly_ gpg signed so you can verify it's correctness.

With the following portage configuration/hooks, any user can run the
tree directly from git:
https://github.com/hasufell/portage-gentoo-git-config

At some point, rsync schould be deprecated completely.

Re: [gentoo-dev] Gentoo-hosted code review

[hasufell]

On 11/01/2015 08:50 PM, Manuel Rüger wrote:
> On 01.11.2015 20:23, hasufell wrote:
>> On 11/01/2015 06:44 PM, Michael Palimaka wrote:
>>> There's been a lot of discussion about relying on GitHub for pull
>>> requests and code review and such, so I have set up a Phabricator
>>> instance against gentoo.git to see how a free alternative might work.
>>>
>>> Here's a few examples of how things could work:
>>>
>>> General post-commit review:
>>> http://phabricator.astralcloak.net/rGENTOO27ba62d0c7fcabdc79ce82a064b43d67b3b11cca
>>>
>>> Tracking commits with issues that need attention:
>>> http://phabricator.astralcloak.net/audit/query/open/
>>>
>>> Pre-commit review: http://phabricator.astralcloak.net/D1
>>>
>>> Phabricator also has all sorts of fancy (optional) features that could
>>> be useful for collaborative development (see http://phabricator.org/ for
>>> more info).
>>>
>>> What do you think?
>>>
>>>
>>
>> phabricator is horrible. I'll definitely use it less (if at all) than
>> bugzilla.
>>
> 
> On 10.10.2015 16:15, Julian Ospald wrote:
>> That's a great start for us, having developers announce publicly that
>> they will ignore our project or require us to create bugs for every
>> missing "|| die" in an ebuild.
> 
> *chuckles*
> 
> 

I don't know how you confuse your ignorant behavior of blacklisting a
whole project with the liberty of gentoo developers to choose the
contribution platform which fits best for their use case (be it email,
IRC, bugzilla, phabricator or github).

But I didn't expect any different behavior from you. I think you should
re-read our CoC and stop posting mails that are just flame.

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

[hasufell]

On 10/30/2015 10:16 PM, Anthony G. Basile wrote:
> On 10/30/15 3:35 PM, hasufell wrote:
>> On 10/30/2015 06:55 PM, Michał Górny wrote:
>>> We have no way of saying 'I prefer polarssl, then gnutls, then
>>> libressl, and never openssl'.
>> I don't think this is something that can be reasonably supported and it
>> sounds awfully automagic. And I don't see how this is possible right
>> now, so I'm not really sure what you expect to get worse.
>>
>> E.g. -gnutls pulling in dev-libs/openssl is not really something you'd
>> expect. If we go for provider USE flags, then things become consistent,
>> explicit and unambiguous. The only problem is our crappy implementation
>> of providers USE flags via REQUIRED_USE.
>>
> I'm not sure what mgorny has in mind, but the problem I see with saying
> I want just X to be my provider system wide is that some pkgs build with
> X others don't, other pkgs might need a different provider.  So it might
> make sense to order them in terms of preference: X1 > X2 > X3 ... and
> then when emerging a package, the first provider in the preference list
> that works is pulled in for that package.
> 

Isn't that basically what the proposal B already was, except that we
don't use REQUIRED_USE for it but some sort of pkg_setup/pkg_pretend
function? I don't see how those ideas even conflict.

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

[hasufell]

On 10/30/2015 11:56 PM, Michał Górny wrote:
> On Fri, 30 Oct 2015 23:40:28 +0100
> hasufell <hasuf...@gentoo.org> wrote:
> 
>> On 10/30/2015 10:16 PM, Anthony G. Basile wrote:
>>> On 10/30/15 3:35 PM, hasufell wrote:  
>>>> On 10/30/2015 06:55 PM, Michał Górny wrote:  
>>>>> We have no way of saying 'I prefer polarssl, then gnutls, then
>>>>> libressl, and never openssl'.  
>>>> I don't think this is something that can be reasonably supported and it
>>>> sounds awfully automagic. And I don't see how this is possible right
>>>> now, so I'm not really sure what you expect to get worse.
>>>>
>>>> E.g. -gnutls pulling in dev-libs/openssl is not really something you'd
>>>> expect. If we go for provider USE flags, then things become consistent,
>>>> explicit and unambiguous. The only problem is our crappy implementation
>>>> of providers USE flags via REQUIRED_USE.
>>>>  
>>> I'm not sure what mgorny has in mind, but the problem I see with saying
>>> I want just X to be my provider system wide is that some pkgs build with
>>> X others don't, other pkgs might need a different provider.  So it might
>>> make sense to order them in terms of preference: X1 > X2 > X3 ... and
>>> then when emerging a package, the first provider in the preference list
>>> that works is pulled in for that package.
>>>   
>>
>> Isn't that basically what the proposal B already was, except that we
>> don't use REQUIRED_USE for it but some sort of pkg_setup/pkg_pretend
>> function? I don't see how those ideas even conflict.
> 
> And some sort of magical USE flag meanings? Please stop this right
> here. We don't need 16 USE flag package variants which mean 4 things in
> different, random and unexpected ways.
> 

I really have no idea what you mean. This is about NOT doing things
magically and not having magical USE flag meanings.

Then you complained that you cannot set gnutls and openssl at the same
time... and the only way around that is not having REQUIRED_USE.

It seems to me you don't really know what you want. Either give an
actual proposal or let us move on.

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

[hasufell]

On 10/30/2015 06:55 PM, Michał Górny wrote:
> 
> We have no way of saying 'I prefer polarssl, then gnutls, then
> libressl, and never openssl'.

I don't think this is something that can be reasonably supported and it
sounds awfully automagic. And I don't see how this is possible right
now, so I'm not really sure what you expect to get worse.

E.g. -gnutls pulling in dev-libs/openssl is not really something you'd
expect. If we go for provider USE flags, then things become consistent,
explicit and unambiguous. The only problem is our crappy implementation
of providers USE flags via REQUIRED_USE.

Re: [gentoo-dev] Re: ssl vs openssl vs libressl vs gnutls USE flag foo

[hasufell]

On 10/28/2015 12:23 PM, Anthony G. Basile wrote:
> 
> A properly designed sub-USE flag would be useful here and clearly better
> than our REQUIRED_USE.  I think REQUIRED_USE is fine for heterogeneous
> cases, but not when you have something like curl where you can either
> turn ssl on or off.  If it is off, nothing more needs to be specified,
> if it is on, then you must further specify one and exactly one ssl
> provider.
> 

Uhm, curl makes use of REQUIRED_USE heavily, otherwise the use_expand
would not work:
> REQUIRED_USE="
>   curl_ssl_winssl? ( elibc_Winnt )
>   threads? ( !adns )
>   ssl? (
>   ^^ (
>   curl_ssl_axtls
>   curl_ssl_gnutls
>   curl_ssl_libressl
>   curl_ssl_openssl
>   curl_ssl_nss
>   curl_ssl_polarssl
>   curl_ssl_winssl
>   )
>   )"

With the providers syntax from exherbo, this monster would basically be
gone.

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

[hasufell]

On 10/28/2015 09:36 AM, Alexis Ballier wrote:
> On Wed, 28 Oct 2015 03:06:59 +0100
> hasufell <hasuf...@gentoo.org> wrote:
>> A is not that difficult. Most uses of 'openssl' can just be replaced
>> with 'ssl', others probably with '!gnutls?' even. A few exotic ones
>> might stay and we will have to advice users to set USE="openssl
>> libressl" instead of USE="-openssl libressl".
>> B will definitely be more work, but ofc is also a lot cleaner and
>> totally unambigous.
> 
> 
> You haven't taken into consideration the licence incompatibilities:
> http://www.gnu.org/licenses/license-list.en.html#OpenSSL
> it gets really messy for libraries: a gpl binary linking against a
>library linking against openssl means the binary can be
>redistributed, but not with such a library linked against openssl...
> 
> the point of the 'openssl' useflag is to have something that is not
> enabled by default and that can be used in RESTRICT="openssl?
> ( bindist )" expressions...
> 


You can just do RESTRICT="ssl? ( bindist )" and disable bindist by
default or vote for solution B.

Re: [gentoo-dev] Re: ssl vs openssl vs libressl vs gnutls USE flag foo

[hasufell]

On 10/28/2015 07:23 AM, Ryan Hill wrote:
> 
> Agreed.  If there's one choice then "ssl" should be used.  
> openssl/libressl/etc
> should really be considered sub-flags of ssl.
> 
> I really wish we had some way of specifying this to make things clearer to the
> user, so they could see exactly how these flags interact with each other.
> Something like (emerge -pv):
> 

The problem here is that we introduced REQUIRED_USE foo for these cases
which is again highly ambigous instead of making the PM aware that this
is an actual sub-USE flag.

This is outside of the scope of this thread, but there are already
distros that have fixed this:
1. NixOS [0] with truly declarative configuration format, e.g. something
like:
packages.ssl.provider = openssl;

or somesuch (just an example)

2. Exherbo partly [1] with providers syntax:
*/* providers: -openssl libressl

and the exheres would then do something like:
DEPENDENCIES="
build+run:
providers:openssl?  ( dev-libs/openssl:0 )
providers:libressl? ( dev-libs/libressl )
"

which is a lot cleaner than USE_EXPAND + REQUIRED_USE, which still can
have arbitrary meanings.

But NIH will prevent us from learning here I guess.


[0] https://nixos.org/nixos/manual/
[1] http://exherbo.org/docs/eapi/providers-and-virtuals.html

Re: [gentoo-dev] Re: ssl vs openssl vs libressl vs gnutls USE flag foo

[hasufell]

On 10/28/2015 12:20 PM, Kristian Fiskerstrand wrote:
> On 10/28/2015 07:23 AM, Ryan Hill wrote:
> 
> 
>> Agreed.  If there's one choice then "ssl" should be used.
>> openssl/libressl/etc should really be considered sub-flags of ssl.
> 
> 
> If we are introducing a new and proper way to define this it might
> make sense to not refer to ssl (is anything actually using SSL these
> days? I certainly hope not), tls is the natural replacement unless we
> want to go for something more generic.
> 

That's nitpick for no gain and will break more configurations than any
of the previously suggested formats.

[gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

[hasufell]

I've seen a lot of ebuilds lately that use 'openssl' USE flag for the
purpose of enabling ssl features. I think this should be discouraged
since it introduces inconsistency and is especially confusing for
packages like media-video/ffmpeg, where'd you expect to get ssl support
by having the global ssl USE flag enabled.

Furthermore, some packages have started to do things like
REQUIRED_USE="^^ ( openssl libressl )"
which is even more inconsistent now and will make it very hard for
people to switch to libressl without figuring out a lot of blockers,
since we have conflicting meanings of 'openssl' now. One uses it as a
feature flag, the other as a provider flag.


We have two choices here afais to design the USE flag meanings and how
they are used by ebuild authors:

A) 1 feature flag, 2 lax provider flags, 1 strict provider flag
* ssl: enable any sort of SSL/TLS support
* gnutls: primarily to enable gnutls provided ssl support in case
  there is a choice
* openssl: primarily to enable openssl provided ssl support in case
   there is a choice (might be implemented as !gnutls? instead)
* libressl: switch the openssl provider to libressl _without_
conflicting with openssl, so any alternative usage of
'openssl' USE flag will not break the libressl dep-graph

consequences:
* REQUIRED_USE="^^ ( openssl libressl )" is _disallowed_
* packages like media-video/ffmpeg should switch the USE flag
  openssl->ssl to avoid confusing global user configuration, but it's
  not strictly disallowed


B) 1 feature flag, 3 strict provider flags
* ssl: enable any sort of SSL/TLS support
* gnutls: only to enable gnutls provided ssl support in case there
  is a choice
* openssl: only to enable openssl provided ssl support in case
   there is a choice (should not be implemented as !gnutls?)
* libressl: only to enable libressl provided ssl support in case there
is a choice, must conflict with 'openssl' USE flag

consequences:
* REQUIRED_USE="^^ ( openssl libressl )" is not only allowed, it is
  _mandatory_
* packages like media-video/ffmpeg _must_ switch the USE flag
  openssl->ssl to avoid breaking global USE flags
* !gnutls? ( dev-libs/openssl:0 ) will be bad form or even disallowed


A is not that difficult. Most uses of 'openssl' can just be replaced
with 'ssl', others probably with '!gnutls?' even. A few exotic ones
might stay and we will have to advice users to set USE="openssl
libressl" instead of USE="-openssl libressl".
B will definitely be more work, but ofc is also a lot cleaner and
totally unambigous.

I hope I didn't confuse anything here.

Re: [gentoo-dev] Non-fast-forward push to gentoo repository

[hasufell]

On 10/23/2015 09:59 PM, Luis Ressel wrote:
> On Wednesday, someone seems to have done a --force'd push to the gentoo
> repository. The commits
> * 5e04009 sci-mathematics/minisat: rev-bump and build fixes for latest,
>   QA cleanup
> * 9c9fce9 media-libs/urt: build fixes, QA cleanups, new shared lib
>   build, SRC_URI
> 
> are now missing from the repo, they were overwritten by
>   cbb7cfa sys-kernel/tuxonice-sources: Version bumps.
> 
> Was this intended? If not, @nerdboy: You might want to commit these
> changes again.

Nah, force pushes are not allowed. It seems someone has hit the "merge
button" at github. All those commits will ofc be overwritten by the
gentoo-bot which pushes from the actual repo to the github mirror.

So again: don't use the merge button.

[gentoo-dev] Re: [gentoo-commits] data/gentoo-news:master commit in: 2015-10-21-future-support-of-hardened-sources-kernel/

[hasufell]

On 10/21/2015 03:34 AM, Anthony G. Basile wrote:
> commit: 1ff602d951b09029917bcc5bf391cbe390772a7b
> Author: Anthony G. Basile  gentoo  org>
> AuthorDate: Wed Oct 21 01:31:55 2015 +
> Commit: Anthony G. Basile  gentoo  org>
> CommitDate: Wed Oct 21 01:40:43 2015 +
> URL:https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=1ff602d9
> 
> News item regarding future support of hardened-sources kernels.
> 
>  ...uture-support-of-hardened-sources-kernel.en.txt | 63 
> ++
>  ...e-support-of-hardened-sources-kernel.en.txt.asc | 17 ++
>  2 files changed, 80 insertions(+)
> 
> diff --git 
> a/2015-10-21-future-support-of-hardened-sources-kernel/2015-10-21-future-support-of-hardened-sources-kernel.en.txt
>  
> b/2015-10-21-future-support-of-hardened-sources-kernel/2015-10-21-future-support-of-hardened-sources-kernel.en.txt
> new file mode 100644
> index 000..f421440
> --- /dev/null
> +++ 
> b/2015-10-21-future-support-of-hardened-sources-kernel/2015-10-21-future-support-of-hardened-sources-kernel.en.txt
> @@ -0,0 +1,63 @@
> +Title: Future Support of hardened-sources Kernel
> +Content-Type: text/plain
> +Posted: 2015-10-21
> +Revision: 1
> +News-Item-Format: 1.0

[...]

This news item is missing an Author header, causing my PM to throw warnings.

GLEP42 also says it is a mandatory header.

https://wiki.gentoo.org/wiki/GLEP:42#News_Item_Headers

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/

[hasufell]

On 10/21/2015 07:21 PM, Ciaran McCreesh wrote:
> On Wed, 21 Oct 2015 01:25:53 +0200
> hasufell <hasuf...@gentoo.org> wrote:
>> Also, my package manager chokes on it. Repoman not, so that looks
>> like a bug.
> 
> s/Repoman/Portage/
> 
> Portage will quite happily let you specify KEYWORDS=":)".
> 

Yes, this has to be fixed. Bug reports are here:

https://bugs.gentoo.org/show_bug.cgi?id=563702
https://bugs.gentoo.org/show_bug.cgi?id=563642

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/

[hasufell]

On 10/20/2015 04:02 PM, Mike Frysinger wrote:
> commit: a68f2479fba9422913cb760166316bf489d72ca8
> Author: Vincent Palatin  chromium  org>
> AuthorDate: Tue Oct 20 14:01:34 2015 +
> Commit: Mike Frysinger  gentoo  org>
> CommitDate: Tue Oct 20 14:01:50 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a68f2479
> 
> dev-python/intelhex: new package from Chromium OS
> 
>  dev-python/intelhex/Manifest|  1 +
>  dev-python/intelhex/intelhex-2.0.ebuild | 18 ++
>  dev-python/intelhex/metadata.xml|  9 +
>  3 files changed, 28 insertions(+)
> 

[...]

> +
> +EAPI="5"
> +
> +PYTHON_COMPAT=( python{2_7,3_3,3_4,3_5} )
> +
> +inherit distutils-r1
> +
> +DESCRIPTION="Python library for Intel HEX files manipulations"
> +HOMEPAGE="http://pypi.python.org/pypi/IntelHex/ 
> https://github.com/bialix/intelhex;
> +SRC_URI="mirror://pypi/I/IntelHex/${P}.tar.gz"
> +
> +LICENSE="BSD"
> +SLOT="0"
> +KEYWORDS="*"

What does that KEYWORDS mean? Unless I read PMS wrong [0][1], this isn't
even allowed. And I don't see a single ebuild in the tree with that syntax.

Also, my package manager chokes on it. Repoman not, so that looks like a
bug.


[0] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-260003.1.6
[1] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-690007.3.2

[gentoo-dev] stabilization commits and atomicity

[hasufell]

I'd like to discuss whether we should allow/encourage stabilization
commits to be less atomic. They often bloat the history, make it hard to
skim through the summaries list and people who are looking for
stabilization probably do 'git log -- ' anyway, no? In
addition, I'm not sure the bug information where people post "stable"
comments is very useful.

At least, the previous commits on
  app-leechcraft/

could have been category-commits, since they all refer to the same thing
and the same bug.

I'd go so far to say allow people to do commits like:
"""
amd64 stabilizations


"""
possibly pre-pending the rough domain like "kde", if any. I think kde
herd already does that, no?

Unless someone thinks the mass-100+ commits are really useful in the
visible history.

Re: [gentoo-dev] stabilization commits and atomicity

[hasufell]

On 10/19/2015 04:37 PM, Ian Stakenvicius wrote:
> 
> 
> 
> It may be my lack of coffee this morning, but I think you and
> hasufell are saying the same thing but using "making commits less
> atomic" conversely.
> 
> Just so i make sure i'm understanding this right, hasufell's
> suggestion is to, instead of rolling a single "atomic" commit for
> every package being stabilized under a tracker bug, that the whole
> set of packages gets stabilized via one commit.  Thus ensuring one
> doesn't get half a kde update, and rollbacks can be done at a single
> commit level, etc.
> 
> Do I have this right?
> 
> (note, since all of these package changes are for a particular
> single purpose imo it would still be an atomic commit)
> 
> 

Well yes. But you could go one step further and argue that we can allow
the same thing when ago's scripts make 300 commits for 300 stabilization
bugs at once (same category or not).

The question is if stabilization needs to be atomic history-wise. It is
nothing you revert or cherry-pick anyway and you could consider it a
global commit too with the subsystem "stable arch".

Re: [gentoo-dev] stabilization commits and atomicity

[hasufell]

On 10/19/2015 07:37 PM, Rich Freeman wrote:
> 
> However, stabilizing a single package really is an impactful change.
> The fact that you're doing 100 of them at one time doesn't really
> diminish the impact of each one.  Any of them could break a system or
> need to be reverted.
> 

Since when do we allow reverting stabilization? The package needs to be
fixed and possibly revbumped instead.

Re: [gentoo-dev] stabilization commits and atomicity

[hasufell]

On 10/19/2015 07:52 PM, Rich Freeman wrote:
> On Mon, Oct 19, 2015 at 1:40 PM, hasufell <hasuf...@gentoo.org> wrote:
>> On 10/19/2015 07:37 PM, Rich Freeman wrote:
>>>
>>> However, stabilizing a single package really is an impactful change.
>>> The fact that you're doing 100 of them at one time doesn't really
>>> diminish the impact of each one.  Any of them could break a system or
>>> need to be reverted.
>>>
>>
>> Since when do we allow reverting stabilization? The package needs to be
>> fixed and possibly revbumped instead.
>>
> 
> It would really depend on the nature of the break.  If it is a serious
> upstream problem and no fix is available, then reverting might be the
> only practical solution.  It is of course not a preferred solution.
> 

I don't think we depend on 'git revert' in that case. KEYWORDS are
trivial changes (in terms of file diffs).

Re: [gentoo-dev] stabilization commits and atomicity

[hasufell]

On 10/19/2015 07:08 PM, Rich Freeman wrote:
> On Mon, Oct 19, 2015 at 11:27 AM, Ian Stakenvicius  wrote:
>>
>> Ahh, so what you're referring to here is stabilization of multiple
>> unrelated packages in a single commit..  ok..  i'm not so
>> comfortable with that idea..
> 
> Nor am I.  A commit should be a set of related changes.  Stabilizing
> all of KDE-n in one commit makes a lot of sense.  Stabilizing 5 random
> packages in one commit doesn't make sense.  By all means push them all
> at once, but don't commit them all at once.  It isn't like we have to
> pay for each commit.
> 

We already know that. But if e.g. ago runs his scripts at 00:00 with
~300 packages stabilized, the history (without git command line) on
github/gitweb will be fun to read (and people DO that).

The argument is that those are related changes to the subsystem "stable
arch" (and affect not random ebuild details, but stable arch only, as in
KEYWORDS). Ofc, people can still create atomic commits if the
stabilization is security related.

Re: [gentoo-dev] [RFC] Allow SLOT documentation in metadata.xml

[hasufell]

On 10/18/2015 08:21 PM, Alexis Ballier wrote:
> 
> 
> btw, once this is committed, please consider adding or asking for a
> repoman warning when subslot is defined but metadata.xml is not filled
> 

Almost forgot: it has been committed yesterday:
https://gitweb.gentoo.org/data/dtd.git/commit/?id=551e00fc42ed21f6a6ff6129b5b85e64725d9665

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[hasufell]

On 10/18/2015 01:43 PM, Rich Freeman wrote:
> On Sun, Oct 18, 2015 at 7:37 AM, hasufell <hasuf...@gentoo.org> wrote:
>> On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
>>> On Sat, 17 Oct 2015 14:49:36 +0200
>>> hasufell <hasuf...@gentoo.org> wrote:
>>>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>>>> What's the problem?
>>>
>>> Running autorecrap.
>>>
>>
>> You can do that with hooks too (which is not very clean tbh). But at
>> that point, you probably want to actually fork the ebuild in an overlay
>> if you need to mess with phase internals instead of relying on some
>> magic that the ebuild writer might or might not have done properly.
>>
> 
> This sounds like "if it isn't done perfectly it isn't worth doing."
> If you're going to start by assuming that devs will always design
> ebuilds incorrectly, then you might as well just fork all of Gentoo
> into your overlay.  :)
> 
> People already find epatch_user useful, and I think moving it to PMS
> will just make it more consistently useful.  Sure, there will be
> mistakes, but right now epatch_user is optional, and in the future it
> could be considered a QA issue.
> 

If you are messing with the build system in a patch, there is no
guarantee that eautoreconf will be enough. It might or might not be true
(see net-irc/hexchat for an example). Are we going to run eautoreconf
unconditionally then (which is exceptionally bad)? Maybe the ebuild
author doesn't even provide a live ebuild and there's no example for
doing the right thing wrt random build systems patches. How about other
build systems? You simply cannot do this properly.

I think we are encouraging bad practice with this feature by making it
part of PMS, causing users to file bugs because their random patches
don't work with someones ebuilds.

If people need to hack on ebuilds, there are already numerous ways to do
that, including doing it properly. Why add another one that is still not
consistently thought through?

EAPI shouldn't be patchwork.

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[hasufell]

On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
> On Sat, 17 Oct 2015 14:49:36 +0200
> hasufell <hasuf...@gentoo.org> wrote:
>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>> What's the problem?
> 
> Running autorecrap.
> 

You can do that with hooks too (which is not very clean tbh). But at
that point, you probably want to actually fork the ebuild in an overlay
if you need to mess with phase internals instead of relying on some
magic that the ebuild writer might or might not have done properly.

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[hasufell]

On 10/17/2015 02:24 PM, Michał Górny wrote:
> 
> 2. eapply_user really belongs in the PM, especially if it's run by
> default. And it needs patch applying function. And if we have to
> implement patch applying function anyway, we may as well make it public
> to avoid unnecessary duplication.
> 

Unreliable. The ebuild may define its own src_prepare function or the PM
might define eapply_user as a no-op, which is valid as per PMS.

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[hasufell]

On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote:
> 
> The other question is more critical -- could you merge eapply and
> eapply_user? Or add some hook to PMS so that eapply_user isn't needed?
> IOW, it'd be nice if every package was, by default, patchable by the user.
> 

IMO, eapply_user should not be in the eclass and not in PMS. patches are
something that can easily be done via PM hooks, if the PM has proper
hooks support.

These hooks can be documented on the wiki (and partly are already).

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[hasufell]

On 10/17/2015 02:38 PM, Rich Freeman wrote:
> On Sat, Oct 17, 2015 at 8:25 AM, hasufell <hasuf...@gentoo.org> wrote:
>> On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote:
>>>
>>> The other question is more critical -- could you merge eapply and
>>> eapply_user? Or add some hook to PMS so that eapply_user isn't needed?
>>> IOW, it'd be nice if every package was, by default, patchable by the user.
>>>
>>
>> IMO, eapply_user should not be in the eclass and not in PMS. patches are
>> something that can easily be done via PM hooks, if the PM has proper
>> hooks support.
>>
> 
> The reason this was done was to give maintainers more control over
> WHEN patches are applied, while still ensuring they are applyied.
> 

You can apply the patches post_unpack or post_src_prepare witht hooks.
What's the problem?

Maintainers might forget to add it, add it in the wrong order or the PM
doesn't support it. So people who want consistent patch support already
HAVE to use hooks and that will not change. So you could as well remove
eapply_user/epatch_user altogether.

> The other feature that is supposed to be in EAPI6 (I didn't read the
> draft yet) is that the PM should refuse to install the package if
> eapply is never called (ie src_prepare is overridden and the ebuild
> didn't call eapply).  It is required that all ebuilds call it once
> unconditionally.  That way users don't get inconsistent behavior from
> package to package and be dependent on maintainers to fix it.
> 

I hope that "feature" doesn't make it into EAPI6.

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[hasufell]

On 10/17/2015 02:52 PM, Ulrich Mueller wrote:
>>>>>> On Sat, 17 Oct 2015, hasufell  wrote:
> 
>>> 2. eapply_user really belongs in the PM, especially if it's run by
>>> default. And it needs patch applying function. And if we have to
>>> implement patch applying function anyway, we may as well make it
>>> public to avoid unnecessary duplication.
> 
>> Unreliable. The ebuild may define its own src_prepare function
> 
> That eapply_user is called can be enforced by repoman, or by a QA
> warning.
> 

And still doesn't give sufficient control to the user. Documenting
proper hooks is more useful.

>> or the PM might define eapply_user as a no-op, which is valid as
>> per PMS.
> 
> Sure, it is implementation defined. Otherwise PMS would have to
> specify all the details, e.g. where does the package manager look
> for user-supplied patches and how are patch directories organised.
> 

So either do it, or just remove it from EAPI=6.

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[hasufell]

On 10/17/2015 02:56 PM, Rich Freeman wrote:
> On Sat, Oct 17, 2015 at 8:49 AM, hasufell <hasuf...@gentoo.org> wrote:
>>
>>> The other feature that is supposed to be in EAPI6 (I didn't read the
>>> draft yet) is that the PM should refuse to install the package if
>>> eapply is never called (ie src_prepare is overridden and the ebuild
>>> didn't call eapply).  It is required that all ebuilds call it once
>>> unconditionally.  That way users don't get inconsistent behavior from
>>> package to package and be dependent on maintainers to fix it.
>>>
>>
>> I hope that "feature" doesn't make it into EAPI6.
>>
> 
> The council already voted it in, but of course the final spec requires
> approval.  I don't intend to approve it without it, unless somebody
> makes a REALLY good case for it.
> 
> Why wouldn't you want this, anyway?  You're advocating for having the
> PM do it 100% of the time, and simultaneously arguing that if it is
> done via a call in the ebuild it shouldn't be 100% consistent.  Those
> positions do not seem consistent, unless you just want EAPI6 to be
> broken so that you can argue for EAPI7 or whatever.
> 

Nah. I'm just saying it isn't as useful as you think it is. Bothering
maintainers with such fatal warnings is just a minor nuisance.

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[hasufell]

On 10/17/2015 03:47 PM, Alexis Ballier wrote:
> On Sat, 17 Oct 2015 14:49:36 +0200
> hasufell <hasuf...@gentoo.org> wrote:
> 
> [...]
>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>> What's the problem?
> 
> autoreconf
> 

Can you elaborate why this would be a problem?

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[hasufell]

On 10/17/2015 03:07 PM, Ulrich Mueller wrote:
>>>>>> On Sat, 17 Oct 2015, hasufell  wrote:
> 
>> And still doesn't give sufficient control to the user. Documenting
>> proper hooks is more useful.
> 
> Nothing prevents the PM from implementing eapply_user() as a hook.
> 

Whether that will be the case is undefined.

My points about eapply_user() are:
* may not be implemented by a given PM at all
* only works for EAPI=6 and not for previous EAPIs
* for previous EAPIS epatch_user is not consistently used for the whole
tree and cannot be relied upon
* the entry point is defined by the ebuild, not by the user, so less
control (e.g. there are cases where you would even want to apply patches
pre_src_compile)
* requires fixing a lot of ebuilds with the chance of introducing
"bugs", because eapply_user is called in a weird place
* unreliable for overlays (either because they don't call eapply_user,
do it wrong, use an older EAPI or do other funky stuff)
* configuration format/locations will be dictated by the PM, which may
or may not be sufficient for the user

Because of that, no one who wants consistent user-patch support will
want to rely on epatch_user alone and even less on eapply_user. I think
it's a waste of time, but it certainly does not affect me, since I will
just keep doing the same thing with hooks or overlays.

But if we follow simplicity, it makes sense to just drop this idea,
since there already is a solution that works consistently and in the way
the user intends.

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[hasufell]

On 10/15/2015 03:26 PM, Michael Orlitzky wrote:
> On 10/14/2015 11:39 PM, Mike Frysinger wrote:
>> iputils is currently in @system for everyone.  by default, it only
>> installs `ping`.  do we feel strongly enough about this to require
>> all systems include it ?  or should this wait for the long idea of
>> releasing stage4's instead of stage3's ?
>> -mike
>>
> 
> Get rid of it. The @system set isn't for "stuff a lot of people want
> installed."
> 
> 

+1

Re: [gentoo-dev] [PATCH] metadata: add slots element

[hasufell]

On 10/13/2015 09:51 AM, Alexis Ballier wrote:
> 
> that would work too, but dtd provides standardization, and avoids
> duplicating package-wide information (meaning of slot/subslot) in every
> single ebuild.
> 

Yeah, the only thing that I wasn't sure about is the subslots part. With
the proposed patch we don't document a subslot for a specific slot, but
for the whole package. Everything else looked too complicated/ugly in
xml and I'm not sure we even need it. If someone has a better idea,
please speak up.
I think it should be kept simple, because we want devs to fill in this
kind of information, not confuse them.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 06:44 AM, wraeth wrote:
> 
> I am aware of this and that it has been the way for quite
> some time. However, while it may be the norm in the wider FOSS
> community, it has not been the norm on the gentoo-dev list - certainly
> people will post things specifically for review, or may highlight
> critical issues; but it has not until recently been a channel for review
> of any and all commits that the Reviewers inspect.
> 
> It is not the fact that there is a review or education process, but that
> this process was executed with the level of tact and grace becoming of a
> flock of ducks flying into the side of a building.
> 
> This education process was implemented in a way that indiscriminately
> pointed the finger at contributors, developer and user alike, sometimes
> for things that mattered, and other times for things that simply didn't.
> What's more, it was implemented without warning and included publishing
> who the author of those mistakes was without the contributor knowing
> that it would be used so (you know, since the whole commit header was in
> this educational message, too).
> 

We already have been working on making an internal policy about _how_
and _where_ to review.

https://wiki.gentoo.org/wiki/Project:Reviewers/Internal_policy

> 
> What I am saying is that until now contributors to Gentoo have received
> feedback on their work in channels that they elected, whether it was
> IRC, Bugzilla, Pull Requests or E-Mail; until suddenly their work (or
> more accurately, the Reviewers teams issues with their work) were
> getting broadcast to anyone who is subscribed to this list, regardless
> of if that contributor wanted that kind of public critiquing.
> 

And another point that I have to make very clear... while we are
certainly trying to find the best suited channel for reviews, the
selection of which one is the best is definitely _not_ about "how do I
minimize public exposure?", but "where is this review relevant?" and
"where does the author of the patch respond to most quickly?".

And frankly, if "public exposure" is a problem for you, then that's
something you have to work on if you like to contribute to FOSS. It's
not personal, it's technical. We will definitely not keep a list of
people who are afraid that a review of their code is posted somewhere
more public (assuming that the ebuild is already GPL-2 or similar and
public). But we'll try to post it where it is relevant and where the
author will respond... if that place is private mail, then so be it, but
again... we'll not keep a list for that around. And it will be a
learning experience for us too to figure out how to approach this best,
including the correct place, the amount of nitpicking and so on. You
cannot expect that everything happens at day 1.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 06:56 AM, Matt Turner wrote:
> 
> So work with the reviewers to ensure the communication is tactful and 
> graceful.
> 

That would be appreciated. So far, we mostly got people complaining (and
some setting up sieve filters to throw all our mails to trash), but not
people offering help. The latter has a bigger chance of actually having
an impact.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 04:12 PM, Ian Delaney wrote:
> On Mon, 12 Oct 2015 15:47:19 +0200
> hasufell <hasuf...@gentoo.org> wrote:
> 
>> On 10/12/2015 03:29 PM, Ian Delaney wrote:
>>>
>>> Not sure how to read this. The whole idea is for provider / client
>>> to communicate and negotiate a workable solution. At a glance this
>>> reads as the user needs to adapt to the service that the client is
>>> offering and appease the provider. What's wrong with this picture?
>>>
>>> How exactly may I ask does anyone actually offer help to the
>>> Reviewers project whose whole aim it seems is to help all us who
>>> cannot write ebuilds right?
>>>
>>
>> Nowhere did way say that people cannot write ebuilds, nor did we
>> impose that picture. That all happened in your own mind.
>>
> 
> Yes Julian. Neither did I Julian. I said 'who cannot write ebuilds
> RIGHT'. Please stop taking words out of my mouth and distorting my
> message.
> 

I'm not a native speaker and people have more than once told you that
your language is difficult to understand.

So, can you elaborate what your sarcastic (that's how I read it)
anecdote was meant for then? Preferably off-list, since this doesn't
seem to help any of us.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 03:51 PM, Rich Freeman wrote:

> That's why I
> suggested a top-5 list or something like that, which would have weeded
> out false positives and focus more on resolutions and trends than
> individual incidents.
> 

https://wiki.gentoo.org/wiki/Project:Reviewers/Common_issues

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 03:58 PM, wraeth wrote:
> I don't expect everything to have been within the N^th degree of
> perfection from day one; and I honestly hope the Reviewers project
> finds its feet and benefits the community; I just believe that it's
> first day could have been handled better.
> 

We've had that discussed a hundred times now, can we move on? Because
honestly, I don't see how this gets us any further.

If you want to help, do reviews, suggest project page changes, propagate
the project.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 03:41 PM, Alexis Ballier wrote:
> 
> They might have failed to notify it,

I did that 2 hours ago already on this thread. What does that tell us ;)

 but I think they've taken into
> account most, if not all, of the problems that had been pointed out:
> https://wiki.gentoo.org/wiki/Project:Reviewers/Internal_policy
> 
> 

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 03:29 PM, Ian Delaney wrote:
> 
> Not sure how to read this. The whole idea is for provider / client to
> communicate and negotiate a workable solution. At a glance this reads
> as the user needs to adapt to the service that the client is offering
> and appease the provider. What's wrong with this picture?
> 
> How exactly may I ask does anyone actually offer help to the Reviewers
> project whose whole aim it seems is to help all us who cannot write
> ebuilds right?
> 

Nowhere did way say that people cannot write ebuilds, nor did we impose
that picture. That all happened in your own mind.

Your picture about our goals is completely incorrect and you seem to
respond to something that's not really our project. So I'd like to ask
you to take a few moments and actually read our replies and the project
page, before we derail even further here.

Re: [gentoo-dev] [PATCH] metadata: add slots element

[hasufell]

On 10/12/2015 07:49 PM, Alexis Ballier wrote:
> On Mon, 12 Oct 2015 19:19:33 +0200
> Julian Ospald  wrote:
> 
>> There seems to be some general confusion about specific package SLOTs
>> and their meaning, since there can be several naming schemes applied
>> and documentation is either non-existent or is inside the ebuild via
>> comments.
>> Because of that it should be part of metadata.xml.
> 
> 
> Why not, but what's the advantage of xmlizing it vs comments in the
> ebuilds?
> 

Because metadata.xml is the place for metadata and has a defined,
verifiable and useful (in terms of actual processing/parsing data) form.

Even if you want those things to be in the ebuild, it would definitely
not be comments, but actual syntax (like exheres).

So basically the same arguments for not having random comments for USE
flags in the ebuilds apply.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/11/2015 09:52 AM, Ian Delaney wrote:
> 
> To my observation the reaction to this has been between displeasure and
> dismay.  Yesterday the dev-ML was flooded with the first day's
> publication of the members' reviews. Firstly the gentoo-commits ML to my
> understanding is intended to be used for and by qa members. This
> project has one whom we presume has the discretion to declare the use
> of the qa hat at whim.
> 

People have been responding to gentoo-commits ML on dev ML since years.
But mostly on smaller scale. I have no knowledge that this is restricted
to QA members.

The reason this dev-ML attempt was chosen is that we got very hostile
and aggressive opinions about our Github activity, telling us it is not
only against the social contract, but also not properly "public" and
everything in gentoo should be public on our own infra channels (they said).

So it seems... however you do it, you do it wrong. Github reviews are
not on our own infra channels, private mails are not public, don't spam
bugzilla, don't spam the ML... It's not particularly easy to not do it
wrong when you have so little options.

I suspect this is not even primarily about the chosen platform, but
about the fact that review culture can introduce a few negative thoughts
such as embarrassment. In order to fix that, we are going to focus the
reviews on Github (for developers who are known to be active there),
private mails and semi-private mails to aliases. In addition, it will
also require a shift of thinking. Reviews are not about exposing a
person, but about improving quality and knowledge. For both parties.

But I guess I have to make one point very clear again: we are not
affiliated with the QA team and this is an attempt to induct peer
reviews (even when private), since this has never happened on larger
scale in gentoo and people were just reverse-fixing mistakes instead of
communicating them in the first place. Which means a great loss for our
self-education.

So it seems a lot of people have got it wrong what the project is about.
It's specifically and explicitly not what the QA team is about, which we
said from the very start. It's not about a reviewers monopoly. It's
about the opposite.

> As someone once put it, it's not the product or message it's the
> delivery of the package

Yeah, so we can either dwell on that or start looking at the actual
product, which I'd expect from the gentoo community.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/11/2015 09:19 AM, Sven Vermeulen wrote:
> 
> This is good news. There are quite a few developers that manage a small
> subset of packages while doing tremendous work for Gentoo within that
> community. For instance, they focus on particular deliverables in
> repositories which eventually get packaged, or on integration of certain
> components which have a strong, broader community coverage.
> 
> These developers will certainly welcome any helping hand (even post-commit)
> in keeping packages of high quality.
> 
> I hope you will also focus on the documentation side. Certain processes that
> we follow within Gentoo (for commits, for instance the Git workflow) would
> benefit from a good document *set* (yes, set, as you'll definitely want such
> processes to have both a single-screen version as well as an elaborate
> version).
> 
> I've also found myself often looking for similar ebuilds in which a certain
> problem would already have been implemented. For instance, ebuilds with an
> optional python part using the python-r1 eclass. Do you think it is
> worthwhile to have a number of packages assigned as good examples?
> 

Those are great ideas, unfortunately we currently don't have a wiki guru
in the team ;)

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/10/2015 05:34 PM, Alexis Ballier wrote:
> 
> It is no secret that I don't care about "hats" :)
> If someone is right, he's right, a QA hat doesn't make something wrong
> magically right. Also, if you'd ask me, QA should be more about Quality
> Assurance, meaning training people, writing docs, fixing trivial
> stuff, helping devs to improve; which implies reviewer project fits
> perfectly. "you must do this" statements shouldn't even be needed, and
> are completely useless in a volunteer-based project anyway :)
> 

QA has the right to remove commit access, so I'm not sure I agree. But I
certainly don't think this is anything important for the Reviewers
project, since the goal is not to remove peoples commit access, but to
teach each other. So I also don't see why we should be affiliated with
the QA project. Since the only difference would be that said power,
which I am not interested in.

In addition, conflicting projects are explicitly allowed in Gentoo as
per GLEP 39, see https://wiki.gentoo.org/wiki/GLEP:39#Specification

>> This is just a concept of peer-reviewing, which was very difficult in
>> CVS times.
> 
> I fail to see how post-commit reviews are made easier with git.
> 

Quite offtopic, but we could discuss this off-list if you want.

> [...]
>>> Also, you should probably focus on what's really important: reviews
>>> like "this is weird, care to explain?" or stylistic nitpicks are
>>> just a waste of every one time, meaning more important stuff does
>>> not get done.
>>>
>>
>> 'has_version' (which you are probably referring to) as a conditional
>> for sedding headers is more than just "weird" and indicates a serious
>> build system bug that needs to be addressed properly.
> 
> It indicates a conditional fix. Just as the code says.

It's a hack, not a fix. And as such, it is worth discussing.

> Before throwing
> an email to -dev ml, I would have expected a reviewer to do his homework
> and try to understand what the condition is, when it will be satisfied,
> and why this was conditional. There is absolutely nothing wrong about
> not knowing the answer, but using -dev ml for it is a bit spammy IMHO.
> 

I did have a look. I was checking both packages (dev-libs/libcdio and
dev-libs/libcdio-paranoia) for the header and made up my own mind about
this. I was still wondering if the maintainer even knows what this is about.

So, maybe you should be more careful with throwing accusations around if
people did their homework or not ;)

And that is certainly something the reviewers will not do. For any given
review, it will be irrelevant who wrote the code.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/10/2015 04:27 PM, Alexis Ballier wrote:
>> The side goal is to review current Gentoo commits for major QA
>> violations and other issues, aiming at improving the quality of
>> ebuilds in Gentoo and helping other developers using bash, ebuilds
>> and git effectively.
> 
> This is completely unrelated: since we've had gentoo-commits ml,
> every one has been able to do commit reviews easily, and most devs have
> done so. Self-proclamed reviewers project certainly does not have the
> monopoly of best practices nor perfect knowledge. I hope they do keep
> the monopoly of being harassing though :)
> 

We are not a subproject of the QA team and have no hats to throw around.
Nothing we say is a "you must do this" statement. Only QA can do that.

This is just a concept of peer-reviewing, which was very difficult in
CVS times.

The project isn't even strictly requried, but just an attempt to
formalize this and maybe make other people do it too.

> Also, you should probably focus on what's really important: reviews
> like "this is weird, care to explain?" or stylistic nitpicks are just a
> waste of every one time, meaning more important stuff does not get done.
> 

'has_version' (which you are probably referring to) as a conditional for
sedding headers is more than just "weird" and indicates a serious build
system bug that needs to be addressed properly.
has_version also doesn't always work as someone might think it works.

But I agree. We'll work on project policies in the next few days
probably. But the scope will definitely not just be "build failures".

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgit2/

[hasufell]

On 10/10/2015 03:54 PM, Manuel Rüger wrote:
> 
> Dear Julian,
> 
> avoiding this mailing list for further reviews is great news.
> Still, I'd like to opt-out from receiving any mails arising from project
> "Reviewers".
> If there are QA-related issues with packages, I maintain, please file a
> bug on bugs.gentoo.org.
> 

That's a great start for us, having developers announce publicly that
they will ignore our project or require us to create bugs for every
missing "|| die" in an ebuild.

Not everything belongs on bugzilla. If there are common mistakes (e.g.
missing SLOT :0 on openssl, libpng, jpeg and whatnot), we might still
post them here, so that people are made aware of that. And that also has
happened recently (I'd say not even half of the ebuilds I was looking at
during my libressl work had a correct openssl depstring).

Knowing that you will ignore all those mails is very motivating. I'll
leave it to your own consideration whether that is in accordance with
our CoC/social contract. But ignoring each other is already very common
in gentoo and accepted practice, so what can I say.


Nevertheless, we'll try to continue, reduce public noise and keep the
reviews useful.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: /

[hasufell]

On 10/10/2015 11:29 AM, Andreas Hüttel wrote:
> commit: a33ebdd225fcf82f3e81a81f676de007bdecd670
> Author: Andreas K. Huettel (dilfridge)  gentoo  org>
> AuthorDate: Sat Oct 10 09:30:20 2015 +
> Commit: Andreas Hüttel  gentoo  org>
> CommitDate: Sat Oct 10 09:30:20 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a33ebdd2
> 
> Merge branch 'master' of git+ssh://git.gentoo.org/repo/gentoo
> 
>  app-admin/conky/conky-1.10.0.ebuild|  2 +-
>  app-portage/g-sorcery/g-sorcery-0.2.1.ebuild   |  2 +-
>  app-portage/g-sorcery/g-sorcery-0.2.ebuild |  2 +-
>  media-tv/xawtv/files/xawtv-3.95-stdbool.patch  | 10 
>  media-tv/xawtv/xawtv-3.95-r3.ebuild|  1 +
>  media-video/cinelerra/cinelerra-20140710.ebuild|  4 ++-
>  .../cinelerra/files/cinelerra-asm-gcc52.patch  | 15 +++
>  .../cinelerra/files/cinelerra-putbits-gcc52.patch  | 29 
> ++
>  net-misc/redir/metadata.xml|  6 +++--
>  profiles/arch/arm/package.use.mask |  6 -
>  10 files changed, 70 insertions(+), 7 deletions(-)
> 

You should (almost) never commit reverse-merges of git.gentoo.org master[0].

Instead, you have to use
git pull --rebase=preserve origin master

in case you get "push conflicts" [1]


[0] https://wiki.gentoo.org/wiki/Gentoo_git_workflow#About_merging
[1] https://wiki.gentoo.org/wiki/Gentoo_git_workflow#About_rebasing

The wording needs to be improved a bit, though.


You can also use "gitk" (tk USE flag of git) to have a more visualized
form of the history before you push.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: /

[hasufell]

On 10/10/2015 01:33 PM, Andreas K. Huettel wrote:
> 
>> You should (almost) never commit reverse-merges of git.gentoo.org
>> master[0].
> 
>> Instead, you have to use
>> git pull --rebase=preserve origin master
> 
>> in case you get "push conflicts" [1]
> 
> 
> Which I tried several times, but git steadfast refused to sign the commit 
> properly. Maybe a new bug somewhere?
> 

What was the error message? Can you reproduce that with a few test commits?

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lisp/sbcl/

[hasufell]

On 10/10/2015 06:56 AM, Andrey Grozin wrote:
> commit: 286567c6d64830eb810dee92bad0038b4b91f50d
> Author: Andrey Grozin  gentoo  org>
> AuthorDate: Sat Oct 10 04:50:18 2015 +
> Commit: Andrey Grozin  gentoo  org>
> CommitDate: Sat Oct 10 04:50:18 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=286567c6
> 
> dev-lisp/sbcl: bump to 1.2.16
> 
> Package-Manager: portage-2.2.22
> 
>  dev-lisp/sbcl/Manifest   | 1 -
>  dev-lisp/sbcl/sbcl-1.2.16.ebuild | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/dev-lisp/sbcl/Manifest b/dev-lisp/sbcl/Manifest
> index e52a23a..bcc4751 100644
> --- a/dev-lisp/sbcl/Manifest
> +++ b/dev-lisp/sbcl/Manifest
> @@ -8,7 +8,6 @@ DIST sbcl-1.1.18-source.tar.bz2 4272315 SHA256 
> 933238392a2a3533b4088b86c4fbd0704
>  DIST sbcl-1.1.18-x86-64-linux-binary.tar.bz2 9196684 SHA256 
> c945406f9421736982efc4eaaeb376b19331422f5b5a349382ed53c742d6cb0a SHA512 
> d63a33532ae6390c00d789c22c4a504b621e707b8aa5f72d12b497be8a590a75604a18f384fa2d27df3a4a0ef3ecd4c27e7bfc4f74fde3a014df1aad5dd8ff0c
>  WHIRLPOOL 
> 980726e0dd182c2b29c5ac4deab994d028e0003a3e2ac3e38a0c052f6607fc75f6b298fb60c99ff9f373c9ba1f243d6bd97de2cb765aad559867598affd510ab
>  DIST sbcl-1.1.6-x86-darwin-binary.tar.bz2 9091955 SHA256 
> 5801c60e2a875d263fccde446308b613c0253a84a61ab63569be62eb086718b3 SHA512 
> 5b9d58ba1a7bcf3aa5011ac5ba1c8dba65e44b2c3f8a31b15db54de6b34ea0f7482c45f1cc4e1323e154ce79fbba030112df3795cb323bca46bac50f15d2a138
>  WHIRLPOOL 
> 673e84bbf685e07568530ccb2c3822dbfffd6226d3de90bfef13078466ae245f63dd2fc4ac48b4d64ca1453cc831ad6913af21540bd3b35fe51700161ca26086
>  DIST sbcl-1.1.8-x86-64-darwin-binary.tar.bz2 9045228 SHA256 
> 729054dc27d6b53bd734eac4dffeaa9e231e97bdbe4927d7a68c8f0210cad700 SHA512 
> d29cf032dd52b014fcc5c48fc5dd0a1f8065838cd9078d129742302c64263b7d630232d1f9c051b56b8b2b34f1bef338aeaf81ff827799032e44ca6165483e34
>  WHIRLPOOL 
> f44112707f000a46d26a6af65e651868639beddab4be9c84c8f2bc8488f198ab661cb6aa62f1d38fbcbe48f259c0c2e54d255ae45db22f648b564f104984
> -DIST sbcl-1.2.11-x86-64-darwin-binary.tar.bz2 10038928 SHA256 
> 057d3a1c033fb53deee994c0135110636a04f92d2f88919679864214f77d0452 SHA512 
> c271796f854fe884e0d8aa6504bbe2e6c078de1555fc9a823463640cfd8c793dbddcb3f32932788d84a41e2b8a085b95c97c13a15c43fc909dcaad18ce25f215
>  WHIRLPOOL 
> 2c39d1ac1490693b758b54b473970deaa9078f00bc579745fbbed169e696846fda888f105bc77d610a8cb1c0f995c6e6ad572b9163d55b3701db02f7f68824b8
>  DIST sbcl-1.2.13-source.tar.bz2 5567609 SHA256 
> e6d93a94cbf821b2c500a9440ca640588e9ac6914dba2f6b5445a5e14eeb1205 SHA512 
> f5f7bfb9e8c6a3dcf8c1bac62dba9ca1385b9689141c24951bec95ee5383f53e4279dd5c3fb382a79b06ef113d3d4aaa3b05fff69f8a819a0988ba03983c0c48
>  WHIRLPOOL 
> 260de2f717544f4e9678b3e40bf59b16d83e3cdfad681c4a9e94fba9ec312a7647243a41076a9e64caa9ebfe33515561c854b939561019f14a3d07faf2425197
>  DIST sbcl-1.2.13-x86-64-linux-binary.tar.bz2 10154344 SHA256 
> 900e58adb9a449e3b5177207908a361de71be1e3aec712aff731ba9a9903f3ab SHA512 
> 483aafc9b38cf317ea764d66e1faf70560cca4c04355ae0a0669692c985034335ec155fc9557acab8cc5f2ee668615985950b2fa96d0acc900b74aceeeafb64c
>  WHIRLPOOL 
> bc9218f7a32194a19b12cd218b2ebfb1dbce01717289241ba62a1b39a424fc2d0620c80b536d1c0a605322e99c52ae0f01d943bd93b7e4c1388ae9b7ab7464bc
>  DIST sbcl-1.2.14-source.tar.bz2 5565538 SHA256 
> b9146dd6460c05bca508f6dda83003580911833eedd51dbc09d8eca80b0f5c06 SHA512 
> 471b215419f9303e010cbfb99866e09a43cc68a63680b5267662a12585b145b9f520592c37c81eabfe81b102255cd82fabb74cca731d8c3eed50747df34a6e2c
>  WHIRLPOOL 
> e89cd4c2ff1b2716c0ba62aed6d2107f05094c053c91db8a14638a80a5b63f83102fc1c125164edf251ed2ca507e00c298a9278efe83ad5f3b27ab53ddd48131
> 
> diff --git a/dev-lisp/sbcl/sbcl-1.2.16.ebuild 
> b/dev-lisp/sbcl/sbcl-1.2.16.ebuild
> index 3ff88d6..a4a2469 100644
> --- a/dev-lisp/sbcl/sbcl-1.2.16.ebuild
> +++ b/dev-lisp/sbcl/sbcl-1.2.16.ebuild
> @@ -14,7 +14,7 @@ BV_ALPHA=1.0.28
>  BV_ARM=1.2.7
>  BV_PPC_MACOS=1.0.47
>  BV_X86_MACOS=1.1.6
> -BV_X64_MACOS=1.2.11
> +BV_X64_MACOS=1.1.8
>  BV_SPARC_SOLARIS=1.0.23
>  BV_X86_SOLARIS=1.2.7
>  BV_X64_SOLARIS=1.2.7
> 

I am a bit confused how this is a bump to "1.2.16". Is just the commit
message wrong or what happened here?

There was a bump in c473e4fcbe3a17d7bc98d3fa1c19624687774165 afais.

And why was BV_X64_MACOS changed?

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-sound/qmmp/

[hasufell]

On 10/10/2015 12:52 PM, Markos Chandras wrote:
> commit: 7afe3acf2ff141d2940f2e02b6e232331d93f68e
> Author: Markos Chandras  gentoo  org>
> AuthorDate: Sat Oct 10 10:51:13 2015 +
> Commit: Markos Chandras  gentoo  org>
> CommitDate: Sat Oct 10 10:51:37 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7afe3acf
> 
> media-sound/qmmp: Version bumps for Qt4 and Qt4 releases
> 
> Drop ppc from qmmp-1.0.0(Qt5) because they don't have
> Qt5 keywords
> 

[...]

> diff --git a/media-sound/qmmp/qmmp-0.9.2.ebuild 
> b/media-sound/qmmp/qmmp-0.9.2.ebuild
> new file mode 100644
> index 000..5f82a4d
> --- /dev/null
> +++ b/media-sound/qmmp/qmmp-0.9.2.ebuild

[...]

> +
> +src_prepare() {
> + if has_version dev-libs/libcdio-paranoia; then
> + sed -i \
> + -e 's:cdio/cdda.h:cdio/paranoia/cdda.h:' \
> + src/plugins/Input/cdaudio/decoder_cdaudio.cpp || die
> + fi

This looks really weird. A conditional sed on what package is installed
on the users system? Can you elaborate?

> +
> + cmake-utils_src_prepare
> +}
> +
> +src_configure() {
> + mycmakeargs=(

It doesn't hurt to make this a local variable.

> + $(cmake-utils_use_use alsa)
> + $(cmake-utils_use_use aac)
> + $(cmake-utils_use_use alsa)

[...]

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgit2/

[hasufell]

On 10/10/2015 01:31 PM, Manuel Rüger wrote:
> commit: 9d15a1c12b3c4f98445a45c051733eb2a67fdb28
> Author: Manuel Rüger  gentoo  org>
> AuthorDate: Sat Oct 10 11:30:54 2015 +
> Commit: Manuel Rüger  gentoo  org>
> CommitDate: Sat Oct 10 11:30:54 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9d15a1c1
> 
> dev-libs/libgit2: Version bump
> 

[...]

> +
> +RDEPEND="
> + !libressl? ( dev-libs/openssl:0 )
> + libressl? ( dev-libs/libressl )
> + sys-libs/zlib
> + net-libs/http-parser

Please order deps alphabetically (I know I added libressl without
reordering, but that was just to keep the diff as small as possible).

> + gssapi? ( virtual/krb5 )
> + ssh? ( net-libs/libssh2 )
> +"
> +DEPEND="${RDEPEND}
> + virtual/pkgconfig
> +"
> +

[...]

> +
> +src_configure() {
> + local mycmakeargs=(
> + -DLIB_INSTALL_DIR="${EPREFIX}/usr/$(get_libdir)"

Something here seems to "break" the pkgconfig file, see:

# pkg-config --variable libdir libgit2
/usr//usr/lib64

> + $(cmake-utils_use_build test CLAR)
> + $(cmake-utils_use_enable trace TRACE)
> + $(cmake-utils_use_use gssapi GSSAPI)
> + $(cmake-utils_use_use ssh SSH)
> + $(cmake-utils_use threads THREADSAFE)
> + )
> + cmake-utils_src_configure
> +}

[...]

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgit2/

[hasufell]

On 10/10/2015 02:24 PM, Fabian Groffen wrote:
> On 10-10-2015 14:19:44 +0200, hasufell wrote:
>>> +RDEPEND="
>>> +   !libressl? ( dev-libs/openssl:0 )
>>> +   libressl? ( dev-libs/libressl )
>>> +   sys-libs/zlib
>>> +   net-libs/http-parser
>>
>> Please order deps alphabetically (I know I added libressl without
>> reordering, but that was just to keep the diff as small as possible).
> 
> Is this a policy 

It is undocumented policy.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgit2/

[hasufell]

On 10/10/2015 02:37 PM, Alexis Ballier wrote:
> On Sat, 10 Oct 2015 14:25:28 +0200
> hasufell <hasuf...@gentoo.org> wrote:
> 
>> On 10/10/2015 02:24 PM, Fabian Groffen wrote:
>>> On 10-10-2015 14:19:44 +0200, hasufell wrote:
>>>>> +RDEPEND="
>>>>> + !libressl? ( dev-libs/openssl:0 )
>>>>> + libressl? ( dev-libs/libressl )
>>>>> + sys-libs/zlib
>>>>> + net-libs/http-parser
>>>>
>>>> Please order deps alphabetically (I know I added libressl without
>>>> reordering, but that was just to keep the diff as small as
>>>> possible).
>>>
>>> Is this a policy 
>>
>> It is undocumented policy.
> 
> 
> It is useless style nitpick. Go maintain the whole tree if you want your
> style to be the only true one :)
> 

It's not my style, it was taught by my recruiters/mentors.

> Sometimes it is indeed better to sort alphabetically, sometimes
> upstream's configure.ac/CMakeLists.txt/whatever ordering is better.
> Whatever minimizes chances of missing a dep change on version bump and
> accommodates best maintainer is policy...
> 

I agree, this can be skipped during reviews.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgit2/

[hasufell]

On 10/10/2015 03:14 PM, Manuel Rüger wrote:
> 
> Dear Michał,
> 
> first of all, please stick to the truth.
> 
> In #gentoo-dev:
>  mrueg: as i pointed out, it was because i see it in pull
> requests and gentoo developers are teaching bad practices to new recruits
>  mgorny: please don't CC me in future then, thanks.
> [...]
>  I already set up a sieve filter to filter out those Re:
> [gentoo-commits] mails in gentoo-dev, I don't want to filter those I
> receive because they actually could be QA-related and not a
> stylistic-nitpick.
> 

We are trying to do useful reviews and we may make mistakes. This is not
to annoy people and if we find that particular things are controversial,
we will just stop adding those to our reviews.

But setting up sieve filters to throw out everything that the project
devotes time on is very motivating.

> I guess your actions were part of the recently established project
> "Reviewers". Therefore, I'd like to remind you and the other members of
> this project about our CoC:
> 
> "Using the correct forum for your post. Bug reports and idle chatter do
> not belong on the gentoo-dev mailing list; discussion about a
> wide-ranging change to the tree probably does not belong on Bugzilla.
> Different fora will also have different standards of behaviour – a joke
> that is perfectly acceptable on IRC will be taken differently when made
> on a mailing list." [1]
> 

As you might know, I haven't really reviewed much on dev ML either,
until people started ranting about our Social Contract, how github is
against it and that everything must be public on our own infra channels.

I'll stick to sending (semi-)private mails then and CC
review...@gentoo.org. So in case you just want to set up another sieve
filter.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-sound/karlyriceditor/files/, media-sound/karlyriceditor/

[hasufell]

On 10/09/2015 08:52 PM, Michael Palimaka wrote:
> commit: 8db5c61ec2b1d9d5b37f1b14434f32342b4f0803
> Author: Michael Palimaka  gentoo  org>
> AuthorDate: Fri Oct  9 18:50:13 2015 +
> Commit: Michael Palimaka  gentoo  org>
> CommitDate: Fri Oct  9 18:51:51 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8db5c61e
> 
> media-sound/karlyriceditor: version bump
> 
> Package-Manager: portage-2.2.20.1
> 

[...]

> diff --git a/media-sound/karlyriceditor/karlyriceditor-1.11.ebuild 
> b/media-sound/karlyriceditor/karlyriceditor-1.11.ebuild
> new file mode 100644
> index 000..358c3c9
> --- /dev/null
> +++ b/media-sound/karlyriceditor/karlyriceditor-1.11.ebuild
> @@ -0,0 +1,37 @@
> +# Copyright 1999-2015 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Id$
> +
> +EAPI=5
> +
> +inherit eutils qt4-r2
> +
> +DESCRIPTION="Application to edit and synchronize lyrics with karaoke songs 
> in various formats"
> +HOMEPAGE="http://www.ulduzsoft.com/linux/karaoke-lyrics-editor/;
> +SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"
> +
> +LICENSE="GPL-3+"
> +SLOT="0"
> +KEYWORDS="~amd64 ~x86"
> +IUSE="libav"
> +
> +RDEPEND="
> + dev-libs/openssl:0
> + dev-qt/qtcore:4
> + dev-qt/qtgui:4
> + media-libs/libsdl

This is missing the 'sound' USE flag on libsdl.

> + libav? ( media-video/libav:= )
> + !libav? ( media-video/ffmpeg:= )
> +"
> +DEPEND="${RDEPEND}
> + virtual/pkgconfig
> +"
> +

[...]

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-analyzer/metasploit/

[hasufell]

On 10/09/2015 05:42 PM, hasufell wrote:
>> +
>> +QA_PREBUILT="
>> +usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x86_linux.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_armle_linux.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x86_solaris.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x64_linux.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x64_linux_dll.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x86_bsd.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x64_bsd.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_mipsbe_linux.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_mipsle_linux.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/meterpreter/msflinker_linux_x86.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/meterpreter/ext_server_sniffer.lso
>> +
>> usr/$(get_libdir)/${PN}${SLOT}/data/meterpreter/ext_server_networkpug.lso
>> +usr/$(get_libdir)/${PN}${SLOT}/data/meterpreter/ext_server_stdapi.lso
>> +usr/$(get_libdir)/${PN}${SLOT}/data/exploits/CVE-2013-2171.bin
>> +usr/$(get_libdir)/${PN}${SLOT}/data/exploits/CVE-2014-3153.elf
>> +usr/$(get_libdir)/${PN}${SLOT}/data/android/libs/x86/libndkstager.so
>> +usr/$(get_libdir)/${PN}${SLOT}/data/android/libs/mips/libndkstager.so
>> +usr/$(get_libdir)/${PN}${SLOT}/data/android/libs/armeabi/libndkstager.so
>> +"
>> +
> 
> I think $(get_libdir) is not allowed in global scope and breaks metadata.
> 
> You can use probably 'usr/lib*/...'
> 
> [...]
> 

And this is the same in dev-ruby/metasploit-payloads ebuild

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: x11-wm/jwm/

[hasufell]

On 10/09/2015 04:45 PM, Ian Delaney wrote:
> commit: 9a94bb3a771b84ec44d2359aa9af6e2fe9e9433d
> Author: Ian Delaney  gentoo  org>
> AuthorDate: Fri Oct  9 14:43:33 2015 +
> Commit: Ian Delaney  gentoo  org>
> CommitDate: Fri Oct  9 14:44:52 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9a94bb3a
> 
> x11-wm/jwm:  bump to -2.3.2
> 
> patch to bump submitted in gentoo bug by 'wraeth' added as
> proxy maintainer under the proxy-maintainers herd in metadata
> 
> Gentoo bug: #562462
> 
> Package-Manager: portage-2.2.20.1
> 
>  x11-wm/jwm/Manifest |  1 +
>  x11-wm/jwm/jwm-2.3.2.ebuild | 66 
> +
>  x11-wm/jwm/metadata.xml |  7 -
>  3 files changed, 73 insertions(+), 1 deletion(-)

[...]

> diff --git a/x11-wm/jwm/jwm-2.3.2.ebuild b/x11-wm/jwm/jwm-2.3.2.ebuild
> new file mode 100644
> index 000..6263aef
> --- /dev/null
> +++ b/x11-wm/jwm/jwm-2.3.2.ebuild
> @@ -0,0 +1,66 @@
> +# Copyright 1999-2013 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Id$
> +

Incorrect header

> +EAPI=4

Why not EAPI=5?

> +inherit eutils
> +
> +DESCRIPTION="Very fast and lightweight still powerful window manager for X"
> +HOMEPAGE="http://joewing.net/programs/jwm/;
> +SRC_URI="http://joewing.net/programs/jwm/releases/${P}.tar.xz;
> +
> +LICENSE="GPL-2"
> +SLOT="0"
> +KEYWORDS="~amd64 ~hppa ~ppc ~x86 ~x86-fbsd"
> +IUSE="bidi debug jpeg png truetype xinerama xpm"
> +
> +RDEPEND="xpm? ( x11-libs/libXpm )
> + xinerama? ( x11-libs/libXinerama )
> + x11-libs/libXext
> + x11-libs/libXrender
> + x11-libs/libXau
> + x11-libs/libXdmcp
> + truetype? ( x11-libs/libXft )
> + png? ( media-libs/libpng )

missng slot

> + jpeg? ( virtual/jpeg )

missing slot

> + bidi? ( dev-libs/fribidi )
> + dev-libs/expat"
> +DEPEND="${RDEPEND}
> + x11-proto/xproto
> + x11-proto/xextproto
> + xinerama? ( x11-proto/xineramaproto )"
> +

[...]

> +
> +src_install() {
> + dodir /usr/bin
> + dodir /etc
> + dodir /usr/share/man
> + emake BINDIR="${D}/usr/bin" SYSCONF="${D}/etc" \
> + MANDIR="${D}/usr/share/man" install
> + rm "${D}"/etc/system.jwmrc
> +
> + echo "#!/bin/sh" > jwm
> + echo "exec /usr/bin/jwm" >> jwm

looks like you want 'make_wrapper' from eutils.eclass

[...]

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-analyzer/metasploit/

[hasufell]

On 10/08/2015 11:04 PM, Richard Farina wrote:
> commit: 408bb337f1207a7c844d99b70a0f5a164f0b990d
> Author: Zero_Chaos  gentoo  org>
> AuthorDate: Thu Oct  8 21:04:12 2015 +
> Commit: Richard Farina  gentoo  org>
> CommitDate: Thu Oct  8 21:04:48 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=408bb337
> 
> net-analyzer/metasploit: I thought keeping the live ebuild in my overlay 
> would decrease the work but it looks like the ruby team and I are duplicating 
> each other and causing more work so moving it back into gentoo
> 

Commit message is over-long, please give a short summary and a more
detailed description after a newline.

>  net-analyzer/metasploit/metasploit-.ebuild | 298 
> +
>  1 file changed, 298 insertions(+)
> 
> diff --git a/net-analyzer/metasploit/metasploit-.ebuild 
> b/net-analyzer/metasploit/metasploit-.ebuild
> new file mode 100644
> index 000..d07ff32
> --- /dev/null
> +++ b/net-analyzer/metasploit/metasploit-.ebuild
> @@ -0,0 +1,298 @@
> +# Copyright 1999-2015 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Header: $
> +

Incorrect header

[...]

> +
> +QA_PREBUILT="
> + usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x86_linux.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_armle_linux.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x86_solaris.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x64_linux.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x64_linux_dll.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x86_bsd.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_x64_bsd.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_mipsbe_linux.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/templates/template_mipsle_linux.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/meterpreter/msflinker_linux_x86.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/meterpreter/ext_server_sniffer.lso
> + 
> usr/$(get_libdir)/${PN}${SLOT}/data/meterpreter/ext_server_networkpug.lso
> + usr/$(get_libdir)/${PN}${SLOT}/data/meterpreter/ext_server_stdapi.lso
> + usr/$(get_libdir)/${PN}${SLOT}/data/exploits/CVE-2013-2171.bin
> + usr/$(get_libdir)/${PN}${SLOT}/data/exploits/CVE-2014-3153.elf
> + usr/$(get_libdir)/${PN}${SLOT}/data/android/libs/x86/libndkstager.so
> + usr/$(get_libdir)/${PN}${SLOT}/data/android/libs/mips/libndkstager.so
> + usr/$(get_libdir)/${PN}${SLOT}/data/android/libs/armeabi/libndkstager.so
> + "
> +

I think $(get_libdir) is not allowed in global scope and breaks metadata.

You can use probably 'usr/lib*/...'

[...]

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-im/dianara/

[hasufell]

On 10/09/2015 03:26 PM, Michael Palimaka wrote:
> commit: 40ef80d0fd08b05a21ca217310859f6d30b60ac2
> Author: Michael Palimaka  gentoo  org>
> AuthorDate: Fri Oct  9 13:25:45 2015 +
> Commit: Michael Palimaka  gentoo  org>
> CommitDate: Fri Oct  9 13:26:07 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=40ef80d0
> 
> net-im/dianara: add missing USE dependencies
> 
> Gentoo-bug: 560624
> 
> Package-Manager: portage-2.2.20.1
> 
>  net-im/dianara/dianara-1.3.1.ebuild | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net-im/dianara/dianara-1.3.1.ebuild 
> b/net-im/dianara/dianara-1.3.1.ebuild
> index 9ff4e3d..37dad4c 100644
> --- a/net-im/dianara/dianara-1.3.1.ebuild
> +++ b/net-im/dianara/dianara-1.3.1.ebuild
> @@ -17,10 +17,10 @@ KEYWORDS="~amd64 ~x86"
>  IUSE=""
>  
>  RDEPEND="
> - >=app-crypt/qca-2.1.0.3:2[qt4]
> + >=app-crypt/qca-2.1.0.3:2[openssl,qt4]
>   dev-libs/qjson
>   dev-libs/qoauth
> - dev-qt/qtcore:4
> + dev-qt/qtcore:4[ssl]
>   dev-qt/qtdbus:4
>   dev-qt/qtgui:4
>   sys-apps/file"
> 

Remember to revbump packages if fixing non-trivial runtime dependencies,
otherwise users VDB might be inconsistent.

I already did it for you in c15d52d9d17b0ec9d5967ba8d0ca720a25fa2e97

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[hasufell]

On 10/09/2015 06:21 PM, Alexis Ballier wrote:
>> Ofc, I will expect people to jump in and say "the council hasn't
>> decided on that yet", but well... it mostly works fine and is not
>> really controversial.
> 
> not sure if council approval is needed; uniformity and consistency is
> way more important than whatever syntax is used
> 

I agree.

There is https://bugs.gentoo.org/show_bug.cgi?id=561190 and
https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:66 but as you can see
it is mostly empty.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ruby/metasploit-payloads/

[hasufell]

On 10/09/2015 06:23 PM, Alexis Ballier wrote:
>>> +# Copyright 1999-2015 Gentoo Foundation
>>> +# Distributed under the terms of the GNU General Public License v2
>>> +#
>>> $Header: 
>>> /var/cvsroot/gentoo-x86/dev-ruby/meterpreter_bins/meterpreter_bins-0.0.10.ebuild,v
>>> 1.1 2014/10/19 23:24:24 zerochaos Exp $ +
>>
>> Incorrect header
> 
> 
> this one annoys me a lot; can't we get repoman to automagically fix it ?
> 

repoman is already broken in that regard as it expects overlay
maintainers to add gentoo copyright, which really makes no sense.

So we would first have to fix that and afair this is blocked by the API
rewrite dol-sen is doing.

Then, a --switch to automagically fix the header could make sense.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-sound/musique/files/, media-sound/musique/

[hasufell]

On 10/09/2015 04:42 PM, Michael Palimaka wrote:
> commit: 2f9b36011ada0104883275fad335084922f5c9c6
> Author: Michael Palimaka  gentoo  org>
> AuthorDate: Fri Oct  9 14:40:56 2015 +
> Commit: Michael Palimaka  gentoo  org>
> CommitDate: Fri Oct  9 14:42:22 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2f9b3601
> 
> media-sound/musique: version bump
> 

reformatted, because email reviews are broken

diff --git a/media-sound/musique/musique-1.4.ebuild
b/media-sound/musique/musique-1.4.ebuild
new file mode 100644
index 000..6e40cbb
--- /dev/null
+++ b/media-sound/musique/musique-1.4.ebuild
@@ -0,0 +1,46 @@
+# Copyright 1999-2015 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+EAPI="5"
+
+inherit eutils qt4-r2
+
+DESCRIPTION="Qt4 music player"
+HOMEPAGE="http://flavio.tordini.org/musique;
+SRC_URI="http://flavio.tordini.org/files/${PN}/${P}.tar.gz;
+
+LICENSE="GPL-3"

It seems this can be GPL-3+, see
https://github.com/flaviotordini/musique#legal-stuff

+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE=""
+
+RDEPEND="
+   dev-qt/qtcore:4
+   dev-qt/qtdbus:4
+   dev-qt/qtgui:4
+   dev-qt/qtsingleapplication[qt4,X]
+   dev-qt/qtsql:4[sqlite]
+   || ( dev-qt/qtphonon:4 media-libs/phonon[qt4] )
+   media-libs/taglib
+"
+DEPEND="${RDEPEND}"
+
+S="${WORKDIR}/${PN}"
+
+DOCS=( CHANGES TODO )
+
+src_prepare () {
+   epatch "${FILESDIR}"/${P}-unbundle-qtsingleapplication.patch
+   rm -r src/qtsingleapplication || die
+   qt4-r2_src_prepare
+}
+
+src_configure() {
+   eqmake4 ${PN}.pro PREFIX="/usr"
+}
+
+src_install() {
+   qt4-r2_src_install
+   doicon data/${PN}.svg

is this icon referenced in a hardcoded way? Otherwise, you can do:
doicon -s scalable data/${PN}.svg

which will install it into /usr/share/icons/hicolor/scalable/apps
which is the more modern location.

doicon also allows -c and -t switches, see
https://devmanual.gentoo.org/eclass-reference/eutils.eclass/index.html

If you go for that location, you also need to update icon cache for
users who run qt applications inside a gtk based DE via gnome2-utils.eclass.

Maybe these cache updates should be replaced by PM hooks, but I'm not
sure if portage hooks support is good enough for that.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ros/compressed_image_transport/

[hasufell]

On 10/09/2015 06:37 PM, Alexis Ballier wrote:
> commit: 4440cc9d950795eaae8f8b049bbf37c073ef5ea0
> Author: Alexis Ballier  gentoo  org>
> AuthorDate: Fri Oct  9 16:37:18 2015 +
> Commit: Alexis Ballier  gentoo  org>
> CommitDate: Fri Oct  9 16:37:18 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4440cc9d
> 
> dev-ros/compressed_image_transport: Add PYTHON_COMPAT and PYTHON_USEDEP on 
> dynamic_reconfigure. Bug #562664.
> 
> Package-Manager: portage-2.2.23
> 

[...]

> --- 
> a/dev-ros/compressed_image_transport/compressed_image_transport-1.9.2.ebuild
> +++ 
> b/dev-ros/compressed_image_transport/compressed_image_transport-1.9.2-r1.ebuild
> @@ -6,6 +6,7 @@ EAPI=5
>  ROS_REPO_URI="https://github.com/ros-perception/image_transport_plugins;
>  KEYWORDS="~amd64 ~arm"
>  ROS_SUBDIR=${PN}
> +PYTHON_COMPAT=( python2_7 )
>  
>  inherit ros-catkin
>  
> @@ -16,7 +17,7 @@ IUSE=""
>  
>  RDEPEND="
>   dev-ros/cv_bridge
> - dev-ros/dynamic_reconfigure
> + dev-ros/dynamic_reconfigure[${PYTHON_USEDEP}]
>   dev-ros/image_transport
>   dev-ros/tf
>   media-libs/opencv
> 
> diff --git 
> a/dev-ros/compressed_image_transport/compressed_image_transport-.ebuild 
> b/dev-ros/compressed_image_transport/compressed_image_transport-.ebuild
> index f7a387a..144fac9 100644
> --- 
> a/dev-ros/compressed_image_transport/compressed_image_transport-.ebuild
> +++ 
> b/dev-ros/compressed_image_transport/compressed_image_transport-.ebuild
> @@ -6,6 +6,7 @@ EAPI=5
>  ROS_REPO_URI="https://github.com/ros-perception/image_transport_plugins;
>  KEYWORDS="~amd64 ~arm"
>  ROS_SUBDIR=${PN}
> +PYTHON_COMPAT=( python2_7 )
>  
>  inherit ros-catkin
>  
> @@ -16,7 +17,7 @@ IUSE=""
>  
>  RDEPEND="
>   dev-ros/cv_bridge
> - dev-ros/dynamic_reconfigure
> + dev-ros/dynamic_reconfigure[${PYTHON_USEDEP}]
>   dev-ros/image_transport
>   dev-ros/tf
>   media-libs/opencv
> 

Maybe I am missing something, but ${PYTHON_DEPS} seems missing here and
I cannot find it in ros-catkin.eclass either. It's only an indirect dep
which is inappropriate.

Maybe other ros packages are affected as well.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ros/compressed_image_transport/

[hasufell]

On 10/09/2015 07:22 PM, Alexis Ballier wrote:
> Doesn't python-r1 add this ? It seems not...
> It should be added to ros-catkin.eclass when PYTHON_COMPAT is set. Any
> hint on how to proceed ?
> 

distutils-r1 adds it, python-r1 is a "low-level" eclass and not supposed
to do a lot of magic.

Technically, you would have to revbump all packages, but since the
indirect dep-graph will pull in python anyway, I guess we can skip that.

I guess you can add it with a if-PYTHON_COMPAT-conditional somewhere
around line 68 where you already modify python related deps (python-exec).

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: x11-misc/screengrab/

[hasufell]

On 10/09/2015 07:17 PM, Michael Palimaka wrote:
> commit: b55a3b89d938b403255a86329f364b8e4a5b5d72
> Author: Michael Palimaka  gentoo  org>
> AuthorDate: Fri Oct  9 17:16:25 2015 +
> Commit: Michael Palimaka  gentoo  org>
> CommitDate: Fri Oct  9 17:17:29 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b55a3b89
> 
> x11-misc/screengrab: version bump
> 
> Gentoo-bug: 553094
> 
> Package-Manager: portage-2.2.20.1
> 
>  x11-misc/screengrab/Manifest|  1 +
>  x11-misc/screengrab/screengrab-1.2.1.ebuild | 37 
> +
>  2 files changed, 38 insertions(+)
> 
> diff --git a/x11-misc/screengrab/Manifest b/x11-misc/screengrab/Manifest
> index 65e448d..0f10856 100644
> --- a/x11-misc/screengrab/Manifest
> +++ b/x11-misc/screengrab/Manifest
> @@ -1 +1,2 @@
>  DIST screengrab-1.0.tar.gz 152250 SHA256 
> 40babc5c1afc32e4f413ec56bfd2bf39bdb894ac32465b6cceec21520e60563f SHA512 
> e34e1fa907ccb105e1b37db40c2dfc22d19b8cdf517a73f4df11f3dffc2cdb0c6ed204d2d1c5bd8efeaa5326f52907fb4b364c84be510d392d7ff882f8d44a7e
>  WHIRLPOOL 
> cefb28f7d4ef29683389e4f4a2e12bb15af049e3c0834f6d53d04650b7b5128090defe5d0849bfdb417e534ccdac12ace73f72a70852f02681a58d35a4032f6b
> +DIST screengrab-1.2.1.tar.gz 156692 SHA256 
> 48cdaf66e6eff3ef0db89cb09b7c5757f07b99dd1cd05321e33b04a14c670d3b SHA512 
> 12892eaf33fe48875c1d0dccdc631cc64c246ba2ba10432539099b35e75c36f19c8ff8b97dee959575f214ea852d1afaa9cf46476f98e0978b379a05df101805
>  WHIRLPOOL 
> dc2a41981a7a0b569d0dac55d1bc16531c64e0e2dbe69330a1ff5a6511b28b0e2b6f8330e50805bf5c5b432afa3ac05aab93bfd398a26d8ff729276d6ccb1bfb
> 
> diff --git a/x11-misc/screengrab/screengrab-1.2.1.ebuild 
> b/x11-misc/screengrab/screengrab-1.2.1.ebuild
> new file mode 100644
> index 000..e3e928b
> --- /dev/null
> +++ b/x11-misc/screengrab/screengrab-1.2.1.ebuild
> @@ -0,0 +1,37 @@
> +# Copyright 1999-2015 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Id$
> +
> +EAPI=5
> +
> +inherit cmake-utils
> +
> +DESCRIPTION="Qt application for getting screenshots"
> +HOMEPAGE="http://screengrab.doomer.org;
> +SRC_URI="https://github.com/DOOMer/screengrab/archive/1.2.1.tar.gz -> 
> ${P}.tar.gz"
> +
> +LICENSE="GPL-2"
> +SLOT="0"
> +KEYWORDS="~amd64 ~x86"
> +IUSE=""
> +
> +DEPEND="
> + dev-qt/qtcore:4
> + dev-qt/qtgui:4
> + x11-libs/libX11
> +"
> +RDEPEND="${DEPEND}"
> +
> +src_prepare() {
> + sed -i -e "/LICENSE.txt/d" CMakeLists.txt || die
> +
> + cmake-utils_src_prepare
> +}
> +
> +src_configure() {
> + local mycmakeargs=(
> + -DSG_DOCDIR=${PF}
> + )
> +
> + cmake-utils_src_configure
> +}
> 

It seems this package bundles x11-libs/libqxt, see
https://github.com/DOOMer/screengrab/tree/531af39ef2563c9ae801bf6cffb441cc8e87b2e7/src/3rdparty/qxt
and
https://github.com/DOOMer/screengrab/tree/531af39ef2563c9ae801bf6cffb441cc8e87b2e7#build-requirements

(the hash is from the 1.2.1 release)

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-fs/zfs-kmod/

[hasufell]

On 10/09/2015 07:48 PM, Matt Turner wrote:
> On Fri, Oct 9, 2015 at 10:03 AM, Jason Zaman  wrote:
>> On Fri, Oct 09, 2015 at 06:20:58PM +0200, Michał Górny wrote:
>>> Dnia 2015-10-09, o godz. 15:40:32
>>> "Richard Yao"  napisał(a):
>>>
 commit: 050bf38afc93a98c5176c95b3c4ffc01212bf46b
 Author: Richard Yao  gentoo  org>
 AuthorDate: Fri Oct  9 15:38:56 2015 +
 Commit: Richard Yao  gentoo  org>
 CommitDate: Fri Oct  9 15:38:56 2015 +
 URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=050bf38a

 sys-fs/zfs-kmod: Remove outdated ebuilds

 Package-Manager: portage-2.2.20.1
 Signed-off-by: Richard Yao  gentoo.org>

  sys-fs/zfs-kmod/zfs-kmod-0.6.2-r4.ebuild | 129 ---
  sys-fs/zfs-kmod/zfs-kmod-0.6.2-r5.ebuild | 129 ---
  sys-fs/zfs-kmod/zfs-kmod-0.6.3.ebuild| 138 
 -
  sys-fs/zfs-kmod/zfs-kmod-0.6.4.ebuild| 142 
 --
  sys-fs/zfs-kmod/zfs-kmod-0.6.5.2.ebuild  | 146 
 ---
>>>
>>> You removed 0.6.5.2 but kept the respective sys-fs/zfs version,
>>> therefore breaking the dependency graph:
>>>
>>> https://qa-reports.gentoo.org/output/gentoo-ci/96dc8cd/12.html#l657
>>>
>> I re-added this. Also forgot to remove the distfiles from the Manifest.
> 
> Likely because he just used git commit instead of repoman commit. I've
> been doing that to avoid the Package-Manager: noise added to the git
> log...
> 

It's fine to not use repoman commit. The only thing to keep in mind then
is to run 'repoman full' _after_ you have staged your files and _before_
they are committed.

That has practically the same effect and allows you to use your own tools.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[hasufell]

On 10/09/2015 01:17 PM, Alexis Ballier wrote:
> commit: 5220bb29741e1685b42a6312c0b7bf2821672040
> Author: Alexis Ballier  gentoo  org>
> AuthorDate: Fri Oct  9 11:16:38 2015 +
> Commit: Alexis Ballier  gentoo  org>
> CommitDate: Fri Oct  9 11:16:52 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5220bb29
> 
> eclass: ros-catkin.eclass: Use cmake-utils_src_make instead of plain emake 
> for src_test so that it works with ninja too.
> 


Please try to use short summary lines and put more detailed description
into the commit message after a newline, also see
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Example

The prefix is also a bit uncommon, see
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_message_format

Ofc, I will expect people to jump in and say "the council hasn't decided
on that yet", but well... it mostly works fine and is not really
controversial.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ruby/metasm/

[hasufell]

On 10/08/2015 11:04 PM, Richard Farina wrote:
> commit: f05eda22c275381c669e6f2a88dabd1356a3541f
> Author: Zero_Chaos  gentoo  org>
> AuthorDate: Thu Oct  8 20:45:33 2015 +
> Commit: Richard Farina  gentoo  org>
> CommitDate: Thu Oct  8 21:04:37 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f05eda22
> 
> dev-ruby/metasm: import from pentoo
> 
> Package-Manager: portage-2.2.22
> 
>  dev-ruby/metasm/Manifest   |  1 +
>  dev-ruby/metasm/metadata.xml   | 10 +++
>  dev-ruby/metasm/metasm-1.0.2-r1.ebuild | 52 
> ++
>  3 files changed, 63 insertions(+)
> 

[...]

> --- /dev/null
> +++ b/dev-ruby/metasm/metasm-1.0.2-r1.ebuild
> @@ -0,0 +1,52 @@
> +# Copyright 1999-2015 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Id$
> +
> +EAPI=5
> +USE_RUBY="ruby19 ruby20 ruby21"
> +
> +inherit ruby-fakegem
> +
> +RUBY_FAKEGEM_EXTRAINSTALL="metasm metasm.rb misc samples"
> +
> +DESCRIPTION="cross-architecture assembler, disassembler, linker, and 
> debugger"
> +HOMEPAGE="http://metasm.cr0.org/;
> +SRC_URI="mirror://rubygems/${P}.gem"
> +
> +LICENSE="BSD"
> +SLOT="${PV}"
> +KEYWORDS="~amd64 ~arm ~x86"
> +#IUSE="development test"
> +RESTRICT=test
> +IUSE=""
> +
> +RDEPEND="${RDEPEND} !dev-ruby/metasploit-model:0"
> +
> +ruby_add_rdepend ">=dev-ruby/railties-4.0.9:4.0
> + >=dev-ruby/activesupport-4.0.9:4.0
> + >=dev-ruby/activemodel-4.0.9:4.0"
> +ruby_add_bdepend "dev-ruby/bundler"
> +
> +all_ruby_prepare() {
> + [ -f Gemfile.lock ] && rm Gemfile.lock

missing "|| die" afais, should probably be

[ -f Gemfile.lock ] && { rm Gemfile.lock || die ; }

> + #For now, we don't support development or testing at all
> + #if ! use development; then
> + sed -i -e "/^group :development do/,/^end$/d" Gemfile || die
> + sed -i -e "/s.add_development_dependency/d" "${PN}".gemspec || 
> die
> + sed -i -e "/spec.add_development_dependency/d" "${PN}".gemspec 
> || die
> + #fi
> + #if ! use test; then
> + sed -i -e "/^group :test do/,/^end$/d" Gemfile || die
> + #fi
> + #if ! use test && ! use development; then
> + sed -i -e "/^group :development, :test do/,/^end$/d" Gemfile || 
> die
> + #fi
> +}
> +
> +each_ruby_prepare() {
> + if [ -f Gemfile ]
> + then
> + BUNDLE_GEMFILE=Gemfile ${RUBY} -S bundle install 
> --local || die
> + BUNDLE_GEMFILE=Gemfile ${RUBY} -S bundle check || die
> + fi
> +}
> 

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ruby/metasploit-payloads/

[hasufell]

On 10/08/2015 11:04 PM, Richard Farina wrote:
> commit: 8fe8aa173945158ebd3bd849b6304992eb29ddeb
> Author: Zero_Chaos  gentoo  org>
> AuthorDate: Thu Oct  8 20:48:03 2015 +
> Commit: Richard Farina  gentoo  org>
> CommitDate: Thu Oct  8 21:04:40 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8fe8aa17
> 
> dev-ruby/metasploit-payloads: import version bump from pentoo
> 
> Package-Manager: portage-2.2.22
> 
>  dev-ruby/metasploit-payloads/Manifest  |  1 +
>  .../metasploit-payloads-1.0.15.ebuild  | 45 
> ++
>  2 files changed, 46 insertions(+)
> 
> diff --git a/dev-ruby/metasploit-payloads/Manifest 
> b/dev-ruby/metasploit-payloads/Manifest
> index f16e5c6..9450c38 100644
> --- a/dev-ruby/metasploit-payloads/Manifest
> +++ b/dev-ruby/metasploit-payloads/Manifest
> @@ -1 +1,2 @@
> +DIST metasploit-payloads-1.0.15.gem 5249536 SHA256 
> 8d186c3bcf8a4537b9a96301e8cc0d847335d3cfa87ca5b2e88a6b2980eab240 SHA512 
> 58afa5c4bc191a05e3ec009d94d40f2d9fc5a025962088845db14aefc410340fdc7b1e30f17c75936495a43fc99576d188960bc5755dbec434d7428fbbdd495a
>  WHIRLPOOL 
> d136642c1de9b18e652c421ad3b9fd859b8d8850dd539d66d4c8b410e09064d7872bc06c505b01d5389d1e2ebe22ed6b3c88aa3a0f08a1578f204201c24b3438
>  DIST metasploit-payloads-1.0.9.gem 5248000 SHA256 
> bd9eec335158dd25e579c680856f8c48aa9ba081a5d51d87a05dbb1e511087a3 SHA512 
> 4c08284d4b1d667f545d97e879b2581830f34d42560ba6d6ed7adf32312adc841d5fdd8b55ab4e06a196d1e313fb44fbb861ccac7790e50f88260e2def0a76ed
>  WHIRLPOOL 
> a398dcad94b38626d4bd3d9980d05a24ccdbc12bbd2e902dd4f78c9bcd2cf4a26c76645d989a00aec69d041d9203c5ff31e0b0f948028ac6cd06ae724d573950
> 
> diff --git a/dev-ruby/metasploit-payloads/metasploit-payloads-1.0.15.ebuild 
> b/dev-ruby/metasploit-payloads/metasploit-payloads-1.0.15.ebuild
> new file mode 100644
> index 000..87598a1
> --- /dev/null
> +++ b/dev-ruby/metasploit-payloads/metasploit-payloads-1.0.15.ebuild
> @@ -0,0 +1,45 @@
> +# Copyright 1999-2015 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Header: 
> /var/cvsroot/gentoo-x86/dev-ruby/meterpreter_bins/meterpreter_bins-0.0.10.ebuild,v
>  1.1 2014/10/19 23:24:24 zerochaos Exp $
> +

Incorrect header

[...]

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ruby/metasploit-payloads/

[hasufell]

On 10/08/2015 11:04 PM, Richard Farina wrote:
> commit: 8fe8aa173945158ebd3bd849b6304992eb29ddeb
> Author: Zero_Chaos  gentoo  org>
> AuthorDate: Thu Oct  8 20:48:03 2015 +
> Commit: Richard Farina  gentoo  org>
> CommitDate: Thu Oct  8 21:04:40 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8fe8aa17
> 
> dev-ruby/metasploit-payloads: import version bump from pentoo
> 
> Package-Manager: portage-2.2.22
> 
>  dev-ruby/metasploit-payloads/Manifest  |  1 +
>  .../metasploit-payloads-1.0.15.ebuild  | 45 
> ++
>  2 files changed, 46 insertions(+)
> 
> diff --git a/dev-ruby/metasploit-payloads/Manifest 
> b/dev-ruby/metasploit-payloads/Manifest
> index f16e5c6..9450c38 100644
> --- a/dev-ruby/metasploit-payloads/Manifest
> +++ b/dev-ruby/metasploit-payloads/Manifest
> @@ -1 +1,2 @@
> +DIST metasploit-payloads-1.0.15.gem 5249536 SHA256 
> 8d186c3bcf8a4537b9a96301e8cc0d847335d3cfa87ca5b2e88a6b2980eab240 SHA512 
> 58afa5c4bc191a05e3ec009d94d40f2d9fc5a025962088845db14aefc410340fdc7b1e30f17c75936495a43fc99576d188960bc5755dbec434d7428fbbdd495a
>  WHIRLPOOL 
> d136642c1de9b18e652c421ad3b9fd859b8d8850dd539d66d4c8b410e09064d7872bc06c505b01d5389d1e2ebe22ed6b3c88aa3a0f08a1578f204201c24b3438
>  DIST metasploit-payloads-1.0.9.gem 5248000 SHA256 
> bd9eec335158dd25e579c680856f8c48aa9ba081a5d51d87a05dbb1e511087a3 SHA512 
> 4c08284d4b1d667f545d97e879b2581830f34d42560ba6d6ed7adf32312adc841d5fdd8b55ab4e06a196d1e313fb44fbb861ccac7790e50f88260e2def0a76ed
>  WHIRLPOOL 
> a398dcad94b38626d4bd3d9980d05a24ccdbc12bbd2e902dd4f78c9bcd2cf4a26c76645d989a00aec69d041d9203c5ff31e0b0f948028ac6cd06ae724d573950
> 
> diff --git a/dev-ruby/metasploit-payloads/metasploit-payloads-1.0.15.ebuild 
> b/dev-ruby/metasploit-payloads/metasploit-payloads-1.0.15.ebuild
> new file mode 100644
> index 000..87598a1
> --- /dev/null
> +++ b/dev-ruby/metasploit-payloads/metasploit-payloads-1.0.15.ebuild
> @@ -0,0 +1,45 @@
> +# Copyright 1999-2015 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Header: 
> /var/cvsroot/gentoo-x86/dev-ruby/meterpreter_bins/meterpreter_bins-0.0.10.ebuild,v
>  1.1 2014/10/19 23:24:24 zerochaos Exp $
> +
> +EAPI=5
> +
> +USE_RUBY="ruby19 ruby20 ruby21"
> +
> +RUBY_FAKEGEM_TASK_DOC=""
> +
> +RUBY_FAKEGEM_EXTRAINSTALL="data"
> +
> +inherit ruby-fakegem
> +
> +DESCRIPTION="Compiled binaries for Metasploit's Meterpreter"
> +HOMEPAGE="https://rubygems.org/gems/metasploit-payloads;
> +
> +LICENSE="BSD"
> +
> +SLOT="${PV}"
> +KEYWORDS="~amd64 ~arm ~x86"
> +IUSE=""
> +
> +#no tests
> +RESTRICT="test strip"
> +
> +QA_PREBUILT="
> + 
> usr/$(get_libdir)/ruby/gems/*/gems/${PN}-${SLOT}/data/meterpreter/msflinker_linux_x86.bin
> + 
> usr/$(get_libdir)/ruby/gems/*/gems/${PN}-${SLOT}/data/meterpreter/ext_server_sniffer.lso
> + 
> usr/$(get_libdir)/ruby/gems/*/gems/${PN}-${SLOT}/data/meterpreter/ext_server_networkpug.lso
> + 
> usr/$(get_libdir)/ruby/gems/*/gems/${PN}-${SLOT}/data/meterpreter/ext_server_stdapi.lso
> + 
> usr/$(get_libdir)/ruby/gems/*/gems/${PN}-${SLOT}/data/android/libs/armeabi/libndkstager.so
> + 
> usr/$(get_libdir)/ruby/gems/*/gems/${PN}-${SLOT}/data/android/libs/mips/libndkstager.so
> + 
> usr/$(get_libdir)/ruby/gems/*/gems/${PN}-${SLOT}/data/android/libs/x86/libndkstager.so
> + "
> +
> +src_install() {
> + ruby-ng_src_install
> + #tell revdep-rebuild to ignore binaries meant for the target
> + dodir /etc/revdep-rebuild
> + cat <<-EOF > "${ED}"/etc/revdep-rebuild/99-${PN}-${SLOT}
> + #These dirs contain prebuilt binaries for running on the TARGET 
> not the HOST
> + 
> SEARCH_DIRS_MASK="/usr/lib*/ruby/gems/*/gems/${PN}-${SLOT}/data/android/libs"
> + EOF
> +}
> 

technically, 'cat' can fail too (e.g. if directory does not exist), so
it should '|| die' at the end of this line

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-ruby/metasploit-credential/

[hasufell]

On 10/08/2015 11:04 PM, Richard Farina wrote:
> commit: 7c78113940300a9ca123133d2eb69647d5220300
> Author: Zero_Chaos  gentoo  org>
> AuthorDate: Thu Oct  8 20:58:11 2015 +
> Commit: Richard Farina  gentoo  org>
> CommitDate: Thu Oct  8 21:04:44 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7c781139
> 
> dev-ruby/metasploit-credential: bump and fix deps
> 
> Metasploit::Credential::SSHKey depends on 'net/ssh', but 
> metasploit-credential does not declare the net-ssh gem as a runtime 
> dependency because metasploit-framework includes its own
> version of 'net/ssh' which would conflict with the gem.
> 
> Package-Manager: portage-2.2.22
> 
>  dev-ruby/metasploit-credential/Manifest|  1 +
>  .../metasploit-credential-1.0.1.ebuild | 27 
> ++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/dev-ruby/metasploit-credential/Manifest 
> b/dev-ruby/metasploit-credential/Manifest
> index 948e652..208f07e 100644
> --- a/dev-ruby/metasploit-credential/Manifest
> +++ b/dev-ruby/metasploit-credential/Manifest
> @@ -1 +1,2 @@
>  DIST metasploit-credential-1.0.0.gem 101888 SHA256 
> 086cb65295f1294c213138bd2a9f2f727d945b90837a7e877b22bc6a47fe33f6 SHA512 
> 4af09458a83d9425c5bfd744bc3f366c08d9175b4c303fa9ff53dd3f2163ba654748ea883d22f069e3b3be1218b57afe909f7ba31feb54c0b7ff781af8d5e631
>  WHIRLPOOL 
> 506c707f3e1be0e90fad02397a34c70e44d1f423b5909d9f61152e2a4e929eadccf0736ec607c569fe75fff24c6003243d0a9a288979450b8c52d5f1feba1f6d
> +DIST metasploit-credential-1.0.1.gem 101888 SHA256 
> e37e02d962a00733f8a82d486ee8b38aa287503d61812fba9cca05e834d873ca SHA512 
> e2d77cf1af9b9f7c09c3b98fc61c032dd5890bc019d09e208706ea93560402c82abc5a3dbc178442fbc1597d9e43e8a98f76bdb71fe470e7091d5e79bb30660f
>  WHIRLPOOL 
> 15b568fa61f64d895df9a7c5c04ae22232f9d805fca71c565fc2db871b4c443c163a922d52faa1953b3fadb157d71a6ea1866d2f740eff0db3262d78066c812e
> 
> diff --git 
> a/dev-ruby/metasploit-credential/metasploit-credential-1.0.1.ebuild 
> b/dev-ruby/metasploit-credential/metasploit-credential-1.0.1.ebuild
> new file mode 100644
> index 000..1537643
> --- /dev/null
> +++ b/dev-ruby/metasploit-credential/metasploit-credential-1.0.1.ebuild
> @@ -0,0 +1,27 @@
> +# Copyright 1999-2015 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Header: Exp $
> +
>

Incorrect header.

Re: [gentoo-dev] unnecessary revbump

[hasufell]

On 10/06/2015 07:03 PM, Michael Orlitzky wrote:
> On 10/06/2015 09:33 AM, William Hubbs wrote:
>> I don't think the revbump of net-misc/openconnect-7.06-r1 to -r2 was
>> necessary. When the change purely affects use flags, that is picked up
>> by the pm and there is no need to force everyone to rebuild the package.
>>
> 
> -r1 is stable.
> 
> 

Correct. I'm not going to mess with stable ebuilds during transition, no
matter how trivial the change seems to be.

Re: [gentoo-dev] unnecessary revbump

[hasufell]

On 10/06/2015 09:28 PM, William Hubbs wrote:
> On Tue, Oct 06, 2015 at 08:23:31PM +0200, hasufell wrote:
>> On 10/06/2015 07:03 PM, Michael Orlitzky wrote:
>>> On 10/06/2015 09:33 AM, William Hubbs wrote:
>>>> I don't think the revbump of net-misc/openconnect-7.06-r1 to -r2 was
>>>> necessary. When the change purely affects use flags, that is picked up
>>>> by the pm and there is no need to force everyone to rebuild the package.
>>>>
>>>
>>> -r1 is stable.
>>>
>>>
>>
>> Correct. I'm not going to mess with stable ebuilds during transition, no
>> matter how trivial the change seems to be.
> 
> As has been said in this thread --newuse still covers it, and if you
> don't have libressl in your use flags it is a wasted rebuild.
> 

I am going to repeat myself: I am not touching _any_ stable ebuild.

Re: [gentoo-dev] LibreSSL switch-over progress

[hasufell]

On 10/05/2015 05:28 PM, Jason A. Donenfeld wrote:
> Last night I tried to enable that flag globally, and then reemerge
> everything relevant. Unfortunately, I got some unresolvable blockers.

Yes, it is currently practically impossible to enable it. However, you
can use the https://github.com/gentoo/libressl overlay right now,
because it contains a dummy openssl ebuild to fix those unresolvable
blockers.


> The reason for this post is: how do I know when to try switching over
> again?

I will announce it, probably cross-posting to user-ML.

You can watch the in-tree progress here:
https://github.com/gentoo/libressl/wiki/Transition-plan#packages-not-converted-yet
https://bugs.gentoo.org/show_bug.cgi?id=561854

Re: [gentoo-dev] LibreSSL switch-over progress

[hasufell]

On 10/05/2015 05:28 PM, Jason A. Donenfeld wrote:
> 
> I assume there are developers hard
> at work adding the flag to each and every package.
> 

Exactly one. And because of that it will take another few weeks (maybe
even months) until we are there.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-dns/bind/files/, net-dns/bind/

[hasufell]

On 10/04/2015 10:29 AM, Pacho Ramos wrote:
> commit: 7f2d82c0ec3bea388511cf190c7426fa2815ea89
> Author: Pacho Ramos  gentoo  org>
> AuthorDate: Sun Oct  4 08:28:58 2015 +
> Commit: Pacho Ramos  gentoo  org>
> CommitDate: Sun Oct  4 08:28:58 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7f2d82c0
> 
> net-dns/bind: Install missing tmpfiles.d file (#559118 by Alexey Sychev)
> 
> Package-Manager: portage-2.2.22
> 
>  net-dns/bind/bind-9.10.2_p4-r1.ebuild | 408 
> ++
>  net-dns/bind/files/named.conf |   1 +
>  2 files changed, 409 insertions(+)
> 
> diff --git a/net-dns/bind/bind-9.10.2_p4-r1.ebuild 
> b/net-dns/bind/bind-9.10.2_p4-r1.ebuild
> new file mode 100644
> index 000..68ccb97
> --- /dev/null
> +++ b/net-dns/bind/bind-9.10.2_p4-r1.ebuild

[...]
> +DEPEND="ssl? ( dev-libs/openssl:0[-bindist] )
> + mysql? ( >=virtual/mysql-4.0 )
> + odbc? ( >=dev-db/unixODBC-2.2.6 )
> + ldap? ( net-nds/openldap )
> + idn? ( net-dns/idnkit )
> + postgres? ( dev-db/postgresql:= )
> + caps? ( >=sys-libs/libcap-2.1.0 )
> + xml? ( dev-libs/libxml2 )
> + geoip? ( >=dev-libs/geoip-1.4.6 )
> + gssapi? ( virtual/krb5 )
> + gost? ( >=dev-libs/openssl-1.0.0:0[-bindist] )
> + seccomp? ( sys-libs/libseccomp )
> + json? ( dev-libs/json-c )"
> +# sdb-ldap? ( net-nds/openldap )
> +
> +RDEPEND="${DEPEND}
> + selinux? ( sec-policy/selinux-bind )
> + || ( sys-process/psmisc >=sys-freebsd/freebsd-ubin-9.0_rc 
> sys-process/fuser-bsd )"

${PYTHON_DEPS} is missing here, even if python USE flag is enabled. Is
that on purpose? This packages uses python-r1 so no python deps will be
automagically added.

[...]
> +
> + if use nslint; then
> + cd $NSLINT_DIR

missing || die

[...]
> +
> +src_install() {
> + emake DESTDIR="${D}" install
> +
> + if use nslint; then
> + cd $NSLINT_DIR

missing || die

[...]
> + dobin nslint
> + doman nslint.8
> + cd "${S}"

missing || die

[...]
> +
> + # some handy-dandy dynamic dns examples
> + pushd "${D}"/usr/share/doc/${PF} 1>/dev/null

missing || die on pushd/popd

> + tar xf "${DISTDIR}"/dyndns-samples.tbz2 || die
> + popd 1>/dev/null
> + fi
> +

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: www-misc/fcgiwrap/

[hasufell]

On 10/04/2015 10:38 AM, Pacho Ramos wrote:
> commit: c93f1bb8b49de29a60715ec6e9326ed619effbc4
> Author: Pacho Ramos  gentoo  org>
> AuthorDate: Sun Oct  4 08:38:36 2015 +
> Commit: Pacho Ramos  gentoo  org>
> CommitDate: Sun Oct  4 08:38:36 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c93f1bb8
> 
> www-misc/fcgiwrap: systemd is needed at run and buildtime (#557020 by Cody 
> Schafer)
> 
> Package-Manager: portage-2.2.22
> 
>  www-misc/fcgiwrap/fcgiwrap-1.1.0-r1.ebuild | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/www-misc/fcgiwrap/fcgiwrap-1.1.0-r1.ebuild 
> b/www-misc/fcgiwrap/fcgiwrap-1.1.0-r1.ebuild
> index 0c76213..cc8d4f7 100644
> --- a/www-misc/fcgiwrap/fcgiwrap-1.1.0-r1.ebuild
> +++ b/www-misc/fcgiwrap/fcgiwrap-1.1.0-r1.ebuild
> @@ -23,7 +23,10 @@ else
>   KEYWORDS="amd64 ~arm x86"
>  fi
>  
> -RDEPEND="dev-libs/fcgi"
> +RDEPEND="
> + dev-libs/fcgi
> + systemd? ( sys-apps/systemd )
> +"
>  DEPEND="${RDEPEND}
>   virtual/pkgconfig"
>  
> 

This needs a revbump, because runtime dependencies have changed and
users VDB must be updated. Especially because this is a stable package.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-dns/bind/files/, net-dns/bind/

[hasufell]

On 10/04/2015 11:44 AM, Pacho Ramos wrote:
> Please report to the right people, you can simply diff between the
> ebuilds to see that I only touched the relevant systemd part. You can
> also, of course, do the same as I needed to do for systemd part and go
> ahead fixing the dies instead of trying to blame on me by the sake of
> it.
> 

git blame shows you as the committer (because the way we use git is a
bit non-standard). I have forwarded the mail to the maintainer as well.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-emulation/libvirt/

[hasufell]

On 10/03/2015 08:29 PM, Matthias Maier wrote:
> commit: a1015c1339068e9e942cb353f46a015b5612db1e
> Author: Matthias Maier  gentoo  org>
> AuthorDate: Sat Oct  3 18:26:45 2015 +
> Commit: Matthias Maier  gentoo  org>
> CommitDate: Sat Oct  3 18:29:30 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1015c13
> 
> app-emulation/libvirt: version bump to 1.2.20
> 
> Package-Manager: portage-2.2.22
> 
>  app-emulation/libvirt/Manifest  |   1 +
>  app-emulation/libvirt/libvirt-1.2.20.ebuild | 492 
> 
>  2 files changed, 493 insertions(+)
> 
> diff --git a/app-emulation/libvirt/Manifest b/app-emulation/libvirt/Manifest
> index 816bdef..961bf34 100644
> --- a/app-emulation/libvirt/Manifest
> +++ b/app-emulation/libvirt/Manifest

[...]
> +
> + [[ -n ${BACKPORTS} ]] && \
> + EPATCH_FORCE=yes EPATCH_SUFFIX="patch" \
> + EPATCH_SOURCE="${WORKDIR}/patches" epatch
> +

little bash nitpicking... the '\' after '&&' is obsolete syntax

[...]
> +
> + # Tweak the init script
> + local avahi_init=
> + local iscsi_init=
> + local rbd_init=
> + local firewalld_init=
> + cp "${FILESDIR}/libvirtd.init-r15" "${S}/libvirtd.init"

missing || die

[...]
> + sed -e "s/USE_FLAG_FIREWALLD/${firewalld_init}/" -i "${S}/libvirtd.init"
> + sed -e "s/USE_FLAG_AVAHI/${avahi_init}/" -i "${S}/libvirtd.init"
> + sed -e "s/USE_FLAG_ISCSI/${iscsi_init}/" -i "${S}/libvirtd.init"
> + sed -e "s/USE_FLAG_RBD/${rbd_init}/" -i "${S}/libvirtd.init"

missing || die on all seds


> +
> + ## additional host drivers
> + myconf+=" $(use_with apparmor)"
> + myconf+=" $(use_with apparmor apparmor-profiles)"
> + myconf+=" $(use_with virt-network network)"
> + myconf+=" --with-storage-fs"
> + myconf+=" $(use_with lvm storage-lvm)"
> + myconf+=" $(use_with iscsi storage-iscsi)"
> + myconf+=" $(use_with parted storage-disk)"
> + mycond+=" $(use_with glusterfs)"
> + mycond+=" $(use_with glusterfs storage-gluster)"
> + myconf+=" $(use_with lvm storage-mpath)"
> + myconf+=" $(use_with rbd storage-rbd)"
> + myconf+=" $(use_with numa numactl)"
> + myconf+=" $(use_with numa numad)"
> + myconf+=" $(use_with selinux)"
> + myconf+=" $(use_with fuse)"

All this myconf stuff is very difficult to read, why not use a bash array?

In addition, it has two spelling errors "mycond", so gluterfs USE flag
is currently broken. Another reason to not use this form.

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

[hasufell]

On 10/03/2015 04:13 AM, Mike Frysinger wrote:
> Title: GCC 5 Defaults to the New C++11 ABI 
> Author: Mike Frysinger 
> Content-Type: text/plain
> Posted: 2015-10-02
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >=sys-devel/gcc-5
> 
> GCC 5 uses the new C++ ABI by default.  When building new code, you might run
> into link time errors like:
> ...: undefined reference to '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
> Or you might see linkage failures with "std::__cxx11::string" in the output.
> 
> These are signs that you need to rebuild packages using the new C++ ABI.
> You can quickly do so by using revdep-rebuild like so:
> # revdep-rebuild --library 'libstdc\+\+\.so\.6'
> 

We shouldn't assume a particular PM/toolset in news items, IMO. Just
saying that people might have to rebuild packages linked against
libstdc++.so.6 should be enough.

They can read the docs if they don't know how.

[gentoo-dev] getting openssl SLOT right

[hasufell]

While adding libressl support I encountered a lot of ebuilds that do
stuff like:
ssl? ( dev-libs/openssl )

There are very few cases where this is actually correct.

FYI:
# cave contents dev-libs/openssl:0.9.8
/usr/lib64
/usr/lib64/libcrypto.so.0.9.8
/usr/lib64/libssl.so.0.9.8

There are no headers whatsoever. This slot is for binary compatibility
and the only consumer seems to be app-text/acroread. If you build
against openssl, you most certainly need dev-libs/openssl:0.
"dev-libs/openssl:*" or "dev-libs/openssl:=" are not correct either
(yes, there are ebuilds that do that).

If you fix that, also consider adding libressl support [0].


--
[0] https://github.com/gentoo/libressl/wiki/Transition-plan

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

On 09/30/2015 10:11 AM, hasufell wrote:
> On 09/30/2015 08:35 AM, Paweł Hajdan, Jr. wrote:
>> On 9/29/15 3:32 PM, Rich Freeman wrote:
>>> The thing is that I think the libressl authors are shooting themselves
>>> in the feet.  When upstreams do this sort of thing they think they're
>>> making the upgrade path easier by not changing their symbol names.  In
>>> reality, they're making the upgrade path harder by preventing
>>> side-by-side adoption of the new solution.
>>
>> Yeah, it's not that obvious how to handle it best.
>>
>> Curious - how would the alternative look like? My reasoning is that if
>> upstream changes symbols, that makes it easy for a distro to install it
>> side-by-side. However, for anything to use such modified lib, they'd
>> need to change all callers to use the alternative function names,
>> wouldn't they?
>>
> 
> Such questions are better off at the openbsd-tech mailing list.

correcting: the libressl mailing list, also see
http://www.libressl.org/mail.html

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

On 09/30/2015 08:35 AM, Paweł Hajdan, Jr. wrote:
> On 9/29/15 3:32 PM, Rich Freeman wrote:
>> The thing is that I think the libressl authors are shooting themselves
>> in the feet.  When upstreams do this sort of thing they think they're
>> making the upgrade path easier by not changing their symbol names.  In
>> reality, they're making the upgrade path harder by preventing
>> side-by-side adoption of the new solution.
> 
> Yeah, it's not that obvious how to handle it best.
> 
> Curious - how would the alternative look like? My reasoning is that if
> upstream changes symbols, that makes it easy for a distro to install it
> side-by-side. However, for anything to use such modified lib, they'd
> need to change all callers to use the alternative function names,
> wouldn't they?
> 

Such questions are better off at the openbsd-tech mailing list. Please
continue such discussions there, including voicing your opinion about
the course of LibreSSL which I cannot change, so rants and questions
about that are slightly offtopic.

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

On 09/30/2015 01:29 PM, Kristian Fiskerstrand wrote:
> On 09/30/2015 01:27 PM, hasufell wrote:
>> On 09/30/2015 01:22 PM, Rich Freeman wrote:
>>> On Wed, Sep 30, 2015 at 2:35 AM, Paweł Hajdan, Jr. 
>>> <phajdan...@gentoo.org> wrote:
>>>> On 9/29/15 3:32 PM, Rich Freeman wrote:
> 
> ..
> 
>>> Perhaps the in-between solution would be for forking upstreams
>>> to preserve the same symbol names as long as the APIs are
>>> identical, and change them when they are not.  I don't really see
>>> that having any more impact on downstream consumers than silently
>>> changing the APIs and it would probably get rid of the symbol
>>> collision problem.
>>>
> 
>> Again: can you take that to libressl mailing list or start another
>> thread?
> 
> 
> The way I see it this is relevant to the discussion at hand. Before
> implementing any system wide change to support LibreSSL, in order to
> avoid future issues, a proper cost/benefit analysis and discussion is
> in order.
> 

Since I am almost the only one working on it, I am not sure what you
mean with that.

If you have anything to add to the import discussion please do so. But
this thread is not about the general course of LibreSSL, because we are
not forking it. And I doubt that anyone here is going to do that, so I
don't see how such discussion are relevant for us here.

The relevant information that impacts us as distributors has already
been added to this thread and the consequences are as follows:
* virtual does not make sense
* libressl USE flag is necessary
* libressl has to conflict with openssl


> Do we have an overview of what functionality and other pros (hereunder
> security gains that is not fixed in OpenSSL) is gained by implementing
> global LibreSSL support?
> 

Yes, it is widely known:
https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities

> Or is this just increasing our maintenance, and security tracking, etc
> burdens without any strong benefits?
> 

It increases maintenance burden in the same way that clang/libav/qt5
support increases maintenance burden.

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

On 09/30/2015 01:22 PM, Rich Freeman wrote:
> On Wed, Sep 30, 2015 at 2:35 AM, Paweł Hajdan, Jr.
>  wrote:
>> On 9/29/15 3:32 PM, Rich Freeman wrote:
>>> The thing is that I think the libressl authors are shooting themselves
>>> in the feet.  When upstreams do this sort of thing they think they're
>>> making the upgrade path easier by not changing their symbol names.  In
>>> reality, they're making the upgrade path harder by preventing
>>> side-by-side adoption of the new solution.
>>
>> Yeah, it's not that obvious how to handle it best.
>>
>> Curious - how would the alternative look like? My reasoning is that if
>> upstream changes symbols, that makes it easy for a distro to install it
>> side-by-side. However, for anything to use such modified lib, they'd
>> need to change all callers to use the alternative function names,
>> wouldn't they?
> 
> Essentially, or somebody has to write a wrapper library.  But, once
> you start changing the APIs everybody has to start tweaking their code
> anyway to use the modified function prototypes.  Of course, they only
> need to tweak the 10% of functions that changed, and not all of them.
> 
> Effectively it would mean that the new library would start out with
> zero users, which is why nobody does it that way.  However, I think
> the end result is worse, unless you maintain strict compatibility.
> 
> It hasn't been as much of a problem with mariadb because they haven't
> gone changing all their APIs/protocols/etc.
> 
> This is the sort of thing that Java was trying to stop with their
> compatibility requirements, and what a lot of companies try to do with
> trademark.  The problem is that trademark doesn't really extend well
> into things like symbol names and APIs.
> 
> Perhaps the in-between solution would be for forking upstreams to
> preserve the same symbol names as long as the APIs are identical, and
> change them when they are not.  I don't really see that having any
> more impact on downstream consumers than silently changing the APIs
> and it would probably get rid of the symbol collision problem.
> 

Again: can you take that to libressl mailing list or start another thread?

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

On 09/30/2015 02:10 PM, Kristian Fiskerstrand wrote:
> On 09/30/2015 01:51 PM, Rich Freeman wrote:
> 
>> I think it was fair to pause to see if somebody could come up with
>>  a better solution that allows co-existence, but absent that I 
>> don't see any benefit from keeping libressl out of the tree.
>> We'll just experience all the downsides of the fork without the
>> upsides.
> 
> This is what worries me as well, as it increase workload and
> complexity affecting multiple projects without any immediate and
> obvious gain.
> 

I'm not sure if you have followed the link I just posted:
https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities

0 vs 5 high severity vulnerabilities is a pretty obvious gain.

And that's also one pretty good reason to not delay this like the git
migration.

If it was about me, I'd simply remove openssl from gentoo altogether to
reduce maintenance load and avoid the choice-for-the-sake-of-choice
situation, but it's not my package and not my call, so I basically don't
care.


Anyway, I feel like this thread is now definitely drifting offtopic, so
I'm probably not going to follow much of this anymore. Feel free to ping
me directly if there's something actually relevant.

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

No useful comments, so I will proceed as outlined in the transition plan.

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

On 09/29/2015 03:32 PM, Rich Freeman wrote:
> [...]

I have waited 9 days. I don't see a reason to wait another few weeks,
just because you like to bikeshed a lot.

I honestly feel like you are wasting my time, unless _you_ can come up
with a better solution and offer to do the actual work.

So far, no one has worked much on libressl, except me, blueness, hannob
and a few community contributors (like Aric Belsito).

That said, I will go ahead with my work now. If you have something to
actually contribute, please ping me.

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

On 09/29/2015 05:31 PM, Alexis Ballier wrote:
> On Sat, 19 Sep 2015 23:04:14 +0200
> hasufell <hasuf...@gentoo.org> wrote:
> 
>> 2. slowly start migrating those ~550 packages with "libressl" USE flag
>> which is similar to gnutls USE flag.
>> There will be no virtual, because those don't give sufficient control
>> (libressl and openssl are not ABI compatible).
> 
> If API compatibility is guaranteed, a virtual makes more sense than a
> useflag. However, even with this assumption, it's not possible these
> days, because we need to:
> - Fix || ( a:= b:= ) deps handling in package managers (hey dynamic
>   deps :) )
> - Create transitive := deps (useful for other things than virtuals, hey
>   ocaml & haskell).
> 
> 
> So yeah, because of lack of better solution this seems to be the best
> method so far.
> 

Even if we fix the problem of SUBSLOTs in virtuals, we still have the
situation that makes for example virtual/ffmpeg insufficient for a lot
of use cases: even the API is not always strictly compatible, so ebuild
writers sometimes need more fine-grained control over the version strings.

This problem is very likely to arise with libressl as well. They want to
be API compatible, but:
* sometimes drop functions that they think have security flaws that
can't be reasonably fixed
* have their own set of functions on top of the openssl API

Because of the last point, it is also possible that packages start to
rely on libressl-specific API and not just on the common part.

So a virtual doesn't seem to make sense, no matter how you look at it, IMO.

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

On 09/20/2015 08:07 AM, Andrew Savchenko wrote:
> Greetings,
> 
> On Sat, 19 Sep 2015 23:04:14 +0200 hasufell wrote:
>> Friends,
>>
>> I think it is time to import LibreSSL[0]. There are not many packages
>> left that don't compile OOTB and those can be patched (e.g. dev-lang/ruby).
>>
>> My idea would be:
>>
>> 1. import "dev-libs/libressl" (this will block dev-libs/openssl) and
>> introduce the global USE flag "libressl" with the following description:
> 
> Please try to avoid such block, e.g. install libressl to a separate
> location.

No. I'm not going to hack downstream.

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

On 09/20/2015 06:47 PM, Manuel Rüger wrote:
> On 20.09.2015 16:26, hasufell wrote:
>> On 09/20/2015 03:27 PM, Manuel Rüger wrote:
>>> Please stop introducing further tree-wide changes regarding libressl.
>>
>> That's not possible, because in order to introduce the USE flag, we have
>> to break the dep-graph on ~arch temporarily (for 'libressl' USE flag
>> only ofc), because of circular deps.
>>
>> I am working on restoring it now. This does not affect stable branch at
>> all and no one who is not using 'libressl' USE flag (which is
>> practically impossible currently).
>>
> 
> Yet the way you execute your plan now violates several devmanual
> policies. Is there any reason for that rush?
> 

Any reason to bother me? There have been several threads about libressl
and the overlay has been up for more than one year I think. If you have
a suggestions, say it.

>> If you have useful comments regarding the transition, please speak up.
>>
> 
> I remember you being one of the devs who considered code reviewing as a
> useful tool.
> Why don't you add a pull request to Gentoo's github mirror and let other
> devs review and ack it there?
> 

Because then I could simply give up with ~550 packages, where for most
of them the change is a two-liner in RDEPEND. It is common in gentoo to
not ask every single maintainer for tree-wide changes. The python herd
does that too.

If I don't know how to do something or if the changes are non-trivial,
then I will definitely open a bug/PR.

Again: this all happens in unstable arch and practically effects no one,
because people cannot effectively enable the USE flag yet.

Do you want to help or not?

Re: [gentoo-dev] LibreSSL import plan

[hasufell]

On 09/20/2015 03:27 PM, Manuel Rüger wrote:
> Please stop introducing further tree-wide changes regarding libressl.

That's not possible, because in order to introduce the USE flag, we have
to break the dep-graph on ~arch temporarily (for 'libressl' USE flag
only ofc), because of circular deps.

I am working on restoring it now. This does not affect stable branch at
all and no one who is not using 'libressl' USE flag (which is
practically impossible currently).

If you have useful comments regarding the transition, please speak up.