[gentoo-dev] Re: how to add a new package with git?

[Ryan Hill]

On Thu, 3 Sep 2015 23:07:37 +0600 (NOVT)
gro...@gentoo.org wrote:

> WARNING: previous mirror push to host 'ituri.gentoo.org' failed, status 
> is:
> 2015-09-03.16:57:50 962 ssh: connect to host ituri.gentoo.org port 
> 22: Connection timed out
> 2015-09-03.16:57:50 962 fatal: Could not read from remote 
> repository.
> 2015-09-03.16:57:50 962
> 2015-09-03.16:57:50 962 Please make sure you have the correct 
> access rights
> 2015-09-03.16:57:50 962 and the repository exists.

Sorry if this has been discussed elsewhere, but what is this warning?  A couple
days ago I started seeing it every time I sync even though I've yet to push
anything to git.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpc6afeYWfel.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/09/15 14:53, Rich Freeman wrote:
> I was suggesting that somebody talk to the portage developers about
> how they intend to implement EAPI6
We don't know. But our tardiness should not retard the development of
other package managers.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJV7UH8AAoJENQqWdRUGk8BY80P/j2l8HH/FcicnF9QvwhUzjUA
bjrCPaFBArPmGIGqCaRjAB6OvrD7SOsdOG1GcQNJ7OSxxx3sV8Vo8Qc4PJ6R43U+
lN5Vxq/dEhJwGpWFOKFdxFGnSJK1wbFlf1l2Y5MkyNd8KBxhTLxh8vWHyIgL3mLC
9L6fteBdhbyUQaAjtKJiVRm1lMKrfgZUu/8zL+pa3RDolErgD+sfNF21AGt8csjn
GwRy/MkQGYKE73Uy+bhtsQPtRl5fChDvbA/hM6mTC3uODY/bEzwNFM0P8sk8L0uj
HkQqErGAWRROTnKH3LQJ3kwO1Lxqr8rosi7Em0zhzKpimSDgx/XlqGLyNaV1bgD7
IuKG/ww5bBgrJPUkhdRFhZl1LA9wFD81koOpbL+zQYi42Q50412lpkNrKS3+5YpK
K9DN+zv/63Hw7GnW6v9MWi5X0+UJlGWKtsTNhvyGy4FV321gRXn3GC/GNGKEbDCB
YlOzmaQoID+22R8P3liBj7CsWRE1i/3EJwaPsFxrixqrGVkwJyBV5kGqgVNU9Uhk
RYWArfpQ6eI92oL90Xpy+sY+aWduhR3O7zYPj4dDYoVMOwFfsFWi/vMqjxZsc3FT
g0g+fC9SEhUeEUXlQhQORrlkVJnEhSXmZQcmXKX6MIlh1jxy67Liby8XSnlQNarj
AH6YTaEkikCmEfqb+nJA
=8vHo
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: how to add a new package with git?

[Justin (jlec)]

On 07/09/15 08:40, Ryan Hill wrote:
> On Thu, 3 Sep 2015 23:07:37 +0600 (NOVT)
> gro...@gentoo.org wrote:
> 
>> WARNING: previous mirror push to host 'ituri.gentoo.org' failed, status 
>> is:
>> 2015-09-03.16:57:50 962 ssh: connect to host ituri.gentoo.org port 
>> 22: Connection timed out
>> 2015-09-03.16:57:50 962 fatal: Could not read from remote 
>> repository.
>> 2015-09-03.16:57:50 962
>> 2015-09-03.16:57:50 962 Please make sure you have the correct 
>> access rights
>> 2015-09-03.16:57:50 962 and the repository exists.
> 
> Sorry if this has been discussed elsewhere, but what is this warning?  A 
> couple
> days ago I started seeing it every time I sync even though I've yet to push
> anything to git.
> 
> 
This comes form the mirroring code of gitolite. If the remote box, where the
repo should be mirrored to isn't up you get this warning.

Justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] <>-DEPENDS

[Jauhien Piatlicki]

On 09/07/2015 02:35 PM, Marc Schiffbauer wrote:
> Hi,
> 
> 
> I'd like to propose a new kind of DEPEND syntax: <>
> 
> This would mean "Any version but the one specified" and is usefull when 
> you have a dependency on another package but a single version of it is 
> not compatible for example.

+1 from me. But how will this affect our already not very fast and
correct depsolver?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] <>-DEPENDS

[Ulrich Mueller]

> On Mon, 7 Sep 2015, Marc Schiffbauer wrote:

> I'd like to propose a new kind of DEPEND syntax: <>

