date:20120523

On Wed, 23 May 2012 23:09:14 -0700
Zac Medico  wrote:

> On 05/23/2012 11:11 PM, Ryan Hill wrote:
> > On Mon, 21 May 2012 21:04:44 +0200
> > Pacho Ramos  wrote:
> > 
> >> Looks like ebuilds not inheriting eutils directly even using epatch are
> >> a lot as I have seen running:
> >> grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
> >> eutils
> >>
> >> Maybe they should be checked and a repoman warning should be added when
> >> an ebuild is using epatch without inheriting eutils directly, otherwise
> >> this problem could reappear if some other eclass no longer inherit it in
> >> the future :-/
> > 
> > Maybe we should make eutils inheritance implicit so all ebuilds get epatch
> > and friends automatically.  Is there really that much overhead?  Or am I
> > missing something obvious?
> 
> Do you mean in EAPI 5? We're already planning to include epatch, as part
> of the epatch_user thing.

I did.  That's awesome, thanks.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!

2012-05-23 Thread Zac Medico

On 05/23/2012 11:11 PM, Ryan Hill wrote:
> On Mon, 21 May 2012 21:04:44 +0200
> Pacho Ramos  wrote:
> 
>> Looks like ebuilds not inheriting eutils directly even using epatch are
>> a lot as I have seen running:
>> grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
>> eutils
>>
>> Maybe they should be checked and a repoman warning should be added when
>> an ebuild is using epatch without inheriting eutils directly, otherwise
>> this problem could reappear if some other eclass no longer inherit it in
>> the future :-/
> 
> Maybe we should make eutils inheritance implicit so all ebuilds get epatch
> and friends automatically.  Is there really that much overhead?  Or am I
> missing something obvious?

Do you mean in EAPI 5? We're already planning to include epatch, as part
of the epatch_user thing.
-- 
Thanks,
Zac

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Dan Douglas

On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote:
> On Wed, 23 May 2012 16:14:53 -0500
>
> Dan Douglas  wrote:
> > If not I will be leaving Gentoo for Funtoo in the near future, though
> > there are disadvantages to doing this I don't look forward to dealing
> > with.
>
> Most of us will probably be doing that :P.

Eh sorry that wasn't meant to be antagonistic. I'll still have Gentoo boxen to
deal with. I just need to be able to use git on the tree (even without the
full history is perfectly fine) to ease the difficulty of local overlay
management. Glad to hear that will be possible, or at least somewhat easier.
--
Dan Douglas

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

[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!

On Mon, 21 May 2012 21:04:44 +0200
Pacho Ramos  wrote:

> Looks like ebuilds not inheriting eutils directly even using epatch are
> a lot as I have seen running:
> grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
> eutils
> 
> Maybe they should be checked and a repoman warning should be added when
> an ebuild is using epatch without inheriting eutils directly, otherwise
> this problem could reappear if some other eclass no longer inherit it in
> the future :-/

Maybe we should make eutils inheritance implicit so all ebuilds get epatch
and friends automatically.  Is there really that much overhead?  Or am I
missing something obvious?


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

On Wed, 23 May 2012 16:14:53 -0500
Dan Douglas  wrote:

> If not I will be leaving Gentoo for Funtoo in the near future, though
> there are disadvantages to doing this I don't look forward to dealing
> with.

Most of us will probably be doing that :P.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!

On Wed, 23 May 2012 11:28:13 +0300
Petteri Räty  wrote:

> On 22.5.2012 8.53, Michał Górny wrote:
> >> Excuse me but the way this change was handled is a bit depressing.
> >> First, the ebuilds should have been fixed to inherit eutils and then
> >> remove eutils from autotools. Now, a bunch of ebuilds are broken out
> >> of nowhere. I don't believe this issue was that urgent in order to
> >> justify the significant breakage of portage tree.
> > 
> > First of all, to quote devmanual:
> > 
> > | Before updating eutils or a similar widely used eclass, it is best to
> > | email the gentoo-dev list. It may be that your proposed change is
> > | broken in a way you had not anticipated> [...]. If you don't email
> > | gentoo-dev first, and end up breaking something, expect to be in a
> > | lot of trouble.
> > 
> > Not that this disrespect for this rule is something new...
> > 
> 
> Even more important is the next chapter:
> 
> "When removing a function or changing the API of an eclass, make sure
> that it doesn't break any ebuilds in the tree, and post a notice to
> gentoo-dev at least 30 days in advance, preferably with a patch included."
> 
> This qualifies as changing the API of an eclass. This chapter comes from
> a council decision:
> 
> http://www.gentoo.org/proj/en/council/meeting-logs/2008-summary.txt

I don't see how removing an inherit is breaking an eclass' API.  The
functionality of the eclass itself does not change.  Yes if you want to get
technical you previously had access to functions from other eclasses by
reaching through it, but that's a side effect that shouldn't be relied upon.
If we do, then making a change to an eclass not only requires an audit of all
the ebuilds using that eclass, but also any eclasses that inherit it and all
of their ebuilds and so on and so forth. Ebuilds should be inheriting what
they need, not relying on other eclasses to do it for them (the exception of
course is "meta" or "base" type eclasses like kde, gnome, or java (i think?)
that are designed to work this way).  The breakage here is a perfect example
how a simple change can have consequences that even a senior developer can
overlook when this practice isn't followed.

That said, I do think adding the eutils inherit back until people can audit
their ebuilds seems like the sanest thing to do.  Normally I'd say just fix
your ebuilds, but I hate it when stable breaks.

-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

signature.asc
Description: PGP signature

Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass

On Thu, 24 May 2012 02:43:47 +0200
hasufell  wrote:

>   -s|--size)
>   if [[ ${2%%x*}x${2%%x*} == "$2" ]] ; then
>   size=${2%%x*}
>   else
>   size=${2}
>   fi
>   case ${size} in
>   16|22|24|32|36|48|64|72|96|128|192|256)
>   size=${size}x${size};;
>   scalable)
>   ;;

Not that anyone would care enough to try to understand what magic is
happening there... Please reimplement in Perl.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Matt Turner

On Wed, May 23, 2012 at 3:37 PM, Arun Raghavan  wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.
> --
> Arun Raghavan
> http://arunraghavan.net/
> (Ford_Prefect | Gentoo) & (arunsr | GNOME)

I seriously cannot tell this is serious, trolling, or sarcasm. If it's
either of the latter two, can we please cut that out? Way too often
sarcasm and inside jokes are misunderstood and we waste a lot of
bandwidth figuring it out.

[gentoo-dev] Re: Remove eclass/ChangeLog

On Wed, 23 May 2012 11:02:58 +0300
Samuli Suominen  wrote:

> On 05/23/2012 05:36 AM, Ryan Hill wrote:

> > One person doesn't do entries.  OMG let's remove it!

> absolutely because inconsitency renderess the file useless

Perfect is the enemy of good enough.  Stuck in a cabin for the weekend
without cvs access, it was handy enough for me.

When we switch to git 4-8 years from now, then yes, kill it.  Until then,
leave it alone please.

-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

signature.asc
Description: PGP signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Mark Wright

Michael Weber  writes:
> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).

+1 for clean cut to git

[gentoo-dev] Re: enhancement for doicon/newicon in eutils.eclass

On 05/21/2012 01:24 AM, hasufell wrote:
> I want support for installing icons into the appropriate directories
> which are under /usr/share/icons/... and not just pixmaps.
> 
> proposal attached + diff
> 
> This should not break existing ebuilds. Tested a bit and open for review
> now.

next version
# @FUNCTION: _iconins
# @DESCRIPTION:
# function for use in doicon and newicon
_iconins() {
(
# wrap the env here so that the 'insinto' call
# doesn't corrupt the env of the caller
local size dir
local context=apps
local theme=hicolor

while [[ $# -gt 0 ]] ; do
case $1 in
-s|--size)
if [[ ${2%%x*}x${2%%x*} == "$2" ]] ; then
size=${2%%x*}
else
size=${2}
fi
case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256)
size=${size}x${size};;
scalable)
;;
*)
eerror "${size} is an unsupported icon size!"
exit 1;;
esac
shift 2;;
-t|--theme)
theme=${2}
shift 2;;
-c|--context)
context=${2}
shift 2;;
*)
if [[ -z $size ]] ; then
insinto /usr/share/pixmaps
else
insinto 
/usr/share/icons/${theme}/${size}/${context}
fi

