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 agai
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
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
confl
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 keyword
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 differ
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
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.
>
> Th
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.
>
> Th
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 simp
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 Pett
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 th
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 El
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
> y
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 eau
On Wed, 09 Jan 2013 13:23:13 +0100
Diego Elio Pettenò 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 only project in the wor
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."
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 fail
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ò
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 migration is never
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...
>
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):
>
> http://git-exp.overlays.gentoo.org/gitweb/?p
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.
-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 t
On 9 January 2013 18:17, Vicente Olivert Riera 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 TESTED_${ARCH} k
On Fri, 4 Jan 2013 23:33:02 -0600
Donnie Berkholz 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 IRC thi
On Wed, 9 Jan 2013 18:39:09 +0200
Markos Chandras wrote:
> On 9 January 2013 18:17, Vicente Olivert Riera
> > 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.
> >
>
On Wed, 09 Jan 2013 05:06:15 -0800
Zac Medico 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 lines.
On Wed, Jan 9, 2013 at 12:02 PM, Jeroen Roovers 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 - mostly legacy (
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 m
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 identica
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?
--
Than
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.gen
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
> >
> > Wh
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 vers
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 f
On Wed, 9 Jan 2013 16:13:10 -0600
William Hubbs 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 option
is available and
On Wed, Jan 09, 2013 at 02:59:10PM -0800, Christopher Head wrote:
> On Wed, 9 Jan 2013 16:13:10 -0600
> William Hubbs 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
On Wed, 9 Jan 2013 18:13:21 -0600
William Hubbs 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 mentions how
it lets yo
-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
> li
On Wed, Jan 9, 2013 at 11:21 PM, Daniel Campbell 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 mind that this
On 01/09/2013 10:33 PM, Rich Freeman wrote:
> On Wed, Jan 9, 2013 at 11:21 PM, Daniel Campbell 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
44 matches
Mail list logo