> This would mean "Any version but the one specified" and is usefull
> when you have a dependency on another package but a single version
> of it is not compatible for example.

This doesn't look like a feature that would be needed very often.
Since "<>cat/foo-1" is equivalent to "|| ( >cat/foo-1  [...]

> What do you think and would is the proper way to suggest this for a
> new EAPI? A new bug? On what?

It should be filed as a bug (assigned to "Gentoo Hosted Projects" /
"PMS/EAPI").

Your proposal looks like a special case of bug 4315, though.

Ulrich


pgp366J7LYFbR.pgp
Description: PGP signature

Re: [gentoo-dev] <>-DEPENDS

[Marc Schiffbauer]

* Ulrich Mueller schrieb am 07.09.15 um 15:07 Uhr:
> > On Mon, 7 Sep 2015, Marc Schiffbauer wrote:
> 
> > I'd like to propose a new kind of DEPEND syntax: <>
> 
> > This would mean "Any version but the one specified" and is usefull
> > when you have a dependency on another package but a single version
> > of it is not compatible for example.
> 
> This doesn't look like a feature that would be needed very often.
> Since "<>cat/foo-1" is equivalent to "|| ( >cat/foo-1  I wonder if it's worth the effort.

Valid point. I am unsure. If it it would make the resolver noticable 
slower, I'd say now. Otherwise propably yes.

> 
> > [...]
> 
> > What do you think and would is the proper way to suggest this for a
> > new EAPI? A new bug? On what?
> 
> It should be filed as a bug (assigned to "Gentoo Hosted Projects" /
> "PMS/EAPI").

Thanks.

> 
> Your proposal looks like a special case of bug 4315, though.

Which is solved using || ( >foo 

signature.asc
Description: Digital signature

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-09-06 23:59 UTC

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/06/2015 05:10 PM, Dale wrote:
> Robin H. Johnson wrote:
>> The attached list notes all of the packages that were added or
>> removed from the tree, for the week ending 2015-09-06 23:59 UTC.
>> 
>> Removals:
>> 
>> Additions:
>> 
>> -- Robin Hugh Johnson Gentoo Linux Developer E-Mail :
>> robb...@gentoo.org GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E
>> B27B 944E 3488 4E85
> 
> 
> U.  You sure?
> 
> Dale
> 
> :-)  :-)
> 
IIRC Robin's spoke with multiple other devs and a script has been
written to work on git. It just hasn't had everything ironed out yet.
Most notable being the cronjob that does the e-mail, based on what we
see. :) Give it some time.

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

iQIcBAEBCAAGBQJV7bRUAAoJEAEkDpRQOeFw3jEP+wY9IxYOTeDeHvZqXDXuTNld
8YMMolssV88e3h6d0riFXIu91SgTvldYjbagWZjxiQ4ITtRihopDSPND7cicSyTd
GV5CqJZxkFxzmzjjLzz4K9f9hoFm754rzcU3BAFXUY1/ugAF3TGOIGaWGT7XOK+n
/l5E7ZQmEA0khrjxFloskF5Cy0bSEgo0tm4+UWekx5ihnoLJCpPkYHNCYz0KWRg8
jhkggu9/DEGvy+DGguvj777ibrAYrqE9iF27FcyXCm4VTnvXbOf7e34N2Aoq7FSL
qpBhuOa8tlaMgqrF55LcfUCz7cpgeXTpi0yan90y6o2jweivE7yClES9SFNaliwq
gpikjzWbuVlSnoG8GusbYULnA6yL7apa+tAEEJXWx895noq7J61ZTh7cDAii7LWN
ZaTFElQML/D01vUz//uarjGNpg3I09U7dtwnPWv8wXp9MXFf2atDsI5XwD5cTThu
iOilWUC6RNLct7rDHvNeIlg+VIRIQgZ6hKlvxReVwWtQiiU0hGIkHwM9/HxUDcbv
RNE1zHkSgNHBxr0kzSAp6ndwIXCIhvKgF7qgj3EKKULIAOm9AbF7PGzDkETmlcDf
9i9z2dNvm9q1Bh4c4UzkuLMfcPenQHbWsssoM8buSf+v5by7BYShuPL9J1O6INoy
FEQoBcHONwqkh5h/SD4G
=B5H9
-END PGP SIGNATURE-

Re: [gentoo-dev] <>-DEPENDS

[Marc Schiffbauer]

* Kent Fredric schrieb am 07.09.15 um 15:18 Uhr:
> On 8 September 2015 at 00:35, Marc Schiffbauer  wrote:
> > What do you think and would is the proper way to suggest this for a new
> > EAPI?  A new bug? On what
> 
> 
> My opposition would be I figure its more likely you want a range of
> exclusion, not a single version.
> 
> EG: you don't really want !=dev-python/paramiko-1.13.0 , you want
> !=dev-python/paramiko1.13.0{,-r{0..999}} or something.

