Re: [gentoo-dev] [PATCH 2/5] Use explicit abi_* flags to select multilib targets.
On Sun, 27 Jan 2013 20:27:06 -0300 Alexis Ballier aball...@gentoo.org wrote: On Sun, 27 Jan 2013 23:46:06 +0100 Michał Górny mgo...@gentoo.org wrote: Alexis, Following your remark, I have redesigned the loop to use MULTILIB_ABIS list to order the ABIs. This should ensure the most valid replacement order. Great, that's better than what I had thought about Additionally, I have added an assertion to ensure that DEFAULT_ABI comes last in MULTILIB_ABIS list. I'm not sure it is a good idea: it is certainly safe, but this removes the flexibility not to build for the DEFAULT_ABI. Not sure if it's sane to do so or if there is any usecase either, but since get_all_abis ensures us DEFAULT_ABI is last I don't see a need to double check it here. Well, you are probably right. No point in being more strict than multilib.eclass. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] splashutils needs a maintainer
El lun, 28-01-2013 a las 00:25 +0100, Alex Legler escribió: On 27.01.2013 23:06, Pacho Ramos wrote: With spock retirement, splashutils became orphan. The problem is that it has a lot of unresolved bugs for a long time: https://bugs.gentoo.org/buglist.cgi?quicksearch=splashutilslist_id=1521218 that would need someone with more knowledge about it to maintain it (as I don't have splash on my systems for years). Also looks like splashutils is no more developed, but I don't know if we have a proper replacement for it in gentoo (most distributions are moving to plymouth, but I haven't tried if it works ok on Gentoo) We have it, it works (or at least worked). Someone would need to implement it in genkernel initrds though as at the moment only dracut can handle it. In terms of package maintenance, I took the package from aidecoe when he dropped it to avoid it getting removed. People seem to have found issues in there now and it could use a bump. As I cannot boot my systems using dracut initrds right now, feel free to take the package (and the openrc plugin for it) and fix/bump/do whatever with it. Then, looks like no alternative is in good shape on Gentoo. What is Sabayon using? They look to have plymouth ebuilds in their overlay (but not in for-gentoo one, then, it probably has some incompatibility Gentoo :/) signature.asc Description: This is a digitally signed message part
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
El lun, 28-01-2013 a las 14:37 +0800, Ben de Groot escribió:
On 28 January 2013 12:37, Mike Frysinger vap...@gentoo.org wrote:
On Sunday 27 January 2013 13:21:27 Pacho Ramos wrote:
The problem is that it doesn't work so well. If I have the following at
src_prepare (for example):
src_prepare() {
DOC_CONTENTS=You must create a symlink rom /etc/splash/tuxonice
to the theme you want tuxonice to use, e.g.: \n
# ln -sfn /etc/splash/emergence /etc/splash/tuxonice
\n
...
and I handle ${DOC_CONTENTS} with quotes, it will end writing that tabs
also in generated file as the contents of the variable will be put
as-is. On the other hand, if I don't put it between quotes
forcibly normalizing whitespace for all callers is wrong imo (as is sending
it
through `fmt`). if the caller gave you content to write, it should write
it.
if the caller didn't want tabs, it shouldn't have used it in the first
place.
-mike
I've started using this eclass, but with README files, not the variable,
because this is currently the only way I can make sure it honours my
formatting.
Couldn't it be covered if echo -e was used (even with fmt) and you,
then, control formatting with some of the sequences it allows (they are
shown in its man page)?
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] last rites: games-puzzle/kmagnet
# Michael Sterrett mr_bon...@gentoo.org (28 Jan 2013) # Doesn't work with newer KDE and upstream seems dead (bug #453756) # Masked for removal on 20130227 games-puzzle/kmagnet
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/abs-guide: metadata.xml ChangeLog
On 2013-01-27 Sun 15:06, Ryan Hill wrote: If you have some kind of problem with this, I suggest you change the default output of metagen. I just find it annoying to have duplicate info for herds under the maintainer tag since tools like euscan and other scripts take that to mean a package has a separate maintainer and herd. Anyway the docs mention that the maintainer tag is supposed to be used for individual maintainers besides herds, but I can see how that metagen help output can be confusing. Tim pgpe0YubCOQ43.pgp Description: PGP signature
Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree
Le samedi 26 janvier 2013 à 02:46 -0500, Mike Frysinger a écrit : On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote: It's not like libcap is a big dependency true, but not everyone needs this, nor can everyone leverage it (caps). it's a linux-centric implementation and is dependent upon filesystem support being available enabled. that doesn't entirely justify making it a USE flag (since the code already has runtime fallback logic for when the fs doesn't support things), but since the USE is low overhead and leverages logic that already has to be there, i have no problem keeping it. plus it defaults to on. hum, ok. and it's not like this is an attempt to make the system more secure by according just the privileges needed for apps to work as intended, right ? mmm that's exactly what this is If the USE flag must stay, how is it different that current caps USE flag ? It applies and not just enables support but is that relevant to the purpose at hand ? [...] In summary, USE=caps if for stripping down from all to the bare minimum caps while USE=filecaps should allow us to provide bare minimum required capabilities from the start. If so, maybe this could be the same USE flag ? I would understand if we wanted to keep it separated to avoid potential confusion about the actual impact on packages though. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splashutils needs a maintainer
On Mon, Jan 28, 2013 at 7:26 PM, Pacho Ramos pa...@gentoo.org wrote: El lun, 28-01-2013 a las 00:25 +0100, Alex Legler escribió: Then, looks like no alternative is in good shape on Gentoo. What is Sabayon using? They look to have plymouth ebuilds in their overlay (but not in for-gentoo one, then, it probably has some incompatibility Gentoo :/) Officially, we have always used fbsplash + splashutils. I have no experience with dracut/plymouth though. -- Fabio Erculiani
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/abs-guide: metadata.xml ChangeLog
On Mon, 28 Jan 2013 11:59:13 -0800 Tim Harder radher...@gentoo.org wrote: On 2013-01-27 Sun 15:06, Ryan Hill wrote: If you have some kind of problem with this, I suggest you change the default output of metagen. I just find it annoying to have duplicate info for herds under the maintainer tag since tools like euscan and other scripts take that to mean a package has a separate maintainer and herd. Anyway the docs mention that the maintainer tag is supposed to be used for individual maintainers besides herds, but I can see how that metagen help output can be confusing. Well I'm just happy to discover I've been misreading it for 6 years. I always thought it was annoying but required because of herds that had different mail aliases than the herd name (see video). So, thanks. We also had documentation in the developer handbook that was incorrect and conflicted with what repoman enforced for a while, but I see that's been removed. -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On Monday 28 January 2013 14:30:06 Pacho Ramos wrote:
El lun, 28-01-2013 a las 14:37 +0800, Ben de Groot escribió:
On 28 January 2013 12:37, Mike Frysinger wrote:
On Sunday 27 January 2013 13:21:27 Pacho Ramos wrote:
The problem is that it doesn't work so well. If I have the following
at src_prepare (for example):
src_prepare() {
DOC_CONTENTS=You must create a symlink rom
/etc/splash/tuxonice
to the theme you want tuxonice to use, e.g.: \n
# ln -sfn /etc/splash/emergence
/etc/splash/tuxonice \n
...
and I handle ${DOC_CONTENTS} with quotes, it will end writing that
tabs also in generated file as the contents of the variable will be
put as-is. On the other hand, if I don't put it between quotes
forcibly normalizing whitespace for all callers is wrong imo (as is
sending it through `fmt`). if the caller gave you content to write,
it should write it. if the caller didn't want tabs, it shouldn't have
used it in the first place.
I've started using this eclass, but with README files, not the variable,
because this is currently the only way I can make sure it honours my
formatting.
Couldn't it be covered if echo -e was used (even with fmt) and you,
then, control formatting with some of the sequences it allows (they are
shown in its man page)?
how is it better to require people to fill the string with \x20\n\t than to
respect what was given ? if people want to normalize whitespace themselves,
they could just as easily do the `echo` themselves.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On 29 January 2013 03:30, Pacho Ramos pa...@gentoo.org wrote: El lun, 28-01-2013 a las 14:37 +0800, Ben de Groot escribió: I've started using this eclass, but with README files, not the variable, because this is currently the only way I can make sure it honours my formatting. Couldn't it be covered if echo -e was used (even with fmt) and you, then, control formatting with some of the sequences it allows (they are shown in its man page)? No. The eclass should assume that DOC_CONTENTS is already correctly formatted. If you must, you can add a convenience function for people who do want reformatting, but this should NOT be the default. Please don't make this eclass harder to use than it needs to be. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
On Sun, 27 Jan 2013 00:26:38 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Just to keep everyone updated, ... FYI, the new 13.0 profiles are now all available in profiles.desc, for now all with status dev (i.e. repoman includes them only when you request developer profile checking). This means the procedure below is complete up to and including point 5) now. Please consider changing your profile symlink manually and testing the new profile tree. In case of problems, please file a bug and assign it to me (or tell me if I'm around). If all goes well, we'll continue in a week. A small bug in repoman turned up when testing the EAPI=5 profiles, and therefore we will wait for the next stable portage version before the 10.0 profiles are deprecated. So, another 3-4 weeks to go maybe. [The only alternative would be to require all devs to run at least ~arch portage, since the bug only affects repoman, not emerge.] To be honest, I don't think this is really a blocker to deprecating the old profiles, unless you're talking about other bug than the one I filed. That bug just caused repoman to error about unstable dependencies when flags were stable-masked. This just means that developers with old repoman won't be able to commit stable ebuilds using stable-masked flags. Note that using the old profiles workarounds the issue through having those flags completely masked and therefore devs having no repoman checks on their dependencies at all... -- Best regards, Michał Górny signature.asc Description: PGP signature
