Re: [gentoo-dev] Openstack image availability
I thought I would point out a few things 1) Did you happen to see this guys step by step instructions for creating a cloud image: http://terrarum.net/blog/creating-a-gentoo-cloud-image.html I basically followed these instructions a year or so ago, and with a few tweaks was able to get Gentoo running on OpenStack. 2) I have extensive knowledge of OpenStack, it's been my profession for the past 2 years, so if you need any assistance, let me know. There are automated platforms such as Fuel by Mirantis that can help people deploy OpenStack on a virtual environment in case anyone wanted to try it out. Also DevStack is another common platform people use to test with. Just throwing my 2 cents into the conversation - Daniel On Mon, Jun 8, 2015 at 12:56 PM, Matthew Thode prometheanf...@gentoo.org wrote: On 06/08/2015 01:38 PM, wirel...@tampabay.rr.com wrote: On 06/08/2015 10:30 AM, Matthew Thode wrote: Hi, I've just started generation of Gentoo Openstack images. Right now it is just a basic amd64 image, but I plan on adding nomultilib and hardened variants (for a total of at least 4 images). I plan on generating these images at least weekly. These images are not yet sanctioned by our infra team, but I plan on remedying that (being a member of said team should help). I am currently using the scripts at https://github.com/prometheanfire/gentoo-cloud-prep to generate the images (based on a heavily modified version of Matt Vandermeulen's scripts). If you have any issues please submit bugs there or contact me on irc (prometheanfire on freenode). Here's the link to the images, I'm currently gpg signing them with the same key I use to sign this email (offline master key smartcard setup for security minded folk). http://23.253.251.73/ Let me know if you have questions, OK, So to test the images, just burn a dvd/usbstick and run it like a liveDVD? I did not see instructions or brief guidance; I'm noob with openstack but curious to see how she performs.. Long term, will we get an openstack-meta (testing) out of this in portage, or should I just dedicated an old dual core amd64 box for image testing? I'm building up (from 100% sources) a mesos cluster offering with cephfs, Apache-spark, Apache-storm and tachyon. It'd be great to run some tests of codes on openstack (running on local hardware) and then test the same hardware running Apache-mesos. So any suggestions you have on that (so the comparisons are as similar as possible, including recommended test codes) would be of keen interest to me. James This is an image to deploy on top of Openstack. While you can deploy Openstack on the image, it isn't made for that purpose. Something like this is needed to import it into glance. glance image-create --name gentoo-20150608 --disk-format qcow2 --container-format bare --is-public True --min-disk 5 --min-ram 512 --file gentoo-amd64-multilib_2015-06-08.qcow2 --progress -- Matthew Thode (prometheanfire)
Re: [gentoo-dev] Openstack image availability
On 06/08/2015 01:10 PM, Daniel wrote: I thought I would point out a few things 1) Did you happen to see this guys step by step instructions for creating a cloud image: http://terrarum.net/blog/creating-a-gentoo-cloud-image.html I basically followed these instructions a year or so ago, and with a few tweaks was able to get Gentoo running on OpenStack. 2) I have extensive knowledge of OpenStack, it's been my profession for the past 2 years, so if you need any assistance, let me know. There are automated platforms such as Fuel by Mirantis that can help people deploy OpenStack on a virtual environment in case anyone wanted to try it out. Also DevStack is another common platform people use to test with. Just throwing my 2 cents into the conversation - Daniel On Mon, Jun 8, 2015 at 12:56 PM, Matthew Thode prometheanf...@gentoo.org mailto:prometheanf...@gentoo.org wrote: On 06/08/2015 01:38 PM, wirel...@tampabay.rr.com mailto:wirel...@tampabay.rr.com wrote: On 06/08/2015 10:30 AM, Matthew Thode wrote: Hi, I've just started generation of Gentoo Openstack images. Right now it is just a basic amd64 image, but I plan on adding nomultilib and hardened variants (for a total of at least 4 images). I plan on generating these images at least weekly. These images are not yet sanctioned by our infra team, but I plan on remedying that (being a member of said team should help). I am currently using the scripts at https://github.com/prometheanfire/gentoo-cloud-prep to generate the images (based on a heavily modified version of Matt Vandermeulen's scripts). If you have any issues please submit bugs there or contact me on irc (prometheanfire on freenode). Here's the link to the images, I'm currently gpg signing them with the same key I use to sign this email (offline master key smartcard setup for security minded folk). http://23.253.251.73/ Let me know if you have questions, OK, So to test the images, just burn a dvd/usbstick and run it like a liveDVD? I did not see instructions or brief guidance; I'm noob with openstack but curious to see how she performs.. Long term, will we get an openstack-meta (testing) out of this in portage, or should I just dedicated an old dual core amd64 box for image testing? I'm building up (from 100% sources) a mesos cluster offering with cephfs, Apache-spark, Apache-storm and tachyon. It'd be great to run some tests of codes on openstack (running on local hardware) and then test the same hardware running Apache-mesos. So any suggestions you have on that (so the comparisons are as similar as possible, including recommended test codes) would be of keen interest to me. James This is an image to deploy on top of Openstack. While you can deploy Openstack on the image, it isn't made for that purpose. Something like this is needed to import it into glance. glance image-create --name gentoo-20150608 --disk-format qcow2 --container-format bare --is-public True --min-disk 5 --min-ram 512 --file gentoo-amd64-multilib_2015-06-08.qcow2 --progress -- Matthew Thode (prometheanfire) Thanks, I did have that link as one of the items in a list of reference material. The reason I went the way I did is so I could integrate into our (Gentoo infra's) image building process. Also, thanks for the offer to help, we are in the #gentoo-openstack channel on freenode. I've been working the last few years on openstack (including the ebuild maintence for it in gentoo) at Rackspace :P. I generally recommend people use the openstack-meta-2015.0. package right now, as it deploys from stable/kilo. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Openstack image availability
On 06/08/2015 10:30 AM, Matthew Thode wrote: Hi, I've just started generation of Gentoo Openstack images. Right now it is just a basic amd64 image, but I plan on adding nomultilib and hardened variants (for a total of at least 4 images). I plan on generating these images at least weekly. These images are not yet sanctioned by our infra team, but I plan on remedying that (being a member of said team should help). I am currently using the scripts at https://github.com/prometheanfire/gentoo-cloud-prep to generate the images (based on a heavily modified version of Matt Vandermeulen's scripts). If you have any issues please submit bugs there or contact me on irc (prometheanfire on freenode). Here's the link to the images, I'm currently gpg signing them with the same key I use to sign this email (offline master key smartcard setup for security minded folk). http://23.253.251.73/ Let me know if you have questions, OK, So to test the images, just burn a dvd/usbstick and run it like a liveDVD? I did not see instructions or brief guidance; I'm noob with openstack but curious to see how she performs.. Long term, will we get an openstack-meta (testing) out of this in portage, or should I just dedicated an old dual core amd64 box for image testing? I'm building up (from 100% sources) a mesos cluster offering with cephfs, Apache-spark, Apache-storm and tachyon. It'd be great to run some tests of codes on openstack (running on local hardware) and then test the same hardware running Apache-mesos. So any suggestions you have on that (so the comparisons are as similar as possible, including recommended test codes) would be of keen interest to me. James
Re: [gentoo-dev] RFC: Indention in metadata.xml
On Sat, Jun 06, 2015 at 09:26:08AM +0200, Justin Lecher (jlec) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi everyone, Can we get an agreement on how we are indenting metadata.xml? I like to properly format and indent metadata.xml, but without having an agreement or policy on the indention, I make unhappy by choosing the wrong. The two options which are already suggested are * 2 spaces * single tab So what should it be? I want to throw in my support for the second option. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] Openstack image availability
On 06/08/2015 01:38 PM, wirel...@tampabay.rr.com wrote: On 06/08/2015 10:30 AM, Matthew Thode wrote: Hi, I've just started generation of Gentoo Openstack images. Right now it is just a basic amd64 image, but I plan on adding nomultilib and hardened variants (for a total of at least 4 images). I plan on generating these images at least weekly. These images are not yet sanctioned by our infra team, but I plan on remedying that (being a member of said team should help). I am currently using the scripts at https://github.com/prometheanfire/gentoo-cloud-prep to generate the images (based on a heavily modified version of Matt Vandermeulen's scripts). If you have any issues please submit bugs there or contact me on irc (prometheanfire on freenode). Here's the link to the images, I'm currently gpg signing them with the same key I use to sign this email (offline master key smartcard setup for security minded folk). http://23.253.251.73/ Let me know if you have questions, OK, So to test the images, just burn a dvd/usbstick and run it like a liveDVD? I did not see instructions or brief guidance; I'm noob with openstack but curious to see how she performs.. Long term, will we get an openstack-meta (testing) out of this in portage, or should I just dedicated an old dual core amd64 box for image testing? I'm building up (from 100% sources) a mesos cluster offering with cephfs, Apache-spark, Apache-storm and tachyon. It'd be great to run some tests of codes on openstack (running on local hardware) and then test the same hardware running Apache-mesos. So any suggestions you have on that (so the comparisons are as similar as possible, including recommended test codes) would be of keen interest to me. James This is an image to deploy on top of Openstack. While you can deploy Openstack on the image, it isn't made for that purpose. Something like this is needed to import it into glance. glance image-create --name gentoo-20150608 --disk-format qcow2 --container-format bare --is-public True --min-disk 5 --min-ram 512 --file gentoo-amd64-multilib_2015-06-08.qcow2 --progress -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds
All,
here is the latest version of this eclass, which I will commit an hour
from now if no one has any objections.
Thanks,
William
# Copyright 2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: golang-vcs.eclass
# @MAINTAINER:
# William Hubbs willi...@gentoo.org
# @BLURB: Eclass for fetching and unpacking go repositories.
# @DESCRIPTION:
# This eclass is written to ease the maintenance of live ebuilds
# of software written in the Go programming language.
inherit eutils
case ${EAPI:-0} in
5)
;;
*)
die ${ECLASS}: Unsupported eapi (EAPI=${EAPI})
;;
esac
EXPORT_FUNCTIONS src_unpack
if [[ -z ${_GOLANG_VCS} ]]; then
_GOLANG_VCS=1
# We depend on dev-vcs/git since it is the most used vcs for Go
# packages. However we will not depend on all vcs's Go supports at the
# eclass level. If your package, or one of its dependencies, uses
# another vcs, please depend on it directly.
DEPEND==dev-lang/go-1.4.2
dev-vcs/git
# @ECLASS-VARIABLE: EGO_PN
# @REQUIRED
# @DESCRIPTION:
# This is the import path for the go package. Please emerge dev-lang/go
# and read go help importpath for syntax.
#
# Example:
# @CODE
# EGO_PN=github.com/user/project
# @CODE
# @ECLASS-VARIABLE: EGO_STORE_DIR
# @DESCRIPTION:
# Storage directory for Go sources.
#
# This is intended to be set by the user in make.conf. Ebuilds must not set
# it.
#
# EGO_STORE_DIR=${DISTDIR}/go-src
# @ECLASS-VARIABLE: EVCS_OFFLINE
# @DEFAULT_UNSET
# @DESCRIPTION:
# If non-empty, this variable prevents any online operations.
# @ECLASS-VARIABLE: EVCS_UMASK
# @DEFAULT_UNSET
# @DESCRIPTION:
# Set this variable to a custom umask. This is intended to be set by
# users. By setting this to something like 002, it can make life easier
# for people who do development as non-root (but are in the portage
# group) and use FEATURES=userpriv.
# @FUNCTION: _golang-vcs_env_setup
# @INTERNAL
# @DESCRIPTION:
# Create EGO_STORE_DIR if necessary and set GOPATH.
_golang-vcs_env_setup() {
debug-print-function ${FUNCNAME} $@
local distdir=${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}}
: ${EGO_STORE_DIR:=${distdir}/go-src}
[[ -n ${EVCS_UMASK} ]] umask_push $EVCS_UMASK
if [[ ! -d ${EGO_STORE_DIR} ]]; then
(
addwrite /
mkdir -p ${EGO_STORE_DIR}
) || die ${ECLASS}: unable to create ${EGO_STORE_DIR}
fi
addwrite ${EGO_STORE_DIR}
export GOPATH=${EGO_STORE_DIR}
[[ -n ${EVCS_UMASK} ]] umask_pop
mkdir -p ${S} ||
die ${ECLASS}: unable to create ${S}
}
# @FUNCTION: _golang-vcs_fetch
# @INTERNAL
# @DESCRIPTION:
# Retrieve the EGO_PN go package along with its dependencies.
_golang-vcs_fetch() {
debug-print-function ${FUNCNAME} $@
[[ -z ${EGO_PN} ]]
die ${ECLASS}: EGO_PN is not set
if [[ -n ${EVCS_OFFLINE} ]]; then
export GOPATH=${S}:${EGO_STORE_DIR}
return
fi
[[ -n ${EVCS_UMASK} ]] umask_push ${EVCS_UMASK}
set -- go get -d -t -u -v -x ${EGO_PN}
echo $@
$@
# I can't call die here, depending on the outcome of the following
# upstream issue.
# https://github.com/golang/go/issues/11090
# Hopefully this will be fixed so that go get -d is successful if
# everything is downloaded. In that case, I can call die.
# That would also remove the test below this line.
[[ ! -d ${EGO_STORE_DIR}/src/${EGO_PN} ]]
die ${ECLASS}: unable to retrieve ${EGO_PN} or a dependency
[[ -n ${EVCS_UMASK} ]] umask_pop
export GOPATH=${S}:${EGO_STORE_DIR}
}
golang-vcs_src_fetch() {
debug-print-function ${FUNCNAME} $@
_golang-vcs_env_setup
_golang-vcs_fetch
}
golang-vcs_src_unpack() {
debug-print-function ${FUNCNAME} $@
golang-vcs_src_fetch
}
fi
signature.asc
Description: Digital signature
Re: [gentoo-dev] RFC: Indention in metadata.xml
Dnia 2015-06-08, o godz. 08:36:02
Justin (jlec) j...@gentoo.org napisał(a):
On 07/06/15 22:22, Michał Górny wrote:
Dnia 2015-06-07, o godz. 22:16:18
Justin Lecher (jlec) j...@gentoo.org napisał(a):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/06/15 14:48, Andrew Udvare wrote:
On 07/06/15 05:12, Alexis Ballier wrote:
On Sat, 6 Jun 2015 22:00:14 -0400 Mike Gilbert
flop...@gentoo.org wrote:
Compatibility with sed scripts is not something I care about.
...
However, I do not disagree an XML parser is better than sed for
the purpose. There are plenty of XML pretty printers.
So you guys think I am using sed for this? Really?
Still you need to tell a XML formatter what indention style to use.
Not exactly. You can write a tool that tries hard to recognize
indentation style and repeat it. Like the one I wrote to replace
herd/ with maintainer/ elements. It was pretty good in figuring out
developer fancies, including multiple different indentation levels.
I am trying to detect what ever they already is for indention. How did you
implement this?
Script attached. Pretty much it looks it tries to figure out what
indent is used for first- and second-level elements, and reproduces
that.
--
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'] = '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()
pgpAIt2DTGsDT.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
Duncan wrote: The point you made here was console-based workflow, as quoted above, and that's what I addressed, arguing that even if was valid at some point, it's no longer the factor it once was. For you, that is. Be aware that this creates your bias. You can't extrapolate from your own situation to a broad statement like the above with any kind of certanity. //Peter
Re: [gentoo-dev] RFC: Indention in metadata.xml
On Sat, Jun 6, 2015 at 12:26 AM, Justin Lecher (jlec) j...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi everyone, Can we get an agreement on how we are indenting metadata.xml? I like to properly format and indent metadata.xml, but without having an agreement or policy on the indention, I make unhappy by choosing the wrong. I was going to stay out of this, but I want to kind of circle back a bit. You want to 'properly format' the documents. I guess part of my question is, what would you do if the proper format was basically undefined? Properly formatted XML files isn't really what I consider a goal. Do you have other goals? For instance: I would like to standardize on spaces or tabs so that we can better automate the tooling around metadata. Or perhaps more clearly: I am writing tools that manipulate metadata.xml; while I can easily ingest metadata.xml, producing the correct output is difficult when spaces or tabs are mixed, can we consistently use one or the other? Or another take: I am trying to write a tool that manipulates metadata.xml and I am having difficulty parsing entries that mix spaces and tabs, please help me. Some of these problems are solved by code (I'm pretty sure the latter problem just requires a sane XML parser for instance.) I believe mgorny already provided code that tried to solve problem 2. Problem 1 is sufficiently generic that it is hard to solve with a code snippet I think. The point is these are all goals other than I want to standardize on tabs or spaces because I like starting tabs vs spaces flamewars on gentoo-dev. This is not meant to be accusatory; merely that standardizing the format because doesn't really solve anything (there is no problem statement.) Perhaps there is an implied statement (consistency is generally better for all parties.) But even that being clearly stated would be nice. -A The two options which are already suggested are * 2 spaces * single tab So what should it be? Jusitn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVcqCPXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmivxIP/3Vdv8fLVThtEdjknncX8txq DSEj1m+pEqVw53noSQscbvjRkiAiGg50xtZFC5zcJVC7cRSIAADGUByakt7w+Lmk D2cHWfQLJr5ZqGMholHdHJC7G7PXDJZ4D90Rt8qL7I1aGjMzWtGXzkzx2+OD+j8F jy8XAa2I30/Rgof+fsUp1mgglv5c4Y94CbJcnkbERuyxA5miB2d1E3i3iiIcoLmB M2fs0DN3oOQT8Fhwp2fJhoRH+aXlayC8o5PbBEKc6xGU5nfvtfvqqGHa9eoqLgXv vpZXIwKm9vujXoPi7DDBMKAPPqDD1OSKBV0fvbwx0Q94H7XzmSmtFW45gPdAyrF2 rwL3dlLcswDsblv46LHmj+m3/VFJagSccrKaH/I4uf4z2+RhjwNO2R+Z66/EYH3n hvoYWQTx0Y+YI2kKKpXymK5e9ZgO7x+dxBHwLpa13JcJP0sMESQbN4jmJ5Rob0xV bqtTsn+/O/rB1iMMC2V1fq3cQT9AQZT3OKnyiXM6nwLDgae30cY4gCUkOqc/ULxp Eakb5D82HlSWIo840BXNAoGOWI7vFrtaKndDukWn+kKk1SeKm3j2ocwzQ7Rzxsa8 60hfE2tsuo0wQBLxslxYyZnv/kPBS9PS8RtZrLpS5V6D4BGS/32zuBVhN1eP9dQ0 dz0kj1uvehcz5/Dhgms4 =e7QN -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Indention in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/08/2015 12:47 PM, William Hubbs wrote: On Sat, Jun 06, 2015 at 09:26:08AM +0200, Justin Lecher (jlec) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi everyone, Can we get an agreement on how we are indenting metadata.xml? I like to properly format and indent metadata.xml, but without having an agreement or policy on the indention, I make unhappy by choosing the wrong. The two options which are already suggested are * 2 spaces * single tab So what should it be? I want to throw in my support for the second option. Thanks, William I'm also in favor of tabs. Aside from being shorter (by a single byte, in this case), they're less prone to off-by-one inconsistencies and any good text editor allows the user to configure the tab width, so everyone can be happy. Just my two cents. ~Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVdiq3AAoJEAEkDpRQOeFwFnMQANYOy+A9D8wU8RQjXtUm5fEO FcK+vXyigt+ENholJVl4NYkL6z7l8dTx5PbjZ4qYUgM0hqwraUI8h69gmXe2r4c+ 3r3FSaLofQ8ePlmaBQOJMw6OTJu9P2VULVh90bByj+2NKzu07aVHkRevzerzvl5F uhiRSQvPNNYCxSrYL+Q5SLKtdfpny+gg9npoNkeoQPSzu/GujicxBisTHb8jaBEs gcP1iSTsvrf8nhYzgxwmKpyDbeBH2V8rUMFOv800m6lbbfXChDHUrOEX81Jxs72/ wfjbEpSFz0Dkhd/WFu4ApMvgaQesT7NudRg5q+YV35aDyx6gXkvdKPyWzNv5FmVd dDmODWnV7oLm8BymhQaqNZOauh/7LlEjKIRTATGow+IWoqwTVgyVw0lp4DmA3n0L Mz8+WgaNfEERYct+Pbrc3MkQsQ7DsyAp8GWQ8b+j2SsNXjsVD2bjB58mKv4udda/ Nj8f8mdu43+O9zRXl385r7U5Nbb3foI9fyvJsN1GyPE+8LDHvs5LDvFDY41Yz3Nk IWaEbEiWGAo5zLOfgld2NOtq8VB7kIMLwF2xhsMfHzO0oQKisPBOH7Ab2x29DvL/ TreinTiDyLtKzlJ6+bprIqH6dTXflaNzHsVzoXQiu9XDdb3hIpXTXup5hlDUZxT6 TZ4zilhFAeYHUjzOOyli =lB7e -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
On Sun, 7 Jun 2015 04:40:47 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Well, yes, but vgacon is rather dated, now. Never heard of a serial console? It's dated sure enough, but I for one use them on a daily basis, and not by choice. jer
[gentoo-dev] Re: RFC: using Ninja in more CMake-based packages
Christoph Junghans posted on Sun, 07 Jun 2015 20:08:25 -0600 as excerpted: 2015-06-07 14:19 GMT-06:00 Justin Lecher (jlec) j...@gentoo.org: On 07/06/15 22:14, Johannes Huber wrote: Am Sonntag 07 Juni 2015, 17:08:57 schrieb Michał Górny: CMake sucks a lot [but will suck less if we switch] CMake to use Ninja instead of make. As you may know, Ninja is the fancy building tool that is faster and much harder to use than make. However, it integrates with CMake much better and with less hackery. GNU make is part of @system, ninja would be considered an extra package being installed. Do we consider it fine to require it randomly? KDE herd maintains ~1000 packages and the majority relies on CMake. I am not aware of any reports about GNU make related build files. So i would vote for the reliable GNU make generator. I tested ninja some while ago on some big cmake science projects and I found it to be faster. So I would vote for Micheals suggestion. Though I also never faced any problems with the makefiles either. It's purely that I found ninja to work smooth and fast. Right after this feature was implemented (bug #430608), ago did some testing on kde-base/kdelibs, but only found a 40 sec save on a 6min overall build. That's still 10-11% (depending on what side of 6 minutes the 40 seconds goes), a pretty sizable difference considering it's just the maker we're fiddling with, not the compiler. [TL;DR summary: yes to marking packages and automating ninja where safe for users that want to, but please keep gnu make the default.] And on those ~1000 kde packages, for live users with ccache cutting compile time and thus speeding overall builds, the figure is likely to be MUCH higher than 10%. WAG of 50%? Anyone? That said, I'm conservative enough to lean toward gnu make as well, certainly by default. But were there a standardized ebuild flag to mark it ninja compatible, and a documented way to change that default, I'd also almost certainly try ninja, particularly when I /am/ doing live-kde as I was for a couple years with kde4, and probably will be again with kde5 once I can actually get kwin5 working long enough on my hardware[1] and eventually find kde5 stable enough of a base to run live again. So marking ebuilds that can use ninja successfully and automating it so people that want to can, great, and by all means, document it well so they know they can, but please, gnu make default for now. --- [1] kwin5 working: I've tried several times over the last year, always getting the same kwin5 crash/respawn loop and thus being unable to get any further into kde5 testing. FWIW single-card radeon turks graphics, triple monitor, native kernel/mesa/xorg driver, works fine with kwin4 in OpenGL mode. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] RFC: Indention in metadata.xml
On 07/06/15 22:22, Michał Górny wrote: Dnia 2015-06-07, o godz. 22:16:18 Justin Lecher (jlec) j...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/06/15 14:48, Andrew Udvare wrote: On 07/06/15 05:12, Alexis Ballier wrote: On Sat, 6 Jun 2015 22:00:14 -0400 Mike Gilbert flop...@gentoo.org wrote: Compatibility with sed scripts is not something I care about. ... However, I do not disagree an XML parser is better than sed for the purpose. There are plenty of XML pretty printers. So you guys think I am using sed for this? Really? Still you need to tell a XML formatter what indention style to use. Not exactly. You can write a tool that tries hard to recognize indentation style and repeat it. Like the one I wrote to replace herd/ with maintainer/ elements. It was pretty good in figuring out developer fancies, including multiple different indentation levels. I am trying to detect what ever they already is for indention. How did you implement this? Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages
On 06/07/2015 05:08 PM, Michał Górny wrote: Hello, developers. [...] It's not clear to me how the transition should look like. Are you suggesting Ninja to be the new default or do you want to switch per-packages after having tested them? If the former, then we need a tinderbox-run.
Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages
On 06/08/2015 02:01 PM, Michał Górny wrote: Dnia 2015-06-08, o godz. 12:46:42 hasufell hasuf...@gentoo.org napisał(a): On 06/07/2015 05:08 PM, Michał Górny wrote: Hello, developers. [...] It's not clear to me how the transition should look like. Are you suggesting Ninja to be the new default or do you want to switch per-packages after having tested them? If the former, then we need a tinderbox-run. The latter. We don't have the resources to do the former properly, and the number of packages relying on GNU make is too large. Some ebuilds will also need more extensive changes. I'm not sure if it makes sense to add additional complexity, but another approach could be done similar to the git shallow clone situation... as in: the ebuild wouldn't say which Makefile generator to use, but which ones work. The default would be: all work. That will expose ninja bugs to our bugtracker.
Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
On Sun, 7 Jun 2015 04:40:47 + (UTC) Duncan wrote: Andrew Savchenko posted on Sat, 06 Jun 2015 20:36:13 +0300 as excerpted: On Sat, 06 Jun 2015 18:35:41 +0600 Vadim A. Misbakh-Soloviov wrote: * linewidth 80 (why do we have this short limit still in 2015) Actually, I dislike that too, but the reason is simple: some people still using text-mode terminals. // It would be nice to finally fix that, but let's be realistic: it looks like it wouldn't be finished in the near 10 years :-/ It will never be finished, because console-based workflow is the most efficient way to work for many people, especially for advanced users/devs. Well, yes, but vgacon is rather dated, now. More folks are using high resolution framebuffer console mode all the time, and with monitors standardizing on 1920x1080 due to HDTV, well... my console mode is 320 columns x 108 lines, now, and 80 chars... is just scrunched up on the left quarter of the screen![1] Of course there's split-screen too, tho I think many are like me and simply startx and run terminal windows if they want split-screen, so haven't bothered configuring it at the frame-buffer console, but again, even that's 160 width, over 100 width if 3-way-vert-split, and still 80 width at 4-way-vert-split, which is getting a bit ridiculous. So console-based workflow isn't so much of an excuse for 80-char lines, these days. Of course lines can be /too/ long. There's a reason newspapers and the like use multi-column printing, after all. But 120 char isn't too bad, and I expect most would find at least 100 char an improvement over 80, which really begins to feel like the old 40-char widths at some point. You missed my point completely. 80 chars limit comes not from the console width, but from the text readability[1]. It doesn't matter how wide one's physical monitor is. Text of 300 characters width will be barely readable. Of course if a code have large left indents for inner blocks, such code may exceed 80-chars barrier, but without left whitespace it should be within limits. Of course there are various exceptions like comments and so on. But as a rule of thumb too wide lines are not readable because eyes shift during line read is way too large. 60-80 chars limit comes from the science, not from the console width. Actually I suspect that console width was selected that way due to readability issues. [1] http://baymard.com/blog/line-length-readability Best regards, Andrew Savchenko pgpnMd5FIx_zK.pgp Description: PGP signature
Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages
Dnia 2015-06-08, o godz. 12:46:42 hasufell hasuf...@gentoo.org napisał(a): On 06/07/2015 05:08 PM, Michał Górny wrote: Hello, developers. [...] It's not clear to me how the transition should look like. Are you suggesting Ninja to be the new default or do you want to switch per-packages after having tested them? If the former, then we need a tinderbox-run. The latter. We don't have the resources to do the former properly, and the number of packages relying on GNU make is too large. Some ebuilds will also need more extensive changes. -- Best regards, Michał Górny pgpNyb1nAR3EY.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: using Ninja in more CMake-based packages
Michał Górny wrote: Dnia 2015-06-08, o godz. 12:46:42 hasufell hasuf...@gentoo.org napisał(a): On 06/07/2015 05:08 PM, Michał Górny wrote: Hello, developers. [...] It's not clear to me how the transition should look like. Are you suggesting Ninja to be the new default or do you want to switch per-packages after having tested them? If the former, then we need a tinderbox-run. The latter. We don't have the resources to do the former properly, and the number of packages relying on GNU make is too large. Some ebuilds will also need more extensive changes. You have your userbase ;) In order to reach as many as possible you could create a news item. Or a mailing list post. Ask them on planet.gentoo.org ;) Tell them how good ninja performs :) Ask them to set the generator to ninja in their make.conf to test if their packages still compile. They create bugs for failing packages and you can easily hard code good old emake in the specific packages. As default there probably should always be emake. IMHO a working build system always is better than a fast but potentially broken one :) -- Best regards, Michał Górny
[gentoo-dev] Re: RFC: using Ninja in more CMake-based packages
Franz Fellner alpine.art...@gmail.com wrote: IMHO a working build system always is better than a fast but potentially broken one :) Meanwhile, it is not so clear which of the two systems is more likely the potentially broken one: According to some of the mentioned bugs, it appears to me that some upstreams consider rather ninja as the working (and well-tested) tool, and Makefile as poor man's fallback.
[gentoo-dev] Openstack image availability
Hi, I've just started generation of Gentoo Openstack images. Right now it is just a basic amd64 image, but I plan on adding nomultilib and hardened variants (for a total of at least 4 images). I plan on generating these images at least weekly. These images are not yet sanctioned by our infra team, but I plan on remedying that (being a member of said team should help). I am currently using the scripts at https://github.com/prometheanfire/gentoo-cloud-prep to generate the images (based on a heavily modified version of Matt Vandermeulen's scripts). If you have any issues please submit bugs there or contact me on irc (prometheanfire on freenode). Here's the link to the images, I'm currently gpg signing them with the same key I use to sign this email (offline master key smartcard setup for security minded folk). http://23.253.251.73/ Let me know if you have questions, -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
Andrew Savchenko posted on Mon, 08 Jun 2015 16:33:55 +0300 as excerpted: On Sun, 7 Jun 2015 04:40:47 + (UTC) Duncan wrote: Andrew Savchenko posted on Sat, 06 Jun 2015 20:36:13 +0300 as excerpted: It will never be finished, because console-based workflow is the most efficient way to work for many people, especially for advanced users/devs. Well, yes, but vgacon is rather dated, now. More folks are using high resolution framebuffer console mode So console-based workflow isn't so much of an excuse for 80-char lines, these days. Of course lines can be /too/ long. There's a reason newspapers and the like use multi-column printing, after all. You missed my point completely. 80 chars limit comes not from the console width, but from the text readability[1]. [The subthread already says OT, allowing those who wish to killfile it, so...] 1) While that point was made (by you or someone else) elsewhere, it wasn't made in this subthread. The point you made here was console-based workflow, as quoted above, and that's what I addressed, arguing that even if was valid at some point, it's no longer the factor it once was. 2) Actually, I didn't miss the text readability point completely, either. Thus the Of course lines can be /too/ long bit, specifically mentioning multi-column newspaper printing, etc. You quoted it, but apparently didn't read it? So differences, if any, appear to be only in degree, tho I'm already on record as saying it's bikeshedding either way. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
