Re: [gentoo-dev] RFC: ban cmake-utils_use_* in EAPI 6

[Jason Zaman]

On Wed, Nov 18, 2015 at 09:53:17PM +1100, Michael Palimaka wrote:
>   $(cmake-utils_use_with foo LibFoo)
>   -DWITH_LibFoo=$(usex foo)
> 
> What do you think?

Do it! I have no idea what the cmake one is supposed to do without
reading docs. The usex one is really obvious.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-libs/courier-unicode/

[Michał Górny]

On Wed, 18 Nov 2015 06:51:04 + (UTC)
"Eray Aslan"  wrote:

> commit: e9620a23f862f69352b0ca31de2f5e4ed642cc69
> Author: Eray Aslan  gentoo  org>
> AuthorDate: Wed Nov 18 06:50:26 2015 +
> Commit: Eray Aslan  gentoo  org>
> CommitDate: Wed Nov 18 06:50:26 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9620a23
> 
> net-libs/courier-unicode: remove old
> 
> Package-Manager: portage-2.2.25
> 
>  net-libs/courier-unicode/Manifest   |  1 -
>  net-libs/courier-unicode/courier-unicode-1.1.ebuild | 20 
>  2 files changed, 21 deletions(-)

This version is required by courier-imap-4.16.0 [1], so you've caused
a depgraph breakage. Please either revert this, remove
courier-imap-4.16.0 (and make sure not to break any revdeps this time)
or fix it.

[1]:https://qa-reports.gentoo.org/output/gentoo-ci/f6b73f6/5.html#l1328


-- 
Best regards,
Michał Górny



pgpwobsdjvI6D.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] EAPI 6 portage is out!

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> And, as a developer maintaining bar in #3 above, you should make
> sure that either the stable version satisfies all rdeps (even those
> in ~arch), or you don't remove the EAPI5 ~arch version until all the
> rdeps are EAPI6.
> 
> Theoretically repoman could check for this; i don't know if it's
> implemented though or if there are any plans to implement it..
> IIRC, confirming removals don't break rdeps is not something repoman
> can do unless you run a 'repoman full' on the whole tree (or at
> least all the rdeps) yourself. 

- -> good usecase for autorepoman (hi Patrick) or the github QA checks after 
adding some extra code in both cases

- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWTM7HAAoJEHRrah2soMK+yp0QAKVBlvvR42YsW1LOoV8Ek22f
O8+4ySe12XGSrFMr9AHBbdRoDQ/7D6uEUbDGjXoeMem6xLTPbzFfOUrrfoISCHwz
2px1l+jUIkOOwD0n3Y7ZlgOccdoGcrS4WgXGKidEn5wbbPG5ggzHpUNvBDsBwZMm
y+COqixcwo7oE9Bdtar6mAhnhyy4b1eZEyUP6/CmY/wXUplzdmZtY+s3FvgCyYah
eGC6aW6pLiZMMx9vZuyXs9D4cN5jV7hc1EJWHp01YNGp8qBtxWL42bFnUBw+flii
bjWIlTaaE3TItoEgGB32MUnCOR8wLSVpPw9mS8T1JeWuuy2uK9va54+WzA25Aa40
6+rm+K4xgxwKVN4s6yF6ZEuiU125/ayaCQQPeT9s/ZoDQt6xASLKQWxM4TrJp897
HYr0mvl34aV8MnijOu+DkHRg5gMt9bZDkS041/OuQuY5pfuOEdUAsym78cSPpgxW
DRol2w4J8N8fUGBnLOLLy7p8c590tb4OGsuWSzNpXAn9cErI39KqlbIDzGcQL6TH
Gz+Mba8DaQ9IBda73o0OdEAFQUT5ZB2oWiK6FJoZjDpG9PQG7CnN63hL7+xLoceF
6fLmENIOwywRwcpTifCQhJ5OziPSKkUK+UK0GhvBh8QX1lS+eY4Xm7211pV/MxUp
yiSwIJYOroSGu/mPq60k
=9nqS
-END PGP SIGNATURE-

Re: [gentoo-dev] EAPI 6 portage is out!

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/11/15 02:25 AM, Ulrich Mueller wrote:
>> On Tue, 17 Nov 2015, Michael Orlitzky wrote:
> 
>> It doesn't seem that unlikely to me...
> 
>> 1. Otherwise stable system with package "foo" keyworded as
>> ~arch.
> 
>> 2. foo needs some dependency of a dependency named "bar".
> 
>> 3. The bar maintainer revbumps and removes the old EAPI=5
>> ebuild.
> 
>> I don't really care either way, I'm just wondering whether this
>> is "safe" because it's actually safe, or "safe" because we're
>> gonna do it anyway.
> 
> Actually it is quite simple:
> 
> - The stable tree should not contain any EAPI 6 ebuilds at this
> point, so stable users should not see any change. - Unstable
> users will have a package manager aware of EAPI 6, so all ebuilds
> will be visible for it. - If you mix stable and unstable then you
> are by definition an advanced user, who will be able to cope with
> the situation. :)
> 

And, as a developer maintaining bar in #3 above, you should make
sure that either the stable version satisfies all rdeps (even those
in ~arch), or you don't remove the EAPI5 ~arch version until all the
rdeps are EAPI6.

Theoretically repoman could check for this; i don't know if it's
implemented though or if there are any plans to implement it..
IIRC, confirming removals don't break rdeps is not something repoman
can do unless you run a 'repoman full' on the whole tree (or at
least all the rdeps) yourself.  This really isn't any different from
the case where foo-1.0 has RDEPEND=" =bar-3.0 " and then bar-3.0 is
dropped.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlZMyF8ACgkQAJxUfCtlWe21RAD7Bxku5bXPbQGLcCwgefjJqadB
LA1tSiK0OkCeUKwvtXEBALw4owHTN/cIOZTFgJkx+scKVvH8lefZbQVjTl9w8KlS
=qb2w
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: ban cmake-utils_use_* in EAPI 6