if [[ $function == doicon ]] ; then
if [[ -f $1 ]] ; then
doins "${1}"
elif [[ -d $1 ]] ; then
shopt -s nullglob
doins "${1}"/*.{png,svg}
shopt -u nullglob
else
eerror "${1} is not a valid 
file/directory!"
exit 1
fi
else
break
fi
shift 1;;
esac
done
if [[ $function == newicon ]] ; then
newins "$@"
fi
) || die
}

# @FUNCTION: doicon
# @USAGE: doicon [options] 
# @DESCRIPTION:
# Install icon into the icon directory /usr/share/icons or into
# /usr/share/pixmaps if "--size" is not set.
# This is useful in conjunction with creating desktop/menu files.
#
# @CODE
#  options:
#  -s, --size
#!!! must specify to install into /usr/share/icons/... !!!
#size of the icon, like 48 or 48x48
#supported icon sizes are:
#16 22 24 32 36 48 64 72 96 128 192 256 scalable
# -c, --context
#defaults to "apps"
# -t, --theme
#defaults to "hicolor"
#
# icons: list of icons
# @CODE
#
# example 1:
#doicon foobar.png fuqbar.svg
#results in: insinto /usr/share/pixmaps ; doins foobar.png fuqbar.svg
#
# example 2:
#doicon -s 48 foobar.png fuqbar.png
#results in: insinto /usr/share/icons/hicolor/48x48/apps ; doins foobar.png 
fuqbar.svg
#
doicon() {
local function=$FUNCNAME
_iconins "$@"
}

# @FUNCTION: newicon
# @USAGE: newicon [options]  
# @DESCRIPTION:
# Like doicon, install the specified icon as newname.
#
# example 1:
#newicon foobar.png NEWNAME.png
#results in: insinto /usr/share/pixmaps ; newins foobar.png NEWNAME.png
#
# example 2:
#newicon -s 48 foobar.png NEWNAME.png 
#results in: insinto /usr/share/icons/hicolor/48x48/apps ; newins 
foobar.png NEWNAME.png
#
newicon() {
local function=$FUNCNAME
_iconins "$@"
}

Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/24/2012 02:30 AM, Mike Frysinger wrote:
> On Wednesday 23 May 2012 20:16:12 hasufell wrote:
>> Thanks, I'v implemented most of that, but your proposal about 
>> non-duplicated list in case) has multiple problems. The only
>> cases that actually work with that snippet are: 
>> 16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|scalable. 
>> All others will fail (like 128x128 or just 48).
> 
> so do: size= if [[ $2 == "scalable" ]] ; then size=$2 elif [[
> ${2%%x*}x${2%%x*} == "$2" ]] ; then size=${2%%x*} case ${size} in 
> 16|22|24|32|36|48|64|72|96|128|192|256) ;; *) size= ;; esac fi 
> -mike

alright

this would work


-s|--size)
if [[ ${2%%x*}x${2%%x*} == "$2" ]] ; then
size=${2%%x*}
else
size=${2}
fi
case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256)
size=${size}x${size};;
scalable)
;;
*)
eerror "${size} is an unsupported icon size!"
exit 1;;
esac
shift 2;;

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPvYRDAAoJEFpvPKfnPDWz8DgIAIA3T7GLWeN1m+8vfyeaVMXj
7UWyBXEcCU5geYqi5KsuY8/0Mq0e47ER+EH3VU+CrbV+UlDxxbyzsF4cqMRq/Oe+
Zz5CmSv4vjAfOyVe9psChue9PnKQwe/w6sS+L9zBftIzCb8G48Eefiir7lp9p7HO
9M5KkLeJwThDkUfhNUKtbNdIf1clnT1GVNrvcPuuasARN/of4ClQVVRISXKKHZen
9yA4D876CxtyN0jBHn78pRg0kZwSPL3PqucIQjli+usvGONX+LWuc7uWFJk8hnHI
E9cJrbUvkSJZx07ajEK1maohJBkfZdVWWxCGtZk0T00Kd2Nyy7o9SFX1hXX3F4I=
=/kaW
-END PGP SIGNATURE-

Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/24/2012 02:30 AM, Mike Frysinger wrote:
> On Wednesday 23 May 2012 20:16:12 hasufell wrote:
>> Thanks, I'v implemented most of that, but your proposal about 
>> non-duplicated list in case) has multiple problems. The only
>> cases that actually work with that snippet are: 
>> 16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|scalable. 
>> All others will fail (like 128x128 or just 48).
> 
> so do: size= if [[ $2 == "scalable" ]] ; then size=$2 elif [[
> ${2%%x*}x${2%%x*} == "$2" ]] ; then size=${2%%x*} case ${size} in 
> 16|22|24|32|36|48|64|72|96|128|192|256) ;; *) size= ;; esac fi 
> -mike

that will install
doicon -s 256x256 "${FILESDIR}"/${PN}.svg
into
/usr/share/icons/hicolor/256/apps/${PN}.svg

and

doicon -s 256 "${FILESDIR}"/${PN}.svg
into
/usr/share/pixmaps/${PN}.svg


I don't see the point in bothering with that.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPvYNeAAoJEFpvPKfnPDWzXeEIAKAK+c/+xkt4UIS2xLK9SGMQ
U1DwEqtiiytYvpB84QYrYjnoEMZrZN76uv6GsFtDYQC1nS5PDJt6F8yhGldF5CWr
UrD12iiIVIi3gLvkWVyfdhX3gA4wn/CL8Vq00R2oIMjy00uTBcYUmFV9X7xJzIxz
zyXhZBsXSpdnqZ1x9+nc9m9zy77Y7FIwA1dR9bWhBsiYMshUjTtGlIBE3uzm6v4Z
qKzhwKoG67jKFQuMyu495VSGGjXIJ0wuNofA2GRWLYZc5xP2nmeG5Q70vpM0CRiI
5Y2epr8thqbX53tsIxyJKqSwvqHGIKItChD0av9saIUa2D0KaUEiRrRN+m6cJuM=
=YxUg
-END PGP SIGNATURE-

Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass

2012-05-23 Thread Mike Frysinger

On Wednesday 23 May 2012 20:16:12 hasufell wrote:
> Thanks, I'v implemented most of that, but your proposal about
> non-duplicated list in case) has multiple problems. The only cases
> that actually work with that snippet are:
> 16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|scalable.
> All others will fail (like 128x128 or just 48).

so do:
size=
if [[ $2 == "scalable" ]] ; then
size=$2
elif [[ ${2%%x*}x${2%%x*} == "$2" ]] ; then
size=${2%%x*}
case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256) ;;
*) size= ;;
esac
fi
-mike


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

Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/22/2012 04:49 AM, Mike Frysinger wrote:
> On Sunday 20 May 2012 19:24:13 hasufell wrote:
>> case ${2} in
> 
> please use $1/$2/etc... with positional variables when possible
> 
>> 16|22|24|32|36|48|64|72|96|128|192|256) size=${2}x${2};; 
>> 16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|128x128|
> 192x192|256x256)
>> size=${2};; scalable) size=scalable;; *) eqawarn "${2} is an
>> unsupported icon size!" ((++ret));; esac
> 
> you can write this w/out having to duplicate two lists: size= if [[
> $2 == "scalable" ]] ; then size=$2 elif [[ ${2:0:2}x${2:0:2} ==
> "$2" ]] ; then size=${2:0:2} case ${size} in 
> 16|22|24|32|36|48|64|72|96|128|192|256) ;; *) size= ;; esac fi if
> [[ -z ${size} ]] ; then eqawarn "${2} is an unsupported icon
> size!" ((++ret)) fi shift 2
> 
> shift 2;; -t|--theme) theme=${2} shift 2;; -c|--context) 
> context=${2} shift 2;; *)
>> if [[ -z ${size} ]] ; then dir=/usr/share/pixmaps else 
>> dir=/usr/share/icons/${theme}/${size}/${context} fi  insinto
>> "${dir}"
> 
> considering you only use $dir once, you could just call `insinto`
> directly on the path rather than using the dir variable at all
> 
>> elif [[ -d ${1} ]] ; then for i in "${1}"/*.{png,svg} ; do doins
>> "${i}" ((ret+=$?)) done
> 
> why loop ?  `doins "${1}"/*.{png,svg}` works just as well
> 
> you probably want to enable nullglobbing here, otherwise this will
> cause problems if you try to doicon on a dir that contains just
> svg.
> 
> also, what about other file types ?  people install xpm, svgz, gif,
> and other file types ...
> 
>> exit ${ret}
> 
> bash masks error codes to [0..255], so all the ret updates should
> probably be changed to just: ret=1
> 
> after all, i doubt anyone cares how many errors there were, just
> that one occurred.  and while you're here, might want to make it
> auto die on failure like we've done with all our other helpers. 
> -mike

Thanks, I'v implemented most of that, but your proposal about
non-duplicated list in case) has multiple problems. The only cases
that actually work with that snippet are:
16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|scalable.
All others will fail (like 128x128 or just 48).
So it would end up like this:

case $1 in
-s|--size)
if [[ ${2:0:2}x${2:0:2} == "$2" ]] ; then
size=${2:0:2}
elif [[ ${2:0:3}x${2:0:3} == "$2" ]] ; then
size=${2:0:3}
else
size=${2}
fi
case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256)
size=${size}x${size};;
scalable)
;;
*)
eerror "${size} is an unsupported icon size!"
exit 1;;
esac
shift 2;;
-t|--theme)


This does not really look cleaner than just using two lists. I would
prefer the latter for readability.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPvX3MAAoJEFpvPKfnPDWzxvMH/16kN1Zkby6LHg2Ev7H2qNPh
ajbqVonTuuLnIVxEwXYXYABEkF+qwD5xnJPMEclvkn8FXAVerFeyaxJgBelldXnr
DJMHiPhz0umJaMfvAFrEsbIo5IrxKMTpMMj3fuu5ruQMrSboV4alPSM7l2haXZ5W
3TbfbFmWoQzft1DolDlFb38M0TtRko7viZ1KQJUZjxCEClh8tEiOrQVxR8xcoi33
MiwEVZlib4KnWetq3qGZdU+xRFi/yzUmtFVv0pfbYIV51w4KHoi8cD6OkpiVzLdI
bhWCmyDeKq6wOcfXfcfGKzYc+2M/hP8xkhiG3/KjDXe6FUzdG63+U1Wmu521VDM=
=Rn8t
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/23/2012 11:14 PM, Dan Douglas wrote:
> On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
>> 2. rsync generation is NOT going away. Users will still be using
>> it.

First, I'd stick with the current rsync to spread the tree (mirror
work and mirrors+regular rsync users shouldn't notice any backend
switch at all).


> Would users have a way of gaining read-only access? This would be
> EXTREMELY helpful.
Sure, this would be possible like any other git checkout
(layman-git-overlays, github.com, etc.).

Please compare (browsing source and access description)
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/
http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git


- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW
xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh
=dvFZ
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Dan Douglas

On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
> 2. rsync generation is NOT going away. Users will still be using it.
Would users have a way of gaining read-only access? This would be EXTREMELY 
helpful. If not I will be leaving Gentoo for Funtoo in the near future, though 
there are disadvantages to doing this I don't look forward to dealing with.
-- 
Dan Douglas

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

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread William Hubbs

On Wed, May 23, 2012 at 10:37:55PM +0200, Michał Górny wrote:
> On Wed, 23 May 2012 15:25:54 -0500
> William Hubbs  wrote:
> 
> > On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote:
> > > I, for one, think we should stay with CVS and leave all this git
> > > Linusware to the new-fangled Fedora kids with their fancy init
> > > systems and tight coupling. CVS was good enough for my grandfather,
> > > and it's good enough for you.
> > 
> > I hope this is sarcasm or a joke?
> 
> Obviously. His grandfather used SCCS.

Heh, that's possible, or maybe he even used prodos [1], which was pretty
cool for its time.

William

[1] http://en.wikipedia.org/wiki/PRODOS


pgp4O14kFI8pz.pgp
Description: PGP signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/23/2012 07:06 PM, Alexey Shvetsov wrote:

> Isnt cvs too sloow on mips? git is much more faster. Same for arm. 
> About big repos, well why not use shallow cloned repo. It will work
> with plane history

Can we please cut that out.
I do/did arch testing on arm5, ppc, sparc on rsync trees and committed
the changes from my shiny 2007s notebook.
I did hesitate to spread my commit credentials over all these machines.

Michael
- -- 
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+9Sv8ACgkQknrdDGLu8JBFLAEAghjKAQwckMndZfO/gGQyVI3N
butEASSJZYQetyNthUgA/3e5Sf9B93ED/wDSDflKP7YwTVwiFOe5c65Md4vdEsQs
=FW7S
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

On Wed, 23 May 2012 15:25:54 -0500
William Hubbs  wrote:

> On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote:
> > I, for one, think we should stay with CVS and leave all this git
> > Linusware to the new-fangled Fedora kids with their fancy init
> > systems and tight coupling. CVS was good enough for my grandfather,
> > and it's good enough for you.
> 
> I hope this is sarcasm or a joke?

Obviously. His grandfather used SCCS.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/23/2012 06:58 PM, Justin wrote:
> Was this a vote for or against a quick proceeding towards git?
No, just to decide if git-cvsserver (providing cvs access) should be
part of an "git master tree" szenario.

In bugzie: Should https://bugs.gentoo.org/333699 stay a blocker of
https://bugs.gentoo.org/333531.

No flame about "git over cvs" in general, whether or not sparse
checkouts (i.e. w/o kde-*,gnome-* categories) make sense.

Michael
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+9SfMACgkQknrdDGLu8JCGtQEAiS3Wcsll94w2rqlMP2WpSypU
fLdxa2wjstJ5Y/2iXCcA+wX/p+OwBzjLAxiwKnSl98XlLSIT/Qsxm5H1TvEEJ71w
=k8j9
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

On Wed, May 23, 2012 at 4:00 PM, Ezequiel Garcia  wrote:
> On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan  
> wrote:
>> I, for one, think we should stay with CVS and leave all this git
>> Linusware to the new-fangled Fedora kids with their fancy init systems
>> and tight coupling. CVS was good enough for my grandfather, and it's
>> good enough for you.
>
> Perhaps it would be instructive if you could tell us one advantage of
> cvs over git.
>

Sure.  The slow commit rate encourages careful deliberation before
hitting the enter key, which therefore improves quality.

Then, if you do make a mistake the slow commit rate means that fixing
that mistake can take a long time, which increases the amount of pain
our end-users run into due to the mistake, which leads to lots of
flame wars on -dev.  That means that the guy who made the mistake is
subjected to more public ridicule, and is less likely to do it again,
That improves quality too.

Since cvs doesn't tie together tree-wide changes in a nice way or
allow them to be transactionally completed, individual package
maintainers don't need to be as concerned with the big picture view.
Now as the maintainer of libfoo the fact that somebody changed my
ebuild without making a corresponding change in some profile is
completely hidden from me, and I can go to sleep peacefully without
realizing that my users are all going to have horribly broken systems
in the morning.  Blissful ignorance of end-user suffering improves
developer morale, and helps get rid of pesky users at the same time.

cvs also makes more more aware of what is going on around me.  Anytime
I want to work on something in parallel with the main development
branch I get to manually merge changes in, which keeps me aware of my
place in the world.  That means that I'm less likely to build nice new
features, which means fewer bugs, which improves quality, and may even
drive away users as an added bonus!

See, cvs is really the wave of the future!

Rich

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread William Hubbs

On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.

I hope this is sarcasm or a joke?

William



pgp8HVeq1dZv3.pgp
Description: PGP signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver


Arun Raghavan писал 2012-05-23 22:37:

I, for one, think we should stay with CVS and leave all this git
Linusware to the new-fangled Fedora kids with their fancy init 
systems

and tight coupling. CVS was good enough for my grandfather, and it's
good enough for you.


CVS is damn slow. On every cvs up it should stat *all* files and cvs 
entryes
in current state its ~212k files in gentoo-x86. It will be sloow on 
every machine unless you put all this files in ram


Actual number of usefull files is only about ~60k 
(ebuilds,eclasses,metadata.xml,patches)


Its comparable to linux kernel git tree ~42k files

And yes git is much more faster.

PS  if ibm s/360 was good for my grandfather why we all use modern 
intel pc? Lets stay under 1 MIPS machines like s/360



--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Ezequiel Garcia

On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan  wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.


Perhaps it would be instructive if you could tell us one advantage of
cvs over git.

(This is me exposing me to your terrible dev-flames, I was feeling too cold ;)

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

+1 for git

I am more used to it, I find it easier to use regarding the utilities
as well as the gui and it is more consistent.
The fact alone that I can update a single directory in CVS without
updating all others can cause breakage, cause repoman checks may be
erroneous.


On 05/23/2012 09:37 PM, Arun Raghavan wrote:
> I, for one, think we should stay with CVS and leave all this git 
> Linusware to the new-fangled Fedora kids with their fancy init
> systems and tight coupling. CVS was good enough for my grandfather,
> and it's good enough for you.

This sounds rather emotional to me.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPvT/OAAoJEFpvPKfnPDWzgPIH/38QflM4GNiUNo3bC5/8tock
FM03JE1Iln4ThvLl25opwGiO5R8akoD3koroUVPLoWV//QfYmcQIm7k7dJJCk4+m
WSQ6H21fL9v2m6QX7PuJwaENFSFBxu3UFy6BE+39iFJAPBiigH1hbE0rad/twYdr
xhnHZti1rGbaFBeXxlGmdhJYi7dtndyuZgTu0oQFfE0+sAAK2GPe5CGLoOFHdtxS
WCMY3C3cB0R7XPoJwUvvt2KmIEXNWfq6rDW3o6so89VdRSNykwMLdK1eZ+MZidIE
61CAJiuIsT4cKX5pbqo72GtU4tUOkQ6jjaJhofAcrSMYKA0IsxYvFAYnKqO4lh4=
=cdBk
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Fabio Erculiani

On Wed, May 23, 2012 at 9:37 PM, Arun Raghavan  wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.

The difference is that while Git is much faster, comes with a very low
WTF/secs rate and really forces you to do things the right way, other
L*e software is not and I agree with you on this.

my 0.02c ;-)

> --
> Arun Raghavan
> http://arunraghavan.net/
> (Ford_Prefect | Gentoo) & (arunsr | GNOME)
>

-- 
Fabio Erculiani

Re: [gentoo-dev] Remove eclass/ChangeLog

2012-05-23 Thread Ian Stakenvicius

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23/05/12 03:23 PM, hasufell wrote:
> On 05/20/2012 03:25 PM, Michał Górny wrote:
>> On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominen 
>>  wrote:
> 
>>> ChangeLog entries missing for every autotools.eclass 
>>> modification today.
> 
>> I will repeat once again: autogenerate them.
> 
> 


Isn't one of the reasons the changelog is there, is so that eclass
changes can be committed with repoman and (with the newer repoman) the
- -m comment will automatically be added to the ChangeLog ??


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk+9Pn0ACgkQ2ugaI38ACPCtogEAh1/FLYMho2HaSyg7e6JDtwcW
UTAPNaD3WPFGyJbO/ZMA/0gh1Ale/msPdzlJyYBny6rDtCjkUNCAP2zwwk+KXV5R
=tdxA
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Nirbheek Chauhan

On Thu, May 24, 2012 at 1:07 AM, Arun Raghavan  wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.
>

+1

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Arun Raghavan

I, for one, think we should stay with CVS and leave all this git
Linusware to the new-fangled Fedora kids with their fancy init systems
and tight coupling. CVS was good enough for my grandfather, and it's
good enough for you.
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] Remove eclass/ChangeLog

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/20/2012 03:25 PM, Michał Górny wrote:
> On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominen
>  wrote:
> 
>> ChangeLog entries missing for every autotools.eclass
>> modification today.
> 
> I will repeat once again: autogenerate them.
> 

+1

I think it is nice to be able to use a different changelog entry than
commit message, but autogenerated entries would be more consistent.

Having ChangeLog files at all is just a convenience, but an important
one imo. It's the quickest way to track down sudden breakage.

scm comments are _not_ the same as a single file holding information
on all changes to an entire directory.


As for the given case I demand that the missing ChangeLog entries will
be added now by vapier, cause it seems they have already caused
breakage: #417265
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPvTkrAAoJEFpvPKfnPDWzG5UIAIKFaGAXYGiyLBwbeQ1QxdlD
wndZJIXN9pWwDU/F3uyKqmHqNC1Aqf7U7g88ue/1FhSSyJeG+rEH1Qmym0Eb3fIe
hECZKWHMV/CDe2VhgGZ+dKvq3Pxz/nGt994NurLbBRWPCY2md63M45+499gb32w0
5wpYcH8vXw/noHvfw4o77Pwzu+5yphDWycOFtrc/UWIK0NXQZLzalnYqwl2HjHKE
vRWn/eAcTL+TzkS/pM7RI4BCROl3Rmk+jmkgeIOAlVlcpYEa41FB5wv7t3HdGM3i
AWiQySQ8iKehH4Blr97czn30hqekI6ACD08hEhiFZeA7JJYRT4ziYS1lapBzGFk=
=u07L
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Rafael Goncalves Martins

-1


-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

Re: [gentoo-dev] Re: Remove eclass/ChangeLog

2012-05-23 Thread Markos Chandras

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/23/2012 05:46 PM, Michał Górny wrote:
> On Wed, 23 May 2012 12:29:34 -0400 Rich Freeman 
> wrote:
> 
>> On Wed, May 23, 2012 at 4:02 AM, Samuli Suominen 
>>  wrote:
>>> On 05/23/2012 05:36 AM, Ryan Hill wrote:
 One person doesn't do entries.  OMG let's remove it!
 
>>> 
>>> absolutely because inconsitency renderess the file useless
>>> 
>> 
>> Well, for now the solution is to enforce following policy.
>> 
>> For the future, perhaps the policy's time has ended.  Sure,
>> Changelogs can be handy, but they are increasingly redundant and
>> scm comments have the potential to be far more useful.  By all
>> means require meaningful scm commit comments, but if Changelog
>> files are holding us back either auto-generate them or ditch
>> them.
> 
> ChangeLogs could be fine for ebuilds. But for more broad cases
> like eclasses, one can usually have a set of changes prepared for
> commit. With CVS, it's PITA but with git it's already much better.
> Of course, it all fails if every commit has to update a randomly
> changed, shared file called ChangeLog...
> 

So we did we introduce changelogs for eclass/ in the first place if
everyone is happy with getting rid of them?

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBCgAGBQJPvSyUAAoJEPqDWhW0r/LCrp0QAIwYhxeO5qeYaCrh3B7WCd3X
pt8cMAquC38VOIjfd+Lz+iG2+8ftYb1s5xQu52F6zZEkbwxCLmYBKJrnpNljSm8T
QAmB4xXg4vKxjpwAyc+fOev53HZdQyzav36m1DhOEXZKixI+OR1MplZ55VlEAT0+
wRPJj9+WsiTMONRkuukCCJtvnY1kDjJLtjNDzUA4QSxh+pgcgAPGoDMh5nL706h5
KW5/jBTW01+oEWyBosXxBUoX8p2/FvAG1Meib0BbEBdsyrYdQSDJK2xMjK0JJ7PH
QhOeA2NameaFA1YzvebB7KDNSGB3zMm1TdnYmhfU1jmWImyB1BQvdFT37KcvZagQ
WhErwHxDojz27lhiCHY95nPDATMxxiC61WdBLoByV93xRAqwnpeSva26hV1Nv552
n3nZ5DWCKRF+qSSEo1Oz3DCtDxV5ygyOw8iHOhqhZ5IcuNIchfYgss/dCFRRy3zy
uN8l/wge7J0MjOVKBnpT9nWmmwhB4pD+o3Avq2OBwuDrqAW7iYKkTPzQwsIq7ZGI
HTvtMhOrULIkm/2c77FGXdFwJWMPueroUe4LntY/0c2l30P2Fafe0sEp5yCjzCeA
uXwWC0iWTPuVBYGFJQ5iZqB3X+LAVWz2HLpqZRJ9qW4X3QXSuXsrr5wdAukjAUCu
8qMUNncYeLeHvdeazWey
=/lXi
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Chí-Thanh Christopher Nguyễn

Alexey Shvetsov schrieb:
>> Shallow clones are also read-only last I checked.
> 
> That isnt true =) you can commit from shallow clone  if and only if
> original repo doesnt have a branching and merging points before and
> after shallow clone point respectively

There can also be breakage when someone reverts a commit that it is not
part of your shallow clone's history, and then you pull.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

On Wed, May 23, 2012 at 01:32:45PM -0400, Rich Freeman wrote:
> On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov  wrote:
> >
> > That isnt true =) you can commit from shallow clone  if and only if original
> > repo doesnt have a branching and merging points before and after shallow
> > clone point respectively
> Is that going to be a practical condition to maintain?
We're going to have lots of branches and merges.

> And how big will the repository actually be?  Are we talking a GB or
> two, or something orders of magnitude larger?
In terms of repo size, we were going to be slicing the history into two
parts:
- fresh start
- historical

The 'fresh start' is what new commits will go on top of, and ranges
40-120MB depending on what git window compression is used.
The historical is ~1.2GB, and if you want a continuous history, you just
use graft to merge the two.

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

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver


Rich Freeman писал 2012-05-23 20:32:
On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov  
wrote:


That isnt true =) you can commit from shallow clone  if and only if 
original
repo doesnt have a branching and merging points before and after 
shallow

clone point respectively



Is that going to be a practical condition to maintain?

And how big will the repository actually be?  Are we talking a GB or
two, or something orders of magnitude larger?

Rich



Full clone will be about 1G or so but no more then 2. If we will drop 
changelog it will be much smaller


--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov  wrote:
>
> That isnt true =) you can commit from shallow clone  if and only if original
> repo doesnt have a branching and merging points before and after shallow
> clone point respectively
>

Is that going to be a practical condition to maintain?

And how big will the repository actually be?  Are we talking a GB or
two, or something orders of magnitude larger?

Rich

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver


Robin H. Johnson писал 2012-05-23 20:19:

On Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote:

Isnt git works with shallow clone? like
# git clone --depth 1 
git+ssh://gitrepo.uri::repo

So you can clone in this manner and push changes back

Also for depth = 1 pack size will be similar to gzipped rsync 
snapshot

(~40M)
The shallow clone is still a shallow clone of the entire repo, and 
you

get the subtree checkout as just part of that.

Shallow clones are also read-only last I checked.


That isnt true =) you can commit from shallow clone  if and only if 
original repo doesnt have a branching and merging points before and 
after shallow clone point respectively

--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

On Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote:
> Isnt git works with shallow clone? like
> # git clone --depth 1  
> git+ssh://gitrepo.uri::repo
> 
> So you can clone in this manner and push changes back
> 
> Also for depth = 1 pack size will be similar to gzipped rsync snapshot 
> (~40M)
The shallow clone is still a shallow clone of the entire repo, and you
get the subtree checkout as just part of that.

Shallow clones are also read-only last I checked.

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

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

Robin H. Johnson писал 2012-05-23 19:47:

On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:

i've looked at the blockers of "[TRACKER] portage migration to git"
[1] and want to discuss "testing git-cvsserver" [2].

There are two proposed scenarios how to migrate the developers write
access to the portage tree.

The primary reasons to continue to support CVS-style access via
git-cvsserver:
1. Lightweight partial/subtree checkouts
- Git has implemented subtree checkouts, but they still bring down
a

fairly large packfile.
2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)

If we can get rid of #2, we're willing to live with #1.

"Clean cut" turns of cvs access on a given and announced timestamp,
rsync-generation/updates is suspended (no input -> no changes), some
magic scripts prepare the git repo (according to [3], some hours
duration) and we all checkout the tree (might be some funny massive
load).
1. You will be given git bundles instead of being allowed to do
initial

clone. That way it's just a resumable HTTP download.
2. rsync generation is NOT going away. Users will still be using it.

Another good point for repo size

https://git.wiki.kernel.org/index.php/GitFaq#How_do_I_use_git_for_large_projects.2C_where_the_repository_is_large.2C_say_approaching_1_TB.2C_but_a_checkout_is_only_a_few_hundred_MB.3F_Will_every_developer_need_1_TB_of_local_disk_space.3F
--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver


Matt Turner писал 2012-05-23 19:59:

On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson
 wrote:

2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)


Please don't go to this trouble for the ability to commit to portage
on *really* slow systems.


Isnt cvs too sloow on mips? git is much more faster. Same for arm.
About big repos, well why not use shallow cloned repo. It will work 
with plane history

--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Matt Turner

On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson  wrote:
> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)

Please don't go to this trouble for the ability to commit to portage
on *really* slow systems.

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Justin

On 23.05.2012 18:47, Robin H. Johnson wrote:
> On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:
>> i've looked at the blockers of "[TRACKER] portage migration to git"
>> [1] and want to discuss "testing git-cvsserver" [2].
>>
>> There are two proposed scenarios how to migrate the developers write
>> access to the portage tree.
> The primary reasons to continue to support CVS-style access via
> git-cvsserver:
> 1. Lightweight partial/subtree checkouts
>- Git has implemented subtree checkouts, but they still bring down a
>fairly large packfile.
> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)
> 
> If we can get rid of #2, we're willing to live with #1.
> 
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>> rsync-generation/updates is suspended (no input -> no changes), some
>> magic scripts prepare the git repo (according to [3], some hours
>> duration) and we all checkout the tree (might be some funny massive load).
> 1. You will be given git bundles instead of being allowed to do initial
>clone. That way it's just a resumable HTTP download.
> 2. rsync generation is NOT going away. Users will still be using it.
> 

Was this a vote for or against a quick proceeding towards git?
You are probably the one who can judge best if the infra side could be
made ready soonish.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver


Robin H. Johnson писал 2012-05-23 19:47:

On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:

i've looked at the blockers of "[TRACKER] portage migration to git"
[1] and want to discuss "testing git-cvsserver" [2].

There are two proposed scenarios how to migrate the developers write
access to the portage tree.

The primary reasons to continue to support CVS-style access via
git-cvsserver:
1. Lightweight partial/subtree checkouts
   - Git has implemented subtree checkouts, but they still bring down 
a

 fairly large packfile.
2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)


Isnt git works with shallow clone? like
# git clone --depth 1  
git+ssh://gitrepo.uri::repo


So you can clone in this manner and push changes back

Also for depth = 1 pack size will be similar to gzipped rsync snapshot 
(~40M)




If we can get rid of #2, we're willing to live with #1.


"Clean cut" turns of cvs access on a given and announced timestamp,
rsync-generation/updates is suspended (no input -> no changes), some
magic scripts prepare the git repo (according to [3], some hours
duration) and we all checkout the tree (might be some funny massive 
load).
1. You will be given git bundles instead of being allowed to do 
initial

   clone. That way it's just a resumable HTTP download.
2. rsync generation is NOT going away. Users will still be using it.


--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
> 
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
The primary reasons to continue to support CVS-style access via
git-cvsserver:
1. Lightweight partial/subtree checkouts
   - Git has implemented subtree checkouts, but they still bring down a
 fairly large packfile.
2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)

If we can get rid of #2, we're willing to live with #1.

> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
1. You will be given git bundles instead of being allowed to do initial
   clone. That way it's just a resumable HTTP download.
2. rsync generation is NOT going away. Users will still be using it.

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

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver


Michał Górny писал 2012-05-23 19:33:

On Wed, 23 May 2012 14:42:37 +0200
Michael Weber  wrote:


*if you still read this* *wow*

Please discuss my arguments and come to the conclusions to
RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
this bug from the blockers of "[TRACKER] portage migration to git".


Kill it! And while we're at it, kill ChangeLogs as well!

/me hides...


Well this can be done with *meaningfull* git commit messages =D

so +1

--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] Re: Remove eclass/ChangeLog

On Wed, 23 May 2012 12:29:34 -0400
Rich Freeman  wrote:

> On Wed, May 23, 2012 at 4:02 AM, Samuli Suominen
>  wrote:
> > On 05/23/2012 05:36 AM, Ryan Hill wrote:
> >> One person doesn't do entries.  OMG let's remove it!
> >>
> >
> > absolutely because inconsitency renderess the file useless
> >
> 
> Well, for now the solution is to enforce following policy.
> 
> For the future, perhaps the policy's time has ended.  Sure, Changelogs
> can be handy, but they are increasingly redundant and scm comments
> have the potential to be far more useful.  By all means require
> meaningful scm commit comments, but if Changelog files are holding us
> back either auto-generate them or ditch them.

ChangeLogs could be fine for ebuilds. But for more broad cases like
eclasses, one can usually have a set of changes prepared for commit.
With CVS, it's PITA but with git it's already much better. Of course,
it all fails if every commit has to update a randomly changed, shared
file called ChangeLog...

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Andreas K. Huettel

> On Wed, 23 May 2012 14:42:37 +0200
> 
> Kill it! And while we're at it, kill ChangeLogs as well!
> 
> /me hides...

+1
+1
+1
+1
...

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing


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

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

On Wed, May 23, 2012 at 10:43 AM, Anthony G. Basile  wrote:
>
> Looks like the bloodbath begins.  I too am in favor of killing cvs.

Please, let it die.  I'll miss my scripts, but I'll gladly deal with
that over whatever breakage comes along every time some cvs plugin
messes up the tree, or we can't use some useful git feature because
cvs amazingly enough behaves like an scm invented 20 years ago.

Rich

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

On Wed, 23 May 2012 14:42:37 +0200
Michael Weber  wrote:

> *if you still read this* *wow*
> 
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".

Kill it! And while we're at it, kill ChangeLogs as well!

/me hides...

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Remove eclass/ChangeLog

On Wed, May 23, 2012 at 4:02 AM, Samuli Suominen  wrote:
> On 05/23/2012 05:36 AM, Ryan Hill wrote:
>> One person doesn't do entries.  OMG let's remove it!
>>
>
> absolutely because inconsitency renderess the file useless
>

Well, for now the solution is to enforce following policy.

For the future, perhaps the policy's time has ended.  Sure, Changelogs
can be handy, but they are increasingly redundant and scm comments
have the potential to be far more useful.  By all means require
meaningful scm commit comments, but if Changelog files are holding us
back either auto-generate them or ditch them.

And, to add my own to cents to this chain about the only thing worse
than failing to directly inherit an eclass dependency is to break the
tree fixing the problem on personal initiative.  When a dev messes up
the solution is to talk to them or if necessary talk to devrel/QA -
not to break end-user systems.

Rich

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Sergei Trofimovich

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

+1 for git switch.

git-cvsserver would make sense if it would be completely transparent
for cvs client. and it's not. so why bother setuping fragile things?

- -- 

  Sergei
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk+9ETgACgkQcaHudmEf86pHTgCgh0lWhRz5VAf0N9xRPOE4gld3
IXIAn1Q9q7BSaIGZpiUHgATng2rBVBWZ
=vbwK
-END PGP SIGNATURE-

Re: [gentoo-dev] anybody interested in writing a Perl ebuild?

On Wed, May 23, 2012 at 01:14:52AM -0700, Grant wrote:
> Thanks, I gave that a try and it did a bunch of stuff but when I try
> to emerge Net-Braintree I get:
that's weird. it did generate all of them fine here
which version of g-cpan?

> I noticed that g-cpan put all of the ebuilds it generated in:
> /var/lib/layman/moonrise/perl-gcpan
> Is that the right place for them?
the default is the last overlay in your config. i suggest looking at the
docs and forcing it to your own overlay, and forcing category to
dev-perl.

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

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread justin

On 23/05/12 14:42, Michael Weber wrote:

> Hi,
> 
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
> 
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
> 
> "Clean cut" turns of cvs access on a given and announced timestamp,


I want to see to it gone. +1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Anthony G. Basile


On 05/23/2012 10:39 AM, Alexey Shvetsov wrote:

+1 for killing cvs




Looks like the bloodbath begins.  I too am in favor of killing cvs.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver


+1 for killing cvs


Johannes Huber писал 2012-05-23 15:54:

Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:


-BEGIN PGP SIGNED MESSAGE-



Hash: SHA256







Hi,







i've looked at the blockers of "[TRACKER] portage migration to git"



[1] and want to discuss "testing git-cvsserver" [2].







There are two proposed scenarios how to migrate the developers write




access to the portage tree.







"Clean cut" turns of cvs access on a given and announced timestamp,



rsync-generation/updates is suspended (no input -> no changes), some




magic scripts prepare the git repo (according to [3], some hours



duration) and we all checkout the tree (might be some funny massive

load).






"testing git-cvsserver" proses "Clean cut" with the additional

ability


to continue using cvs update/commit, - in best case - on the old



checkout w/o alteration on the developers side.







"Clean cut" forces us to clean up out dirty checkouts (I have some



added directories, added ebuilds i hesitated to `repoman commit`).



Plus we have to alter all our hot-wired portage mangling scripts

from


cvs'ish to git'ish (I use my read/write checkout as portage tree

(cvs


checkout + egencache for checkout) and have an automated

google-chrome


bump script). But this can be accomplished on a per developer basis,




and slackers don't stall the process.







"testing git-cvsserver" forces us all to test these cvs'ish scripts



and behaviours against a git-cvsserver and report.



We all know that this test-runs will never happen, stalling this bug




till infinity.



Plus infra/"subset of devs marshalling the migration" get stuck



between fixing git issues and git-cvsserver.







*if you still read this* *wow*







Please discuss my arguments and come to the conclusions to



RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove




this bug from the blockers of "[TRACKER] portage migration to git".







My lengthy 2 cents.







[1] https://bugs.gentoo.org/333531



[2] https://bugs.gentoo.org/333699



[3] https://bugs.gentoo.org/333705#c2



- --



Gentoo Dev



http://xmw.de/



-BEGIN PGP SIGNATURE-



Version: GnuPG v2.0.17 (GNU/Linux)



Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/







iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd



VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW



=jXLQ



-END PGP SIGNATURE-


I support RESOLUTION WONTFIX, if nobody cares about the bug since it
was opened it is obvious out of interest. There is no reason to
support jurassic software.

Clean cut++

Cheers


--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, 
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

[gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Michael Palimaka


On 2012-05-23 22:42, Michael Weber wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

i've looked at the blockers of "[TRACKER] portage migration to git"
[1] and want to discuss "testing git-cvsserver" [2].

There are two proposed scenarios how to migrate the developers write
access to the portage tree.

"Clean cut" turns of cvs access on a given and announced timestamp,
rsync-generation/updates is suspended (no input ->  no changes), some
magic scripts prepare the git repo (according to [3], some hours
duration) and we all checkout the tree (might be some funny massive load).

"testing git-cvsserver" proses "Clean cut" with the additional ability
to continue using cvs update/commit, - in best case - on the old
checkout w/o alteration on the developers side.

"Clean cut" forces us to clean up out dirty checkouts (I have some
added directories, added ebuilds i hesitated to `repoman commit`).
Plus we have to alter all our hot-wired portage mangling scripts from
cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
checkout + egencache for checkout) and have an automated google-chrome
bump script). But this can be accomplished on a per developer basis,
and slackers don't stall the process.

"testing git-cvsserver" forces us all to test these cvs'ish scripts
and behaviours against a git-cvsserver and report.
We all know that this test-runs will never happen, stalling this bug
till infinity.
Plus infra/"subset of devs marshalling the migration" get stuck
between fixing git issues and git-cvsserver.

*if you still read this* *wow*

Please discuss my arguments and come to the conclusions to
RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
this bug from the blockers of "[TRACKER] portage migration to git".

My lengthy 2 cents.

[1] https://bugs.gentoo.org/333531
[2] https://bugs.gentoo.org/333699
[3] https://bugs.gentoo.org/333705#c2
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
=jXLQ
-END PGP SIGNATURE-



Another vote for clean cut.

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Fabio Erculiani

Please kill CVS with fire!
I've been waiting for this since 2009.

-- 
Fabio Erculiani

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Matthew Thode

On 05/23/2012 07:54 AM, Johannes Huber wrote:
> Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
> Hi,
> 
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
> 
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
> 
> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
> 
> "testing git-cvsserver" proses "Clean cut" with the additional ability
> to continue using cvs update/commit, - in best case - on the old
> checkout w/o alteration on the developers side.
> 
> "Clean cut" forces us to clean up out dirty checkouts (I have some
> added directories, added ebuilds i hesitated to `repoman commit`).
> Plus we have to alter all our hot-wired portage mangling scripts from
> cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
> checkout + egencache for checkout) and have an automated google-chrome
> bump script). But this can be accomplished on a per developer basis,
> and slackers don't stall the process.
> 
> "testing git-cvsserver" forces us all to test these cvs'ish scripts
> and behaviours against a git-cvsserver and report.
> We all know that this test-runs will never happen, stalling this bug
> till infinity.
> Plus infra/"subset of devs marshalling the migration" get stuck
> between fixing git issues and git-cvsserver.
> 
> *if you still read this* *wow*
> 
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
> 
> My lengthy 2 cents.
> 
> [1] https://bugs.gentoo.org/333531
> [2] https://bugs.gentoo.org/333699
> [3] https://bugs.gentoo.org/333705#c2
> 
> I support RESOLUTION WONTFIX, if nobody cares about the bug since it was 
> opened it is obvious out of interest. There is no reason to support jurassic 
> software. 
> 
> Clean cut++
> 
> Cheers

clean-cut++

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Aaron W. Swenson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/23/2012 09:25 AM, Andreas K. Huettel wrote:
> 
>> 
>> Please discuss my arguments and come to the conclusions to 
>> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and
>> remove this bug from the blockers of "[TRACKER] portage migration
>> to git".
>> 
> 
> +1
> 
> Please cut cvs support once and for all.
> 
+1 for clean cut
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+85e4ACgkQVxOqA9G7/aDWpgD/SYfC3aOlOP2kAwK3qt81smH8
YWs60Kl77Xx+wIM1jx8A/0PkisxPTsLE5jR59GhaDmC+epoodW1GOak//pAvCmCG
=F8Rw
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Andreas K. Huettel


> 
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
> 

+1

Please cut cvs support once and for all.

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing


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

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Ian Whyman

On May 23, 2012 1:55 PM, "Johannes Huber"  wrote:
>
> Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
>
> > -BEGIN PGP SIGNED MESSAGE-
>
> > Hash: SHA256
>
> >
>
> > Hi,
>
> >
>
> > i've looked at the blockers of "[TRACKER] portage migration to git"
>
> > [1] and want to discuss "testing git-cvsserver" [2].
>
> >
>
> > There are two proposed scenarios how to migrate the developers write
>
> > access to the portage tree.
>
> >
>
> > "Clean cut" turns of cvs access on a given and announced timestamp,
>
> > rsync-generation/updates is suspended (no input -> no changes), some
>
> > magic scripts prepare the git repo (according to [3], some hours
>
> > duration) and we all checkout the tree (might be some funny massive
load).
>
> >
>
> > "testing git-cvsserver" proses "Clean cut" with the additional ability
>
> > to continue using cvs update/commit, - in best case - on the old
>
> > checkout w/o alteration on the developers side.
>
> >
>
> > "Clean cut" forces us to clean up out dirty checkouts (I have some
>
> > added directories, added ebuilds i hesitated to `repoman commit`).
>
> > Plus we have to alter all our hot-wired portage mangling scripts from
>
> > cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
>
> > checkout + egencache for checkout) and have an automated google-chrome
>
> > bump script). But this can be accomplished on a per developer basis,
>
> > and slackers don't stall the process.
>
> >
>
> > "testing git-cvsserver" forces us all to test these cvs'ish scripts
>
> > and behaviours against a git-cvsserver and report.
>
> > We all know that this test-runs will never happen, stalling this bug
>
> > till infinity.
>
> > Plus infra/"subset of devs marshalling the migration" get stuck
>
> > between fixing git issues and git-cvsserver.
>
> >
>
> > *if you still read this* *wow*
>
> >
>
> > Please discuss my arguments and come to the conclusions to
>
> > RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
>
> > this bug from the blockers of "[TRACKER] portage migration to git".
>
> >
>
> > My lengthy 2 cents.
>
> >
>
> > [1] https://bugs.gentoo.org/333531
>
> > [2] https://bugs.gentoo.org/333699
>
> > [3] https://bugs.gentoo.org/333705#c2
>
> > - --
>
> > Gentoo Dev
>
> > http://xmw.de/
>
> > -BEGIN PGP SIGNATURE-
>
> > Version: GnuPG v2.0.17 (GNU/Linux)
>
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> >
>
> > iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
>
> > VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
>
> > =jXLQ
>
> > -END PGP SIGNATURE-
>
>
>
> I support RESOLUTION WONTFIX, if nobody cares about the bug since it was
opened it is obvious out of interest. There is no reason to support
jurassic software.
>
>
>
> Clean cut++
>
>
>
> Cheers
>
> --
>
> Johannes Huber (johu)
>
> Gentoo Linux Developer / KDE Team
>
> GPG Key ID F3CFD2BD
>
>

Another vote for clean cut from me.

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

2012-05-23 Thread Johannes Huber

Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
> 
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
> 
> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
> 
> "testing git-cvsserver" proses "Clean cut" with the additional ability
> to continue using cvs update/commit, - in best case - on the old
> checkout w/o alteration on the developers side.
> 
> "Clean cut" forces us to clean up out dirty checkouts (I have some
> added directories, added ebuilds i hesitated to `repoman commit`).
> Plus we have to alter all our hot-wired portage mangling scripts from
> cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
> checkout + egencache for checkout) and have an automated google-chrome
> bump script). But this can be accomplished on a per developer basis,
> and slackers don't stall the process.
> 
> "testing git-cvsserver" forces us all to test these cvs'ish scripts
> and behaviours against a git-cvsserver and report.
> We all know that this test-runs will never happen, stalling this bug
> till infinity.
> Plus infra/"subset of devs marshalling the migration" get stuck
> between fixing git issues and git-cvsserver.
> 
> *if you still read this* *wow*
> 
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
> 
> My lengthy 2 cents.
> 
> [1] https://bugs.gentoo.org/333531
> [2] https://bugs.gentoo.org/333699
> [3] https://bugs.gentoo.org/333705#c2
> - --
> Gentoo Dev
> http://xmw.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
> VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
> =jXLQ
> -END PGP SIGNATURE-

I support RESOLUTION WONTFIX, if nobody cares about the bug since it was 
opened it is obvious out of interest. There is no reason to support jurassic 
software. 

Clean cut++

Cheers
-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD


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

[gentoo-dev] Portage Git migration - clean cut or git-cvsserver

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

i've looked at the blockers of "[TRACKER] portage migration to git"
[1] and want to discuss "testing git-cvsserver" [2].

There are two proposed scenarios how to migrate the developers write
access to the portage tree.

"Clean cut" turns of cvs access on a given and announced timestamp,
rsync-generation/updates is suspended (no input -> no changes), some
magic scripts prepare the git repo (according to [3], some hours
duration) and we all checkout the tree (might be some funny massive load).

"testing git-cvsserver" proses "Clean cut" with the additional ability
to continue using cvs update/commit, - in best case - on the old
checkout w/o alteration on the developers side.

"Clean cut" forces us to clean up out dirty checkouts (I have some
added directories, added ebuilds i hesitated to `repoman commit`).
Plus we have to alter all our hot-wired portage mangling scripts from
cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
checkout + egencache for checkout) and have an automated google-chrome
bump script). But this can be accomplished on a per developer basis,
and slackers don't stall the process.

"testing git-cvsserver" forces us all to test these cvs'ish scripts
and behaviours against a git-cvsserver and report.
We all know that this test-runs will never happen, stalling this bug
till infinity.
Plus infra/"subset of devs marshalling the migration" get stuck
between fixing git issues and git-cvsserver.

*if you still read this* *wow*

Please discuss my arguments and come to the conclusions to
RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
this bug from the blockers of "[TRACKER] portage migration to git".

My lengthy 2 cents.

[1] https://bugs.gentoo.org/333531
[2] https://bugs.gentoo.org/333699
[3] https://bugs.gentoo.org/333705#c2
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
=jXLQ
-END PGP SIGNATURE-

[gentoo-dev] So...

2012-05-23 Thread Andreas K. Huettel


... since the bugs seem to be stalled and noone has recently posted on gentoo-
scm, what's the real status of the infamous git migration? :)

Cheers, A

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing


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

Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!

2012-05-23 Thread Kacper Kowalik

On 05/23/2012 01:00 PM, Pacho Ramos wrote:
> El mié, 23-05-2012 a las 10:31 +0100, Markos Chandras escribió:
>> On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos  wrote:
>>> El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
 On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
> On May 20, autools.eclass was changed to no longer inherit eutils, see
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133&r2=1.134
>
> Relying on autotools.eclass for your eutils needs was always a terrible
> idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
> since they can no longer use epatch. See bug #416847 for an example.
>
> Check your ebuilds to make sure you inherit eutils in anything that uses
> epatch!
>
> -Alexandre Rostovtsev.
>
>
>
 Since eutils inherits multilib and user, the breakage extends beyond 
 epatch.
 For example, I just saw bug #417153, where a user reported failed calls
 to enew{user,group}.



>>>
>>> The autotools.eclass change should probably be reverted until things are
>>> properly checked I think (and I will do it tomorrow if nobody disagrees)
>>
>> It is far too late to do that. What is done is done. Let try and fix
>> what is still broken
>>
>> Regards,
>> Markos
>>
>>
> 
> But we still have no idea what kind of commands provided by eutils and
> eclasses inheritted by it are now missing, epatch usage was fixes,
> enewgroup/user will probably be done but... other missing commands could
> still appear in the tree :|

I wrote a simple, stupid script just a moment ago. Please don't show it
to anybody who knows how to write in Python :D

It shows all missing inherits, not just the ones causing failures, but
it could prolly be adjusted to do that instead.

Cheers,
Kacper
#!/usr/bin/env python

import re
import os
import argparse

class DirectoryWalker:
# a forward iterator that traverses a directory tree

def __init__(self, directory):
self.stack = [directory]
self.files = []
self.index = 0

def __getitem__(self, index):
while 1:
try:
file = self.files[self.index]
self.index = self.index + 1
except IndexError:
# pop next directory from stack
self.directory = self.stack.pop()
self.files = os.listdir(self.directory)
self.index = 0
else:
# got a filename
fullname = os.path.join(self.directory, file)
if os.path.isdir(fullname) and not os.path.islink(fullname):
self.stack.append(fullname)
return fullname


usage = "usage: %prog [options] DIRECTORY"

parser = argparse.ArgumentParser()
parser.add_argument("-e", nargs=1, default=["user"],
help="Name of the eclass to test, e.g. 'user'")
parser.add_argument("-p", nargs=1, default=["/usr/portage"],
help="Directory where eclass resides, e.g. PORTDIR")
parser.add_argument("directory", nargs=1,
help="Directory with ebuilds to run tests" )
args = parser.parse_args()

is_ebuild = re.compile('\.ebuild$')

ebuilds = filter(is_ebuild.search, DirectoryWalker(args.directory[0]))

re_func  = re.compile("FUNCTION").search  # TODO: improve me

fname = open('%s/eclass/%s.eclass'% (args.p[0], args.e[0]))
funcs = [func.split()[-1].strip()
for func in filter(re_func, fname.readlines())]
fname.close()

# Listen carefully, I shall speak it only once
regexps = {func: re.compile(func).search for func in funcs}
re_inher = re.compile("^inherit.*%s"% args.e[0]).match

for ebuild in ebuilds:
fname = open(ebuild,'r')
lines = fname.readlines()
fname.close()

uses_function = any([len(filter(regexps[key], lines))
for key in regexps.keys()])
uses_eclass = len(filter(re_inher, lines))

if uses_function and not uses_eclass:
print("%s should inherit %s.eclass" % (ebuild, args.e[0]))


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!

2012-05-23 Thread Pacho Ramos

El mié, 23-05-2012 a las 10:31 +0100, Markos Chandras escribió:
> On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos  wrote:
> > El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
> >> On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
> >> > On May 20, autools.eclass was changed to no longer inherit eutils, see
> >> > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133&r2=1.134
> >> >
> >> > Relying on autotools.eclass for your eutils needs was always a terrible
> >> > idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
> >> > since they can no longer use epatch. See bug #416847 for an example.
> >> >
> >> > Check your ebuilds to make sure you inherit eutils in anything that uses
> >> > epatch!
> >> >
> >> > -Alexandre Rostovtsev.
> >> >
> >> >
> >> >
> >> Since eutils inherits multilib and user, the breakage extends beyond 
> >> epatch.
> >> For example, I just saw bug #417153, where a user reported failed calls
> >> to enew{user,group}.
> >>
> >>
> >>
> >
> > The autotools.eclass change should probably be reverted until things are
> > properly checked I think (and I will do it tomorrow if nobody disagrees)
> 
> It is far too late to do that. What is done is done. Let try and fix
> what is still broken
> 
> Regards,
> Markos
> 
> 

But we still have no idea what kind of commands provided by eutils and
eclasses inheritted by it are now missing, epatch usage was fixes,
enewgroup/user will probably be done but... other missing commands could
still appear in the tree :|


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

Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!

2012-05-23 Thread Markos Chandras

On Wed, May 23, 2012 at 9:04 AM, Pacho Ramos  wrote:
> El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
>> On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
>> > On May 20, autools.eclass was changed to no longer inherit eutils, see
>> > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133&r2=1.134
>> >
>> > Relying on autotools.eclass for your eutils needs was always a terrible
>> > idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
>> > since they can no longer use epatch. See bug #416847 for an example.
>> >
>> > Check your ebuilds to make sure you inherit eutils in anything that uses
>> > epatch!
>> >
>> > -Alexandre Rostovtsev.
>> >
>> >
>> >
>> Since eutils inherits multilib and user, the breakage extends beyond epatch.
>> For example, I just saw bug #417153, where a user reported failed calls
>> to enew{user,group}.
>>
>>
>>
>
> The autotools.eclass change should probably be reverted until things are
> properly checked I think (and I will do it tomorrow if nobody disagrees)

It is far too late to do that. What is done is done. Let try and fix
what is still broken

Regards,
Markos

[gentoo-dev] dev-libs/libusb -> virtual/libusb, please, check your overlays

2012-05-23 Thread Samuli Suominen

Whole gentoo-x86 is using the virtuals now. Please check your overlays 
to avoid dev-libs/libusb from creeping back in to the tree.


http://qa-reports.gentoo.org/output/genrdeps/dindex/dev-libs/libusb
http://qa-reports.gentoo.org/output/genrdeps/rindex/dev-libs/libusb

If you have packages in overlays using dev-libs/libusb please fix them 
now to avoid them creeping into Portage.


There is a repoman bug open but still without a patch:

http://bugs.gentoo.org/417123

This is important now because of the dev-libs/libusb-compat stabilization:

http://bugs.gentoo.org/417135

Otherwise you'd be introducing conflicting dependencies for /stable/ users.

Futhermore some of the virtual/libusb dependencies in tree are missing 
usage of correct SLOT, and should be fixed, that involves checking the 
package sources (of course). If you want to help with this, please do.


Thanks,
Samuli

[gentoo-dev] Help required with getting new media-gfx/graphviz in tree.

2012-05-23 Thread Samuli Suominen

We are behind with graphviz and 2.28.x series has been out for quite a 
while.


However working on the ebuild will require quite a work and then 
backtracking the bugs that come after it as a result (believe me, there 
will be ones)


It seems graphics@ is currently a bit understaffed and I really don't 
see anyone working on this anytime soon without sending this mail.


Thanks ahead

- Samuli

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

2012-05-23 Thread Petteri Räty

On 22.5.2012 8.53, Michał Górny wrote:

>>>
>> Excuse me but the way this change was handled is a bit depressing.
>> First, the ebuilds should have been fixed to inherit eutils and then
>> remove eutils from autotools. Now, a bunch of ebuilds are broken out
>> of nowhere. I don't believe this issue was that urgent in order to
>> justify the significant breakage of portage tree.
> 
> First of all, to quote devmanual:
> 
> | Before updating eutils or a similar widely used eclass, it is best to
> | email the gentoo-dev list. It may be that your proposed change is
> | broken in a way you had not anticipated> [...]. If you don't email
> | gentoo-dev first, and end up breaking something, expect to be in a
> | lot of trouble.
> 
> Not that this disrespect for this rule is something new...
> 

Even more important is the next chapter:

"When removing a function or changing the API of an eclass, make sure
that it doesn't break any ebuilds in the tree, and post a notice to
gentoo-dev at least 30 days in advance, preferably with a patch included."

This qualifies as changing the API of an eclass. This chapter comes from
a council decision:

http://www.gentoo.org/proj/en/council/meeting-logs/2008-summary.txt

Regards,
Petteri

Re: [gentoo-dev] anybody interested in writing a Perl ebuild?

2012-05-23 Thread Grant

>> Hello, is anyone interested in writing a Perl ebuild for this payment module:
>> http://search.cpan.org/dist/Net-Braintree/
> Use g-cpan.
>
> g-cpan -g Net::Braintree
>
> It will generate packages for the module and all needed deps
> (DateTime-Format-RFC3339, DateTime-Format-Atom,
> Module-Install-TestTarget, Hash-Inflator, local-lib, URI-Query).

Thanks, I gave that a try and it did a bunch of stuff but when I try
to emerge Net-Braintree I get:

>>> Verifying ebuild manifests
!!! A file is not listed in the Manifest:
'/var/lib/layman/moonrise/perl-gcpan/DateTime-Format-RFC3339/DateTime-Format-RFC3339-1.0.5.ebuild'
!!! A file is not listed in the Manifest:
'/var/lib/layman/moonrise/perl-gcpan/DateTime-Format-Atom/DateTime-Format-Atom-1.0.2.ebuild'

I noticed that g-cpan put all of the ebuilds it generated in:

/var/lib/layman/moonrise/perl-gcpan

Is that the right place for them?

- Grant

Re: [gentoo-dev] Re: Remove eclass/ChangeLog

2012-05-23 Thread Samuli Suominen


On 05/23/2012 05:36 AM, Ryan Hill wrote:

On Sun, 20 May 2012 15:33:11 +0300
Samuli Suominen  wrote:


ChangeLog entries missing for every autotools.eclass modification today.

On 05/20/2012 03:31 PM, Mike Frysinger (vapier) wrote:

vapier  12/05/20 12:31:33


One person doesn't do entries.  OMG let's remove it!




absolutely because inconsitency renderess the file useless

Re: [gentoo-dev] Re: autotools.eclass no longer inherits eutils; check your ebuilds!

2012-05-23 Thread Pacho Ramos

El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:
> On 2012-05-22 03:46, Alexandre Rostovtsev wrote:
> > On May 20, autools.eclass was changed to no longer inherit eutils, see
> > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133&r2=1.134
> >
> > Relying on autotools.eclass for your eutils needs was always a terrible
> > idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
> > since they can no longer use epatch. See bug #416847 for an example.
> >
> > Check your ebuilds to make sure you inherit eutils in anything that uses
> > epatch!
> >
> > -Alexandre Rostovtsev.
> >
> >
> >
> Since eutils inherits multilib and user, the breakage extends beyond epatch.
> For example, I just saw bug #417153, where a user reported failed calls 
> to enew{user,group}.
> 
> 
> 

The autotools.eclass change should probably be reverted until things are
properly checked I think (and I will do it tomorrow if nobody disagrees)


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

Re: [gentoo-dev] anybody interested in writing a Perl ebuild?