Re: [gentoo-dev] RFD: News item format 2.0

[Michał Górny]

On Fri, 15 Jan 2016 00:00:02 +0100
Ulrich Mueller  wrote:

> > On Thu, 14 Jan 2016, Michał Górny wrote:  
> 
> > On Thu, 14 Jan 2016 07:28:43 -0500
> > Rich Freeman  wrote:  
> 
> >> One way to do this (and I'm certainly open to others) is a
> >> Display-If-Installable header which takes a keyword string and an
> >> atom (typically a specific PV).  The package manager would
> >> determine if a package with that keyword string and PV would be
> >> accepted or not based on the user's configuration, and if so
> >> display the news.  
> 
> > Based on your idea, this is how I'd do it:  
> 
> > 1. 'Display-If-Visible' that enables news items if given atom is
> > visible for PM (i.e. in repo, with right keywords and not masked).
> > I would avoid using 'Installable' as that could get confusing wrt
> > conflicts and so on.  
> 
> I had omitted the Display-If-Visible header (which has been discussed
> since 2007 at least) deliberately, because we want to get format 2.0
> done in a timely manner.

That doesn't really make sense to me. There is no real urgency in
getting the new format right now, and omitting the most important issue
is not really the solution here.

> The problem with any visibility filtering is that visibility depends
> on user configuration [1], and I don't know what changes in the
> package manager would be necessary to make this work correctly and
> efficiently. For example, how does portage's --autounmask-write option
> interact with it?

Leave solving this to Portage developers. Autounmasking is not
something you do often on stable systems, and we have better QA to
avoid issues that could require it.

What's most important right now is to have Portage process news items
after 'emerge --sync' (or any other emerge operation), check visibility
of packages (with current configuration) and enable news items that
apply.

We could also process changed news files on emerge start, and warn
verbosely that new news items start applying.

> [1] https://bugs.gentoo.org/show_bug.cgi?id=290038#c9

-- 
Best regards,
Michał Górny



pgpQ5KKiKwHwD.pgp
Description: OpenPGP digital signature

[gentoo-dev] Lastrites: media-sound/seq24

[Pacho Ramos]

# Pacho Ramos  (16 Jan 2016)
# Dead for years, not compatible with latest libsigc++ (#569514), it
# requires either a lot of patching or move to a forked project that
tries
# to continue it. Removal in a month.
media-sound/seq24

Re: [gentoo-dev] Goodbye Java on ppc32?

[James Le Cuirot]

On Tue, 12 Jan 2016 13:44:16 +
James Le Cuirot  wrote:

> On Sat, 9 Jan 2016 23:10:43 +
> James Le Cuirot  wrote:
> 
> > I'm mulling over the idea of dropping Java on 32-bit ppc. Having
> > personally used Gentoo on this hardware myself in the past, I've
> > resisted the temptation to drop it sooner but I think it's time to
> > throw in the towel now.  
> 
> Since there hasn't been an outcry against this announcement so far,
> it's likely that I will proceed with it at the weekend.

Support has now been dropped. No one besides that one user on IRC spoke
up to say they were using it so I've been able to do this with a fairly
clear conscience.

Thanks to chithanh for offering to help but you can put your time
towards something more worthwhile. :)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpmEy9CHjRZn.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] hasufell's extended leave and libressl

[Anthony G. Basile]

On 1/16/16 7:54 PM, Joshua Kinard wrote:
> On 01/16/2016 19:41, Anthony G. Basile wrote:
>> Hi everyone,
>>
>> I emailed Julian earlier today and asked him to come back.  He state in
>> no uncertain terms that he does not intend on coming back.
>>
>> Julian and I were working on the libressl project together.  He was
>> doing the lion share and I contributed here and there for packages that
>> I was interested in.
>>
>> I just don't have time to push that project through on my own.  Mostly
>> what needs to be done is the migration to the tree as described on the
>> following page:
>>
>> https://github.com/gentoo/libressl/wiki/Transition-plan
>>
>> I'd like to solicit help in pushing this through.  Any takers?
> 
> Is the plan to just make packages in the tree compatible with libressl so that
> users can choose either one, or to migrate off of openssl entirely?
> 

The plan is basically this ...

IUSE="libressl ssl"

RDEPEND="
ssl? (
!libressl? ( dev-libs/openssl:0 )
libressl? ( dev-libs/libressl )
)
"

You choose either libressl or openssl and you build the entire tree with
that.

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

[gentoo-dev] hasufell's extended leave and libressl

[Anthony G. Basile]

Hi everyone,

I emailed Julian earlier today and asked him to come back.  He state in
no uncertain terms that he does not intend on coming back.

Julian and I were working on the libressl project together.  He was
doing the lion share and I contributed here and there for packages that
I was interested in.

I just don't have time to push that project through on my own.  Mostly
what needs to be done is the migration to the tree as described on the
following page:

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

I'd like to solicit help in pushing this through.  Any takers?

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

Re: [gentoo-dev] Herd up for grabs: net-dialup

[Anthony G. Basile]

