[gentoo-dev] Re: metadata.xml un-ization, v2
On 10/12/14 06:35, Luca Barbato wrote: > On 09/12/14 17:34, Michał Górny wrote: > >> I'm all for keeping it simple. However, backwards compatibility makes >> it hard to keep things simple. I'd love to do, say, metadata.yml >> supporting stuff like: >> >> - maintainer: f...@gentoo.org, b...@gentoo.org >> >> - maintainer: >>- name: Foo Bar >> email: f...@gentoo.org >>- b...@gentoo.org >> >> (pseudo-code, not sure if it's 100% valid YAML) >> > > Would be neat though. > > Back to the discussion would be nice to have just proj...@gentoo.org > instead of complex mappings. This would be by far the easiest solution. Some herds already have an alias like this eg. freedesktop -> freedesktop-bugs. Much easier than mass-editing every single metadata.xml with what amounts to a cosmetic change.
Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing
Il 09/12/2014 15:26, Martin Vaeth ha scritto:
> viv...@gmail.com wrote:
>> - The project only has 20 commit, last one 8 months ago
>> https://github.com/m-click/mcpdf.git
> The "project" is just a few lines anyway: merely a wrapper to the library.
> All the work happens in the itext library which AFAIK is the same project
> (in different versions) for pdftk as for mcpdf.
> Of course, the new library version might contain new bugs,
> as your example seems to suggest (did pdftk work with this example?)
my example work daily in a box with very few updated and some builds at
least 2 years old, and it's the simplest one.
yet it's working well from a lot of time.
pdftk is NOT only a wrapper to itext (a 9 years old version [2]) it also
include a java library for crypto and it's own management in c++ files.
now, without counting the java crypto lib the c++ files weight around
8k LOC [3]
itext may have been evolved, but calling a 90 LOC java program a "drop
in" replacement for pdftk seem adventurous ...
for comparison `pdftk --help` output is 556 lines of text.
so we can conclude that the "project" is NOT what it claims to be and a
replacement (even using modern itext with licensing problems) will
weight at least at least 556 lines?
>
>> find /g/portage/ -name '*.ebuild' -exec egrep 'sys-devel/gcc.*gcj' {} +
> Searching also through all layman (remote) overlays with
>
> $ eix -#Rry 'sys-devel/gcc[^ ]*gcj'
>
> I found besides the mentioned
>
> app-text/pdftk
> dev-java/ecj-gcj
> dev-java/gcj-jdk
>
> one further dependency:
>
> $ eix -Rvle imule
> net-p2p/imule [1]
> [...] irouter? ( sys-devel/gcc[gcj] ) [...]
> P2P sharing software which connects through I2P and Kad network [...]
> [1] "zugaina" layman/zugaina
[2]
http://sourceforge.net/projects/itextpdf/files/itext-paulo/itext-paulo-155/
[3] $ LC_ALL=C wc -l *cc
542 attachments.cc
498 passwords.cc
4482 pdftk.cc
2433 report.cc
137 win32_utf8_include.cc
8092 total
Re: [gentoo-dev] metadata.xml un-ization, v2
On Tue, Dec 9, 2014 at 11:04 AM, Michał Górny wrote: > Dnia 2014-12-09, o godz. 12:59:26 > Ulrich Mueller napisał(a): > >> >> As the previously stated goal was to get rid of herds, I don't >> understand why you want to reintroduce them as a value of the >> type attribute. The existing herd elements should become either >> type="project" or type="team" (everything that is not a project, >> I suppose). > > As I said, I don't care what final values are. I added a lot of options > to make people happy. As far as I'm concerned, the whole type="" can go > away. I thought we were generally agreed we wanted to get rid of herds. The goal wasn't to rename them, but to get rid of them. We could have email aliases for bugs so that people can sign up for notifications, but they would NOT be considered maintainers. Of course, any would be welcome to become actual maintainers, but as far as treecleaning/etc goes the package is unmaintained. If we just rename "herd" to "team" then we have the same issue where nobody can tell if anybody is taking care of anything because it all goes into some nebulous bin full of packages where nobody is responsible for anything in particular, and nobody can speak for the "team" because it isn't really a team. How about "contact" instead of team. A package could have any number of contacts, and they just get CC'ed on bugs, and there is no meaning to a contact besides being CC'ed on bugs. They're never assignees - if there is nobody else in metadata besides a contact then the assignee is maintainer-wanted. -- Rich
Re: [gentoo-dev] metadata.xml un-ization, v2
On Wed, Dec 10, 2014 at 2:06 AM, Ulrich Mueller wrote: >> On Tue, 9 Dec 2014, Rich Freeman wrote: > >> I thought we were generally agreed we wanted to get rid of herds. >> The goal wasn't to rename them, but to get rid of them. > >> We could have email aliases for bugs so that people can sign up for >> notifications, but they would NOT be considered maintainers. Of >> course, any would be welcome to become actual maintainers, but as >> far as treecleaning/etc goes the package is unmaintained. > >> If we just rename "herd" to "team" then we have the same issue where >> nobody can tell if anybody is taking care of anything because it all >> goes into some nebulous bin full of packages where nobody is >> responsible for anything in particular, and nobody can speak for the >> "team" because it isn't really a team. > >> How about "contact" instead of team. A package could have any >> number of contacts, and they just get CC'ed on bugs, and there is no >> meaning to a contact besides being CC'ed on bugs. They're never >> assignees - if there is nobody else in metadata besides a contact >> then the assignee is maintainer-wanted. > > Now sure it I get this, so can you explain with a concrete example? > Let's say, for a package that currently has xemacs in its > metadata. > That would depend on whether xemacs became a project or not. The first part of my proposal [1] was to review the list of herds and decide which ones were going to become projects, and then review the list of packages and let developers sign up to maintain packages that didn't have a non-herd maintainer. So, if xemacs herd wasn't going to become a project, and nobody signed up to maintain it, then in your example xemacs@g.o would become a contact and the package would be assigned to maintainer-needed. If xemacs decided to become an active project then it would become a project and would be considered maintained. If xemacs decided not to become a project but one or more developers or projects stepped up to maintain it, then xemacs would become a contact and the maintainers who added themselves to metadata would become the maintainers. If you're not actually going to fix the herd problem, then rather than renaming "herds" to "teams" you might as well leave the broken herds in place so that somebody else can actually fix them later. :) 1 - http://article.gmane.org/gmane.linux.gentoo.devel/93587/ -- Rich
Re: [gentoo-dev] metadata.xml un-ization, v2
09.12.2014 14:59, Ulrich Mueller пишет: > "proxy-maintainer" is very confusing because you won't put the proxy > maintainer there, but the user who is being proxied. Please rename > to something like "proxied" (assuming that this exists as a word in > English) or "by-proxy". +1 for that. Proxy maintainer is a Gentoo developer, that commits changes, authored by proxied maintainer, who does not have commit access to main tree -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] metadata.xml un-ization, v2
Dnia 2014-12-09, o godz. 00:46:28
Michał Górny napisał(a):
> So considering the previous thread, the Council and QA discussions, I
> have prepared a new version of the metadata.xml update. To hopefully
> make everyone happy, I come with this three-step process:
And the Council meeting brought a bit of update to this. More
specifically:
1. type="" is now limited to developer, project and team,
corresponding respectively to a single person, a GLEP 39 project (with
webpage) and any other kind of group of people [attached].
2. I've also updated the script to use the new syntax and stop adding
to make things smaller. The herd descriptions are pretty
bad-suited for maintainer anyway.
3. herds.xml is to be deprecated as well, with existing herds being
replaced by projects (GLEP 39) or teams.
4. We eventually want to migrate to another (simpler, more compact)
metadata format, preferably YAML. The exact format is yet to be specced
(for example, I have no good ideas of doing restrict="".
Does anyone have any more comments or should I proceed with updating
the tree for 1+2?
Oh, and as usual the current diff is at:
http://dev.gentoo.org/~mgorny/tmp/herds.diff.xz
--
Best regards,
Michał Górny
Index: metadata.dtd
===
RCS file: /var/cvsroot/gentoo/xml/htdocs/dtd/metadata.dtd,v
retrieving revision 1.13
diff -u -B -r1.13 metadata.dtd
--- metadata.dtd 9 May 2013 06:58:55 - 1.13
+++ metadata.dtd 9 Dec 2014 21:28:03 -
@@ -13,6 +13,11 @@
+
+
+
+
+
#!/usr/bin/env python
from collections import namedtuple
import errno
import glob
from lxml.builder import E
import lxml.etree
import os
import os.path
def main():
herdtuple = namedtuple('herdtuple', ('email', 'name'))
herddb = {}
portdir = '/var/db/repos/gentoo'
herdsfile = os.path.join(portdir, 'metadata/herds.xml')
herdsxml = lxml.etree.parse(herdsfile)
for h in herdsxml.getroot():
k = h.find('name').text
e = h.find('email').text
d = h.find('description').text
herddb[k] = herdtuple(e, d)
intree = portdir
outtree = '/tmp/1'
# LAZINESS!
for f in glob.glob(os.path.join(intree, '*/*/metadata.xml')):
subpath = os.path.relpath(f, intree)
print(subpath)
outf = os.path.join(outtree, subpath)
xml = lxml.etree.parse(f)
herds = xml.getroot().findall('herd')
if not herds: # yay, one file less to care about
continue
r = xml.getroot()
maints = r.findall('maintainer')
if maints:
insertpoint = maints[-1]
else:
insertpoint = herds[-1]
# try to guess indentation
def all_texts(node):
first = True
for e in node:
if first:
yield node.text
first = False
yield e.tail
def all_indents(node):
for t in all_texts(node):
if t is None:
yield ''
return
spl = t.split('\n')
# go to last line without text
for l in spl:
if l.lstrip(' \t') != '':
break
# go to the last line
t = l[:len(l) - len(l.lstrip(' \t'))]
yield t
def sub_indents(node):
for e in node:
for x in all_indents(e):
yield x
# some random defaults
indent = '\t'
try:
indent = max(all_indents(r), key=len)
except ValueError:
pass
inner_indent = indent*2 if indent else '\t'
try:
inner_indent = max(sub_indents(r), key=len)
except ValueError:
pass
# start adding new herds after maintainers
for h in herds:
he = herddb[h.text.strip()]
# look for duplicate entries
for m in maints:
if m.find('email').text.strip() == he.email:
m.set('type', 'herd')
r.remove(h)
break
else:
attrs = dict(h.items())
attrs['type'] = 'team'
nm = E.maintainer('\n',
inner_indent, E.email(he.email), '\n',
indent,
**attrs
)
nextinsert = insertpoint.getnext()
nm.tail = insertpoint.tail
if nextinsert is not None:
r.insert(r.index(nextinsert), nm)
else:
# avoid extra indent
nm.tail = '\n'
r.append(nm)
insertpoint = nm
# now we can remove it safely
r.remove(h)
# now fix pre-indent
prev = nm.getprevious()
if prev is not None:
prev.tail = '\n' + indent
else:
nm.getparent().text = '\n' + indent
try:
os.makedirs(os.path.dirname(outf))
except OSError as e:
if e.errno != errno.EEXIST:
raise
try:
os.unlink(outf)
except OSError as e:
if e.errno != errno.ENOENT:
raise
xml.write(outf, encoding='UTF-8', xml_declaration='1.0')
# yay, add trailing newline because lxml is dumb
with open(outf, 'ab') as f:
f.write(b'\n')
if __name__ == '__main__':
main()
pgpjbMxDkt5Hl.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] New portage-9999 plugin-sync system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/12/2014 07:11, Brian Dolbec wrote: > > For those people running portage-. I've now merged the new > plugin-sync system into the master branch. I've just added the > following einfo block to the .ebuild. I will be preparing a > news item for review soon. We will be extending some of the > modules options, adding more capabilities such as git branch and > depth options. Thank you guys, I'm eager to see it live :) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlSIJhAACgkQKiQSS7ZY+hM1FwD+J9l+qaOunmbpOjOA/c7vac+7 +Yh0GKHWXybXHcUHYTIA/2vQ1AzQMm5Yhy0uZA+iO34aI2LkOEjEbg2qQc6O8Xvh =TpZx -END PGP SIGNATURE-
Re: [gentoo-dev] metadata.xml un-ization, v2
On 09/12/14 17:34, Michał Górny wrote: I'm all for keeping it simple. However, backwards compatibility makes it hard to keep things simple. I'd love to do, say, metadata.yml supporting stuff like: - maintainer: f...@gentoo.org, b...@gentoo.org - maintainer: - name: Foo Bar email: f...@gentoo.org - b...@gentoo.org (pseudo-code, not sure if it's 100% valid YAML) Would be neat though. Back to the discussion would be nice to have just proj...@gentoo.org instead of complex mappings. lu
Re: [gentoo-dev] metadata.xml un-ization, v2
> On Tue, 9 Dec 2014, Rich Freeman wrote: > I thought we were generally agreed we wanted to get rid of herds. > The goal wasn't to rename them, but to get rid of them. > We could have email aliases for bugs so that people can sign up for > notifications, but they would NOT be considered maintainers. Of > course, any would be welcome to become actual maintainers, but as > far as treecleaning/etc goes the package is unmaintained. > If we just rename "herd" to "team" then we have the same issue where > nobody can tell if anybody is taking care of anything because it all > goes into some nebulous bin full of packages where nobody is > responsible for anything in particular, and nobody can speak for the > "team" because it isn't really a team. > How about "contact" instead of team. A package could have any > number of contacts, and they just get CC'ed on bugs, and there is no > meaning to a contact besides being CC'ed on bugs. They're never > assignees - if there is nobody else in metadata besides a contact > then the assignee is maintainer-wanted. Now sure it I get this, so can you explain with a concrete example? Let's say, for a package that currently has xemacs in its metadata. Ulrich pgp27zV7X7x44.pgp Description: PGP signature
