On Wed, 30 Oct 2019 10:52:35 -0500
William Hubbs wrote:
> If not, I would rather see you pick one of the two options above.
-r1 bump all existing consumers of that eclass first? :)
pgpOohqnJQZK6.pgp
Description: OpenPGP digital signature
On Fri, 1 Nov 2019 19:59:35 +
Michael 'veremitz' Everitt wrote:
> Thoughts from outside peanut gallery?
>
> Michael / veremitz.
I have an alternative that might be more pleasant:
1. Change repoman so that when its clear that:
- There is at least one ebuild being changed
- There is on
On Mon, 4 Nov 2019 10:53:44 -0500
Michael Orlitzky wrote:
> To avoid these sorts of questions in the future, it might be worth the
> time it would take to vote on each of these policies formally, document
> them on the wiki, and then move the related checks to ::gentoo/metadata
> where other p
On Mon, 4 Nov 2019 23:24:57 +
Michael 'veremitz' Everitt wrote:
> Straw man anyone? I know Guy Fawkes night is coming up here in the UK ... ;)
I love you, but please, less trolling.
This is a developer discussion venue, not a place for cheap-shots like
reddit.
pgpVMFPNhhCyl.pgp
Descripti
On Fri, 22 Nov 2019 07:46:45 +0100
Michał Górny wrote:
> Cc: pyt...@gentoo.org, Michał Górny
> Subject: [gentoo-dev] [PATCH v3 1/5] python-utils-r1.eclass: Introduce
> build_sphins() helper
> Date: Fri, 22 Nov 2019 07:46:45 +0100
> Reply-to: gentoo-dev@lists.gentoo.org
You have a typo in the
On Wed, 4 Dec 2019 13:44:22 +0100
Miroslav Šulc wrote:
> it's proly little bit off this topic, but why do we have to copy
> homepage and description from ebuild to ebuild? wouldn't it be better to
> move this information to metadata.xml and keep it just there? or does in
> reality one package
On Wed, 04 Dec 2019 13:36:07 +0100
Michał Górny wrote:
> My point is: gentoo.org as a HOMEPAGE sucks. Please use something more
> specific instead. Even link to gitweb would be more helpful because it
> would at least be relevant to the package in question.
I agree so much I would support the
On Wed, 4 Dec 2019 17:24:54 +0200
Joonas Niilola wrote:
> I take it you haven't checked the CI results lately? Reaction to that
> probably spawned this ML thread.
In that case, good work :)
pgp3S4GcNB4R5.pgp
Description: OpenPGP digital signature
On Thu, 5 Dec 2019 09:40:50 -0500
Aaron Bauman wrote:
> Wonderful response, William.
Just because its EOL, doesn't mean it stops working.
It just means *support* for defects and security problems is dropped.
It doesn't prevent us from:
a) vendor patching bugs
b) vendor patching security issu
On Fri, 06 Dec 2019 21:10:12 +0100
Andreas Sturmlechner wrote:
> Calculating dependencies... done!
>
> Total: 0 packages, Size of downloads: 0 KiB
>
> WARNING: One or more updates/rebuilds have been skipped due to a
> dependency conflict:
>
> dev-python/sphinx:0
>
> (dev-python/sphinx-2.0.1
On Fri, 6 Dec 2019 12:58:47 -0500
Michael Orlitzky wrote:
> $ git rebase -i
>
> to do a rebase starting at the one you'd like to fix.
Or, if you know the hash of the faulty commit, you can do:
$ git rebase -i DEADBEEF^1
( 1st parent of commit DEADBEEF )
Which absolves you from needin
On Fri, 06 Dec 2019 10:03:23 +0100
Alexis Ballier wrote:
> (*) and force the use of some handy git options like only commit paths
> starting from cwd even if other files had been git added, which i never
> remember what is the git cli option for this
There isn't so much a CLI option, more, there
On Fri, 6 Dec 2019 12:09:31 -0800
Georgy Yakovlev wrote:
> Default output just prints crate name.
> With -vv we can see all cargo options and rustc args.
On the overlay with rust-crate.eclass, I've not found the verbose
output very helpful for anything.
I would probably ask for a knob to tweak
On Sat, 14 Dec 2019 08:16:03 +0100
Ulrich Mueller wrote:
> These prevent NOCOLOR in make.conf or emerge --color=n from working
> correctly, and I guess they are also problematic from an accessibility
> point of view.
>
> Are there any objections against removing these sequences from strings?
> A
On Wed, 18 Dec 2019 23:58:22 +
Sergei Trofimovich wrote:
> [c] would be nice to be solved at portage level if portage could schedule
> multiple merges for the same package with different USE flags.
Related bugs:
- Portage should be able to auto-flip USE="test" & FEATURES="test"
https://b
On Wed, 18 Dec 2019 22:35:40 +
Michael 'veremitz' Everitt wrote:
> There is some very strange wrapping/formatting in this message, was that
> intentional?
If I had to guess, I'd say the word-wrap length was accidentally set to
"8" instead of "80".
pgpHbspqNJkzy.pgp
Description: OpenPGP di
On Thu, 19 Dec 2019 20:40:26 +0100
Michał Górny wrote:
> The proposal is to add a new dependency type (codename: IDEPEND) which
> indicates dependencies used for pkg_*inst (and pkg_*rm?) phases
Given the nature of this, I somewhat expect this to cover dependencies
required for src_unpack and src
On Fri, 13 Dec 2019 12:50:00 +0100
Alexis Ballier wrote:
> Seems a good candidate for a future EAPI
In theory, there are packages that can execute src_test when USE="test"
is not satisfied.
Just I don't tend to see this in practice.
pgpOyg14m2iTZ.pgp
Description: OpenPGP digital signature
On Fri, 20 Dec 2019 13:54:44 -0500
Mike Gilbert wrote:
> Yes, I think you misunderstand something, but I'm not sure exactly how.
I think the missing part of my understanding might be that IDEPEND
needs to be satisfied by:
- Packages installing binpkg's ( which don't need src_fetch, unpack, etc
On Sat, 28 Dec 2019 08:09:33 +0100
Michał Górny wrote:
> How can we improve this?
Every time this kind of issue comes up, I can't help feeling we need
some sort of tool more advanced than what we currently have.
Something that maintains persistence of keyword demands similar to how
the current
On Sat, 28 Dec 2019 10:35:09 +0100
Fabian Groffen wrote:
> Hmmm, interested to hear what kind of things you're thinking about here.
A lot of the "Work" of filing a keyword request is modelling all the
consequential keywordings that have to take place.
If there was say, a web based UI, that:
-
On Sat, 28 Dec 2019 11:14:15 +
Michael 'veremitz' Everitt wrote:
> I know I'm gonna be shot down in flames, because $heresy, but here is where
> a package 'database' would actually work quite well, because you can
> trivially create a query that pulls this data out, and sorts it by package
>
On Sat, 28 Dec 2019 11:14:15 +
Michael 'veremitz' Everitt wrote:
> I know I'm gonna be shot down in flames, because $heresy, but here is where
> a package 'database' would actually work quite well, because you can
> trivially create a query that pulls this data out, and sorts it by package
>
On Sat, 28 Dec 2019 11:35:49 +
Michael 'veremitz' Everitt wrote:
> Note: we're nnot acttually talking about replacing portage here, just
> creating a tool thiink php script web tthingy)) that will do some of
> the pre-screeninng wok that AT hate (eg what kensiington did with
> s
On Sat, 28 Dec 2019 11:40:08 +
James Le Cuirot wrote:
> Unfortunately a3li used Elasticsearch, which no one understands, but
> it's a start.
And I've used ES enough to say I would rather never use it again.
pgp7mS3HF7Z2A.pgp
Description: OpenPGP digital signature
On Sat, 28 Dec 2019 21:19:18 -0500
Aaron Bauman wrote:
> Ah, you found the Achilles heel. It is much easier to postulate on the mailing
> list, use big words, and then say you just won't do that thing because
> tools/languages such.
>
> Perl though...
FTR: Even though I'm good at Perl, I wouldn
On Sun, 19 Jan 2020 07:08:30 -0500
Rich Freeman wrote:
> The official sources aren't in github. A bugzilla component is
> available, so if github goes away there is no problem and we aren't
> relying on it.
If github goes away after bugs and PR's are filed on github, then that
historical contex
On Sun, 19 Jan 2020 12:31:52 +0100
Michał Górny wrote:
> Enjoy!
Many thanks for making this happen.
pgpkU6bOR1NU6.pgp
Description: OpenPGP digital signature
On Sun, 19 Jan 2020 13:54:33 -0500
Rich Freeman wrote:
> Nothing of importance should be stored on github.
>
> If you and I have a conversation at a bar, and as a result you decide
> to make a commit without any useful comments, and then we both retire
> from the project, just as much informatio
On Thu, 30 Jan 2020 08:19:08 -0500
Rich Freeman wrote:
> Really the main threat (IMO) is that the code could be de-copylefted.
> They could make GPL v4 a copy of the BSD license, and now anything
> that was v2+ is effectively BSD and can be used in non-FOSS software
> without issue. I guess that
On Wed, 26 Feb 2020 15:36:52 +0100
Michał Górny wrote:
> +fdo-mime = xdg-utils
> +games = (none)
Some of these need to have more context. For instance, a comment for
the games one citing -ml discussions about why the eclass is
deprecated, and what you should be doing instead, might be useful
p
On Sat, 07 Mar 2020 17:28:53 +0100
Michał Górny wrote:
> dev-python/fedmsg
Just to buck the trend: Thanks.
When I saw the PR for this with my name in it (due to comaint), I
initially reacted and was going to oppose this removal.
But, well, I thought about it, and the reason this was here in th
On Wed, 18 Mar 2020 11:59:25 -0500
William Hubbs wrote:
> Sure, but if you run into something like that you just don't use the
> noarch keyword for those packages.
But as soon as this happens, all dependent packages that are noarch
will need to also transition to not using no-arch.
So it turn
On Wed, 18 Mar 2020 17:52:25 +
James Le Cuirot wrote:
> Not quite. Tools like repoman will need to be updated to understand
> that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
> only KEYWORDS="noarch". I do think the idea has merit though.
But the inverse is _not_ true,
On Wed, 18 Mar 2020 09:54:42 -0500
William Hubbs wrote:
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
>
> Thanks,
I'm just gonna say I disagree with this proposal as stated.
Stability and arch support, fo
On Thu, 19 Mar 2020 03:07:21 +0100
Thomas Deutschmann wrote:
> Why can't we use "ALLARCHES" stabilization for that?
Because that experiment basically failed.
Bugs with that flag, basically were treated (repeatedly) like that flag
wasn't there.
And that approach still has the weakness of it bei
On Thu, 19 Mar 2020 14:52:08 +0100
Gerion Entrup wrote:
> Maybe I misunderstand something but shouldn't that be the normal case?
> Every single Python package (candidates for noarch) for example depends
> on the Python interpreter, which must have non noarch keywords.
Yeah. So Basically, this p
On 22 February 2015 at 15:35, Daniel Campbell wrote:
> >
> > Personally, I think that controlling who is allowed to run certain
> > types of applications via group membership is a great idea. We
> > should introduce that approach for other applications too. How
> > about an "editors" group? Text
On 22 February 2015 at 18:06, Gordon Pettey wrote:
>
> Protect the permissions on the files, not the editors - there's always
> another way to get content into a file if you have write permission to it.
> If you try to do that with a g+xo-x, then you're going to have to do the
> same for every si
On 6 March 2015 at 09:03, Michael Orlitzky wrote:
> I've settled on using a colon i.e. "jer format." If the bug references a
> specific version (range), then I use =, >=, etc. appropriately. In the
> case of stabilization bugs, I'd throw in the "=".
>
I was under the impression adding "=" was ju
On 15 March 2015 at 11:37, Rich Freeman wrote:
> Suggestions:
> gentoo-repo
> gentoo-repository
> gentoo-main
> gentoo-repo-main
> gentoo-repository-main
>
Similarly in the "solve confusion as to purpose" for newbies:
gentoo-packages
gentoo-ebuilds
The names would be possibly be incorrect und
On 15 March 2015 at 21:54, Dirkjan Ochtman wrote:
> . In that vain, "gentoo-base"
> could also work?
>
I like this idea. I was initially toying with "gentoo-overlay" because it
was more specific than "repo" but it didn't float well because the model
was wrong.
"gentoo-base" however kinda works
On 27 March 2015 at 10:32, Andreas K. Huettel wrote:
> It would be great to logically separate ebuild repositories (main tree and
> overlays) somehow logically from code, data, ...
>
> How about adding an additional level "repo" for everything that contains
> ebuild trees?
>
> repo/gentoo
On 00:29, Sun, 12/04/2015 Michał Górny wrote:
I think the simplest solution would be to develop a generic USE flag
that would only serve the purpose of forcing bundled dependencies for
bootstrapping/initial install.
We have already:
build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!
On 02:36, Sun, 12/04/2015 Andreas K. Huettel wrote:
> > build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for
> > creating build images and the first half of bootstrapping [make
> > stage1]
> >
> > bootstrap - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used
> > duri
On 17 April 2015 at 02:22, Bob Wya wrote:
> Are you maintaining an overlay listed in Layman? If not then it's pretty
> obvious that
> you're just trolling the mailing list and wasting a lot of folk's time...
>
I'm not sure that's the case. Its easy enough to maintain an overlay. Its
easy enough
On 17 April 2015 at 05:27, hasufell wrote:
> To reply to the topic: If the only reason you want to become a gentoo
> developer is "contributing ebuilds", then you should reconsider that,
> because there are easier ways to do that.
> But if you are interested in politics, PMS, EAPI and other
> org
On 18 April 2015 at 02:33, Andrew Savchenko wrote:
> The problem is double effort: previously one developer effort was
> needed, now effort is doubled at least: reviewers must dig into
> details how submitted code works, test it and only then commit. Now
> remember that reviewers are also develop
On 18 April 2015 at 07:14, Justin Bronder wrote:
> Unless the process has changed
> drastically since I joined, the only lengthy part of joining is
> potentially waiting for the recruitment team to catch up on their
> backlog. If someone doesn't have a couple of hours to spend filling out
> the
On 23 April 2015 at 15:07, Duncan <1i5t5.dun...@cox.net> wrote:
> Perhaps the slashdot effect of everybody almost at once needing to delete
> and (re)add their overlays in layman, thus forcing a new clone,
>
Eh? That seems incredibly wrong for git.
git remote set-url master
Would handle the gi
On 23 April 2015 at 21:02, Duncan <1i5t5.dun...@cox.net> wrote:
> with patches already in
> the live-git version, and I believe lessons were learned about
> coordinating repo updates when a major host changes as well, so
> hopefully, if there's a next time it'll go much smoother than this one
> di
On 3 May 2015 at 09:11, Maxim Koltsov wrote:
> LeechCraft has some functionality that is implemented in C++14 and won't
> be available otherwise.
>
Can you clarify the nature of that functionality?
Shouldn't the USE flag be thus in terms of what that functionality is, not
in terms of the depend
On 3 May 2015 at 10:18, Georg Rudoy <0xd34df...@gmail.com> wrote:
> We have "idn" or "gnutls" or "python" etc USE flags after all, not
> "support_international_names_in_blah" or
> "allow_secure_news_fetching_in_foo" or "build_scripting_support_for_baz".
>
> Or I just didn't get you here, sorry me
On 4 May 2015 at 02:04, Georg Rudoy <0xd34df...@gmail.com> wrote:
> Why should the user care if python is supported? What does python support
> per se offer to the user? I would argue that what's important are the
> features exposed via Python stuff (unless the user theyself is expected to
> write
On 7 June 2015 at 00:22, Justin Lecher (jlec) wrote:
> * linewidth >> 80 (why do we have this short limit still in 2015)
I wouldn't say this is the reason... but there's a specific benefit for me
at least with the font size I use and the screen size I have.
Means you can fit 2 terminals in ni
On 5 July 2015 at 17:03, C Bergström wrote:
>
> Again I don't see it as "lying" - (you're still working on stuff until
> you push.. development isn't done) The ability to do micro or
> incremental commits instead of the svn's forced wait approach is the
> benefit here.
Generally its better to st
On 6 July 2015 at 07:15, William Hubbs wrote:
> If you use the hash of a merge commit with "git show", you get nothing, so
> the merge commit is useless in terms of following changes.
git show -m
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
On 6 July 2015 at 08:01, William Hubbs wrote:
> Once we have a version of git stable that allows this, can someone fill
> me in on why we would need to sign commits if we sign pushes? If we have
> a signature on the push, we know where that came from, so it seems to be
> overkill to sign the commi
On 7 July 2015 at 01:48, Peter Stuge wrote:
> fact that a merge commit ideally does *not* contain any
> modifications.
That's not /entirely/ true. The merge commit will have a new TREE
object which is a composite TREE object of both of its PARENT TREE
objects ( But all BLOBs in the resulting TR
On 7 July 2015 at 12:04, Patrick Lauer wrote:
>
> So thanks for your intentional comedy, but let's be serious here.
It would be really nice if we could define some sort of variable in
the ebuild itself with a relative cost metric for the ebuilds install
time. It wouldn't need to be precise, just
On 17 July 2015 at 13:13, NP-Hardass wrote:
> Additionally, I feel that a signature is a means of acknowledging that
> a package has been looked over, and that developer has stated that
> they approve of the existing state
That much is somewhat implied by a developer owning a commit. Because
in
On 17 July 2015 at 22:34, Andrew Savchenko wrote:
> 2. Add an optional feature to emerge (or even to PMS?) allowing user
> to provide a usable GPG key for signing packages CONTENTS files
> after its generation. In order for such key to be usable during
> emerge run, gpg-agent should be used; alter
On 10 August 2015 at 11:46, hasufell wrote:
> As I see it, a lot of people already stuff the bug number into the
> summary and I can't really say anything against that. It gives a nice
> overview when you look at it:
> https://gitweb.gentoo.org/repo/gentoo.git/log/
>
> Given that fact, I am not su
On 10 August 2015 at 13:40, Doug Goldstein wrote:
> $ git push --signed origin master
>
> You need a passphrase to unlock the secret key for
> user: "Doug Goldstein "
> 4096-bit RSA key, ID 0xA2BC03DC87ED1BD4, created 2015-04-24
> (subkey on main key ID 0x6C4E620431C9980D)
>
> gpg: cancel
On 11 August 2015 at 09:05, Matthias Maier wrote:
> We could also provide automatic signed tags every 30min/1h/2h/whatever
> (signed with a suitable infrastructure key). With that, the integrity of
> a tagged git checkout can be easily verified on client side.
I'm distinctly under the impression
On 11 August 2015 at 15:06, Mike Frysinger wrote:
> it would have to re-use the same tag name every time otherwise we end up with
> 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea
I was very much under the impression git is not designed with repeated
tag replication in considera
fs/tags/test
456d216e3d1894d62429daf0ec482c3afb087dbe
git cat-file tag 456d216e3d1894d62429daf0ec482c3afb087dbe
object 9ca77ee7f72902e4e89456ff560a670465969603
type commit
tag test
tagger Kent Fredric 1439264837 +1200
A test tag
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAABCAAGBQJVyXBKAAoJEOhU
On 11 August 2015 at 19:44, Thomas Kahle wrote:
> If somebody knows how to configure pinentry curses correctly (in
> particular with respect to screen/multiplexing and long running
> sessions, that would be a great help (and wiki addition).
I suspect its more a bug in GPG than pinentry, as it ap
On 11 August 2015 at 20:38, Michał Górny wrote:
> Dnia 2015-08-11, o godz. 10:29:55
> Alexander Berntsen napisał(a):
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 10/08/15 22:59, Aaron W. Swenson wrote:
>> > Users can fetch/pull from Github.
>> Users should not have to interfac
On 11 August 2015 at 20:57, Tobias Klausmann wrote:
>
> The cat/pn rule is tricky anyway: what if one commit touches 100
> packages? Or should that be split into 100 commits for easier
> partial rollback?
I think you've misread "The rule"
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_
On 12 August 2015 at 02:28, Ian Stakenvicius wrote:
> Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn:
> adjusted dependencies' are generic (and short) enough yet descriptive
> enough to see what went on while scanning the log.
I personally find those summaries a bit too terse
On 12 August 2015 at 16:21, Ciaran McCreesh
wrote:
> Can't we all (except for the usual suspect) just agree that REQUIRED_USE
> was a mistake, and go back to pkg_pretend? The only justification for
> REQUIRED_USE was that it could allegedly be used in an automated
> fashion, and this hasn't happen
On 14 August 2015 at 07:59, Rich Freeman wrote:
> Will that include any case where the string "$Id$" appears in a patch file?
Surely that can be avoided by using a git attributes specification
that only applies to */*/*.ebuild ?
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
On 14 August 2015 at 17:45, Michał Górny wrote:
> Don't force the implicit expansion on all developers and users forking
> the repo.
You wouldn't, I thought we were talking about $Id$ only being expanded
on the git->rsync transition, and people worrying that $Id$ would be
expanded in patches, wh
On 15 August 2015 at 21:56, Andrew Savchenko wrote:
> And even with current thin-manifest
> workflow there may be conflict if they touch the same files.
They'll be single-line conflicts though, which will mean assuming
different developers touch different files, git will be able to
trivially mer
On 14 August 2015 at 05:37, Ciaran McCreesh
wrote:
> Uh, the point of the 'pretend' bit in the name is that it *is* run when
> you do emerge -p.
It is strange really.
It does them *after* prompting "yes" with --ask
Whats the point of that?
Granted they are very slow for me now with the KDE5 s
On 21 August 2015 at 13:03, Rich Freeman wrote:
> I'd rather see groups like QA making proposals to improve cross-Gentoo
> consistency than see stagnation. It was an RFC, and people can post
> issues with it, or escalate to Council if they're concerned. If
> taking it to Council I'd suggest you
On 21 August 2015 at 19:16, Sergey Popov wrote:
> Now, THAT should be fixed either way - by moving 'dedicated' to
> 'server'(for those packages), or, preferabbly - by allowing
> USE='dedicated' to work as hasufell said - build ONLY dedicated server
> and no client at all.
Another compromise that
On 30 August 2015 at 07:53, Matt Turner wrote:
>
> Is there a better way of directing reporters to file bugs upstream? Of
> course it's not always clear whether a bug is an ebuild bug or
> something easily patched in Gentoo vs a driver bug that requires an
> upstream developer...
I've always see
On 30 August 2015 at 19:20, Daniel Campbell wrote:
> Quick question: what is RT?
>
RT is rt.cpan.org, for which every cpan distribution that gets
published gets a free bug tracker there
where permissions assigned to that bug tracker reflect permissions
granted under the CPAN authority scheme.
-
On 30 August 2015 at 21:37, Duncan <1i5t5.dun...@cox.net> wrote:
> In addition to the other services a distro provides, a big one is having
> one single place to file bugs, instead of a couple hundred different bug
> tracker accounts on a half-dozen tracker software bases, and that's not
> even cou
On 31 August 2015 at 00:15, Peter Stuge wrote:
> In theory it can, but my experience is that in practice it doesn't
> change very often.
>
>
>> sometimes the metadata visible on the CPAN sources is also wrong,
>> and requires an experienced developer to chase its tail to work out
>> where it curre
On 3 September 2015 at 07:17, Paweł Hajdan, Jr. wrote:
> Do you have specific examples?
None that I can currently recall, I've just long resigned myself from
trying to care with Google products. The instances I can recall were
more defects in their web services, some where there was literally no
On 5 September 2015 at 01:12, Aaron W. Swenson wrote:
> Would you consider dropping the TZ offset? If the script were to translate
> the DT to UTC, that'd remove some noise and shorten the line by 5.
+1
> dev-java/antenna 2015-09-03 13:45:07Z monsieurp b4215f4
>
> And I know
On 5 September 2015 at 06:51, Michał Górny wrote:
>> information. How else would we determine this?
>
> PGP key matching?
/.mailmap
git help shortlog -> MAPPING AUTHORS
This system allows displaying committers under spellings/aliases/email
addresses other than the one they committed as for an
On 8 September 2015 at 00:35, Marc Schiffbauer wrote:
> I currently have this case in app-backup/obnam which is not compatible
> to =dev-python/paramiko-1.13.0
>
> In DEPEND I now have this:
>
> !=dev-python/paramiko-1.13.0
> || ( dev-python/paramiko-1.13.0 )
>
> which does the trick, but I th
On 8 September 2015 at 03:26, Marc Schiffbauer wrote:
> And as the cherry on the cake theere could be
>
> <> ( foo/bar-1 foo/bar-5 )
I kinda tried suggesting a similar syntax, but then I realised it
couldn't work, because it implicitly says "none of these" but it
doesn't state any sort of "Pull
On 13 September 2015 at 09:15, hasufell wrote:
> Because that is not a valid bug report. Patches must be attached to
> bugzilla.
I would recommend against attaching the pull in patch form against
bugzilla. It might lead to unintentionally misleading consequences.
If the patch is automatedly fil
On 14 September 2015 at 16:35, konsolebox wrote:
> Many times we need to match packages like this: something-1.0.2a.*
>
> But that expression is not allowed with ~ (only targets revisions) and
> neither with * (.*) is invalid.
What does =cat/pkg-something-1.0.2a* do? ( note, lack of . before *
On 14 September 2015 at 18:09, konsolebox wrote:
> Because they could also match pkg-1.0.2aa
I don't believe it works that way.
That would imply
=pkg-1.0.2* would match 1.0.20
When it only matches 1.0.2 and 1.0.2.*
You're reading it in shell glob notation and not the portage notation,
that t
On 14 September 2015 at 18:52, Ulrich Mueller wrote:
> It does, in fact.
>
>> When it only matches 1.0.2 and 1.0.2.*
>
>> You're reading it in shell glob notation and not the portage notation,
>> that the trailing dot is *implied*,
>
> No, there isn't any dot implied. It uses simple prefix compari
On 14 September 2015 at 20:01, Ulrich Mueller wrote:
>=cat/foo-1.020.3
>=cat/foo-1.020.3*
>=cat/foo-01.02.3*
Of those, I only expect the last to match, because leading 0's are not
typically significant.
However, that "=dev-lang/perl-05.22*" matches dev-lang/perl-5.22.0 but
"=dev-lan
On 14 September 2015 at 20:01, Ulrich Mueller wrote:
> We could fix this in a future EAPI such that version components would
> not be split when matching. So =1.3* would not match 1.30 any more
> because the 30 could only be matched as a whole.
>
> OTOH, I am not aware of any problems caused by th
On 14 September 2015 at 20:22, konsolebox wrote:
> If we use an arithmetic operator like ~> then that could be decided
As a counter proposal I'd suggest a different suffix character than
"*" instead. It just seems less confusing to have something like
=cat/foo-1.30+
Instead of
~>cat/foo-1.30
On 14 September 2015 at 21:04, Ulrich Mueller wrote:
> Well, version comparison is described in [1] and it says that
> =cat/foo-1.020.3 will match cat/foo-1.02.3.
Surely, as per Algorithm 2, that is false, because "020" and "02" are
both integers, and therefor they'd default to integer comparison
On 14 September 2015 at 21:04, Ulrich Mueller wrote:
> Could someone check what is Paludis's behaviour for the examples
> above? Also, does =cat/foo-1.2* match cat/foo-1.20 in Paludis?
Portage:
emerge --ignore-default-opts -vpO =dev-lang/perl-5.2*
These are the packages that would be merged,
On 14 September 2015 at 23:38, Ulrich Mueller wrote:
> Comparison in Algorithm 2 only takes place for the zeroth component
> (i.e., "1", for the example above).
>
> For all following numeric components Algorithm 3 is called. For the
> next component, the condition in line 1 is true, so it will rem
On 15 September 2015 at 06:54, Ulrich Mueller wrote:
>
>> I think it'd be okay to e.g. change the meaning and behavior of * in
>> a new EAPI.
>
> Bug 560466 now.
Assuming the syntax can be changed in a future EAPI.
What EAPI applies to the use of these specifiers on the command line?
What EAPI
On 16 September 2015 at 19:40, konsolebox wrote:
> And I find it so wrong that it makes me think that it shouldn't have
> been acknowledged by any packaging system. That versioning madness
> should have been just fixed in the ebuilds level.
Yeah. My experience with versions is its better to hav
On 19 September 2015 at 10:09, konsolebox wrote:
> As for A6FGHKE and TRIAL, it's impossible to tell their actual level
> values so even if we choose to map them lexicographically, we would
> still not be able to use a universal algorithm that could tell how it
> affects the base version (just lik
701 - 800 of 875 matches
Mail list logo