[Brian Dolbec]

On Wed, 18 Nov 2015 11:47:35 -0500
Mike Gilbert  wrote:

> On Wed, Nov 18, 2015 at 10:23 AM, Brian Dolbec 
> wrote:
> > On Wed, 18 Nov 2015 12:02:15 +0100
> > Alexis Ballier  wrote:
> >  
> >> On Wed, 18 Nov 2015 21:53:17 +1100
> >> Michael Palimaka  wrote:
> >>  
> >> > What do you think?  
> >>
> >>
> >> +1
> >>
> >> even if I sometimes use those cmake-utils_use*, they tend to
> >> confuse me and find -DABCD=$(usex ...) much easier to understand
> >> for the occasional user of cmake-utils.eclass.
> >>  
> >
> >
> > Forgive me if I'm wrong, but I thought EAPI 6 specifications were
> > finalized.
> >
> > Doesn't that mean this will have to wait for EAPI 7?  
> 
> eclass API is not directly tied to EAPI/PMS. However,
> cmake-utils.eclass has this:
> 
> case ${EAPI} in
> 2|3|4|5) : ;;
> *) die "EAPI=${EAPI:-0} is not supported" ;;
> esac
> 
> That means that its API is currently undefined when EAPI is set to 6;
> the eclass will immediately die.
> 
> This is just a convenient opportunity to change the API of this eclass
> without risking breakage of existing ebuilds.
> 

Thanks to both Michael and Mike.

I didn't read enough of the emails and missed this was about eclass
API's

-- 
Brian Dolbec 

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

[Michael Orlitzky]

On 11/18/2015 12:55 PM, Michael Orlitzky wrote:
> 
> That's taking about half a second if I run it from the command-line.
> 

...and this takes even longer:

  cinfo = self.grab(['git', self._work_tree, 'diff-tree',
 '--name-status',
 '--no-renames',
 '--format=%ct %cN <%cE>%n%B',
 '--root',
 '--relative=%s' % (cp, ),
 '-r',
 c,
 '--', '.']).rstrip('\n').split('\n')

That happens for every commit.

[gentoo-dev] Re: EAPI 6 portage is out!

[»Q«]

On Wed, 18 Nov 2015 18:06:23 +0100
Ulrich Mueller  wrote:

> > On Wed, 18 Nov 2015, »Q«  wrote:  
> 
> > When ~ keywording is needed for dependencies, the PM's output makes
> > it clear what's needed. In cases where EAPI 6 is needed for
> > dependencies but the PM is unaware of EAPI 6, will there be good
> > clues in the PM's output that the PM itself needs to be ~
> > keyworded?  
> 
> IIRC, portage will output a message like "masked by EAPI" along with
> a longer explanation that you should upgrade portage to a version
> aware of that EAPI.

Thanks.  ISTM that's plenty, and as a mostly-stable user with a 
few ~ packages it's all I'd hope for.

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

[Michael Orlitzky]

On 11/18/2015 09:48 AM, Peter Stuge wrote:
> Peter Stuge wrote:
>> Robin H. Johnson wrote:
>>> However, the largest sticking point, even with parallel threads, is that
>>> it seems the base ChangeLog generation is incredibly slow. It averages
>>> above 350ms per package right now (at 19k packages in a full cycle, it's
>>> a long time), but some packages can take up to 5 seconds so far.
>>
>> Which code is doing this generation? Sorry - ENOOVERVIEW. :\
> 
> Bump. Does anyone know where I can take a look at this code?
> 

I don't know, but since no one else is answering, I'll try to find out.
There are a few bugs on b.g.o. (search "changelog") that suggest
`egencache --update-changelog` is being used. The egencache command is
part of portage, so

  $ git clone http://anongit.gentoo.org/git/proj/portage.git

Looking at bin/egencache, you'll find a bunch of indirection, but
ultimately, the generate_changelog() method of the GenChangeLogs class
is doing the work. The implementation is straightforward. I suspect the
slow part is,

  # now grab all the commits
  revlist_cmd = ['git', self._work_tree, 'rev-list']
  if self._changelog_reversed:
  revlist_cmd.append('--reverse')
  revlist_cmd.extend(['HEAD', '--', '.'])
  commits = self.grab(revlist_cmd).split()

where

  @staticmethod
  def grab(cmd):
  p = subprocess.Popen(cmd, stdout=subprocess.PIPE)
  return _unicode_decode(p.communicate()[0],
 encoding=_encodings['stdio'],
 errors='strict')

That's taking about half a second if I run it from the command-line.

Re: [gentoo-dev] RFC: ban cmake-utils_use_* in EAPI 6

[Davide Pesavento]

On Wed, Nov 18, 2015 at 11:53 AM, Michael Palimaka
 wrote:
[...]
>
> What do you think?

+1 for banning them.

Thanks,
Davide

[gentoo-dev] Re: EAPI 6 portage is out!

[Ulrich Mueller]

> On Wed, 18 Nov 2015, »Q«  wrote:

> When ~ keywording is needed for dependencies, the PM's output makes
> it clear what's needed. In cases where EAPI 6 is needed for
> dependencies but the PM is unaware of EAPI 6, will there be good
> clues in the PM's output that the PM itself needs to be ~ keyworded?

IIRC, portage will output a message like "masked by EAPI" along with
a longer explanation that you should upgrade portage to a version
aware of that EAPI.

Ulrich


pgpfRzbslucIS.pgp
Description: PGP signature

[gentoo-dev] Re: EAPI 6 portage is out!

[»Q«]

On Wed, 18 Nov 2015 12:05:26 +0100
Ulrich Mueller  wrote:

> > On 18/11/15 08:25, Ulrich Mueller wrote:  
> >> - If you mix stable and unstable then you are by definition an 
> >> advanced user, who will be able to cope with the situation. :)
  
