[gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
My idea is to allow failing for some patches without breaking build at all. And, in parallel, to add groupping. How I imagine that: etc/portage/patches/app-cat/name/ | | - group_name/ | | | |- 01_foo.patch | |- 02_bar.patch | |- ... | |- 01_moo.patch |- 99_meow.patch Where every first-level piece (patch or group) in ```etc/portage/patches/app-cat/name/``` MAY tolerably fail (not causing die for emerge), but if one of the patches inside the group fails, then group MUST NOT be applied at all (and all previously applied patches from this group MUST be reversed). Any objections/approvals/suggestions? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
Dnia 2014-06-15, o godz. 16:06:57 Vadim A. Misbakh-Soloviov m...@mva.name napisał(a): My idea is to allow failing for some patches without breaking build at all. And, in parallel, to add groupping. How I imagine that: etc/portage/patches/app-cat/name/ | | - group_name/ | | | |- 01_foo.patch | |- 02_bar.patch | |- ... | |- 01_moo.patch |- 99_meow.patch Where every first-level piece (patch or group) in ```etc/portage/patches/app-cat/name/``` MAY tolerably fail (not causing die for emerge), but if one of the patches inside the group fails, then group MUST NOT be applied at all (and all previously applied patches from this group MUST be reversed). Just don't. Or more specifically: it's not worth the effort, the extra complexity, the confusion and the wholesale mess involved. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
Vadim A. Misbakh-Soloviov: My idea is to allow failing for some patches without breaking build at all. And, in parallel, to add groupping. How I imagine that: etc/portage/patches/app-cat/name/ | | - group_name/ | | | |- 01_foo.patch | |- 02_bar.patch | |- ... | |- 01_moo.patch |- 99_meow.patch Where every first-level piece (patch or group) in ```etc/portage/patches/app-cat/name/``` MAY tolerably fail (not causing die for emerge), but if one of the patches inside the group fails, then group MUST NOT be applied at all (and all previously applied patches from this group MUST be reversed). Any objections/approvals/suggestions? How does epatch know if I want a patch to cause || die or not? The only use case I see here is don't want to clean up old patches.
[gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc)
I debated where to post this, but the topic is fairly dev-oriented and has big long-term impact so I landed here. This really isn't organizational in nature. During the council meeting there was a bit of a philosophical debate over the proper role of EAPI vs implementing functions in eclasses. I felt that it was important enough to at least get more community input before we continue voting on features like user patching/etc which tend to favor an EAPI-based approach. I'll try to fairly frame the arguments, though I personally lean in the EAPI direction and I'll leave it to somebody else to fix my straw man. The Eclass argument goes like this: Eclasses already work in every PM. Half of what we're debating is already in eutils. Why move this code into the PM, where it has to be re-implemented everywhere? If anything we should be moving more PM functionality out and into eclasses where we can have competing implementations and more flexibility. The EAPI argument goes like this: Sure, you can have 14 different implementations of epatch which lets each maintainer use the one that makes the most sense. However, who wants to edit an ebuild which uses a bad epatch implementation and re-learn how to add a patch? Adding patches is a common thing, so why not have a standard way to do it? We can still have eclasses for one-offs. And how can you ever do something like user patches when they will only work if the maintainer cares to support them? I view this as not being unlike dealing with programs that encourage the use of Turing-complete configuration files. Sure, they give you a lot more power, but that power comes at a cost. Sendmail config files are a running joke, and if you want to control the niceness or ioniceness of an OpenRC service then you're going to have to read the script and possibly patch it. When there is no value in everybody doing things differently, why not just do them the same way? Besides, I think user-patches are a GREAT feature to have, and one I use all the time (without even thinking about it if a package with a patch gets rebuilt). As I said in the meeting, if we were selling Gentoo to make money, it would be the sort of feature that you'd advertise. Why make it hard to use such a distinctive advantage of a source-based distro? Since this month is the last one for this Council term as an added bonus you stack the next Council with folks who agree with you on this one... :) Rich
Re: [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc)
On Sun, 15 Jun 2014 07:00:15 -0400 Rich Freeman ri...@gentoo.org wrote: The Eclass argument goes like this: Eclasses already work in every PM. Half of what we're debating is already in eutils. Why move this code into the PM, where it has to be re-implemented everywhere? If anything we should be moving more PM functionality out and into eclasses where we can have competing implementations and more flexibility. The big problem with eclasses is that they're far too messy and complicated. Sure, you can *technically* express (say) ABI dependencies using a complicated eclass which translates them into a convoluted series of use dependencies, nested || dependencies etc (more or less correctly most of the time). But the package mangler is being given less information that way, which means it has to have all sorts of dodgy heuristics to deal with them, and can't give good error messages when it breaks. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
On Sun, 15 Jun 2014 16:06:57 +0700 Vadim A. Misbakh-Soloviov m...@mva.name wrote: My idea is to allow failing for some patches without breaking build at all. And, in parallel, to add groupping. [...] Any objections/approvals/suggestions? What are the use cases of this idea? What is its goal? In my use case, I've found or written patches with a permanent purpose; therefore, I'd like the patches to apply or die hard with a purpose. I can't imagine an use case where you don't want them to apply. Temporary backported patches (eg. from version 2) come to mind; it then becomes tricky to know whether it fails because it is the new version (2), or whether it is a version (2) in between that breaks. That would become a whole new feature request with specific directory, file or header syntaxes, which takes time to implement; at which point, one wonders if just (re)moving away the patch when you see it fail in the early src_prepare phase followed by a --resume is more favorable. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
Am Sonntag, 15. Juni 2014, 11:06:57 schrieb Vadim A. Misbakh-Soloviov: My idea is to allow failing for some patches without breaking build at all. Please No. It just generates a big mess. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc)
Dnia 2014-06-15, o godz. 07:00:15 Rich Freeman ri...@gentoo.org napisał(a): The Eclass argument goes like this: Eclasses already work in every PM. Half of what we're debating is already in eutils. Why move this code into the PM, where it has to be re-implemented everywhere? If anything we should be moving more PM functionality out and into eclasses where we can have competing implementations and more flexibility. I think this point is a bit tangential. While eclasses are the obvious way of having code common between package managers, I don't think sharing code should be an argument for putting something in an eclass. Please remember that you can create your own base repository without having 'gentoo' as master. Then, putting code in eclasses actually requires you to duplicate it -- unlike code in PM which is shared between all repos. Now, for the overall point. I think there are a few cases when you want something in the PM: 1. when it's a common thing to do that doesn't require repository- specific details like relying on some out-of-@system packages, 2. when it requires specific interaction with the package manager, 3. when it is required by some other PM-specific code. Keeping it 'internal' just means having duplicate code between PM and eclasses. I think the only debatable thing here is (1). If we ever decide that having common stuff in an eclass is feasible, we ought to move all the common stuff that's possible -- including econf, emake, possibly some install helpers. This may even have more benefits than that. For example, you would fit the implementation to specific system -- like 'gentoo' repository eclass would be fit for Gentoo-specific tools. Instead of putting requirements for a system in PMS and trying to fit PM and profiles together, we'd just use whatever the repository provides. Of course this brings another argument -- every single ebuild would have to source a specific eclass. For EAPI 6, I've focused on going the opposite way -- putting more commonly used stuff to EAPI so that many of eutils inherits could be removed. I don't have the numbers but I'd dare guess inheriting eutils everywhere does come with some overhead on metadata cache generation. As far as both eapply eapply_user are concerned, I believe they both belong to the group of commonly used functions, so they ought to go into PM wrt (1). Moreover, eapply_user pretty much requires you to provide a location for the patches -- and putting /etc/portage into an eclass is just wrong. Of course, we could try some new, fancy location but well... I'd rather keep it as-is and consider it PM-specific, so argument (2). And if put eapply_user anyway, argument (3) says we gotta add eapply as well, or otherwise we'll be using two similar functions all the time -- one in the PM, the other in the eclass. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Subslots: should they be bumped like SONAME or on any ABI changes?
On Sat, Jun 14, 2014 at 7:41 AM, Michał Górny mgo...@gentoo.org wrote: Hi, Some time ago we've got bug #510780 [1] asking us to bump subslot on LLVM even though the new version was ABI-compatible with previous one. It was because it introduced new APIs which applications could make use of. Since I believe this is a wider issue, I would like to know the opinion of our community about this. More specifically: do we want subslots to change only when backwards- incompatible ABI changes are done -- alike SONAME -- or whenever any ABI change is done? The problem seems a bit complex. I think subslot should only change with SONAME. Packages depending on a new API can use a versioned dependency to ensure the new API is available. I think this covers all of the cases and doesn't cause problems? Let me know if I've misunderstood something.
Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference
Steven J. Long: I'll see you when you get there, if you ever get there.. No improvements so far. I am going to hardmask sys-devel/crossdev, unless someone can explain why we are still in broken stage. More packages are popping up that randomly break. Recent failures were related to tc-getBUILD_CC. This isn't stable in any way. I'm not blaming anyone, but that's what hardmasking is for. A working solution was declined, so...
Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference
hasufell schrieb:
No improvements so far. I am going to hardmask sys-devel/crossdev,
unless someone can explain why we are still in broken stage.
More packages are popping up that randomly break. Recent failures were
related to tc-getBUILD_CC.
This isn't stable in any way. I'm not blaming anyone, but that's what
hardmasking is for. A working solution was declined, so...
If I understand correctly, it is not the crossdev package being present on
the system, but the generated toolchains that cause the trouble.
I think there are less intrusive options than hardmask, such as pkg_pretend()
check or blocking offending packages from cross-${CTARGET} category.
Best regards,
Chí-Thanh Christopher Nguyễn
[gentoo-dev] Auto-patching ebuilds themselves Was: Eclass vs EAPI For Utility Functions (Patching/etc)
Rich Freeman posted on Sun, 15 Jun 2014 07:00:15 -0400 as excerpted: Besides, I think user-patches are a GREAT feature to have, and one I use all the time (without even thinking about it if a package with a patch gets rebuilt). As I said in the meeting, if we were selling Gentoo to make money, it would be the sort of feature that you'd advertise. Why make it hard to use such a distinctive advantage of a source-based distro? Agreed with everything, but focusing on the above as a jump-off point for... A similarly great feature to have would be epatch-ebuild. Back when gentoo/kde was trying to dump IUSE=semantic-desktop[1], I was doing enough ebuild patching with enough churn in the ebuilds[2] that manual per-ebuild patching was simply no longer feasible. It can be noted that normal sources patching (as epatch) would NOT work here, at least not easily, because it was the ebuilds themselves that were forcing the various semantic-desktop related config options on and forcing dependencies to match, so it was the ebuilds themselves that needed that patched back out. I ended up with an /etc/portage/patches.ebuild that mirrored /etc/portage/patches in functionality, using a sync script that download-updated both the gentoo tree and the layman-managed overlays, then _automatically_ applied the patches from the patches.ebuild tree and redigested the ebuilds[3], then regenerating cache to account for the changes. The _automatic_ bit being critical as at that point I was handling enough of them that doing it manually would not have been fun. Talk about a feature worth advertising, the user-level ability to automatically live-patch ebuilds by simply dropping a patch in the appropriate location just like we do sources was and remains great, definitely something I'd love to see in the PMs at some point. =:^) As we've found with user-epatched sources, this should greatly simplify deployment of experimental patches. Just attach the patch to the bug and tell the user what directory to drop it in, and no more worries about having to tell users what to edit or how to do manual patching, in ordered to test a fix. =:^) --- [1] Dropping IUSE=semantic-desktop: Something I'm /ever/ so glad gentoo/ kde changed their minds on. =:^) [2] The ebuilds in question were from the gentoo/kde overlay, before they reached the tree. That overlay and the ebuilds in it get a *LOT* of churn! [3] Redigesting: As I run live-sources kde there were few source tarballs to redigest, only the ebuilds. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
Tom Wijsman posted on Sun, 15 Jun 2014 14:19:54 +0200 as excerpted: On Sun, 15 Jun 2014 16:06:57 +0700 Vadim A. Misbakh-Soloviov m...@mva.name wrote: My idea is to allow failing for some patches without breaking build at all. And, in parallel, to add groupping. [...] Any objections/approvals/suggestions? What are the use cases of this idea? What is its goal? In my use case, I've found or written patches with a permanent purpose; therefore, I'd like the patches to apply or die hard with a purpose. I can't imagine an use case where you don't want them to apply. Indeed. If the patches no longer apply, I want to know it so I can either clean them out or generate fresh patches that apply to the new code. So far you (OP) have unanimous rejection, but that may simply be because we don't see that use-case. So let's see the use-case first, and if that is agreed to be useful enough, there's still some change to either change opinion, or perhaps come up with a less objectionable way to support that use-case without the severe down sides of the current proposal. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-06-15 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2014-06-15 23h59 UTC. Removals: dev-perl/perl-PBS 2014-06-11 09:30:35 zlogene games-strategy/openxcom 2014-06-14 19:28:46 mr_bones_ media-plugins/vdr-noepgmenu 2014-06-15 08:21:41 hd_brummy Additions: dev-python/sphinx_rtd_theme 2014-06-09 02:27:45 bicatali dev-ruby/netrc 2014-06-09 18:08:29 graaff dev-ruby/delayer2014-06-11 07:39:01 naota www-client/qtweb2014-06-11 15:29:23 jer dev-python/pyoembed 2014-06-12 03:06:08 rafaelmartins www-apps/blohg-tumblelog2014-06-12 03:07:40 rafaelmartins dev-python/jaraco-utils 2014-06-12 03:48:48 patrick dev-python/more-itertools 2014-06-12 04:02:40 patrick dev-libs/libserialport 2014-06-12 19:56:28 vapier dev-python/pretty-yaml 2014-06-12 23:54:32 chutzpah net-libs/phodav 2014-06-13 12:05:09 dev-zero dev-python/django-haystack 2014-06-14 02:47:22 idella4 sci-libs/libsigrok 2014-06-14 02:47:41 vapier sci-libs/libsigrokdecode2014-06-14 05:59:11 vapier sci-electronics/sigrok-cli 2014-06-14 06:22:26 vapier sys-firmware/sigrok-firmware-fx2lafw2014-06-14 06:48:05 vapier sci-electronics/pulseview 2014-06-14 07:02:49 vapier dev-ruby/hashr 2014-06-14 12:03:34 mrueg games-strategy/openxcom 2014-06-14 16:15:27 maksbotan games-engines/openxcom 2014-06-14 19:33:21 mr_bones_ net-analyzer/icinga22014-06-15 19:49:46 prometheanfire dev-python/pyxenstore 2014-06-15 19:59:10 robbat2 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-perl/perl-PBS,removed,zlogene,2014-06-11 09:30:35 games-strategy/openxcom,removed,mr_bones_,2014-06-14 19:28:46 media-plugins/vdr-noepgmenu,removed,hd_brummy,2014-06-15 08:21:41 Added Packages: dev-python/sphinx_rtd_theme,added,bicatali,2014-06-09 02:27:45 dev-ruby/netrc,added,graaff,2014-06-09 18:08:29 dev-ruby/delayer,added,naota,2014-06-11 07:39:01 www-client/qtweb,added,jer,2014-06-11 15:29:23 dev-python/pyoembed,added,rafaelmartins,2014-06-12 03:06:08 www-apps/blohg-tumblelog,added,rafaelmartins,2014-06-12 03:07:40 dev-python/jaraco-utils,added,patrick,2014-06-12 03:48:48 dev-python/more-itertools,added,patrick,2014-06-12 04:02:40 dev-libs/libserialport,added,vapier,2014-06-12 19:56:28 dev-python/pretty-yaml,added,chutzpah,2014-06-12 23:54:32 net-libs/phodav,added,dev-zero,2014-06-13 12:05:09 dev-python/django-haystack,added,idella4,2014-06-14 02:47:22 sci-libs/libsigrok,added,vapier,2014-06-14 02:47:41 sci-libs/libsigrokdecode,added,vapier,2014-06-14 05:59:11 sci-electronics/sigrok-cli,added,vapier,2014-06-14 06:22:26 sys-firmware/sigrok-firmware-fx2lafw,added,vapier,2014-06-14 06:48:05 sci-electronics/pulseview,added,vapier,2014-06-14 07:02:49 dev-ruby/hashr,added,mrueg,2014-06-14 12:03:34 games-strategy/openxcom,added,maksbotan,2014-06-14 16:15:27 games-engines/openxcom,added,mr_bones_,2014-06-14 19:33:21 net-analyzer/icinga2,added,prometheanfire,2014-06-15 19:49:46 dev-python/pyxenstore,added,robbat2,2014-06-15 19:59:10 Done.
[gentoo-dev] Re: crossdev and multilib interference
On Sun, 15 Jun 2014 20:35:53 + hasufell hasuf...@gentoo.org wrote: Steven J. Long: I'll see you when you get there, if you ever get there.. No improvements so far. I am going to hardmask sys-devel/crossdev, unless someone can explain why we are still in broken stage. Do that and we'll have to take you out behind the woodshed. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
