Re: [gentoo-dev] rewritten epatch
On Saturday 19 December 2009 07:33:33 Diego Elio “Flameeyes” Pettenò wrote: Il giorno ven, 18/12/2009 alle 23.56 -0800, Brian Harring ha scritto: For changes of this sort, abusing the tinderboxes to get a real world test run makes a lot of sense. I can put it into run with the tinderbox, no problem with that. i'm guessing you havent seen any problems then -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rewritten epatch
i'm guessing you havent seen any problems then Sorry forgot to notice you, nope the tinderbox completed the run, and restarted now, no problem at all. -- Diego Flameeyes Pettenò - flamee...@gmail.com Free Software developer and consultant http://blog.flameeyes.eu/
[gentoo-dev] Lastrite: net-analyzer/zabbix-{agent,frontend,server}
# Patrick Lauer patr...@gentoo.org (09 Jan 2010) # Package has been unsplit, use net-analyzer/zabbix net-analyzer/zabbix-agent net-analyzer/zabbix-frontend net-analyzer/zabbix-server Unmaintained and no longer useful as package has been unsplit
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
El jue, 07-01-2010 a las 15:59 -0700, Denis Dupeyron escribió: 2010/1/2 Pacho Ramos pa...@condmat1.ciencias.uniovi.es: [...] I failed to see if, finally, an approval from the council is needed for merging [multilib] to portage-2.2 or not The only approval that's required to merge anything to an official portage branch is Zac's (zmedico). He may have to follow some rules and wait for some vote from the council when for example EAPIs are concerned but whether to merge code or not is his decision and responsibility. That said I've never seen him refusing to merge anything that was worth it. if [multilib] will be discussed finally on this meeting. Technically we don't need to (I'll explain that in another email) but we may. I'm just starting to work on the agenda for the 18th and I don't have everything in place yet. Denis. OK, thanks a lot for the information :-) Best regards signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Documentation licenses and license_groups
On Thu, 7 Jan 2010, Hanno Böck wrote:
- Add GPL-1 and LGPL-2 to @GPL-COMPATIBLE
- Add a new group @FSF-APPROVED-OTHER containing the following:
Arphic
CCPL-Attribution-2.0
CCPL-Attribution-ShareAlike-2.0
DSL
FDL-1.1 FDL-1.2 FDL-1.3
FreeArt
GPL-1 GPL-2 GPL-3
OFL-1.1
OPL
I already went ahead and committed two new sets - FREE-DOCUMENTS and
MISC-FREE.
The above ones could probably be all added to FREE-DOCUMENTS.
Done, but I kept the FSF-APPROVED-OTHER set separate so that following
upstream changes will be easier.
And thanks for adding the FREE set and its FREE-{SOFTWARE,DOCUMENTS}
subsets. Accepting @FREE is enough for all packages in stage3, except
for man-pages-posix.
Not sure what we should do about this one. The crucial sentence is:
,
| Modifications to the text are permitted so long as any conflicts
| with the standard are clearly marked as such in the text.
`
Any opinions?
Ulrich
Re: [gentoo-dev] Some ideas on the licensing issue
On Thu, 7 Jan 2010, Hanno Böck wrote: So what do you suggest? Remove GPL-COMPATIBLE and move everything into FSF-APPROVED? Yeah, I think that's reasonable. I've just learned that GLEP 23 explicitly requires GPL-COMPATIBLE to be present. The GLEP would also require a NON-MUST-HAVE-READ group: NON-MUST-HAVE-READ licenses are those that don't require manual acceptance for to be considered legally binding. Whatever that means. Ulrich
Re: [gentoo-dev] Some ideas on the licensing issue
On Sat, Jan 09, 2010 at 08:52:10PM +0100, Ulrich Mueller wrote: On Thu, 7 Jan 2010, Hanno Böck wrote: So what do you suggest? Remove GPL-COMPATIBLE and move everything into FSF-APPROVED? Yeah, I think that's reasonable. I've just learned that GLEP 23 explicitly requires GPL-COMPATIBLE to be present. The GLEP would also require a NON-MUST-HAVE-READ group: NON-MUST-HAVE-READ licenses are those that don't require manual acceptance for to be considered legally binding. Whatever that means. Some licenses (eg some in @EULA) require explicit acceptance of the license. @NON-MUST-HAVE-READ was supposed to be all licenses that you agree to merely by using any material under them. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Documentation licenses and license_groups
Ulrich Mueller wrote: Not sure what we should do about this one. The crucial sentence is: , | Modifications to the text are permitted so long as any conflicts | with the standard are clearly marked as such in the text. ` Any opinions? It seems fine to me. I think it's somewhat analogous to how a modified TeX file must have a new name: it's a minor annoyance, but it doesn't particularly restrict the end result.