> Only that there is no real difference to the existing situation when
> mixing stable and unstable. It is not guaranteed that all dependencies
> of an unstable package are stable, so already now users may have to
> accept the ~ keyword for dependencies in some cases. Similarly, such
> users may have to accept EAPI 6 for some dependencies, which implies
> that they install a package manager supporting EAPI 6.

When ~ keywording is needed for dependencies, the PM's output makes it
clear what's needed.  In cases where EAPI 6 is needed for dependencies
but the PM is unaware of EAPI 6, will there be good clues in the PM's
output that the PM itself needs to be ~ keyworded?

Re: [gentoo-dev] RFC: ban cmake-utils_use_* in EAPI 6

[Mike Gilbert]

On Wed, Nov 18, 2015 at 10:23 AM, Brian Dolbec  wrote:
> On Wed, 18 Nov 2015 12:02:15 +0100
> Alexis Ballier  wrote:
>
>> On Wed, 18 Nov 2015 21:53:17 +1100
>> Michael Palimaka  wrote:
>>
>> > What do you think?
>>
>>
>> +1
>>
>> even if I sometimes use those cmake-utils_use*, they tend to confuse
>> me and find -DABCD=$(usex ...) much easier to understand for the
>> occasional user of cmake-utils.eclass.
>>
>
>
> Forgive me if I'm wrong, but I thought EAPI 6 specifications were
> finalized.
>
> Doesn't that mean this will have to wait for EAPI 7?

eclass API is not directly tied to EAPI/PMS. However,
cmake-utils.eclass has this:

case ${EAPI} in
2|3|4|5) : ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac

That means that its API is currently undefined when EAPI is set to 6;
the eclass will immediately die.

This is just a convenient opportunity to change the API of this eclass
without risking breakage of existing ebuilds.

Re: [gentoo-dev] EAPI 6 portage is out!

[Rich Freeman]

On Wed, Nov 18, 2015 at 10:10 AM, Brian Dolbec  wrote:
> On Wed, 18 Nov 2015 06:59:19 -0500
> Rich Freeman  wrote:
>
>> Actually, what is less clear to me is how portage versioning actually
>> works, or if we attach any meaning to the version numbers at all.
>> Both the stable and unstable series are on 2.2.x, but there are no
>> versions in the tree between 2.2.20 and 2.2.23.
>>
>
> So, we have 2 user groups, stable and unstable.
>
> Current stable is 2.2.20.1
> current unstable is 2.2.25 <==just released

So, my first point was that the version numbering seems to have no
relationship to what is stable and unstable.  It isn't really meant as
a big complaint, but it just suggests a lack of a release strategy.

>
> With 2.2.4 becoming stable, why would we keep the buggy ~ 2.2.3 in the
> tree taking up space?  We already established that ~ users will have
> migrated away from it.
>

Sure, and my comment wasn't really directed at portage in particular,
though it is a fair reply because I did use it as an example.  Portage
is a bit unique in that it has no upstream QA process - the QA is
being done entirely within Gentoo.  For packages other than portage
there should be less reason to drop versions, since they probably
wouldn't have been released if they were unsuitable to release.

>
>> That tends
>> to result in a situation where if you follow ~arch you end up having
>> to accept lots of updates because none of the versions stay in the
>> tree long enough to actually get stabilized.
>
> that happens for some pkgs, if it happens too much for you, update less
> often.

What do you mean by "update less often?"  Are you suggesting not
running emerge --sync?  Not wanting to follow every ~arch version of a
package whose stable version has a problem isn't the same as not
wanting to update your entire tree, and there is no reason to force
users to choose between only those choices.

>
>> Unless a ~arch package
>> version is so broken that it could never be stabilized it is probably
>> better to leave them there so that it is easier for users to drop back
>> from ~arch to stable without downgrading.
>>
>
> Rich, please re-read your above statements until you see the total
> failure in your logic.

It is a bit ironic that you chose this as the part to quote when
adding a snide remark.  My whole point was that we shouldn't
NEEDLESSLY drop old versions,  You seemed to have taken this as a
complaint about dropping old versions when there is a valid reason for
doing so.

Your tone here is anything but helpful.  My intent was really to
contribute to the discussion constructively and point out a pain point
for people running mixed-keywords.  Perhaps I didn't explain my point
as well as I could have.  When somebody is saying something that
doesn't seem sensible to you, it is usually better to assume that they
just didn't make their point well than to assume that they don't have
anything worth saying.

-- 
Rich

Re: [gentoo-dev] RFC: ban cmake-utils_use_* in EAPI 6

[Michał Górny]

On Wed, 18 Nov 2015 07:23:55 -0800
Brian Dolbec  wrote:

> On Wed, 18 Nov 2015 12:02:15 +0100
> Alexis Ballier  wrote:
> 
> > On Wed, 18 Nov 2015 21:53:17 +1100
> > Michael Palimaka  wrote:
> >   
> > > What do you think?
> > 
> > 
> > +1
> > 
> > even if I sometimes use those cmake-utils_use*, they tend to confuse
> > me and find -DABCD=$(usex ...) much easier to understand for the
> > occasional user of cmake-utils.eclass.
> >   
> 
> 
> Forgive me if I'm wrong, but I thought EAPI 6 specifications were
> finalized.
> 
> Doesn't that mean this will have to wait for EAPI 7?

It's eclass API, so it's free to change anytime. Using a new EAPI to
change eclass API has the benefit that you can ban new uses of
deprecated functions without breaking existing ebuilds.

-- 
Best regards,
Michał Górny



pgppUCVhwHQzy.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: ban cmake-utils_use_* in EAPI 6

[Brian Dolbec]

On Wed, 18 Nov 2015 12:02:15 +0100
Alexis Ballier  wrote:

> On Wed, 18 Nov 2015 21:53:17 +1100
> Michael Palimaka  wrote:
> 
> > What do you think?  
> 
> 
> +1
> 
> even if I sometimes use those cmake-utils_use*, they tend to confuse
> me and find -DABCD=$(usex ...) much easier to understand for the
> occasional user of cmake-utils.eclass.
> 


