[gentoo-dev] [warning] the bug queue has 81 bugs

2015-08-11 Thread Alex Alexander
Our bug queue has 81 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!



Re: [gentoo-dev] Re: Referencing bug reports in git

2015-08-11 Thread Tobias Klausmann
Hi! 

On Tue, 11 Aug 2015, Duncan wrote:

 Ryan Hill posted on Mon, 10 Aug 2015 18:17:30 -0600 as excerpted:
 
  On Mon, 10 Aug 2015 12:25:58 + (UTC)
  Duncan 1i5t5.dun...@cox.net wrote:
  What about:
  
  * bug number in summary strongly recommended
  
  Making the bug number in the summary manditory or strongly encouraged
  leads to wonderful commit messages like:
  
  ---
  cat-pkg: Fix bug #504321.
 
 Ideally, it'd be something a bit more informative (here taking Gordon's 
 points about the previously suggested B#):
 
 cat-egory/semi-long-package-name: fix amd64-fbsd build error G-504321
 
  I would like to see this be more common:
  
  ---
  cat-pkg: Make the thingy work again
  
  Gentoo-Bug: https://bugs.gentoo.org/504321 *(or 504321 Idon'tcarewhich)
  
  
  If we're limiting the summary to 1 line, 70-75 chars, manditory
  cat/package and bug number there's not a lot of room to summarize in.
 
 Note that a bug number would fit in your above summary very easily, 
 omitting nothing, as it's only ~35/75 length.
 
 Even with my somewhat longer cat/pkg example with the longest arch-
 keyword I could quickly find, there's still room to indicate at minimum 
 build vs runtime error, with the gentoo bug number reference for anyone 
 who might find it interesting enough to look further than the one-line.  
 People can then either select and klipper-popup (adding my usual trigger 
 method to the others people have mentioned), or read the longer 
 description for the full bug URL to click, if they prefer.

The more we stuff into the summary line, the harder it will be to
write meaningful summaries. And thus, people will write crappy
ones or ignore the length limit. I recommend against any more
prescription over Add the the cat/pn if meaningful, don't use
more than 75 characters.

The cat/pn rule is tricky anyway: what if one commit touches 100
packages? Or should that be split into 100 commits for easier
partial rollback?

Regards,
Tobias

-- 
Sent from aboard the Culture ship
Fine Till You Came Along



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
What's not clear with 'apropriate' word in my sentence?

Let me clarify - if package depend either on Qt4 or Qt5 and CAN not be
built with Qt at all - force this behaviour with REQUIRED_USE.

I think that it was obvious that i have meant exactly this case, cause
other cases are unreasonable here.

09.08.2015 23:07, Alexandre Rostovtsev пишет:
 On Sun, 2015-08-09 at 22:38 +0300, Sergey Popov wrote:
 qa team lead hat

 In short - apropriate REQUIRED_USE with setting recommended
 USE-flag(e.g. USE=+qt4 qt5 or USE=qt4 +qt5)

 /qa team lead hat
 
 If a package has optional guis, why should users of the default profile get 
 any
 gui enabled by default? The default profile usually means headless server. 
 It
 means users who specifically don't need gtk, don't need qt4, don't need qt5,
 don't need X.
 
 So please don't + desktop-oriented USE flags in an ebuild's IUSE by default
 unless the whole ebuild is intended mainly for desktop users.
 
 Users will have default behaviour for empty make.conf. If they adjust
 they make.conf to globally include/exclude some Qt-related USEs - they
 are already moving from default and that's why - they can add apropriate
 options to package.use
 
 There is more than one default from which to move away. Different profiles
 globally enable different flags. Desktop, gnome, and kde profiles already 
 enable
 qt4 globally. Plasma already enables qt4 and qt5 globally. And the desktop
 profile will probably end up enabling qt4 and qt5 at some point.
 


-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

2015-08-11 Thread Dmitry Yu Okunev


On 08/11/2015 10:12 AM, Michał Górny wrote:
 Dnia 2015-08-11, o godz. 09:56:55
 Dmitry Yu Okunev dyoku...@ut.mephi.ru napisał(a):
 On 08/11/2015 12:06 AM, Michał Górny wrote:
 3. Too many text, hard to read. Some bugs may refer to a dozen of
 URLs.

 And how is a dozen numbers better?

 Less text, more readable.

 How is:

   Bug: 123451, 453445, 344334, 343444

 more readable than:

   Bug: https://bugs.gentoo.org/123451
   Bug: https://bugs.gentoo.org/453445
   Bug: https://bugs.gentoo.org/344334
   Bug: https://bugs.gentoo.org/343444

 Readability is a matter of formatting, not contents.

 1. One line and 35 chars are certainly more readable than four lines
 and 140 chars.

 Character counts are completely irrelevant to readability. Visual space
 is. And in this case, exhibit A (also known as wall of digits) is more
 likely to get people confused.

 I think it's just individual preference. No sense to argue this. Just
 everybody should consider that there exists another position on this
 question.

 However I want to add an other argument:

 1a. It's easier to parse the Bug: header is there only bug IDs
 (without URLs).
 
 What if there are different bug trackers involved? We sometimes note
 upstream bugs, other distro bugs, pull requests...