Erm. +1 
You are of cause right. So you just discovered a potential bug in my 
ebuild :-P

> 
> But distinguishing between "Just this exact version" and "This range" is hard.
> 
> Does <> Imply "and any -rversion" ?
> 
> Does <> imply "and any sub-version" like ~ does ?

Well, than I might change my mind and prefer != over <> as it would be 
more flexible:

!=foo/bar-1 => exact version
!~foo/bar-1 => that version and any revision

And as the cherry on the cake theere could be

<> ( foo/bar-1 foo/bar-5 )

To express real ranges (that would include revisions)

-Marc

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] <>-DEPENDS

[Marc Schiffbauer]

* Ian Stakenvicius schrieb am 07.09.15 um 16:41 Uhr:
> Why not just:
> 
> DEPEND="
> dev-python/paramiko
> !~dev-python/paramiko-1.13.0
> "
> 
> Depend on the package but block the individual atom(s) that don't work?

I like it. At least with the current possibilities. I was not aware that 
"!~" is already a valid blocker.


> 
> Given that there will be *very few* valid use cases for this type of
> syntax I don't know if it's such a good idea to add it.  I expect
> adding this new syntax would be more likely to cause issues via
> improper usage than it would add a benefit or fill any massively
> pressing need...

Depending on how it is implemented, I think it would be intuitive to 
use. I'd find having "=" vs. "!=" and "~" vs. "!~" straight forward.

You are of cource right that there is no "massively pressing need" atm.  
But that was not always a reason for a new feature ;)

-Marc

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] dev-rust category

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/07/2015 05:56 AM, Jauhien Piatlicki wrote:
> Hi,
> 
> On 09/07/2015 07:28 AM, Daniel Campbell wrote:
>> On 09/06/2015 02:00 PM, Jauhien Piatlicki wrote:
>>> Hi,
>> 
>>> On 09/05/2015 11:23 PM, Daniel Campbell wrote:
 On 09/05/2015 01:04 PM, Matthew Thode wrote:
>> 
> I think cargo should probably go in dev-util with other
> rust libraries and programs going into dev-rust as needed,
> but that's just me :D
 
 Agreed. dev-util until it grows in size (isn't the 
 recommendation 5-10+ pkgs?), then dev-rust. Despite the
 package moves being somewhat cumbersome, it makes more sense
 to do it once it's clear Rust has an ecosystem going rather
 than catch stragglers in its infancy.
 
>> 
>>> Ok, looks quite logical for me. So the next question. I
>>> remember portage had some problems with moving packages. Would
>>> it work if I'll move dev-rust/cargo to dev-util/cargo in our
>>> overlay now. And later when rust infrastructure grows move it
>>> in the main tree back to dev-rust? Or will it break something?
>> 
>>> -- Jauhien
>> 
>> 
>> Now that we're on git, I don't see why a quick `git mv
>> old-cat/foo new-cat/foo` wouldn't get the job done. Don't quote
>> me on it, but my guess is it would work fine. Then make sure the
>> profile data gets updated by updating the relevant file(s).
>> 
>> If you're keeping it in an overlay until you think it's ready for
>> the Gentoo repo, you may as well keep it whatever you want since
>> it's not bound by Gentoo policy. I would start with dev-util,
>> even in tree, and migrate to dev-rust when it reaches critical
>> mass on packages (I'd say at least ten).
>> 
>> 
> 
> I'm speaking not about git, but about portage move [1] (see Moving 
> ebuilds there). This is unrelated to version control.
> 
> [1] https://devmanual.gentoo.org/ebuild-maintenance/index.html
> 
Right, that's what the 'updating the relevant file(s)' part was about.
:) If you're the only developer working on it, I don't see why it
would be a problem. Of course, other developers who are more
experienced in these situations should probably show up and say
something, but based on what you've told me and the processes Gentoo
has in place, it should be okay.

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