Forgive me if I'm wrong, but I thought EAPI 6 specifications were
finalized.

Doesn't that mean this will have to wait for EAPI 7?

-- 
Brian Dolbec 

Re: [gentoo-dev] EAPI 6 portage is out!

[Brian Dolbec]

On Wed, 18 Nov 2015 06:59:19 -0500
Rich Freeman  wrote:

> On Wed, Nov 18, 2015 at 6:05 AM, Ulrich Mueller 
> wrote:
> >
> > And on what basis would you stabilise Portage, when there are no
> > ebuilds in the tree to test its EAPI 6 code?
> >  
> 
> As long as the EAPI6 code in the new portage is no more broken than
> the EAPI6 code in the current stable version of portage (which doesn't
> work/exist at all), it isn't much of a regression.  What would be more
> of a pain is dealing with fixes in stable.
> 
> But, I don't have a problem with starting to use EAPI6 now, mainly
> because the ~arch version of portage does not require any new ~arch
> dependencies that would create a mess for stable users.  So, if a user
> needs to switch to a newer portage for a month or two it shouldn't be
> that big of a deal.
> 

The above part is fine :)


But this next bit...

> Actually, what is less clear to me is how portage versioning actually
> works, or if we attach any meaning to the version numbers at all.
> Both the stable and unstable series are on 2.2.x, but there are no
> versions in the tree between 2.2.20 and 2.2.23.
> 

So, we have 2 user groups, stable and unstable.

Current stable is 2.2.20.1
current unstable is 2.2.25 <==just released

So, when we release a new unstable version, unstable users upgrade,
what do you think happens to the older unstable version at that point.
It no longer receives much testing as the unstable users upgrade to the
newer unstable version.

If we feel that there is enough bugs in those that we do not want to
stabilize it.  Why would we keep it in the tree?  Just so more users
can potentially come across those bugs and open new bugs, since the old
bugs for those were closed with the newer release that contains the fix?
Are the bug wranglers low on work?

Here is a current example:

portage-2.2.23 is now old enough to consider stabilizing it.  It
contains a new cgroup feature.  It has a bug making it difficult for
people unless they again disable that feature.

portage-2.2.24 has no new features, just a bunch of bug fixes.

We decided that we will wait a few weeks and call for 2.2.24 to be
stabilized, maybe we will wait just one week (not the normal 30 days),
since 2.2.23 is out of consideration, 2.2.24 testing will dwindle to
nothing in the next week as people upgrade to 2.2.25.  

With 2.2.4 becoming stable, why would we keep the buggy ~ 2.2.3 in the
tree taking up space?  We already established that ~ users will have
migrated away from it.



> The main thing I find painful in following ~arch on the odd package is
> when maintainers drop versions quickly after bumping them.  

You want a package version with known serious bugs left in the tree so
more people can experience them? 

> That tends
> to result in a situation where if you follow ~arch you end up having
> to accept lots of updates because none of the versions stay in the
> tree long enough to actually get stabilized.  

that happens for some pkgs, if it happens too much for you, update less
often.

> Unless a ~arch package
> version is so broken that it could never be stabilized it is probably
> better to leave them there so that it is easier for users to drop back
> from ~arch to stable without downgrading.
> 

Rich, please re-read your above statements until you see the total
failure in your logic.

-- 
Brian Dolbec 

Re: [gentoo-dev] EAPI 6 portage is out!

[Andreas K. Huettel]

Am Mittwoch, 18. November 2015, 12:12:05 schrieb Alexander Berntsen:
> On 18/11/15 12:05, Ulrich Mueller wrote:
> > Only that there is no real difference to the existing situation
> > when mixing stable and unstable. It is not guaranteed that all
> > dependencies of an unstable package are stable, so already now
> > users may have to accept the ~ keyword for dependencies in some
> > cases. Similarly, such users may have to accept EAPI 6 for some
> > dependencies, which implies that they install a package manager
> > supporting EAPI 6.
> 
> There's a difference between some packages being troublesome, and
> encouraging everyone to rewrite their eclasses and ebuilds, if the end
> result is a huge portion of ebuilds causing headaches.

Well, at some point it has to be introduced in the main tree. 
Can you prove at any point that portage is 100% correct? 

Also, adding EAPI=6 support to eclasses mostly consists of adding branches to 
case statements. I.e. the new code paths will never run on old EAPI.

> > And on what basis would you stabilise Portage, when there are no
> > ebuilds in the tree to test its EAPI 6 code?
> 
> When I do QA in projects I'm involved with (at least outside of
> Gentoo), we don't do it live on end-user systems. I'll leave the
> details as an exercise for the Gentoo developer.

So, I suggest you branch gentoo.git, start adding some new ebuilds to it 
(don't forget to use a random combination of eclasses, like perl-module, 
python-r1, kde4-base ...), update your system and check for all possible 
resolver oddities... Too much work? Tough.

-- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] EAPI 6 portage is out!

[Andreas K. Huettel]

Am Mittwoch, 18. November 2015, 10:25:23 schrieb Alexander Berntsen:
> On 18/11/15 08:25, Ulrich Mueller wrote:
> > - If you mix stable and unstable then you are by definition an
> > advanced user, who will be able to cope with the situation. :)
> 
> This attitude is shitty, and I am willing to wager a really big bunch
> of users fall into this category.
> 
> I don't think EAPI 6 is *that* shiny, that we need to start using it
> prior to stable Portage supporting it. It's a potential mess for a
> huge portion of our users.

It would be helpful if you could point out what exactly *didn't* work in the 
past, instead of just making big words and large noise here. After all that's 
exactly the procedure that has been used for the last EAPI introductions.

-- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

[Peter Stuge]

Peter Stuge wrote:
> Robin H. Johnson wrote:
> > However, the largest sticking point, even with parallel threads, is that
> > it seems the base ChangeLog generation is incredibly slow. It averages
> > above 350ms per package right now (at 19k packages in a full cycle, it's
> > a long time), but some packages can take up to 5 seconds so far.
> 
> Which code is doing this generation? Sorry - ENOOVERVIEW. :\

