Re: [gentoo-dev] rfc: empty directories in ${D}
On Sat, 31 Mar 2018 20:46:56 +0100 Andrey Utkin <andrey_ut...@gentoo.org> wrote: > Right, I am not aware why PMS has left this explicitly undefined. Because when we wrote the spec, Portage's actual behaviour on empty directories was extremely tricky to define and depended upon things like whether you were upgrading or reinstalling a package. -- Ciaran McCreesh
Re: [gentoo-dev] News Item: Portage Dynamic Deps
On Mon, 22 Jan 2018 11:28:21 +0100 "Andreas K. Huettel" <dilfri...@gentoo.org> wrote: > Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico: > > According to Gentoo policy, future ebuild dependency changes need > > to be accompanied by a revision bump in order to trigger rebuilds > > for users. Therefore, you should only need to use --changed-deps=y > > for a single deep @world update. After that, if you encounter > > installed packages with outdated dependencies in a future deep > > @world update, then you should report it as a bug. > > Did you come up with a solution how to handle eclass-generated > dependency changes then? > > I'd loathe to have to do identical revision bumps for, say, all perl- > module.eclass consumers... perl-cleaner is rather strong evidence that the Perl situation needs a major change anyway... -- Ciaran McCreesh
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change
On Wed, 10 Jan 2018 17:48:32 -0500 "Aaron W. Swenson" <titanof...@gentoo.org> wrote: > Modified a bit. This should show for anyone who has GnuCash installed. For anyone who has any version of GnuCash installed, either now or at any point in the future. (See the recent thread on expiring news items...) Are you sure you don't just want to target this at people who have the old version installed, instead? -- Ciaran McCreesh
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change
On Wed, 10 Jan 2018 19:35:52 +0100 Kristian Fiskerstrand <k...@gentoo.org> wrote: > On 01/10/2018 07:31 PM, Aaron W. Swenson wrote: > > Display-If-Installed: >=app-office/gnucash-2.7.0 > > And we might want to display it before users actually upgrades if it > is for backing up an auto migrated change? Yes, this header is backwards. It's a message to be displayed to users who have the old version, not a message to be displayed to users who install the new version for the first time ever and who have never used the old version. -- Ciaran McCreesh
Re: [gentoo-dev] Re: Deleting old news items
On Sat, 6 Jan 2018 08:18:19 -0500 kuzetsa <kuze...@gmail.com> wrote: > On 01/06/2018 05:05 AM, Ulrich Mueller wrote: > >>>>>> On Sat, 6 Jan 2018, Duncan wrote: > >> $ equery b news.eselect > >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) > >> So in that case it's not the PM, but eselect. > > In fact, it is the PM that would do the filtering, before filling > > the list of unread news items > > in /var/lib/gentoo/news/news-gentoo.read. > > > > Filtering in eselect news would be problematic: Obtaining the list > > of items with "eselect news list" and e.g. reading them with > > "eselect news read" are issued as separate commands, which requires > > that the list of valid items does not change. However, time-based > > filtering could cause a race condition, like an item expiring > > between execution of the two commands. > > The race condition could be addressed by issuing a warning > at or around the time when expirations occur (midnight), > with or without detecting specific expirations which may > have occurred: How accurate is "around"? Obviously we'd need to introduce a user configuration option so different users could set appropriate values for their needs. Seriously though, all this complexity is just highlighting that dates are a really bad way of deciding when a news item should expire, and that if we need anything, it's more Display-If conditions. -- Ciaran McCreesh
Re: [gentoo-dev] Deleting old news items
On Wed, 3 Jan 2018 12:23:33 +0100 Kristian Fiskerstrand <k...@gentoo.org> wrote: > Do we necessarily need to do even that? A package manager could have a > feature to mask based on other heuristics without changing the format, > e.g all messages from before X, presumably with a switch to show Package manglers having to use heuristics when explicit information could easily be provided by developers but isn't is the source of at least 27.4% of Gentoo's problems. -- Ciaran McCreesh
Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon
On Fri, 8 Sep 2017 11:10:54 -0500 Gordon Pettey <petteyg...@gmail.com> wrote: > And this is all irrelevant since the copyright applies to the > software, not the location you obtain it from. Nobody commits > copyright infringement by buying a used book from their neighbour > instead of buying it at Half Price Books. > Distribution licenses are another thing, but if the original SRC_URI > from the ebuild wasn't RESTICT="fetch", what makes anybody think that > would suddenly change with a new SRC_URI? Are you a lawyer, and does this constitute legal advice? I ask, because the lawyers I've spoken to about a similar issue seemed to think it wasn't that simple. -- Ciaran McCreesh
Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon
On Sat, 9 Sep 2017 03:56:38 +1200 Kent Fredric <ken...@gentoo.org> wrote: > > >> Sir, please see my above comment about building ballistic > > >> missiles. It may be important for the Gentoo Foundation to add a > > >> disclaimer similar to the one I mentioned. I would hate for the > > >> Foundation or any of its administrators or contributors to be > > >> found guilty of aiding and abetting terrorists. > > > > > > Yeah. Stop trolling, please. > > > > > > > I am being completely serious. You can find such a clause in the > > iTunes license. > > > > If it seems ridiculous please reconsider the subject in question. > > I'm not sure how enforceable that clause is as a License. Until recently, there was a clause in the Nauty licence prohibiting use in "military applications". This was sufficient for the highly paid lawyers who looked at it to recommend not redistributing Nauty as part of the GAP computer algebra system, because computer algebra could conceivably be used for blowing stuff up. -- Ciaran McCreesh
Re: [gentoo-dev] Re: [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip
On Fri, 08 Sep 2017 14:54:10 +0200 Michał Górny <mgo...@gentoo.org> wrote: > W dniu pią, 08.09.2017 o godzinie 12∶48 +, użytkownik Martin Vaeth > napisał: > > Michał Górny <mgo...@gentoo.org> wrote: > > > +# 1.2b-alpha4 -> 1 . 2 '' b - alpha '' 4 > > > > Is this only to explain the syntax or are there plans to > > extend the allowed versions for pms? > > It only explains how the functions parse stuff (except for ver_test > which uses PMS rules). They are by definition supposed to work with > random upstream versions. This sounds like the sort of thing that could go horribly wrong... I didn't design versionator to work with arbitrary messy stuff since the main use is in manipulating Gentoo PV versions. Where are these other versions coming from? -- Ciaran McCreesh
Re: [gentoo-dev] [PATCH v3] eclass/kernel-2.eclass: Remove use of tr in global scope
On Thu, 07 Sep 2017 07:42:31 +0200 Michał Górny <mgo...@gentoo.org> wrote: > >+if [[ "${EAPI}" -lt 6 ]]; then > > EAPI is not a number. The next one we'll call gray-grizzly just to > prove the point. Careful, you're turning into me. -- Ciaran McCreesh
Re: [gentoo-dev] vim-syntax USE flag
On Sat, 22 Jul 2017 16:27:39 -0400 Mike Gilbert <flop...@gentoo.org> wrote: > Packages currently handle installation of vim syntax support files > inconsistently. Some builds install the files if the "vim-syntax" USE > flag is enabled, while others install them unconditionally. > > Do these files fall into the "small text files" category for > unconditional installation? If so, we should probably phase out the > vim-syntax USE flag. > > If we want to keep the USE flag, I would suggest documenting a global > policy regarding its use. Should that live in the devmanual? Or maybe > the Vim project page? One potential issue is help files: any Vim plugin that comes with documentation needs a little script (which requires Vim to be installed) to be run in pkg_postinst. -- Ciaran McCreesh
Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds
On Mon, 10 Jul 2017 18:14:23 -0700 Raymond Jennings <shent...@gmail.com> wrote: > If I may ask, does anyone have any profiling information one way or > the other to shed light on the situation? Paludis does complete dependency and unused package tracking for everything by default. Any performance difficulties are implementation-related, not a fundamental problem. -- Ciaran McCreesh
Re: [gentoo-dev] Sets vs Meta ebuilds
On Mon, 10 Jul 2017 17:21:42 -0400 Ian Stakenvicius <a...@gentoo.org> wrote: > On 10/07/17 04:47 PM, William L. Thomson Jr. wrote: > > On Mon, 10 Jul 2017 15:36:11 -0500 > > Ben Kohler <bkoh...@gmail.com> wrote: > >> > >> If you want dependencies checked, use the correct option which > >> checks them. This takes significantly longer than -C, as it's > >> significantly more complex to check for. > >> > >> As far as I can tell, you are literally asking for -C to behave > >> like -c, when you could just be using -c instead. > > > > No I simply want warnings like that exist for profiles and set > > packages. > > > > Also more information when attempting to remove a package that is > > not removed. > > > > OK, well, as Ben said it's not feasible to make -C act like -c due to > the performance hit involved and due to the purpose of the command > itself. Have you profiled this? It shouldn't be slow if implemented correctly. -- Ciaran McCreesh
Re: [gentoo-dev] Sets vs Meta ebuilds
On Tue, 11 Jul 2017 00:24:10 +0200 Michał Górny <mgo...@gentoo.org> wrote: > William, I'm not sure if you're aware of how package managers work but > checking reverse dependencies of a package takes significant amount of > time. Changing -C to do that would be a serious performance > regression. Which would result in users requesting yet another option > to disable this. Eh, that's a Portage performance problem, not a package manager performance problem. -- Ciaran McCreesh
Re: [gentoo-dev] Re: Sets vs Meta ebuilds
On Sat, 8 Jul 2017 19:58:13 -0400 "William L. Thomson Jr." <wlt...@o-sinc.com> wrote: > On Sun, 9 Jul 2017 00:49:57 +0100 > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > On Sat, 8 Jul 2017 19:39:33 -0400 > > "William L. Thomson Jr." <wlt...@o-sinc.com> wrote: > > > The two ways are not the same, and there is a reason sets exist in > > > the first place. People seem to be over looking that fact. I did > > > not add sets. They are not new. I am simply trying to expand > > > their use. > > > > Sets exist because people keep saying "let's have sets!" without > > agreeing on what sets actually are or how they are to be used. > > Do they need to agree? Isn't Gentoo about choice? Maybe your use of > sets is different from mine. Is that not acceptable to have choice? Well yes, they do need to agree, because otherwise when two different developers put sets in a profile expecting different effects, then at least two developers are going to end up confused, disappointed, and quite probably breaking user systems. -- Ciaran McCreesh
Re: [gentoo-dev] Re: Sets vs Meta ebuilds
On Sat, 8 Jul 2017 19:39:33 -0400 "William L. Thomson Jr." <wlt...@o-sinc.com> wrote: > The two ways are not the same, and there is a reason sets exist in the > first place. People seem to be over looking that fact. I did not add > sets. They are not new. I am simply trying to expand their use. Sets exist because people keep saying "let's have sets!" without agreeing on what sets actually are or how they are to be used. Sets remain half-baked because it turns out they don't make consistent sense in different contexts when you give them a non-superficial amount of thought. -- Ciaran McCreesh
Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints
On Sat, 8 Jul 2017 16:39:29 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > > As much as I hate the weird || ( use ? ( ) ) and empty block rules, > > it would be worse to have them apply in some situations but not > > others. > > Indeed, makes sense. Would it also make sense to have some more > logical meaning in a future EAPI ? I mean, in every context I've ever > seen, applying a rule to the empty set is the neutral of that rule, > so that it preserves associativity. > That'd mean: || ( ) is false, && ( ) is true, ^^ ( ) is false, ?? ( ) > is false. The sensible thing to do is ban it, and additionally ban use? ( ) inside || and ^^ (if we've not done that already...). -- Ciaran McCreesh
Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints
On Sat, 8 Jul 2017 16:14:09 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > On Sat, 8 Jul 2017 13:01:39 +0100 > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > On Sat, 8 Jul 2017 13:49:56 +0200 > > Alexis Ballier <aball...@gentoo.org> wrote: > > > On Sat, 8 Jul 2017 12:26:59 +0200 > > > Ulrich Mueller <u...@gentoo.org> wrote: > > > > | * An any-of group (||) evaluates to true if at least one of > > > > the | items in it evaluates to true. > > > > | * An exactly-one-of group (^^) evaluates to true if exactly > > > > one of | the items in it evaluates to true, and all the > > > > remaining items | evaluate to false. > > > > | * An at-most-one-of group (??) evaluates to true if at most > > > > one of | the items in it evaluates to true. > > > > > > > > It should be added that any empty group (|| or ^^ or ??) > > > > evalutates to true, because that's what PMS specifies: > > > > https://projects.gentoo.org/pms/6/pms.html#x1-780008.2 > > > > > > A bit OT, but that is *definitely* counter intuitive. What's the > > > rationale and usecase behind this ? > > > > Annoying special cases like || ( foo? ( ... ) bar? ( ... ) ) . The > > original reason was that old versions of Portage would simply remove > > unmet "flag? ( )" blocks internally. It was kept in EAPI 0 because > > stuff in the tree used it back then. > > Wasn't REQUIRED_USE something completely new with no prior usage in > EAPI 3 ? Yes, but the spec defines dependency-like structures and their meanings once and consistently, rather than all over the place and inconsistently. As much as I hate the weird || ( use ? ( ) ) and empty block rules, it would be worse to have them apply in some situations but not others. -- Ciaran McCreesh
Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints
On Sat, 8 Jul 2017 13:49:56 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > On Sat, 8 Jul 2017 12:26:59 +0200 > Ulrich Mueller <u...@gentoo.org> wrote: > > | * An any-of group (||) evaluates to true if at least one of the > > | items in it evaluates to true. > > | * An exactly-one-of group (^^) evaluates to true if exactly one of > > | the items in it evaluates to true, and all the remaining items > > | evaluate to false. > > | * An at-most-one-of group (??) evaluates to true if at most one of > > | the items in it evaluates to true. > > > > It should be added that any empty group (|| or ^^ or ??) evalutates > > to true, because that's what PMS specifies: > > https://projects.gentoo.org/pms/6/pms.html#x1-780008.2 > > A bit OT, but that is *definitely* counter intuitive. What's the > rationale and usecase behind this ? Annoying special cases like || ( foo? ( ... ) bar? ( ... ) ) . The original reason was that old versions of Portage would simply remove unmet "flag? ( )" blocks internally. It was kept in EAPI 0 because stuff in the tree used it back then. -- Ciaran McCreesh
Re: [gentoo-dev] Sets vs Meta ebuilds
On Fri, 7 Jul 2017 21:38:31 +0100 James Le Cuirot <ch...@gentoo.org> wrote: > On Fri, 7 Jul 2017 12:48:04 -0400 > NP-Hardass <np-hard...@gentoo.org> wrote: > > There is actually a huge functional difference between the two that > > you are missing here. A meta package defines its dependencies in > > full dependency syntax. This means you can specify versions, USE > > flag dependencies, make packages dependent on USE flags, etc. A > > package set is just a list of packages (potentially constrained by > > version. TTBOMK, there is no inclusion of any USE flag > > functionality in sets. Additionally, let's say you have a more > > complicated dependency like || ( A B ), I don't think there is a > > way to describe that in a package set at all. > > Actually you can specify basic USE dependencies in sets. You can also > specify SLOTs. For example, this is valid. > > media-libs/tiff:3[abi_x86_32,jpeg,zlib,-cxx] And this is one of many reasons "sets in profiles" isn't going to work: we don't really know what most of this stuff means... -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Thu, 15 Jun 2017 19:30:02 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > On Thu, 15 Jun 2017 18:04:35 +0100 > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > On Thu, 15 Jun 2017 18:55:45 +0200 > > Alexis Ballier <aball...@gentoo.org> wrote: > > > The guarantee comes from the fact that the output is always in the > > > space of all possible inputs from the user. So, if some output > > > will kill a kitten, so does some input. > > > > USE=minimal > > USE=mips > > USE=-ssl > > > > So what? So, if the aim of this solution is to make things better for the user, what are you doing to establish that this will make things better for the user instead of recommending something awful? -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Thu, 15 Jun 2017 18:55:45 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > The guarantee comes from the fact that the output is always in the > space of all possible inputs from the user. So, if some output will > kill a kitten, so does some input. USE=minimal USE=mips USE=-ssl -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Thu, 15 Jun 2017 18:37:16 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > > So you're saying that at the end of this, there's an ENFORCED_USE > > solver that spits out some answer that may or may not be in any way > > a sane solution to the conflict. > > > > I don't see how that's helpful to a user. > > Define sane. > The definition of the solver is made to change the least possible of > the inputs and is completely and easily predictable by the person > writing the constraint. That is something I would call sane. The problem is not just writing a resolver that spits out a valid output. The problem is writing a resolver which will never go and uninstall bash as a result of unintended combinations of inputs (which Portage used to do, but there's now a special exception for system packages, so it will only occasionally unexpectedly uninstall critical packages that aren't explicitly in system due to virtuals instead). This is *hard*. A bad suggestion to the user is worse than no suggestion at all. Unless you can safely determine that there aren't any unintended consequences of your rule, the focus needs to be on producing good error messages so the user can figure the problem out, not on producing bad solutions that will confuse things even more. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Thu, 15 Jun 2017 18:30:10 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > On Thu, 15 Jun 2017 17:22:26 +0100 > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > On Thu, 15 Jun 2017 18:19:04 +0200 > > Alexis Ballier <aball...@gentoo.org> wrote: > > > On Thu, 15 Jun 2017 17:13:57 +0100 > > > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > > > On Thu, 15 Jun 2017 18:07:00 +0200 > > > > Alexis Ballier <aball...@gentoo.org> wrote: > > > > > > The best way to convince me is through valid > > > > > > examples. > > > > > > > > > > It is also easier to be convinced when you try to understand > > > > > and ask for clarifications instead of just rejecting without > > > > > thinking :) > > > > > > > > The problem with this entire proposal is that it's still in > > > > "well I can't think of how it could possibly go wrong" > > > > territory. We need a formal proof that it's sound. History has > > > > shown that if something can be abused by Gentoo developers, it > > > > will be abused... > > > > > > Had you read the thread you would have noticed that I provided an > > > algorithm giving sufficient conditions for the solver to work. > > > That is, if developers pay attention to repoman warnings/errors, > > > it will never fail. Obviously, since we're still in the SAT > > > space, you can ignore the errors and make it fail, but it'll > > > never be worse than what we currently have. > > > > You have shown that you produce a solution, not the solution that's > > actually wanted. > > Since 'wanted' is still undefined, I'd say it produces the defined > solution and you can adapt to the definition to get what you want. So you're saying that at the end of this, there's an ENFORCED_USE solver that spits out some answer that may or may not be in any way a sane solution to the conflict. I don't see how that's helpful to a user. -- Ciaran mcCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Thu, 15 Jun 2017 18:19:04 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > On Thu, 15 Jun 2017 17:13:57 +0100 > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > On Thu, 15 Jun 2017 18:07:00 +0200 > > Alexis Ballier <aball...@gentoo.org> wrote: > > > > The best way to convince me is through valid examples. > > > > > > It is also easier to be convinced when you try to understand and > > > ask for clarifications instead of just rejecting without > > > thinking :) > > > > The problem with this entire proposal is that it's still in "well I > > can't think of how it could possibly go wrong" territory. We need a > > formal proof that it's sound. History has shown that if something > > can be abused by Gentoo developers, it will be abused... > > Had you read the thread you would have noticed that I provided an > algorithm giving sufficient conditions for the solver to work. That > is, if developers pay attention to repoman warnings/errors, it will > never fail. Obviously, since we're still in the SAT space, you can > ignore the errors and make it fail, but it'll never be worse than what > we currently have. You have shown that you produce a solution, not the solution that's actually wanted. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Thu, 15 Jun 2017 18:07:00 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > > The best way to convince me is through valid examples. > > It is also easier to be convinced when you try to understand and ask > for clarifications instead of just rejecting without thinking :) The problem with this entire proposal is that it's still in "well I can't think of how it could possibly go wrong" territory. We need a formal proof that it's sound. History has shown that if something can be abused by Gentoo developers, it will be abused... -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Mon, 05 Jun 2017 20:10:12 +0200 Michał Górny <mgo...@gentoo.org> wrote: > I'm sure Ciaran will love to elaborate ;-). It's doomed. Even if you get it to work, which you won't, it won't survive ten seconds contact with the enemy. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] NeoVim and vim-syntax
On Fri, 2 Jun 2017 15:34:19 -0400 "Walter Dnes" <waltd...@waltdnes.org> wrote: > On Fri, Jun 02, 2017 at 01:14:31PM +1200, Kent Fredric wrote > > On Thu, 1 Jun 2017 09:38:01 -0400 > > "Walter Dnes" <waltd...@waltdnes.org> wrote: > > > > > As mentioned elsewhere, what happens when two or three other > > > people do their own forks? Plugin 1 works with vim A and B but > > > not C or D. Plugin 2 works with vim A and C and D but not B. The > > > number of directories could potentially be 2^N where N is the > > > number of forks. And who's going to do the necessary testing > > > across multiple versions? And remember that each minor version > > > bump of any of the forks could render another fork's plugin > > > incompatable. This is a classic "moving target". The only way > > > that works is to have each fork look after their own copies of > > > plugins. > > > > If and when that happens: > > It already has happened. Compare /usr/portage/app-editors against > http://texteditors.org/cgi-bin/wiki.pl?ViFamily Portage has... > > * elvis > * levee > * nvi > * vi > * vim > * vis > > ...not to mention neovim, which doesn't show up on texteditors.org. And none of the rest of those are Vim compatible, or support Vim's scripting language. NeoVim is the only one that does, and only because it's effectively a fork. > This would require a multi-dimensional array of approx 7 packages > (today) versus however many ebuilds are currently in Portage for each > editor. Do I see any volunteers for compatibility testing for all > current and future VI-family editors and plugins on all current and > future ebuilds on all arches (small and large endian) and various USE > flags? You appear to be confusing vi and vim. -- Ciaran McCreesh
Re: [gentoo-dev] Re: [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Fri, 2 Jun 2017 14:56:42 + (UTC) Martin Vaeth <mar...@mvath.de> wrote: > Most examples mentioned earlier were actually 2SAT, i.e., > they are only of the form foo? ( bar ) (possibly with negations) > or can be easily reduced to that. E.g. > ^^ ( foo bar ) > foo? ( !bar graulty bazola ) > can be rewritten as 2 or 3 2SAT-clauses as above, respectively. > > For 2SAT, there are linear time algorithms. You're getting the encoding wrong. "foo? ( bar )" does not encode as "( !foo \/ bar )", because that would permit the solver to turn on bar even if there is no need to do so. Good luck figuring out how to encode grounding in SAT... -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] NeoVim and vim-syntax
On Thu, 1 Jun 2017 09:38:01 -0400 "Walter Dnes" <waltd...@waltdnes.org> wrote: > On Wed, May 31, 2017 at 11:54:59PM +0100, Ciaran McCreesh wrote > > - Have a separate anyvimishthing directory, and make both vim and > > neovim look there, and only make plugins that have been tested to > > work with both install to that directory. > > As mentioned elsewhere, what happens when two or three other people > do their own forks? Nothing, unless those forks obtain large user bases, and then the issue gets revisited. This is unlikely to happen. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] NeoVim and vim-syntax
On Thu, 01 Jun 2017 07:00:30 +0200 Michał Górny <mgo...@gentoo.org> wrote: > > - Have a separate anyvimishthing directory, and make both vim and > > neovim look there, and only make plugins that have been tested to > > work with both install to that directory. > > ...and then vimthreesome for things that work with three vim > implementations? If that ever happens, which is fairly unlikely, then revisit the problem then, rather than adding unnecessary complexity now just in case. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] NeoVim and vim-syntax
On Thu, 01 Jun 2017 02:32:24 +0700 "Vadim A. Misbakh-Soloviov" <gen...@mva.name> wrote: > - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all > the installed files > > - patching NeoVim source to include Vim's runtimedirs (incl. "after" > dir), // NeoVim upstream highly disagree with such way, if any > > - patching VIMRUNTIME environment variable, > > - making a wrapper, > > - rewrite all the existing ebuilds to take nvim into account and > force all newcomers to also take it, > > - symlinking a directory, > // mostly bad way, since opposite plugin compatibility is not > garanteed and users can install nvim-only plugins in the future > > - making postinst hook to regenerate content of NeoVim's > site-directory (maybe, by symlinking installed vim modules there) > > or even: > > - making eselect module for user to rule that. - Have a separate anyvimishthing directory, and make both vim and neovim look there, and only make plugins that have been tested to work with both install to that directory. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Wed, 31 May 2017 21:02:24 +0200 Michał Górny <mgo...@gentoo.org> wrote: > No, it can't. That's the whole point. The algorithm must be defined so > that it is always predictable independently of order So what's this mysterious algorithm then? -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Wed, 31 May 2017 09:35:04 +0200 Michał Górny <mgo...@gentoo.org> wrote: > On śro, 2017-05-31 at 08:24 +0100, Ciaran McCreesh wrote: > > On Wed, 31 May 2017 08:55:17 +0200 > > Michał Górny <mgo...@gentoo.org> wrote: > > > For example: > > > > > > foo? ( bar ) > > > > > > would mean 'if you have USE=foo, then USE=bar is enabled as > > > well'. > > > > What about "if bar cannot be enabled, then turn foo off"? > > Not expressible. The best you can do is 'if bar is disabled, ...' This is the kind of thing that gets very messy when a user wants ssl enabled, and has to enable either openssl or libressl, and they're on a profile where openssl is masked but the ebuild writer prefers that option... -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Wed, 31 May 2017 08:55:17 +0200 Michał Górny <mgo...@gentoo.org> wrote: > For example: > > foo? ( bar ) > > would mean 'if you have USE=foo, then USE=bar is enabled as well'. What about "if bar cannot be enabled, then turn foo off"? -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Tue, 30 May 2017 10:46:54 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > On Tue, 30 May 2017 09:22:45 +0100 > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > On Tue, 30 May 2017 09:42:45 +0200 > > Alexis Ballier <aball...@gentoo.org> wrote: > > > Oh crap, this requires to solve SAT. > > > > The main problem would not be solving SAT, in this case. The problem > > is providing the right answer when not enough information is given. > > Spitting out a resolution which satisfies every dependency isn't > > typically that difficult. Spitting out a resolution which doesn't > > just turn off all your use flags and uninstall most of your programs > > is the hard part. > > I don't really understand here: Assuming the formula is reduced where > user-set useflags and profile-masked/forced ones are already assigned > their true/false values, this leaves a formula with variables where > changing any of those won't turn off (or on) anything you didn't want. > If you can solve SAT on this reduced instance then you're safe, aren't > you ? First problem: encoding "don't change this from its current setting unless you have a reason to do so" is an utter pain in SAT. There are other models like ASP that can just about get around this, but expressing it properly is best done by just writing your own solver. Remember that you have to allow the solver to toggle some flags, so you can't just lock everything, but at the same time, you don't want the solver to randomly toggle a flag that isn't specified by the user or the profile, unless it absolutely has a good reason to do so. Second problem: a solver will spit out an arbitrary solution. If the user then runs it again, there's no guarantee that it will spit out the same arbitrary solution. That can be addressed by the right choice of restart policies and tiebreaking etc if you're prepared to muck around with the solver enough. But even if you do, suppose the user thinks "yes, that's almost fine, but let me change one other thing" (or if the install fails half-way through and the user tries to carry on after fixing it). The solver will then spit out a totally different arbitrary solution that looks nothing like the first one. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Tue, 30 May 2017 09:42:45 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > Oh crap, this requires to solve SAT. The main problem would not be solving SAT, in this case. The problem is providing the right answer when not enough information is given. Spitting out a resolution which satisfies every dependency isn't typically that difficult. Spitting out a resolution which doesn't just turn off all your use flags and uninstall most of your programs is the hard part. > Not hard as in you need a Ph.D. in algorithms to solve it but the > kind of hardness almost every cryptographic algorithm used today, and > in the foreseeable future, relies on. Hrm, you're a bit off, there. SAT solving in practice isn't usually that bad unless either your inputs are huge or they're deliberately crafted to be ultra-nasty. Being NP-complete just means that instances that will hit exponential behaviour exist, not that those instances will occur in the application area you care about. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Tue, 30 May 2017 00:01:16 +0200 Ulrich Mueller <u...@gentoo.org> wrote: > >>>>> On Mon, 29 May 2017, Michał Górny wrote: > > On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote: > >> Can you provide an efficient algorithm for the above syntax? That > >> is, given a set of +/- useflags forced by user, output the set of > >> effective useflags (or a rant if it is inconsistent). > > > I'd rather leave that to people who are good with algorithms. I find > > the whole thing scary but I don't really see a sane alternative > > here. Worst case, we have to figure out some arbitrary limitations > > to keep things sane. > > IMHO the sanest alternative would be to restrict the syntax to USE > conditional forms which have an obvious solution. One of the many > problems of REQUIRED_USE is that it sometimes requires solving a > Zebra Puzzle. Solving zebra puzzles isn't really that bad in practice most of the time. The tricky bit is finding the *right* solution, given poor input data that doesn't really let you evaluate what right is. As a simple example, in the olden days, the most obvious and shortest answer to fixing Gnome resolution errors was to set USE=mips because that disabled a whole load of browser dependencies... -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Mon, 29 May 2017 23:23:55 +0200 Michał Górny <mgo...@gentoo.org> wrote: > > Can you provide an efficient algorithm for the above syntax? > > That is, given a set of +/- useflags forced by user, output the set > > of effective useflags (or a rant if it is inconsistent). > > I'd rather leave that to people who are good with algorithms. I find > the whole thing scary but I don't really see a sane alternative here. > Worst case, we have to figure out some arbitrary limitations to keep > things sane. That bit is NP-complete by an easy reduction from SAT. That isn't necessarily a problem, because resolution isn't even in NP yet we're still managing to spit out decent answers most of the time. Rather, the difficulty lies in spitting out a *good* solution to the problem from a user's perspective, and that's something that can't be done without extremely high quality inputs. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Mon, 29 May 2017 21:42:33 +0200 Michał Górny <mgo...@gentoo.org> wrote: > On pon, 2017-05-29 at 20:24 +0100, Ciaran McCreesh wrote: > > On Mon, 29 May 2017 17:33:13 +0200 > > Michał Górny <mgo...@gentoo.org> wrote: > > > For a long time we seem to be missing appropriate tools to handle > > > USE flag constraints efficiently. EAPI 4 brought REQUIRED_USE but > > > all things considered, it has proven to be far from an optimal > > > solution. I would therefore like to discuss adding a better tool > > > to amend or replace it, to allow for automated handling of USE > > > flag constraints. > > > > REQUIRED_USE's problems all come from it being thrown in at the last > > minute without any testing of either the user experience or the > > feasibility of its implementation. Have you implemented a prototype > > to show that you can actually fix those problems? > > I tend to RFC before starting the implementation. Saves effort. Not the implementation. A prototype implementation. As we saw from REQUIRED_USE, it really doesn't save effort to spend time specifying something that can't even remotely work... -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Mon, 29 May 2017 17:33:13 +0200 Michał Górny <mgo...@gentoo.org> wrote: > For a long time we seem to be missing appropriate tools to handle USE > flag constraints efficiently. EAPI 4 brought REQUIRED_USE but all > things considered, it has proven to be far from an optimal solution. > I would therefore like to discuss adding a better tool to amend or > replace it, to allow for automated handling of USE flag constraints. REQUIRED_USE's problems all come from it being thrown in at the last minute without any testing of either the user experience or the feasibility of its implementation. Have you implemented a prototype to show that you can actually fix those problems? -- Ciaran McCreesh
Re: [gentoo-dev] Reverse use of Python/Ruby versions
On Tue, 11 Apr 2017 02:31:54 +0700 "Vadim A. Misbakh-Soloviov" <gen...@mva.name> wrote: > > If Java can do it, so can others. > > And here I come with my 5¢. And my point here is simple: > > No, Java (Team) can't. Ah, you appear to be thinking of the Gentoo Java team as it currently exists, rather than the mythical perfect Gentoo Java team that existed ten years ago and which will rise again soon, which is what William meant. -- Ciaran McCreesh
Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)
On Sun, 26 Mar 2017 13:04:18 -0700 Brian Dolbec <dol...@gentoo.org> wrote: > While this is a simple format. This is not a standard data input file > format for language tools to map it into native language variables and > types. > > I would much prefer for any new files to be created in a format that > most languages have data input modules for and are easily read/edited > by humans. While this can be read and split easily in python code. > It is not future proof for additional data being added and/or removed. > > For the repoman stage3 rewrites. I am moving all configurable data > from the code into yaml based files in /metadata/repoman. These > files will be easily edited by all developers for updates to banned > eclasses and various other values not needing code changes. > > So with a general file name of arches.desc Is there any other data > that we want to include in that file? Possibly migrated from other > file(s). In that case a dictionary format yaml file might be best. > My example below has additional info over what was proposed. > It is an example only to show the possible benefit of such a file > type. It's bad enough that we have to parse XML inside the package mangler for optional data. Adding YAML (with all its format bugs: YAML files created with libyaml can't be read by syck, and vice-versa) for files that the package mangler has to read is even worse. Plain text *is* a standard format. -- Ciaran McCreesh
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Thu, 23 Mar 2017 22:37:49 +0100 Alexis Ballier <aball...@gentoo.org> wrote: > On Thu, 23 Mar 2017 20:30:40 + > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > On Thu, 23 Mar 2017 21:22:54 +0100 > > Alexis Ballier <aball...@gentoo.org> wrote: > > > Indeed, according to pms.git commit log, the rule was laxed > > > because it was clearly an oversight in EAPI6 [1] and was the > > > standard behavior in previous EAPIs. But in the same commit, an > > > "harmless note" was added that "Ebuilds must not access the > > > directory in global scope." in addition to the "May or may not > > > exist" statement and "Not necessarily present when installing > > > from a binary package" footnote. Please explain how this last > > > addition is not a backwards-breaking change. PMS is not a tool to > > > push your personal agenda of cleaning up the deve^^err tree. > > > > The original wording should probably have been something like "may > > or may not exist, so ebuilds MUST NOT go poking around for it", but > > the original wording was written assuming reasonable behaviour from > > developers, and we deliberately chose not to go the SHALL, MUST NOT > > route because of the added cost of developing a specification that's > > safe from hostile implementers. > > "reasonable" is not something that can be reasonably defined :) There's a fairly good rule of thumb: is anyone else already doing this horrible new thing you're about to add to the tree? If not, it's probably not reasonable. > after a few dozens of emails, what i understand of the issue is: > autoconf assumes either the eblit stuff is in the environment, or > FILESDIR variable is empty or points to its files dir; this might be > borderline but definitely not hostile. No, the issue is that eblits are a dodgy mechanism that go beyond what ebuilds are supposed to do and that cause problems for package manglers. When we're working with a general purpose shell underneath, it's very hard to write a specification that can preemptively forbid every kind of perverse mess any developer can come up with, particularly when the developer starts looking for loopholes like claiming it's OK to try to access a directory which is defined as potentially not existing when the clear intent of the specification is that "the directory isn't guaranteed to be there so don't try to use it for anything". > this breaks in the (hypothetical?) case where the package is installed > from a binpkg *and* the binpkg format does not include the whole > environment but rather a verbatim copy of the ebuild and its > eclasses(*). > > (*) not sure how that can even work with env saving between phases but > that's not the point It can't, so that weird hypothetical is irrelevant. But more to the point, we're only wondering about these weird hypothetical situations because someone felt the need to make everyone's life a misery by putting some special snowflake code in the tree. -- Ciaran McCreesh
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Thu, 23 Mar 2017 21:22:54 +0100 Alexis Ballier <aball...@gentoo.org> wrote: > Indeed, according to pms.git commit log, the rule was laxed because it > was clearly an oversight in EAPI6 [1] and was the standard behavior in > previous EAPIs. But in the same commit, an "harmless note" was added > that "Ebuilds must not access the directory in global scope." in > addition to the "May or may not exist" statement and "Not necessarily > present when installing from a binary package" footnote. Please > explain how this last addition is not a backwards-breaking change. > PMS is not a tool to push your personal agenda of cleaning up the > deve^^err tree. The original wording should probably have been something like "may or may not exist, so ebuilds MUST NOT go poking around for it", but the original wording was written assuming reasonable behaviour from developers, and we deliberately chose not to go the SHALL, MUST NOT route because of the added cost of developing a specification that's safe from hostile implementers. -- Ciaran McCreesh
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Thu, 23 Mar 2017 20:49:15 +0100 Alexis Ballier <aball...@gentoo.org> wrote: > On Thu, 23 Mar 2017 19:17:43 + > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > On Thu, 23 Mar 2017 20:12:04 +0100 > > Alexis Ballier <aball...@gentoo.org> wrote: > > > However, retroactively adding new rules > > > > Which, as you've already been told, is not what happened. Sit back, > > enjoy the tree getting slightly less terrible, and stop trying to > > find alternative facts to justify standing in the way of progress. > > > > I'm sorry but forcing people to rewrite working stuff for no reason is > not progress. There is plenty of reason, and there is no forcing. -- Ciaran McCreesh
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Thu, 23 Mar 2017 20:12:04 +0100 Alexis Ballier <aball...@gentoo.org> wrote: > However, retroactively adding new rules Which, as you've already been told, is not what happened. Sit back, enjoy the tree getting slightly less terrible, and stop trying to find alternative facts to justify standing in the way of progress. -- Ciaran McCreesh
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Thu, 23 Mar 2017 19:52:13 +0100 Alexis Ballier <aball...@gentoo.org> wrote: > > Do you think really think it's fine for maintainer to: > > > > 1. go against best practices, principle of least surprise and > > basically make it harder for anyone else to touch the ebuild (-> aim > > for bus factor of 1 and/or making himself indispensable)? > > This is very (too) subjective. It's really not. eblits are the result of vapier being vapier, and just shoving stuff into the tree without review rather than doing things properly. This stuff matters: Gentoo needs to be actively improving the quality of the tree so that progress can be made, not fighting a losing battle to stop it from getting even worse. -- Ciaran McCreesh
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On Thu, 23 Mar 2017 19:41:01 +0100 Alexis Ballier <aball...@gentoo.org> wrote: > > The PMS[0] says > > > >Ebuilds must not access [FILESDIR] in global scope. > > > > But, for example, autoconf-2.69-r2.ebuild does, > > > >if [[ -z ${__EBLITS__} && -n ${FILESDIR} ]] ; then > > source "${FILESDIR}"/eblits/main.eblit || die > >fi > > > > in global scope. > > > > Continuing to be the devil's advocate, it seems adding '&& -d > ${FILESDIR}' to that if would fix the issue too. At least with all > currently approved EAPIs. Please stop. PMS was not written with the kind of resources needed to deal with people deliberately trying to find loopholes. -- Ciaran McCreesh
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 16:25:54 -0500 Michael Orlitzky <m...@gentoo.org> wrote: > On 03/02/2017 04:06 PM, Zac Medico wrote: > >> > >> I agree with this ^ but I don't think portage should rebuild for > >> DEPEND at all. It creates one more dangerous "it works in > >> portage!" situation that will plague users of other package > >> managers. > >> > >> (I'm not saying it couldn't be useful, but it should go in the > >> next EAPI if we're gonna do it.) > > > > PMS doesn't specify when rebuilds are supposed to be triggered. You > > can consider the rebuilds as a means to satisfy the dependencies. > > Saying that the package manager should not make an effort to satisfy > > dependencies would be silly. > > It doesn't violate the PMS to do the extra rebuilds, but the PMS also > doesn't say that they should happen. > > Hypothetical situation: a developer notices that Go packages need to > be rebuilt when the compiler changes, so he adds subslot operators to > DEPEND and everything looks fine. Until someone with a different > package manager tries to use it, that is; the rebuilds aren't > triggered unless you're using portage. The point is to specify dependencies declaratively. A dependency expresses a dependency, not an action. If you can't express the kind of dependency you need, then we need either labels or another *DEPEND variable to take care of it, not a bodge. -- Ciaran McCreesh
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On Thu, 2 Mar 2017 09:47:35 -0500 Michael Orlitzky <m...@gentoo.org> wrote: > On 03/02/2017 09:24 AM, Mike Gilbert wrote: > >> > >> In other words, the ":=" only does something special in RDEPEND. > >> That makes sense when you think of it as meaning "the thing will > >> break" rather than "I want to do a rebuild." The only reason it's > >> not an error to put them in DEPEND is because it would annoy > >> everyone doing DEPEND="${RDEPEND}". > > > > Portage has interesting behavior for ":=" in DEPEND: it varies > > depending on your "with-bdeps" setting. > > > > This is why we can't have nice things. Actually you can't have nice things because the labels proposal was voted down for "being invented by the wrong people". -- Ciaran McCreesh
Re: [gentoo-dev] Removal of CVS headers
On Sun, 26 Feb 2017 21:16:28 +0100 Lars Wendler <polynomia...@gentoo.org> wrote: > How about QA finally starts acting on useful issues or at least do > actions that make sense? Part of the job of QA is to improve the overall quality of the tree. This includes going through and fixing historical mistakes. You may think it's not important, but if Gentoo finally gets into the habit of ongoing improvements, the tree will slowly get better rather than worse over time. -- Ciaran McCreesh
Re: [gentoo-dev] Printer drivers and net-print
On Thu, 23 Feb 2017 23:58:50 +0300 Andrew Savchenko <birc...@gentoo.org> wrote: > On Thu, 23 Feb 2017 18:50:45 +0100 Ulrich Mueller wrote: > > >>>>> On Thu, 23 Feb 2017, Andrew Savchenko wrote: > > >> https://projects.gentoo.org/pms/6/pms.html#x1-180003.1.1 > > >> "Category Names" > > > > > I don't see a requirement here, only note on most common > > > pattern: > > > > > ``Note: A hyphen is not required because of the virtual category. > > > Usually, however, category names will contain a hyphen.'' > > > > It is a note on what is the exclusive pattern, with the single > > exception of the virtual category. I believe that we shouldn't break > > that pattern. > > I'm fine with this approach, but could PMS be updated to contain > more clear statement to avoid misunderstanding? E.g.: > ``all category names must contain a single hyphen with a > special exception for "virtual"'' It's not a "must". Also, putting that rule in and having the package mangler enforce it can have unintended consequences: for example, there used to be the mild nuisance of dealing with overlays which didn't contain a categories list, and which did contain directories named CVS all over the place. -- Ciaran McCreesh
Re: [gentoo-dev] Re: The changes about the stabilization process
On Tue, 3 Jan 2017 05:56:56 +1300 Kent Fredric <ken...@gentoo.org> wrote: > On Thu, 29 Dec 2016 17:23:58 + > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > > Because it isn't... Are set names atoms? Are package names without > > an associated category atoms? > > If I use the content of man 5 ebuild as a guide, I'd say no, sets > can't be atoms. What about if you read the user-oriented documentation, which has a different semi-definition? -- Ciaran McCreesh
Re: [gentoo-dev] Re: The changes about the stabilization process
On Thu, 29 Dec 2016 13:28:12 +0100 Marc Schiffbauer <msch...@gentoo.org> wrote: > "atom" is a well defined term in the gentoo world, so why not use it? Because it isn't... Are set names atoms? Are package names without an associated category atoms? -- Ciaran McCreesh
Re: [gentoo-dev] Re: The changes about the stabilization process
On Thu, 29 Dec 2016 16:44:12 +0100 Jeroen Roovers <j...@gentoo.org> wrote: > On Wed, 28 Dec 2016 22:31:19 + > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > We made a deliberate decision not to use the word "atom" in PMS > > because it means subtly different things in different contexts. > > You're doing it again! You're not citing any decisions on actual > mailing lists, chat logs or in documentation, and you use > qualifications like "subtl[e]" to denote some deeper rationale that > is apparently very difficult to explain to the "uninitiated". Good > job, if your job was to deter the "uninitiated". > > Where was that decision recorded? What subtle differences did you > perceive? Which contexts lead to those different meanings, and why did > you not keep "atom" and qualify it according to context? Did you > document the history, present and future of the term "atom" so you > could point out why it was rejected for future use? Even, what > real-world problem were you trying to solve in rejecting "atom"? Unfortunately we had a team of three when writing PMS to begin with, and the emphasis was on producing a definitive spec, not a history book. We did not have a volunteer archivist at the time. If you'd like to volunteer to start, I'm sure you'd be welcome to produce an annotated PMS for people who are interested in that kind of thing -- the annotated C++ reference manual was a lovely read, back when it was maintained. -- Ciaran McCreesh
Re: [gentoo-dev] Re: The changes about the stabilization process
On Wed, 28 Dec 2016 23:21:51 +0100 Jeroen Roovers <j...@gentoo.org> wrote: > On Thu, 29 Dec 2016 03:49:30 +1100 > Michael Palimaka <kensing...@gentoo.org> wrote: > > > Can you please avoid reintroducing the term "atom" there, when we > > > are trying to get rid of it elsewhere [1]? Note that PMS doesn't > > > define the term [2]. > > > > Any suggestions for improved text? Ideally it would be > > stabilisation/keywording agnostic as the same field is used in both > > components. > > How about "atoms". We've been using that for ages (regardless of what > PMS authors think) so why change it now? Alternatively, I would > propose to call them "bikesheds" as that will work just as well as > any other label and will succinctly refer to the creative process > that made it a replacement for "atoms". We made a deliberate decision not to use the word "atom" in PMS because it means subtly different things in different contexts. -- Ciaran McCreesh
Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash
On Sun, 4 Dec 2016 18:47:48 -0800 Daniel Campbell <z...@gentoo.org> wrote: > Compliance with what? If others desire Quickbook support, they can > make a tool to convert from ledger. There's no good reason for a > non-profit, libre software organization to use and depend on > proprietary software. Did nobody learn a lesson from BitKeeper? Have you checked that the people hosting Gentoo's infrastructure don't use any proprietary software anywhere inside their building either? Most cleaning companies use a closed source staff scheduling program. It would be a terrible violation of the social contract if Gentoo depended upon that. -- Ciaran McCreesh
Re: [gentoo-dev] Uppercase characters in package names
On Fri, 2 Dec 2016 13:24:29 -0500 Mike Gilbert <flop...@gentoo.org> wrote: > On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh > <ciaran.mccre...@googlemail.com> wrote: > > On Fri, 2 Dec 2016 13:02:48 -0500 > > Mike Gilbert <flop...@gentoo.org> wrote: > >> The devmanual states: > >> > >> The name section should contain only lowercase non-accented > >> letters, the digits 0-9, hyphens, underscores and plus characters. > >> Uppercase characters are strongly discouraged, but technically > >> valid. > >> > >> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html > >> > >> > >> Why are uppercase characters strongly discouraged? > >> > >> Wouldn't it make sense to follow upstream's naming convention? > > > > What's upstream's naming convention for Firefox? > > I have no idea. What's your point? That naming conventions are generally complicated and a mess, and that no-one wants to have to remember whether it's firefox, Firefox, or FireFox. -- Ciaran McCreesh
Re: [gentoo-dev] Uppercase characters in package names
On Fri, 2 Dec 2016 13:02:48 -0500 Mike Gilbert <flop...@gentoo.org> wrote: > The devmanual states: > > The name section should contain only lowercase non-accented letters, > the digits 0-9, hyphens, underscores and plus characters. Uppercase > characters are strongly discouraged, but technically valid. > > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html > > > Why are uppercase characters strongly discouraged? > > Wouldn't it make sense to follow upstream's naming convention? What's upstream's naming convention for Firefox? -- Ciaran McCreesh
Re: [gentoo-dev] Developer GitHub usernames
On Mon, 21 Nov 2016 21:28:33 +0100 Jeroen Roovers <j...@gentoo.org> wrote: > On Mon, 21 Nov 2016 10:01:47 +0100 > Michał Górny <mgo...@gentoo.org> wrote: > > > Since some of our people don't want to admit they're using GitHub or > > otherwise want to pretend they're not > > Interesting how you simply can't understand that some people hate > mixing work and pleasure[1] and how you then need to ridicule what you > don't understand, Ciaran. Wait what. Why am I being blamed for any of this? I assure you, Michał isn't one of my sockpuppet developer accounts, and my involvement with Github as a company is limited to them buying me an awful lot of free booze once. I think you might be seeing conspiracies in the wrong place... -- Ciaran McCreesh
Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?
On Mon, 24 Oct 2016 15:34:14 -0700 Matt Turner <matts...@gentoo.org> wrote: > In order to contribute to GNU projects, one must sign a copyright > assignment statement. > > Gentoo doesn't have anything similar as far as I'm aware, which makes > me question the legitimacy of "Gentoo Foundation" copyrights. > > What is the story? Gentoo did have a copyright transfer agreement at one point, which was written by an actual paid-for lawyer. Developers had to agree to hand over their floppy disks and monitors to the Foundation upon request. Developers who were recruited in a particular time window had to sign it, but anyone who started before didn't. -- Ciaran McCreesh
Re: [gentoo-dev] Package file name requirement for binary ebuilds
On Mon, 17 Oct 2016 16:43:40 -0400 "William L. Thomson Jr." <wlt...@o-sinc.com> wrote: > No its a PMS requirement as you said not visual as I was saying... PMS doesn't cover multiple repository stuff in much detail. We didn't want to mandate Portage's historical weird overlay behaviour, so it doesn't really specify anything at all. -- Ciaran McCreesh
Re: [gentoo-dev] New Working Group established to evaluate the stable tree
On Sun, 14 Aug 2016 23:35:58 +0200 Kristian Fiskerstrand <k...@gentoo.org> wrote: > During the latest Council meeting it was determined to set up a new > Working Group to come up with recommendations for improving the state > of the stable tree at a later Council meeting. What's a Working Group, and how is it related to a Project? Shouldn't there be a GLEP to define what a Working Group is first? -- Ciaran McCreesh
Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian
On Thu, 11 Aug 2016 17:57:59 +0300 Mart Raudsepp <l...@gentoo.org> wrote: > I strongly believe that it's important to have such a use case as > Steam work problem-free in Gentoo. Steam isn't a use case, it's a program. -- Ciaran McCreesh
Re: [gentoo-dev] Re: Packages up for grabs
On Sun, 7 Aug 2016 12:24:37 -0500 james <gar...@verizon.net> wrote: > >> Let them use java* codes, as that is what all the universities are > >> teaching and promoting. I agree > >> with gentoo proper on severely restricting java*, on > >> gentoo-proper, but that sort of thing is killing gentoo and just > >> appears to the open world as a filter mechanism to keep out and go > >> elsewhere, snoot. There are just too many exciting and useful > >> codes out there running java. > > > > "All" ? Some. And the dominance and focus on Java is itself telling > > of the quality and type of the education provider. > > > > Some education providers may not touch Java at all, and focus > > predominantly on C. > > Sure, I agree here, but, statistically these "hi level" languages are > being taught, in lieu of C; and that is really sad. I'm sure there > are exceptions, would you have a few CS departments that push C over > java and the other, newer languages? (I'm curios). You all appear to be missing the point of education. If you are learning technologies, your skills will be obsolete in five years. If you are learning general principles and problem solving, the particular language being used is much less important. -- Ciaran McCreesh
Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts
On Sun, 24 Jul 2016 10:17:24 +0200 Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote: > > Then ebuilds will fail just the same > > No. Before, ebuilds would maybe display an upgrading message when > they shouldn't, or vice versa. Now the eclass dies on them. This attitude that invisible failures (which don't get fixed, and which lead to occasional weirdness) are better than visible failures (which must be fixed) is an odd one... Postel has a lot to answer for. -- Ciaran McCreesh
Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
On Sun, 24 Jul 2016 10:05:23 +0300 Andrew Savchenko <birc...@gentoo.org> wrote: > I agree with you, but REPLACING_VERSIONS has nothing to do with > such recovery. Yes, it does. Specifically, what we want is for developers to get into the habit of writing safe, clean code, even if they think they don't need to care about it in some particular situation because they can't think of how it would go wrong. It's the same as getting into the habit of sticking || die on things. > 1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery > from hardware crashes forked well long before. Before this, you could use has_version in pkg_*, and it would tell you the *old* version of the package that was installed. The phase order changed a while ago, and broke this, so REPLACING_VERSIONS was the replacement. Again, the situation is complicated, there's a lot of messy history behind this, and if you don't know it all, just do what the spec says and stop wasting everyone's time by arguing. > 2) If you will look into the tree, in the absolute majority of cases > REPLACING_VERSIONS is being used to determine whether informational > messages should be shown to a user or not. Such messages usually > include some upgrade hints or howtos; and REPLACING_VERSIONS check > is required to avoid showing them to unaffected users. It has > absolutely nothing to do with the error recovery done by PM itself. Don't get into the habit of writing code that makes unnecessary assumptions that will come back and screw users over in unexpected situations. It's easy to do this the right way, so at this point I can only conclude that you're persisting in trying to do it wrong just to avoid admitting that you made a mistake from ignorance. It's OK to be wrong sometimes (and this is why code review exists), but it's not OK to continue to argue that you were right out of stubbornness. -- Ciaran McCreesh
Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
On Sun, 24 Jul 2016 00:04:53 +0200 "Andreas K. Huettel" <dilfri...@gentoo.org> wrote: > 1) If a package only ever had one slot, it cannot ever have two > versions installed at the same time. That guarantee (of only ever one > slot) can be given for the portage tree (sic). Obviously it doesn't > work for overlays, but there are many things we don't care about for > overlays. [A] Outright wrong, as has already been explained in this thread several times. > 2) If a package manager leaves two versions of a non-slotted package > "installed" somehow, that package manager is fundamentally broken and > its author should forever refrain from specifying anything. It's not > our job to work around Paludis failure modes. [B] This is not a Paludis issue. It happens with Portage too. The install sequence is carefully designed to install the new version of the package, and then remove the old one (and if you think about it for a few seconds, you can see that it *has* to be this way). If an error or ctrl+c occurs at the wrong point, both versions remain installed, and importantly, there is a safe way to recover from this. -- Ciaran McCreesh
Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
On Sun, 24 Jul 2016 00:30:39 +0300 Andrew Savchenko <birc...@gentoo.org> wrote: > Oh, nice: strictly follow PMS no matter what, right? Then let me > remind you that not so long time ago I advocated for strictly > following PMS [1,2], which _allows_ || ( A:= B:= ) construct [3]. > > But I was _enforced_ by QA to _violate_ PMS and remove the valid > syntax blocks [4]. This decision was made because of $reasons: > - we lack ||= operator; > - || ( := ) behaviour is not implemented properly in existing PM; > - "it doesn't make *any* sense"; > - other valid and unquestionable $reasons ... > > So the result is that common sense and practical considerations > take over PMS. And what we have in the REPLACING_VERSIONS case? > It doesn't matter that such situation never happened and will > likely never happen, but one must follow PMS strictly no matter > what. Such attitude is not fair at least. No. You have simply failed to understand the reason || ( A:= B:= ) doesn't work. It may superficially appear correct, but you either need to think carefully about the implications, or just accept wisdom from people who have. I remind you that PMS does not explicitly prohibit a dependency upon =A-1 =A-2 where A is not slotted, either: it's a nonsense dependency, but syntactically valid. Please stop trying to use your common sense in areas where you lack the intuition and experience to have accurate common sense. > Do we ever had such case like multiple versions of the same > single-slotted package installed or recorded as installed in the > real world? I'm not sure even in this, but I may assume that it may > happen one day. Yes, this happens with failures on uninstalls and upgrades. > Do we have any proof that PM can recover from such situation, > where VDB is a mess and installed files can also be a mess? I'm not > sure in this at all. Yes, things have been designed quite carefully to allow this to happen. You recover by installing a new version, and using it to replace the two installed versions simultaneously. > Do we have any test suits for portage (as the most popular PM > implementation) for such cases? I doubt this, I can find none. I'm > not sure if such tests are implemented in other PM test suits too. Portage doesn't exactly have many tests... -- Ciaran McCreesh
Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
On Sat, 23 Jul 2016 17:23:48 +0300 Andrew Savchenko <birc...@gentoo.org> wrote: > On Fri, 22 Jul 2016 14:57:36 +0100 Ciaran McCreesh wrote: > > On Fri, 22 Jul 2016 16:41:56 +0300 > > Andrew Savchenko <birc...@gentoo.org> wrote: > [...] > > > I see no point in trashing ebuilds with dead code that will never > > > be used. Though if there will be a PMS or eclass function with > > > "proper" implementation, I don't mind, since extra code will be > > > moved from ebuild elsewhere. > > > > Slots are not the only way in which you can end up with multiple > > installed versions of the same package. Another way is if there's a > > fatal error during certain parts of the upgrade process. > > If setup is broken to the point when several version within single > slot are installed (or are reported to be installed), then: > > 1) There is no way to tell which version is valid and all of them > may be invalid. That's why REPLACING_VERSIONS is of no use at all > in such situation. > > 2) System is severely broken and mistakenly shown (or not shown) > ewarn message will be the least problem for a user of such system. Uh, nope. The PM can recover from that situation, so long as people don't go around writing broken ebuilds that make unwarranted assumptions that the spec specifically tells them not to make. Don't get into the habit of writing broken code. Or to put it another way: you are wrong, and you don't know enough about the situation to understand why you're wrong, and you clearly have no interest in learning, so just do as you're told. -- Ciaran McCreesh
Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
On Fri, 22 Jul 2016 16:41:56 +0300 Andrew Savchenko <birc...@gentoo.org> wrote: > On Fri, 22 Jul 2016 13:14:23 +0200 Michał Górny wrote: > > Dnia 22 lipca 2016 13:00:42 CEST, Andrew Savchenko > > <birc...@gentoo.org> napisał(a): > > >On Thu, 21 Jul 2016 07:12:12 +0200 Michał Górny wrote: > [...] > > >> Few important QA notes: > > >> > > >> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 > > >> gives false, > > > > > >Thanks, fixed. > > > > > >> 2. REPLACING_VERSIONS can have more than one value, > > > > > >While it can indeed, I see no way for this to happen if package > > >hasn't and never had multiple slots. > > > > Wrong. PMS specifically requests you to account for such a > > possibility. > > Common sence must prevail over formal approaches. While PMS is > great, it is not perfect in all possible aspects, and this one is > one of them. > And this is a perfect example of why so much stuff in Gentoo is subtly broken... Things are usually more complicated than you think, buggy code usually works well enough that the mistakes aren't noticed in most cases, and too many developers are far too convinced of their own competence. You need to appreciate that you do not have a complete understanding of what is going on, your "common sense" is leading you astray, and that that API was designed the way it was out of necessity. > I see no point in trashing ebuilds with dead code that will never > be used. Though if there will be a PMS or eclass function with > "proper" implementation, I don't mind, since extra code will be > moved from ebuild elsewhere. Slots are not the only way in which you can end up with multiple installed versions of the same package. Another way is if there's a fatal error during certain parts of the upgrade process. -- Ciaran McCreesh
Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
On Wed, 15 Jun 2016 00:21:45 +0200 "Andreas K. Huettel" <dilfri...@gentoo.org> wrote: > Am Montag, 13. Juni 2016, 09:50:15 schrieb Alexander Berntsen: > > > I still think you're underestimating the need for centralization. > > > What you call a "core/base" package is probably going to end up > > > being anything listed in a dependency. That is a LOT of packages, > > > actually - we're not just talking about libc and zlib. > > > > It's not a lot compared to how many we have today. > > Please do me a favor and emerge @system on a fresh stage > installation, with USE=kde ... > > ... So, > > * does KDE go into the curated repos? or > * will the useflag functionality be discontinued? * Your package mangler tells you you need some packages which can be found in the ::kde repository if you have that flag enabled, and suggests you either install repository/kde or disable that USE flag so that it can continue. -- Ciaran McCreesh
Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
On Thu, 9 Jun 2016 14:25:08 +0200 Dirkjan Ochtman <d...@gentoo.org> wrote: > I would tend to agree with those who have written that coordinating > work across repos is kind of a pain. How do you know? What is your experience in the area of coordinating work across repos in a Gentoo-style distribution? -- Ciaran McCreesh
Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
On Thu, 9 Jun 2016 06:20:38 -0400 Rich Freeman <ri...@gentoo.org> wrote: > > On 08/06/16 16:53, Rich Freeman wrote: > >> Do you propose that you can have cross-repo dependencies? > > Sure. This works well in Exherbo using Paludis. We could do it > > right now if we wanted to. > > > >> If so that creates a lot of potential issues, even if you do it > >> the NixOS way. > > You should tell Exherbo and NixOS about all these issues that they > > should be having but aren't having. > > > > Perhaps you could explain how they actually prevent the issues I > brought up? Since you didn't actually quote them I'll do so: > > Suppose you have 10 packages, and they each depend on zlib from a > different repository? They don't. Packages do not depend upon "zlib from repository x". They depend upon "zlib". The Exherbo model is not "packages are all over the place and there is no coordination whatsoever". The model is "packages that lots of people use are in a small number of core repositories and are carefully dealt with to avoid breakages, but packages that have small numbers of users are in personal repositories which everyone can see". Libraries and packages that start to be used by many people get moved to one of the central repositories; one way to tell that this needs to be done is when it looks like the issues you think could happen actually start to happen. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Global USE=gui
On Fri, 10 Jun 2016 00:18:44 +0200 Ulrich Mueller <u...@gentoo.org> wrote: > >>>>> On Thu, 9 Jun 2016, Michał Górny wrote: > >> That would be a policy violation. Packages should pick a reasonable > >> default if flags are conflicting, but not force users to > >> micro-manage their flags. > > > Who did establish that *idiotic* policy and why is he still a > > developer? > > Michał, > You may want to reconsider your tone. > > The policy was established when documenting REQUIRED_USE for EAPI 4, > and it is based on consensus in bug 353624 [1] and in the gentoo-dev > mailing list [2,3]. Really, that policy predates REQUIRED_USE, and even EAPIs... In the olden days, the rule was that USE flags were for things that were optional, and that if something wasn't optional, then it shouldn't be controlled by USE flags. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] Global USE=gui
On Tue, 7 Jun 2016 22:59:42 +0200 Michał Górny <mgo...@gentoo.org> wrote: > Not 5 minutes. Depending on the context, Portage can complain about > REQUIRED_USE in a few seconds because it has no further point > in evaluating the depgraph. ...but it shouldn't, because then it only gives you the first error. -- Ciaran McCreesh
Re: [gentoo-dev] What are eblits?
On Fri, 27 May 2016 00:28:35 +0200 rindeal <dev.rind...@gmail.com> wrote: > 1) what are they? A horrible QA violation. > 2) why are they used? Because some people like to feel special... -- Ciaran McCreesh
Re: [gentoo-dev] Proposal for changes for the next EAPI version
On Tue, 17 May 2016 07:26:03 -0400 Michael Orlitzky <m...@gentoo.org> wrote: > We already have "emerge --config" which is expected to be run after > the install process has completed, so I don't think that this is too > much of a stretch. Maybe call the phase "pkg_test" analogous to > "pkg_config" and in contrast to "src_test" which runs within the > working directory. Then "emerge --test" could run it. For various technical reasons to do with the spec and package manglers sometimes using phase function names with the src_ or pkg_ stripped off, calling it that would be a huge pain. -- Ciaran McCreesh
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On Mon, 16 May 2016 15:56:01 +0800 Ian Delaney <idel...@gentoo.org> wrote: > As long as this persists and is not intervened to polish and tidy up, > g-devs will persist in making innocent, naive or incompetent blunders > and run the gauntlet of being publicly scolded over errata. I can only > express my view that this style of personal demeaning potentially > results in embarrassment, public humiliation and drives community > members away from participation. The ultimate negative influence. I > would never entertain taking on eclass writing with the incumbent qa > member delivering assessments under the title of 'code review' in the > style he does. If you're writing the kind of code that results in you being subjected to scathing criticism for breaking metadata generation for the entire tree, then discouraging you from contributing can only be good for the distribution... -- Ciaran McCreesh
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On Sun, 15 May 2016 08:40:39 +0900 Aaron Bauman <b...@gentoo.org> wrote: > Please enlighten me as to what was impolite here? The strong > language of "seriously" or definitively stating that the individual > did not perform the necessary QA actions before committing? Both of > which are completely called for and appropriate. No vulgarity, > insults, or demeaning words were used. How would you have responded > professionally? It's important to remember that Gentoo is run by volunteers. Expecting a professional standard when it comes to the quality of commit criticism is unfair. -- Ciaran McCreesh
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On Sat, 14 May 2016 11:55:42 +0200 > Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney: > > On Sat, 7 May 2016 23:25:58 +0200 > > > Do you seriously expect this code to work? How about testing? Or > > > reading diffs before committing? > > > > Do you seriously expect us to sit and absorb this form of pious > > put down? From one who knows far better who is entitled to speak > > down to colleagues as is completely lacking a cerebral cortex? > > Those times are drawing to an end. Did anyone ever teach you to > > treat folk in such manner and expect them to respect it? I don't > > think so Not over my dead cvs perhaps > > Well, we still do need some commit quality, you know... Why? Gentoo is about the community. Requiring a basic standard of commit quality a) reduces the number of community members who are able to contribute, 2) leads to fewer forums posts discussing how to fix problems, iii) hurts Gentoo's DistroWatch statistics by reducing the volume of commits, and fourthly, discriminates unfairly against competency-challenged developers by imposing subjective interpretations of the value of source code from a position of unearned authority. This is against the code of conduct, and is bad for the community! -- Ciaran McCreesh
Re: [gentoo-dev] News Item: LastPass package migration
On Sun, 8 May 2016 01:25:58 -0400 Göktürk Yüksek <gokt...@binghamton.edu> wrote: > Display-If-Installed: app-admin/lastpass Every version, forever, even for new installs made next year? -- Ciaran McCreesh
Re: [gentoo-dev] Uncoordinated changes
On Sun, 14 Feb 2016 19:53:56 +0100 Patrick Lauer <patr...@gentoo.org> wrote: > I don't have time to follow every little change, so it's quite > annoying to reverse-engineer this change that apparently is a > compromise that no one actually wanted, and hasn't really been > finished yet. Sigh. Why reverse engineer it? It's all documented. -- Ciaran McCreesh
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
On Tue, 19 Jan 2016 23:32:30 +0100 Michał Górny <mgo...@gentoo.org> wrote: > The problem was, is and will be that packages are unmaintained. Not > that stats show that they are many. No it's not. Gentoo is about the community, and it's important for the community not to perceive that there is a problem. Being honest where users or Phoronix could pick up on it is bad PR. Let's not create a toxic perception of the state of the tree. -- Ciaran McCreesh
Re: [gentoo-dev] [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability
On Wed, 11 Nov 2015 07:16:42 +0100 Patrick Lauer <patr...@gentoo.org> wrote: > Wouldn't it be 'easier' (fsov easy) to have portage use sane-default > locale settings, so that estonian or turkish users don't get hit by > weirdness in the [a-z] character class etc.? Paludis forces all the LC variables to sane values. A few vocal annoying users hate this, and patch it out... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Revision diffs
On Sat, 7 Nov 2015 02:34:22 +1300 Kent Fredric <kentfred...@gmail.com> wrote: > On 7 November 2015 at 02:16, Michael Orlitzky <m...@gentoo.org> wrote: > > These days, if I'm careful to revbump when necessary AND limit my > > commits to one logical change, can I wind up going from (say) -r1 > > all the way to -r4 before pushing my changes. > > Personally I don't think that's necessary. The "-r bump on dep change" > argument is a defence against installer limitations and the > replication of changes to users. No it isn't. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: ChangeLog
On Mon, 2 Nov 2015 14:00:18 -0600 Dale <rdalek1...@gmail.com> wrote: > Rich Freeman wrote: > > On Mon, Nov 2, 2015 at 1:08 AM, Dale <rdalek1...@gmail.com> wrote: > >> Then perhaps all this should have been worked out BEFORE switching > >> to github? > > We didn't switch to github. > > Then why are people saying to use git to look at the logs? I don't > want to use git. git != github... > I liked being able to go to the tree and look at the > change logs when I needed to which is sometimes often. I think you have a technology comprehension problem here, rather than a technology problem. The problem is your workflow, not the tools. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Depending on a range of slots
On Mon, 2 Nov 2015 12:48:29 -0500 Michael Orlitzky <m...@gentoo.org> wrote: > Is there a way to say "give me any 4.x or 5.x slot"? No. Slots are meaningless strings and do not support any comparison except equality. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Depending on a range of slots
On Mon, 2 Nov 2015 14:33:57 -0500 Michael Orlitzky <m...@gentoo.org> wrote: > Followup question, which of these is less dumb? > > Option 1: berkdb? ( >=sys-libs/db-4:* Option 2: berkdb? ( || ( sys-libs/db:4.2 ... sys-libs/db:5.3 ) ) Best option goes leftmost in ||. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Depending on a range of slots
On Mon, 2 Nov 2015 22:01:05 +0100 hasufell <hasuf...@gentoo.org> wrote: > That's an interesting pitfall. I am pretty sure we have this kind of > syntax a lot in the tree. Might make sense to document it. Would make more sense just to implement version ranges in full generality, since developers seem to insist upon using < dependencies anyway... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: ChangeLog
On Sun, 01 Nov 2015 22:19:24 +0600 Мисбах-Соловьёв Вадим <m...@mva.name> wrote: > > Now how can this user display the ChangeLog for > > a certain package? > ``` > git log -- pkg-category/pkg-name/ > ``` > // assuming user in portage directory or passed GIT_DIR with path to > it. > > Although, it is only if user has successfully cloned/synced the > repo ;) Which is hardcore quest when you're living in, say, Syria, > Egypt, Somalia, or something like that. Or, if you're, say, in > transsiberian train ride for a week. Perhaps there is a better choice of distribution for you if you are. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] News Item: Changes in default VIDEO_CARDS
On Thu, 29 Oct 2015 17:13:29 +0100 Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote: > Ciaran McCreesh schrieb: > > On Thu, 29 Oct 2015 16:22:40 +0100 > > Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote: > >> The previous time I wanted to post a news item with USE > >> dependencies, this was not possible because the > >> Display-If-Installed dependency atom had to conform to EAPI 0. But > >> now that all profiles are EAPI 5 this is ok I hope. > > It's not really clear what the EAPI for the news directory is... > > I guess you are right, but as all package managers must now > understand EAPI 5 dependency atoms, it is not likely that any will > choke on it. Well Portage won't, since it doesn't do input validation and will pretty much allow you to use any EAPI's syntax anywhere. Paludis will probably warn that you're using an EAPI 5 feature somewhere where EAPI 5 hasn't been declared, since everything that isn't explicitly a particular EAPI is EAPI 0. > Besides, existing news items already use > Display-If-Profile: to point to EAPI 5 profiles. That isn't how EAPIs work, conceptually. Whenever a PM does something with a spec, it asks what the EAPI is in the context of that spec, which in turn depends upon where that spec came from. A user using a profile with EAPI 5 does not mean that every dep spec is treated as being EAPI 5 -- the profile EAPI just applies to things from that particular profiles directory. (And even if it did work the way you think, users not using an EAPI 5 profile would still need to be able to parse that news item...) > But I can ask the Council for clarification on the issue. Not so much a Council issue as a PMS one, but the trouble is that news items slightly predate PMS and EAPIs. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] News Item: Changes in default VIDEO_CARDS
On Thu, 29 Oct 2015 16:22:40 +0100 Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote: > The previous time I wanted to post a news item with USE dependencies, > this was not possible because the Display-If-Installed dependency > atom had to conform to EAPI 0. But now that all profiles are EAPI 5 > this is ok I hope. It's not really clear what the EAPI for the news directory is... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/
On Wed, 21 Oct 2015 01:25:53 +0200 hasufell <hasuf...@gentoo.org> wrote: > Also, my package manager chokes on it. Repoman not, so that looks > like a bug. s/Repoman/Portage/ Portage will quite happily let you specify KEYWORDS=":)". -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review
On Sun, 18 Oct 2015 20:19:12 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > what I was trying to understand is what is the usefulness of eapply > vs epatch The point of eapply is that it's inside the package manager, so it can safely be used by default phase functions, for user patches, etc. Rather than it being a direct copy of the epatch API, we took this as an opportunity to tidy up the behaviour to make it do something easy to understand and sensible, rather than being full of scary voodoo heuristics which are rarely necessary (and when they are, fixing your patches is easy) and which have weird effects that you don't know about until it's too late. Of course, this is part of the larger debate on "as much as possible in the PM" versus "as much as possible in the tree". The main "in the PM" argument is "less breakage and better testing"; the main "in the tree" argument is that things going spectacularly wrong for users every now and again is fine because it lets developers have new useless toys slightly faster. (This is a totally unbiased and entirely comprehensive summary of the debate.) > or simply using 'epatch "${PATCHES[@]}"' when proper patches do not > fit in what you call 'all the useful features': I haven't seen any, > so that I know where to stand on using that feature or not. It is > simply inferior and deemed unfixable until next EAPI. It would be nice if eutils defined epatch to die for EAPI 6... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review
On Sun, 18 Oct 2015 10:31:09 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > > The rationale is that we cannot apply patches in the default > > src_prepare() unless there is a patch function in the package > > manager itself. Obviously the default phase cannot call a function > > from an eclass. > > well, that was the idea behind base.eclass :) > why not just improving it ? No, the idea behind base.eclass was that somehow ebuilds were "object oriented", and that whenever you had "object oriented" you had to have a single base class for everything. It was a silly idea and we should all be glad it has been forgotten. > - why should I ever want eapi6 src_prepare instead of > base_src_prepare ? Well base.eclass is supposed to be being removed, and is allegedly banned for all new ebuilds... But the big gain for everyone is in replacing a weird, overly clever and highly fragile collection of weirdness that's designed to mostly accept any dodgy input, with one that just gets you to give it a sane input to begin with. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review
On Sun, 18 Oct 2015 20:00:11 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > On Sun, 18 Oct 2015 13:44:30 +0100 > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > [...] > > > - why should I ever want eapi6 src_prepare instead of > > > base_src_prepare ? > > > > Well base.eclass is supposed to be being removed, and is allegedly > > banned for all new ebuilds... > > > > But the big gain for everyone is in replacing a weird, overly clever > > and highly fragile collection of weirdness that's designed to mostly > > accept any dodgy input, with one that just gets you to give it a > > sane input to begin with. > > > > removing features is certainly not a gain for me > > after all, the safest program is the one that does nothing It's a good thing we've left in all the useful features, then. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review
On Sat, 17 Oct 2015 14:49:36 +0200 hasufell <hasuf...@gentoo.org> wrote: > You can apply the patches post_unpack or post_src_prepare witht hooks. > What's the problem? Running autorecrap. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC/announcement] Reviewers project
On Mon, 12 Oct 2015 13:13:15 +0800 Ian Delaney<idel...@gentoo.org> wrote: > The main target learners here are keen users. You can take told a > mistake with the background and status of a dev. They don't. They are > often intimidated and fearful if gentoo devs. We wonder why. So how about letting them that if they make a mistake, there are now ways of rectifying that quickly? -- Ciaran McCreesh signature.asc Description: PGP signature