iQIcBAEBCAAGBQJV7bGLAAoJEAEkDpRQOeFwpJgQANOst5gnRN5fwETnrR42bQYD
aqZn4+ZAF8tHN45XUsa9RzCY1w9YO1GBxUPhkhUBIesJPB326gy8pc9TL/g2VNfF
QcWEfh0loiqE5pAE1IjAeLROR01AEfADIivoBKJ2kTr2ziztxxjIab30UY1WfaxX
kvXY5bEi9AQPW28e4cdNBX8JBJqn+V31allS+AnVZApd6+FPU/UfjZ5TF9JC9w04
qS6gd0fRBWXSb8cZoufJkgiDttlleSW89AxYJKTOAUCDO8opfVr/kPB5UY22Jftd
LdXl/5U0jAlt5OEthSZvDBB6cJ0ydI5DmtjMG93DXQcxXTfMneI45H6UAw0SXdt6
Ss/Uy2fHLojSP07rcWhUt7RNaXNUhEbhnplu4Gf8iHRymPIbUTS8MaM37nCDvouV
GE2puyUFvn11l14JIcJLKT4zfEd9+9pM2m8IhrCjF86c4KRfUXJsQzZmavmAcUiY
Fn7oMv4/WaQa+V4y6fQzpedBBoeGNpxmunOYOKvlx2puwd3UJGOn6szCL4vLKQW8
dxuNIiTSc1aIUHKoaIKqeZ4fwNQFcAhnxuoyd5Z4zZ1zKE5VFVBCAV+gadzH3w2K
x40my64c4KxUy+1gKB6yvXAU3KP5HqIuoM9dcUJqLmoWgyzWk9gO5k2P30IKABdM
74Ks5PKTyvNF5T8hxpt/
=I0es
-END PGP SIGNATURE-

Re: [gentoo-dev] <>-DEPENDS

[Marc Schiffbauer]

* Michał Górny schrieb am 07.09.15 um 17:16 Uhr:
> Dnia 2015-09-07, o godz. 14:35:07
> Marc Schiffbauer  napisał(a):
> 
> > I'd like to propose a new kind of DEPEND syntax: <>
> > 
> > This would mean "Any version but the one specified" and is usefull when 
> > you have a dependency on another package but a single version of it is 
> > not compatible for example.
> > 
> > I currently have this case in app-backup/obnam which is not compatible 
> > to =dev-python/paramiko-1.13.0
> > 
> > In DEPEND I now have this:
> > 
> >   !=dev-python/paramiko-1.13.0
> >   || ( dev-python/paramiko-1.13.0 )
> > 
> > which does the trick, but I think much more straight forward would be:
> > 
> >   <>dev-python/paramiko-1.13.0
> > 
> > which would be the exact opposite of =dev-python/paramiko-1.13.0
> 
> What if you want to exclude two versions? This looks like an even worse
> case of the > + < -dep problem.
> 
> > An alternate syntax would be (but I'd prefer the former):
> > 
> >   !=dev-python/paramiko-1.13.0
> 
> This is a blocker syntax, so it's used already.

OK thanks. And I ignored that fact in one of my other mails. So I guess 
this ends up in: Never mind ;)



-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-09-06 23:59 UTC

[Dale]

Daniel Campbell wrote:
> On 09/06/2015 05:10 PM, Dale wrote:
> > Robin H. Johnson wrote:
> >> The attached list notes all of the packages that were added or
> >> removed from the tree, for the week ending 2015-09-06 23:59 UTC.
> >>
> >> Removals:
> >>
> >> Additions:
> >>
> >> -- Robin Hugh Johnson Gentoo Linux Developer E-Mail :
> >> robb...@gentoo.org GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E
> >> B27B 944E 3488 4E85
>
>
> > U.  You sure?
>
> > Dale
>
> > :-)  :-)
>
> IIRC Robin's spoke with multiple other devs and a script has been
> written to work on git. It just hasn't had everything ironed out yet.
> Most notable being the cronjob that does the e-mail, based on what we
> see. :) Give it some time.
>
>
>


I saw some of the posts here about it and I thought they fixed it but I
guess it was something else they fixed.  I'm sure they will get around
to it one day.  No big deal, just wanted to post to hopefully get the
attention of the person that does that sort of thing.  Just in case they
thought it was fixed but somehow it failed. 

Dale

:-)  :-) 

Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user

[Rich Freeman]

On Mon, Sep 7, 2015 at 3:51 AM, Alexander Berntsen  wrote:
>
> On 05/09/15 14:53, Rich Freeman wrote:
>> I was suggesting that somebody talk to the portage developers about
>> how they intend to implement EAPI6
> We don't know. But our tardiness should not retard the development of
> other package managers.
>

This wouldn't hold up developers of other package managers, just the
change to the eclass.  I wasn't suggesting waiting until EAPI6 was
implemented, or securing a 100% binding commitment from anybody.  I
was just suggesting that users might not like having two different
variables that end up doing the same thing, simply because nobody
bothered to talk to anybody else.

If you ask and there is no answer I wouldn't hold things up.

-- 
Rich