Bump. Does anyone know where I can take a look at this code?


//Peter

[gentoo-dev] Last rites: app-pda/libopensync* and friends

[Michael Palimaka]

# Michael Palimaka  (18 Nov 2015)
# Ebuilds unfinished work-in-progress. Dead upstream.
# Masked for removal in 30 days. Bug #550234.
app-pda/libopensync
app-pda/libopensync-plugin-file
app-pda/libopensync-plugin-gnokii
app-pda/libopensync-plugin-gpe
app-pda/libopensync-plugin-irmc
app-pda/libopensync-plugin-moto
app-pda/libopensync-plugin-palm
app-pda/libopensync-plugin-python
app-pda/libopensync-plugin-sunbird
app-pda/libopensync-plugin-synce-rra
app-pda/libopensync-plugin-syncml
app-pda/libopensync-plugin-vformat
app-pda/libsyncml
app-pda/msynctool
app-pda/multisync-gui
app-pda/osynctool

Re: [gentoo-dev] EAPI 6 portage is out!

[Rich Freeman]

On Wed, Nov 18, 2015 at 7:06 AM, Alexander Berntsen  wrote:
> We are talking about people who run Gentoo stable who need to
> keyword several specific packages because the lack of manpower
> leads to Gentoo stable by itself not being very usable for most
> people.
>

In this case, however, I don't really see that much impact on stable
users.  At most they need to accept a ~arch version of portage until
it becomes stable again.  It is a PITA because of how we tend to drop
versions of ~arch packages before they ever become stable, but any
stable user is already familiar with this pain and I don't really
think it is related to the EAPI6 introduction.

There really isn't a great alternative either.  It seems likely that
portage will end up having a bunch of little bumps with bugfixes until
things settle down, so it isn't a great time to try to stabilize EAPI6
versions of portage.  We'll get through the pain faster with the
widespread testing you get in ~arch.

>
> Whatever. I just wanted to raise my concern. It has been raised.
> You're all free to not care. Too bad for the user^Wthankless
> contributors.

Well, if you care that much, do more than post about it on a list.
This is actually a topic I care a lot about, but right now I don't
have a better solution to offer so it isn't productive to just hurl
abuse on those trying to actually improve things simply because they
aren't improving everything at once.

I don't really have a problem with politely pointing out the downsides
of the current state, but you need to be patient if you don't actually
have a solution for them as nothing is going to happen without one.

So, in an attempt to try to make this discussion more productive, feel
free to start a thread if you have any ideas of practical solutions
for making life better for mixed-keyword users?  My biggest suggestion
would be to avoid pruning older ~arch versions unless they have
serious problems, so that they can become potential stable targets
later, and that maintainers should always have a path to stable in
mind.  Another suggestion would be for maintainers to store some kind
of metadata that communicates their stabilization/versioning strategy
(which could be useful both to mixed-keyword users and to
co-maintainers or other random devs who need to touch ebuilds).  Some
package just can never go stable, and some version series might never
go stable due to upstream reasons, and it would be nice if that were
all captured in some way.

-- 
Rich

Re: [gentoo-dev] EAPI 6 portage is out!

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 18/11/15 13:01, Rich Freeman wrote:
> People who run ~arch are not really end-users - they're 
> contributors who have volunteered to test packages.
We are talking about people who run Gentoo stable who need to
keyword several specific packages because the lack of manpower
leads to Gentoo stable by itself not being very usable for most
people.


Whatever. I just wanted to raise my concern. It has been raised.
You're all free to not care. Too bad for the user^Wthankless
contributors.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWTGm3AAoJENQqWdRUGk8BQOsQALH/uwdDqhcbJhVwLPQ70WBj
ugYr83K5rumSc+riy5kMsM0qRH6unx4pJYeOotSlCM/FZAMMp1bPGViWbJXF7ulm
keLRiizI/wcnemGKWw/dOv1FwjRq1Dlsc8RnIIGnxD6Y/ah0wxTgMNBhvBmItrBv
uZrC7ke22A+qC2/vurs3yqQmJk1HRD1cHamjfPT77mfWv3EKoZ1SSEyxg44TZMnV
9xI958RZNyFSENR//PQVYhf88a8KPmTYykAZa1/aoL0oADdNr9BByheP4Ndbdwaq
8JAWTSJJfL4skYgvscajnKUTLxgRsp2lF5gT1JD8+6wMjq1Cg6E47MNy6nZ40CYF
qo+uV4LUkeCTQWsVVAAYybGiOQimN4TV9TSD3Vn/hnaLZk7/eUTjbwYmfqQBU34G
X5UjHiCMVtY+7zaYB/1axJWhwvbjKF7mwXsNfyFfkpDw1LGfRDVmM/pamAI8tsCx
sstYlUP742QV8xm3pWlkYSc3b+a4Ubh4+nW45Qv9FTq0VKFpahXdkjPPoyIIHxFY
as6KyGb+WHDCxB7m5aIM1sRNJcrY/jtCqiHV/a+mZOdBIeN5fEYPLR70Qzk4snaL
GBtOFRpynU9h8QLnZ0OlBKx4basbyaEaiOovE9FLM19lAmsVEJX+ksOXpLkoiKR2
Ys0oJPitEIufyebCmtUi
=5xCX
-END PGP SIGNATURE-

Re: [gentoo-dev] EAPI 6 portage is out!

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 18/11/15 12:59, Rich Freeman wrote:
> Actually, what is less clear to me is how portage versioning
> actually works, or if we attach any meaning to the version numbers
> at all.
The higher number is the newer version.

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