On 1/16/16 8:09 PM, Joshua Kinard wrote:
> On 01/16/2016 12:30, Michał Górny wrote:
>> Hello, everyone.
>>
>> The current maintainer(s) of net-dialup herd has decided that he's
>> (they're) not interested in keeping it and would like the packages
>> to be dropped to maintainer-needed.
>>
>> Is anyone interested in keeping the herd as-is and maintaining all
>> packages in it? If I get no reply till 2016-01-24, I will effectively
>> remove the herd and announce the packages that landed in maintainer-
>> -needed as a result.
>>
>> Packages currently in herd, along with their other maintainers:
>>
>> net-dialup/accel-ppp : pinkbyte@
>> net-dialup/capi4k-utils  : 
>> net-dialup/capidivert: 
>> net-dialup/capifwd   : 
>> net-dialup/capisuite : 
>> net-dialup/cistronradius : 
>> net-dialup/cutecom   : 
>> net-dialup/dial  : 
>> net-dialup/diald : 
>> net-dialup/drdsl : 
>> net-dialup/dtrace: sbriesen@
>> net-dialup/dwun  : 
>> net-dialup/fbgetty   : 
>> net-dialup/fcpci : 
>> net-dialup/freeradius: 
>> net-dialup/freeradius-client : 
>> net-dialup/globespan-adsl: 
>> net-dialup/gnuradius : 
>> net-dialup/gtkterm   : 
>> net-dialup/hcfpcimodem   : 
>> net-dialup/isdn-firmware : 
>> net-dialup/itund : 
>> net-dialup/kpnadsl4linux : 
>> net-dialup/linux-atm : 
>> net-dialup/lrzsz : 
>> net-dialup/mgetty: 
>> net-dialup/mingetty  : 
>> net-dialup/minicom   : 
>> net-dialup/mwavem: 
>> net-dialup/picocom   : flameeyes@
>> net-dialup/ppp   : 
>> net-dialup/pppconfig : 
>> net-dialup/ppp-scripts   : 
>> net-dialup/pptpclient: 
>> net-dialup/pptpd : 
>> net-dialup/qtwvdialer: 
>> net-dialup/radiusclient  : 
>> net-dialup/radiusclient-ng   : 
>> net-dialup/rp-l2tp   : 
>> net-dialup/rp-pppoe  : 
>> net-dialup/sendpage  : 
>> net-dialup/sercd : 
>> net-dialup/speedtouch-usb: 
>> net-dialup/tkvoice   : 
>> net-dialup/ueagle4-atm   : 
>> net-dialup/ueagle-atm: 
>> net-dialup/wvdial: 
>> net-dialup/xc: 
>> net-dialup/xl2tpd: floppym@
>> net-dns/pdnsd: polynomial-c@
>> net-libs/libcapi : 
>> net-libs/wvstreams   : 
>> net-misc/capiisdnmon : 
>> net-misc/hylafaxplus : mattm@
>> net-misc/iaxmodem: 
>> net-misc/termpkg : 
>> www-apps/freeradius-dialupadmin : 
>>
> 
> I can look at taking over net-dialup/xc.  It rarely gets updates anyways, as
> upstream never intended it to be used on Linux (Xenix and SCO OpenServer were
> the intended targets).  Somehow, it works, but has quite a few QA issues
> (namely cavalier sprintf() usage with no buffer overflow checks).  It's been 
> on
> my TODO list to fix up one of these days, as well as adding the hard-to-find
> 5.x release.
> 
> I've also played with hylafax and iaxmodem before, but no longer have setups 
> to
> test those with.
> 


If people take care of their own packages in that list, that would
really speed things up!

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

Re: [gentoo-dev] Herd up for grabs: net-dialup

[Joshua Kinard]

On 01/16/2016 12:30, Michał Górny wrote:
> Hello, everyone.
> 
> The current maintainer(s) of net-dialup herd has decided that he's
> (they're) not interested in keeping it and would like the packages
> to be dropped to maintainer-needed.
> 
> Is anyone interested in keeping the herd as-is and maintaining all
> packages in it? If I get no reply till 2016-01-24, I will effectively
> remove the herd and announce the packages that landed in maintainer-
> -needed as a result.
> 
> Packages currently in herd, along with their other maintainers:
> 
> net-dialup/accel-ppp : pinkbyte@
> net-dialup/capi4k-utils  : 
> net-dialup/capidivert: 
> net-dialup/capifwd   : 
> net-dialup/capisuite : 
> net-dialup/cistronradius : 
> net-dialup/cutecom   : 
> net-dialup/dial  : 
> net-dialup/diald : 
> net-dialup/drdsl : 
> net-dialup/dtrace: sbriesen@
> net-dialup/dwun  : 
> net-dialup/fbgetty   : 
> net-dialup/fcpci : 
> net-dialup/freeradius: 
> net-dialup/freeradius-client : 
> net-dialup/globespan-adsl: 
> net-dialup/gnuradius : 
> net-dialup/gtkterm   : 
> net-dialup/hcfpcimodem   : 
> net-dialup/isdn-firmware : 
> net-dialup/itund : 
> net-dialup/kpnadsl4linux : 
> net-dialup/linux-atm : 
> net-dialup/lrzsz : 
> net-dialup/mgetty: 
> net-dialup/mingetty  : 
> net-dialup/minicom   : 
> net-dialup/mwavem: 
> net-dialup/picocom   : flameeyes@
> net-dialup/ppp   : 
> net-dialup/pppconfig : 
> net-dialup/ppp-scripts   : 
> net-dialup/pptpclient: 
> net-dialup/pptpd : 
> net-dialup/qtwvdialer: 
> net-dialup/radiusclient  : 
> net-dialup/radiusclient-ng   : 
> net-dialup/rp-l2tp   : 
> net-dialup/rp-pppoe  : 
> net-dialup/sendpage  : 
> net-dialup/sercd : 
> net-dialup/speedtouch-usb: 
> net-dialup/tkvoice   : 
> net-dialup/ueagle4-atm   : 
> net-dialup/ueagle-atm: 
> net-dialup/wvdial: 
> net-dialup/xc: 
> net-dialup/xl2tpd: floppym@
> net-dns/pdnsd: polynomial-c@
> net-libs/libcapi : 
> net-libs/wvstreams   : 
> net-misc/capiisdnmon : 
> net-misc/hylafaxplus : mattm@
> net-misc/iaxmodem: 
> net-misc/termpkg : 
> www-apps/freeradius-dialupadmin : 
> 

I can look at taking over net-dialup/xc.  It rarely gets updates anyways, as
upstream never intended it to be used on Linux (Xenix and SCO OpenServer were
the intended targets).  Somehow, it works, but has quite a few QA issues
(namely cavalier sprintf() usage with no buffer overflow checks).  It's been on
my TODO list to fix up one of these days, as well as adding the hard-to-find
5.x release.

I've also played with hylafax and iaxmodem before, but no longer have setups to
test those with.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] hasufell's extended leave and libressl

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/16/2016 04:41 PM, Anthony G. Basile wrote:
> Hi everyone,
> 
> I emailed Julian earlier today and asked him to come back.  He
> state in no uncertain terms that he does not intend on coming
> back.
> 
> Julian and I were working on the libressl project together.  He
> was doing the lion share and I contributed here and there for
> packages that I was interested in.
> 
> I just don't have time to push that project through on my own.
> Mostly what needs to be done is the migration to the tree as
> described on the following page:
> 
> https://github.com/gentoo/libressl/wiki/Transition-plan
> 
> I'd like to solicit help in pushing this through.  Any takers?
> 
What happened with hasufell? I feel like I missed something.

(This direct e-mail is deliberate; I figured this was worth a private
conversation instead of airing dirty laundry)

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

iQIcBAEBCAAGBQJWmuueAAoJEAEkDpRQOeFwkzkQANsm1SEh7iVqTBh5aJFh7PBc
Gm53iZv84uQZR8N9ChDp5YheIET5WuElDP7feaomEg+orLxmGIedVaexa5/H0te8
YoPHGqXvI1e9ryJtgimwTaOSlnPc0hz7uTngvxNSPlNwpaXxlDXw6SQZEZTtCBda
hIV5kep9XF6F3lnCsx5Lt3w9vyGw71BK0OsWfEvLwYBqv7id/94My3N2KvRoJh7I
gtdc3BtDammy8xBAg/8DZQ1PTNBzkn/mULVJRJGK5TkohNLVtjO9ZOv0XyJ7adMW
F7Zbz5rPDjslguGKqDCObwGYltk8xR6jBFXRYVtKLnIv8tr5Nc397I5haq36jUvi
TwNOLPnKOoCyTT4Gn/iSi1mKa9wPw5Io+buXNQciTUKOxB5g2gBGaldU8sbQ2NEe
MjPf5W6WARd/LhH4Psnuze7cYR4lWl2UBTaP4GHtOHQc+dIDfCyw7HRDBgSHblyx
FmdyvwUaywa4X2F5oELOYi63jFS7wJLef8gYUDA5imODXP3r4s+rO5VXiqFS7YQE
m/xVj+ZjZY5wrhsaq0oTcGBNNDEk0nzP5Uxum9JVDsrsPKjtMDFAyKcIv1AMFLOY
05x2ulYto364zuqNrU6XPy8YJqpnRJhPrlPMKHLiHl52DThi8gioXpKLQcWV34O1
5NIIgiO2LuAUi83P5RMo
=+evk
-END PGP SIGNATURE-

Re: [gentoo-dev] hasufell's extended leave and libressl

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/16/2016 05:17 PM, Daniel Campbell wrote:
> On 01/16/2016 04:41 PM, Anthony G. Basile wrote:
>> Hi everyone,
> 
>> I emailed Julian earlier today and asked him to come back.  He 
>> state in no uncertain terms that he does not intend on coming 
>> back.
> 
>> Julian and I were working on the libressl project together.  He 
>> was doing the lion share and I contributed here and there for 
>> packages that I was interested in.
> 
>> I just don't have time to push that project through on my own. 
>> Mostly what needs to be done is the migration to the tree as 
>> described on the following page:
> 
>> https://github.com/gentoo/libressl/wiki/Transition-plan
> 
>> I'd like to solicit help in pushing this through.  Any takers?
> 
> What happened with hasufell? I feel like I missed something.
> 
> (This direct e-mail is deliberate; I figured this was worth a
> private conversation instead of airing dirty laundry)
> 
> 
Apparently zlg has forgotten how to use e-mail. X_X
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWmuvmAAoJEAEkDpRQOeFwaN0P/03yxJcUJDzg5P6Y5/Vh5eCx
ZPx623Ujq3UjhhBFMXc7kvyUG3lVr0ndyRPZqIHdlPPCo1aY76O9nuj0nuyZSnjc
KjHgJ4Fk1UXncTArYHhAJRr0x0vbBDXpejyT3ValN+aI756ESLQGJRALCDmlJ9Ex
wFrESzaI6ZoNa10cckRhyCf1r8ZNiRUwGsPYg7pO1UOTkByWvqwX+qAOvNvOdNtd
0onKz85ctEtRt2Fpj2xWWAbXG/KK+qpq/BDLG3n/SAkrk5pvi3dmeEWlZZz+uRxe
+FSuRePHoMCvHJF2wdb71QS/JFy+4r7Q2qHW6tS+Rb7UzNGnODI9FsKV6JCnXwvM
vRBsXkoB2jseTGfzSUjRwOOBlB7b4tXY/JeihM90X/hHixM/AXstth0Kyk20Og5s
SaY0aEfnJrnx137jHhIM8hMZzejOKtOUcGJ0eVMc+cYDFXSd5XRttA4MiTqEoTLw
9e7Zhksho+a2sVVki0CraFL7zDDhPawOVIBc17oVpnY/UOAm8xeHlzAueFFwuQtH
MjsJU+b599YS36fV77D0BqK5qWujYdxiB4Lyn0OPkZdSrF2eeUdzI0D69c4uBTFQ
KcBdMaPLCfIXDyjB05hEkVqznT3ZnzHAKTZoxHMFrDYocg0G6feQOVb1Uu/bQAQl
UxbWFildGaOajDcPJ96E
=TfRx
-END PGP SIGNATURE-

Re: [gentoo-dev] RFD: News item format 2.0

[Ulrich Mueller]

> On Sat, 16 Jan 2016, Michał Górny wrote:

> That doesn't really make sense to me. There is no real urgency in
> getting the new format right now, and omitting the most important
> issue is not really the solution here.

The idea was to introduce EAPI 5 dependencies for the
Display-If-Installed header. Anything else is an added bonus at this
stage, and can be included if it is trivial to implement.

Nothing prevents us from creating a format 2.1 or 3.0 later for any
features that will take more time. Or, if we are thinking in long time
scales, we could even incorporate the news item spec into PMS with the
next EAPI (and replace the format number by the EAPI).

>> The problem with any visibility filtering is that visibility
>> depends on user configuration [1], and I don't know what changes in
>> the package manager would be necessary to make this work correctly
>> and efficiently. For example, how does portage's --autounmask-write
>> option interact with it?

> Leave solving this to Portage developers. Autounmasking is not
> something you do often on stable systems, and we have better QA to
> avoid issues that could require it.

Yeah, if I wasn't sure about Display-If-Visible, then this statement
would finally convince me that we should skip that feature, for the
time being. That something does not happen often is no excuse for not
having an implementation that can handle such rare cases.

Ulrich


pgpkB_SqJV8ZT.pgp
Description: PGP signature

[gentoo-dev] Herd up for grabs: desktop-dock

[Michał Górny]

Hello, everyone.

The current sole maintainer of desktop-dock herd has decided that he's
not interested in keeping it and would like the packages to be dropped
to maintainer-needed.

Is anyone interested in keeping the herd as-is and maintaining all
packages in it? If I get no reply till 2016-01-24, I will effectively
remove the herd and announce the packages that landed in maintainer-
-needed as a result.

Packages currently in herd, along with their other maintainers:

app-admin/gkrellm: 
games-puzzle/wmpuzzle: games, voyageur@
media-plugins/gkrellmpc  : sound
media-sound/alsamixer-app: sound, voyageur@
x11-libs/libdockapp  : voyageur@
x11-misc/mixer_app   : voyageur@
x11-misc/stalonetray : 
x11-misc/trayer  : 
x11-misc/xdock   : 
x11-plugins/allin1   : 
x11-plugins/bfm  : voyageur@
x11-plugins/bubblemon: voyageur@
x11-plugins/cputnik  : voyageur@
x11-plugins/docker   : voyageur@
x11-plugins/fsviewer : voyageur@
x11-plugins/gkrellaclock : 
x11-plugins/gkrellfire   : 
x11-plugins/gkrellflynn  : 
x11-plugins/gkrellkam: 
x11-plugins/gkrellm-bgchanger : 
x11-plugins/gkrellm-bluez: 
x11-plugins/gkrellm-countdown : 
x11-plugins/gkrellm-imonc: 
x11-plugins/gkrellmlaunch: 
x11-plugins/gkrellm-leds : 
x11-plugins/gkrellm-mailwatch : 
x11-plugins/gkrellmoon   : 
x11-plugins/gkrellm-plugins  : 
x11-plugins/gkrellm-radio: 
x11-plugins/gkrellmss: 
x11-plugins/gkrellm-trayicons : 
x11-plugins/gkrellm-vaiobright : 
x11-plugins/gkrellm-volume   : 
x11-plugins/gkrellmwireless  : 
x11-plugins/gkrellm-xkb  : 
x11-plugins/gkrellshoot  : 
x11-plugins/gkrellstock  : 
x11-plugins/gkrellsun: 
x11-plugins/gkrelltop: 
x11-plugins/gkrellweather: 
x11-plugins/gkwebmon : 
x11-plugins/i8krellm : 
x11-plugins/monto: voyageur@
x11-plugins/wmacpi   : voyageur@
x11-plugins/wmacpiload-ac: voyageur@
x11-plugins/wmacpimon: voyageur@
x11-plugins/wmail: voyageur@
x11-plugins/wmapm: voyageur@
x11-plugins/wmapmload: voyageur@
x11-plugins/wmappl   : voyageur@
x11-plugins/wmbatteries  : voyageur@
x11-plugins/wmbattery: voyageur@
x11-plugins/wmbiff   : voyageur@
x11-plugins/wmbinclock   : voyageur@
x11-plugins/wmbio: voyageur@
x11-plugins/wmblob   : voyageur@
x11-plugins/wmbluecpu: voyageur@
x11-plugins/wmbutton : voyageur@
x11-plugins/wmcalc   : voyageur@
x11-plugins/wmCalClock   : voyageur@
x11-plugins/wmcalendar   : voyageur@
x11-plugins/wmcdplay : voyageur@
x11-plugins/wmcliphist   : voyageur@
x11-plugins/wmclock  : voyageur@
x11-plugins/wmclockmon   : voyageur@
x11-plugins/wmcms: voyageur@
x11-plugins/wmcoincoin   : voyageur@
x11-plugins/wmcp : voyageur@
x11-plugins/wmcpu: voyageur@
x11-plugins/wmcpuload: voyageur@
x11-plugins/wmcube   : voyageur@
x11-plugins/wmdate   : voyageur@
x11-plugins/wmdf : voyageur@
x11-plugins/wmdiskmon: voyageur@
x11-plugins/wmdl : voyageur@
x11-plugins/wmdots   : voyageur@
x11-plugins/wmDownload   : voyageur@
x11-plugins/wmdrawer : voyageur@
x11-plugins/wmfire   : voyageur@
x11-plugins/wmfishtime   : voyageur@
x11-plugins/wmforkplop   : voyageur@
x11-plugins/wmfortune: voyageur@
x11-plugins/wmfrog   : voyageur@
x11-plugins/wmfsm: voyageur@
x11-plugins/wmget: voyageur@
x11-plugins/wmgrabimage  : voyageur@
x11-plugins/wmgtemp  : voyageur@
x11-plugins/wmhdplop : voyageur@
x11-plugins/wmifinfo : voyageur@
x11-plugins/wmifs: voyageur@
x11-plugins/wminet   : voyageur@
x11-plugins/wmitime  : voyageur@
x11-plugins/wmix : voyageur@
x11-plugins/wmjsql   : voyageur@
x11-plugins/wmlaptop : voyageur@
x11-plugins/wmlife   : voyageur@
x11-plugins/wmload   : voyageur@
x11-plugins/wmlongrun: voyageur@
x11-plugins/wmlpq: voyageur@
x11-plugins/wmmaiload: voyageur@
x11-plugins/wmmand   : voyageur@
x11-plugins/wmMatrix : voyageur@
x11-plugins/wmmemfree: voyageur@
x11-plugins/wmmemload: voyageur@
x11-plugins/wmmemmon : voyageur@
x11-plugins/wmmenu   : voyageur@
x11-plugins/wmmisc   : voyageur@
x11-plugins/wmmixer  : voyageur@
x11-plugins/wmmldonkey   : voyageur@
x11-plugins/wmmon: voyageur@
x11-plugins/wmmon+smp: voyageur@
x11-plugins/wmMoonClock  : voyageur@
x11-plugins/wmmp3: voyageur@
x11-plugins/wmmsg: voyageur@
x11-plugins/wmnd : voyageur@
x11-plugins/wmnet: voyageur@
x11-plugins/wmnetload: 

[gentoo-dev] Packages up for grab

[Manuel Rüger]

Feel free to add yourself to:

app-editors/diakonos
app-misc/ddccontrol
app-misc/ddccontrol-db
net-libs/txtorcon
net-wireless/mfoc
sys-apps/fwts
sys-apps/fxload
x11-plugins/pidgin-indicator


- M



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Herd up for grabs: net-ftp

[Michał Górny]

Hello, everyone.

The current maintainer(s) of net-ftp herd has decided that he's
(they're) not interested in keeping it and would like the packages
to be dropped to maintainer-needed.

Is anyone interested in keeping the herd as-is and maintaining all
packages in it? If I get no reply till 2016-01-24, I will effectively
remove the herd and announce the packages that landed in maintainer-
-needed as a result.

Packages currently in herd, along with their other maintainers:

net-ftp/cmdftp   : 
net-ftp/filezilla: voyageur@
net-ftp/proftpd  : proxy-maintainers, bernd/lommerzheim.com, 
voyageur@, slyfox@
net-ftp/pure-ftpd: polynomial-c@
net-ftp/tlswrap  : 
net-ftp/vsftpd   : proxy-maintainers, hwoarang@, wired@, 
bugs/bergstroem.nu

-- 
Best regards,
Michał Górny



pgpucqqosCSwm.pgp
Description: OpenPGP digital signature

[gentoo-dev] Herd up for grabs: net-dialup

[Michał Górny]

Hello, everyone.

The current maintainer(s) of net-dialup herd has decided that he's
(they're) not interested in keeping it and would like the packages
to be dropped to maintainer-needed.

Is anyone interested in keeping the herd as-is and maintaining all
packages in it? If I get no reply till 2016-01-24, I will effectively
remove the herd and announce the packages that landed in maintainer-
-needed as a result.

Packages currently in herd, along with their other maintainers:

net-dialup/accel-ppp : pinkbyte@
net-dialup/capi4k-utils  : 
net-dialup/capidivert: 
net-dialup/capifwd   : 
net-dialup/capisuite : 
net-dialup/cistronradius : 
net-dialup/cutecom   : 
net-dialup/dial  : 
net-dialup/diald : 
net-dialup/drdsl : 
net-dialup/dtrace: sbriesen@
net-dialup/dwun  : 
net-dialup/fbgetty   : 
net-dialup/fcpci : 
net-dialup/freeradius: 
net-dialup/freeradius-client : 
net-dialup/globespan-adsl: 
net-dialup/gnuradius : 
net-dialup/gtkterm   : 
net-dialup/hcfpcimodem   : 
net-dialup/isdn-firmware : 
net-dialup/itund : 
net-dialup/kpnadsl4linux : 
net-dialup/linux-atm : 
net-dialup/lrzsz : 
net-dialup/mgetty: 
net-dialup/mingetty  : 
net-dialup/minicom   : 
net-dialup/mwavem: 
net-dialup/picocom   : flameeyes@
net-dialup/ppp   : 
net-dialup/pppconfig : 
net-dialup/ppp-scripts   : 
net-dialup/pptpclient: 
net-dialup/pptpd : 
net-dialup/qtwvdialer: 
net-dialup/radiusclient  : 
net-dialup/radiusclient-ng   : 
net-dialup/rp-l2tp   : 
net-dialup/rp-pppoe  : 
net-dialup/sendpage  : 
net-dialup/sercd : 
net-dialup/speedtouch-usb: 
net-dialup/tkvoice   : 
net-dialup/ueagle4-atm   : 
net-dialup/ueagle-atm: 
net-dialup/wvdial: 
net-dialup/xc: 
net-dialup/xl2tpd: floppym@
net-dns/pdnsd: polynomial-c@
net-libs/libcapi : 
net-libs/wvstreams   : 
net-misc/capiisdnmon : 
net-misc/hylafaxplus : mattm@
net-misc/iaxmodem: 
net-misc/termpkg : 
www-apps/freeradius-dialupadmin : 

-- 
Best regards,
Michał Górny



pgp8K7HGzI4Tu.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] hasufell's extended leave and libressl

[Joshua Kinard]

On 01/16/2016 19:41, Anthony G. Basile wrote:
> Hi everyone,
> 
> I emailed Julian earlier today and asked him to come back.  He state in
> no uncertain terms that he does not intend on coming back.
> 
> Julian and I were working on the libressl project together.  He was
> doing the lion share and I contributed here and there for packages that
> I was interested in.
> 
> I just don't have time to push that project through on my own.  Mostly
> what needs to be done is the migration to the tree as described on the
> following page:
> 
> https://github.com/gentoo/libressl/wiki/Transition-plan
> 
> I'd like to solicit help in pushing this through.  Any takers?

Is the plan to just make packages in the tree compatible with libressl so that
users can choose either one, or to migrate off of openssl entirely?

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] hasufell's extended leave and libressl

[Anthony G. Basile]

On 1/16/16 8:03 PM, Anthony G. Basile wrote:
> On 1/16/16 7:54 PM, Joshua Kinard wrote:
>> On 01/16/2016 19:41, Anthony G. Basile wrote:
>>> Hi everyone,
>>>
>>> I emailed Julian earlier today and asked him to come back.  He state in
>>> no uncertain terms that he does not intend on coming back.
>>>
>>> Julian and I were working on the libressl project together.  He was
>>> doing the lion share and I contributed here and there for packages that
>>> I was interested in.
>>>
>>> I just don't have time to push that project through on my own.  Mostly
>>> what needs to be done is the migration to the tree as described on the
>>> following page:
>>>
>>> https://github.com/gentoo/libressl/wiki/Transition-plan
>>>
>>> I'd like to solicit help in pushing this through.  Any takers?
>>
>> Is the plan to just make packages in the tree compatible with libressl so 
>> that
>> users can choose either one, or to migrate off of openssl entirely?
>>
> 
> The plan is basically this ...
> 
> IUSE="libressl ssl"
> 
> RDEPEND="
> ssl? (
> !libressl? ( dev-libs/openssl:0 )
> libressl? ( dev-libs/libressl )
> )
> "
> 
> You choose either libressl or openssl and you build the entire tree with
> that.
> 


Actually, if people take care of their own packages, that would really
speed things up.

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

Re: [gentoo-dev] Herd up for grabs: net-dialup

[Anthony G. Basile]

On 1/16/16 8:10 PM, Anthony G. Basile wrote:
> On 1/16/16 8:09 PM, Joshua Kinard wrote:
>> On 01/16/2016 12:30, Michał Górny wrote:
>>> Hello, everyone.
>>>
>>> The current maintainer(s) of net-dialup herd has decided that he's
>>> (they're) not interested in keeping it and would like the packages
>>> to be dropped to maintainer-needed.
>>>
>>> Is anyone interested in keeping the herd as-is and maintaining all
>>> packages in it? If I get no reply till 2016-01-24, I will effectively
>>> remove the herd and announce the packages that landed in maintainer-
>>> -needed as a result.
>>>
>>> Packages currently in herd, along with their other maintainers:
>>>
>>> net-dialup/accel-ppp : pinkbyte@
>>> net-dialup/capi4k-utils  : 
>>> net-dialup/capidivert: 
>>> net-dialup/capifwd   : 
>>> net-dialup/capisuite : 
>>> net-dialup/cistronradius : 
>>> net-dialup/cutecom   : 
>>> net-dialup/dial  : 
>>> net-dialup/diald : 
>>> net-dialup/drdsl : 
>>> net-dialup/dtrace: sbriesen@
>>> net-dialup/dwun  : 
>>> net-dialup/fbgetty   : 
>>> net-dialup/fcpci : 
>>> net-dialup/freeradius: 
>>> net-dialup/freeradius-client : 
>>> net-dialup/globespan-adsl: 
>>> net-dialup/gnuradius : 
>>> net-dialup/gtkterm   : 
>>> net-dialup/hcfpcimodem   : 
>>> net-dialup/isdn-firmware : 
>>> net-dialup/itund : 
>>> net-dialup/kpnadsl4linux : 
>>> net-dialup/linux-atm : 
>>> net-dialup/lrzsz : 
>>> net-dialup/mgetty: 
>>> net-dialup/mingetty  : 
>>> net-dialup/minicom   : 
>>> net-dialup/mwavem: 
>>> net-dialup/picocom   : flameeyes@
>>> net-dialup/ppp   : 
>>> net-dialup/pppconfig : 
>>> net-dialup/ppp-scripts   : 
>>> net-dialup/pptpclient: 
>>> net-dialup/pptpd : 
>>> net-dialup/qtwvdialer: 
>>> net-dialup/radiusclient  : 
>>> net-dialup/radiusclient-ng   : 
>>> net-dialup/rp-l2tp   : 
>>> net-dialup/rp-pppoe  : 
>>> net-dialup/sendpage  : 
>>> net-dialup/sercd : 
>>> net-dialup/speedtouch-usb: 
>>> net-dialup/tkvoice   : 
>>> net-dialup/ueagle4-atm   : 
>>> net-dialup/ueagle-atm: 
>>> net-dialup/wvdial: 
>>> net-dialup/xc: 
>>> net-dialup/xl2tpd: floppym@
>>> net-dns/pdnsd: polynomial-c@
>>> net-libs/libcapi : 
>>> net-libs/wvstreams   : 
>>> net-misc/capiisdnmon : 
>>> net-misc/hylafaxplus : mattm@
>>> net-misc/iaxmodem: 
>>> net-misc/termpkg : 
>>> www-apps/freeradius-dialupadmin : 
>>>
>>
>> I can look at taking over net-dialup/xc.  It rarely gets updates anyways, as
>> upstream never intended it to be used on Linux (Xenix and SCO OpenServer were
>> the intended targets).  Somehow, it works, but has quite a few QA issues
>> (namely cavalier sprintf() usage with no buffer overflow checks).  It's been 
>> on
>> my TODO list to fix up one of these days, as well as adding the hard-to-find
>> 5.x release.
>>
>> I've also played with hylafax and iaxmodem before, but no longer have setups 
>> to
>> test those with.
>>
> 
> 
> If people take care of their own packages in that list, that would
> really speed things up!
> 

oops sorry wrong thread :(

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

[gentoo-dev] New project: ML

[Michael Palimaka]

I am announcing the ML project[1], to replace the old herd in
preparation for the implementation of GLEP 67.

1: https://wiki.gentoo.org/wiki/Project:ML

[gentoo-dev] [PATCH 07/16] appendices/editor-configuration/emacs: remove the CVS related setting #558642

[Gokturk Yuksek]

Setting vc-cvs-stay-local to nil causes VC to query the remote repository.
Git is a distributed VCS. As such no equivalent command exists for git.
Remove the CVS related setting.

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/appendices/editor-configuration/emacs/text.xml 
b/appendices/editor-configuration/emacs/text.xml
index 55fade0..37c5504 100644
--- a/appendices/editor-configuration/emacs/text.xml
+++ b/appendices/editor-configuration/emacs/text.xml
@@ -48,7 +48,7 @@ automatically check for the existence of it and ask you to 
add one.
 
 Other useful settings can be disabled backup files
 (by (setq make-backup-files nil) and
-(setq vc-cvs-stay-local nil)), so you don't clutter CVS
+so you don't clutter the git repository
 directories and confuse repoman with it (by adding unnecessary entries
 into a Manifest file e.g.). Emacs can even contact the outside world
 by using the X servers clipboard abilities when yanking, which is
-- 
2.4.10

[gentoo-dev] [PATCH 08/16] ebuild-maintenance: rewrite the text on adding binary files to the tree #558642

[Gokturk Yuksek]

Remove the paragraph about adding binary files to CVS.
Replace the instances of CVS with git.

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
index ac68dcd..10709ea 100644
--- a/ebuild-maintenance/text.xml
+++ b/ebuild-maintenance/text.xml
@@ -42,22 +42,9 @@ above 20KB) which should be distributed as tarballs via the
 Gentoo mirror 
system
 so that people do not waste excessive amounts of bandwidth and hard drive
 space. Also, you should not add binary (non-ASCII) files to the
-Portage CVS tree. If you need to do this in another CVS tree, for
-example, if you need to add a small PNG graphic for whatever reason,
-be sure to add it to CVS by using the -kb option, like so:
-
-
-
-# cvs add -kb myphoto.png
-
-
-
-The -kb option tells CVS that myphoto.png is a binary
-file and should be treated specially.  For example, merging the 
-differences between two different versions of this file should not be 
-allowed to happen, for obvious reasons.  Also, speaking of merging 
+git tree. Also, speaking of merging
 changes, any patches you add to Portage should generally not be 
-compressed.  This will allow CVS to merge changes and correctly inform 
+compressed.  This will allow git to merge changes and correctly inform
 developers of conflicts.
 
 
@@ -149,7 +136,7 @@ simply, 1.0-gentoo.diff.  Also note that the
 gentoo extension informs people that this patch was created 
 by us, the Gentoo Linux developers, rather than having been grabbed from a 
 mailing list or somewhere else. Again, you should not compress these 
-patches because CVS does not play well with binary files.
+patches because git does not play well with binary files.
 
 
 
-- 
2.4.10

[gentoo-dev] [PATCH 06/16] ebuild-writing/user-submitted: do not put user information in ChangeLog #558642

[Gokturk Yuksek]

ChangeLog files are auto-generated by infra post git-migration.
For user-submitted ebuilds, include the user information in the commit
message instead. Mention that user submitted git patches and pull
requests preserve the authorship information by default.

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/ebuild-writing/user-submitted/text.xml 
b/ebuild-writing/user-submitted/text.xml
index ef80c0d..22f8fa8 100644
--- a/ebuild-writing/user-submitted/text.xml
+++ b/ebuild-writing/user-submitted/text.xml
@@ -21,9 +21,11 @@ The user-submitted ebuild must not contain custom headers 
like this:
 
 
 
-Such information should be added to the ChangeLog instead.
-The first ChangeLog entry should always credit the user who
-submitted the ebuild, with their full name and e-mail address.
+Such information should be included in the git commit message instead.
+Note that ebuilds received in the form of git patches or pull requests
+will have the user as the commit author by default, in which case
+including the user information in the commit message explicitly
+may not be necessary.
 
 
 
-- 
2.4.10

[gentoo-dev] [PATCH 01/16] general-concepts/manifest: drop the use of "CVS keyword expansion" #558642

[Gokturk Yuksek]

With the git migration no CVS keyword expansions are happening. However,
Manifest file may still need to be regenerated.

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/general-concepts/manifest/text.xml 
b/general-concepts/manifest/text.xml
index 27ebdef..12961da 100644
--- a/general-concepts/manifest/text.xml
+++ b/general-concepts/manifest/text.xml
@@ -18,8 +18,8 @@ The Manifest may also be digitally signed.
 
 
 To generate the Manifest, use ebuild foo.ebuild manifest. When
-committing, the Manifest file must be regenerated to handle any CVS 
keyword
-expansion changes  repoman will do this automatically.
+committing, the Manifest file must be regenerated to handle any
+changes  repoman will do this automatically.
 
 
 
-- 
2.4.10

[gentoo-dev] [PATCH 02/16] general-concepts/mirrors: substitute "CVS" with "the git tree" #558642

[Gokturk Yuksek]

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/general-concepts/mirrors/text.xml 
b/general-concepts/mirrors/text.xml
index e860988..6e3386a 100644
--- a/general-concepts/mirrors/text.xml
+++ b/general-concepts/mirrors/text.xml
@@ -55,7 +55,7 @@ On rare occasions you may need to replace a file that is 
already mirrored.  In t
 follows:
 
   Put a copy of the new distfile on dev.gentoo.org into 
/space/distfiles-local
-  commit the new manifest to CVS
+  commit the new manifest to the git tree
   wait
 
 After a few hours a cron job on dev.gentoo.org will fetch the file and replace 
the version on the
-- 
2.4.10

[gentoo-dev] [PATCH 03/16] general-concepts/tree: substitute "CVS" with "git" #558642

[Gokturk Yuksek]

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/general-concepts/tree/text.xml b/general-concepts/tree/text.xml
index 022a1ea..6f59f09 100644
--- a/general-concepts/tree/text.xml
+++ b/general-concepts/tree/text.xml
@@ -59,11 +59,11 @@ The basic layout of the portage tree is as follows:
   Scripts directory, scripts/
   
   Distfiles directory, distfiles/. This is not included in the main
-  CVS tree, but it will be found on most user systems.
+  git tree, but it will be found on most user systems.
   
   
   Packages directory, packages. Again, this is found on user systems 
but not
-  in the main CVS tree.
+  in the main git tree.
   
 
 
-- 
2.4.10

[gentoo-dev] [PATCH 00/16] devmanual: update the docs for post git-migration #558642

[Gokturk Yuksek]

Hi,

The following patch series attempt to update devmanual to replace the instances
of CVS with their git equivalents. I tried to keep the changes small in favor
of updating the docs over multiple iterations of patch series. The intention is
to get the bare bone changes in so that the quiz questions can be answered.

Currently not included in the series are:
- References to CVS in sections about herds since they will have to be
  rewritten per GLEP 67 soon anyway.
  See: https://bugs.gentoo.org/show_bug.cgi?id=572144
- I am not sure about what to do with the subsection
  Ebuild Functions/Miscellaneous Files/ChangeLog. The ChangeLog files
  still exist in the rsync tree, however they are of little importance
  in terms of development.

Gokturk Yuksek (16):
  general-concepts/manifest: drop the use of "CVS keyword expansion"
#558642
  general-concepts/mirrors: substitute "CVS" with "the git tree" #558642
  general-concepts/tree: substitute "CVS" with "git" #558642
  general-concepts/tree: replace the mention of ChangeLog #558642
  ebuild-writing/misc-files: replace the code for cvs commit with git
#558642
  ebuild-writing/user-submitted: do not put user information in
ChangeLog #558642
  appendices/editor-configuration/emacs: remove the CVS related setting
#558642
  ebuild-maintenance: rewrite the text on adding binary files to the
tree #558642
  ebuild-maintenance: rewrite the subsection on commit policy for git
#558642
  ebuild-maintenance: rewrite the subsection on upgrading ebuilds for
git #558642
  ebuild-maintenance: rewrite the subsection on moving ebuilds for git
#558642
  ebuild-maintenance: rewrite the subsection on removing ebuilds for git
#558642
  ebuild-maintenance: rewrite the subsection on removing packages for
git #558642
  ebuild-maintenance: replace "cvs commit" with "git commit" #558642
  general-concepts/git-to-rsync/diagram: update the description for git
#558642
  general-concepts/git-to-rsync/diagram: update the description for git
#558642

 appendices/editor-configuration/emacs/text.xml |  2 +-
 ebuild-maintenance/text.xml| 77 ++
 ebuild-writing/common-mistakes/text.xml|  2 +-
 ebuild-writing/misc-files/metadata/text.xml|  3 +-
 ebuild-writing/user-submitted/text.xml |  8 ++-
 general-concepts/git-to-rsync/diagram.svg  |  2 +-
 general-concepts/manifest/text.xml |  4 +-
 general-concepts/mirrors/diagram.svg   |  2 +-
 general-concepts/mirrors/text.xml  |  2 +-
 general-concepts/tree/text.xml |  4 +-
 10 files changed, 44 insertions(+), 62 deletions(-)

-- 
2.4.10

[gentoo-dev] [PATCH 05/16] ebuild-writing/misc-files: replace the code for cvs commit with git #558642

[Gokturk Yuksek]

Replace "cvs commit" with the equivalent "git add && git commit" version.

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/ebuild-writing/misc-files/metadata/text.xml 
b/ebuild-writing/misc-files/metadata/text.xml
index e506b1c..a8beacc 100644
--- a/ebuild-writing/misc-files/metadata/text.xml
+++ b/ebuild-writing/misc-files/metadata/text.xml
@@ -532,7 +532,8 @@ is currently:
 
 xmllint --noout --valid metadata.xml
 glep31check metadata.xml
-cvs commit -m "Adding category metadata.xml for my-category" metadata.xml
+git add metadata.xml
+git commit --gpg-sign -m "Adding category metadata.xml for my-category"
 
 
 
-- 
2.4.10

[gentoo-dev] [PATCH 04/16] general-concepts/tree: replace the mention of ChangeLog #558642

[Gokturk Yuksek]

Package updates do not require changing of the ChangeLog file. Package
updates by users that do not mention what has changed is still
considered a common mistake however.

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/ebuild-writing/common-mistakes/text.xml 
b/ebuild-writing/common-mistakes/text.xml
index 1718d55..1716e5d 100644
--- a/ebuild-writing/common-mistakes/text.xml
+++ b/ebuild-writing/common-mistakes/text.xml
@@ -468,7 +468,7 @@ of the application, if any exists.
 
 
 
-Package updates without changing the ChangeLog
+Package updates without explaining what has changed
 
 
 
-- 
2.4.10

[gentoo-dev] [PATCH 15/16] general-concepts/git-to-rsync/diagram: update the description for git #558642

[Gokturk Yuksek]

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/general-concepts/git-to-rsync/diagram.svg 
b/general-concepts/git-to-rsync/diagram.svg
index 8cf7414..2ee9608 100644
--- a/general-concepts/git-to-rsync/diagram.svg
+++ b/general-concepts/git-to-rsync/diagram.svg
@@ -2,7 +2,7 @@
 http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;>
 http://www.w3.org/2000/svg; version="1.1">
-CVS to RSYNC Propagation
+Git to RSYNC Propagation
 
 
 
-- 
2.4.10

[gentoo-dev] [PATCH 09/16] ebuild-maintenance: rewrite the subsection on commit policy for git #558642

[Gokturk Yuksek]

Remove the mention of updating the ChangeLog.
Remove the mention of file conflicts during commit as CVS keeps track of
files whereas git keeps track of changesets.

Add a note regarding commit atomicity: Git commits are always atomic, so
combining package.mask/license changes with ebuild changes in the same
commit does not violate atomicity. However, there is no way to accomplish
this using repoman commit.

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
index 10709ea..2d46749 100644
--- a/ebuild-maintenance/text.xml
+++ b/ebuild-maintenance/text.xml
@@ -96,7 +96,7 @@ work on those architectures.
 
 
 
-CVS Commit Policy
+Git Commit Policy
 
 
 
@@ -105,15 +105,18 @@ work on those architectures.
 Always test that package.mask is okay by doing 
 emerge --pretend mypkg before you commit and check 
 that it doesn't contain any conflicts.
-Always update the ChangeLog before you commit.
-Always commit the updated package.mask before 
-the updated package, in case conflicts occur while you commit 
-package.mask.
+Always commit the updated package.mask before
+the updated package.
 Always do atomic commits; if you commit a package with a new license, 
 or that is masked, then first commit the revised package.mask 
and/or license, 
 then commit the ebuild, ChangeLog, patches
 and metadata.xml all in 
one go
-to avoid breaking users' installations.
+.
+ Although the set of changes in a single git commit is atomic, and
+combining package.mask/license changes with ebuild changes in a
+single commit wouldn't break atomicity, it is not currently possible to do so
+using repoman commit.
+
 
 
 
-- 
2.4.10

[gentoo-dev] [PATCH 12/16] ebuild-maintenance: rewrite the subsection on removing ebuilds for git #558642

[Gokturk Yuksek]

Substitute the mentions of CVS with git.

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
index 8c542d0..4078d46 100644
--- a/ebuild-maintenance/text.xml
+++ b/ebuild-maintenance/text.xml
@@ -364,8 +364,8 @@ entry which may be affected by your change.
 
 
 When removing an ebuild make sure that no dependencies in Portage are broken
-due to the removal - additionally, your CVS commit message should explain
-clearly why the ebuild is being removed from CVS.
+due to the removal - additionally, your git commit message should explain
+clearly why the ebuild is being removed from the git repository.
 
 
 
-- 
2.4.10

[gentoo-dev] [PATCH 13/16] ebuild-maintenance: rewrite the subsection on removing packages for git #558642

[Gokturk Yuksek]

Substitute the mentions of CVS with git.
Rewrite CVS commands with their git equivalents.
Remove the paragraph about deleting directories in CVS.

X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
Signed-off-by: Gokturk Yuksek 

diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
index 4078d46..7014689 100644
--- a/ebuild-maintenance/text.xml
+++ b/ebuild-maintenance/text.xml
@@ -396,20 +396,15 @@ When removing packages follow these steps:
   Send last rites to gentoo-dev-announce and gentoo-dev
   Mask the package
   Wait 30 days (or more)
-  Remove from CVS unless the reason for removal has been fixed
+  Remove from the git tree unless the reason for removal has been 
fixed
   Remove package.mask entry
   Close open bugs as WONTFIX
  
 
-
-In order to remove a package completely from CVS, delete any files from the
-directory and commit this, CVS will take care of removing empty directories
-itself.
-
-
-# 
cd app-admin
-# cvs rm -Rf scotty
-# cvs ci -m "app-admin/scotty removal 
(pending 21st July 2006), see #77501 for reference." scotty
+
+# cd app-admin
+# git rm -rf scotty
+# git commit --gpg-sign -m 
"app-admin/scotty: removal (pending 21st July 2006), see #77501 for reference." 
scotty
 
 
 
-- 
2.4.10