Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5)
On Tue, 19 Jun 2012 23:07:01 +0200 Thomas Sachau wrote: > Do you prefer having everything hardcoded in PMS or can you accept > outsourcing bigger code pieces into some sort of eclass (i am thinking > about some external code base, which can be duplicated by the package > manager with internal code, but has to be used, if the external eclass > has a newer version/revision then the duplicated internal code)? The package manager mustn't require any particular eclass to be present, and there mustn't be duplication between eclasses and the package manager. > I am especially thinking about the setup of the environment and the > code details for the wrappers for binaries and headers, hardcoding > those details into PMS makes it hard to change/fix issues later on. Sounds like you haven't really got a clean design then. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 06/20/2012 06:46 AM, Doug Goldstein wrote: On Tue, Jun 19, 2012 at 10:27 PM, Samuli Suominen wrote: On 06/20/2012 06:19 AM, Mike Frysinger wrote: On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote: On 06/15/2012 06:10 PM, Mike Frysinger wrote: On Friday 15 June 2012 03:44:14 Samuli Suominen wrote: On 06/13/2012 06:02 AM, Mike Frysinger wrote: i've noticed a growing trend where people put setup of variables into pkg_setup that only matter to src_* funcs presumably so they don't have to call the respective src_* func from an inherited eclass. unfortunately this adds pointless overhead to binpkgs. can we please move away from this practice ? Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, DOCS for src_install, PATCHES for src_prepare these are static variables, so defining them in a func is pointless "sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used before, not sure if it's used in tree right now or not as we've always said, USE conditional patches are to be highly discouraged I agree BUT there are cases where it's OK to use conditional patching: For example, libfoo-0.1.1 is broken and is fixed in git for master which will be in next release. The fix doesn't apply to 0.1.1 cleanly without heavy modifications. Then you would take the easiest possible route to get 0.1.1 working again, with the comfort of knowing it's properly fixed for the next version. -Samuli I assume you mean libfoo-0.1.1 is broken when USE=bar is enabled and you get a patch for that conditional case when USE=bar is enabled. Right. Of course. Either way, the better solution is to mask it and have people use libfoo-0.1.0 Doesn't really apply to this case: Think about masking stable Xfce 4.10 when the fix is in git that will be released as 4.12 in about year. ;-) - Samuli
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tue, Jun 19, 2012 at 11:21 PM, Mike Frysinger wrote:
> On Tuesday 19 June 2012 17:35:00 Jeroen Roovers wrote:
>> On Tue, 12 Jun 2012 23:02:40 -0400 Mike Frysinger wrote:
>> > i've noticed a growing trend where people put setup of variables into
>> > pkg_setup that only matter to src_* funcs presumably so they don't
>> > have to call the respective src_* func from an inherited eclass.
>> > unfortunately this adds pointless overhead to binpkgs. can we please
>> > move away from this practice ?
>>
>> Like this?
>
> not quite
>
>> * ERROR: cat/pkg-version failed (prepare phase):
>> * python_set_active_version() can be used only in pkg_setup() phase
>> *
>> * Call stack:
>> * ebuild.sh, line 85: Called src_prepare
>> * environment, line 5885: Called python_set_active_version '2'
>> * environment, line 5603: Called die
>> * The specific snippet of code:
>> * die "${FUNCNAME}() can be used only in pkg_setup() phase";
>> *
>>
>> Shouldn't that be in src_prepare already, or does python.eclass do
>> something rather important here while installing a binpkg?
>
> Gentoo's python integration is an ugly beast. in this case, i believe it's
> screwing with your $ROOT which means it has to be in pkg_* (let's quietly
> ignore what happens if you try to emerge two ebuilds which need conflicting
> versions of python active).
> -mike
python_set_active_version basically just sets the EPYTHON and
PYTHON_ABI variables; nothing in ${ROOT} is modified.
The variables are used in python_pkg_setup to implement use-flag
checks for PYTHON_USE_WITH, and also in python_mod_optimize which is
called in pkg_postinst.
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tue, Jun 19, 2012 at 10:27 PM, Samuli Suominen wrote: > On 06/20/2012 06:19 AM, Mike Frysinger wrote: >> >> On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote: >>> >>> On 06/15/2012 06:10 PM, Mike Frysinger wrote: On Friday 15 June 2012 03:44:14 Samuli Suominen wrote: > > On 06/13/2012 06:02 AM, Mike Frysinger wrote: >> >> i've noticed a growing trend where people put setup of variables into >> pkg_setup that only matter to src_* funcs presumably so they don't >> have >> to call the respective src_* func from an inherited eclass. >> unfortunately this adds pointless overhead to binpkgs. can we please >> move away from this practice ? > > > Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, > DOCS for src_install, PATCHES for src_prepare these are static variables, so defining them in a func is pointless >>> >>> >>> "sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used >>> before, not sure if it's used in tree right now or not >> >> >> as we've always said, USE conditional patches are to be highly discouraged > > > I agree BUT there are cases where it's OK to use conditional patching: > > For example, libfoo-0.1.1 is broken and is fixed in git for master which > will be in next release. The fix doesn't apply to 0.1.1 cleanly without > heavy modifications. > Then you would take the easiest possible route to get 0.1.1 working again, > with the comfort of knowing it's properly fixed for the next version. > > -Samuli > I assume you mean libfoo-0.1.1 is broken when USE=bar is enabled and you get a patch for that conditional case when USE=bar is enabled. Either way, the better solution is to mask it and have people use libfoo-0.1.0 -- Doug Goldstein
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 06/20/2012 06:19 AM, Mike Frysinger wrote: On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote: On 06/15/2012 06:10 PM, Mike Frysinger wrote: On Friday 15 June 2012 03:44:14 Samuli Suominen wrote: On 06/13/2012 06:02 AM, Mike Frysinger wrote: i've noticed a growing trend where people put setup of variables into pkg_setup that only matter to src_* funcs presumably so they don't have to call the respective src_* func from an inherited eclass. unfortunately this adds pointless overhead to binpkgs. can we please move away from this practice ? Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, DOCS for src_install, PATCHES for src_prepare these are static variables, so defining them in a func is pointless "sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used before, not sure if it's used in tree right now or not as we've always said, USE conditional patches are to be highly discouraged I agree BUT there are cases where it's OK to use conditional patching: For example, libfoo-0.1.1 is broken and is fixed in git for master which will be in next release. The fix doesn't apply to 0.1.1 cleanly without heavy modifications. Then you would take the easiest possible route to get 0.1.1 working again, with the comfort of knowing it's properly fixed for the next version. -Samuli
Re: [gentoo-dev] Killing UEFI Secure Boot
Hi, I have about 11 years of experience with coreboot. I got involved while developing a custom BIOS for an embedded system. You may already have caught some presentation I or one of the other developers have made about the project. There's a bunch of links over at http://www.coreboot.org/Screenshots Richard Yao wrote: > Core Boot is a Linux distribution. Sorry sir, but no. coreboot (one word, lowercase) is an open source BIOS replacement. Proprietary BIOSes do two things: 1. hardware initialization on http://stuge.se/pc2010.png everything red requires init by firmware 2. starts an operating system this means implementing the BIOS Boot Specification, running master boot record code into real mode segment 7c00h, eltorito CD-ROM extensions and all of that crap coreboot does step 1. and nothign else, and significantly faster than common proprietary BIOSes. When coreboot is done it starts another, separate, program, we call that program "the payload." The payload and coreboot are stored together in the boot flash, but are not linked together. The payload can be any bare-metal program. There are many legacy-free bootloader payloads, including GRUB2 and gPXE/iPXE/whateverit'scalledtoday, but it can just as easily be an operating system kernel or an embedded application if no OS is needed. Boot flash are often 32Mbit today, so Linux and a small initramfs fits comfortably. The default payload is SeaBIOS, which is also the firmware QEMU uses. SeaBIOS is an open source legacy BIOS implementation, and the combination of coreboot and SeaBIOS provides a legacy-compatible boot environment that starts your system exactly like an old-fashioned proprietary BIOS. With coreboot my laptop boots from power button to firefox in a little over 8 seconds. Out of that time, coreboot runs for about 600 milliseconds. This is a fairly typical number. > The 80386's RESET state is emulated uniformly across all x86 and amd64, > so it should not take much effort to support the basic functions of > setting up the CPU, loading the kernel (from the EEPROM) and jumping > into it. This is word for word what the founders of the coreboot project (then called LinuxBIOS) thought back in 1999, and it blew up in their face. In the following 15 years hardware has gotten significantly more complex, and significantly more closed, again please have a look at http://stuge.se/pc2010.png The closer you are to the CPU the more impossible it is to acquire reliable documentation for how to program the hardware. > Those are the only things that a BIOS replacement needs to do. Please join the project! If you find lowlevel programming interesting it is an amazing good time, even if progress is slow at times. Now is a fantastic time to get involved! For the first time in the history of the project, there is code in the repository for all current hardware platforms from both AMD and Intel. > they are doing far more than those basic functions I hope I've been able to clarify that actually coreboot does nothing other than what is neccessary. This is the very essence of coreboot. > Basic functionality would only require the work of a few people. I'm afraid that this is rather naive. An experienced coreboot developer given all required documentation[1] (and ideally some 100-1000k EUR/USD worth of test equipment) can possibly do a port to a new hardware platform (new CPU and chipset) in twelve to eighteen months full time. A hard core developer but without previous experience from PC firmware and coreboot should add some six months for loading the domain into her head. [1] For Intel this requires two stages of NDAs and a decent business case where Intel will sell five-six figure amounts of chips, or fewer chips but to an important customer. In contrast, AMD put the documentation on their webpage. NVIDIA did not give the documentation to anyone no matter what the business case. VIA doesn't publish documentation on the web, but some coreboot developers do have good relations with them. Over the last couple years Google have hired most of the active coreboot developers including the project founder, and they've been working on support for Intel's Sandy Bridge and Ivy Bridge platforms, which powers the new Chromebook. I do not know how much time they've spent, but from my outside view I estimate that it took this amazing team of engineers between 25 and 30 man-months. This may be a very optimistic estimate. These new Intel platforms require a blob, firmware for a microcontroller in the chipset, which runs while the main CPU is still held in reset, in order to do some early prepararation of the system. The firmware blob is signed by Intel. I don't know if the signature scheme has been broken, I guess it might at some point, but that will likely be by the usual IT security crowd suspects. In Google's coreboot code they are using Intel's reference code for initializing the memory controller. This is so far also a blob, again
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tuesday 19 June 2012 17:35:00 Jeroen Roovers wrote:
> On Tue, 12 Jun 2012 23:02:40 -0400 Mike Frysinger wrote:
> > i've noticed a growing trend where people put setup of variables into
> > pkg_setup that only matter to src_* funcs presumably so they don't
> > have to call the respective src_* func from an inherited eclass.
> > unfortunately this adds pointless overhead to binpkgs. can we please
> > move away from this practice ?
>
> Like this?
not quite
> * ERROR: cat/pkg-version failed (prepare phase):
> * python_set_active_version() can be used only in pkg_setup() phase
> *
> * Call stack:
> * ebuild.sh, line 85: Called src_prepare
> * environment, line 5885: Called python_set_active_version '2'
> * environment, line 5603: Called die
> * The specific snippet of code:
> * die "${FUNCNAME}() can be used only in pkg_setup() phase";
> *
>
> Shouldn't that be in src_prepare already, or does python.eclass do
> something rather important here while installing a binpkg?
Gentoo's python integration is an ugly beast. in this case, i believe it's
screwing with your $ROOT which means it has to be in pkg_* (let's quietly
ignore what happens if you try to emerge two ebuilds which need conflicting
versions of python active).
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote: > On 06/15/2012 06:10 PM, Mike Frysinger wrote: > > On Friday 15 June 2012 03:44:14 Samuli Suominen wrote: > >> On 06/13/2012 06:02 AM, Mike Frysinger wrote: > >>> i've noticed a growing trend where people put setup of variables into > >>> pkg_setup that only matter to src_* funcs presumably so they don't have > >>> to call the respective src_* func from an inherited eclass. > >>> unfortunately this adds pointless overhead to binpkgs. can we please > >>> move away from this practice ? > >> > >> Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables, > >> DOCS for src_install, PATCHES for src_prepare > > > > these are static variables, so defining them in a func is pointless > > "sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used > before, not sure if it's used in tree right now or not as we've always said, USE conditional patches are to be highly discouraged > >> and XFCONF for src_configure > > > > now you're down to one variable which means you've got one func to > > /properly/ define > > src_configure() still requires calling itself (xfconf_src_configure) in > the end of the function yes, but that's the correct way to do it -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 06/15/2012 06:10 PM, Mike Frysinger wrote:
On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:
On 06/13/2012 06:02 AM, Mike Frysinger wrote:
i've noticed a growing trend where people put setup of variables into
pkg_setup that only matter to src_* funcs presumably so they don't have
to call the respective src_* func from an inherited eclass.
unfortunately this adds pointless overhead to binpkgs. can we please
move away from this practice ?
Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables,
DOCS for src_install, PATCHES for src_prepare
these are static variables, so defining them in a func is pointless
"sort of" not necessarily, 'has $useflag && PATCHES+=( )' has been used
before, not sure if it's used in tree right now or not
and XFCONF for src_configure
now you're down to one variable which means you've got one func to /properly/
define
src_configure() still requires calling itself (xfconf_src_configure) in
the end of the function
someone suggested writing, for example, xfconf() function that accepts
$@ arguments so you could
src_configure() {
xfconf \
$(use_enable foo)
}
but I don't really like that either...
src_setup() would be cool and solve all the forementioned issues
-Samuli
Re: [gentoo-dev] Killing UEFI Secure Boot
On Tue, Jun 19, 2012 at 9:33 PM, Richard Yao wrote: > On 06/19/2012 09:25 PM, Rich Freeman wrote: > We would gain a faster boot process. We would also enable people to > avoid paying money for keys that can be revoked without a refund. > While I have no doubt that a determined team could make a firmware that booted marginally faster, I don't get the bit about not paying for keys. You don't have to pay anybody for a key to boot with UEFI - you just need to either disable secure boot, or install your own keys. I can't see how installing your own keys is going to be harder than flashing the entire BIOS, and if you still want secure boot presumably you still have to install your own keys. If somebody wants to make a generic UEFI bootloader for PCs they should by all means do so - I'm sure people would find use for it. I just don't see it as an essential ingredient for Gentoo. If I really wanted to mess with my BIOS I'd probably be loading core boot on it. Rich
Re: [gentoo-dev] Killing UEFI Secure Boot
On 06/19/2012 09:25 PM, Rich Freeman wrote: >> In theory, the kernel could be modified to only execute signed binaries >> and portage could be modified to produce signed binaries. The user could >> build a system that required everything to be signed with the private >> key of his choice. A hardened system that required signed binaries would >> be even more secure than a typical system using Secure Boot where only >> the bootloader, kernel and kernel modules are signed. The user would be >> in full control of his hardware. The user would not need to pay for this >> and the system would also boot faster. > > You can do all of this with the UEFI firmware that will come with your > computer already. Why replace it? We would gain a faster boot process. We would also enable people to avoid paying money for keys that can be revoked without a refund. I would rather people make donations to the Gentoo Foundation voluntarily than to Verisign out of necessity, but that is just me.
Re: [gentoo-dev] Killing UEFI Secure Boot
On Tue, Jun 19, 2012 at 9:10 PM, Richard Yao wrote: > On 06/19/2012 08:22 PM, Rich Freeman wrote: > Core Boot is a Linux distribution. I do not think that we should boot > Gentoo using their distribution any more than we boot Gentoo using RHEL. Well, maybe it is a distro in the sense that genkernel or dracut are distros (they bundle a bunch of tools in conjunction with a kernel to do something). The whole point of Core Boot is to be a BIOS replacement - either to do work on its own, or to boot something else. Like UEFI it aims to do more than just load one sector off the hard drive, check for a magic number, and jump into it. > In theory, the kernel could be modified to only execute signed binaries > and portage could be modified to produce signed binaries. The user could > build a system that required everything to be signed with the private > key of his choice. A hardened system that required signed binaries would > be even more secure than a typical system using Secure Boot where only > the bootloader, kernel and kernel modules are signed. The user would be > in full control of his hardware. The user would not need to pay for this > and the system would also boot faster. You can do all of this with the UEFI firmware that will come with your computer already. Why replace it? > The 80386's RESET state is emulated uniformly across all x86 and amd64, > so it should not take much effort to support the basic functions of > setting up the CPU, loading the kernel (from the EEPROM) and jumping > into it. Everything else is secondary. Fair enough, and the fact is that most modern OSes depend little on the BIOS for much of anything. I'm not sure that is absolutely nothing, but obviously the Core Boot folks have it working in some cases. > > Those are the only things that a BIOS replacement needs to do. As you > pointed out, Core Boot is trying to add value. That means that they are > doing far more than those basic functions. Other features are nice, but > not if they get in the way of being able to boot. Other things can come > the system boot process works. > > Did I miss any technical obstacles? Honestly, I'd probably ask one of the Core Boot folks. Has anybody already tried to make a core boot light? If their system already works on any board out there, then we're re-inventing the wheel. If theirs doesn't, then we need to ask why, since we're likely to run into the same barriers. In any case, this seems like a solution to a problem that we don't have. Any win7-certified motherboard is doing to be able to boot without secure boot just fine, so why do we need to replace it with a minimal firmware that does the same thing? I can see why one might want to improve on it, with Core Boot and such. However, I suspect the last thing we want in the Gentoo handbook is for every newbie to be flashing a Gentoo-made firmware onto their board and we get to deal with the bricks. Rich
Re: [gentoo-dev] Killing UEFI Secure Boot
On 06/19/2012 08:22 PM, Rich Freeman wrote: > On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao wrote: >> I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster. > > So, replacing a BIOS is a fairly tall order - I'm not convinced that > Core Boot is slow simply because they're doing it wrong. They're also > looking to add value (like booting a diskless server off of a random > website or whatever - not just simple disk/PXE like most BIOS). My > understanding is that clusters are one of their big use cases. Core Boot is a Linux distribution. I do not think that we should boot Gentoo using their distribution any more than we boot Gentoo using RHEL. > I also don't get the claim that we need to flash our BIOS chips to get > around secure boot. If you don't want to use secure boot just disable > it - it is no harder than changing your boot device order, system > time, or any of a myriad of other firmware settings. It gets more > complicated if you want to keep secure boot but boot your own OS, > since you have to manage the keys/signing/etc. In theory, the kernel could be modified to only execute signed binaries and portage could be modified to produce signed binaries. The user could build a system that required everything to be signed with the private key of his choice. A hardened system that required signed binaries would be even more secure than a typical system using Secure Boot where only the bootloader, kernel and kernel modules are signed. The user would be in full control of his hardware. The user would not need to pay for this and the system would also boot faster. > Nothing is keeping anybody from creating their own firmware. However, > I doubt we'll see 25 devs take this on as a full-time job, which is > probably what it would take to support the bazillions of boards out > there. Keep in mind that many motherboard vendors require signed > firmware so you'll need to find an exploit for every make/model out > there to even load your firmware. That seems a bit much compared to > just disabling secure boot... The 80386's RESET state is emulated uniformly across all x86 and amd64, so it should not take much effort to support the basic functions of setting up the CPU, loading the kernel (from the EEPROM) and jumping into it. Everything else is secondary. Those are the only things that a BIOS replacement needs to do. As you pointed out, Core Boot is trying to add value. That means that they are doing far more than those basic functions. Other features are nice, but not if they get in the way of being able to boot. Other things can come the system boot process works. Basic functionality would only require the work of a few people. Things beyond that (e.g. pre-kernel VGA console initialization, pre-kernel networking, etcetera) might require vendor support through documentation. I would be thrilled if 25 developers wanted to work on this full time, but I am not certain that would make sense. Linux already has thousands of developers working on hardware support, including developers from Intel. We should be able to leverage that. Did I miss any technical obstacles?
Re: [gentoo-dev] Killing UEFI Secure Boot
On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao wrote: > I know that the Core Boot project also tries to accomplish this, but their > development process is slow and their approach seems to make the boot process > more complicated than it needs to be. Since Secure Boot will force us to > flash our BIOS chips (or stick to old hardware), I think it would be > worthwhile to develop our own solution by extending genkernel. This should > have the benefit of making our systems boot faster. So, replacing a BIOS is a fairly tall order - I'm not convinced that Core Boot is slow simply because they're doing it wrong. They're also looking to add value (like booting a diskless server off of a random website or whatever - not just simple disk/PXE like most BIOS). My understanding is that clusters are one of their big use cases. I also don't get the claim that we need to flash our BIOS chips to get around secure boot. If you don't want to use secure boot just disable it - it is no harder than changing your boot device order, system time, or any of a myriad of other firmware settings. It gets more complicated if you want to keep secure boot but boot your own OS, since you have to manage the keys/signing/etc. Nothing is keeping anybody from creating their own firmware. However, I doubt we'll see 25 devs take this on as a full-time job, which is probably what it would take to support the bazillions of boards out there. Keep in mind that many motherboard vendors require signed firmware so you'll need to find an exploit for every make/model out there to even load your firmware. That seems a bit much compared to just disabling secure boot... Rich
[gentoo-dev] Killing UEFI Secure Boot
I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. With that in mind, I believe we can solve the Secure Boot problem by installing Gentoo on PC hardware like how OpenWRT is installed on routers. http://wiki.openwrt.org/doc/techref/flash.layout We can extend genkernel to produce images similar OpenWRT images. This image would have partitions. In particular, it would have one for the bootloader, another for the kernel and a third for an optional root filesystem. The bootloader partition would be further divided between boot code and the NVRAM, which would contain bootloader settings. The bootloader would read the NVRAM to obtain the kernel command line that it provides to the kernel and then boot it. THe kernel would then be responsible for initializing hardware and mounting the rootfs. We will need boot code designed to start after RESET, read the NVRAM, configure the memory address space, load the kernel and jump into it. It would also handle any other things that either the kernel requires or that users want, such as a VGA text console before the kernel boots. A VGA console will require additional documentation from vendors, but routers seem to boot fine without it and our systems should too. x86 hardware emulates an 80386 environment at RESET, so we should be able to use documentation on 80386 to assist in development: http://css.csail.mit.edu/6.858/2011/readings/i386.pdf Das U-Boot and RedBoot are typically used on routers, but unlike RedBoot, Das U-Boot supports x86. In addition, the knowledge and tools necessary to develop on physical hardware are quite accessible: http://openschemes.com/2009/10/20/installing-a-plcc-eeprom-socket-onto-a-mobo/ http://www.sivava.com/EPROM_Programmer_5.html Developing on physical hardware could be tedious and time consuming, so it would probably be best to develop this on virtual hardware first. VMWare in particular uses a Phoenix BIOS. My expectation is that developing this on VMware's virtual hardware will help avoid issues when development moves to physical hardware. In addition, instructions are available for booting custom BIOS images, which is precisely what we need to develop this: http://pete.akeo.ie/2011/06/extracting-and-using-modified-vmware.html I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster. This should open the door to further genkernel extensions, such as the creation of an initramfs that provides a general purpose GRUB replacement. This would enable us to flash the BIOS only once and then boot newer kernels (or even other operating systems) by adding entries to the NVRAM. It would still be faster than Core Boot because the kernel in the BIOS chip should still be able to mount the rootfs and boot the system. Does anyone have any thoughts, comments or suggestions? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On Tue, 12 Jun 2012 23:02:40 -0400
Mike Frysinger wrote:
> i've noticed a growing trend where people put setup of variables into
> pkg_setup that only matter to src_* funcs presumably so they don't
> have to call the respective src_* func from an inherited eclass.
> unfortunately this adds pointless overhead to binpkgs. can we please
> move away from this practice ?
Like this?
* ERROR: cat/pkg-version failed (prepare phase):
* python_set_active_version() can be used only in pkg_setup() phase
*
* Call stack:
* ebuild.sh, line 85: Called src_prepare
* environment, line 5885: Called python_set_active_version '2'
* environment, line 5603: Called die
* The specific snippet of code:
* die "${FUNCNAME}() can be used only in pkg_setup() phase";
*
Shouldn't that be in src_prepare already, or does python.eclass do
something rather important here while installing a binpkg?
jer
Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5)
Brian Harring schrieb: > On Tue, Jun 19, 2012 at 08:54:07PM +0200, Thomas Sachau wrote: >> Ciaran McCreesh schrieb: >>> On Tue, 19 Jun 2012 20:16:39 +0200 >>> Thomas Sachau wrote: Since there is again no response at all, it seems like everyone is ok with this, so i will propose to add this to the next council agenda for EAPI-5 addition. >>> >>> Got a diff for PMS? >>> >> >> Last time you only requested enough details for implementation, you did >> not require a PMS diff, so i wrote more details for the implementation. >> >> If you, Brian (for pkgcore) and zmedico accept this for EAPI-5, i might >> look into creating a diff against PMS but until then, i dont want to >> waste my time, especially since noone commented on the implementation >> details or the technical details and any change would require even more >> work to rework/adjust the PMS diff. > > You need a glep here frankly; per the norm, if you want things to move > faster, then put in time- aka, generate a patch against PMS, write a > patch for portage, etc, you get the idea. Since multilib-portage code is just a git branch for the portage code, i effectively have a patch for portage. ;-) Before i start investing more time, a question to the PM developers: Do you prefer having everything hardcoded in PMS or can you accept outsourcing bigger code pieces into some sort of eclass (i am thinking about some external code base, which can be duplicated by the package manager with internal code, but has to be used, if the external eclass has a newer version/revision then the duplicated internal code)? I am especially thinking about the setup of the environment and the code details for the wrappers for binaries and headers, hardcoding those details into PMS makes it hard to change/fix issues later on. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5)
On Tue, Jun 19, 2012 at 08:54:07PM +0200, Thomas Sachau wrote: > Ciaran McCreesh schrieb: > > On Tue, 19 Jun 2012 20:16:39 +0200 > > Thomas Sachau wrote: > >> Since there is again no response at all, it seems like everyone is ok > >> with this, so i will propose to add this to the next council agenda > >> for EAPI-5 addition. > > > > Got a diff for PMS? > > > > Last time you only requested enough details for implementation, you did > not require a PMS diff, so i wrote more details for the implementation. > > If you, Brian (for pkgcore) and zmedico accept this for EAPI-5, i might > look into creating a diff against PMS but until then, i dont want to > waste my time, especially since noone commented on the implementation > details or the technical details and any change would require even more > work to rework/adjust the PMS diff. You need a glep here frankly; per the norm, if you want things to move faster, then put in time- aka, generate a patch against PMS, write a patch for portage, etc, you get the idea. The bit re: a PMS patch is mostly that in looking at your proposal... well, I personally don't want to write that patch (nor do I suspect ulm/ciaran do either). One thing to note; this has been posted for all of 2-3 days; that's not exactly much time for 1) people to comment, 2) people to frankly comprehend the quite dense description you wrote. Please write a glep covering details of the implementation, background, preferablly why this route over others. Bluntly... clue everyone else in rather than hoping they'll just sign off on a fairly opaque list of things. :) It'll be useful for dev education also- which is a bit of a requirement for stuff of this sort considering it's not going to be a magic deploy/shit works everywhere situation I suspect. Would also be useful getting commentary from crossdev folk considering your solution is intended to be (best I can tell) full cross compilation support, and they've been leading that front for many, many years. Cheers- ~brian
Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5)
On Tue, 19 Jun 2012 20:54:07 +0200 Thomas Sachau wrote: > Ciaran McCreesh schrieb: > > On Tue, 19 Jun 2012 20:16:39 +0200 > > Thomas Sachau wrote: > >> Since there is again no response at all, it seems like everyone is > >> ok with this, so i will propose to add this to the next council > >> agenda for EAPI-5 addition. > > > > Got a diff for PMS? > > Last time you only requested enough details for implementation, you > did not require a PMS diff, so i wrote more details for the > implementation. > > If you, Brian (for pkgcore) and zmedico accept this for EAPI-5, i > might look into creating a diff against PMS but until then, i dont > want to waste my time, especially since noone commented on the > implementation details or the technical details and any change would > require even more work to rework/adjust the PMS diff. Here's the thing: I doubt the lack of feedback is down to everyone being happy with the proposal. I strongly suspect it's because people look at it and go "huh?". You've provided exactly the kind of information that no-one cares about (e.g. long lists of variable names, which will probably just come from a var in profiles), and none of what really matters. I think you'll get a better response if you write this up in GLEP form (i.e. motivation, examples etc) to describe to ebuild developers what's in it for them, and as a diff against PMS so that package mangler authors can work out exactly what you're saying. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5)
Ciaran McCreesh schrieb: > On Tue, 19 Jun 2012 20:16:39 +0200 > Thomas Sachau wrote: >> Since there is again no response at all, it seems like everyone is ok >> with this, so i will propose to add this to the next council agenda >> for EAPI-5 addition. > > Got a diff for PMS? > Last time you only requested enough details for implementation, you did not require a PMS diff, so i wrote more details for the implementation. If you, Brian (for pkgcore) and zmedico accept this for EAPI-5, i might look into creating a diff against PMS but until then, i dont want to waste my time, especially since noone commented on the implementation details or the technical details and any change would require even more work to rework/adjust the PMS diff. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5)
On Tue, 19 Jun 2012 20:16:39 +0200 Thomas Sachau wrote: > Since there is again no response at all, it seems like everyone is ok > with this, so i will propose to add this to the next council agenda > for EAPI-5 addition. Got a diff for PMS? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5)
Thomas Sachau schrieb: > Duncan schrieb: >> Thomas Sachau posted on Sat, 16 Jun 2012 12:31:40 +0200 as excerpted: >> >>> Since i am not that sure about my ability to write formal specs, i am >>> presenting my first draft for further review and suggestions for >>> improvement. >> >> Just a format suggestion. Call it nitpicky if you want, and yes, my >> client isn't perfect, but I'm sure people with a bit of experience >> writing such specs will tell you I'm not alone... >> >> Several of your points ended up as very long single lines. My client can >> wrap, but that wraps the points as well (so for example 2.1 starts in the >> middle of a line). So I was left with the choice to either massively >> horizontally scroll, or of trying to figure out where one point ended and >> another began, since wrapping it... /wrapped/ it, so points appeared in >> the middle of a line. >> >> Please: >> >> * If you use long lines, leave a vertical space (blank line) between >> points so when a client wraps them, they wrap as individual paragraphs. >> >> * Alternatively, wrap at something sensible. (The traditional wrap for >> posting is 72 chars or so, 80 minus a few to allow a few levels of >> quoting without rewrap. I wouldn't complain at 90, but if you're going >> to bother, you might as well go the standard route and avoid further >> issues.) >> >> Long lines as paragraphs would probably be easier especially early in the >> process when you're modifying a lot, but you still risk (even more) >> limited clients having issues with it. YMMV. >> > > I suggest you look for a better client to handle the line wrapping > better. ;-) In the meantime, the same file attached with wrapped lines. > Since there is again no response at all, it seems like everyone is ok with this, so i will propose to add this to the next council agenda for EAPI-5 addition. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] spec draft for cross-compile support in future EAPI (EAPI-5)
Luca Barbato schrieb: > On 06/16/2012 12:31 PM, Thomas Sachau wrote: >> Since i am not that sure about my ability to write formal specs, i am >> presenting my first draft for further review and suggestions for >> improvement. > > Currently I'm experimenting with evil hack with qemu-static (hopefully > that would make my student life happier later). > > What would be nice on a full multilib/multiabi system is to have > > /lib/ld-linux-foo-arch.so.2 for each active architecture This should be under control by the libc ebuild/package, not controlled by the package manager. > > /usr/$CTUPLE/ as destdir for each of them if you mean $CTUPLE as an arch, so that every arch should have all files for each package, then something like that does not exist. It may be possible with an extended multilib-portage, but since i did not think about it nor tested it, i cant say for sure. > and possibly split RDEPEND/DEPEND to have HDEPEND to list build > dependencies that need to be run on host. What should the difference between DEPEND and HDEPEND be? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] spec draft for cross-compile support in future EAPI (EAPI-5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/16/2012 12:31 PM, Thomas Sachau wrote: > Since i am not that sure about my ability to write formal specs, i am > presenting my first draft for further review and suggestions for > improvement. Currently I'm experimenting with evil hack with qemu-static (hopefully that would make my student life happier later). What would be nice on a full multilib/multiabi system is to have /lib/ld-linux-foo-arch.so.2 for each active architecture /usr/$CTUPLE/ as destdir for each of them PATH and ld.so.conf pointing to them accordingly. and possibly split RDEPEND/DEPEND to have HDEPEND to list build dependencies that need to be run on host. lu - -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/gvVYACgkQ6Ex4woTpDjQlaQCg1W/PZxOo/2EDktU0XR6/48nf 9RcAoOg40vFoSIX7gNpD82qdym54MB4m =hEyq -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/17/2012 10:31 PM, Michał Górny wrote: > Hello, > > A simple solution to a program long-unsolved. In GLEP form. > > Both attached and published as a gist: > > https://gist.github.com/2945569 > > (please note that github doesn't render GLEP headers correctly) > As already stated I like this idea, because I already got some optional dep bloat in x11-misc/spacefm and media-sound/gmusicbrowser. However I have a few objections: 1. Optional deps are SUGGESTIONS from the dev which he considered nice/good/sane at the time of writing the ebuild. Other people might totally disagree with those suggestions. As useflags in IUSE_RUNTIME can pick from global useflags as well or even set "+foo" the user might have a hard time to turn off things he does not want without turning them off for regular IUSE as well. Means: "foo" pulls in an optional dependency for package suckbar/gaybar, but it also pulls in build-time deps for nerdbar/geekbar The user has to figure out now what the useflag does for each package and micromanage useflags to maybe avoid undesired optional deps. FEATURES="optional-deps" would be one way to overcome this, so I can globally turn useflags in IUSE_RUNTIME off without those in regular IUSE. But that may cause problems with REQUIRED_USE then maybe, not sure. 2. Afais useflags that are already in IUSE and used for build-time stuff must not be used for IUSE_RUNTIME too. This is a random rule IMO. I don't have many cases in mind where this would be annoying (could think of "debug" enabling some in-source switches and adding optional debug tools in RDEPEND. Having one flag here would make it cleaner and tighter for the user to interact with useflags.). However... this is not a logical rule, rather a technical issue. If there is a way to avoid this restriction that would be nice. (There was one proposal about expanding useflags in IUSE_RUNTIME, but I have not thought far in that direction.) 3. There are no unconditional optional deps possible. ssuominen had an example: "virtualx.eclass could have suggestion/recommendation to enable USE=xvfb in x11-base/xorg-server" and some things I forgot...
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On 06/17/2012 10:31 PM, Michał Górny wrote: > Hello, > > A simple solution to a program long-unsolved. In GLEP form. > > Both attached and published as a gist: > > https://gist.github.com/2945569 > > (please note that github doesn't render GLEP headers correctly) > This looks very nice, imo.
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On 06/17/2012 05:39 PM, Michał Górny wrote: > But Python doesn't have one. Bindings built using other > languages don't have that either. That seems something interesting to tackle with the python community. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Tue, 19 Jun 2012 10:43:47 +0200 Michał Górny wrote: > > > - being package-oriented rather than feature-oriented, > > > > No; use flags are our configuration space, and they turn on/off > > sections of the given pkgs graph. Your proposal relies on the same > > concept; bluntly, what you're proposing is just as 'package > > oriented'. > > > > Effectively, you can't dismiss SDEPEND/ODEPEND via changing the > > rules between your proposal and ODEPEND's proposal. Nice try > > though. :) > > USE flags can describe features, like USE=ssl, USE=html, USE=whatever. > The exherbo suggested dependencies just list the relevant packages. > > In other words, here you enable USE=html to get HTML output. With > SDEPEND, you would --take dev-python/somerandomhtmllibrary. Incorrect. Exherbo allows suggestions to be grouped, described and taken by feature. It's done via annotations (the same mechanism used to provide decent handling of blockers etc). Search for "group-name" in exheres-for-smarties for an example. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Mon, 18 Jun 2012 20:04:48 -0700 Brian Harring wrote: > On Sun, Jun 17, 2012 at 10:31:59PM +0200, Micha?? G??rny wrote: > > 4. flags listed in ``IUSE_RUNTIME`` may be referred through USE > >dependencies by other packages' ``DEPEND``, ``RDEPEND`` > >and ``PDEPEND`` variables. > > Unless I'm on crack, you're stating that essentially an optional use > flag (one you label 'runtime'), is able to be used transitively > during DEPEND. That's not particularly "here's some suggested pkgs > to install"- that's "rebuild the fucker for this changed DEPEND", > which is the existing situation. It could be used by another package. Let's say dev-util/foo is a documentation generator in Python. It has optional runtime dependencies for HTML output enabled via USE=html. If dev-libs/bar uses foo for HTML output during the build, it can DEPEND on dev-util/foo[html]. > > The remaining reused features include: > > > > - dependency syntax, > > If you invent new syntax, I'm going to be unhappy. KISS as it were. > > > - ability to use ``REQUIRED_USE``, USE dependencies, > > - ability to describe flags in `metadata.xml`, > > - global flag names (and descriptions). > > > > Alternative proposed solution involved creating additional > > ``SDEPEND`` variable. That proposition had the following > > disadvantages: > > > > - being package-oriented rather than feature-oriented, > > No; use flags are our configuration space, and they turn on/off > sections of the given pkgs graph. Your proposal relies on the same > concept; bluntly, what you're proposing is just as 'package oriented'. > > Effectively, you can't dismiss SDEPEND/ODEPEND via changing the rules > between your proposal and ODEPEND's proposal. Nice try though. :) USE flags can describe features, like USE=ssl, USE=html, USE=whatever. The exherbo suggested dependencies just list the relevant packages. In other words, here you enable USE=html to get HTML output. With SDEPEND, you would --take dev-python/somerandomhtmllibrary. > > - lack of ability to express multiple packages required by a single > > feature, > > Eh? SDEPEND="my_feature? ( pkg1 pkg 2 )" SDEPEND didn't involve USE flags. If it did, we're back to square one. > > - lack of ability to express cross-feature dependencies, > > Clarify. This is a wee bit too vague for responding to ;) REQUIRED_USE. You don't have USE flags, you can't do that. > > - lack of ability to describe features provided by enabled packages, > > metadata.xml's local use description already covers that; in your > proposal above you lock in on use flags for the controlling of it > (which, presumably you'll abuse to get descriptions of) yet claim > it's not possible for ODEPEND (better name than SDEPEND :P). It didn't use USE flags. > > - necessity of implementing a new user interface parts to control > > the dependencies, > > Um... This is bullshit. Your proposal above is going to require a > lot more implementation, documentation of how this all is supposed to > work, and user ededucation for the weird scenarios where things don't > behave as expected, or they don't understand why changing use flag X, > results in the PM pulling in new packages (acting akin to -N), while > changing flag Y doesn't, and only does so/rebuilds via -N. > > That's not one of those things we can easily summarize in a UI; not > unless we want to extraordinarily verbose. While ODEPEND requires additional --take option, a way to list all possible packages which could be taken, teaching users why they are listed yet not pulled, how to pull and unpull them. > > - lack of backwards compatibility. > > This is a bit of a stretch; to be clear, you're proposing that the > depgraph changes in subtle/nasty ways on the fly under your scheme, > and that a PM supporting IUSE_RUNTIME vs one that doesn't, won't find > new and subtle ways to blow up the packages involved (specifically to > expose differing behaviour). It does that already. See 'man emerge', --dynamic-deps. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On Mon, 18 Jun 2012 19:42:55 -0700
Brian Harring wrote:
> Bleh; wish your attachment had been text/plain for inline
> commenting; pardon any mangling...
Sorry, forgot to change the type before sending.
> > 3. Defining dynamic SLOT groups
> > ---
> >
> > The list of supported dynamic SLOT groups should be declared
> > in profile `make.defaults` as ``DYNAMIC_SLOT_GROUPS`` variable. That
> > variable should contain whitespace-separated list of group names.
> >
> > For each group, the same file should have a variable named
> > ``DYNAMIC_SLOTS_`` followed by the group name. That variable should
> > list all possible dynamic SLOTs belonging to that group.
>
> This is USE_EXPAND machinery; you should clarify why it's not being
> reused here, nor treat explicitly as such.
I tried to avoid reusing USE flags partially since that could lead to
potential problems which I could miss. It's basically fine to use flags
here as long as we ensure that only one from a group is enabled for one
ebuild, and they are reused like the rest of the text states.
> Also, this gets fugly when one starts talking about individual pkgs
> that have their own slotting, rather than global patterns like
> python/multilib.
>
> Should consider that and address it...
Could you provide an example use case? I guess we could assume there
could be dyn. SLOTs/flags not mentioned in the global list, and that's
where developer has to explicitly express their relations.
> > 4. Defining supported SLOTs in an ebuild
> >
> >
> > An ebuild supporting building for multiple dynamic SLOTs has to
> > declare the supported slots using ``DYNAMIC_SLOTS`` variable. The
> > variable can be inherited from eclasses.
> >
> > For example, an ebuild supporting building for multiple Python ABIs
> > would declare (either explicitly or implicitly through an eclass)::
> >
> > DYNAMIC_SLOTS='py2.6 py2.7 py3.1 py3.2'
> >
> > which would mean that when the package is built, one of the
> > ``pyX.Y`` SLOTs must be used. As all of the listed SLOTs belong to
> > the same group, only of them may be used at a time.
> >
> > An ebuild may also declare dynamic SLOTs from multiple groups::
> >
> > DYNAMIC_SLOTS='py2.6 py2.7 lib32 lib64'
> >
> > In this case, both one of ``pyX.Y`` and ``libX`` SLOTs need to be
> > declared.
>
> The words "I'll implement that when hell freezes over" come to
> mind. That's a mess requiring the PM to know all potential values
> and do interpolation on the fly; you're expecting the PM to be far,
> far more intelligent then it can be, and the results won't be
> pleasant (not counting the joys of writing such a resolver mind you).
Doesn't the previous section exactly state where all possible values
are to be listed?
> Additionally, your notion breaks down if py3.3 supports lib64, but
> not lib32.
Doesn't sound like a likely case.
> If the groupings are treated as USE_EXPAND (even if a segregated
> group of it), you can abuse the same REQUIRED_USE machinery to
> specify the allowed pigeon holes/slots, including arbitrary group
> combinations.
>
> Still will be a bit harsh for the resolver I expect, but that's at
> least descriptive enough to handle the py3.3/lib64 scenario I
> mentioned, while being explicit data the PM can operate on (local to
> that ebuild) without having to do nastyness.
>
> Note also that if one just dropped your notion of reinventing the
> wheel, and reused REQUIRED_USE logic for slots... well, strikes me
> that gives the flexibility you desire while folding it into existing
> slot machinery. Haven't prototyped it, so may be cracktastic, but
> seems a bit more integrated than what you're proposing.
Agreed.
> > 5. Building the ebuild against chosen SLOTs
> > ---
> >
> > In ``pkg_*`` and ``src_*`` phases, the build environment is provided
> > with currently enabled dynamic SLOTs via variables named
> > ``DYNAMIC_SLOT_`` followed by dynamic SLOT group name. The ebuild
> > must use this variable to adjust the build process accordingly
> > which can be done either directly or via an eclass.
> >
> > For example, in an ebuild using dynamic SLOTs for Python ABIs, the
> > check may look like::
> >
> > case ${DYNAMIC_SLOT_PYTHON} in
> > py2.6)
> > # ...
> > ;;
> > py2.7)
> > # ...
> > ;;
> > # ...
> > esac
>
> For ebuilds where one can't reuse the same source (moreso, can't do
> the build of two different targets w/in that source, meaning you need
> two work trees), this breaks down- which I expect is common. That
> workflow needs to be non sucky for ebuild devs- so... sort that angle
> please.
Yes, argparse is a good example. I was still thinking how to handle
that. Probably will require conditionals in SRC_URI and so on, so
probably one more argument for USE_
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/graphviz: ChangeLog
On 06/19/2012 10:10 AM, Naohiro Aota wrote: Samuli Suominen writes: On 06/17/2012 10:12 AM, Naohiro Aota (naota) wrote: naota 12/06/17 07:12:19 Modified: ChangeLog Log: Add ~x86-fbsd. #419621 (Portage version: 2.2.0_alpha110/cvs/Linux x86_64) Revision ChangesPath 1.261media-gfx/graphviz/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/graphviz/ChangeLog?rev=1.261&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/graphviz/ChangeLog?rev=1.261&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/graphviz/ChangeLog?r1=1.260&r2=1.261 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/media-gfx/graphviz/ChangeLog,v retrieving revision 1.260 retrieving revision 1.261 diff -u -r1.260 -r1.261 --- ChangeLog 16 Jun 2012 16:39:58 - 1.260 +++ ChangeLog 17 Jun 2012 07:12:19 - 1.261 @@ -1,6 +1,9 @@ # ChangeLog for media-gfx/graphviz # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/media-gfx/graphviz/ChangeLog,v 1.260 2012/06/16 16:39:58 ssuominen Exp $ +# $Header: /var/cvsroot/gentoo-x86/media-gfx/graphviz/ChangeLog,v 1.261 2012/06/17 07:12:19 naota Exp $ + + 17 Jun 2012; Naohiro Aota graphviz-2.28.0.ebuild: + Add ~x86-fbsd. #419621 16 Jun 2012; Samuli Suominen graphviz-2.28.0.ebuild, metadata.xml: No change happened to the ebuild itself as it already had ~x86-fbsd (some faulty script?) It was my fault. I misunderstood bug #419621's intentions to be adding ~x86-fbsd to graphviz. hm, then, should I remove the ChangeLog entry? Well, this is so minor issue I won't be pursuing it in any way... but yes, the entry should be removed. All the best (in any case) - Samuli
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/graphviz: ChangeLog
Samuli Suominen writes: > On 06/17/2012 10:12 AM, Naohiro Aota (naota) wrote: > >> naota 12/06/17 07:12:19 >> >>Modified: ChangeLog >>Log: >>Add ~x86-fbsd. #419621 >> >>(Portage version: 2.2.0_alpha110/cvs/Linux x86_64) >> >> Revision ChangesPath >> 1.261media-gfx/graphviz/ChangeLog >> >> file : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/graphviz/ChangeLog?rev=1.261&view=markup >> plain: >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/graphviz/ChangeLog?rev=1.261&content-type=text/plain >> diff : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-gfx/graphviz/ChangeLog?r1=1.260&r2=1.261 >> >> Index: ChangeLog >> === >> RCS file: /var/cvsroot/gentoo-x86/media-gfx/graphviz/ChangeLog,v >> retrieving revision 1.260 >> retrieving revision 1.261 >> diff -u -r1.260 -r1.261 >> --- ChangeLog16 Jun 2012 16:39:58 - 1.260 >> +++ ChangeLog17 Jun 2012 07:12:19 - 1.261 >> @@ -1,6 +1,9 @@ >> # ChangeLog for media-gfx/graphviz >> # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 >> -# $Header: /var/cvsroot/gentoo-x86/media-gfx/graphviz/ChangeLog,v 1.260 >> 2012/06/16 16:39:58 ssuominen Exp $ >> +# $Header: /var/cvsroot/gentoo-x86/media-gfx/graphviz/ChangeLog,v 1.261 >> 2012/06/17 07:12:19 naota Exp $ >> + >> + 17 Jun 2012; Naohiro Aota graphviz-2.28.0.ebuild: >> + Add ~x86-fbsd. #419621 >> >> 16 Jun 2012; Samuli Suominen >> graphviz-2.28.0.ebuild, >> metadata.xml: >> >> >> >> > > No change happened to the ebuild itself as it already had ~x86-fbsd > (some faulty script?) It was my fault. I misunderstood bug #419621's intentions to be adding ~x86-fbsd to graphviz. hm, then, should I remove the ChangeLog entry? pgpIqp4cmtgU2.pgp Description: PGP signature