iQIcBAEBCgAGBQJWTGhsAAoJENQqWdRUGk8BimgQAOCEt/PzIDgvezHZoKYRYpSR
stwHOfM8iN9ToCqehjGGjKfojd3sFSPoBZi/hmnKuCQY5ni3cTE/8+RKXi/d5zS+
SEfGhJNd67ctyNrqaXYGOVG/PjX+mSpaFw51UTMZEH+lN04rhCxzqtczjvGXHysv
qY8otUtSxzpyooyPR5pT0EvxB3FLrfv7BgR3z8DsNWeP85qVFpMLPFbrWB5DGdxQ
22vr61Pgq60tC6BlGMmNyXlypAt0JS4CRMER2Kce1+mFfTz/YILgm+eNVq3FCsI0
p9bl+k7gU5tRyBSPfsyVE1ceS0E/0Dg/1a7SvE+ZNcgW6gZs2terYZJr+Jeq2aBn
Y0hOCxl6e7yPmecOy1XjUyYJ5B8OF6Od13Bs+pN7ycy/Av3pK4xXEyoLnt4hAtUD
l9uUkXdOk4ftK1SKjf1WMwMPp5lpc+fFdCL0sHKhfGl9+lR4/Di8NOP4iXxxmbm8
2j/ZSe697rZvHWcvtBDeZ6wTwplM7r41tYVTfob1i9yDHmixe9TgsJph6NqkdmAH
EXB5GScatUVkSz2z2FvolceTqTJ5LDUoyxv62CoZNFeY9WcAJV289YOTB6kWZIce
cV/hqnG7IN7HOvmu0UNMrNlsu5OR6jW8DF5BYuUZZNyZt58xlsFRaE33QWSBlKbM
mCK3m/9JqP2kb5djvKCp
=yAZB
-END PGP SIGNATURE-

Re: [gentoo-dev] EAPI 6 portage is out!

[Rich Freeman]

On Wed, Nov 18, 2015 at 6:12 AM, Alexander Berntsen  wrote:
> When I do QA in projects I'm involved with (at least outside of
> Gentoo), we don't do it live on end-user systems. I'll leave the
> details as an exercise for the Gentoo developer.
>

People who run ~arch are not really end-users - they're contributors
who have volunteered to test packages.

But, if you want to contribute a unit testing framework for portage
I'm sure it would be welcome!

-- 
Rich

Re: [gentoo-dev] EAPI 6 portage is out!

[Rich Freeman]

On Wed, Nov 18, 2015 at 6:05 AM, Ulrich Mueller  wrote:
>
> And on what basis would you stabilise Portage, when there are no
> ebuilds in the tree to test its EAPI 6 code?
>

As long as the EAPI6 code in the new portage is no more broken than
the EAPI6 code in the current stable version of portage (which doesn't
work/exist at all), it isn't much of a regression.  What would be more
of a pain is dealing with fixes in stable.

But, I don't have a problem with starting to use EAPI6 now, mainly
because the ~arch version of portage does not require any new ~arch
dependencies that would create a mess for stable users.  So, if a user
needs to switch to a newer portage for a month or two it shouldn't be
that big of a deal.

Actually, what is less clear to me is how portage versioning actually
works, or if we attach any meaning to the version numbers at all.
Both the stable and unstable series are on 2.2.x, but there are no
versions in the tree between 2.2.20 and 2.2.23.

The main thing I find painful in following ~arch on the odd package is
when maintainers drop versions quickly after bumping them.  That tends
to result in a situation where if you follow ~arch you end up having
to accept lots of updates because none of the versions stay in the
tree long enough to actually get stabilized.  Unless a ~arch package
version is so broken that it could never be stabilized it is probably
better to leave them there so that it is easier for users to drop back
from ~arch to stable without downgrading.

-- 
Rich

Re: [gentoo-dev] EAPI 6 portage is out!

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 18/11/15 12:23, Ulrich Mueller wrote:
> That sort of QA should take place before making a new Portage 
> relaese. I was talking about marking it stable, though.
The problem we are talking about isn't making sure Portage's EAPI 6
support is bug free, but the pain caused by encouraging widespread use
of features not available in the stabilised Portage.

> Quoting the devmanual:
> 
> arch Both the package version and the ebuild are widely tested, 
> known to work and not have any serious issues on the indicated 
> platform.
> 
> "Widely tested" has always meant tested on unstable users'
> systems.
Appealing to tradition or technical debt is not a strong way of
convincing me. That you've been doing things wrong all along does not
make for a good excuse to keep doing it wrong.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWTGB9AAoJENQqWdRUGk8BG0AQAN8cBbWyd00uW1puvZPlXJKj
VdRZ2ejnt2HFX+XIROJuCQeRghHTRSEUFkGlyB4GeGkUoCjP3zmvADel/kV+7eB4
8Kir/HIlWEIaIN9szdH1vFP13AuHe8bS3Y+dFFb2GrQb6I8oIDCRSI3J1wZbztpO
kyhwiJ2eNQaw+SbDbMHL4t8PomMkVpyv2Ix4y/K96e1gaGp9XGhT38YthxhnMBoy
9x8L6GHXyFnqnWYe/V549muENy2HwbAUGw9blBn/2R9U+DG4Ewc3PBEKPk75GFE3
kbl3T9xgeyWmuGRUn73aMUiluu0gvgNvwn5l9QT7po4n5wotOi76XBvewLPA+O7b
jeu/3+n1iW75+x7n7T+Pn5uJ+9xffgTQcg7rcStYU6l+dpVEOXcnoptgyeJ6gY91
lhidelO1Wnk9x6VyxXNg4jfFphX19/H51xyfyFXxgj398Ex3kEZ3/X52mTGxuRJD
4h6LxkgDsZvWc6/GkmL8USWrUPAP8i2ncjTEabixXzbZCjG4DzN6nJoC6m/8aLyT
MOoytIwc+evBUyBAKZ19f4m86FC1dcd5V7dGqGnR/tPWjc6xbx5f+iZk88/yKexO
mXnr3K9f3uzFH2vXFGuHgiq8xPKNEV2ToYUL+M5bG1y4ZxbUiWmIzadI/t5pVPFK
7mn8r8x1ZWhNvCzzduF7
=9smD
-END PGP SIGNATURE-

Re: [gentoo-dev] EAPI 6 portage is out!