Re: [gentoo-dev] <>-DEPENDS

[Kent Fredric]

On 8 September 2015 at 00:35, Marc Schiffbauer  wrote:
> I currently have this case in app-backup/obnam which is not compatible
> to =dev-python/paramiko-1.13.0
>
> In DEPEND I now have this:
>
>   !=dev-python/paramiko-1.13.0
>   || ( dev-python/paramiko-1.13.0 )
>
> which does the trick, but I think much more straight forward would be:
>
>   <>dev-python/paramiko-1.13.0
>
> which would be the exact opposite of =dev-python/paramiko-1.13.0
>
> An alternate syntax would be (but I'd prefer the former):
>
>   !=dev-python/paramiko-1.13.0
>
> What do you think and would is the proper way to suggest this for a new
> EAPI?  A new bug? On what


My opposition would be I figure its more likely you want a range of
exclusion, not a single version.

EG: you don't really want !=dev-python/paramiko-1.13.0 , you want
!=dev-python/paramiko1.13.0{,-r{0..999}} or something.

But distinguishing between "Just this exact version" and "This range" is hard.

Does <> Imply "and any -rversion" ?

Does <> imply "and any sub-version" like ~ does ?


-- 
Kent

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

Re: [gentoo-dev] <>-DEPENDS

[Ian Stakenvicius]

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

> On Sep 7, 2015, at 8:35 AM, Marc Schiffbauer  wrote:
> 
> Hi,
> 
> 
> I'd like to propose a new kind of DEPEND syntax: <>
> 
> This would mean "Any version but the one specified" and is usefull when 
> you have a dependency on another package but a single version of it is 
> not compatible for example.
> 
> I currently have this case in app-backup/obnam which is not compatible 
> to =dev-python/paramiko-1.13.0
> 
> In DEPEND I now have this:
> 
>  !=dev-python/paramiko-1.13.0
>  || ( dev-python/paramiko-1.13.0 )
> 
> which does the trick, but I think much more straight forward would be:
> 
>  <>dev-python/paramiko-1.13.0
> 
> which would be the exact opposite of =dev-python/paramiko-1.13.0
> 
> An alternate syntax would be (but I'd prefer the former):
> 
>  !=dev-python/paramiko-1.13.0
> 
> What do you think and would is the proper way to suggest this for a new 
> EAPI?  A new bug? On what?
> 
> TIA
> -


Why not just:

DEPEND="
dev-python/paramiko
!~dev-python/paramiko-1.13.0
"

Depend on the package but block the individual atom(s) that don't work?

Given that there will be *very few* valid use cases for this type of syntax I 
don't know if it's such a good idea to add it.  I expect adding this new syntax 
would be more likely to cause issues via improper usage than it would add a 
benefit or fill any massively pressing need...

Re: [gentoo-dev] <>-DEPENDS

[Michał Górny]

Dnia 2015-09-07, o godz. 14:35:07
Marc Schiffbauer  napisał(a):

> I'd like to propose a new kind of DEPEND syntax: <>
> 
> This would mean "Any version but the one specified" and is usefull when 
> you have a dependency on another package but a single version of it is 
> not compatible for example.
> 
> I currently have this case in app-backup/obnam which is not compatible 
> to =dev-python/paramiko-1.13.0
> 
> In DEPEND I now have this:
> 
>   !=dev-python/paramiko-1.13.0
>   || ( dev-python/paramiko-1.13.0 )
> 
> which does the trick, but I think much more straight forward would be:
> 
>   <>dev-python/paramiko-1.13.0
> 
> which would be the exact opposite of =dev-python/paramiko-1.13.0

What if you want to exclude two versions? This looks like an even worse
case of the > + < -dep problem.

> An alternate syntax would be (but I'd prefer the former):
> 
>   !=dev-python/paramiko-1.13.0

This is a blocker syntax, so it's used already.

-- 
Best regards,
Michał Górny



pgpNVzbtKjHkl.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-09-06 23:59 UTC

[malc]

I updated the scripts and since I didn't find them in a relevant
infra-repo, posted them to a couple of other replies to earlier week's
versions of this, cc: Robin.
I've heard nothing. I have opened
https://bugs.gentoo.org/show_bug.cgi?id=559894 and attached them
there.

On Mon, Sep 7, 2015 at 5:27 PM, Dale  wrote:
> Daniel Campbell wrote:
>
> On 09/06/2015 05:10 PM, Dale wrote:
>> Robin H. Johnson wrote:
>>> The attached list notes all of the packages that were added or
>>> removed from the tree, for the week ending 2015-09-06 23:59 UTC.
>>>
>>> Removals:
>>>
>>> Additions:
>>>
>>> -- Robin Hugh Johnson Gentoo Linux Developer E-Mail :
>>> robb...@gentoo.org GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E
>>> B27B 944E 3488 4E85
>
>
>> U.  You sure?
>
>> Dale
>
>> :-)  :-)
>
> IIRC Robin's spoke with multiple other devs and a script has been
> written to work on git. It just hasn't had everything ironed out yet.
> Most notable being the cronjob that does the e-mail, based on what we
> see. :) Give it some time.
>
>>
>>
>
>
> I saw some of the posts here about it and I thought they fixed it but I
> guess it was something else they fixed.  I'm sure they will get around to it
> one day.  No big deal, just wanted to post to hopefully get the attention of
> the person that does that sort of thing.  Just in case they thought it was
> fixed but somehow it failed.
>
> Dale
>
> :-)  :-)

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-08-30 23:59 UTC

