On 01/08/2013 11:49 PM, Duncan wrote:
Zac Medico posted on Tue, 08 Jan 2013 23:36:59 -0800 as excerpted:
Thought: Do the CVS keyword expansion in repoman, and then feed the
expanded file to CVS for commit. This gives you a fixed file, which
you can then generate your manifest against.
On 03/01/13 00:41, Pacho Ramos wrote:
What is the purpose of this stuff:
if [[ ${___ECLASS_ONCE_EUTILS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_EUTILS=recur -_+^+_- spank
I don't know exactly sure if this is the source of some recent problems,
but I assume it is.
While fixing some
On 01/09/2013 12:40 AM, justin wrote:
My question, did anybody else might have observed similar things? Is
there a flaw in this *ECLASS_ONCE_* stuff?
There could well be, but even in the absence of the *ECLASS_ONCE_*
stuff, the problem that you're describing could be attributed to eclass
On 09-01-2013 00:31:04 -0800, Zac Medico wrote:
Of course that assumes that the keywords are suitably distinct such that
they won't ordinarily be found in the pre-expanded lines. Whether that's
actually the case or not I've no idea...
Well, I'd suggest to simply drop the keywords.
On 09/01/2013 10:09, Fabian Groffen wrote:
Yeah, but I'd really appreciate it if they could stay for as long as
we're on CVS, so my scripts that use the version number to retrieve
diffs and apply them to the Prefix' tree versions keep on working.
Since we're discussing adding this on Portage
On 09/01/13 10:03, Zac Medico wrote:
On 01/09/2013 12:40 AM, justin wrote:
My question, did anybody else might have observed similar things? Is
there a flaw in this *ECLASS_ONCE_* stuff?
There could well be, but even in the absence of the *ECLASS_ONCE_*
stuff, the problem that you're
On 09/01/2013 09:40, justin wrote:
Also the internals of the build are affected (probably through the
difference in configure). This leads to disrespected LDFLAGS and broken
tclConfig.sh. So this simple change has deep consequences.
This looks like the _version_ of autoconf used is
On 09-01-2013 10:14:21 +0100, Diego Elio Pettenò wrote:
On 09/01/2013 10:09, Fabian Groffen wrote:
Yeah, but I'd really appreciate it if they could stay for as long as
we're on CVS, so my scripts that use the version number to retrieve
diffs and apply them to the Prefix' tree versions keep
On 09/01/13 10:26, Diego Elio Pettenò wrote:
On 09/01/2013 09:40, justin wrote:
Also the internals of the build are affected (probably through the
difference in configure). This leads to disrespected LDFLAGS and broken
tclConfig.sh. So this simple change has deep consequences.
This looks
On 09/01/13 10:26, Diego Elio Pettenò wrote:
On 09/01/2013 09:40, justin wrote:
Also the internals of the build are affected (probably through the
difference in configure). This leads to disrespected LDFLAGS and broken
tclConfig.sh. So this simple change has deep consequences.
This looks
On 09/01/13 12:29, justin wrote:
On 09/01/13 10:26, Diego Elio Pettenò wrote:
On 09/01/2013 09:40, justin wrote:
Also the internals of the build are affected (probably through the
difference in configure). This leads to disrespected LDFLAGS and broken
tclConfig.sh. So this simple change has
On 09/01/2013 12:39, justin wrote:
I assume it is a portage problem, because the log says autoconf is run
but configure.in didn't change.
What do you mean configure.in didn't change but autoconf is run?
Does it cause a maintainer-mode rebuild?
Did you use eautoreconf?
--
Diego Elio
Zac Medico posted on Tue, 08 Jan 2013 23:42:39 -0800 as excerpted:
Weren't we planning to drop the CVS keywords for the git migration,
anyway?
Talking about which... I don't want a big subthread out of this, just
looking for a simple answer:
Are the git migration blockers at such a point
On 09/01/2013 13:20, Duncan wrote:
Are the git migration blockers at such a point that we can get an ETA
yet?
PLEASE ALL STOP DETOURING EVERY DAMN TOPIC OUT THERE WITH THE GIT
MIGRATION, THANK YOU VERY MUCH.
And yes I know it's not polite to scream. At this point I DON'T CARE.
--
Diego
On Wed, Jan 9, 2013 at 7:20 AM, Duncan 1i5t5.dun...@cox.net wrote:
Zac Medico posted on Tue, 08 Jan 2013 23:42:39 -0800 as excerpted:
Weren't we planning to drop the CVS keywords for the git migration,
anyway?
Are the git migration blockers at such a point that we can get an ETA
yet?
On 09/01/13 12:44, Diego Elio Pettenò wrote:
On 09/01/2013 12:39, justin wrote:
I assume it is a portage problem, because the log says autoconf is run
but configure.in didn't change.
What do you mean configure.in didn't change but autoconf is run?
the build.log says
Running eautoreconf
On Wed, 09 Jan 2013 13:23:13 +0100
Diego Elio Pettenò flamee...@flameeyes.eu wrote:
PLEASE ALL STOP DETOURING EVERY DAMN TOPIC OUT THERE WITH THE GIT
MIGRATION, THANK YOU VERY MUCH.
Translation: We all know that there are lots of things that would be a
hell of a lot easier if we weren't the
On 09/01/2013 13:35, justin wrote:
Running autoheader ...[!!]
That is unfortunately common...
A diff between the original and the two run build's configure.in shows
only a difference by one of the two (in both cases the autoheader failed).
I lost you here... can you attach the build logs?
On 09/01/2013 13:37, Ciaran McCreesh wrote:
Translation: We all know that there are lots of things that would be a
hell of a lot easier if we weren't the only project in the world still
using CVS, but the Git migration is never going to happen, so
mentioning it just makes everyone angry.
No,
On 09/01/13 13:40, Diego Elio Pettenò wrote:
On 09/01/2013 13:35, justin wrote:
Running autoheader ...[!!]
That is unfortunately common...
A diff between the original and the two run build's configure.in shows
only a difference by one of the two (in both cases the autoheader failed).
I
On 09/01/2013 13:54, justin wrote:
I found the problem. The patch works on configure and configure.in. If
both files are patched sometimes autoconf doesn't run.
I fixed the patch to only touch .in and everything is fine.
autoconf or eautoconf problem?
QA violation by patching both files
On Wed, Jan 9, 2013 at 7:42 AM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
On 09/01/2013 13:37, Ciaran McCreesh wrote:
Translation: We all know that there are lots of things that would be a
hell of a lot easier if we weren't the only project in the world still
using CVS, but the Git
On 01/09/2013 01:09 AM, Fabian Groffen wrote:
On 09-01-2013 00:31:04 -0800, Zac Medico wrote:
Of course that assumes that the keywords are suitably distinct such that
they won't ordinarily be found in the pre-expanded lines. Whether that's
actually the case or not I've no idea...
Well,
On 09-01-2013 05:06:15 -0800, Zac Medico wrote:
If we had a live cvs - git sync, then I'd suggest that you migrate your
scripts to use that instead. However, it looks like this one is not
synced regularly (last sync was about 2 months ago):
Diego Elio Pettenò posted on Wed, 09 Jan 2013 13:23:13 +0100 as excerpted:
On 09/01/2013 13:20, Duncan wrote:
Are the git migration blockers at such a point that we can get an ETA
yet?
PLEASE ALL STOP DETOURING EVERY DAMN TOPIC OUT THERE WITH THE GIT
MIGRATION, THANK YOU VERY MUCH.
And
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello everyone :-)
some devs and I were talking about the fact that TESTED bugzilla
keyword may need a change on his description, or, maybe it's needed to
create new TESTED_${ARCH} keywords.
Personally, I was using TESTED keyword when an ebuild was
On 9 January 2013 18:17, Vicente Olivert Riera per...@carrosses.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello everyone :-)
some devs and I were talking about the fact that TESTED bugzilla
keyword may need a change on his description, or, maybe it's needed to
create new
On Fri, 4 Jan 2013 23:33:02 -0600
Donnie Berkholz dberkh...@gentoo.org wrote:
On 05:31 Fri 21 Dec , Matt Turner wrote:
My point is that you consistently write long essays that I, and
apparently most others, don't bother to read. I'm not sure if
you're aware of this.
Someone said
On Wed, 9 Jan 2013 18:39:09 +0200
Markos Chandras hwoar...@gentoo.org wrote:
On 9 January 2013 18:17, Vicente Olivert Riera per...@carrosses.com
some devs and I were talking about the fact that TESTED bugzilla
keyword may need a change on his description, or, maybe it's needed
to create
On Wed, 09 Jan 2013 05:06:15 -0800
Zac Medico zmed...@gentoo.org wrote:
On 01/09/2013 01:09 AM, Fabian Groffen wrote:
On 09-01-2013 00:31:04 -0800, Zac Medico wrote:
Of course that assumes that the keywords are suitably distinct such that
they won't ordinarily be found in the pre-expanded
On Wed, Jan 9, 2013 at 12:02 PM, Jeroen Roovers j...@gentoo.org wrote:
A lot clearer than a single text field littered with keywords would be some
tick boxes, indeed. In fact, it makes me wonder why we use a half-obscured
list
in a select field for adding/removing arch teams now.
Agree -
El lun, 07-01-2013 a las 10:34 +0100, Pacho Ramos escribió:
[...]
This will install a README.gentoo file
But there are still pending issues I don't know how to handle:
- Eclass was originally oriented to cover those kind of messages that
could be shown by elog first time the package is
On 01/09/2013 12:31 AM, Zac Medico wrote:
I guess we could use the cvs -ko option [1] on all files. That's
apparently what prevents $Header expansion for $PORTDIR/skel.ebuild.
Actually, we should use -kb rather than -ko, since -kb disables
transformations entirely [1]. The -ko mode is identical
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
--
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have different
README.gentoo
El mié, 09-01-2013 a las 22:15 +0100, Pacho Ramos escribió:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo
What if there
All,
as you probably know by now, udev-197 has hit the tree.
This new version implements a new feature called predictable network
interface names [1], which I have currently turned off for live systems,
because it
will require migration on the part of the user.
When you upgrade to this new
Greg KH schrieb:
On Mon, Dec 10, 2012 at 12:21:29AM +0100, Chí-Thanh Christopher Nguyễn wrote:
Greg KH schrieb:
No, all we need is to enable EFI stub support in the kernel, and
integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in
some location where UEFI looks for it
On Wed, 9 Jan 2013 16:13:10 -0600
William Hubbs willi...@gentoo.org wrote:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
This seems like a good thing for some systems. Will there be a news
item when 197 (or greater) goes stable informing people that the
On Wed, Jan 09, 2013 at 02:59:10PM -0800, Christopher Head wrote:
On Wed, 9 Jan 2013 16:13:10 -0600
William Hubbs willi...@gentoo.org wrote:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
This seems like a good thing for some systems. Will there be a
On Wed, 9 Jan 2013 18:13:21 -0600
William Hubbs willi...@gentoo.org wrote:
There is a way for users to opt out if we default this to on, but I
think the new naming scheme has advantages over the traditional eth*
wlan* etc names.
I think it should be taken with a grain of salt. The page
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/09/2013 04:13 PM, William Hubbs wrote:
All,
as you probably know by now, udev-197 has hit the tree.
This new version implements a new feature called predictable
network interface names [1], which I have currently turned off for
live
On Wed, Jan 9, 2013 at 11:21 PM, Daniel Campbell dlcampb...@gmx.com wrote:
So long as users retain the choice of keeping eth* or wlan*, no
complaints from me. I (and others) came to Gentoo to get away from
systemd, and this smells of a systemd-ism. Will eudev be pursuing this
as well?
Keep in
On 01/09/2013 10:33 PM, Rich Freeman wrote:
On Wed, Jan 9, 2013 at 11:21 PM, Daniel Campbell dlcampb...@gmx.com wrote:
So long as users retain the choice of keeping eth* or wlan*, no
complaints from me. I (and others) came to Gentoo to get away from
systemd, and this smells of a systemd-ism.
44 matches
Mail list logo