For example Gentoo may use Gentoo-Bug:/Bug-Gentoo: as I mentioned.
Debian uses Bug-Debian: for Debian ITS references and Bug: for
upstream bugreport references in their patches (debian/patches/*), IIRC.

 And is there any guarantee that URL format won't be changed in future
 (that everybody won't be have to rewrite their parsers). I mean not
 near future, but any long future.
 
 I doubt it can change *without* changing the bug tracker software.
 And then, old IDs will no longer be relevant.

Why? Just migrate with saved IDs.

 In fact, since the URLs
 are Bugzilla-specific it will allow us to ensure better compatibility
 if we start numbering bugs from 1 again.

IMHO, it's a really bad idea to do not migrate previous data to the new ITS.

 There's URL and there's URI. Even if URL is no longer valid, it will
 still be a valid URI. It will still allow us to uniquely identify
 the bug report.

Only if you will use Bugzilla or some workarounds to imitate Bugzilla.
It's a lock-in.

 2. Strings are read from left to right (at least in English), thus
 having most important information last on the line is not
 convenient.

 This is not literature. Keys usually precede values, and namespaces
 precede namespaced identifiers.

 A commit-comment is not a source code. It's an ordinary text (like
 literature).
 
 Literature is a long continuous text which you read left-to-right,
 and usually without going back. This is short text which you read
 randomly, possibly going back and forth, and scanning for specific
 details.

Well, ok. But personally I have a habit to read such text left-to-right.
It requires split seconds to recognize this lines similarity but it
requires.

Anyway as I said, I will see much more garbage while looking on the
whole text if you will use URLs instead of pure IDs.

 As far as I'm aware, URLs are supported much more widely than
 Gentoo-specific bug numbers. They are uniform and unique by definition.
 The tools using bug numbers can be easily expanded to extract them from
 URLs. I don't really see forking cgit to support Gentoo bug numbers, or
 asking github to provide special rules for our commits.

 We should not adjust our ecosystem for closed and proprietary
 solutions like github.

 URLs are not github invention. Localized bug numbers are local Gentoo
 non-sense. So should we adjust it to ignore the rest of the world and
 expect everyone to create custom hackery just to be able to see a bug
 report?

 You can use header Gentoo-Bug: (instead of Bug:) and explain in
 documentation ways to parse that.
 
 So you're suggesting it's better to invent a custom format and tell
 people how to handle it, rather than use a commonly-supported format?

What you mean with the custom format? I suggest to use comment as a
comment, but not as a documentation about How to reach Gentoo ITS in
every comment.

I can agree with another argument:
There should be a possibility to define an upstream bug which format in
turn can be simply unified only by URLs. And it may became harder to
read when neighboring headlines are formatted different ways (one header
— pure IDs, another one — URLs). But _IMHO_, it doesn't outweigh
disadvantages of this approach (with URLs for reference on Gentoo bug).

--
Best regards, Dmitry.



signature.asc
Description: OpenPGP digital signature


Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

2015-08-11 Thread Kent Fredric
On 11 August 2015 at 20:38, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-08-11, o godz. 10:29:55
 Alexander Berntsen berna...@gentoo.org napisał(a):

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 10/08/15 22:59, Aaron W. Swenson wrote:
  Users can fetch/pull from Github.
 Users should not have to interface with or rely on proprietary
 software to use Gentoo.

 Then please provide them with true open-source infrastructure. And also
 remember to block all the mirrors by default.


Its fine to say can in the context of They may if they want to, but
they are not forced to.

Having a quality infrastructure should happen in parallel to github mirrors.

Uses may use the proprietary one or the opensource one.

As long as nothing *demands* they use the proprietary instead of the
opensource one, and there is a working path that is usable and
covenient to avoid the proprietary ( which there is in this case ),
then there's no real foul.

The only downside is realistically, if all users cloned from gentoo
infra using git, then we would drown.

Ban mirrors wouldn't fix this problem, Ban github wouldn't fix this problem.

So you basically *must* implement a reasonable infrastructure, and
they can use github instead if it is more convenient for them.

To an extent this does imply we're relying that *some* users will use
github/other to decrease our server load.

Meh.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL



Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

2015-08-11 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/08/15 22:59, Aaron W. Swenson wrote:
 Users can fetch/pull from Github.
Users should not have to interface with or rely on proprietary
software to use Gentoo.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVybKCAAoJENQqWdRUGk8BIWcQANRXyH+ZRJImlbASQM1QSApS
hr7Y8xFj8Wm9Ym8gTJCCxyWW8frW7yCyAJByHF6znRCjxl3qRGfKGnMd/gfYR5l8
UmRHVKaqborjzkhd6+W0EtjvxWJ6bwI2FGG4p+xCk7uVAN4V2leu2gxSeUTfWO18
DfJd92y7LM5xrzsmE5KUyB1uaHzdfxbZpR1tHix/jzK6Wpp90/lJVVL3AwnRz6Cu
T9TmTXkVnWck7DIHU8OKluxgdKrEbkKRkB5wzgESAHd75T9HvECwBpFcAXkdr4X2
vnYx4+ZXvydgu8WAFimAefbpbQVaCZd8AQ9XFOIo3tiy8di5ALlSKNXG6cdVlsue
GaU+qNkJavzOI+QtydJGogY7hhT3rAP1BBeeZxXdTjBO9qQUB3LCcK6IsXtbtQw/
+cbmPJPm4r1wRJD1x7NxU/1LWO3JNTcM1YxvskdKKiDYAnBadMEcjPHWt7vUA8QR
GWze8YvcAr6VDjPqd366kM/fvmY4Y/2TNl3wWCB18Nagoq6dx2ba0//4pMUpfOdS
/1WDMoJRQ/M4cfShgZvNnvCM7qNcJXzLc68fD1xzzvWEyhkOj/vydeztzNykLzop
BUgl08J0jgokbVAwxzlnOubtK2F7vSLu6hFBliVQINoNqbPpTjxE3NIJvPfFkeUL
qhbaV+CoPE7MNeH4a0lt
=asRz
-END PGP SIGNATURE-



Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

2015-08-11 Thread Dmitry Yu Okunev
Hello.

I'm not a gentoo-dev, so sorry if I shouldn't express my thoughts with
my lame English here. Please tell me if it's so.

On 08/11/2015 12:06 AM, Michał Górny wrote:
 3. Too many text, hard to read. Some bugs may refer to a dozen of
 URLs.

 And how is a dozen numbers better?

 Less text, more readable.

 How is:

   Bug: 123451, 453445, 344334, 343444

 more readable than:

   Bug: https://bugs.gentoo.org/123451
   Bug: https://bugs.gentoo.org/453445
   Bug: https://bugs.gentoo.org/344334
   Bug: https://bugs.gentoo.org/343444

 Readability is a matter of formatting, not contents.

 1. One line and 35 chars are certainly more readable than four lines
 and 140 chars.
 
 Character counts are completely irrelevant to readability. Visual space
 is. And in this case, exhibit A (also known as wall of digits) is more
 likely to get people confused.

I think it's just individual preference. No sense to argue this. Just
everybody should consider that there exists another position on this
question.

However I want to add an other argument:

1a. It's easier to parse the Bug: header is there only bug IDs
(without URLs).

And is there any guarantee that URL format won't be changed in future
(that everybody won't be have to rewrite their parsers). I mean not
near future, but any long future.

 2. Strings are read from left to right (at least in English), thus
 having most important information last on the line is not
 convenient.
 
 This is not literature. Keys usually precede values, and namespaces
 precede namespaced identifiers.

A commit-comment is not a source code. It's an ordinary text (like
literature).

 3. A lot of duplicated and useless information consumes time and
 space, irritating people.
 
 Well, maybe I'm very special then because I can *instantly* notice that
 the four quoted lines are almost identical and differ only by bug
 numbers.

Yes. But as for me this duplicated text adds a lot of garbage to the
total text of a comment. It's harder to fast look over it. You were
right — Visual space does matter.

And Andrew said useless information — I agree.

 4. Think about people using special accessibility devices like
 speech-to-text engine or Braille terminal. It will be pain for them
 to read all this notorious URLs. And we have at least one developer
 relying upon such devices.
 
 And that's the first valid argument. Though I would doubt that
 accessibility software handles random numbers better than URLs. Unless
 you consider retyping one of the six numbers you just heard easier than
 triggering some kind of URL activation feature.

I remember that William Hubbs asked me to remove one very simple
ASCII-arted scheme (that explains how the code works) from a patch,
because it's very inconvenient to listen that stuff using speech-to-text
engines. May be somebody should just ask him for his opinion on this
question? I think it's more convenient to listen pure bug IDs rather
than a lot of full URLs.

 What is a corner case? Why not defining clicking on the link in
 the git log as a corner case?

 As far as I'm aware, URLs are supported much more widely than
 Gentoo-specific bug numbers. They are uniform and unique by definition.
 The tools using bug numbers can be easily expanded to extract them from
 URLs. I don't really see forking cgit to support Gentoo bug numbers, or
 asking github to provide special rules for our commits.

 We should not adjust our ecosystem for closed and proprietary
 solutions like github.
 
 URLs are not github invention. Localized bug numbers are local Gentoo
 non-sense. So should we adjust it to ignore the rest of the world and
 expect everyone to create custom hackery just to be able to see a bug
 report?

You can use header Gentoo-Bug: (instead of Bug:) and explain in
documentation ways to parse that.

-- 
Best regards, Dmitry.



signature.asc
Description: OpenPGP digital signature


Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

2015-08-11 Thread Michał Górny
Dnia 2015-08-11, o godz. 10:29:55
Alexander Berntsen berna...@gentoo.org napisał(a):

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 On 10/08/15 22:59, Aaron W. Swenson wrote:
  Users can fetch/pull from Github.
 Users should not have to interface with or rely on proprietary
 software to use Gentoo.

Then please provide them with true open-source infrastructure. And also
remember to block all the mirrors by default.

-- 
Best regards,
Michał Górny
http://dev.gentoo.org/~mgorny/


pgpQRRnGxpZR1.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
Err, i have read the whole thread and still does not get a point, why i
am wrong.

It's old battle like we have beforce with gtk meaning any versions of
GTK flag. This behaviour should be killed with fire.

Let's me reiterate some of the cases:

1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can
be chosen, but not both.

Fix this with REQUIRED_USE, do not enable any of Qt flags by default

2. Package can not be build without Qt GUI - either Qt4 or Qt5 is
required, but not both

Same thing here, different REQUIRED_USE operator. But - enable one of
the flags by default to ease life of users.

3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
package even exists?)

Do not use REQUIRED_USE here, not needed.

Now, please tell me, where am i wrong?

09.08.2015 23:08, Davide Pesavento пишет:
 On Sun, Aug 9, 2015 at 12:38 PM, Sergey Popov pinkb...@gentoo.org wrote:
 qa team lead hat

 In short - apropriate REQUIRED_USE with setting recommended
 USE-flag(e.g. USE=+qt4 qt5 or USE=qt4 +qt5)

 /qa team lead hat

 That's most painless decision for both developers and users. Developers
 do not need to maintain ugly dependencies like

 DEPEND=qt4 ? (
 qt5 ( dev-qt/qtcore:5 )
 !qt5 ( dev-qt/qtcore:4 )
 )
 ...
 
 and other mess.

 /qa team lead hat

 Users will have default behaviour for empty make.conf. If they adjust
 they make.conf to globally include/exclude some Qt-related USEs - they
 are already moving from default and that's why - they can add apropriate
 options to package.use

 
 Sergey,
 
 It seems you completely ignored the discussion that took place in this
 thread (and I also think you misunderstood the scenario judging from
 the example you gave). Therefore I'm sorry but I will ignore your
 opinion as QA team lead.
 
 Thanks,
 Davide
 

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

2015-08-11 Thread Leno Hou
I think ppc64le would become popular,  https://en.wikipedia.org/wiki/Ppc64.

1. enable porting x86 Linux based application with minimal effort.
2. Some PowerPC user, little endian apparently feels cheap, wrong, and
PCish.
3. Other distrbutions like Ubuntu, Redhat and SUSE already support little
endian in powerpc.


*Leno Hou*
E-mail :  leno...@gmail.com

On Tue, Aug 11, 2015 at 5:49 PM, James Le Cuirot ch...@gentoo.org wrote:

 On Tue, 11 Aug 2015 17:22:21 +0800
 Leno Hou leno...@gmail.com wrote:

  Please let me know forward/steps to port gentoo on ppc64le.

 I'm not on the ppc team but I do some ppc(64) testing for Java
 packages. Although these are relatively well-maintained keywords
 overall, I think the team would struggle to cope with an additional
 one. It's also important to note that while ppc and ppc64 can be tested
 on the same hardware, I think ppc64le would require different hardware?
 If ppc64le does become popular then I would suggest that we drop 32-bit
 ppc first. Others may disagree though. :)

 --
 James Le Cuirot (chewi)
 Gentoo Linux Developer



Re: [gentoo-dev] Re: Referencing bug reports in git

2015-08-11 Thread Kent Fredric
On 11 August 2015 at 20:57, Tobias Klausmann klaus...@gentoo.org wrote:

 The cat/pn rule is tricky anyway: what if one commit touches 100
 packages? Or should that be split into 100 commits for easier
 partial rollback?


I think you've misread The rule

https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_Message_Format

Emphasis added:

 commits that affect **primarily** a particular subsystem should prepend the 
  following code to the first line of the commit message:

 **if the change affects multiple directories**, but is mostly related to a 
 particular subsystem, then prepend the subsystem which best reflects the 
 intention (e.g. you add a new license, but also modify profiles/license_group


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL



Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

2015-08-11 Thread Michał Górny
Dnia 2015-08-11, o godz. 09:56:55
Dmitry Yu Okunev dyoku...@ut.mephi.ru napisał(a):

 Hello.
 
 I'm not a gentoo-dev, so sorry if I shouldn't express my thoughts with
 my lame English here. Please tell me if it's so.
 
 On 08/11/2015 12:06 AM, Michał Górny wrote:
  3. Too many text, hard to read. Some bugs may refer to a dozen of
  URLs.
 
  And how is a dozen numbers better?
 
  Less text, more readable.
 
  How is:
 
Bug: 123451, 453445, 344334, 343444
 
  more readable than:
 
Bug: https://bugs.gentoo.org/123451
Bug: https://bugs.gentoo.org/453445
Bug: https://bugs.gentoo.org/344334
Bug: https://bugs.gentoo.org/343444
 
  Readability is a matter of formatting, not contents.
 
  1. One line and 35 chars are certainly more readable than four lines
  and 140 chars.
  
  Character counts are completely irrelevant to readability. Visual space
  is. And in this case, exhibit A (also known as wall of digits) is more
  likely to get people confused.
 
 I think it's just individual preference. No sense to argue this. Just
 everybody should consider that there exists another position on this
 question.
 
 However I want to add an other argument:
 
 1a. It's easier to parse the Bug: header is there only bug IDs
 (without URLs).

What if there are different bug trackers involved? We sometimes note
upstream bugs, other distro bugs, pull requests...

 And is there any guarantee that URL format won't be changed in future
 (that everybody won't be have to rewrite their parsers). I mean not
 near future, but any long future.

I doubt it can change *without* changing the bug tracker software.
And then, old IDs will no longer be relevant. In fact, since the URLs
are Bugzilla-specific it will allow us to ensure better compatibility
if we start numbering bugs from 1 again.

There's URL and there's URI. Even if URL is no longer valid, it will
still be a valid URI. It will still allow us to uniquely identify
the bug report.

  2. Strings are read from left to right (at least in English), thus
  having most important information last on the line is not
  convenient.
  
  This is not literature. Keys usually precede values, and namespaces
  precede namespaced identifiers.
 
 A commit-comment is not a source code. It's an ordinary text (like
 literature).

Literature is a long continuous text which you read left-to-right,
and usually without going back. This is short text which you read
randomly, possibly going back and forth, and scanning for specific
details.

  As far as I'm aware, URLs are supported much more widely than
  Gentoo-specific bug numbers. They are uniform and unique by definition.
  The tools using bug numbers can be easily expanded to extract them from
  URLs. I don't really see forking cgit to support Gentoo bug numbers, or
  asking github to provide special rules for our commits.
 
  We should not adjust our ecosystem for closed and proprietary
  solutions like github.
  
  URLs are not github invention. Localized bug numbers are local Gentoo
  non-sense. So should we adjust it to ignore the rest of the world and
  expect everyone to create custom hackery just to be able to see a bug
  report?
 
 You can use header Gentoo-Bug: (instead of Bug:) and explain in
 documentation ways to parse that.

So you're suggesting it's better to invent a custom format and tell
people how to handle it, rather than use a commonly-supported format?

-- 
Best regards,
Michał Górny
http://dev.gentoo.org/~mgorny/


pgpFUxUHmcnoq.pgp
Description: OpenPGP digital signature


[gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

2015-08-11 Thread Leno Hou
Greetings ! Any Ideas/steps of how to  porting gentoo on  ppc64le
architecture?

Is it that we should add 'ppc64le' keyword to portage ?


As some of you might know,  Ubuntu has been introduced in support of
ppc64le. http://www.ubuntu.com/download/server/power8 ! It's just as it
 sounds  ppc64( 64bit only ) but little endian. I've been made basic chroot
environment  in my
Ubuntu 14.04 ppc64le manually, the packages was built  and you can see here
for detail:
https://bpaste.net/show/e99035777057

And another way how to porting is: https://wiki.gentoo.org/wiki/Porting

Please let me know forward/steps to port gentoo on ppc64le.

Appreciated your thoughts, comments and efforts on it ~~~

Leno Hou
E-mail: leno...@gmail.com


Re: [gentoo-dev] git commit / push signing error

2015-08-11 Thread Thomas Kahle
Hi,

On 10/08/15 21:02, Daniel Campbell (zlg) wrote:
 On 08/10/2015 06:15 AM, Doug Goldstein wrote:
 On Mon, Aug 10, 2015 at 3:36 AM, Chí-Thanh Christopher Nguyễn 
 chith...@gentoo.org wrote:
 Doug Goldstein schrieb:
 gpg: cancelled by user gpg: skipped 0xA2BC03DC87ED1BD4:
 Operation cancelled gpg: signing failed: Operation cancelled 
 error: gpg failed to sign the data

 There was an IRC discussion yesterday about this. Probably your
 pinentry tries to talk to a GUI and fails. Try:

 unset DISPLAY export GPG_TTY=$(tty)

 to make it fall back to curses, or use eselect pinentry to
 select curses as default.

 Interestingly, git requires GPG_TTY if eselect-pinentry is set to
 gtk-2 or qt4, but repoman doesn't.


 Best regards, Chí-Thanh Christopher Nguyễn


 
 $ eselect pinentry show Current pinentry binary implementation: 
 pinentry-curses
 
 $ eselect pinentry list Available pinentry binary implementations: 
 [1]   pinentry-curses *
 
 Its the only version I've got on this machine. The box is headless
 and I ssh into and I use keychain to manage my SSH and GPG agent.
 
 What's your keychain line look like in your .bashrc/.bash_profile?
 Here's the relevant portion of mine. I was also having problems with
 it until I changed the order of the arguments:
 
 [snip]
 /usr/bin/keychain --agents ssh,gpg ~/.ssh/id_rsa ${GPGKEY}
 source ~/.keychain/sporkbox-sh  /dev/null
 source ~/.keychain/sporkbox-sh-gpg  /dev/null
 [snip]

I have it exactly like you but I can reproduce the problem as
follows.

- I ssh into a long running byobu session on the machine.
- I have pinentry-curses eselected

1) Spawn a new shell, keychain runs, pinentry-curses asks for the
passphrases that are not cached yet, and everything is fine (in
all running shells!).

2) Log off and return only after the passphrase timeout of the agent

3) The problem described in this thread appears, pinentry-curses
won't start, both $DISPLAY and $tty are empty.

4) To fix, I just need to run any process that is able to start
pinentry-curses and type the passphrase.  Keychain is one option
for that.  git --signed is not.

The only thing that is diffent from your setup is that I use zsh.
Looking at the scripts created by keychain this should be fine,
though.

If somebody knows how to configure pinentry curses correctly (in
particular with respect to screen/multiplexing and long running
sessions, that would be a great help (and wiki addition).

Cheers,
Thomas



-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

2015-08-11 Thread James Le Cuirot
On Tue, 11 Aug 2015 17:22:21 +0800
Leno Hou leno...@gmail.com wrote:

 Please let me know forward/steps to port gentoo on ppc64le.

I'm not on the ppc team but I do some ppc(64) testing for Java
packages. Although these are relatively well-maintained keywords
overall, I think the team would struggle to cope with an additional
one. It's also important to note that while ppc and ppc64 can be tested
on the same hardware, I think ppc64le would require different hardware?
If ppc64le does become popular then I would suggest that we drop 32-bit
ppc first. Others may disagree though. :)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer



Re: [gentoo-dev] Re: rsync mirror security

2015-08-11 Thread Rich Freeman
On Mon, Aug 10, 2015 at 11:44 PM, Matthias Maier tam...@gentoo.org wrote:
 That is, I was under the impression signing a tag only signs the
 references themselves, and then relies on SHA1 referential integrity
 beyond that.

 No, a signed tag verifies that the whole integrirty of the entire
 repository, whereas a signed commit only authenticates the differences
 introduced by a single commit.

 As long as there are no conflicts, a signed commit can be rebased
 freely (especially also on top of malicious commits...).


A signed commit and a signed tag are basically equivalent as far as
authentication of the contents of the tree go.  All a tag does is
reference a commit by sha1, and a commit references the top level
directory of the tree by sha1 in the state it was in when it was
created.

Sure, you can rebase a commit, but that doesn't actually change a
commit.  It creates one or more new commits in the place of a bunch of
existing ones with new sha1s, and points the current head at the last
one.  If the old commits are no longer referenced by any other heads
they will get garbage collected.  If you point two heads at the same
commit and do a rebase the history as seen by the other head won't
change at all.

Since a tag is just a label it is actually EASIER to tamper with than
a commit.  You can't change a commit without changing its hash.  tags
are referenced by name, not by hash, which is basically the whole
point, so you CAN change the content of a tag and have it keep the
same name.  Of course, if you try to push/pull that new tag git is
going to complain about the inconsistency, just as it does if you try
to do a non-fast-forward push and so on.

I don't think that having a bazillion tags or rewriting them
constantly adds any security to the tree.  What might add security for
end-users is if git automatically checked the push signatures, which
are the signatures that ensure that branches aren't tampered with
(which is what rebasing you bring up actually does).

-- 
Rich



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
11.08.2015 15:30, Michael Palimaka пишет:
 On 11/08/15 20:10, Sergey Popov wrote:
 Err, i have read the whole thread and still does not get a point, why i
 am wrong.
 
 You clearly have not. The reasoning behind Qt team's policy is described
 on the page and has been reiterated on this list. You are undermining
 what little confidence there is in the QA team by making decisions with
 no consultation about problems you do not understand.
 
 It's old battle like we have beforce with gtk meaning any versions of
 GTK flag. This behaviour should be killed with fire.

 Let's me reiterate some of the cases:

 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can
 be chosen, but not both.

 Fix this with REQUIRED_USE, do not enable any of Qt flags by default
 
 Problem: this requires manual intervention if the user has both qt4 and
 qt5 USE flags enabled.


User choice of using USE flags is NOT a problem


 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is
 required, but not both

 Same thing here, different REQUIRED_USE operator. But - enable one of
 the flags by default to ease life of users.
 
 Problem: this requires manual intervention if the user has both qt4 and
 qt5 USE flags enabled.

Same here


 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
 package even exists?)

 Do not use REQUIRED_USE here, not needed.

 Now, please tell me, where am i wrong?

 
 The problem is manual intervention is required if the user has both qt4
 and qt5 USE flags enabled - and this is a common configuration. It is
 not acceptable to make a user manually add numerous package.use entries
 when all they want to do is install KDE.

And here

 I agree Qt's policy is not a perfect solution, but in the absence of
 some feature allowing a preference to be set when there is a conflict
 it's the best we've got.
 

If you want to go this way, then please provide helper functions in
eclasses to set dependencies properly for all common use cases. That
will ease life both of developers and users.

Leaving constructing of dependencies to developers in all cases will
cause only pain in your solution.

Look at the example with berkdb/gdbm, that i have posted recently.

If both of flags are not set - we stick to default.
Should this be set in EVERY ebuild explicitly?

Maybe provide some sugar like $(qt_use_default qtgui 5), where
qt_use_default is the name of function, qtgui is the package and 5 is
the slot for default choice, where either BOTH of flags(qt4, qt5) are
enabled or disabled

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
11.08.2015 15:32, Michael Palimaka пишет:
 On 11/08/15 20:17, Sergey Popov wrote:
 09.08.2015 23:28, Ulrich Mueller пишет:
 I disagree with this. Really, REQUIRED_USE should be used sparingly,
 and IMHO the above is not a legitimate usage case for it.

 So, you prefer to make ugly mess of deps here like i posted before or
 introduce some really unneded USE-flag like 'gui', 'qt', etc. to make
 users even more confused?

 Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags.
 And dependency string like this:

 !berkdb? ( !gdbm? ( sys-libs/gdbm ) )

 One sentence: WHAT THE HELL?

 Imagine that it would be dozen of flags. Is it fun to mess with deps
 like this for you?
 
 Shall we ban this too?
 
 ffmpeg? (
 libav? ( media-video/libav:= )
 !libav? ( media-video/ffmpeg:0= )
 )
 
 
 
 

No, because ffmpeg here is a feature AND name of concrete realization.
Not ideal case as i would said, but it is acceptable.

You want to migrate to such decision? Like:

qt? (
qt5? ( dev-lang/qtcore:5 )
!qt5? ( dev-lang/qtcore:4 )
)

Fine by me, if you would ask.

As i said one message earlier: Something like $(qt_use_default qtgui 5)

which will generate something like this:

qt4? (
qt5? ( dev-lang/qtcore:5 )
!qt5? ( dev-lang/qtcore:4 )
)
!qt5? ( !qt4? ( dev-lang/qtcore:5 ) )

would help too.

If you are doing complicated things(and please, do not tell me that
provided dependency string is simple and understandable by every
developer in just a second without wanting to improve or simplify
it) - do it through eclass. And provide nice API.

Thanks for listening and sorry if i was too harsh

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
11.08.2015 13:18, Georg Rudoy пишет:
 
 You missed the fourth option: the package can not be built without Qt
 GUI, but it supports building with either Qt version at the same time.
 

Not a problem.

REQUIRED_USE=|| ( qt4 qt5 )

At least one of flags should be enabled, but both can be enabled too(if
i understand your example correctly)

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Georg Rudoy
2015-08-11 11:10 GMT+01:00 Sergey Popov pinkb...@gentoo.org:

 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
 package even exists?)


Take app-text/poppler as an officially supported example.

Take x11-libs/qwt as an example of a library that gets a patched library
name to avoid collisions (at least, last time I looked into it).

I would argue this is a very desirably property for libraries in general. I
even keep my own small overlay with Qt5-enabled versions of libraries like
qxmpp, qtermwidget or liblastfm.


 Do not use REQUIRED_USE here, not needed.


You missed the fourth option: the package can not be built without Qt GUI,
but it supports building with either Qt version at the same time.

-- 
  Georg Rudoy


[gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
I'd suggest to make a QA team meeting to override this policies with
more correct and rationale.

Qt team members are greatly appreciated on this meeting. Even more, i
think that we should not take any decision on this without at least Qt
team lead(or half of Qt team devs)

So, let's arrange some time and talk about this, cause it is really
confusing. Qt team point is understandable, but it's still wrong. Let's
make some consensus here.

02.08.2015 19:34, Ben de Groot пишет:
 Recently some team members of the Qt project have adopted these ebuild
 policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies
 
 I have an issue with the policy adopted under Requires one of two Qt
 versions. In my opinion, in the case where a package offers a choice
 between qt4 or qt5, we should express this in explicit useflags and a
 REQUIRED_USE=^^ ( qt4 qt5 ). This offers the user the clearest choice.
 
 Other developers state that users are not interested in such
 implementation details, or that forced choice through REQUIRED_USE is
 too much of a hassle. This results in current ebuilds such as quassel to
 not make it clear that qt4 is an option.
 
 This goes against the principle of least surprise, as well as against QA
 recommendations. I would like to hear specifically from QA about how we
 should proceed, but comments from the wider developer community are also
 welcome.
 
 -- 
 Cheers,
 
 Ben | yngwin
 Gentoo developer
 


-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/

2015-08-11 Thread hasufell
On 08/11/2015 08:34 AM, Mike Frysinger wrote:
 commit: 719cc5ef240b766953ddbe1e7a6593f8091eed12
 Author: Mike Frysinger vapier AT gentoo DOT org
 AuthorDate: Tue Aug 11 06:28:16 2015 +
 Commit: Mike Frysinger vapier AT gentoo DOT org
 CommitDate: Tue Aug 11 06:34:22 2015 +
 URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=719cc5ef
 
 microcode-ctl: stop installing the init script
 
 Updating microcode on the fly is dangerous as it can modify the set of
 valid instructions.  An active example of this is Intel's TSX insns --
 the latest microcode push disables the insn on newer CPUs and causes
 SIGILL when you try to use it.  But if you test for the insn before the
 microcode is updated, it will execute fine.  For daemons that launched
 before the update, they'll find the flag works, and then crash later on
 when the insn no longer exists.
 
 Thus the only safe way to update microcode is at boot time via a builtin
 initramfs.  Details on this operation can be found in #528712#41.
 

I've already asked you twice on the ML why you keep ignoring the
standard we set for the commit message summary and pretty much everyone
is following except you.

Do you ignore us on purpose?



Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

2015-08-11 Thread Ciaran McCreesh
On Tue, 11 Aug 2015 10:29:55 +0200
Alexander Berntsen berna...@gentoo.org wrote:
 On 10/08/15 22:59, Aaron W. Swenson wrote:
  Users can fetch/pull from Github.
 Users should not have to interface with or rely on proprietary
 software to use Gentoo.

Like the stuff running on the big expensive routers that make the
internets work? Can I have my tree delivered by pigeon, since I suspect
the post office runs Windows?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Referencing bug reports in git

2015-08-11 Thread Rich Freeman
On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric kentfred...@gmail.com wrote:
 On 11 August 2015 at 20:57, Tobias Klausmann klaus...@gentoo.org wrote:

 The cat/pn rule is tricky anyway: what if one commit touches 100
 packages? Or should that be split into 100 commits for easier
 partial rollback?

 **if the change affects multiple directories**, but is mostly related to a 
 particular subsystem, then prepend the subsystem which best reflects the 
 intention (e.g. you add a new license, but also modify 
 profiles/license_group

++
Go read the proposal.  This email chain simplifies it but people have
already thought of most of those corner cases already.

However, I do want to touch on this bit from the previous email: Or
should that be split into 100 commits for easier partial rollback?

Each commit should be one logical change.  If you stabilize 100
separate packages in an afternoon, there should be 100 commits.  If
you stabilize kde-5.0 there probably should be one commit that touches
100 packages.  Likewise if you rename a package and fix 100 references
to it in other packages, that should probably also be a single commit
(but I'd separate renaming the package from any other changes to the
content of the package).

That is actually one of the advantages of git.  You can stabilize
kde-5 and a user doing an rsync will either get kde 4.x or the full
kde 5, and nothing in-between.

But, one commit in the final tree should still remain one logical change.

-- 
Rich



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
11.08.2015 16:04, Sergey Popov пишет:
 11.08.2015 15:32, Michael Palimaka пишет:
 On 11/08/15 20:17, Sergey Popov wrote:
 09.08.2015 23:28, Ulrich Mueller пишет:
 I disagree with this. Really, REQUIRED_USE should be used sparingly,
 and IMHO the above is not a legitimate usage case for it.

 So, you prefer to make ugly mess of deps here like i posted before or
 introduce some really unneded USE-flag like 'gui', 'qt', etc. to make
 users even more confused?

 Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags.
 And dependency string like this:

 !berkdb? ( !gdbm? ( sys-libs/gdbm ) )

 One sentence: WHAT THE HELL?

 Imagine that it would be dozen of flags. Is it fun to mess with deps
 like this for you?

 Shall we ban this too?

 ffmpeg? (
 libav? ( media-video/libav:= )
 !libav? ( media-video/ffmpeg:0= )
 )




 
 No, because ffmpeg here is a feature AND name of concrete realization.
 Not ideal case as i would said, but it is acceptable.
 
 You want to migrate to such decision? Like:
 
 qt? (
   qt5? ( dev-lang/qtcore:5 )
   !qt5? ( dev-lang/qtcore:4 )
 )
 
 Fine by me, if you would ask.
 
 As i said one message earlier: Something like $(qt_use_default qtgui 5)
 
 which will generate something like this:
 
 qt4? (
   qt5? ( dev-lang/qtcore:5 )
   !qt5? ( dev-lang/qtcore:4 )
 )
 !qt5? ( !qt4? ( dev-lang/qtcore:5 ) )
 
 would help too.
 
 If you are doing complicated things(and please, do not tell me that
 provided dependency string is simple and understandable by every
 developer in just a second without wanting to improve or simplify
 it) - do it through eclass. And provide nice API.
 
 Thanks for listening and sorry if i was too harsh
 

Oops, sorry dev-qt/qtgui inside the brackets, of course.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
11.08.2015 16:11, James Le Cuirot пишет:
 On Tue, 11 Aug 2015 15:58:49 +0300
 Sergey Popov pinkb...@gentoo.org wrote:
 
 If both of flags are not set - we stick to default.
 Should this be set in EVERY ebuild explicitly?

 Maybe provide some sugar like $(qt_use_default qtgui 5), where
 qt_use_default is the name of function, qtgui is the package and 5 is
 the slot for default choice, where either BOTH of flags(qt4, qt5) are
 enabled or disabled
 
 That sounds a little bit like what I suggested earlier.
 
 https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df
 

But without introducing brand new useless USE flag. Which makes huge
difference to me :-)

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
09.08.2015 23:28, Ulrich Mueller пишет:
 I disagree with this. Really, REQUIRED_USE should be used sparingly,
 and IMHO the above is not a legitimate usage case for it.

So, you prefer to make ugly mess of deps here like i posted before or
introduce some really unneded USE-flag like 'gui', 'qt', etc. to make
users even more confused?

Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags.
And dependency string like this:

!berkdb? ( !gdbm? ( sys-libs/gdbm ) )

One sentence: WHAT THE HELL?

Imagine that it would be dozen of flags. Is it fun to mess with deps
like this for you?

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

2015-08-11 Thread Rich Freeman
On Tue, Aug 11, 2015 at 5:07 AM, Kent Fredric kentfred...@gmail.com wrote:

 Having a quality infrastructure should happen in parallel to github mirrors.

 Uses may use the proprietary one or the opensource one.


While I generally tend to agree with you, if we're just talking about
mirroring is this a real problem?

Right now Gentoo has a large number of rsync/http mirrors.  As far as
any of us are concerned, they're just an DNS address that speaks
rsync/http.  None of us have any idea what OS or software they're
running.  If one of our mirrors is IIS running on Windows 7, that is
pretty transparent to the end user.  They're just mirrors.

That is basically all github is in this case.  A commit shows up in
the gentoo infra repository, and some process somewhere pushes it to
the github repository.  If we were to set up an independent network of
git mirrors, they'd probably work the same way.  (Git should actually
be pretty easy to mirror.)  To an end user all they see is a DNS name
that talks whatever protocol git uses.  Short of an on-site inspection
you'd never be able to prove that it is actually FOSS.

Apologies if I sounds like an MS open standards, not open source
shill - but to some extent when you're talking about networked
services they work out to be the same thing.  I think it is far more
important to keep the infrastructure that creates the tree pure-FOSS
(and documented/published so that anybody who wants to could basically
roll their own Gentoo).  If we use a more commercial service to just
help scale it up like a CDN or something like github, that isn't
really as essential to the essence of Gentoo.  I do think that people
who complain about depending on a github-based workflow have a
legitimate concern, but that isn't what we're talking about here.

In any case, nobody is getting rid of the rsync mirrors anytime soon,
so we don't have to be in any rush to figure this out.  Consider this
thinking out loud if you will...

-- 
Rich



Re: [gentoo-dev] Re: Referencing bug reports in git

2015-08-11 Thread hasufell
On 08/11/2015 01:49 PM, Rich Freeman wrote:
 On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric kentfred...@gmail.com wrote:
 On 11 August 2015 at 20:57, Tobias Klausmann klaus...@gentoo.org wrote:

 The cat/pn rule is tricky anyway: what if one commit touches 100
 packages? Or should that be split into 100 commits for easier
 partial rollback?

 **if the change affects multiple directories**, but is mostly related to a 
 particular subsystem, then prepend the subsystem which best reflects the 
 intention (e.g. you add a new license, but also modify 
 profiles/license_group
 
 ++
 Go read the proposal.  This email chain simplifies it but people have
 already thought of most of those corner cases already.
 
 However, I do want to touch on this bit from the previous email: Or
 should that be split into 100 commits for easier partial rollback?
 
 Each commit should be one logical change.  If you stabilize 100
 separate packages in an afternoon, there should be 100 commits.  If
 you stabilize kde-5.0 there probably should be one commit that touches
 100 packages.  Likewise if you rename a package and fix 100 references
 to it in other packages, that should probably also be a single commit
 (but I'd separate renaming the package from any other changes to the
 content of the package).
 
 That is actually one of the advantages of git.  You can stabilize
 kde-5 and a user doing an rsync will either get kde 4.x or the full
 kde 5, and nothing in-between.
 
 But, one commit in the final tree should still remain one logical change.
 

Right.

In addition, we just took the freedom to add the clause all commits
must be repoman-valid:
https://wiki.gentoo.org/index.php?title=Gentoo_git_workflowdiff=352978oldid=352858

That will be necessary too for the CI work mgorny is doing and will also
make bisecting and cherry-picking easier.

That is: if splitting up a commit into several makes repoman fail on
some of them, it probably should be one commit instead (or you have to
reconsider the order you commit stuff in... e.g. first add the license
and then the package).


But we are drifting OT again.



[gentoo-dev] Re: useflag policies

2015-08-11 Thread Michael Palimaka
On 11/08/15 20:10, Sergey Popov wrote:
 Err, i have read the whole thread and still does not get a point, why i
 am wrong.

You clearly have not. The reasoning behind Qt team's policy is described
on the page and has been reiterated on this list. You are undermining
what little confidence there is in the QA team by making decisions with
no consultation about problems you do not understand.

 It's old battle like we have beforce with gtk meaning any versions of
 GTK flag. This behaviour should be killed with fire.
 
 Let's me reiterate some of the cases:
 
 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can
 be chosen, but not both.
 
 Fix this with REQUIRED_USE, do not enable any of Qt flags by default

Problem: this requires manual intervention if the user has both qt4 and
qt5 USE flags enabled.

 
 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is
 required, but not both
 
 Same thing here, different REQUIRED_USE operator. But - enable one of
 the flags by default to ease life of users.

Problem: this requires manual intervention if the user has both qt4 and
qt5 USE flags enabled.

 
 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
 package even exists?)
 
 Do not use REQUIRED_USE here, not needed.
 
 Now, please tell me, where am i wrong?
 

The problem is manual intervention is required if the user has both qt4
and qt5 USE flags enabled - and this is a common configuration. It is
not acceptable to make a user manually add numerous package.use entries
when all they want to do is install KDE.

I agree Qt's policy is not a perfect solution, but in the absence of
some feature allowing a preference to be set when there is a conflict
it's the best we've got.




[gentoo-dev] Re: useflag policies

2015-08-11 Thread Michael Palimaka
On 11/08/15 20:17, Sergey Popov wrote:
 09.08.2015 23:28, Ulrich Mueller пишет:
 I disagree with this. Really, REQUIRED_USE should be used sparingly,
 and IMHO the above is not a legitimate usage case for it.
 
 So, you prefer to make ugly mess of deps here like i posted before or
 introduce some really unneded USE-flag like 'gui', 'qt', etc. to make
 users even more confused?
 
 Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags.
 And dependency string like this:
 
 !berkdb? ( !gdbm? ( sys-libs/gdbm ) )
 
 One sentence: WHAT THE HELL?
 
 Imagine that it would be dozen of flags. Is it fun to mess with deps
 like this for you?

Shall we ban this too?

ffmpeg? (
libav? ( media-video/libav:= )
!libav? ( media-video/ffmpeg:0= )
)






Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Alexandre Rostovtsev
On Tue, 2015-08-11 at 16:04 +0300, Sergey Popov wrote:
 You want to migrate to such decision? Like:
 
 qt? (
qt5? ( dev-lang/qtcore:5 )
!qt5? ( dev-lang/qtcore:4 )
 )
 
 Fine by me, if you would ask.

That flag should be called gui. Not qt.

This would be the real solution to gnome team's gtk/gtk2/gtk3 flag
problem and to qt team's flag problem too.

signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread James Le Cuirot
On Tue, 11 Aug 2015 15:58:49 +0300
Sergey Popov pinkb...@gentoo.org wrote:

 If both of flags are not set - we stick to default.
 Should this be set in EVERY ebuild explicitly?
 
 Maybe provide some sugar like $(qt_use_default qtgui 5), where
 qt_use_default is the name of function, qtgui is the package and 5 is
 the slot for default choice, where either BOTH of flags(qt4, qt5) are
 enabled or disabled

That sounds a little bit like what I suggested earlier.

https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
11.08.2015 16:30, Michael Palimaka пишет:
 
 Don't forget that as a project with no special authority, Qt's policy
 remains a suggestion for the vast majority of maintainers. If someone
 wishes to provide support for only one Qt version or abuse their users
 with REQUIRED_USE they are still free to do so.
 

Not enforcing policies on main tree is a bad thing. If you make policy,
make other maintainers follow it. I am not against consistent policy
that ease life BOTH for developers and users.

You think that REQUIRED_USE is abusive to users: fine. Point accepted.
I think that provided DEPEND strings if they will be typed at every
single qt-related ebuild that needs them are abusive to developers.

So, maybe we should wrap them into eclass and stop riding our own
bicycles...

And then - use apropriate one-liner where it's needed, providing
reasonable default and NOT confusing users with overmanaging their
package.use

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

2015-08-11 Thread Rich Freeman
On Tue, Aug 11, 2015 at 8:26 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Tue, 11 Aug 2015 10:29:55 +0200
 Alexander Berntsen berna...@gentoo.org wrote:
 On 10/08/15 22:59, Aaron W. Swenson wrote:
  Users can fetch/pull from Github.
 Users should not have to interface with or rely on proprietary
 software to use Gentoo.

 Like the stuff running on the big expensive routers that make the
 internets work? Can I have my tree delivered by pigeon, since I suspect
 the post office runs Windows?

Only if that pigeon has had its personal genome sequenced.

BTW, did I mention that once we get all the dev gpg keys sorted out
we're going to need a cheek swab from everybody?

-- 
Rich



[gentoo-dev] Summary line (was: Re: Referencing bug reports in git)

2015-08-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 04:57 AM, Tobias Klausmann wrote:
 The more we stuff into the summary line, the harder it will be to 
 write meaningful summaries. And thus, people will write crappy ones
 or ignore the length limit. I recommend against any more 
 prescription over Add the the cat/pn if meaningful, don't use more
 than 75 characters.
 
 The cat/pn rule is tricky anyway: what if one commit touches 100 
 packages? Or should that be split into 100 commits for easier 
 partial rollback?
 
 Regards, Tobias
 


The summary line limit is going to be a real issue, tbh.  I think it
would probably be best to adopt the convention of putting a few
choice, perhaps even canned, phrases in the summary line, and ensure
any and all details (effectively what the summary line used to be for
when it had practically no limit) within the commit message body instead
.

Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn:
adjusted dependencies' are generic (and short) enough yet descriptive
enough to see what went on while scanning the log.  'Fix bug' IMO in
the summary doesn't work at all because, although its accurate, that
bug could literally be anything at all.

Multi-package commits are going to be more of an issue of course..  I
did one last night, fortunately I think I can get away with using
mozilla packages in place of cat/pn since it is a very specific set
of packages.  Perhaps for sweeping changes like that we can use the
herdname or projectname or the category name (if its a particular
category only)?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKBpIACgkQAJxUfCtlWe3pQgD8Ct1elGvDIObKKvskQJ1jCZIK
cYvuWdMD7pobr/hH6iIA/jnYirAb9CDe4iNlVPqG2AKYbj9NJdGnpoL/TFhJtj8U
=vnTb
-END PGP SIGNATURE-



Re: [gentoo-dev] Summary line (was: Re: Referencing bug reports in git)

2015-08-11 Thread Kent Fredric
On 12 August 2015 at 02:28, Ian Stakenvicius a...@gentoo.org wrote:
 Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn:
 adjusted dependencies' are generic (and short) enough yet descriptive
 enough to see what went on while scanning the log.

I personally find those summaries a bit too terse.

Mostly, because when I see A version is bumped I immediately expect
to know which version the bump is to, but have to dig out the diff to
find out.

I would also prefer, where possible, to replace adjusted
dependencies to be more concise, like include dev-perl/Foo in
dependencies, ( though of course, apply some taste, listing more than
3 distinct new dependencies in the summary is execessive, treat them
like hashtags on twitter, 1 is good, 2 is OK, 3 and you're starting to
get crazy )

 Multi-package commits are going to be more of an issue of course..  I
 did one last night, fortunately I think I can get away with using
 mozilla packages in place of cat/pn since it is a very specific set
 of packages.  Perhaps for sweeping changes like that we can use the
 herdname or projectname or the category name (if its a particular
 category only)?

Agreed. If you need multi-package changes and you can't think of a
good category prefix to use, the commit message should visibly
acknowledge that its a multi-package commit of some kind, and the
*kind* of change should be very clear.

Just keep in mind really the recommendations for prefix naming are
descriptive, not prescriptive, and interpretation and good taste need
to be applied everywhere.



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 10:01 AM, Michał Górny wrote:
 Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement
 monsie...@gentoo.org napisał(a):
 
 Hi there
 
 According to
 https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,

 
there may be developer-specific, task-specific, project-specific branch
es
 etc. As far as I understand, it means I can go and create my own
 branch on the main repository and push it and it gets spread all
 over the place. Is that correct?
 
 Could someone explain to me the rationale behind this decision?
 
 Truth to be told, I kinda dislike the fact any developer can do
 this.
 
 As long as it's used with caution, I don't see a problem. Of course
 it would be bad if everyone pushed branches for any minor change.
 However, if there is a long-term work going on a branch, I don't
 see a problem with keeping it public.
 

Examples in particular I can think of for something like this being
useful would be for, say, major EAPI-bump-related feature
implementations (ie, EAPI5 and slot-operators/subslots), or major
across-tree impementation changes like what we saw with the
multilib-eclass porting.

These are large projects touching most if not all ebuilds, that a
great many developers would or should be involved in.  Something like
this could be done in a separately hosted repo instead of in the main
gentoo repo, but then all developers would need to subscribe to this
other repo, while having it in a branch in the main one i think would
make it easier for everyone to get involved once they're ready, and
would still allow the changes to stay out of the master branch until
the project is ready to launch.






-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKEK8ACgkQAJxUfCtlWe35RwEAi2VkkJkCWXCh6tJhEKDbfmzY
fP3rh20RURm84+8K2ysA/2u3dcTukXlGcLHW2xRSR/bjx5be1X+IL8A48bsqgujr
=uppX
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 10:19 AM, Rich Freeman wrote:
 On Tue, Aug 11, 2015 at 9:42 AM, Sergey Popov pinkb...@gentoo.org
 wrote:
 11.08.2015 16:36, Rich Freeman пишет:
 On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov
 pinkb...@gentoo.org wrote:
 11.08.2015 16:11, James Le Cuirot пишет:
 On Tue, 11 Aug 2015 15:58:49 +0300 Sergey Popov
 pinkb...@gentoo.org wrote:
 
 If both of flags are not set - we stick to default. 
 Should this be set in EVERY ebuild explicitly?
 
 Maybe provide some sugar like $(qt_use_default qtgui 5),
 where qt_use_default is the name of function, qtgui is
 the package and 5 is the slot for default choice, where
 either BOTH of flags(qt4, qt5) are enabled or disabled
 
 That sounds a little bit like what I suggested earlier.
 
 https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d
629b1dc9b30df



 
But without introducing brand new useless USE flag. Which makes huge
 difference to me :-)
 
 
 If we want the typical user to not set either qt4 or qt5, are
 we saying that any package that could use either always enable
 one of them by default?  Then all users get a GUI by default,
 and then users have to explicitly disable it?  That seems to be
 the opposite of how we normally do things, but it does let you
 get away from having lots of users turning on qt.
 
 I suggested this for packages, where GUI can not be disabled AND
 it should be either qt4 or qt5. Then, if we do not add + to USE 
 description, users without anything in make.conf just run the
 blocker
 
 
 What if the GUI can be disabled?  Should we force users to set 
 USE=-qt4 -qt5 to disable the GUI?  Or should we force users to
 put one of those in their make.conf or profile to enable it
 (causing problems with packages that don't allow both)?
 

I think the idea with USE=gui is that the generic profiles then no
longer need any qt4/qt5/gtk3/whatever flags in them at all, and the
ebuilds themselves can set a single default-enable on the particular
flag that should be used by default, thus allowing REQUIRED_USE to be
satisfied by default when an end-user doesn't care.

However, I agree that USE=gui still has the problem where the
sub-flags have active state in VDB, meaning that any change to the
sub-flags will trigger rebuilds on -N even if USE=-gui.  And since
(if i understand this thread correctly) part of the reason for doing
all of this is to ensure VDB is as accurate as possible to what the
package actually uses/needs/depends on/etc, we end up not having
solved anything.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKEmUACgkQAJxUfCtlWe3fowEA6Sx5CtDme6K2h5Yu0yYrfUnb
2ZunvwQFlv4QAD+fQ1wA/3aX/kfviD+FttzxHgWBH3uGg1SX8DHNCFptfv9y2lJe
=6i3x
-END PGP SIGNATURE-



[gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Patrice Clement
Hi there

According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
there may be developer-specific, task-specific, project-specific branches
etc. As far as I understand, it means I can go and create my own branch on the
main repository and push it and it gets spread all over the place. Is that
correct?

Could someone explain to me the rationale behind this decision?

Truth to be told, I kinda dislike the fact any developer can do this. 

proj/gentoo should be kept for serious business i.e. commits that affects the
tree. On the long run, if everybody goes down that road, we will see flourish
numerous branches (who said unmaintained?), all stalled at a different state of
the main repo, and it will only generate a lot of noise and confusion for
nothing. Further, since we've moved over to git, the main tree now gets
replicated to github and we all have github accounts here, don't we? Which makes
the whole forking and submitting PRs a cinch.

If a developer wants to tinker with the tree, he can fork it to its github
devspace, fiddle around, and later on send us a PR back with his changes to
merge.

Cheers,
Patrice




Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Michał Górny
Dnia 2015-08-11, o godz. 15:52:16
Patrice Clement monsie...@gentoo.org napisał(a):

 Hi there
 
 According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
 there may be developer-specific, task-specific, project-specific branches
 etc. As far as I understand, it means I can go and create my own branch on 
 the
 main repository and push it and it gets spread all over the place. Is that
 correct?
 
 Could someone explain to me the rationale behind this decision?
 
 Truth to be told, I kinda dislike the fact any developer can do this. 

As long as it's used with caution, I don't see a problem. Of course it
would be bad if everyone pushed branches for any minor change. However,
if there is a long-term work going on a branch, I don't see a problem
with keeping it public.

-- 
Best regards,
Michał Górny
http://dev.gentoo.org/~mgorny/


pgpEZol2EBxlc.pgp
Description: OpenPGP digital signature


[gentoo-dev] Re: useflag policies

2015-08-11 Thread Michael Palimaka
On 11/08/15 23:04, Sergey Popov wrote:
 11.08.2015 15:32, Michael Palimaka пишет:
 On 11/08/15 20:17, Sergey Popov wrote:
 09.08.2015 23:28, Ulrich Mueller пишет:
 I disagree with this. Really, REQUIRED_USE should be used sparingly,
 and IMHO the above is not a legitimate usage case for it.

 So, you prefer to make ugly mess of deps here like i posted before or
 introduce some really unneded USE-flag like 'gui', 'qt', etc. to make
 users even more confused?

 Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags.
 And dependency string like this:

 !berkdb? ( !gdbm? ( sys-libs/gdbm ) )

 One sentence: WHAT THE HELL?

 Imagine that it would be dozen of flags. Is it fun to mess with deps
 like this for you?

 Shall we ban this too?

 ffmpeg? (
 libav? ( media-video/libav:= )
 !libav? ( media-video/ffmpeg:0= )
 )




 
 No, because ffmpeg here is a feature AND name of concrete realization.
 Not ideal case as i would said, but it is acceptable.
 
 You want to migrate to such decision? Like:
 
 qt? (
   qt5? ( dev-lang/qtcore:5 )
   !qt5? ( dev-lang/qtcore:4 )
 )
 
 Fine by me, if you would ask.

This looks fine to me - I have no particular solution preference. I
understand there's been objection to generic GUI USE flags in the past
though.

 
 As i said one message earlier: Something like $(qt_use_default qtgui 5)
 
 which will generate something like this:
 
 qt4? (
   qt5? ( dev-lang/qtcore:5 )
   !qt5? ( dev-lang/qtcore:4 )
 )
 !qt5? ( !qt4? ( dev-lang/qtcore:5 ) )
 
 would help too.
 
 If you are doing complicated things(and please, do not tell me that
 provided dependency string is simple and understandable by every
 developer in just a second without wanting to improve or simplify

I disagree but we're getting offtopic. The thread was raised regarding
support of packages that at-most-one-of qt4 or qt5.

Ben is of course right that for these packages, USE=qt4 qt5
automagically selecting qt5 is not the clearest result and has the
potential for confusion. I feel that usability benefit of this choice
outweighs the negatives. This leaves only a few options:

1. Leave the policy recommendation as-is (letting maintainers adopt or
ignore it as they see fit)

2. Veto the policy recommendation and force something different
(maintainers who disagree will likely either drop support for multiple
qt versions or stop maintaining the package completely)

3. Create a whole new solution like USE=gui (what happens if I have
multiple gui implementation USE flags set?)




[gentoo-dev] [PATCH repositories.dtd] Support multiple owner/ elements

2015-08-11 Thread Michał Górny
Hello,

A quick patch for review. It changes the DTD for repositories.xml to
support multiple owner/ tags. We have at least one repository with
more than one owner, and I don't really see creating aliases for our
users just to support that. Any comments?


Index: repositories.dtd
===
RCS file: /var/cvsroot/gentoo/xml/htdocs/dtd/repositories.dtd,v
retrieving revision 1.1
diff -u -B -r1.1 repositories.dtd
--- repositories.dtd12 Oct 2009 19:06:08 -  1.1
+++ repositories.dtd11 Aug 2015 14:14:28 -
@@ -21,7 +21,7 @@
   xmlns CDATA #FIXED ''
   version CDATA #FIXED '1.0'
 
-!ELEMENT repo 
(name,(description)+,(longdescription)*,(homepage)?,owner,(source)+,(feed)*)
+!ELEMENT repo 
(name,(description)+,(longdescription)*,(homepage)?,(owner)+,(source)+,(feed)*)
 !ATTLIST repo
   xmlns CDATA #FIXED ''
   priority CDATA #IMPLIED


-- 
Best regards,
Michał Górny
http://dev.gentoo.org/~mgorny/


pgpFJdIhtwaNP.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Alexandre Rostovtsev
On Wed, 2015-08-12 at 00:02 +1000, Michael Palimaka wrote:
 3. Create a whole new solution like USE=gui (what happens if I have
 multiple gui implementation USE flags set?)

This is what I would suggest. It would remove 90% of the problem since
most applications use only one gui toolkit.

If no toolkit USE flags are set, go with the best (most stable, best
supported) toolkit.

If multiple flags are set - here you have a choice. The user-friendly
approach is to add some logic to find the best toolkit out of the
ones for which a flag is set (this gets complicated in the theoretical
case of three toolkits).

However, the user-friendly approach is completely unworkable when there
are reverse dependencies on your package (plugins for example) that
require a specific toolkit.

So a better choice might be REQUIRED_USE, *but* then you must adjust
package.use in all profiles to allow your package to be emerged without
forcing a user to manually set/unset flags.

signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Rich Freeman
On Tue, Aug 11, 2015 at 9:42 AM, Sergey Popov pinkb...@gentoo.org wrote:
 11.08.2015 16:36, Rich Freeman пишет:
 On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov pinkb...@gentoo.org wrote:
 11.08.2015 16:11, James Le Cuirot пишет:
 On Tue, 11 Aug 2015 15:58:49 +0300
 Sergey Popov pinkb...@gentoo.org wrote:

 If both of flags are not set - we stick to default.
 Should this be set in EVERY ebuild explicitly?

 Maybe provide some sugar like $(qt_use_default qtgui 5), where
 qt_use_default is the name of function, qtgui is the package and 5 is
 the slot for default choice, where either BOTH of flags(qt4, qt5) are
 enabled or disabled

 That sounds a little bit like what I suggested earlier.

 https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df


 But without introducing brand new useless USE flag. Which makes huge
 difference to me :-)


 If we want the typical user to not set either qt4 or qt5, are we
 saying that any package that could use either always enable one of
 them by default?  Then all users get a GUI by default, and then users
 have to explicitly disable it?  That seems to be the opposite of how
 we normally do things, but it does let you get away from having lots
 of users turning on qt.

 I suggested this for packages, where GUI can not be disabled AND it
 should be either qt4 or qt5. Then, if we do not add + to USE
 description, users without anything in make.conf just run the blocker


What if the GUI can be disabled?  Should we force users to set
USE=-qt4 -qt5 to disable the GUI?  Or should we force users to put
one of those in their make.conf or profile to enable it (causing
problems with packages that don't allow both)?

-- 
Rich



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Anthony G. Basile

On 8/11/15 10:19 AM, hasufell wrote:

On 08/11/2015 04:10 PM, Alexis Ballier wrote:

On Tue, 11 Aug 2015 16:01:05 +0200
Michał Górny mgo...@gentoo.org wrote:


Dnia 2015-08-11, o godz. 15:52:16
Patrice Clement monsie...@gentoo.org napisał(a):


Hi there

According to
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
there may be developer-specific, task-specific, project-specific
branches etc. As far as I understand, it means I can go and create
my own branch on the main repository and push it and it gets spread
all over the place. Is that correct?

Could someone explain to me the rationale behind this decision?

Truth to be told, I kinda dislike the fact any developer can do
this.

As long as it's used with caution, I don't see a problem.

Then we should define 'caution' I think :)


I would not say caution so much as good judgment.  The first example 
that came to mind was working with the profiles which crosses many 
directories and files.  In the past when I did restructuring to the 
hardened profiles, I tested by using a branch of the hardened-dev 
overlay.  It was annoying and I would do a bind mount over 
/usr/portage/profiles and had to rebase manually.  A test branch of the 
the main tree which could get rebased and eventually merged back would 
make the workflow so much better.  Another example was when we 
revitalized the selinux policies.  There were hundreds of commits to be 
done.  A branch here that got merged back would be ideal.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA




Re: [gentoo-dev] Summary line

2015-08-11 Thread Mikle Kolyada


11.08.2015 17:36, hasufell пишет:
 On 08/11/2015 04:28 PM, Ian Stakenvicius wrote:
 On 11/08/15 04:57 AM, Tobias Klausmann wrote:
 The more we stuff into the summary line, the harder it will be to 
 write meaningful summaries. And thus, people will write crappy ones
 or ignore the length limit. I recommend against any more 
 prescription over Add the the cat/pn if meaningful, don't use more
 than 75 characters.
 The cat/pn rule is tricky anyway: what if one commit touches 100 
 packages? Or should that be split into 100 commits for easier 
 partial rollback?
 Regards, Tobias


 The summary line limit is going to be a real issue, tbh.  I think it
 would probably be best to adopt the convention of putting a few
 choice, perhaps even canned, phrases in the summary line, and ensure
 any and all details (effectively what the summary line used to be for
 when it had practically no limit) within the commit message body instead
 .

 Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn:
 adjusted dependencies' are generic (and short) enough yet descriptive
 enough to see what went on while scanning the log.  'Fix bug' IMO in
 the summary doesn't work at all because, although its accurate, that
 bug could literally be anything at all.

 Multi-package commits are going to be more of an issue of course..  I
 did one last night, fortunately I think I can get away with using
 mozilla packages in place of cat/pn since it is a very specific set
 of packages.  Perhaps for sweeping changes like that we can use the
 herdname or projectname or the category name (if its a particular
 category only)?



 The CATEGORY: prefix is already in the wiki. Interesting idea about
 projectname/herdname prefix.

 I've already seen someone (I think ulm) prefixing with [QA].

 I don't feel strong about this. IMO, if there is no useful prefix...
 just don't use any. The lack of prefix will make it obvious that this is
 a larger change. But project/herd specific prefixes could still make sense.

Mgorny has commited a fix to live portage

https://github.com/gentoo/portage/commit/46dafadff58da0220511f20480b73ad09f913430

I think it will be in the tree soon.



[gentoo-dev] Re: useflag policies

2015-08-11 Thread Michael Palimaka
On 12/08/15 00:29, Rich Freeman wrote:
 On Tue, Aug 11, 2015 at 9:39 AM, Sergey Popov pinkb...@gentoo.org wrote:
 11.08.2015 16:30, Michael Palimaka пишет:

 Don't forget that as a project with no special authority, Qt's policy
 remains a suggestion for the vast majority of maintainers. If someone
 wishes to provide support for only one Qt version or abuse their users
 with REQUIRED_USE they are still free to do so.


 Not enforcing policies on main tree is a bad thing. If you make policy,
 make other maintainers follow it. I am not against consistent policy
 that ease life BOTH for developers and users.
 
 ++
 
 I think the qt team taking the lead on this makes sense, but this is
 the sort of thing that just makes sense as a treewide policy.  If
 people don't like their suggested policy they can take it to
 QA/council/whatever, but it makes more sense to have projects setting
 standards than having everybody doing their own thing.
 
 I realize this is frustrating and contentious, but I think we're
 better off hashing this out, and implementing something reasonable,
 than having a bazillion different conventions that users have to deal
 with.  Usually I prefer maintainer autonomy, but this is just one of
 those times it doesn't make sense.
 

Isn't this moving towards a situation that we used GLEP 39 to remove?




Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

2015-08-11 Thread Anthony G. Basile

On 8/11/15 10:33 AM, Ian Stakenvicius wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 06:11 AM, Leno Hou wrote:

I think ppc64le would become popular,
https://en.wikipedia.org/wiki/Ppc64.

1. enable porting x86 Linux based application with minimal effort.
  2. Some PowerPC user, little endian apparently feels cheap, wrong,
and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE
already support little endian in powerpc.



In terms of the codepaths, what's different between ppc64le vs ppc64,
and ppc64le vs amd64 ?  Obviously kernels will differ, but in terms of
C/C++/other compiled source code what needs to change?

If all this needs is its own profile for a CHOST/CBUILD specification
and it can leverage an existing keyword, then this should be rather
simple to implement yes?


We would leverage this on ppc64 keyword.  It is a bit dangerous to claim 
that a pkg stable on ppc64 is stable on ppc64le, but we would live with 
that risk.  Ideally you should test on both.  The situation is analogous 
to mips where there are many different ISAs and both be and le.  It is 
one of the reasons mips is hard to move back into stable.  But having 
stable keywords is really nice when it comes to building and maintaining 
stages and keeping base pkgs versions in sync with the other arches.  
For this reason, I would even been in favor of restoring stable mips 
with the understanding that stable carries something of a risk when 
crossing the be/le boundry, or the mips I vs mips III, or 32 vs 64, etc.


Having said that, what would break?  Assembly and other code that makes 
assumption about byte order.   There is some out there, but not much.  
We'll deal with it when we hit it.  Any of the heavy duty stuff, like 
syscall interfaces or setjmp/longjmp etc, should be relegated to the 
libc and kernel.






-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKB7UACgkQAJxUfCtlWe1sbQD+KcbYpfo56GrLIVlFyw2iXbMB
ZOWzuvyI8SVq/DY0SQMBAJgDIjCza8QyUgWEtq2/g5Yu+uWiCibf2ouMeNAOkQ33
=YoUg
-END PGP SIGNATURE-




--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA




Re: [gentoo-dev] Re: rsync mirror security

2015-08-11 Thread Matthias Maier

 constantly adds any security to the tree.  What might add security for
 end-users is if git automatically checked the push signatures, which
 are the signatures that ensure that branches aren't tampered with
 (which is what rebasing you bring up actually does).

It is news to me that a signature from a push is also transported to a
subsequent pull request for a client, do you have some external
references for this procedure?

Regardless of the technical implementation, the fact still remains that
with the current git repositories (gentoo and the one populated with
metadata from gentoo-mirror) we might have another way of providing
a signed and tamper-proof [1] ebuild tree (apart from our daily, signed
snapshots).

Best,
Matthias

[1] At least as long our git infrastructure is not compromised...


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Sergey Popov
11.08.2015 16:36, Rich Freeman пишет:
 On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov pinkb...@gentoo.org wrote:
 11.08.2015 16:11, James Le Cuirot пишет:
 On Tue, 11 Aug 2015 15:58:49 +0300
 Sergey Popov pinkb...@gentoo.org wrote:

 If both of flags are not set - we stick to default.
 Should this be set in EVERY ebuild explicitly?

 Maybe provide some sugar like $(qt_use_default qtgui 5), where
 qt_use_default is the name of function, qtgui is the package and 5 is
 the slot for default choice, where either BOTH of flags(qt4, qt5) are
 enabled or disabled

 That sounds a little bit like what I suggested earlier.

 https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df


 But without introducing brand new useless USE flag. Which makes huge
 difference to me :-)

 
 If we want the typical user to not set either qt4 or qt5, are we
 saying that any package that could use either always enable one of
 them by default?  Then all users get a GUI by default, and then users
 have to explicitly disable it?  That seems to be the opposite of how
 we normally do things, but it does let you get away from having lots
 of users turning on qt.

I suggested this for packages, where GUI can not be disabled AND it
should be either qt4 or qt5. Then, if we do not add + to USE
description, users without anything in make.conf just run the blocker


-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Quality Assurance project lead
Gentoo Proxy maintainers project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Tobias Klausmann
Hi! 

On Tue, 11 Aug 2015, Michał Górny wrote:
 Dnia 2015-08-11, o godz. 15:52:16
 Patrice Clement monsie...@gentoo.org napisał(a):
 
  According to 
  https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
  there may be developer-specific, task-specific, project-specific branches
  etc. As far as I understand, it means I can go and create my own branch on 
  the
  main repository and push it and it gets spread all over the place. Is that
  correct?
  
  Could someone explain to me the rationale behind this decision?
  
  Truth to be told, I kinda dislike the fact any developer can do this. 
 
 As long as it's used with caution, I don't see a problem. Of course it
 would be bad if everyone pushed branches for any minor change. However,
 if there is a long-term work going on a branch, I don't see a problem
 with keeping it public.

I agree with monsierp here, person-level stuff should not be in
the official repo.

Also note that not in the main repo does not mean non-public.
People (and projects) can always publish their version of the
tree somewhere else.

I personally even dislike the project branches, but those I am
more willing to accept.

Regards,
Tobias

PS: Call me a pessimist, but every time I see if it's used with
caution, I think: yeah, but it won't.

-- 
Sent from aboard the Culture ship
Fine Till You Came Along



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Alexis Ballier
On Tue, 11 Aug 2015 16:01:05 +0200
Michał Górny mgo...@gentoo.org wrote:

 Dnia 2015-08-11, o godz. 15:52:16
 Patrice Clement monsie...@gentoo.org napisał(a):
 
  Hi there
  
  According to
  https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
  there may be developer-specific, task-specific, project-specific
  branches etc. As far as I understand, it means I can go and create
  my own branch on the main repository and push it and it gets spread
  all over the place. Is that correct?
  
  Could someone explain to me the rationale behind this decision?
  
  Truth to be told, I kinda dislike the fact any developer can do
  this. 
 
 As long as it's used with caution, I don't see a problem.

Then we should define 'caution' I think :)

 Of course it
 would be bad if everyone pushed branches for any minor change.
 However, if there is a long-term work going on a branch, I don't see
 a problem with keeping it public.

Most, if not all, projects I've seen use forks for this. This doesn't
prevent being public but gives a clear definition of what 'caution' is.
Branches are usually reserved for releases maintainance.

Alexis.



Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

2015-08-11 Thread Ultrabug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/2015 16:32, Michał Górny wrote:
 Hello, everyone.
 
 Now that we're officially on git and can officially use pull
 requests to provide rapid community interaction, it'd be convenient
 to have a little better framework for pinging package maintainers.
 
 With the unofficial mirror/pull request project, I was either
 looking for project member GitHub accounts and pinging found
 project members by name, or talking to them directly on IRC.
 However, with the growth in number of pull requests this will
 become more and more inconvenient. Therefore, I think it's time to
 be able to mirror teams willing to work with GitHub community there
 for easier 'pings'.
 

I like the idea, sounds very handy

 I have two ideas right now:
 
 1. creating GitHub Gentoo project teams corresponding to willing
 Gentoo teams,
 
 2. preparing lists of GitHub usernames on project wiki pages.
 
 Solution 1. is cleaner. In this case, we create GitHub teams under 
 the Gentoo projects, and add appropriate Gentoo developers having 
 GitHub accounts to the teams. Then, in PRs we can just ping the
 whole team like @Gentoo/Qt or like.
 

+1 imho, clean  simple, only team and ppl willing to participate can
get there

 Solution 2. avoids adding any GitHub teams. In this case, in team
 wiki page we collect team member usernames like @Pesa,
 @kensington, ... so we could copy-paste it to pull requests. We
 still require extra effort when 'assigning' PRs but at least I
 don't have to lookup the same people over and over again.
 
 With some Wiki people help, we could even implement updating
 GitHub teams automatically following Wiki member changes.
 
 Your thoughts?
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKCqsACgkQKiQSS7ZY+hNd9AD9FBXc16nF9sp2Xk1gBpXsduGt
a2+f1tHSMN9ChSrCBM4A/Ao1nCfMNBEaI9WYBUOQ0Cti5hkjM9X66sMlnszsBahP
=GS6Q
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 08:58 AM, Sergey Popov wrote:
 11.08.2015 15:30, Michael Palimaka пишет:
 On 11/08/15 20:10, Sergey Popov wrote:
 Err, i have read the whole thread and still does not get a
 point, why i am wrong.
 
 You clearly have not. The reasoning behind Qt team's policy is
 described on the page and has been reiterated on this list. You
 are undermining what little confidence there is in the QA team by
 making decisions with no consultation about problems you do not
 understand.
 
 It's old battle like we have beforce with gtk meaning any
 versions of GTK flag. This behaviour should be killed with
 fire.
 
 Let's me reiterate some of the cases:
 
 1. Package can be build without Qt GUI at all, but either Qt4
 or Qt5 can be chosen, but not both.
 
 Fix this with REQUIRED_USE, do not enable any of Qt flags by
 default
 
 Problem: this requires manual intervention if the user has both
 qt4 and qt5 USE flags enabled.
 
 
 User choice of using USE flags is NOT a problem
 
 
 2. Package can not be build without Qt GUI - either Qt4 or Qt5
 is required, but not both
 
 Same thing here, different REQUIRED_USE operator. But - enable
 one of the flags by default to ease life of users.
 
 Problem: this requires manual intervention if the user has both
 qt4 and qt5 USE flags enabled.
 
 Same here
 
 
 3. Package can be build with Qt4 or Qt5 or both AT THE SAME
 TIME(if such package even exists?)
 
 Do not use REQUIRED_USE here, not needed.
 
 Now, please tell me, where am i wrong?
 
 
 The problem is manual intervention is required if the user has
 both qt4 and qt5 USE flags enabled - and this is a common
 configuration. It is not acceptable to make a user manually add
 numerous package.use entries when all they want to do is install
 KDE.
 
 And here
 
 I agree Qt's policy is not a perfect solution, but in the absence
 of some feature allowing a preference to be set when there is a
 conflict it's the best we've got.
 
 
 If you want to go this way, then please provide helper functions
 in eclasses to set dependencies properly for all common use cases.
 That will ease life both of developers and users.
 

Why do you need this?

#1, if you really want RDEPEND to only include the deps the package
will actually use, then you do this:

old:

qt5? ( list of qt5 atoms )
qt4? ( list of qt4 atoms )

..to new:

qt5? ( list of qt5 atoms )
!qt5? (
  qt4? ( list of qt4 atoms )
)


BUT I would advise against this.  If a user has specified both qt4 and
qt5 in USE, then I see no problem with the VDB having both qt4 and qt5
atoms listed as dependencies.  End-users that want a clean VDB can
just make sure they only enable one flag, but end-users that don't
care will have packages that just work.


 Leaving constructing of dependencies to developers in all cases
 will cause only pain in your solution.

It really wont, see above.  At minimum, it's barely any more work than
it is with a REQUIRED_USE based solution.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKDTkACgkQAJxUfCtlWe09QAD/ST47V7i08k09c8o+dgMx8hQP
cRyBiTzxHKKtQ3aqmKIBAIdjBB4rGZLLMjiu9l0KfUOkOT1J+Z8oHPWQhzDPJpqv
=LCgR
-END PGP SIGNATURE-



[gentoo-dev] Re: useflag policies

2015-08-11 Thread Michael Palimaka
On 11/08/15 22:58, Sergey Popov wrote:
 11.08.2015 15:30, Michael Palimaka пишет:
 On 11/08/15 20:10, Sergey Popov wrote:
 Err, i have read the whole thread and still does not get a point, why i
 am wrong.

 You clearly have not. The reasoning behind Qt team's policy is described
 on the page and has been reiterated on this list. You are undermining
 what little confidence there is in the QA team by making decisions with
 no consultation about problems you do not understand.

 It's old battle like we have beforce with gtk meaning any versions of
 GTK flag. This behaviour should be killed with fire.

 Let's me reiterate some of the cases:

 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can
 be chosen, but not both.

 Fix this with REQUIRED_USE, do not enable any of Qt flags by default

 Problem: this requires manual intervention if the user has both qt4 and
 qt5 USE flags enabled.

 
 User choice of using USE flags is NOT a problem

I invite you to reproduce the problem yourself then make the judgement.
Using REQUIRED_USE like this makes the affected packages unusable.


 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is
 required, but not both

 Same thing here, different REQUIRED_USE operator. But - enable one of
 the flags by default to ease life of users.

 Problem: this requires manual intervention if the user has both qt4 and
 qt5 USE flags enabled.
 
 Same here
 

 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
 package even exists?)

 Do not use REQUIRED_USE here, not needed.

 Now, please tell me, where am i wrong?


 The problem is manual intervention is required if the user has both qt4
 and qt5 USE flags enabled - and this is a common configuration. It is
 not acceptable to make a user manually add numerous package.use entries
 when all they want to do is install KDE.
 
 And here
 
 I agree Qt's policy is not a perfect solution, but in the absence of
 some feature allowing a preference to be set when there is a conflict
 it's the best we've got.

 
 If you want to go this way, then please provide helper functions in
 eclasses to set dependencies properly for all common use cases. That
 will ease life both of developers and users.
 
 Leaving constructing of dependencies to developers in all cases will
 cause only pain in your solution.
 
 Look at the example with berkdb/gdbm, that i have posted recently.
 
 If both of flags are not set - we stick to default.
 Should this be set in EVERY ebuild explicitly?
 
 Maybe provide some sugar like $(qt_use_default qtgui 5), where
 qt_use_default is the name of function, qtgui is the package and 5 is
 the slot for default choice, where either BOTH of flags(qt4, qt5) are
 enabled or disabled

How does this solve the REQUIRED_USE problem? Or is your only objection
is that resulting dependency string is too hard?

Don't forget that as a project with no special authority, Qt's policy
remains a suggestion for the vast majority of maintainers. If someone
wishes to provide support for only one Qt version or abuse their users
with REQUIRED_USE they are still free to do so.




Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread William Hubbs
On Tue, Aug 11, 2015 at 04:12:29PM +0200, hasufell wrote:
 On 08/11/2015 03:52 PM, Patrice Clement wrote:
  Hi there
  
  According to 
  https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
  there may be developer-specific, task-specific, project-specific branches
  etc. As far as I understand, it means I can go and create my own branch on 
  the
  main repository and push it and it gets spread all over the place. Is that
  correct?
  
  Could someone explain to me the rationale behind this decision?
  
  Truth to be told, I kinda dislike the fact any developer can do this. 
  
  proj/gentoo should be kept for serious business i.e. commits that affects 
  the
  tree. On the long run, if everybody goes down that road, we will see 
  flourish
  numerous branches (who said unmaintained?), all stalled at a different 
  state of
  the main repo, and it will only generate a lot of noise and confusion for
  nothing. Further, since we've moved over to git, the main tree now gets
  replicated to github and we all have github accounts here, don't we? Which 
  makes
  the whole forking and submitting PRs a cinch.
  
  If a developer wants to tinker with the tree, he can fork it to its github
  devspace, fiddle around, and later on send us a PR back with his changes to
  merge.
  
 
 Branches can still make sense, even if the model is that everyone has
 his own fork, see
 http://nvie.com/posts/a-successful-git-branching-model/
 for an example.
 
 I currently don't see a reason to limit the workflow to one master branch.
 
 It doesn't necessarily generate noise or confusion and there are various
 ways to only fetch specific branches if you really need to do so. Git's
 main advantage _are_ branches and it has sufficient methods to deal with
 a lot of them.
 
 If they cause trouble, we can still prune them and enforce stricter
 rules, but since we don't even know how they will be used, this point is
 moot yet.
 
 I'm with mgorny and hasufell on this; I'm not worried about regulating
 branches that much.

Also, since we have our own tree on g.g.o, the tree on github is a
mirror, so we should treat it as such, e.g. it could go down at any
point, and if it does, we can keep working based on our official tree.

There's even a way in git itself to do something like a github pull
request (see the git request-pull command), so we don't need to rely on
github for that.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

2015-08-11 Thread James Le Cuirot
On Tue, 11 Aug 2015 10:33:26 -0400
Ian Stakenvicius a...@gentoo.org wrote:

 On 11/08/15 06:11 AM, Leno Hou wrote:
  I think ppc64le would become popular,
  https://en.wikipedia.org/wiki/Ppc64.
  
  1. enable porting x86 Linux based application with minimal effort.
   2. Some PowerPC user, little endian apparently feels cheap, wrong,
  and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE
  already support little endian in powerpc.
  

 
 In terms of the codepaths, what's different between ppc64le vs ppc64,
 and ppc64le vs amd64 ?  Obviously kernels will differ, but in terms of
 C/C++/other compiled source code what needs to change?
 
 If all this needs is its own profile for a CHOST/CBUILD specification
 and it can leverage an existing keyword, then this should be rather
 simple to implement yes?

I spoke to blueness in #gentoo-powerpc and he basically said the same
thing, that the existing ppc64 keyword should suffice. He noted that
we do not have different keywords for every mips variant because that
would be a lot of keywords! Stage 3 tarballs (possibly cross-compiled)
could be provided and some initial work could be done to ensure they
actually function but beyond that, endian issues would simply be dealt
with as they are reported.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 09:04 AM, Sergey Popov wrote:
 11.08.2015 15:32, Michael Palimaka пишет:
 On 11/08/15 20:17, Sergey Popov wrote:
 09.08.2015 23:28, Ulrich Mueller пишет:
 I disagree with this. Really, REQUIRED_USE should be used
 sparingly, and IMHO the above is not a legitimate usage case
 for it.
 
 So, you prefer to make ugly mess of deps here like i posted
 before or introduce some really unneded USE-flag like 'gui',
 'qt', etc. to make users even more confused?
 
 Really, look at man-db ebuild. Especially on berkdb and gdbm
 USE flags. And dependency string like this:
 
 !berkdb? ( !gdbm? ( sys-libs/gdbm ) )
 
 One sentence: WHAT THE HELL?
 
 Imagine that it would be dozen of flags. Is it fun to mess with
 deps like this for you?
 
 Shall we ban this too?
 
 ffmpeg? ( libav? ( media-video/libav:= ) !libav? (
 media-video/ffmpeg:0= ) )
 
 
 
 
 
 No, because ffmpeg here is a feature AND name of concrete
 realization. Not ideal case as i would said, but it is acceptable.
 
 You want to migrate to such decision? Like:
 
 qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) )
 
 Fine by me, if you would ask.
 
 As i said one message earlier: Something like $(qt_use_default
 qtgui 5)
 
 which will generate something like this:
 
 qt4? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) 
 !qt5? ( !qt4? ( dev-lang/qtcore:5 ) )
 
 would help too.

Woah -- why would qt5 be a dep when both flags are off?  If you have a
package that -needs- one version enabled, then in that case I do fully
support REQUIRED_USE=|| ( qt4 qt5 ).  '||' being the one-or-more-of
operator.

The other alternative here would be that there is no qt5 flag, just a
qt4 one, and the qt4 one toggles qt5 off and qt4 on.  And that just
isn't pretty, so let's not do that.

And using this form of REQUIRED_USE I believe (if I understand what
QA's and QT's stances are on this) is not in conflict with either
group, right?



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKDosACgkQAJxUfCtlWe2Z8QD/Z+NvyJ0VXoIQH/KRPy8Asete
iXZTpA1QgLDh4xYJE9YBAOTV61mJP472jBu/kEmJOK9cZPFW9PfJ15I0IvoBWdNF
=1oaz
-END PGP SIGNATURE-



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Alexis Ballier
On Tue, 11 Aug 2015 16:19:12 +0200
hasufell hasuf...@gentoo.org wrote:

 On 08/11/2015 04:10 PM, Alexis Ballier wrote:
  On Tue, 11 Aug 2015 16:01:05 +0200
  Michał Górny mgo...@gentoo.org wrote:
  
  Dnia 2015-08-11, o godz. 15:52:16
  Patrice Clement monsie...@gentoo.org napisał(a):
 
  Hi there
 
  According to
  https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
  there may be developer-specific, task-specific, project-specific
  branches etc. As far as I understand, it means I can go and
  create my own branch on the main repository and push it and it
  gets spread all over the place. Is that correct?
 
  Could someone explain to me the rationale behind this decision?
 
  Truth to be told, I kinda dislike the fact any developer can do
  this. 
 
  As long as it's used with caution, I don't see a problem.
  
  Then we should define 'caution' I think :)
  
  Of course it
  would be bad if everyone pushed branches for any minor change.
  However, if there is a long-term work going on a branch, I don't
  see a problem with keeping it public.
  
  Most, if not all, projects I've seen use forks for this.
 
 Blender does not, afaik. And I've seen a lot of projects doing that.
 The difference between e.g. myremote/featurebranch and
 upstream/featurebranch is just that someone has looked over
 upstream/featurebranch and that it requires pull requests to get
 stuff in (so the developer work happens in their developer forks, but
 the results still get into the same upstream branch).

You can merge remote tracking branches just the same you merge
'upstream' branches. You can even rebase them which tends to give a
better history but is harder if you forbid non fast-forward pushes
to gentoo.git. Pull requests are only useful for pre-commit reviews.

 That would, for example, make sense for libressl. Since we basically
 just overwrite a lot of ebuilds to be able to test them with libressl
 patches. That is currently done with an overlay which always opens up
 the problem that we lack behind the tree and undesired openssl ebuilds
 leak in for the user, because of tree-overlay desync.

Branch or remote, this doesn't change anything since no commit to
master will automagically update your branch. The only thing you're
achieving is a fixed gentoo-x86 tree snapshot + an overlay in the same
repo, which you could already do anyway.



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Rich Freeman
On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov pinkb...@gentoo.org wrote:
 11.08.2015 16:11, James Le Cuirot пишет:
 On Tue, 11 Aug 2015 15:58:49 +0300
 Sergey Popov pinkb...@gentoo.org wrote:

 If both of flags are not set - we stick to default.
 Should this be set in EVERY ebuild explicitly?

 Maybe provide some sugar like $(qt_use_default qtgui 5), where
 qt_use_default is the name of function, qtgui is the package and 5 is
 the slot for default choice, where either BOTH of flags(qt4, qt5) are
 enabled or disabled

 That sounds a little bit like what I suggested earlier.

 https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df


 But without introducing brand new useless USE flag. Which makes huge
 difference to me :-)


If we want the typical user to not set either qt4 or qt5, are we
saying that any package that could use either always enable one of
them by default?  Then all users get a GUI by default, and then users
have to explicitly disable it?  That seems to be the opposite of how
we normally do things, but it does let you get away from having lots
of users turning on qt.

Normally we'd just turn them on in a profile, but you can't do this if
some packages need qt4, some need qt5, and some fail if both are
enabled.

-- 
Rich



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread hasufell
On 08/11/2015 03:52 PM, Patrice Clement wrote:
 Hi there
 
 According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
 there may be developer-specific, task-specific, project-specific branches
 etc. As far as I understand, it means I can go and create my own branch on 
 the
 main repository and push it and it gets spread all over the place. Is that
 correct?
 
 Could someone explain to me the rationale behind this decision?
 
 Truth to be told, I kinda dislike the fact any developer can do this. 
 
 proj/gentoo should be kept for serious business i.e. commits that affects 
 the
 tree. On the long run, if everybody goes down that road, we will see flourish
 numerous branches (who said unmaintained?), all stalled at a different state 
 of
 the main repo, and it will only generate a lot of noise and confusion for
 nothing. Further, since we've moved over to git, the main tree now gets
 replicated to github and we all have github accounts here, don't we? Which 
 makes
 the whole forking and submitting PRs a cinch.
 
 If a developer wants to tinker with the tree, he can fork it to its github
 devspace, fiddle around, and later on send us a PR back with his changes to
 merge.
 

Branches can still make sense, even if the model is that everyone has
his own fork, see
http://nvie.com/posts/a-successful-git-branching-model/
for an example.

I currently don't see a reason to limit the workflow to one master branch.

It doesn't necessarily generate noise or confusion and there are various
ways to only fetch specific branches if you really need to do so. Git's
main advantage _are_ branches and it has sufficient methods to deal with
a lot of them.

If they cause trouble, we can still prune them and enforce stricter
rules, but since we don't even know how they will be used, this point is
moot yet.



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Rich Freeman
On Tue, Aug 11, 2015 at 9:39 AM, Sergey Popov pinkb...@gentoo.org wrote:
 11.08.2015 16:30, Michael Palimaka пишет:

 Don't forget that as a project with no special authority, Qt's policy
 remains a suggestion for the vast majority of maintainers. If someone
 wishes to provide support for only one Qt version or abuse their users
 with REQUIRED_USE they are still free to do so.


 Not enforcing policies on main tree is a bad thing. If you make policy,
 make other maintainers follow it. I am not against consistent policy
 that ease life BOTH for developers and users.

++

I think the qt team taking the lead on this makes sense, but this is
the sort of thing that just makes sense as a treewide policy.  If
people don't like their suggested policy they can take it to
QA/council/whatever, but it makes more sense to have projects setting
standards than having everybody doing their own thing.

I realize this is frustrating and contentious, but I think we're
better off hashing this out, and implementing something reasonable,
than having a bazillion different conventions that users have to deal
with.  Usually I prefer maintainer autonomy, but this is just one of
those times it doesn't make sense.

-- 
Rich



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Alexis Ballier
On Tue, 11 Aug 2015 10:26:46 -0400
Anthony G. Basile bluen...@gentoo.org wrote:

 On 8/11/15 10:19 AM, hasufell wrote:
  On 08/11/2015 04:10 PM, Alexis Ballier wrote:
  On Tue, 11 Aug 2015 16:01:05 +0200
  Michał Górny mgo...@gentoo.org wrote:
 
  Dnia 2015-08-11, o godz. 15:52:16
  Patrice Clement monsie...@gentoo.org napisał(a):
 
  Hi there
 
  According to
  https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
  there may be developer-specific, task-specific, project-specific
  branches etc. As far as I understand, it means I can go and
  create my own branch on the main repository and push it and it
  gets spread all over the place. Is that correct?
 
  Could someone explain to me the rationale behind this decision?
 
  Truth to be told, I kinda dislike the fact any developer can do
  this.
  As long as it's used with caution, I don't see a problem.
  Then we should define 'caution' I think :)
 
 
 I would not say caution so much as good judgment.  The first
 example that came to mind was working with the profiles which crosses
 many directories and files.  In the past when I did restructuring to
 the hardened profiles, I tested by using a branch of the hardened-dev 
 overlay.  It was annoying and I would do a bind mount over 
 /usr/portage/profiles and had to rebase manually.  A test branch of
 the the main tree which could get rebased and eventually merged back
 would make the workflow so much better.  Another example was when we 
 revitalized the selinux policies.  There were hundreds of commits to
 be done.  A branch here that got merged back would be ideal.


you probably did this before it happened, but a solution in the last
months could have been to fork gentoo-portage-rsync-mirror, merge it
back (or better: rebase onto it) from time to time, and do a squashed PR
that you can merge with mgorny's scripts.



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread hasufell
On 08/11/2015 04:10 PM, Alexis Ballier wrote:
 On Tue, 11 Aug 2015 16:01:05 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
 Dnia 2015-08-11, o godz. 15:52:16
 Patrice Clement monsie...@gentoo.org napisał(a):

 Hi there

 According to
 https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
 there may be developer-specific, task-specific, project-specific
 branches etc. As far as I understand, it means I can go and create
 my own branch on the main repository and push it and it gets spread
 all over the place. Is that correct?

 Could someone explain to me the rationale behind this decision?

 Truth to be told, I kinda dislike the fact any developer can do
 this. 

 As long as it's used with caution, I don't see a problem.
 
 Then we should define 'caution' I think :)
 
 Of course it
 would be bad if everyone pushed branches for any minor change.
 However, if there is a long-term work going on a branch, I don't see
 a problem with keeping it public.
 
 Most, if not all, projects I've seen use forks for this.

Blender does not, afaik. And I've seen a lot of projects doing that. The
difference between e.g. myremote/featurebranch and
upstream/featurebranch is just that someone has looked over
upstream/featurebranch and that it requires pull requests to get stuff
in (so the developer work happens in their developer forks, but the
results still get into the same upstream branch).

That would, for example, make sense for libressl. Since we basically
just overwrite a lot of ebuilds to be able to test them with libressl
patches. That is currently done with an overlay which always opens up
the problem that we lack behind the tree and undesired openssl ebuilds
leak in for the user, because of tree-overlay desync.



[gentoo-dev] Re: useflag policies

2015-08-11 Thread Michael Palimaka
On 11/08/15 23:39, Sergey Popov wrote:
 11.08.2015 16:30, Michael Palimaka пишет:

 Don't forget that as a project with no special authority, Qt's policy
 remains a suggestion for the vast majority of maintainers. If someone
 wishes to provide support for only one Qt version or abuse their users
 with REQUIRED_USE they are still free to do so.

 
 Not enforcing policies on main tree is a bad thing. If you make policy,
 make other maintainers follow it. I am not against consistent policy
 that ease life BOTH for developers and users.

With what authority? Whether we like it or not, no project has any
formal authority to tell others how to handle their part of Gentoo.

 
 You think that REQUIRED_USE is abusive to users: fine. Point accepted.
 I think that provided DEPEND strings if they will be typed at every
 single qt-related ebuild that needs them are abusive to developers.
 
 So, maybe we should wrap them into eclass and stop riding our own
 bicycles...
 
 And then - use apropriate one-liner where it's needed, providing
 reasonable default and NOT confusing users with overmanaging their
 package.use
 

Please read Ben's original post again. Dependency strings are not the topic.




[gentoo-dev] Mirroring Gentoo project/team members on GitHub

2015-08-11 Thread Michał Górny
Hello, everyone.

Now that we're officially on git and can officially use pull requests
to provide rapid community interaction, it'd be convenient to have
a little better framework for pinging package maintainers.

With the unofficial mirror/pull request project, I was either looking
for project member GitHub accounts and pinging found project members by
name, or talking to them directly on IRC. However, with the growth in
number of pull requests this will become more and more inconvenient.
Therefore, I think it's time to be able to mirror teams willing to work
with GitHub community there for easier 'pings'.

I have two ideas right now:

1. creating GitHub Gentoo project teams corresponding to willing Gentoo
teams,

2. preparing lists of GitHub usernames on project wiki pages.

Solution 1. is cleaner. In this case, we create GitHub teams under
the Gentoo projects, and add appropriate Gentoo developers having
GitHub accounts to the teams. Then, in PRs we can just ping the whole
team like @Gentoo/Qt or like.

Solution 2. avoids adding any GitHub teams. In this case, in team wiki
page we collect team member usernames like @Pesa, @kensington, ... so
we could copy-paste it to pull requests. We still require extra effort
when 'assigning' PRs but at least I don't have to lookup the same
people over and over again.

With some Wiki people help, we could even implement updating GitHub
teams automatically following Wiki member changes.

Your thoughts?

-- 
Best regards,
Michał Górny
http://dev.gentoo.org/~mgorny/


pgpcKS2VQk_90.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

2015-08-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 06:11 AM, Leno Hou wrote:
 I think ppc64le would become popular,
 https://en.wikipedia.org/wiki/Ppc64.
 
 1. enable porting x86 Linux based application with minimal effort.
  2. Some PowerPC user, little endian apparently feels cheap, wrong,
 and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE
 already support little endian in powerpc.
 
 

In terms of the codepaths, what's different between ppc64le vs ppc64,
and ppc64le vs amd64 ?  Obviously kernels will differ, but in terms of
C/C++/other compiled source code what needs to change?

If all this needs is its own profile for a CHOST/CBUILD specification
and it can leverage an existing keyword, then this should be rather
simple to implement yes?



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKB7UACgkQAJxUfCtlWe1sbQD+KcbYpfo56GrLIVlFyw2iXbMB
ZOWzuvyI8SVq/DY0SQMBAJgDIjCza8QyUgWEtq2/g5Yu+uWiCibf2ouMeNAOkQ33
=YoUg
-END PGP SIGNATURE-



Re: [gentoo-dev] Summary line

2015-08-11 Thread hasufell
On 08/11/2015 04:28 PM, Ian Stakenvicius wrote:
 On 11/08/15 04:57 AM, Tobias Klausmann wrote:
 The more we stuff into the summary line, the harder it will be to 
 write meaningful summaries. And thus, people will write crappy ones
 or ignore the length limit. I recommend against any more 
 prescription over Add the the cat/pn if meaningful, don't use more
 than 75 characters.
 
 The cat/pn rule is tricky anyway: what if one commit touches 100 
 packages? Or should that be split into 100 commits for easier 
 partial rollback?
 
 Regards, Tobias
 
 
 
 The summary line limit is going to be a real issue, tbh.  I think it
 would probably be best to adopt the convention of putting a few
 choice, perhaps even canned, phrases in the summary line, and ensure
 any and all details (effectively what the summary line used to be for
 when it had practically no limit) within the commit message body instead
 .
 
 Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn:
 adjusted dependencies' are generic (and short) enough yet descriptive
 enough to see what went on while scanning the log.  'Fix bug' IMO in
 the summary doesn't work at all because, although its accurate, that
 bug could literally be anything at all.
 
 Multi-package commits are going to be more of an issue of course..  I
 did one last night, fortunately I think I can get away with using
 mozilla packages in place of cat/pn since it is a very specific set
 of packages.  Perhaps for sweeping changes like that we can use the
 herdname or projectname or the category name (if its a particular
 category only)?
 
 
 

The CATEGORY: prefix is already in the wiki. Interesting idea about
projectname/herdname prefix.

I've already seen someone (I think ulm) prefixing with [QA].

I don't feel strong about this. IMO, if there is no useful prefix...
just don't use any. The lack of prefix will make it obvious that this is
a larger change. But project/herd specific prefixes could still make sense.



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 06:10 AM, Sergey Popov wrote:
 Err, i have read the whole thread and still does not get a point,
 why i am wrong.
 
 It's old battle like we have beforce with gtk meaning any
 versions of GTK flag. This behaviour should be killed with fire.
 
 Let's me reiterate some of the cases:
 
 1. Package can be build without Qt GUI at all, but either Qt4 or
 Qt5 can be chosen, but not both.
 
 Fix this with REQUIRED_USE, do not enable any of Qt flags by
 default
 


Why does this need REQUIRED_USE at all?  neither flag is necessary,
and just because the package only uses one flag at a time doesn't mean
we should require users that have both flags set in profiles to -have
to- package.use one of them off.



 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is 
 required, but not both
 
 Same thing here, different REQUIRED_USE operator. But - enable one
 of the flags by default to ease life of users.
 

IUSE=qt4 +qt5 and USE=qt4 -qt5 globally (ie from profiles) is
going to make a REQUIRED_USE force an exception in package.use as
well.  Again, annoying to end-users for no overly good reason and see #1
.


 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if
 such package even exists?)
 
 Do not use REQUIRED_USE here, not needed.
 
 Now, please tell me, where am i wrong?
 


IMO it's wrong because REQUIRED_USE is a BFH for what really ends up
as an extra, dangling enabled use flag.  Unless there's a case (and i
truely doubt there is) that there's a package with IUSE=qt4 that
depends on ANOTHER package with IUSE=qt4 qt5, and that other package
only builds against one implementation, AND the dep on the first
package doesn't include any use deps, I still see no actual -need- for
REQUIRED_USE.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKCZwACgkQAJxUfCtlWe3GqwEA2UCV9E+h+Djy7+KiwqODkEjv
MiToijoa6ncX3xicD4cA/3PIQcv3ObG+obxECkB1gzyYclQrVGCaHT79DAkVE3oK
=2iat
-END PGP SIGNATURE-



Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

2015-08-11 Thread Mikle Kolyada


11.08.2015 17:32, Michał Górny пишет:
 Hello, everyone.

 Now that we're officially on git and can officially use pull requests
 to provide rapid community interaction, it'd be convenient to have
 a little better framework for pinging package maintainers.

 With the unofficial mirror/pull request project, I was either looking
 for project member GitHub accounts and pinging found project members by
 name, or talking to them directly on IRC. However, with the growth in
 number of pull requests this will become more and more inconvenient.
 Therefore, I think it's time to be able to mirror teams willing to work
 with GitHub community there for easier 'pings'.

 I have two ideas right now:

 1. creating GitHub Gentoo project teams corresponding to willing Gentoo
 teams,

 2. preparing lists of GitHub usernames on project wiki pages.

 Solution 1. is cleaner. In this case, we create GitHub teams under
 the Gentoo projects, and add appropriate Gentoo developers having
 GitHub accounts to the teams. Then, in PRs we can just ping the whole
 team like @Gentoo/Qt or like.

 Solution 2. avoids adding any GitHub teams. In this case, in team wiki
 page we collect team member usernames like @Pesa, @kensington, ... so
 we could copy-paste it to pull requests. We still require extra effort
 when 'assigning' PRs but at least I don't have to lookup the same
 people over and over again.

 With some Wiki people help, we could even implement updating GitHub
 teams automatically following Wiki member changes.

 Your thoughts?


First one more clear. Jut don't forget update it, when someone new join
the team, as usual.



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Rich Freeman
On Tue, Aug 11, 2015 at 10:26 AM, Anthony G. Basile bluen...@gentoo.org wrote:
 I would not say caution so much as good judgment.  The first example that
 came to mind was working with the profiles which crosses many directories
 and files.  In the past when I did restructuring to the hardened profiles, I
 tested by using a branch of the hardened-dev overlay.  It was annoying and I
 would do a bind mount over /usr/portage/profiles and had to rebase manually.
 A test branch of the the main tree which could get rebased and eventually
 merged back would make the workflow so much better.  Another example was
 when we revitalized the selinux policies.  There were hundreds of commits to
 be done.  A branch here that got merged back would be ideal.


Agree.  You could still do this with an outside repository that
everybody adds a remote to (a git repository can have many remotes).
You can merge/rebase from a branch outside of gentoo to one inside of
gentoo.

I think the preference should be that users doing their own work
should try to keep the interim stuff out of the main gentoo
repository.  On the other hand, when collaborating teams should be
welcome to use the gentoo repository or their own overlay as makes
sense, with the preference moving more to gentoo as the number of
impacted devs/testers/etc gets bigger.  It will always be a judgment
call.

In the end there isn't that big a difference in git between git
checkout origin/proj/kde5 and git checkout kde5overlay/master.
That is the beauty of git.

-- 
Rich



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 12:03 PM, hasufell wrote:
 On 08/11/2015 05:21 PM, Alexis Ballier wrote:
 
 Big changes that that go in feature branches and are merged in
 one pass are, from my experience, way too much prone to errors.
 Did anyone ever try to review a merge commit?
 
 
 You will run repoman (and probably other pkgcore based checks)
 before you push that merge. That is for sure.
 
 The only problem that can arise there is that we don't roll our
 versions via branches, but via filenames. That means you may
 merge correctly, but in master there was already a newer version
 of app-misc/foo which now lacks the multilib migration (which
 isn't a tree breaker, since stuff still repomanchecks).
 
 We could probably come up with some magic git/bash lines that
 help with that. As in: not just detect merge-conflicts, but also
 soft conflicts in the sense that someone else touched the same
 ebuild-directory as you in between.
 
 NixOS for example has (probably not only for that reason) not
 any version based filenames, but they roll release-channels via
 branches.
 

That sort of relates to the idea that was brought up last year, if
portage could be made to detect and do VDB-only merges and would
re-emerge ebuilds based on the fact that they were modified rather
than their ${PVR} being incremented, then we could get rid of
revision#'s entirely.  Not a true version removal but it would
reduce the number of distinct files we would be working with in
cases like the above.

But this isn't the place to discuss that tangent I don't think; that
needs a whole new thread and a whole lot of portage development and
possibly a PMS change?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKHf0ACgkQAJxUfCtlWe23RQEAuuHF7S5bKHl8ayGYgitGZFuh
ETcKKDxaKw76i2pVDwkA/RLwUKUpbZpId7mvl3j9c4obO9ZAxCaxW25UikU1ZtsV
=YBDy
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: rsync mirror security

2015-08-11 Thread Rich Freeman
On Tue, Aug 11, 2015 at 10:53 AM, Matthias Maier tam...@gentoo.org wrote:

 constantly adds any security to the tree.  What might add security for
 end-users is if git automatically checked the push signatures, which
 are the signatures that ensure that branches aren't tampered with
 (which is what rebasing you bring up actually does).

 It is news to me that a signature from a push is also transported to a
 subsequent pull request for a client, do you have some external
 references for this procedure?


They're stored in the tree under the ref refs/push-certs.  I have no
idea how to go about verifying them - they're pretty new so there
aren't a lot of docs.  I had no idea they were even there until Robin
answered a similar question I asked him.

git ls-remote for those curious about what other refs are lying around.

-- 
Rich



Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

2015-08-11 Thread Michał Górny
Dnia 2015-08-11, o godz. 18:45:40
hasufell hasuf...@gentoo.org napisał(a):

 On 08/11/2015 06:42 PM, Michał Górny wrote:
  Dnia 2015-08-10, o godz. 22:51:59
  hasufell hasuf...@gentoo.org napisał(a):
  
 
  I was wondering if that could be automated in a separate branch (only
  needs to update in 24h intervals).
  
  Please don't cruft the repo with huge metadata. And I have
  metadata-applied mirrors for all repositories at [1].
  
  [1]:https://github.com/gentoo-mirror/
  
 
 The problem with those mirrors is... the history is gone and the
 signatures as well. So people would have to clone the metadata-cache
 from that mirror, put it into the real mirror clone and then probably
 still update it via egencache, because they are not perfectly in sync.

I know. I'm planning to improve it when I have some time. So far this
was easier because not all repos are git, and I'm not really into
trying hard to convert other VCS-es.

-- 
Best regards,
Michał Górny
http://dev.gentoo.org/~mgorny/


pgpchQVprgyFI.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Alexis Ballier
On Tue, 11 Aug 2015 11:11:43 -0400
Ian Stakenvicius a...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 11/08/15 10:01 AM, Michał Górny wrote:
  Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement
  monsie...@gentoo.org napisał(a):
  
  Hi there
  
  According to
  https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
 
  
 there may be developer-specific, task-specific, project-specific
 branch es
  etc. As far as I understand, it means I can go and create my own
  branch on the main repository and push it and it gets spread all
  over the place. Is that correct?
  
  Could someone explain to me the rationale behind this decision?
  
  Truth to be told, I kinda dislike the fact any developer can do
  this.
  
  As long as it's used with caution, I don't see a problem. Of course
  it would be bad if everyone pushed branches for any minor change.
  However, if there is a long-term work going on a branch, I don't
  see a problem with keeping it public.
  
 
 Examples in particular I can think of for something like this being
 useful would be for, say, major EAPI-bump-related feature
 implementations (ie, EAPI5 and slot-operators/subslots), or major
 across-tree impementation changes like what we saw with the
 multilib-eclass porting.
 
 These are large projects touching most if not all ebuilds, that a
 great many developers would or should be involved in.  Something like
 this could be done in a separately hosted repo instead of in the main
 gentoo repo, but then all developers would need to subscribe to this
 other repo, while having it in a branch in the main one i think would
 make it easier for everyone to get involved once they're ready, and
 would still allow the changes to stay out of the master branch until
 the project is ready to launch.


For me, this is actually a reason to prohibit it :)

EAPI bumps should be done package by package, not at a major scale:
otherwise, let's just scrap EAPI entirely and update the API as we see
fit with p.masked package managers :)

multilib eclasses conversions should also be done one by one to be done
properly (otherwise using multilib-portage is probably a better idea)
and each conversion touches one package (two if you count emul-*).

Big changes that that go in feature branches and are merged in one pass
are, from my experience, way too much prone to errors. Did anyone ever
try to review a merge commit?



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread hasufell
On 08/11/2015 05:21 PM, Alexis Ballier wrote:
 
 Big changes that that go in feature branches and are merged in one pass
 are, from my experience, way too much prone to errors. Did anyone ever
 try to review a merge commit?
 

You will run repoman (and probably other pkgcore based checks) before
you push that merge. That is for sure.

The only problem that can arise there is that we don't roll our versions
via branches, but via filenames. That means you may merge correctly, but
in master there was already a newer version of app-misc/foo which now
lacks the multilib migration (which isn't a tree breaker, since stuff
still repomanchecks).

We could probably come up with some magic git/bash lines that help with
that. As in: not just detect merge-conflicts, but also soft conflicts
in the sense that someone else touched the same ebuild-directory as you
in between.

NixOS for example has (probably not only for that reason) not any
version based filenames, but they roll release-channels via branches.



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Rich Freeman
On Tue, Aug 11, 2015 at 10:42 AM, Michael Palimaka
kensing...@gentoo.org wrote:
 On 12/08/15 00:29, Rich Freeman wrote:

 I realize this is frustrating and contentious, but I think we're
 better off hashing this out, and implementing something reasonable,
 than having a bazillion different conventions that users have to deal
 with.  Usually I prefer maintainer autonomy, but this is just one of
 those times it doesn't make sense.


 Isn't this moving towards a situation that we used GLEP 39 to remove?


Fair enough.  I don't really have a problem with the qt team proposing
a policy and having QA or the Council bless it.  Or having a more
general policy and the QA policy is just an instance of it.

-- 
Rich



Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

2015-08-11 Thread Michał Górny
Dnia 2015-08-10, o godz. 22:51:59
hasufell hasuf...@gentoo.org napisał(a):

 On 08/10/2015 10:47 PM, Andrew Savchenko wrote:
  On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:
  On 08/10/2015 05:09 PM, Rich Freeman wrote:
  On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert flop...@gentoo.org wrote:
 
  Expanding on this: the rsync master creates the following
  files/directories under metatdata. On my own system, I like to symlink
  them to locations outside my repo so that related portage features
  continue to work.
 
  I would like to have these added in .gitignore.
 
  metadata/dtd/ # used by something?
  metadata/glsa/ # used by the GLSA utilities?
  matadata/herds.xml # used by equery from gentoolkit
  metadata/news/ # used by eselect news
 
 
  As a side note, it probably wouldn't hurt to set up a guide for
  running git on /usr/portage, including setting up these symlinks,
  running egencache after emerge --sync, etc.  I imagine that this is a
  configuration that many developers will tend to use, and with the
  advent of git we may see more users who tend to contribute doing the
  same.
 
 
  In fact, this should be the recommended way of running gentoo for
  everyone. Our rsync methods are still inherently insecure (unless I
  missed something), because:
  1. machine key
  2. profiles, eclasses and so on are not covered with a
  signature/Manifest anyway
   
  Not unless metadata cache will be synced too from a trusted source.
  It takes too much time to generate, especially on non-brand-new
  hardware.
  
 
 I was wondering if that could be automated in a separate branch (only
 needs to update in 24h intervals).

Please don't cruft the repo with huge metadata. And I have
metadata-applied mirrors for all repositories at [1].

[1]:https://github.com/gentoo-mirror/

-- 
Best regards,
Michał Górny
http://dev.gentoo.org/~mgorny/


pgpAowOCShyhg.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Summary line

2015-08-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 10:35 AM, Kent Fredric wrote:
 On 12 August 2015 at 02:28, Ian Stakenvicius a...@gentoo.org
 wrote:
 Stuff like 'cat/pn: version bumps', 'cat/pn: new features',
 'cat/pn: adjusted dependencies' are generic (and short) enough
 yet descriptive enough to see what went on while scanning the
 log.
 
 I personally find those summaries a bit too terse.
 
 Mostly, because when I see A version is bumped I immediately
 expect to know which version the bump is to, but have to dig out
 the diff to find out.
 
 I would also prefer, where possible, to replace adjusted 
 dependencies to be more concise, like include dev-perl/Foo in 
 dependencies, ( though of course, apply some taste, listing more
 than 3 distinct new dependencies in the summary is execessive,
 treat them like hashtags on twitter, 1 is good, 2 is OK, 3 and
 you're starting to get crazy )
 

I agree, these are short and don't have nearly as much meaning as
they should -- if there's space, absolutely we should add more
meaning.  I think my point still stands though that the short
description should be more like these messages rather than fix
bug#someting when there's absolutely no indication of what the bug
is actually about.

So long as all of the details are in the main commit message body,
of course...

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKFFcACgkQAJxUfCtlWe0FRAEAgrL/FYmdYlA10JQyjkhrWPW6
Md6CjK5CCWQh35sz5U8A/Agp6d8HHSu69ZinmhE1VCw9D8TjJ3r5WtQYEo0X8Vhj
=WHfg
-END PGP SIGNATURE-



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/08/15 11:21 AM, Alexis Ballier wrote:
 On Tue, 11 Aug 2015 11:11:43 -0400 Ian Stakenvicius
 a...@gentoo.org wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 On 11/08/15 10:01 AM, Michał Górny wrote:
 Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement 
 monsie...@gentoo.org napisał(a):
 
 Hi there
 
 According to 
 https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,



 
there may be developer-specific, task-specific, project-specific
 branch es
 etc. As far as I understand, it means I can go and create
 my own branch on the main repository and push it and it
 gets spread all over the place. Is that correct?
 
 Could someone explain to me the rationale behind this
 decision?
 
 Truth to be told, I kinda dislike the fact any developer
 can do this.
 
 As long as it's used with caution, I don't see a problem. Of
 course it would be bad if everyone pushed branches for any
 minor change. However, if there is a long-term work going on
 a branch, I don't see a problem with keeping it public.
 
 
 Examples in particular I can think of for something like this
 being useful would be for, say, major EAPI-bump-related
 feature implementations (ie, EAPI5 and
 slot-operators/subslots), or major across-tree impementation
 changes like what we saw with the multilib-eclass porting.
 
 These are large projects touching most if not all ebuilds, that
 a great many developers would or should be involved in.
 Something like this could be done in a separately hosted repo
 instead of in the main gentoo repo, but then all developers
 would need to subscribe to this other repo, while having it in
 a branch in the main one i think would make it easier for
 everyone to get involved once they're ready, and would still
 allow the changes to stay out of the master branch until the
 project is ready to launch.
 
 
 For me, this is actually a reason to prohibit it :)
 
 EAPI bumps should be done package by package, not at a major
 scale: otherwise, let's just scrap EAPI entirely and update the
 API as we see fit with p.masked package managers :)

Not EAPI bumps, but implementation of major new features as a result
of the new EAPI.  Most EAPI changes generally are beneficial to
particular ebuilds, but some (such as slot-operators and subslots)
really needed to be implemented across a great many packages (and
eclasses too at times).  We did it with overlays and patches via
b.g.o and slowly things migrated, but I think it would have gone a
lot faster if all developers had quick and easy access to a branch.

 multilib eclasses conversions should also be done one by one to
 be done properly (otherwise using multilib-portage is probably a
 better idea) and each conversion touches one package (two if you
 count emul-*).

But they don't just touch one package -- you pretty much needed to
do a full deptree at a time.  We worked around it with a rather
messy 'delete all files in emul-* that collide with the
multilib-built packages currently available' plus a convoluted set
of ||() deps wrapping each emul and the individual alternative
atoms.  And even then it was still a mess to try and actually use it
on end-user systems due to various conflicts.

 Big changes that that go in feature branches and are merged in
 one pass are, from my experience, way too much prone to errors.
 Did anyone ever try to review a merge commit?

This makes sense, yes; the merge back to the main tree could very
well be more difficult than it's worth, however if the branch is
available to all, then the migration into the main tree could be
done piecemeal in batches too rather than in one huge swash.

The point is, I think it'd be easier and faster to implement these
major treewide projects (and easier to verify too) if the work could
be done in a branch available to all, rather than in what would
effectively be an overlay someplace external.How we manage it
effectively, I can't say one way or the other but likely this is
something that we will need to learn from experience as much as
decree policy for.




-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXKGfIACgkQAJxUfCtlWe11XgD/SvvIb9pcZ/k2WRH5OsrKG2G4
0uYC0godRRVytY7s78MA/0dMKUqAlVmqF/HntzPJYoLAqQxGCsrNassDB1iLBV6p
=/msL
-END PGP SIGNATURE-



Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

2015-08-11 Thread hasufell
On 08/11/2015 06:42 PM, Michał Górny wrote:
 Dnia 2015-08-10, o godz. 22:51:59
 hasufell hasuf...@gentoo.org napisał(a):
 

 I was wondering if that could be automated in a separate branch (only
 needs to update in 24h intervals).
 
 Please don't cruft the repo with huge metadata. And I have
 metadata-applied mirrors for all repositories at [1].
 
 [1]:https://github.com/gentoo-mirror/
 

The problem with those mirrors is... the history is gone and the
signatures as well. So people would have to clone the metadata-cache
from that mirror, put it into the real mirror clone and then probably
still update it via egencache, because they are not perfectly in sync.



Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

2015-08-11 Thread William Hubbs
On Tue, Aug 11, 2015 at 04:32:40PM +0200, Michał Górny wrote:
 Hello, everyone.
 
 Now that we're officially on git and can officially use pull requests
 to provide rapid community interaction, it'd be convenient to have
 a little better framework for pinging package maintainers.
 
 With the unofficial mirror/pull request project, I was either looking
 for project member GitHub accounts and pinging found project members by
 name, or talking to them directly on IRC. However, with the growth in
 number of pull requests this will become more and more inconvenient.
 Therefore, I think it's time to be able to mirror teams willing to work
 with GitHub community there for easier 'pings'.

People can also use the git request-pull command to tell maintainers
where to pull from, so I'm not sure that mirroring every team/member on
github is necessary.

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] Managing etc/* in an embbeded system

2015-08-11 Thread Zac Medico
On 08/11/2015 10:48 AM, Joakim Tjernlund wrote:
 On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote:
 On 07/23/2015 12:46 AM, Joakim Tjernlund wrote:
 On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote:

 Sent from an iPhone, sorry for the HTML...

 On Jul 22, 2015, at 5:38 PM, Rich Freeman ri...@gentoo.org wrote:

 On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund
 joakim.tjernl...@transmode.se wrote:

 There can not be any manual merges after an SW update here.

 I started to look at INSTALL_MASK, what if I set INSTALL_MASK
 to point to all conf files I want to manage myself.
 Then /etc/inittab etc. will not be touched when updating init

 This sounds like overkill.

 If you've already installed a custom /etc/inittab, then when you
 emerge init, it won't overwrite your inittab even if you don't change
 anything in your portage config.  emerge won't touch any files in /etc
 unless they don't already exist.  


 ..AND have been modified.  IIRC if the hash of the config files match what 
 they were when the package 
 was 
 previously emerged, then the files are updated aren't they?

 I expect that this is fine in the situation described, but it's worth 
 knowing that a config file left 
 unmodified may be replaced with a different vanilla config file later on.

 Sure, but what if I need to change a conf file in an installed system? Or 
 rebuild a a system from scratch?
 The user only runs a one SW update command to update an installed system in 
 the field and cannot edit a 
 bunch
 of files too. Especially when there are hundreds of systems sitting in 
 remote locations.

 If you use the profile-bashrcs profile-formats setting [1], then your
 profiles can use package.bashrc to define post_src_install and/or
 INSTALL_MASK to remove unwanted config files from upstream packages.
 Then you can easily replace the upstream config files with config files
 installed by your own configurations installed by your own ebuilds.
 
 Finally getting back to this after lots of distractions.
 I cannot get profile-formats  = profile-bashrcs to work.
 I have in metadata/layout.conf:
   masters = gentoo
   profile-formats = portage-2 profile-bashrcs 
 then in profiles/tmv3-target-overlay/profile.bashrc:
   INSTALL_MASK=
 Doing portageq envvar INSTALL_MASK just yields an empty line
 I guess I am missing something here?
 
 

See the man portage for profile-bashrcs details. It uses
package.bashrc rather than profile.bashrc, so that explains why it's not
working for you.
-- 
Thanks,
Zac



Re: [gentoo-dev] Managing etc/* in an embbeded system

2015-08-11 Thread Joakim Tjernlund
On Tue, 2015-08-11 at 10:55 -0700, Zac Medico wrote:
 On 08/11/2015 10:48 AM, Joakim Tjernlund wrote:
  On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote:
   On 07/23/2015 12:46 AM, Joakim Tjernlund wrote:
On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote:
 
 Sent from an iPhone, sorry for the HTML...
 
  On Jul 22, 2015, at 5:38 PM, Rich Freeman ri...@gentoo.org wrote:
  
  On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund
  joakim.tjernl...@transmode.se wrote:
   
   There can not be any manual merges after an SW update here.
   
   I started to look at INSTALL_MASK, what if I set INSTALL_MASK
   to point to all conf files I want to manage myself.
   Then /etc/inittab etc. will not be touched when updating init
  
  This sounds like overkill.
  
  If you've already installed a custom /etc/inittab, then when you
  emerge init, it won't overwrite your inittab even if you don't 
  change
  anything in your portage config.  emerge won't touch any files in 
  /etc
  unless they don't already exist.  
 
 
 ..AND have been modified.  IIRC if the hash of the config files match 
 what they were when the 
 package 
 was 
 previously emerged, then the files are updated aren't they?
 
 I expect that this is fine in the situation described, but it's worth 
 knowing that a config file 
 left 
 unmodified may be replaced with a different vanilla config file later 
 on.

Sure, but what if I need to change a conf file in an installed system? 
Or rebuild a a system from 
scratch?
The user only runs a one SW update command to update an installed 
system in the field and cannot edit 
a 
bunch
of files too. Especially when there are hundreds of systems sitting in 
remote locations.
   
   If you use the profile-bashrcs profile-formats setting [1], then your
   profiles can use package.bashrc to define post_src_install and/or
   INSTALL_MASK to remove unwanted config files from upstream packages.
   Then you can easily replace the upstream config files with config files
   installed by your own configurations installed by your own ebuilds.
  
  Finally getting back to this after lots of distractions.
  I cannot get profile-formats  = profile-bashrcs to work.
  I have in metadata/layout.conf:
masters = gentoo
profile-formats = portage-2 profile-bashrcs 
  then in profiles/tmv3-target-overlay/profile.bashrc:
INSTALL_MASK=
  Doing portageq envvar INSTALL_MASK just yields an empty line
  I guess I am missing something here?
  
  
 
 See the man portage for profile-bashrcs details. It uses
 package.bashrc rather than profile.bashrc, so that explains why it's not
 working for you.

hmm, I figured I could use profile.bashrc to set stuff for all pkgs?
In any case I tried package.bashrc but portageq envvar INSTALL_MASK does not 
print
anything either. It occurred to me that portageq envvar is not the right tool 
see
variable defined in bash scripts? Is there some other tools I can use?

 Jocke




[gentoo-portage-dev] [PATCH] egencache: Always output EAPI=0 in cache entries

2015-08-11 Thread Michał Górny
Remove the code skipping EAPI=0 output in cache entries. There is really
no reason to treat EAPI=0 specially here, and this makes the output more
consistent.
---
 bin/egencache | 2 --
 1 file changed, 2 deletions(-)

diff --git a/bin/egencache b/bin/egencache
index 6075ccf..5c00248 100755
--- a/bin/egencache
+++ b/bin/egencache
@@ -297,8 +297,6 @@ class GenCache(object):
# EAPI from _parse_eapi_ebuild_head, we don't write cache
# entries for unsupported EAPIs.
if metadata is not None and eapi_supported:
-   if metadata.get('EAPI') == '0':
-   del metadata['EAPI']
for trg_cache in self._trg_caches:
self._write_cache(trg_cache,
cpv, repo_path, metadata, ebuild_hash)
-- 
2.5.0




Re: [gentoo-dev] Managing etc/* in an embbeded system

2015-08-11 Thread Joakim Tjernlund
On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote:
 On 07/23/2015 12:46 AM, Joakim Tjernlund wrote:
  On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote:
   
   Sent from an iPhone, sorry for the HTML...
   
On Jul 22, 2015, at 5:38 PM, Rich Freeman ri...@gentoo.org wrote:

On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
 
 There can not be any manual merges after an SW update here.
 
 I started to look at INSTALL_MASK, what if I set INSTALL_MASK
 to point to all conf files I want to manage myself.
 Then /etc/inittab etc. will not be touched when updating init

This sounds like overkill.

If you've already installed a custom /etc/inittab, then when you
emerge init, it won't overwrite your inittab even if you don't change
anything in your portage config.  emerge won't touch any files in /etc
unless they don't already exist.  
   
   
   ..AND have been modified.  IIRC if the hash of the config files match 
   what they were when the package 
   was 
   previously emerged, then the files are updated aren't they?
   
   I expect that this is fine in the situation described, but it's worth 
   knowing that a config file left 
   unmodified may be replaced with a different vanilla config file later on.
  
  Sure, but what if I need to change a conf file in an installed system? Or 
  rebuild a a system from scratch?
  The user only runs a one SW update command to update an installed system in 
  the field and cannot edit a 
  bunch
  of files too. Especially when there are hundreds of systems sitting in 
  remote locations.
 
 If you use the profile-bashrcs profile-formats setting [1], then your
 profiles can use package.bashrc to define post_src_install and/or
 INSTALL_MASK to remove unwanted config files from upstream packages.
 Then you can easily replace the upstream config files with config files
 installed by your own configurations installed by your own ebuilds.

Finally getting back to this after lots of distractions.
I cannot get profile-formats  = profile-bashrcs to work.
I have in metadata/layout.conf:
  masters = gentoo
  profile-formats = portage-2 profile-bashrcs 
then in profiles/tmv3-target-overlay/profile.bashrc:
  INSTALL_MASK=
Doing portageq envvar INSTALL_MASK just yields an empty line
I guess I am missing something here?




Re: [gentoo-dev] RFC: News item about Nepomuk removal

2015-08-11 Thread Johannes Huber
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

given non-negative replies this is published now.

Greeting.

Am 08.08.2015 um 13:28 schrieb Johannes Huber:
 Hello Gentoos,
 
 please read and comment on the attached news item for the upcoming
 Nepomuk removal.
 
 Greetings,
 

- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVyjmnXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vPt8QAJAz9KMS2/WZQ10ss2I5qqYI
3VM91lt2GQ0FBypu5sAiTFftqXOYdB7prY1iW4QmBWvFpR7Ul9qfeZED1dTHkS4F
yAZ4BfseaO2pVcQaQ/biKDxKOKBU7j/FJ94fSpLOuLju52Ed2+RJ3eKD6w9LBNjr
THVWiv6kQehMu4hk16EY5nRyAM8pRuU+iaZ2P5xthqhMnIieXhbxS77T9W6DHWnM
3U11y5lukcFBKWPoBVcfKWuQHaaobwW8QpAz0gOmb7kI4jm2Q5L2Y2oW3gfWR9pM
V2PmRZ7XwQ/SRYgTBRlL3vpkQQ7uq9VUcp2C0XfNbXDYRzh3af+0uvAiG6h8GilK
SeTbrcmEmE7DQVedbSNw78SX/GnU/Ql8KanNM01qc3oJfWfsxsFruezfDklNmQ83
ma+cSk3PR1ZOe6BmUKX9Wl+Jy/jS0eASxjHPd946W8KcOZNwzRhZxMJV5lOP09Xn
/cIJalaI3ZbAwtc1FldUDLbMwzQUXH8HsqkRHM5vdfXRcIflMA1ryKMGQbXgCWrQ
vSG999wCPtAG3skaqok8ZCaGr5qgqOkIGvv3I7wKY71OKCNe2wHuM5GmPW9uqtVI
RnchiDFxGnS5NiIehjo/AWal/fDT6V3C9JizlLYQ5wiEL+zIoWRtt+SzohXUcIHe
LR1TqelJ56TZ/p4ou8Lj
=EnjI
-END PGP SIGNATURE-
Title: Nepomuk removal
Author: Johannes Huber j...@gentoo.org
Content-Type: text/plain
Posted: 2015-08-11
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: dev-db/virtuoso-server

With KDE SC 4.13.0 release the default semantic desktop search engine
switched from Nepomuk to Baloo.[1] This change was honoured in Gentoo
by changing the semantic-desktop use flag to cover the new engine and
moving the old to nepomuk use flag.

The underlaying storage backend for Nepomuk aka Virtuoso DB has a lot
of unsolved upstream issues[2], therefore we will remove it. This means
packages with build options on the old stack will drop them. Other
packages which hard requiring it will be removed.

If you are still using Nepomuk you can switch to Baloo by globally
enable semantic-desktop and disabling nepomuk use flag in
/etc/portage/make.conf or using one of the kde desktop profiles.

[1] https://www.kde.org/announcements/4.13/
[2] https://bugs.gentoo.org/buglist.cgi?quicksearch=virtuoso
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAABCgBmBQJVyjeuXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vv+AQAMkio+WhdU+gE3rDNdKuRts4
aXafLqE8pIi+kcURGmsuWquc9hv90qcRgYdN7O12jIRHA9YLhsJCa8tbvDw9cP3r
17qG1FBwAE1qDDhWOAeMN+LovL5qnRnZNN52LSSbpFbCp7gzSwSGp+gRsNg3VYVW
LtwwYUm22DafFIfWAgk0ie/2H3JdTaJv/Ob++ZE6aQjlnLplQe9n0fGYmrp3EV8Y
gumVD3tH7327Ic2vexxvy/sWcPgbY4UeNXQKxlYkIpwcFzm/bjofqFHrq1xH5Dm5
arxMb56M98U5oVtrWve1+7TVDbWsOfOEjaEliAuel7QjS6aAMlQHoWhpn1maFCZX
vpTVW6JS0o+GbTg39+oGxQ/x6WCuNUW/kf3Y4SWxYygL61nrf/lK7EyBKefF0IZd
G+HDFXkMff2WXE/bp8GZRoGz5UCpWaEqx7blhNNQRTI8AXFQpMPdLJGpkIiepRIl
1FRCNeZ5GMlXjszsTxyU6YomYHqK+nalV2olcb1mu8u8DuEMdFWfY9ckQtMYQJ1i
9bxAGtZuQMiEGBp0PJ4JxBgpnRYhsQyry6MCCdBN7vEeb0Gwd/i3baG2xb8FNIEw
TRHYpD1NlaPoF8L7x2qn9eNbJSgM0d/y5y0ZVWnUes/yczBZEEHUfL/S8o5cX3bb
1PVTIWOsEtz0mzFI5Mfy
=6hti
-END PGP SIGNATURE-


Re: [gentoo-dev] Re: RFC: News item about Nepomuk removal

2015-08-11 Thread Johannes Huber
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Am 09.08.2015 um 05:01 schrieb Duncan:
 Johannes Huber posted on Sat, 08 Aug 2015 13:28:08 +0200 as
 excerpted:
 
 Title: Nepomuk removal
 
 Looks good here, and the title's nice and short too. =:^)
 

Thanks for positive feedback.

Greetings
- -- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJVyjnsXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy
OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vJ6MQAK7lt/OdbDzTZLmyPdbQ376K
8QcvNF2dUtJa/nSHzlKxk1D+AEI9PfP6VQE2tkrk5uIEtr+KVfP91ZO8QCUeXUZT
wapWr4AldPaSxK6cwzW9/oHm0Ux4MU4VQKk4bgjR6ImjxDhYwJxc8OHosPzbviY1
/ABJbLIfj3Hp1XY1leSoY20rEBYmy1yRCkMPjVz7pCGEH1697sQIkmv5xBCaI4SA
Hb0AwpuQXzYyW4DIevZZH2PMyMj9WBVmjcg7VdQexf6JOySljit3Ws2tdLdHaUHu
Kz4Bm98h1KX3XnqUwnWIVhuAzvUR06C7e6Cm4M92PRX1Oyp5+W2HscAPGHLZEHCs
S7Y33ZSHwOU5EqysFm43fplLZxSfGy9+wysHBztjueb0qAjNYBlidFdMhv3ab0PB
JwPYzR5IdTuMk032RZKxjksS8yJlJazgL9SmfxVucK9/o9S46g5y86JgG9Ll+tln
sDXETQot5wPhN+wxniNTBSzR89paQARtFbEufrn53ITu2hwL3Log0iU1Poie0zZX
EADTyuXC6sLhrDwGZQZOH+OApL1LH6QM53chrpUCfpBuh08qgINo498wdB90/cdG
ctLUyofX71H+7rNxi5qt7kiFyjkF5aI2/gAktlVQJpFEfxnCZWHJLEIFLTYvSnnv
wOTt0X7ct7h4Mer8eOpU
=HwoP
-END PGP SIGNATURE-



Re: [gentoo-dev] golang-vcs.eclass: remove the EGO_SRC variable

2015-08-11 Thread William Hubbs
All,

I found something in this patch which I have fixed locally. It is just a
replace on a couple of lines, so I'll explain what it is here rather
than reposting the patch.

Every occurance of '%/*' in the patch should be '%/...' instead.

William



signature.asc
Description: Digital signature


Re: [gentoo-portage-dev] [PATCH] egencache: Always output EAPI=0 in cache entries

2015-08-11 Thread Zac Medico
On 08/11/2015 10:38 AM, Michał Górny wrote:
 Remove the code skipping EAPI=0 output in cache entries. There is really
 no reason to treat EAPI=0 specially here, and this makes the output more
 consistent.
 ---
  bin/egencache | 2 --
  1 file changed, 2 deletions(-)
 
 diff --git a/bin/egencache b/bin/egencache
 index 6075ccf..5c00248 100755
 --- a/bin/egencache
 +++ b/bin/egencache
 @@ -297,8 +297,6 @@ class GenCache(object):
   # EAPI from _parse_eapi_ebuild_head, we don't write cache
   # entries for unsupported EAPIs.
   if metadata is not None and eapi_supported:
 - if metadata.get('EAPI') == '0':
 - del metadata['EAPI']
   for trg_cache in self._trg_caches:
   self._write_cache(trg_cache,
   cpv, repo_path, metadata, ebuild_hash)
 

LTGM.
-- 
Thanks,
Zac



Re: [gentoo-dev] [PATCH repositories.dtd] Support multiple owner/ elements

2015-08-11 Thread Mike Gilbert
On Tue, Aug 11, 2015 at 10:16 AM, Michał Górny mgo...@gentoo.org wrote:
 Hello,

 A quick patch for review. It changes the DTD for repositories.xml to
 support multiple owner/ tags. We have at least one repository with
 more than one owner, and I don't really see creating aliases for our
 users just to support that. Any comments?

Sounds reasonable, but please make sure the tools (layman) can handle
it properly.



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Alexis Ballier
On Tue, 11 Aug 2015 18:03:54 +0200
hasufell hasuf...@gentoo.org wrote:

 On 08/11/2015 05:21 PM, Alexis Ballier wrote:
  
  Big changes that that go in feature branches and are merged in one
  pass are, from my experience, way too much prone to errors. Did
  anyone ever try to review a merge commit?
  
 
 You will run repoman (and probably other pkgcore based checks) before
 you push that merge. That is for sure.


passing repoman, or any static checker, is definitely a very small
subset of what is needed to be good for gentoo-x86

 The only problem that can arise there is that we don't roll our
 versions via branches, but via filenames. That means you may merge
 correctly, but in master there was already a newer version of
 app-misc/foo which now lacks the multilib migration (which isn't a
 tree breaker, since stuff still repomanchecks).
 
 We could probably come up with some magic git/bash lines that help
 with that. As in: not just detect merge-conflicts, but also soft
 conflicts in the sense that someone else touched the same
 ebuild-directory as you in between.
 
 NixOS for example has (probably not only for that reason) not any
 version based filenames, but they roll release-channels via branches.

After fixing all these sorts of conflicts, I hope you test things
thouroughly, again, after the merge. In the end, it's shorter and
simpler to stop and think at the beginning on how to split your work in
small commits without branching.



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Daniel Campbell (zlg)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/11/2015 03:41 AM, Sergey Popov wrote:
 I'd suggest to make a QA team meeting to override this policies
 with more correct and rationale.
 
 Qt team members are greatly appreciated on this meeting. Even more,
 i think that we should not take any decision on this without at
 least Qt team lead(or half of Qt team devs)
 
 So, let's arrange some time and talk about this, cause it is
 really confusing. Qt team point is understandable, but it's still
 wrong. Let's make some consensus here.
 
 02.08.2015 19:34, Ben de Groot пишет:
 Recently some team members of the Qt project have adopted these
 ebuild policies:
 https://wiki.gentoo.org/wiki/Project:Qt/Policies
 
 I have an issue with the policy adopted under Requires one of
 two Qt versions. In my opinion, in the case where a package
 offers a choice between qt4 or qt5, we should express this in
 explicit useflags and a REQUIRED_USE=^^ ( qt4 qt5 ). This
 offers the user the clearest choice.
 
 Other developers state that users are not interested in such 
 implementation details, or that forced choice through
 REQUIRED_USE is too much of a hassle. This results in current
 ebuilds such as quassel to not make it clear that qt4 is an
 option.
 
 This goes against the principle of least surprise, as well as
 against QA recommendations. I would like to hear specifically
 from QA about how we should proceed, but comments from the wider
 developer community are also welcome.
 
 -- Cheers,
 
 Ben | yngwin Gentoo developer
 
 
 
I'm interested in this meeting as well, as maintainer of a package
that can be built with one of two toolkit versions. At the moment, I'm
using REQUIRED_USE with a preference preset for users that don't care,
but it does cause a problem when both flags are set (so it's something
I'd like to fix). I'd like to be part of the conversation if you don't
mind.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVykQPAAoJEAEkDpRQOeFwVAgP+wYqVva9YHWmUOwC2dyrUFhx
EjnPHBRaAsd6vOdoKKoFbO2c4wMhcoXb2C9pgLDw4O+eB2Q7JE3iMiiG/vAwGGtN
10meoAjvFV+DxpB7EYiHNj8NtlKq8PAncHusu6H/eP7YwdS37ruO4E89nBbXzxjU
JQru2bxL6Jf7m/LuI5lihdU6fwe1GrsDz0fCaeZ/49zBE8EPY1PjDbV8G8vHq/S6
UAgGXmFbzN8lPXfgBgnaD4O6So+WrhILUeTy4CVUQu0599W4UFmLqOmupeRHD0SM
wHjtJ/0gW+Wfb7VbuQsfrmNYuu0Fh/Wx15qs62/8YcgIOxb5YI31cefPa7e3HZbm
RQ52JC16Pl7VxPEsf5jhcQ6+QCpdOi/jH7B72JQiSgmtLF9N6j4kcr8XGtJB/HLy
PlJES1865ugS8LWpMiJCCwGyO8o/lOi4scbumw+XxjWj43Z93d66wGK84Yf2goAL
VBVA0JjzrJ46EIrBbqOPECMZZvJjeq4t28V3DHAdLPZmxhvLQjIjEqb8wywR5USa
NJ4kDgP5H85udznBk7JWapFu+ipphFm8uzKt6nqCeAfVc/y3n4rLZ9aUDCBVKodv
lzr652TmUw2sBvmhM6oRqsGZuMg6t0peBOOTFjTMJl+WYG+eUybvsWk9RQ9HQpuW
aqpPa6GiLL9Gbx8JTX8F
=JOKI
-END PGP SIGNATURE-



Re: [gentoo-dev] Developer branches on proj/gentoo

2015-08-11 Thread Alexis Ballier
On Tue, 11 Aug 2015 11:51:14 -0400
Ian Stakenvicius a...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 11/08/15 11:21 AM, Alexis Ballier wrote:
  On Tue, 11 Aug 2015 11:11:43 -0400 Ian Stakenvicius
  a...@gentoo.org wrote:
  
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
  
  On 11/08/15 10:01 AM, Michał Górny wrote:
  Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement 
  monsie...@gentoo.org napisał(a):
  
  Hi there
  
  According to 
  https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
 
 
 
  
 there may be developer-specific, task-specific, project-specific
  branch es
  etc. As far as I understand, it means I can go and create
  my own branch on the main repository and push it and it
  gets spread all over the place. Is that correct?
  
  Could someone explain to me the rationale behind this
  decision?
  
  Truth to be told, I kinda dislike the fact any developer
  can do this.
  
  As long as it's used with caution, I don't see a problem. Of
  course it would be bad if everyone pushed branches for any
  minor change. However, if there is a long-term work going on
  a branch, I don't see a problem with keeping it public.
  
  
  Examples in particular I can think of for something like this
  being useful would be for, say, major EAPI-bump-related
  feature implementations (ie, EAPI5 and
  slot-operators/subslots), or major across-tree impementation
  changes like what we saw with the multilib-eclass porting.
  
  These are large projects touching most if not all ebuilds, that
  a great many developers would or should be involved in.
  Something like this could be done in a separately hosted repo
  instead of in the main gentoo repo, but then all developers
  would need to subscribe to this other repo, while having it in
  a branch in the main one i think would make it easier for
  everyone to get involved once they're ready, and would still
  allow the changes to stay out of the master branch until the
  project is ready to launch.
  
  
  For me, this is actually a reason to prohibit it :)
  
  EAPI bumps should be done package by package, not at a major
  scale: otherwise, let's just scrap EAPI entirely and update the
  API as we see fit with p.masked package managers :)
 
 Not EAPI bumps, but implementation of major new features as a result
 of the new EAPI.  Most EAPI changes generally are beneficial to
 particular ebuilds, but some (such as slot-operators and subslots)
 really needed to be implemented across a great many packages (and
 eclasses too at times).  We did it with overlays and patches via
 b.g.o and slowly things migrated, but I think it would have gone a
 lot faster if all developers had quick and easy access to a branch.


I'm glad this wasn't done that way actually. When subslots appeared,
there was a serious tendency to use them in a fashion that caused
useless rebuilds most of the time. With time, and discussions on some
specific cases, saner practices were adopted.


  multilib eclasses conversions should also be done one by one to
  be done properly (otherwise using multilib-portage is probably a
  better idea) and each conversion touches one package (two if you
  count emul-*).
 
 But they don't just touch one package -- you pretty much needed to
 do a full deptree at a time.

Sorry, but no. There was an order in which you could do it, but that's
all.

  We worked around it with a rather
 messy 'delete all files in emul-* that collide with the
 multilib-built packages currently available' plus a convoluted set
 of ||() deps wrapping each emul and the individual alternative
 atoms.  And even then it was still a mess to try and actually use it
 on end-user systems due to various conflicts.

We split up the huge task into small and manageable ones, yes. I see it
as a clear benefit and I'd even say this is one of the major reasons
multilib-portage didn't make it. This also allowed to iteratively
improve the multilib approach with the experience gained from
converting small parts while getting feedback from those interested.

I don't know what conflicts you're talking about, but I haven't
seen any that was not due to a poor conversion.

  Big changes that that go in feature branches and are merged in
  one pass are, from my experience, way too much prone to errors.
  Did anyone ever try to review a merge commit?
 
 This makes sense, yes; the merge back to the main tree could very
 well be more difficult than it's worth, however if the branch is
 available to all, then the migration into the main tree could be
 done piecemeal in batches too rather than in one huge swash.
 
 The point is, I think it'd be easier and faster to implement these
 major treewide projects (and easier to verify too) if the work could
 be done in a branch available to all, rather than in what would
 effectively be an overlay someplace external.

You seem to like pull requests and pre-commit reviews :)
I believe it is optimistic to say that because there is a 

Re: [gentoo-dev] Managing etc/* in an embbeded system

2015-08-11 Thread Zac Medico
On 08/11/2015 11:11 AM, Joakim Tjernlund wrote:
 On Tue, 2015-08-11 at 10:55 -0700, Zac Medico wrote:
 On 08/11/2015 10:48 AM, Joakim Tjernlund wrote:
 On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote:
 On 07/23/2015 12:46 AM, Joakim Tjernlund wrote:
 On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote:

 Sent from an iPhone, sorry for the HTML...

 On Jul 22, 2015, at 5:38 PM, Rich Freeman ri...@gentoo.org wrote:

 On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund
 joakim.tjernl...@transmode.se wrote:

 There can not be any manual merges after an SW update here.

 I started to look at INSTALL_MASK, what if I set INSTALL_MASK
 to point to all conf files I want to manage myself.
 Then /etc/inittab etc. will not be touched when updating init

 This sounds like overkill.

 If you've already installed a custom /etc/inittab, then when you
 emerge init, it won't overwrite your inittab even if you don't change
 anything in your portage config.  emerge won't touch any files in /etc
 unless they don't already exist.  


 ..AND have been modified.  IIRC if the hash of the config files match 
 what they were when the 
 package 
 was 
 previously emerged, then the files are updated aren't they?

 I expect that this is fine in the situation described, but it's worth 
 knowing that a config file 
 left 
 unmodified may be replaced with a different vanilla config file later on.

 Sure, but what if I need to change a conf file in an installed system? Or 
 rebuild a a system from 
 scratch?
 The user only runs a one SW update command to update an installed system 
 in the field and cannot edit 
 a 
 bunch
 of files too. Especially when there are hundreds of systems sitting in 
 remote locations.

 If you use the profile-bashrcs profile-formats setting [1], then your
 profiles can use package.bashrc to define post_src_install and/or
 INSTALL_MASK to remove unwanted config files from upstream packages.
 Then you can easily replace the upstream config files with config files
 installed by your own configurations installed by your own ebuilds.

 Finally getting back to this after lots of distractions.
 I cannot get profile-formats  = profile-bashrcs to work.
 I have in metadata/layout.conf:
   masters = gentoo
   profile-formats = portage-2 profile-bashrcs 
 then in profiles/tmv3-target-overlay/profile.bashrc:
   INSTALL_MASK=
 Doing portageq envvar INSTALL_MASK just yields an empty line
 I guess I am missing something here?



 See the man portage for profile-bashrcs details. It uses
 package.bashrc rather than profile.bashrc, so that explains why it's not
 working for you.
 
 hmm, I figured I could use profile.bashrc to set stuff for all pkgs?

You can, but package.bashrc might lead to better organization, since it
allows you to use package atoms to specify which bashrc file(s) will be
sourced by a particular ebuild.

 In any case I tried package.bashrc but portageq envvar INSTALL_MASK does not 
 print
 anything either. It occurred to me that portageq envvar is not the right tool 
 see
 variable defined in bash scripts? Is there some other tools I can use?

There's no tool for this, but you can put an elog message in the bashrc
to provide an indication that it's working as expected.
-- 
Thanks,
Zac



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Gregory Woodbury
Is a possible solution something like an eselect module to indicate
the preferred
interface kit? It could default to any package that is available with
a sequential
set of preferred order.
Then ebuild would consult the eselect module, and users who care can
select the kit they want, and users who don't care/know get the default.


Just a nickel's worth opinion. Due to inflation it isn't 2 cents any more.
-- 
G.Wolfe Woodbury
redwo...@gmail.com



Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Rich Freeman
On Tue, Aug 11, 2015 at 3:13 PM, Gregory Woodbury redwo...@gmail.com wrote:
 Is a possible solution something like an eselect module to indicate
 the preferred
 interface kit? It could default to any package that is available with
 a sequential
 set of preferred order.
 Then ebuild would consult the eselect module, and users who care can
 select the kit they want, and users who don't care/know get the default.

That still neglects the case where a user just wanted to say use the
best version of qt for any particular package, which I'd argue is
probably the most common use case.  It may not make sense to have one
global preference system-wide, and managing it per-package is painful.
It really does make sense to leave it up to the maintainer, while
still letting people either turn off qt entirely if they'd prefer to
do so, or override the default implementation when they really want
to.

There is always requiring any package that supports qt to enable
either qt4 or qt5 by default, so the typical user who wants qt does
nothing, the typical user who doesn't want qt sets USE=-qt4 -qt5,
and then anybody who wants to override things per-package can do so.
That is simple to define in ebuilds, and you can set REQUIRED_USE to
prevent them both from being set.  It just means having qt support by
default all over the tree and forcing people who don't want it to
explicitly turn it off.  That is simple to do at least, but not really
in keeping with the general spirit of the base profile being a minimal
one.  And it would still be difficult to do anything at the profile
level if it were appropriate to do so.

-- 
Rich



Re: [gentoo-portage-dev] [PATCH] egencache: Always output EAPI=0 in cache entries

2015-08-11 Thread Brian Dolbec
On Tue, 11 Aug 2015 10:54:10 -0700
Zac Medico zmed...@gentoo.org wrote:

 On 08/11/2015 10:38 AM, Michał Górny wrote:
  Remove the code skipping EAPI=0 output in cache entries. There is
  really no reason to treat EAPI=0 specially here, and this makes the
  output more consistent.
  ---
   bin/egencache | 2 --
   1 file changed, 2 deletions(-)
  
  diff --git a/bin/egencache b/bin/egencache
  index 6075ccf..5c00248 100755
  --- a/bin/egencache
  +++ b/bin/egencache
  @@ -297,8 +297,6 @@ class GenCache(object):
  # EAPI from _parse_eapi_ebuild_head, we don't
  write cache # entries for unsupported EAPIs.
  if metadata is not None and eapi_supported:
  -   if metadata.get('EAPI') == '0':
  -   del metadata['EAPI']
  for trg_cache in self._trg_caches:
  self._write_cache(trg_cache,
  cpv, repo_path, metadata,
  ebuild_hash)
  
 
 LTGM.

yeah, merge please

-- 
Brian Dolbec dolsen




Re: [gentoo-dev] golang-vcs.eclass: remove the EGO_SRC variable

2015-08-11 Thread William Hubbs
On Tue, Aug 11, 2015 at 01:22:40PM -0500, William Hubbs wrote:
 All,
 
 I found something in this patch which I have fixed locally. It is just a
 replace on a couple of lines, so I'll explain what it is here rather
 than reposting the patch.
 
 Every occurance of '%/*' in the patch should be '%/...' instead.
 
 William
 

All,

this has been committed along with an identical fix to
golang-vcs-snapshot.eclass.

These were pretty high priority, so I hope it is ok that they were
committed about twenty-four hours after the post here.

William



signature.asc
Description: Digital signature


  1   2   >