[malc]

Yup - nothing I can do about mailmap without commit access. On the
dates - I was just spitting out what git gave me... I've delved into
git help log => PRETTY FORMATS and changed it to use a unix timestamp
and reverted to the old (python default) format.
Updated script in https://bugs.gentoo.org/show_bug.cgi?id=559894

Output now looks like:

Removals:
dev-java/antenna2015-09-03 14:45:07  monsieurp
   b4215f4
dev-java/jjtraveler 2015-09-03 14:46:28  monsieurp
   0bda332
net-misc/netcf  2015-09-06 20:49:42  cardoe
   b32b14c

[gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2015-09-06 23:59 UTC

[Duncan]

Robin H. Johnson posted on Mon, 07 Sep 2015 23:54:36 + as excerpted:

> I've been travelling a lot the past month (Helsinki, LA, Seattle), and
> it's on my list of stuff to do (along with finalize and announce the
> migrated git history).

[grumble grumble, top posting, tho you just followed what you were 
replying to, but it still makes it all but impossible to quote proper 
context, so I only did one level deep]

This is definitely not a personal complaint as I know you're doing what 
you can and will get to it in due time, and I'm immensely grateful that 
we have you working on it at all and that the git switch did actually 
happen even if it seemed to be an instance of DukeNukem:Forever, but...

The above has me somewhat concerned.  Any time an individual has to make 
excuses for something as ultimately critical to an organization as 
finishing up the loose ends on the git switchover is to gentoo, the words 
"bus factor" loom large in my head.

Is it simply that while others can do it, you were the one who 
volunteered, as you could make at least enough time to get the basics 
squared away in a relatively immediate timeframe, and will do the rest 
later, but there's others who would have eventually (perhaps months, or 
even a year or two later) gotten to it were you to meet some misfortune, 
or is it really down to (singular) YOU, and there's reason to worry, not 
just because of that, but because of the inevitable overwork and burnout 
such a situation unfortunately tends to lead to?

IOW, is there something the council or foundation needs to do proactively 
here to ease a pressure point before something blows and it's reactive, 
or are there human backups in place and tested/ready-if-needed just as 
surely as are the server backups?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] <>-DEPENDS

[Kent Fredric]

On 8 September 2015 at 03:26, Marc Schiffbauer  wrote:
> And as the cherry on the cake theere could be
>
> <> ( foo/bar-1 foo/bar-5 )


I kinda tried suggesting a similar syntax, but then I realised it
couldn't work, because it implicitly says "none of these" but it
doesn't state any sort of "Pull something"

And then I wondered what:

<> ( foo/bar-1 foo/quux-1 )

would do and my head exploded with all the pain.

So as verbose as the current syntax may be, its very easy to design
something worse, so I figure it better not to do anything unless we're
sure we haven't made a mess of it.

=foo-bar/baz-(<4.9-r999,>5.0)

Or something, where "mixing the package atoms up is impossible", and
that way the planner could know that the versions applied to a single
requirement, instead of having to guess what it all means when it sees
3 specifications for the same package and going crazy with
backtracking.


-- 
Kent

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

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-09-06 23:59 UTC

[Robin H. Johnson]

I've been travelling a lot the past month (Helsinki, LA, Seattle), and
it's on my list of stuff to do (along with finalize and announce the
migrated git history).