[Ulrich Mueller]

> On Wed, 18 Nov 2015, Alexander Berntsen wrote:

>> And on what basis would you stabilise Portage, when there are no 
>> ebuilds in the tree to test its EAPI 6 code?
> When I do QA in projects I'm involved with (at least outside of
> Gentoo), we don't do it live on end-user systems. I'll leave the
> details as an exercise for the Gentoo developer.

That sort of QA should take place before making a new Portage relaese.
I was talking about marking it stable, though.

Quoting the devmanual:

   arch
   Both the package version and the ebuild are widely tested, known
   to work and not have any serious issues on the indicated platform.

"Widely tested" has always meant tested on unstable users' systems.

Ulrich


pgpxZOjNX17dA.pgp
Description: PGP signature

Re: [gentoo-dev] EAPI 6 portage is out!

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 18/11/15 12:05, Ulrich Mueller wrote:
> Only that there is no real difference to the existing situation
> when mixing stable and unstable. It is not guaranteed that all
> dependencies of an unstable package are stable, so already now
> users may have to accept the ~ keyword for dependencies in some
> cases. Similarly, such users may have to accept EAPI 6 for some
> dependencies, which implies that they install a package manager
> supporting EAPI 6.
There's a difference between some packages being troublesome, and
encouraging everyone to rewrite their eclasses and ebuilds, if the end
result is a huge portion of ebuilds causing headaches.

> And on what basis would you stabilise Portage, when there are no 
> ebuilds in the tree to test its EAPI 6 code?
When I do QA in projects I'm involved with (at least outside of
Gentoo), we don't do it live on end-user systems. I'll leave the
details as an exercise for the Gentoo developer.

> If we had followed this argument in the past, we would be at EAPI
> 0 still.
Reaching.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWTF0EAAoJENQqWdRUGk8BR/IQANZUF+ZFdVuzEqhayUiH6teG
5zqi2rlyx3Sh7N7zdm4NyG9k/GW9LZrok2ZC4fcruIuOx8gAG9oPFzAfGgwFnojf
ugsD7xSSHyHXpZONvmqffRs6AbX6omGdmdF8tmPHec28iWl44g79D25Eqj+dqsyd
XRqjmAuQauB/fmiLaFyZmGrDuvzn/e+DO8P6QzMgw9OTPV/YZM2FQsvO8gHQPH16
MVlAhIIo46gAh8sMKP7SGok87J7rV1LiRn/Z+RCsjRSMWsGjCRvFRTGeCCNs8sMA
BLMds7I+7Oj64YvoVCtjRlfJw+NL6l2Xrb9ZEpjNefnUuP1PY8FlVTd4w2rLEhyn
issEplE4EFA1uJiEv5atVaW7Sjl1YO+XoSyrxs5jmYcXEcB3ohtjhGYUWCDyn3H6
EjNTALqiHLnQQoNxxpDQcqNa6QAEYwna2y5813FXk7qG+qrbjx2tUwjwuDgdq201
QL4dZIhgbOrGb4ePa5hgoN9PuoGveIpUUYNjFHAAJHWTlbje842O5XuoiGLSxkyX
tqhtSqZni/uiuS8wD+uEHR0Edc80YgYH8UOZ+g4ePKyEU/GBwC7GaR48eAPAukMD
GRIi8BqS3azEXkexdLaxJ8ksTKOzsCabr0BkI10rc/N/EMbBlKWwjc8ajq3x2pJ5
Gx0NNxCn54sqskDeLWxQ
=0ySj
-END PGP SIGNATURE-

Re: [gentoo-dev] EAPI 6 portage is out!

[Ulrich Mueller]

> On Wed, 18 Nov 2015, Alexander Berntsen wrote:

> On 18/11/15 08:25, Ulrich Mueller wrote:
>> - If you mix stable and unstable then you are by definition an 
>> advanced user, who will be able to cope with the situation. :)
> This attitude is shitty, and I am willing to wager a really big
> bunch of users fall into this category.

Only that there is no real difference to the existing situation when
mixing stable and unstable. It is not guaranteed that all dependencies
of an unstable package are stable, so already now users may have to
accept the ~ keyword for dependencies in some cases. Similarly, such
users may have to accept EAPI 6 for some dependencies, which implies
that they install a package manager supporting EAPI 6.

> I don't think EAPI 6 is *that* shiny, that we need to start using it
> prior to stable Portage supporting it.

And on what basis would you stabilise Portage, when there are no
ebuilds in the tree to test its EAPI 6 code?

> It's a potential mess for a huge portion of our users.

If we had followed this argument in the past, we would be at EAPI 0
still.

Ulrich


pgpgbZkHXRGxW.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: ban cmake-utils_use_* in EAPI 6

[Alexis Ballier]

On Wed, 18 Nov 2015 21:53:17 +1100
Michael Palimaka  wrote:

> What do you think?


+1

even if I sometimes use those cmake-utils_use*, they tend to confuse
me and find -DABCD=$(usex ...) much easier to understand for the
occasional user of cmake-utils.eclass.

[gentoo-dev] RFC: ban cmake-utils_use_* in EAPI 6

[Michael Palimaka]

cmake-utils.eclass currently defines 10 helper functions to assist in
configuring packages.

For example:

local mycmakeargs=(
$(cmake-utils_use_with foo LibFoo)
)

which outputs -DWITH_LibFoo=ON or OFF

Most of these helpers were introduced before, and could be replaced by,
usex:

local mycmakeargs=(
-DWITH_LibFoo=$(usex foo)
)

In bug #514384 it has been discussed banning many/all of these helpers
in EAPI 6 and later.

With usex, it's much clearer what actually get passed to cmake, reducing
the chance of incorrect arguments, but $(cmake-utils_use_with foo
LibFoo) is considered by some to be cleaner-looking and nicer to read
than -DWITH_LibFoo=$(usex foo)

The helpers also pass the same option multiple times with different
capitalisation variants:

$(cmake-utils_use_with foo) emits -DWITH_foo=OFF -DWITH_FOO=OFF
-DWITH_Foo=OFF

This makes ebuild maintenance a little bit easier, at the expense of
being less "correct" and unknown configure option warnings useless

The helpers themselves are listed below in order of the number of
packages using them:

cmake-utils_use_with135
cmake-utils_use_enable  106
cmake-utils_use_build   89
cmake-utils_use_find_package75
cmake-utils_use_use 37
cmake-utils_use_disable 14
cmake-utils_use_want10
cmake-utils_use_has 8
cmake-utils_use_no  3
cmake-utils_useno   2

What do you think?

Re: [gentoo-dev] EAPI 6 portage is out!

[Raymond Jennings]

On Wed, Nov 18, 2015 at 1:25 AM, Alexander Berntsen 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 18/11/15 08:25, Ulrich Mueller wrote:
> > - If you mix stable and unstable then you are by definition an
> > advanced user, who will be able to cope with the situation. :)
> This attitude is shitty, and I am willing to wager a really big bunch
> of users fall into this category.
>

I second the motion.

I can vouch for myself as such a user who often uses unstable packages to
get new features or dodge bugs in the stable versions.

As a general default, though, I stick with stable packages.

Taking an occasional unstable package in an otherwise stable system (and
obeying any revbump directives provoked by dependencies) is a legal
operation that is actually supported by commit rules that prohibit stable
versions from depending on unstable versions of dependencies.

Why would that policy exist if mixing stable and unstable were unsupported?

I don't think EAPI 6 is *that* shiny, that we need to start using it
> prior to stable Portage supporting it. It's a potential mess for a
> huge portion of our users.
>
>
> That said, I'd like to extend my thanks to Micha? for working on this.
> - --
> Alexander
> berna...@gentoo.org
> https://secure.plaimi.net/~alexander
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCgAGBQJWTEQCAAoJENQqWdRUGk8BrQ0P/j4ZDShZNWtvyw/QtCSgY5+i
> CTYx2cqv0+dmtIE4pdteaf535I8Ax7WH9c1OnTbMl1taAmTvEIulQUof64rjz/PB
> t5csfLQqgNV6w0ck5g6+dJq2iNgC65QpPbtENXYOwkq6bo9Zs1KFuodq6b0y9M7y
> 7Wk3gLIzjZBwXFpEbSupu0lM3nS/RPUJ20SH0aUfkpxgUVJJr5UENsxPyk8XzETf
> caJyfGmb5LcNVKmq6bRUA67KPzAWtQJTw2eUHyyTd0lob1QVIKDwizFXA5ZxCPsC
> PrZZ7txyOEiKdOOupF2HYlit2pWCITaS1ELyzr9aKDsRB4+WsrvuSA0JuRUNV9yn
> PP4aocOpmSbGiuYsQl2kvZcuEipVjqFc+iqZAW6HQlf6/v2LMOTSeCp1lpwLEbxQ
> zvK29IdR0uOQDctI3i0X0arV0CW/C3DVxdHlyxHMMKgjmCmr2lPmB+xPSzpU1aYE
> kB8+9l82PjoBvI5+A3S0ynACF4c018NrIDWC+RLgPh3KfBw2yiXRZOouW1snfXca
> 7Rqv5BDaURKuwlfckl2mNG5bWCq0jc2K+Rru9JcgviX7HaAO3SBIhH1g860Xi9Nn
> UN4CoXZohXph8XD/o6CEu+TD4puu5H1xMGsDkD5PihGsxnYyhR9pJdlz0nf5ZuPk
> p8r78oHdqMX2Sb7LmUh1
> =WAIc
> -END PGP SIGNATURE-
>
>

Re: [gentoo-dev] EAPI 6 portage is out!

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 18/11/15 08:25, Ulrich Mueller wrote:
> - If you mix stable and unstable then you are by definition an 
> advanced user, who will be able to cope with the situation. :)
This attitude is shitty, and I am willing to wager a really big bunch
of users fall into this category.

I don't think EAPI 6 is *that* shiny, that we need to start using it
prior to stable Portage supporting it. It's a potential mess for a
huge portion of our users.


That said, I'd like to extend my thanks to Micha? for working on this.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWTEQCAAoJENQqWdRUGk8BrQ0P/j4ZDShZNWtvyw/QtCSgY5+i
CTYx2cqv0+dmtIE4pdteaf535I8Ax7WH9c1OnTbMl1taAmTvEIulQUof64rjz/PB
t5csfLQqgNV6w0ck5g6+dJq2iNgC65QpPbtENXYOwkq6bo9Zs1KFuodq6b0y9M7y
7Wk3gLIzjZBwXFpEbSupu0lM3nS/RPUJ20SH0aUfkpxgUVJJr5UENsxPyk8XzETf
caJyfGmb5LcNVKmq6bRUA67KPzAWtQJTw2eUHyyTd0lob1QVIKDwizFXA5ZxCPsC
PrZZ7txyOEiKdOOupF2HYlit2pWCITaS1ELyzr9aKDsRB4+WsrvuSA0JuRUNV9yn
PP4aocOpmSbGiuYsQl2kvZcuEipVjqFc+iqZAW6HQlf6/v2LMOTSeCp1lpwLEbxQ
zvK29IdR0uOQDctI3i0X0arV0CW/C3DVxdHlyxHMMKgjmCmr2lPmB+xPSzpU1aYE
kB8+9l82PjoBvI5+A3S0ynACF4c018NrIDWC+RLgPh3KfBw2yiXRZOouW1snfXca
7Rqv5BDaURKuwlfckl2mNG5bWCq0jc2K+Rru9JcgviX7HaAO3SBIhH1g860Xi9Nn
UN4CoXZohXph8XD/o6CEu+TD4puu5H1xMGsDkD5PihGsxnYyhR9pJdlz0nf5ZuPk
p8r78oHdqMX2Sb7LmUh1
=WAIc
-END PGP SIGNATURE-