On Sat, 10 Mar 2012 20:27:06 -0600, William Hubbs wrote:
If all goes well, this will be committed to the tree on 3/14 UTC.
A major change like this needs more notice than this. The news item
should give some reasonable notice of the change to give people time to
get their initramfs setup
On Sun, 11 Mar 2012 08:06:35 +
Neil Bothwick n...@digimed.co.uk wrote:
On Sat, 10 Mar 2012 20:27:06 -0600, William Hubbs wrote:
If all goes well, this will be committed to the tree on 3/14 UTC.
A major change like this needs more notice than this. The news item
should give some
As times have changed and IRC is used more an more. I propose adding an
optional irc/irc data field to layman's repositories.xml file
format. This information would be listed along with the other
information when running:
# layman -i some-overlay
This added information would then be available
On Sun, 11 Mar 2012 09:41:02 +0100, Michał Górny wrote:
A major change like this needs more notice than this. The news item
should give some reasonable notice of the change to give people time
to get their initramfs setup working and tested before it is needed
in anger.
Maybe the
On Sun, 11 Mar 2012 09:36:24 +
Neil Bothwick n...@digimed.co.uk wrote:
On Sun, 11 Mar 2012 09:41:02 +0100, Michał Górny wrote:
A major change like this needs more notice than this. The news
item should give some reasonable notice of the change to give
people time to get their
On 11.03.2012 04:53, Rich Freeman wrote:
On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs willi...@gentoo.org wrote:
here is the udev 181 unmasking news item.
If all goes well, this will be committed to the tree on 3/14 UTC.
I guess this might be OK for unstable, but before this goes stable
After reading previous discussion:
http://help.lockergnome.com/linux/gentoo-dev-Deprecate-EAPIs--ftopict530567.html
Looks like preventing NEW commits from using eapi1 (via repoman) could
be done without major issues. This could even being done also for eapi2
as it's close enough to eapi3, but I
On 03/11/12 20:01, Pacho Ramos wrote:
After reading previous discussion:
http://help.lockergnome.com/linux/gentoo-dev-Deprecate-EAPIs--ftopict530567.html
Looks like preventing NEW commits from using eapi1 (via repoman) could
be done without major issues. This could even being done also for
On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer patr...@gentoo.org wrote:
I'd deprecate eapi2 too, we don't need 5 flavours around when we
effectively only want to support one (and eapi0 in a few places)
I wouldn't mind having a deprecation timeline for eapi3 too (now +6
months maybe?), but
On Sun, 11 Mar 2012 09:52:40 -0400
Rich Freeman ri...@gentoo.org wrote:
Is there really much of a benefit to this? I guess for anybody who
runs scripts to mass-manipulate ebuilds it might be helpful, but I
think all the package managers planned on supporting all the EAPIs for
quite a while
On 03/11/2012 03:52 PM, Rich Freeman wrote:
On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauerpatr...@gentoo.org wrote:
I'd deprecate eapi2 too, we don't need 5 flavours around when we
effectively only want to support one (and eapi0 in a few places)
I wouldn't mind having a deprecation timeline
On 03/11/12 21:52, Rich Freeman wrote:
On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer patr...@gentoo.org wrote:
I'd deprecate eapi2 too, we don't need 5 flavours around when we
effectively only want to support one (and eapi0 in a few places)
I wouldn't mind having a deprecation timeline for
Patrick Lauer schrieb:
On 03/11/12 21:52, Rich Freeman wrote:
On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer patr...@gentoo.org wrote:
I'd deprecate eapi2 too, we don't need 5 flavours around when we
effectively only want to support one (and eapi0 in a few places)
I wouldn't mind having a
Ciaran McCreesh schrieb:
Is there really much of a benefit to this? I guess for anybody who
runs scripts to mass-manipulate ebuilds it might be helpful, but I
think all the package managers planned on supporting all the EAPIs for
quite a while longer.
We have to support them indefinitely.
On 03/11/2012 04:03 AM, Petteri Räty wrote:
The Display-If-Installed atom shows the news item to stable users once
it's committed. I am not sure at what point does Portage show it when
the atom is = so we might want to evaluate the options.
It's displayed after the package is installed,
On Sun, 11 Mar 2012 16:14:33 +0100
Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote:
Ciaran McCreesh schrieb:
Is there really much of a benefit to this? I guess for anybody who
runs scripts to mass-manipulate ebuilds it might be helpful, but I
think all the package managers planned
Ciaran McCreesh schrieb:
On Sun, 11 Mar 2012 16:14:33 +0100
Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote:
Ciaran McCreesh schrieb:
Is there really much of a benefit to this? I guess for anybody who
runs scripts to mass-manipulate ebuilds it might be helpful, but I
think all the
On Sun, 11 Mar 2012 17:18:45 +0100
Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote:
Assume a new version 13.37 of your package manager drops EAPI=1
support. So package-manager-13.37.ebuild checks in pkg_pretend() if
any EAPI=1 package is installed on the system. If yes, then it
aborts,
Ciaran McCreesh schrieb:
On Sun, 11 Mar 2012 17:18:45 +0100
Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote:
Assume a new version 13.37 of your package manager drops EAPI=1
support. So package-manager-13.37.ebuild checks in pkg_pretend() if
any EAPI=1 package is installed on the
On Sun, 11 Mar 2012 17:46:05 +0100
Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote:
That I suspected, that's why I asked about feasibility.
grep 1 $(portageq vdb_path)/*/*/EAPI die might work for portage
and its current VDB layout.
vdb_path is one of those things that really really
On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
Right now, a quick 'grep -l github.*tarball' shows that there are about
147 ebuilds in portage using github snapshots. This evaluates to 83
different packages.
The problem with github is that it suffixes the tarballs with
a
Here is the latest version of the news item; this gives a few days
notification before the unmasking.
William
Title: udev-181 unmasking
Author: William Hubbs willi...@gentoo.org
Content-Type: text/plain
Posted: 2012-03-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-fs/udev-181
I moved some of the functions currently implemented in the ebuilds for
www-client/chromium and www-client/google-chrome into a new eclass
chromium.eclass.
This will allow the two packages to share some code, and it will reduce
the size of each chromium ebuild by around 4K (18K - 14K).
I have
On Sun, 11 Mar 2012 19:35:36 +0200
Samuli Suominen ssuomi...@gentoo.org wrote:
On 03/11/2012 07:33 PM, William Hubbs wrote:
On Sat, Mar 10, 2012 at 07:28:41PM -0800, Luca Barbato wrote:
On 3/10/12 6:53 PM, Rich Freeman wrote:
neither the genkernel nor dracut docs have specific instructions
On Sun, 11 Mar 2012, William Hubbs wrote:
Here is the latest version of the news item; this gives a few days
notification before the unmasking.
[...]
udev-181 is being unmasked on 2012-03-17 UTC.
You should remove the UTC here, or add a time.
Ulrich
On 03/11/2012 10:25 AM, Leho Kraav wrote:
On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
Right now, a quick 'grep -l github.*tarball' shows that there are about
147 ebuilds in portage using github snapshots. This evaluates to 83
different packages.
The problem with github is
On Sun, 11 Mar 2012 10:25:38 -0700 (PDT)
Leho Kraav l...@kraav.com wrote:
On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
Right now, a quick 'grep -l github.*tarball' shows that there are
about 147 ebuilds in portage using github snapshots. This evaluates
to 83 different
# Samuli Suominen ssuomi...@gentoo.org (11 Mar 2012)
# Deprecated bindings since gtkmozembed was removed at upstream
# Removal in 30 days.
dev-perl/Gtk2-MozEmbed
dev-dotnet/gecko-sharp
# Samuli Suominen ssuomi...@gentoo.org (11 Mar 2012)
# Replaced by USE=ntfsprogs in sys-fs/ntfs3g
# Removal in
On Sun, Mar 11, 2012 at 12:18 PM, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
Assume a new version 13.37 of your package manager drops EAPI=1 support.
So package-manager-13.37.ebuild checks in pkg_pretend() if any EAPI=1
package is installed on the system. If yes, then it aborts,
Rich Freeman schrieb:
On Sun, Mar 11, 2012 at 12:18 PM, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
Assume a new version 13.37 of your package manager drops EAPI=1 support.
So package-manager-13.37.ebuild checks in pkg_pretend() if any EAPI=1
package is installed on the system. If
On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote:
On Sat, 10 Mar 2012 20:27:06 -0600
William Hubbs willi...@gentoo.org wrote:
An initramfs which does this is created by =sys-kernel/genkernel-3.4.25 or
=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
sure
On 11.3.2012 17.33, Zac Medico wrote:
On 03/11/2012 04:03 AM, Petteri Räty wrote:
The Display-If-Installed atom shows the news item to stable users once
it's committed. I am not sure at what point does Portage show it when
the atom is = so we might want to evaluate the options.
It's
On Sun, Mar 11, 2012 at 11:28:19PM +0200, Petteri Räty wrote:
On 11.3.2012 17.33, Zac Medico wrote:
On 03/11/2012 04:03 AM, Petteri Räty wrote:
The Display-If-Installed atom shows the news item to stable users once
it's committed. I am not sure at what point does Portage show it when
the
On 11.3.2012 23.43, William Hubbs wrote:
On Sun, Mar 11, 2012 at 11:28:19PM +0200, Petteri Räty wrote:
On 11.3.2012 17.33, Zac Medico wrote:
On 03/11/2012 04:03 AM, Petteri Räty wrote:
The Display-If-Installed atom shows the news item to stable users once
it's committed. I am not sure at what
On Sat, Mar 10, 2012 at 09:53:25PM -0500, Rich Freeman wrote:
On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs willi...@gentoo.org wrote:
here is the udev 181 unmasking news item.
If all goes well, this will be committed to the tree ?on 3/14 UTC.
I guess this might be OK for unstable, but
Robin H. Johnson posted on Sun, 11 Mar 2012 21:08:47 + as excerpted:
The quickest initramfs, assuming that ALL kernel modules you need to
boot are already compiled into your kernel:
genkernel --install --no-ramdisk-modules initramfs
Plus optionally, If you know you don't need any of
William Hubbs posted on Sun, 11 Mar 2012 12:26:57 -0500 as excerpted:
Here is the latest version of the news item; this gives a few days
notification before the unmasking.
Thanks.
--
Duncan - List replies preferred. No HTML msgs.
Every nonfree program has a lord, a master --
and if you use
On Sun, Mar 11, 2012 at 11:03:50PM +, Duncan wrote:
Meanwhile, also note that there's PARTLABEL, PARTUUID and ID, that the
mount manpage promises to honor. I've not used these myself, but there
was a thread on the btrfs list discussing GPT format and users of its
partition-labels (as
On Sun, Mar 11, 2012 at 11:48:19PM +0200, Petteri Räty wrote:
On 11.3.2012 23.43, William Hubbs wrote:
On Sun, Mar 11, 2012 at 11:28:19PM +0200, Petteri Räty wrote:
On 11.3.2012 17.33, Zac Medico wrote:
On 03/11/2012 04:03 AM, Petteri Räty wrote:
The Display-If-Installed atom shows the
2012/3/11 Ciaran McCreesh ciaran.mccre...@googlemail.com:
On Sun, 11 Mar 2012 09:52:40 -0400
Rich Freeman ri...@gentoo.org wrote:
Is there really much of a benefit to this? I guess for anybody who
runs scripts to mass-manipulate ebuilds it might be helpful, but I
think all the package
These must be maintained indefinitely to provide an upgrade path for
older Gentoo Linux installations. It is rare, but people do upgrade
old installs from time to time. Without some EAPI=1 packages, there is
no path for people to use to upgrade.
On Sun, Mar 11, 2012 at 8:01 AM, Pacho Ramos
top-posting me too to avoid more confusion, sorry
Se my other reply to this thread, upgrading in place an old gentoo
install is nearly impossible, it's so bad that glibc breakage can
occour, that require a knowledge of the system so high that everything
else become nuances of a vague problem.
Richard Yao schrieb:
These must be maintained indefinitely to provide an upgrade path for
older Gentoo Linux installations. It is rare, but people do upgrade
old installs from time to time. Without some EAPI=1 packages, there is
no path for people to use to upgrade.
The clean upgrade path
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2012-03-11 23h59 UTC.
Removals:
games-arcade/ultrastar-ng 2012-03-06 19:58:36 mr_bones_
dev-php/file-iterator 2012-03-10 15:49:39 olemarkus
dev-php/php-codecoverage
On Sun, Mar 11, 2012 at 8:15 PM, Francesco Riosa viv...@gmail.com wrote:
To be able to upgrade a gentoo installation as old as five years is
interesting and valuable but require an effort that has yet to be
made.
I suspect it shouldn't be difficult IF you have access to a binary
package
On Sun, Mar 11, 2012 at 04:14:33PM +0100, Ch??-Thanh Christopher Nguy???n wrote:
Ciaran McCreesh schrieb:
Is there really much of a benefit to this? I guess for anybody who
runs scripts to mass-manipulate ebuilds it might be helpful, but I
think all the package managers planned on
On Fri, Mar 09, 2012 at 06:52:40PM +0100, Micha?? G??rny wrote:
On Fri, 09 Mar 2012 12:31:24 -0500
Michael Orlitzky mich...@orlitzky.com wrote:
On 03/09/12 12:11, Ulrich Mueller wrote:
On Fri, 09 Mar 2012, Michael Orlitzky wrote:
What if bash starts to parse the script completely
On 12 March 2012 02:27, Michał Górny mgo...@gentoo.org wrote:
On Sun, 11 Mar 2012 10:25:38 -0700 (PDT)
Leho Kraav l...@kraav.com wrote:
On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
Right now, a quick 'grep -l github.*tarball' shows that there are
about 147 ebuilds in
On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote:
On 03/09/2012 11:20 AM, Ciaran McCreesh wrote:
On Fri, 09 Mar 2012 11:49:44 -0500
Michael Orlitzky mich...@orlitzky.com wrote:
isnt the whole point of the proposal to get eapi without sourcing ?
so that we can use new bash
On Fri, Mar 09, 2012 at 09:47:50AM -0800, Zac Medico wrote:
On 03/09/2012 09:31 AM, Michael Orlitzky wrote:
On 03/09/12 12:11, Ulrich Mueller wrote:
On Fri, 09 Mar 2012, Michael Orlitzky wrote:
What if bash starts to parse the script completely and barfs at
'syntax error' before it
On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring ferri...@gmail.com wrote:
Pragmatic reality, the eapi function actually would work fine. As
pointed out elsewhere, bash parses as it goes- which isn't going to
change.
Unless the ebuild isn't written in bash...
How do you source the ebuild if
On Sun, Mar 11, 2012 at 7:20 PM, Rich Freeman ri...@gentoo.org wrote:
On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring ferri...@gmail.com wrote:
Pragmatic reality, the eapi function actually would work fine. As
pointed out elsewhere, bash parses as it goes- which isn't going to
change.
On 03/11/2012 07:03 PM, Brian Harring wrote:
Pragmatic reality, the eapi function actually would work fine. As
pointed out elsewhere, bash parses as it goes- which isn't going to
change.
If someone invokes 'eapi happy-meal' and it's not supported,
the sourcing is stopped immediately,
On 03/11/2012 06:55 PM, Brian Harring wrote:
On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote:
Yeah. Another way of putting it is that the requirement to spawn a bash
process and source the ebuild adds a ridiculous amount of unnecessary
complexity, in violation of the KISS principle
LGTM.
--
Thanks,
Zac
55 matches
Mail list logo