On Mon, Sep 07, 2015 at 06:46:11PM +0100, malc wrote:
> I updated the scripts and since I didn't find them in a relevant
> infra-repo, posted them to a couple of other replies to earlier week's
> versions of this, cc: Robin.
> I've heard nothing. I have opened
> https://bugs.gentoo.org/show_bug.cgi?id=559894 and attached them
> there.
> 
> On Mon, Sep 7, 2015 at 5:27 PM, Dale  wrote:
> > Daniel Campbell wrote:
> >
> > On 09/06/2015 05:10 PM, Dale wrote:
> >> Robin H. Johnson wrote:
> >>> The attached list notes all of the packages that were added or
> >>> removed from the tree, for the week ending 2015-09-06 23:59 UTC.
> >>>
> >>> Removals:
> >>>
> >>> Additions:
> >>>
> >>> -- Robin Hugh Johnson Gentoo Linux Developer E-Mail :
> >>> robb...@gentoo.org GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E
> >>> B27B 944E 3488 4E85
> >
> >
> >> U.  You sure?
> >
> >> Dale
> >
> >> :-)  :-)
> >
> > IIRC Robin's spoke with multiple other devs and a script has been
> > written to work on git. It just hasn't had everything ironed out yet.
> > Most notable being the cronjob that does the e-mail, based on what we
> > see. :) Give it some time.
> >
> >>
> >>
> >
> >
> > I saw some of the posts here about it and I thought they fixed it but I
> > guess it was something else they fixed.  I'm sure they will get around to it
> > one day.  No big deal, just wanted to post to hopefully get the attention of
> > the person that does that sort of thing.  Just in case they thought it was
> > fixed but somehow it failed.
> >
> > Dale
> >
> > :-)  :-)
> 

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Alec Warner]

On Thu, Sep 3, 2015 at 4:28 AM, Kent Fredric  wrote:

> On 3 September 2015 at 07:17, Paweł Hajdan, Jr. 
> wrote:
> > Do you have specific examples?
>
>
> None that I can currently recall, I've just long resigned myself from
> trying to care with Google products. The instances I can recall were
> more defects in their web services, some where there was literally no
> place to go, and I just kept getting the feeling nobody cared.
>

Often that can be the case. On the team I am on, we care but we have about
a billion other things to do than fix low priority bugs or implement
one-off customer features in our clients or APIs. Often I recommend (as
Pawel did later in the thread) writing and using extensions to add these
features. Obviously in the ads one, its not really possible to fix for
everyone (here install this third party extension!) but for gmail it seems
feasible to write a browser extension to highlight the text for you.


>
> eg: I found a coding defect in the Google Ads code that injected the
> version string from whatever flash implementation you were using
> verbatim inside an HTML Tags attributes without caring to escape it,
> which meant if you had a competing implementation(eg: Gnash ) that
> used a double-quote mark in its version string, Ad injection could
> cause entire page layout to be broken.
>

> Or for instance, when GMail overhauled their email service, despite
> the pleas of developers to have a "Don't top-post by default" toggle
> in the settings, the whole developer community was deemed unimportant
> and that such a feature could never happen.
>

So write an extension that doesn't do it?


>
> So now every time I reply to something, I have to fight with GMail to
> make sure I highlight the whole message manually first, making sure
> not to have my selector accidentally slip outside the email text, and
> *then* hit reply, which makes it quote it instead.
>

I'm unsure if extensions work on mobile though :(


>
> The latter choice has been the one that stuck with me the most,
> because I'm constantly feeling like I'm being slapped in the face by
> it.


> Granted these instances are not instances of "Software I run on my
> machine", but they are still software to me.
>

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

Re: [gentoo-dev] Re: how to add a new package with git?

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Montag, 7. September 2015, 08:40:36 schrieb Ryan Hill:
> On Thu, 3 Sep 2015 23:07:37 +0600 (NOVT)
> 
> gro...@gentoo.org wrote:
> > WARNING: previous mirror push to host 'ituri.gentoo.org' failed, status
> > is:
> > 2015-09-03.16:57:50 962 ssh: connect to host ituri.gentoo.org
> > port 22: Connection timed out
[...]
> 
> Sorry if this has been discussed elsewhere, but what is this warning?  A
> couple days ago I started seeing it every time I sync even though I've yet
> to push anything to git.

TL;DR: this is something that only infra needs to care about.

