Re: [gentoo-dev] metadata.xml unherd/-ization, v2
Dnia 2014-12-09, o godz. 00:46:28
Michał Górny mgo...@gentoo.org napisał(a):
Hello, all.
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:
1. Add type= attribute to maintainer/ tag (see attached patch),
2. Convert herd/ to maintainer type=herd/,
If anyone cares, attaching my script doing the conversion. It tries
hard to preserve the indentation used in metadata.xml. However, it does
not preserve ' vs in attribute names.
The diff can be seen @
http://dev.gentoo.org/~mgorny/tmp/herds.diff.xz
--
Best regards,
Michał Górny
#!/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()]
attrs = dict(h.items())
attrs['type'] = 'herd'
nm = E.maintainer('\n',
inner_indent, E.email(he.email), '\n',
inner_indent, E.name(he.name), '\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()
pgpyb3eAROl08.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] Lastrites: net-im/linpopup, app-office/teapot, net-irc/bitchx, sys-power/cpufrequtils, x11-plugins/gkrellm-cpufreq, media-sound/gnome-alsamixer, sys-devel/ac-archive, net-misc/emirror
El lun, 08-12-2014 a las 14:46 -0500, Rich Freeman escribió: On Wed, Dec 3, 2014 at 2:07 PM, Michael Orlitzky m...@gentoo.org wrote: It doesn't look like it's going to work so well without cpufrequtils. There's a new homepage with a few new releases at: Are there any actual issues with cpufrequtils, beyond having a dead upstream? It's explained at: https://bugs.gentoo.org/show_bug.cgi?id=484242#c1 Also, indeed, other distributions killed it long time ago (usually in favor of cpupower, the kernel-tools pointed at http://pkgs.fedoraproject.org/cgit/cpufrequtils.git/tree/dead.package ) Regarding the gkrellm-plugins, looks like Fedora is supplying this one: http://pkgs.fedoraproject.org/cgit/gkrellm-freq.git/tree/gkrellm-freq.spec
Re: [gentoo-dev] Lastrites: net-im/linpopup, app-office/teapot, net-irc/bitchx, sys-power/cpufrequtils, x11-plugins/gkrellm-cpufreq, media-sound/gnome-alsamixer, sys-devel/ac-archive, net-misc/emirror
On Tue, Dec 9, 2014 at 5:05 AM, Pacho Ramos pa...@gentoo.org wrote: El lun, 08-12-2014 a las 14:46 -0500, Rich Freeman escribió: On Wed, Dec 3, 2014 at 2:07 PM, Michael Orlitzky m...@gentoo.org wrote: It doesn't look like it's going to work so well without cpufrequtils. There's a new homepage with a few new releases at: Are there any actual issues with cpufrequtils, beyond having a dead upstream? It's explained at: https://bugs.gentoo.org/show_bug.cgi?id=484242#c1 Also, indeed, other distributions killed it long time ago (usually in favor of cpupower, the kernel-tools pointed at http://pkgs.fedoraproject.org/cgit/cpufrequtils.git/tree/dead.package ) Regarding the gkrellm-plugins, looks like Fedora is supplying this one: http://pkgs.fedoraproject.org/cgit/gkrellm-freq.git/tree/gkrellm-freq.spec Hmm, looks like thermald might solve the problem now. Not sure if it was around yet the last time I looked for a substitute. I really just need something that will adjust the governor settings when the CPU gets hot (room and processor cooling isn't ideal). -- Rich
Re: [gentoo-dev] Lastrites: net-im/linpopup, app-office/teapot, net-irc/bitchx, sys-power/cpufrequtils, x11-plugins/gkrellm-cpufreq, media-sound/gnome-alsamixer, sys-devel/ac-archive, net-misc/emirror
El mar, 09-12-2014 a las 06:28 -0500, Rich Freeman escribió: [...] Hmm, looks like thermald might solve the problem now. Not sure if it was around yet the last time I looked for a substitute. I really just need something that will adjust the governor settings when the CPU gets hot (room and processor cooling isn't ideal). -- Rich No idea about what app could do that as, in my case, kernel automatically turns down the CPU speed when it gets hot and, after some time, progressively starts to increase it again if it keeps cool enough (I remember to suffer that a year ago many times with a laptop that was a bit dirty)... not sure why that is not working for you :(
Re: [gentoo-dev] metadata.xml unherd/-ization, v2
On Tue, 9 Dec 2014, Michał Górny wrote: As for the exact details, I've pretty much decided to go for featurism here, IOW making everyone happy. It also proves how absurd typing maintainers is but if you really feel like having it, sure. The default is 'developer', herd/ tags would be converted into 'herd' and there are other options including 'proxy-maintainer', 'project', 'team' meant to fit all our wannabies. The diff explains the particular options. !ELEMENT maintainer ( email, (description| name)* ) +!-- maintainer organizational type -- +!-- developer: regular Gentoo developer (direct e-mail) -- +!-- herd: herd (defined in herds.xml) -- 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). +!-- project: project (having Wiki/g.o project page) -- +!-- proxy-maintainer: maintainer that is not a Gentoo developer + and commits via a proxy -- 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. +!-- team: team of people that is not a herd nor a project -- +!ATTLIST maintainer type (developer|herd|project|proxy-maintainer|team) developer Ulrich pgp8PLOAnOIYP.pgp Description: PGP signature
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On 2014-12-07 11:37, Michał Górny wrote: Hello, developers and users. As some of you know, the toolchain packages in Gentoo suffer from lack-of-sanity issues and their maintainers are completely unwilling to improve things. I have finally decided to start working on a fork of the sys-devel/gcc ebuilds, and I have some bits ready for initial testing in 'mgorny' repo, so I would like to know your opinion. Before you start, the shortcomings are: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. 2. No gcj support. Since the ebuild has been forked out of toolchain.eclass, and the gcj support suffers a lot of issues there, I decided there's no point in copying the code. Not sure if anybody actually uses it, and if it is actually useful for anything but will probably get reintroduced one day [above 'if' applies too]. 3. No bootstrapping, fallbacks and possible some other random feature support. The goal was pretty much to get gcc compiling first, and avoid awful lot of effort if things prove to have no future. 4. Hardened is not tested. I think I have copied all the needed code and fixed some stuff but I have no clue if it still works ;). Now, the major changes are: 1. Most of the insanity removed. No more toolchain.eclass. The ebuild has just the code for the current gcc version. You can read it and know what it does, you don't have to parse a few dozen version conditionals, runtime conditionals and random crap code that doesn't do anything in some gcc versions. In fact, I think I removed most of the no-op code. And now you can actually change something in the ebuild without caring for gcc3.4, or without breaking stuff for stable ebuilds. 2. USE flags are supposed to work. I've replaced the cases when they were silently ignored with REQUIRED_USE. I've also removed the silent removals when they didn't work -- so if your current toolchain is broken, things may actually fail instead of giving your different gcc than you wanted. Probably deserves explanatory pkg_pretend() at some point, with messages like 'disable USE=-foo because your toolchain is broken'. 3. Things simplified where they could have been simplified. For example, I removed the big gcc executable moving function and replaced it with --enable-version-specific-runtime-libs. It was enabled in toolchain.eclass with a comment 'If we enable it on non-Darwin we screw up the behaviour this eclass relies on.' So yep, precious cargo cult -- why enable something that would require you to remove your useless complex function?! 4. Added gx86-multilib love. Now you have abi_* flags to control the compiler runtime. Of course, since gcc is a pile of random modules not fit for one another it has different code for different targets. In particular, on mips you can't do two ABIs -- either single one (non-multilib) or all three of them (--enable-multilib). 5. Added multilib gcc wrappers. Long story short, multilib gcc now shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it doesn't screw up your system! Of course, the final implementation may differ since it's an early idea but it works. Now distcc happily builds stuff for your x86 clients. 6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen rather than silently skipping doc build when it's not installed... 7. Disabled bootstrap by default (and in fact completely for now). It is not *that* useful, and means time savings (and distcc support): Thu Nov 6 20:39:31 2014 sys-devel/gcc-4.9.2 merge time: 1 hour, 56 minutes and 43 seconds. Sun Dec 7 10:46:08 2014 sys-devel/gcc-4.9.2-r100 merge time: 34 minutes and 55 seconds. If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd appreciate any bug reports, except for those covering things i've already listed as missing :). Any further comments will be very helpful in deciding on the way forward. If there is a real interest in my fork, I will probably move it to gx86 as sys-devel/gcc-mgorny. I will also be happy to work on replacing the new versions of original sys-devel/gcc completely. With QA process against toolchain.eclass if necessary. Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!), tested to build some core stuff with it: kernel 3.17, glibc, coreutils, openssl, ssh... All seems to work fine. I'll try to recompile the whole machine with it. After emerge, there are these notices: * QA Notice: command not found: * * /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 3110: pax-mark: command not found * /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 3111: pax-mark: command not found # emerge -pvq gcc [ebuild R ] sys-devel/gcc-4.9.2-r100 USE=cxx fortran nls nptl openmp pie sanitize (-altivec) -doc (-fixed-point) -go -graphite (-hardened) (-libssp) -objc -objc++
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
Dnia 2014-12-09, o godz. 14:23:21 Tomas Mozes tomas.mo...@shmu.sk napisał(a): On 2014-12-07 11:37, Michał Górny wrote: Hello, developers and users. As some of you know, the toolchain packages in Gentoo suffer from lack-of-sanity issues and their maintainers are completely unwilling to improve things. I have finally decided to start working on a fork of the sys-devel/gcc ebuilds, and I have some bits ready for initial testing in 'mgorny' repo, so I would like to know your opinion. Before you start, the shortcomings are: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. 2. No gcj support. Since the ebuild has been forked out of toolchain.eclass, and the gcj support suffers a lot of issues there, I decided there's no point in copying the code. Not sure if anybody actually uses it, and if it is actually useful for anything but will probably get reintroduced one day [above 'if' applies too]. 3. No bootstrapping, fallbacks and possible some other random feature support. The goal was pretty much to get gcc compiling first, and avoid awful lot of effort if things prove to have no future. 4. Hardened is not tested. I think I have copied all the needed code and fixed some stuff but I have no clue if it still works ;). Now, the major changes are: 1. Most of the insanity removed. No more toolchain.eclass. The ebuild has just the code for the current gcc version. You can read it and know what it does, you don't have to parse a few dozen version conditionals, runtime conditionals and random crap code that doesn't do anything in some gcc versions. In fact, I think I removed most of the no-op code. And now you can actually change something in the ebuild without caring for gcc3.4, or without breaking stuff for stable ebuilds. 2. USE flags are supposed to work. I've replaced the cases when they were silently ignored with REQUIRED_USE. I've also removed the silent removals when they didn't work -- so if your current toolchain is broken, things may actually fail instead of giving your different gcc than you wanted. Probably deserves explanatory pkg_pretend() at some point, with messages like 'disable USE=-foo because your toolchain is broken'. 3. Things simplified where they could have been simplified. For example, I removed the big gcc executable moving function and replaced it with --enable-version-specific-runtime-libs. It was enabled in toolchain.eclass with a comment 'If we enable it on non-Darwin we screw up the behaviour this eclass relies on.' So yep, precious cargo cult -- why enable something that would require you to remove your useless complex function?! 4. Added gx86-multilib love. Now you have abi_* flags to control the compiler runtime. Of course, since gcc is a pile of random modules not fit for one another it has different code for different targets. In particular, on mips you can't do two ABIs -- either single one (non-multilib) or all three of them (--enable-multilib). 5. Added multilib gcc wrappers. Long story short, multilib gcc now shows up in gcc-config alike crossdev -- but unlike i686 crossdev, it doesn't screw up your system! Of course, the final implementation may differ since it's an early idea but it works. Now distcc happily builds stuff for your x86 clients. 6. Added missing dependencies. Yep, USE flags now, say, pull in doxygen rather than silently skipping doc build when it's not installed... 7. Disabled bootstrap by default (and in fact completely for now). It is not *that* useful, and means time savings (and distcc support): Thu Nov 6 20:39:31 2014 sys-devel/gcc-4.9.2 merge time: 1 hour, 56 minutes and 43 seconds. Sun Dec 7 10:46:08 2014 sys-devel/gcc-4.9.2-r100 merge time: 34 minutes and 55 seconds. If you're interested in testing it, 'layman -a mgorny' and enjoy. I'd appreciate any bug reports, except for those covering things i've already listed as missing :). Any further comments will be very helpful in deciding on the way forward. If there is a real interest in my fork, I will probably move it to gx86 as sys-devel/gcc-mgorny. I will also be happy to work on replacing the new versions of original sys-devel/gcc completely. With QA process against toolchain.eclass if necessary. Thanks, I've tried this on ~amd64. It builds in 10 minutes (wow!), tested to build some core stuff with it: kernel 3.17, glibc, coreutils, openssl, ssh... All seems to work fine. I'll try to recompile the whole machine with it. After emerge, there are these notices: * QA Notice: command not found: * * /var/tmp/portage/sys-devel/gcc-4.9.2-r100/temp/environment: line 3110: pax-mark: command not found *
[gentoo-dev] Re: sys-devel/gcc::mgorny up for testing
viv...@gmail.com 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?)
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
Re: [gentoo-dev] Lastrites: net-im/linpopup, app-office/teapot, net-irc/bitchx, sys-power/cpufrequtils, x11-plugins/gkrellm-cpufreq, media-sound/gnome-alsamixer, sys-devel/ac-archive, net-misc/emirror
On Tue, 09 Dec 2014 11:05:31 +0100 Pacho Ramos pa...@gentoo.org wrote: El lun, 08-12-2014 a las 14:46 -0500, Rich Freeman escribió: On Wed, Dec 3, 2014 at 2:07 PM, Michael Orlitzky m...@gentoo.org wrote: It doesn't look like it's going to work so well without cpufrequtils. There's a new homepage with a few new releases at: Are there any actual issues with cpufrequtils, beyond having a dead upstream? It's explained at: https://bugs.gentoo.org/show_bug.cgi?id=484242#c1 Also, indeed, other distributions killed it long time ago (usually in favor of cpupower, the kernel-tools pointed at http://pkgs.fedoraproject.org/cgit/cpufrequtils.git/tree/dead.package ) Regarding the gkrellm-plugins, looks like Fedora is supplying this one: http://pkgs.fedoraproject.org/cgit/gkrellm-freq.git/tree/gkrellm-freq.spec gkrellm-freq-1.0 was removed from the tree: https://bugs.gentoo.org/show_bug.cgi?id=334907 https://bugs.gentoo.org/show_bug.cgi?id=339908 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-plugins/gkrellm-gkfreq/ChangeLog?view=markup But it looks like there's a new 2.3 version of it: http://sourceforge.net/projects/gkrellm-gkfreq/ I will try to recreate ebuild in my overlay and test it.
Re: [gentoo-dev] metadata.xml unherd/-ization, v2
On Tue, 9 Dec 2014 12:59:26 +0100 Ulrich Mueller u...@gentoo.org wrote: On Tue, 9 Dec 2014, Michał Górny wrote: As for the exact details, I've pretty much decided to go for featurism here, IOW making everyone happy. It also proves how absurd typing maintainers is but if you really feel like having it, sure. The default is 'developer', herd/ tags would be converted into 'herd' and there are other options including 'proxy-maintainer', 'project', 'team' meant to fit all our wannabies. The diff explains the particular options. !ELEMENT maintainer ( email, (description| name)* ) +!-- maintainer organizational type -- +!-- developer: regular Gentoo developer (direct e-mail) -- +!-- herd: herd (defined in herds.xml) -- 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). Probably because of the rather verbose criticism brought forward by a single developer. jer
Re: [gentoo-dev] metadata.xml unherd/-ization, v2
Am Dienstag 09 Dezember 2014, 00:46:28 schrieb Michał Górny: 2. Convert herd/ to maintainer type=herd/, Could any person type=developer/ please explain to me why this additional xmlfication is of any improvement type=nonzero/? As far as I know the typical way to edit metadata.xml files for all of us is still by hand in a text editor, and I prefer a lot typing herdkde/herd over maintainer type=herdkde/maintainer Cheers, Andreas PS. This is a mere syntactical point, and not taking side in any way for/against herds. Separate mail. -- Andreas K. Huettel Gentoo Linux developer kde, council signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] metadata.xml unherd/-ization, v2
Dnia 2014-12-09, o godz. 16:49:24 Andreas K. Huettel dilfri...@gentoo.org napisał(a): Am Dienstag 09 Dezember 2014, 00:46:28 schrieb Michał Górny: 2. Convert herd/ to maintainer type=herd/, Could any person type=developer/ please explain to me why this additional xmlfication is of any improvement type=nonzero/? As far as I know the typical way to edit metadata.xml files for all of us is still by hand in a text editor, and I prefer a lot typing herdkde/herd over maintainer type=herdkde/maintainer maintainer type=herd emailk...@gentoo.org/email nameLovely KDE herd/name /maintainer to be more precise. This was already explained in my previous thread. Because: 1. valid email/ is much more useful than semi-ambiguous herd/, 2. bug assignment in order is simpler than magical rules like 'maintainer first, herd second unless description says otherwise', 3. herds.xml is global, metadata.xml is per-repo. Many of us *read* metadata.xml via cat or simple text editor, and don't want to be forced to use slow tools like 'equery' to make semi-meaningful output out of it. And I believe reading happens much more often than writing. That said, vim starts with useful template for metadata.xml. It's easy to copy maintainer/ element and fill in different e-mail addresses. I'd honestly drop the whole type= but a few developers insist on keeping the extra disambiguation. -- Best regards, Michał Górny pgpyPEfk65aCK.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] metadata.xml unherd/-ization, v2
Dnia 2014-12-09, o godz. 12:59:26 Ulrich Mueller u...@gentoo.org napisał(a): On Tue, 9 Dec 2014, Michał Górny wrote: As for the exact details, I've pretty much decided to go for featurism here, IOW making everyone happy. It also proves how absurd typing maintainers is but if you really feel like having it, sure. The default is 'developer', herd/ tags would be converted into 'herd' and there are other options including 'proxy-maintainer', 'project', 'team' meant to fit all our wannabies. The diff explains the particular options. !ELEMENT maintainer ( email, (description| name)* ) +!-- maintainer organizational type -- +!-- developer: regular Gentoo developer (direct e-mail) -- +!-- herd: herd (defined in herds.xml) -- 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. +!-- project: project (having Wiki/g.o project page) -- +!-- proxy-maintainer: maintainer that is not a Gentoo developer + and commits via a proxy -- 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. Because the whole naming in proxy-maintainership is confusing :). -- Best regards, Michał Górny pgpKKmIPbisCX.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
Dnia 2014-12-08, o godz. 09:56:11 Alexis Ballier aball...@gentoo.org napisał(a): On Sun, 7 Dec 2014 11:37:57 +0100 Michał Górny mgo...@gentoo.org wrote: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. Could you please elaborate on this ? How and why this broke, what is wrong in glibc, what would be a sane crossdev alternative and how crossdev is not. 1. eblits are broken in glibc. Another case of incorrect interpretation of code sharing with love for breaking stable ebuilds. Plus I'd love to add multilib flags to it but we'll likely doing that to main glibc as well soon, if eblits don't get into our way. 2. crossdev is broken because it creates semi-random, unmaintained ebuilds in randomly chosen overlay, those ebuilds relying on toolchain.eclass behavior. 3. I don't have any real alternative design yet. However, one of the first ideas of changing crossdev is to replace copying ebuilds with symlinking gcc ebuild directory. This will at least ensure proper sync between real ebuilds and cross-ebuilds. -- Best regards, Michał Górny pgpxIrlqF6nnb.pgp Description: OpenPGP digital signature
Re: Re: [gentoo-dev] metadata.xml unherd/-ization, v2
As far as I know the typical way to edit metadata.xml files for all of us is still by hand in a text editor, and I prefer a lot typing herdkde/herd over maintainer type=herdkde/maintainer maintainer type=herd emailk...@gentoo.org/email nameLovely KDE herd/name /maintainer to be more precise. Ugh. Even more ugly stuff from the department of redundancy department. (Yeah usually I just copy an existing file too...) Keep it simple. The only result of stuffing more and more requirements into auxiliary files is that noone will fill them out completely. 1. valid email/ is much more useful than semi-ambiguous herd/, 2. bug assignment in order is simpler than magical rules like 'maintainer first, herd second unless description says otherwise', 3. herds.xml is global, metadata.xml is per-repo. Many of us *read* metadata.xml via cat or simple text editor, and don't want to be forced to use slow tools like 'equery' to make semi-meaningful output out of it. So the solution is to duplicate all information into every package directory. Great. (And if I want to send an e-mail to the postgresql team I still have to figure out how their alias looks like or find a package that they maintain first.) Why not instead come up with a new set of rules (and maybe new tags) that simplify? As example, scratch herd/, add project/ with a 1:1 transformation of argument to mail address. As example, always assign bugs to first entry. -- Andreas K. Huettel Gentoo Linux developer kde, council signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
Dnia 2014-12-08, o godz. 07:27:51 Anthony G. Basile bluen...@gentoo.org napisał(a): On 12/07/14 08:18, Michał Górny wrote: I will also be happy to work on replacing the new versions of original sys-devel/gcc completely. With QA process against toolchain.eclass if necessary. Let's get the list of QA issues so I at least can work towards a toolchain-r1.eclass if you're not interested in going that way. Also, I take the QA issues seriously, but threatening a QA intervention against toolchain and then acting by forking is heavy handed. QA actions against the current codebase is understandable. So to sum, I'd like to see the QA issues (and others) address in the current approache and toolchain.eclass. Since we can make mistakes and since toolchain is fragile, I suggest a toolchain-r1.eclass where we can test (just change the inheritance in gcc ebuilds for testing) and finally, when we're happy, do the switcheroo. First QA issue: toolchain.eclass is intrusive and makes ebuilds hard to understand and track. If you can remove it and make gcc into proper ebuilds that can get revision-level changes, we can discuss. Hey! why don't I join QA so I can also fix eclasses that I find intrusive. Let's not make QA the final refuge of those who want to push through their preferences. Yes, that's exactly what occurred to me! Then I joined QA. But seriously saying, I didn't mean forcing anything on anyone myself. I meant starting proper QA process which could eventually hopefully result in QA prohibiting the use of current eclass in future ebuilds, and or referring to the Council about switching the default gcc provider. Of course, that's only the worst scenario. To proceed forward, you have bugs open against toolchain.eclass. The practice is to submit the patches to this list for review. If after awards you have community support, commit despite the maintainer's objections. Having obtained community support, you will have much more legitimacy against reverts. I can't speak for the whole council, but I would support you under such circumstances. I cannot support a position where QA simply asserts itself. When/if an appeal percolates up to the council, I will side with the maintainer under the argument that the commit to the eclass was not sufficiently reviewed. As I already said, the main issue simply can't be fixed this way. It's not that much *bugs in code in toolchain.eclass* but *what's in toolchain.eclass*. If we think of eclasses as libraries, then your library provides main() function. With conditionals for 14 consecutive releases of your program. And you already told people to link random stuff to it, and rely on every internal API detail. -- Best regards, Michał Górny pgpCY7C6hAMlb.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] metadata.xml unherd/-ization, v2
Dnia 2014-12-09, o godz. 17:17:35 Andreas K. Huettel dilfri...@gentoo.org napisał(a): As far as I know the typical way to edit metadata.xml files for all of us is still by hand in a text editor, and I prefer a lot typing herdkde/herd over maintainer type=herdkde/maintainer maintainer type=herd emailk...@gentoo.org/email nameLovely KDE herd/name /maintainer to be more precise. Ugh. Even more ugly stuff from the department of redundancy department. (Yeah usually I just copy an existing file too...) Keep it simple. The only result of stuffing more and more requirements into auxiliary files is that noone will fill them out completely. 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) But that's another topic, and a lot of work to support, and most of the tools will never be fixed to support it. 1. valid email/ is much more useful than semi-ambiguous herd/, 2. bug assignment in order is simpler than magical rules like 'maintainer first, herd second unless description says otherwise', 3. herds.xml is global, metadata.xml is per-repo. Many of us *read* metadata.xml via cat or simple text editor, and don't want to be forced to use slow tools like 'equery' to make semi-meaningful output out of it. So the solution is to duplicate all information into every package directory. Great. Just the e-mail. (And if I want to send an e-mail to the postgresql team I still have to figure out how their alias looks like or find a package that they maintain first.) How about just using the e-mail? You don't CC all the team members, do you? Why not instead come up with a new set of rules (and maybe new tags) that simplify? As example, scratch herd/, add project/ with a 1:1 transformation of argument to mail address. As example, always assign bugs to first entry. That is *precisely the goal* of this. We scratch herd/ and project/, and just use well-supported maintainer/ tag. type= is entirely optional, unobtrusive and backwards-compatible with existing apps. And yes, with just maintainer/ tag the rule in bug assignment is always to the first entry. -- Best regards, Michał Górny pgpnYUBluFop4.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
В Tue, 9 Dec 2014 17:21:22 +0100 Michał Górny mgo...@gentoo.org пишет: Dnia 2014-12-08, o godz. 09:56:11 Alexis Ballier aball...@gentoo.org napisał(a): On Sun, 7 Dec 2014 11:37:57 +0100 Michał Górny mgo...@gentoo.org wrote: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. Could you please elaborate on this ? How and why this broke, what is wrong in glibc, what would be a sane crossdev alternative and how crossdev is not. 1. eblits are broken in glibc. Another case of incorrect interpretation of code sharing with love for breaking stable ebuilds. Plus I'd love to add multilib flags to it but we'll likely doing that to main glibc as well soon, if eblits don't get into our way. Yeah. Stable glibc ebuild gets broken from time to time after changes in eblits. 2. crossdev is broken because it creates semi-random, unmaintained ebuilds in randomly chosen overlay, those ebuilds relying on toolchain.eclass behavior. 3. I don't have any real alternative design yet. However, one of the first ideas of changing crossdev is to replace copying ebuilds with symlinking gcc ebuild directory. This will at least ensure proper sync between real ebuilds and cross-ebuilds. crossdev already works that way for a long time (see -oO option in help): $ ls -l /var/cache/portage/repos/crossdev/cross-armv6j-hardfloat-linux-gnueabi/ total 0 lrwxrwxrwx 1 portage portage 42 Oct 23 22:24 binutils - /var/cache/portage/tree/sys-devel/binutils lrwxrwxrwx 1 portage portage 37 Oct 23 22:24 gcc - /var/cache/portage/tree/sys-devel/gcc lrwxrwxrwx 1 portage portage 37 Oct 23 22:24 gdb - /var/cache/portage/tree/sys-devel/gdb lrwxrwxrwx 1 portage portage 38 Oct 23 22:24 glibc - /var/cache/portage/tree/sys-libs/glibc lrwxrwxrwx 1 portage portage 48 Oct 23 22:24 linux-headers - /var/cache/portage/tree/sys-kernel/linux-headers -- Alexander Tsoy
Re: [gentoo-dev] sys-devel/gcc::mgorny up for testing
On Tue, 9 Dec 2014 17:21:22 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2014-12-08, o godz. 09:56:11 Alexis Ballier aball...@gentoo.org napisał(a): On Sun, 7 Dec 2014 11:37:57 +0100 Michał Górny mgo...@gentoo.org wrote: 1. No cross-compilation support. If the project proves being a success it will be readded at some point. However, I will likely fork glibc first and work on a sane crossdev alternative. Could you please elaborate on this ? How and why this broke, what is wrong in glibc, what would be a sane crossdev alternative and how crossdev is not. 1. eblits are broken in glibc. Another case of incorrect interpretation of code sharing with love for breaking stable ebuilds. its a local toolchain.eclass yes Plus I'd love to add multilib flags to it but we'll likely doing that to main glibc as well soon, if eblits don't get into our way. keep in mind that, thanks to implicit system deps, you'll have to use.force what your toolchain is supposed to be able to produce. also, you'll probably face much more problems with bootstrapping than the cosmetics of eblits: get a gcc that can compile .o for your abi is easy, but you do not have the libc yet so can't link anything unless you use nodefaultlibs alike switches 2. crossdev is broken because it creates semi-random, unmaintained ebuilds in randomly chosen overlay, those ebuilds relying on toolchain.eclass behavior. it symlinks the dirs these days, so its not unmaintained toolchain.eclass behavior you're referring to is probably the category parsing to get CTARGET; this is very likely used in all other libc ebuilds so you'll have to fix them too; not mentioning the ability to update your cross toolchains with 'emerge world' that you cant do if you dont feed CTARGET in some way. 3. I don't have any real alternative design yet. However, one of the first ideas of changing crossdev is to replace copying ebuilds with symlinking gcc ebuild directory. This will at least ensure proper sync between real ebuilds and cross-ebuilds. as said above, this is the case here Alexis.
Re: [gentoo-dev] metadata.xml unherd/-ization, v2
On Tue, 9 Dec 2014, Michał Górny wrote: That is *precisely the goal* of this. We scratch herd/ and project/, and just use well-supported maintainer/ tag. type= is entirely optional, unobtrusive and backwards-compatible with existing apps. And yes, with just maintainer/ tag the rule in bug assignment is always to the first entry. This still means that you either - duplicate in every package dir information that is also maintained elsewhere, like mapping from herd or project name to its e-mail address, or - need to do reverse mapping, e.g. from the e-mail address to the project's name. Ulrich pgpCg9J7JLSSz.pgp Description: PGP signature
Re: [gentoo-dev] metadata.xml unherd/-ization, v2
Dnia 2014-12-09, o godz. 18:59:22 Ulrich Mueller u...@gentoo.org napisał(a): On Tue, 9 Dec 2014, Michał Górny wrote: That is *precisely the goal* of this. We scratch herd/ and project/, and just use well-supported maintainer/ tag. type= is entirely optional, unobtrusive and backwards-compatible with existing apps. And yes, with just maintainer/ tag the rule in bug assignment is always to the first entry. This still means that you either - duplicate in every package dir information that is also maintained elsewhere, like mapping from herd or project name to its e-mail address, or - need to do reverse mapping, e.g. from the e-mail address to the project's name. Sure. But usually the e-mail address is more useful than the project name. Plus, it's unique so we can use it to identify projects without having to really care about names, project page addresses etc. E-mail is the common denominator between all different maintainer types. -- Best regards, Michał Górny pgprvAqdft_eW.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] metadata.xml unherd/-ization, v2
Dnia 2014-12-09, o godz. 10:15:09
Michał Górny mgo...@gentoo.org napisał(a):
Dnia 2014-12-09, o godz. 00:46:28
Michał Górny mgo...@gentoo.org napisał(a):
Hello, all.
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:
1. Add type= attribute to maintainer/ tag (see attached patch),
2. Convert herd/ to maintainer type=herd/,
If anyone cares, attaching my script doing the conversion. It tries
hard to preserve the indentation used in metadata.xml. However, it does
not preserve ' vs in attribute names.
The diff can be seen @
http://dev.gentoo.org/~mgorny/tmp/herds.diff.xz
And a small update to the script attached, that avoids adding duplicate
maintainer/ tags when herd's already in maintainer/ as well. Linked
diff updated as well.
--
Best regards,
Michał Górny
#!/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 herd/ 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'] = 'herd'
nm = E.maintainer('\n',
inner_indent, E.email(he.email), '\n',
inner_indent, E.name(he.name), '\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()
pgpDOQo1eZbAs.pgp
Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] Almost always print ::repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/12/14 22:05, Brian Dolbec wrote: ^^^ what the hell is that, another olde English word ;) Nowt = Naught = Nothing Owt = Aught = Anything They are prominently used today as well. As for the patch itself: I like the idea, but where is this requested? Do users actually want it? Also, I would prefer to remove the old option entirely. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlSGszkACgkQRtClrXBQc7XROwD+PnBiyivmwJ7x8+x7Qe+TgGSs JfvdZPDtxwgaGXoTT8oA/ixK1djJa5SDQTiuQ+tVVOgRFxo69PTaXM0g6o/rGpcR =j3fc -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] emerge --info: Modernize output of configuration of repositories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/12/14 20:04, Arfrever Frehtes Taifersar Arahesis wrote: + for skipped_var in skipped_vars: + try: + myvars.remove(skipped_var) + except ValueError: + pass + wat - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlSGt90ACgkQRtClrXBQc7WbPQD9E7Co8kmP5FviWlU0h2262iWj fNzPMFcCk5vNaj6xGzAA/3RsaZJhDCnDhlkrc1L25HKGbT1gESPjm4Dhu0IDFHZV =8KHv -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Support for per-repository per-attribute environmental variables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/12/14 01:33, Arfrever Frehtes Taifersar Arahesis wrote: I suggest to add support for per-repository per-attribute environmental variables in Portage. These variables would be used when PORTAGE_REPOSITORIES is not set. Please file a bug report. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlSGuBQACgkQRtClrXBQc7VRXwD9GvR4uIUGetdl21xVBO6i1AnW A4iHqFDikIj+HYdCsf0A/2VGftRhK+PFNS6jq4Jg6zpbxky1SG+cjmweLTw71C/3 =Fb7p -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] emerge --info: Modernize output of configuration of repositories
2014-12-09 09:50 Alexander Berntsen napisał(a): On 08/12/14 20:04, Arfrever Frehtes Taifersar Arahesis wrote: + for skipped_var in skipped_vars: + try: + myvars.remove(skipped_var) +except ValueError: + pass + wat It is deleting elements from a list. mylist = [ab, cd, ef] mylist ['ab', 'cd', 'ef'] mylist.remove(cd) mylist ['ab', 'ef'] mylist.remove(cd) Traceback (most recent call last): File stdin, line 1, in module ValueError: list.remove(x): x not in list -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Almost always print ::repository
2014-12-09 09:30 Alexander Berntsen napisał(a): As for the patch itself: I like the idea, but where is this requested? It is part of work for deleting any remaining uses of deprecated PORTDIR, PORTDIR_OVERLAY and SYNC variables, mainRepo() and mainRepoLocation() functions, main-repo attribute. Also, I would prefer to remove the old option entirely. OK. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