The fact that every dev sees it all the time leads to no end of pointless 
irritation.

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJV7gOYXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5P5sP/3oFgOXQkIhE2yLlnU8a8Czu
T2KKh1ZawRWQpyxIkjaCSlUv6vYedeaYPy73R4wHKdqC5COVP1EggvNd2U3lcxq/
f5DhNmcz3CyQ/snbM90NXWhmrVvdFJDqe2P0/zds7Gzs5i4Nwk2o1rBnhj+q11el
PUM+XOjt19rndkQTumTbW1Z8nC0z7nRXod+T/F5cWMaA8aP1TKp/rBth5c41Q0Ub
yIMPw/nfVbDUYYomIPZOVxKBOVJUGcW2B5elSkgfFGHtQZBfHF6Ak2GID1lCYEsl
juer7fB7hocUE7IubtobrXhmrdpVvRuFjNSOogn9TYsFyAgIsOZVqWgpy5nb58FJ
2OKl6/O/iieZwwBMOPpxMZq+Y2UyZAKbKFaIcXB44I7OsNGyJ+R4HsE15XDIdxCw
bygo0818Sb0AGdVc7W7s7bsXC7hhVgBeO56r4kU+SecsC062TaMKJYKCKLfTUAxL
2znZj4XgX8mIWedHxCaS+O839besNujOhiLsrbSJ7IkAjC86MmllUETSk1cjMFsu
MWtS9IORGWtnoaJ7gTf7039fi0ePHSPzO/Xbn7jDvIO8aIRk6rMH5G8emm8OHIfm
1OjpBTa2Qlegaxo9KosrJPtZbcVTbM20babTGNRHWy/mhioyvTyhLEZSLu3sU3N2
Lzt9w3PbcYRxH91XX7+q
=AqA3
-END PGP SIGNATURE-

[gentoo-dev] <>-DEPENDS

[Marc Schiffbauer]

Hi,


I'd like to propose a new kind of DEPEND syntax: <>

This would mean "Any version but the one specified" and is usefull when 
you have a dependency on another package but a single version of it is 
not compatible for example.

I currently have this case in app-backup/obnam which is not compatible 
to =dev-python/paramiko-1.13.0

In DEPEND I now have this:

  !=dev-python/paramiko-1.13.0
  || ( dev-python/paramiko-1.13.0 )

which does the trick, but I think much more straight forward would be:

  <>dev-python/paramiko-1.13.0

which would be the exact opposite of =dev-python/paramiko-1.13.0

An alternate syntax would be (but I'd prefer the former):

  !=dev-python/paramiko-1.13.0

What do you think and would is the proper way to suggest this for a new 
EAPI?  A new bug? On what?

TIA
-Marc

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] dev-rust category

[Jauhien Piatlicki]

Hi,

On 09/07/2015 07:28 AM, Daniel Campbell wrote:
> On 09/06/2015 02:00 PM, Jauhien Piatlicki wrote:
>> Hi,
> 
>> On 09/05/2015 11:23 PM, Daniel Campbell wrote:
>>> On 09/05/2015 01:04 PM, Matthew Thode wrote:
> 
 I think cargo should probably go in dev-util with other rust 
 libraries and programs going into dev-rust as needed, but
 that's just me :D
>>>
>>> Agreed. dev-util until it grows in size (isn't the
>>> recommendation 5-10+ pkgs?), then dev-rust. Despite the package
>>> moves being somewhat cumbersome, it makes more sense to do it
>>> once it's clear Rust has an ecosystem going rather than catch
>>> stragglers in its infancy.
>>>
> 
>> Ok, looks quite logical for me. So the next question. I remember
>> portage had some problems with moving packages. Would it work if
>> I'll move dev-rust/cargo to dev-util/cargo in our overlay now. And
>> later when rust infrastructure grows move it in the main tree back
>> to dev-rust? Or will it break something?
> 
>> -- Jauhien
> 
> 
> Now that we're on git, I don't see why a quick `git mv old-cat/foo
> new-cat/foo` wouldn't get the job done. Don't quote me on it, but my
> guess is it would work fine. Then make sure the profile data gets
> updated by updating the relevant file(s).
> 
> If you're keeping it in an overlay until you think it's ready for the
> Gentoo repo, you may as well keep it whatever you want since it's not
> bound by Gentoo policy. I would start with dev-util, even in tree, and
> migrate to dev-rust when it reaches critical mass on packages (I'd say
> at least ten).
> 
> 

I'm speaking not about git, but about portage move [1] (see Moving
ebuilds there). This is unrelated to version control.

[1] https://devmanual.gentoo.org/ebuild-maintenance/index.html



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Paweł Hajdan , Jr .]

On 9/3/15 10:16 PM, Andrew Udvare wrote:
> Chromium team is no different in this regard. No options, for anything.
> It is extremely annoying when they implement 'privacy-violating'
> features like the previously visited sites in the New tab (before you've
> entered a URL), with no option to disable despite pleas to give that option.

Do you have references to these pleas? I'd expect e.g. some public bug
reports.

Would overriding the new tab page using an extension
(https://developer.chrome.com/extensions/override) work for you?

Paweł



signature.asc
Description: OpenPGP digital signature