On Wed, 11 Nov 2020 19:38:35 -0500
Rich Freeman wrote:
> I just host stuff like that on my dev webspace, or better yet on
> github or something else that will auto-tarball stuff.
Oh, yeah, and don't rely on github auto-tarball stuff.
History has demonstrated github sometimes "forgets" their cac
On Wed, 11 Nov 2020 19:38:35 -0500
Rich Freeman wrote:
> I thought that the whole mirror:// thing was discouraged. For
> anything else you just stick SRC_URI in the ebuild and the mirrors
> should fetch it when they see it in the repo.
>
> I just host stuff like that on my dev webspace, or bett
On Mon, 9 Nov 2020 12:15:07 +0200
Jaco Kroon wrote:
> You mentioned working raport with upstream? Can we rely on that to at
> the very least get them to update that to "due to the way Gentoo
> functions we request that you first file issues with the Gentoo
> repository rather than directly with
On Wed, 4 Nov 2020 17:34:07 +0100
Marek Szuba wrote:
>> x11-terms/rxvt-unicode
> Will co-maintain this one with conikost, don't mind being listed as
> primary maintainer.
If you strike an issue that you think should be followed upstream, rope
me in. (put me on the bottom of the maintainer list
On Mon, 02 Nov 2020 00:05:34 +
"Robin H. Johnson" wrote:
> The attached list notes all of the packages that were added or removed
> from the tree, for the week ending 2020-11-01 23:59 UTC.
>
> Removals:
<3MB of data trimmed>
It looks like you reported all added and removed packages for th
On Sun, 18 Oct 2020 11:41:38 +1300
Kent Fredric wrote:
> Uh, do we need a new catagory for this one package?
Scratch that, my brain is disabled and my eixing failed the first time
and I jumped because it was a category with no recollection of seeing
before.
Now I see there is one, I do st
On Sat, 17 Oct 2020 18:05:40 -0400
Aisha Tammy wrote:
> gui-libs/display-manager-init
Uh, do we need a new catagory for this one package?
pgp0al5IKutdA.pgp
Description: OpenPGP digital signature
On Tue, 6 Oct 2020 20:55:25 +
Max Magorsch wrote:
> Further customization options are available on the preferences pages.
> Feel free to let me know if you are missing anything. Apart from that:
> Happy customizing.
>
> /M
This is awesome \o/
Though I may have spotted a bug or two.
When y
On Wed, 16 Sep 2020 16:05:49 -0600
Tim Harder wrote:
> Speaking for myself, I avoid hosting most of my Gentoo-related work
> (outside of gentoo repo ebuild mangling) on gentoo.org since I prefer
> the services offered elsewhere in terms of usability, visibility, and
> project maintenance. Take th
On Wed, 16 Sep 2020 19:47:35 -0400
Rich Freeman wrote:
> Seems like a way to improve this would be better documentation and a
> DIY infra testing platform.
>
> First, document how to prepare a service for infra hosting. Maybe
> provide an example service.
>
> Second, publish a tarball of a con
On Wed, 16 Sep 2020 07:11:12 -0400
Rich Freeman wrote:
> I realize this is a bit more tangential. I just think that infra is
> already a huge failure point, so having more stuff on infra actually
> makes that failure point more critical. A Gentoo where little is
> hosted on stuff we own is much
On Mon, 14 Sep 2020 10:15:31 -0400
Rich Freeman wrote:
> It might be easier to take smaller steps, such as having a policy that
> "any call for devs to use/test a new tool/service, or any service that
> automatically performs transactions on bugzilla, must be FOSS, and the
> link to the source mu
On Tue, 15 Sep 2020 09:12:58 +0200
Toralf Förster wrote:
> However this doesn't cover bugs filed a while ago and are not be fixed in
> current stable.
A mitigation would be it wouldn't file a stabilization req if there was
already one open.
Basically means as soon as there's one stable req, it
On Sun, 13 Sep 2020 12:04:39 -0700
Alec Warner wrote:
> Is openrc critical to Gentoo? it doesn't live on our infra.
> Is pkgcore critical to Gentoo? it doesn't live on our infra.
Both those things are "things employed by users for their systems".
Neither of those things are integral to any work
On Mon, 7 Sep 2020 08:14:52 +0200
Michał Górny wrote:
> However, please
> +do not include it in the package.mask entry as users do not need
> +to be forced to proactively unmerge it.
I can think of a utilitarian value of doing this anyway.
Namely, it gives a window during `emerge -uD @
On Thu, 3 Sep 2020 14:49:25 +0100
Michael 'veremitz' Everitt wrote:
> I know this is a much more onerous "solution" but I thought I would throw
> it out there, and see if any other interested parties (eg. kent\n and
> potentially graaff) may be able to share their thoughts..
Actually, the more I
On Tue, 1 Sep 2020 08:47:12 -0400
Michael Orlitzky wrote:
> Here's a trick that bugzilla cannot do: show me the bugs that are
> assigned to me **or a project that I'm a member of**. Killer feature
> right there.
Something bugzilla also doesn't do:
Automatically search for "dev-foo/bar" in cf_st
# Kent Fredric (2020-08-17)
# No reverse dependencies, and Gtk support is becomming
# obsolete in Gentoo
# Removal in 30 days
dev-perl/gnome2-vfs-perl
pgpZCAMkQcO9D.pgp
Description: OpenPGP digital signature
On Tue, 28 Jul 2020 19:17:04 -0400
Aaron Bauman wrote:
> net-irc/quasselgrep
Uh, what?
[I] net-irc/quasselgrep
Installed versions: 0_p20190211(13:18:43
18/07/20)(PYTHON_TARGETS="python3_7 -python3_6")
Maybe just the older version?
pgpZibCoYPFgd.pgp
Description: OpenPGP digital signatu
# Kent Fredric (15 Jul 2020)
# No LICENSE declaration by upstream, and no response from upstream
# since at least 2013 as to what license to use (bug #732710)
# Removal in 30 days.
dev-perl/Data-Diver
pgp9YHMIAr5i9.pgp
Description: OpenPGP digital signature
# Kent Fredric (2020-07-10)
# No reverse dependencies, and Gtk2 support is becomming
# obsolete in Gentoo.
# Removal in 30 days
pgpqlJgLDz9hL.pgp
Description: OpenPGP digital signature
On Wed, 8 Jul 2020 20:48:44 +1200
Kent Fredric wrote:
> The "easy" workaround is to use `dev-perl/Gentoo-PerlMod-Version`, and
> have it munch upstreams version into a "gentoo normalized version", and
> then use that version for comparison.
Actually, on that note
On Wed, 8 Jul 2020 09:40:17 +0100
Alexey Sokolov wrote:
> Another comment, unrelated to the new features: RESTRICT="test?
> (test)" probably shouldn't trigger the T symbol the same way as
> RESTRICT="test" does.
+1.
This presently has bothered me, because it basically means with the
roll-out o
On Wed, 8 Jul 2020 02:57:57 +
Max Magorsch wrote:
> - all outdated packages (according to repology)
Unfortunately for Perl, repology can't be taken verbatim.
There's a really fun problem with Perl versions, so I'll link you to
our writeup to explain it:
https://wiki.gentoo.org/wiki/Proje
On Wed, 8 Jul 2020 02:57:57 +
Max Magorsch wrote:
> Additionally, there are new sites for all package maintainers, that is:
> - Gentoo Projects (e.g. pyt...@gentoo.org)
> - Gentoo Developers (e.g. la...@gentoo.org
> - Proxied Maintainers (e.g. la...@the-cow.de)
Some other thoughts her
On Wed, 8 Jul 2020 02:57:57 +
Max Magorsch wrote:
> I am glad to announce further progress at packages.gentoo.org (pgo in
> the following). Compared to previous work during the last months,
> which mostly addressed the back end, the new changes are rather
> comprehensive. That's why I am look
On Sun, 28 Jun 2020 08:18:23 -0400
Michael Orlitzky wrote:
> With LD set to something libtooly in the
> environment, the pari build fails. We can solve that by unsetting LD in
> the ebuild, but for that to be The Right Thing To Do, we should be
> expecting LD to contain something libtooly, and th
On Fri, 12 Jun 2020 09:24:11 -0700
Georgy Yakovlev wrote:
> Not sure if --features=default will activate default set and how it
> will react to being passed along.
>
> --no-default-features --features default
> IDK, looks kinda unnatural.
>
> I have a feeling that we'll get more boilerplate if
On Fri, 12 Jun 2020 02:04:51 -0700
Georgy Yakovlev wrote:
> +#cargo_src_configure --no-default-features
Looking at the source, I don't see how this is passed from this command to
anything.
> + # transform array from simple feature list
> + # to multiple cargo args:
> + # --feat
On Wed, 10 Jun 2020 20:25:20 +0200
Michał Górny wrote:
> The general purpose of codec project [2] is to maintain core libraries
> for various multimedia format encoder/decoder libraries. It's like
> gfx+sound+video except only for core packages and not every possible
> single viewer, player, edi
On Sun, 7 Jun 2020 06:43:19 -0400
Rich Freeman wrote:
> Historically a lot of projects worked more like "tags" as an
> alternative way of grouping packages other than categories. While
> tags are a great idea projects are a terrible way to implement them.
I was thinking perhaps instead of "grou
On Sun, 24 May 2020 13:05:35 +
Peter Stuge wrote:
> The bar only needs to be raised high enough.
Sure. A lot of this is just "think about what could happen in the worst
case imaginable".
Its very unlikely our worst cases will happen.
But we should at least have the ability to easily add mi
On Sun, 24 May 2020 10:33:18 +0200
Michał Górny wrote:
> If it creates an invalid environment that is known to break packages
> and is not QA-sanctioned, it should be masked. Period.
Seems like yet another argument in favour of my initial position, that
it probably shouldn't be controlled by a
On Sat, 23 May 2020 22:41:02 -0400
Mike Gilbert wrote:
> Could you please add this flag to package.use.force? I don't think we
Sounds more like a case for package.use.stable.force or something.
For non-stable, we don't give guarantees about well-supported, only
that there will be bugs, and they
On Sun, 24 May 2020 09:40:50 +0800
"Pengcheng Xu" wrote:
> Do we currently have (or is there a plan for) a mechanism to manage the
> symbolic links and/or create them after merging the package when necessary?
> It's quite tiresome to type in $CHOST-gcc for simple everyday tasks.
There are (cu
On Fri, 22 May 2020 21:58:54 +0200
Michał Górny wrote:
> Let's put it like this. This thing starts working. Package X is
> broken, and we see that almost nobody is using it. We remove that
> package. Now somebody is angry. He submits a lot of fake data to
> render the service useless so that
On Fri, 22 May 2020 22:13:11 +
Peter Stuge wrote:
> While services such as reCAPTCHA are (as said) massively intrusive, there
> are other, much less intrusive and even terminal-compatible ways to construct
> a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle
> for a
On Fri, 22 May 2020 12:53:03 -0700
Brian Dolbec wrote:
> We cannot exclude overlays which will have cat/pkg not in the main
> gentoo repo. So, we should not excludea submission that includes a few
> of these. They would just become irrelevant outliers to our
> processesing of the data. In fact
On Thu, 21 May 2020 10:47:07 +0200
Michał Górny wrote:
> Other ideas
> ===
> Do you have any other ideas on how we could resolve this?
And a question I'd like to revisit, because nobody responded to it:
- What are the incentives a would-be spammer has to spam this service.
Services tha
On Fri, 22 May 2020 01:38:02 +1200
Kent Fredric wrote:
> So instead of the ID being generated locally, you'd send a request
> asking for an ID, it would send you the challenge math, you'd send the
> answer, and then you'd get your ID.
Additionally, you could even al
On Thu, 21 May 2020 15:16:12 +0200
Michał Górny wrote:
> Isn't the whole point of salted hash to use unique salts?
You'd thinik so, but I've seen too many piece of code where the salt
was a hardcoded string right there in the hash generation.
md5sum( "SeKrIt\0" + pass )
So I've learned to nev
On Thu, 21 May 2020 10:47:07 +0200
Michał Górny wrote:
> An alternative of using a proof-of-work algorithm was suggested to me
> yesterday. The idea is that every submission has to be accompanied with
> the result of some cumbersome calculation that can't be trivially run
> in parallel or optimi
On Thu, 21 May 2020 14:25:00 +0200
Ulrich Mueller wrote:
> That's why I said salted hash.
Even a salted hash becomes a trivial joke when the input data you're
hashing has a *total* entropy of only 32bits.
You at very least need a unique salt per hash, or you only have to
expose the salt to crea
On Tue, 19 May 2020 13:27:40 +0200
Michał Górny wrote:
> gander --submit
The server replied (500):
Server Error (500)
Server Error (500)
Submission failed.
pgpLOndd9Coih.pgp
Description: OpenPGP digital signature
On Thu, 07 May 2020 09:29:36 +0200
Michał Górny wrote:
> For example, if OCaml bindings on some package are broken and require
> a lot of work, I would find useful to know how likely it is that anyone
> is using it. Or if a lot of people are enabling 'frobnicate' flag,
> I could consider employi
On Sat, 09 May 2020 15:22:52 +0200
Gerion Entrup wrote:
> I'm not sure, if Portage is capable of this, but a distinction in USE
> flags needed to fulfil some dependency of another package and USE flags
> actively activated by the user could be useful.
Presently impossible, as how portage impleme
On Fri, 8 May 2020 09:49:18 +0200
Jaco Kroon wrote:
> So we do need the full list of packages installed, filtered to ::gentoo,
> but there needs to be an indicated whether it's installed because it's
> in @world, as a dep of something in @world (which is possibly not in
> ::gentoo), or is some fo
On Thu, 23 Apr 2020 10:32:41 +1200
Kent Fredric wrote:
Ugh. I just discovered this approach is in use in multiple packages.
https://metacpan.org/source/LDS/AcePerl-1.92/DISCLAIMER.txt
https://metacpan.org/source/LDS/Bio-SamTools-1.00/DISCLAIMER
https://metacpan.org/source/AVULLO/Bio-DB-HTS
On Tue, 5 May 2020 02:47:48 +0200
Thomas Deutschmann wrote:
> Yes it would be a signal but a useless signal, not?
"There are no users reported using this dist, so we can nuke it" is
still far far superior to "there are no reverse dependencies, so we can
nuke it"
*Even* when the former is false
On Mon, 27 Apr 2020 09:43:44 -0400
Mike Gilbert wrote:
> He was replying to me. Your master connection will continue to work
> just fine, as I said in my previous message.
I must have lost something in grammar, because no matter how many times I read:
> If you are authenticating that master con
On Sun, 26 Apr 2020 18:00:19 -0700
Alec Warner wrote:
> This is correct.
Surely then, this is a reduction in fuctionality.
That's a handy tool to put up your sleeve when you're trying to avoid
getting thrashed by slow network connects when some contributor is
pushing every 30 seconds :)
pgp6H
On Sun, 26 Apr 2020 10:52:27 +0200
Michał Górny wrote:
> Do you have any other idea for spam protection then?
What is the realistic risk here for spamming?
If the record is well formed, and pertains to known packages, the worst
I currently imagine is astroturfing: A single individual attempting
On Sun, 26 Apr 2020 03:39:24 -0700
Brian Dolbec wrote:
> We would need that
> person/team to only enable their test system for gentoostats/disabled
> for deployments. Repeated failure to do that could result in that uuid
> being blacklisted. Part of the initial profile details for that
> vm/ima
On Sun, 26 Apr 2020 14:38:54 +0200
Thomas Deutschmann wrote:
> Let's assume we will get reports that app-misc/foo is only installed 20
> times. If you are going to judge based on this data, "Obviously, nobody
> is using that package, it's stuck on ... safe to remove" your
> view is biased:
I see
Advantages:
- {{package}} template can link to this as well as the page on
packages.gentoo.org when it exists
- packages.gentoo.org can link to this when it exists
- Serves as a good default place for "maintainer down" and
inter-maintainer documentation.
- Good place to document the sorts of
On Sun, 26 Apr 2020 10:08:32 +0200
Michał Górny wrote:
> A proper solution to cluster problem would probably involve some way to
> internally collect and combine data data before submission. If you have
> large clusters of similar systems, I think you'd want to have all
> packages used on differ
On Sat, 25 Apr 2020 14:12:02 -0700
Alec Warner wrote:
> Thus I now plan to remove this access[0]. If you need access to ssh as
> something not-git to git.gentoo.org, let me know in the next week.
Will this affect people who set up no-op SSH connections for a
persistent connection master, so that
I've just discovered dev-perl/Ace has some fun questionable licensing
which includes a lovely indemnity clause, which had previously gone
unnoticed, and it stipulates additional requests for research
publications, which is not something mentioned in any license currently
in tree other than Tinker
On Sat, 11 Apr 2020 21:41:58 +0100
Samuel Bernardo wrote:
> loosing ebuilds (we
> wants it!... we needs it must!... my precious)
Ebuilds are never actually "lost".
If you use gentoo's git repo for /usr/portage, you can always wind back
the whole tree, or some subset thereof, to a state where t
On Sun, 12 Apr 2020 10:43:07 +0200
Agostino Sarubbo wrote:
> In case of 'yes', the arch team member must compile with FEATURE="test" and
> he
> is allowed to block the stabilization in case of test-failure.
>
> In case there will be a test-failure there are two choices:
> 1) The maintainer fix
On Sat, 11 Apr 2020 11:39:21 -0400
Michael Orlitzky wrote:
> I've been setting them just in case someone has a workflow/automation
> involving the keywords that hasn't been updated in ten years. If you
> kill the keywords, I wouldn't have to worry about that, so +1.
And that's pretty much the sa
On Fri, 10 Apr 2020 12:31:19 +0100
Samuel Bernardo wrote:
> - if there is more then X new versions in upstream, get from a release
> feed associated with ebuild (X value defined by project leader with
> threshold set by CI)
This is probably the biggest difficult part really.
There's lots of dif
On Wed, 8 Apr 2020 17:39:54 +
Peter Stuge wrote:
> E.g. for auditing the installed values of these could be worth a lot.
Only as far as analyising "why was this package installed, currently
the metadata says its un-audited!".
But for things like "affected by CVE/Bug", the very nature of tho
On Tue, 07 Apr 2020 14:44:04 +0100
Roy Bamford wrote:
> Gentoo must not single out any package for special treatment.
Indeed. Cases like this just demonstrate that something about the way
we do things is somehow inadequate.
The idea that "what we have works" is something we get away with,
becau
On Tue, 7 Apr 2020 12:47:33 +0200
Thomas Deutschmann wrote:
> Sure, that could have banal reasons like "No one audited the Linux
> version yet". But in security you don't issue warnings if you aren't
> sure. Because if you make false statements people will no longer trust
> you. But trust is ever
On Mon, 6 Apr 2020 23:55:07 +0100
Samuel Bernardo wrote:
> This is the kind of useful information that we could collect from the
> QA, extending the greatness of the best distro ever made. The
> availability of software from a distro is better than installing it
> standalone, allowing to share kn
On Sun, 5 Apr 2020 17:11:01 +0100
Samuel Bernardo wrote:
> Sorry about my comment, but couldn't that be solved choosing the right
> profile or opting for an official overlay, raking the assurance level of
> those?
If zoom is a binary only package, not opensource, we can't make any
assurances.
E
On Thu, 2 Apr 2020 10:01:57 +0200
Michal Prívozník wrote:
> Alternatively, you can set up a VM that contains nothing but the bare
> minimum required to run app X and assign webcam to it, for instance.
> Having said that, I'd still love the packaging system to install the app
> as it resolves all
On Wed, 1 Apr 2020 17:53:39 -0700
Alec Warner wrote:
> you cannot accept arbitrary long
> passwords
Sure you can, as long as you're not storing them anywhere, and are
instead, storing their checksum of some kind.
Then the only limitations really are how much memory and time you have
to locally
On Mon, 23 Mar 2020 20:27:51 +0200
Joonas Niilola wrote:
> AFAIK all major changes have been posted here and pushed with some delay.
In my experience, "Some delay" is usually short, as developers making
the change are eager to push it through.
But the people maintaining the overlays are much mo
On Sun, 22 Mar 2020 15:11:23 +0100
"Haelwenn (lanodan) Monnier" wrote:
> I think it might be better to fix bugzilla to be able to send multiple
> attachments at once. AWS S3 might be okay for the long term but I've often
> seen paste services being used and most of them expire in a week/month,
On Sat, 21 Mar 2020 11:03:19 +0300
Alexander Tsoy wrote:
> Binary distros usually have separate repositories for each
> architecture.
One aspect: They don't have a package database that's a collection of
bash scripts that have to be routinely executed.
And they also don't have USE flags to comp
On Thu, 19 Mar 2020 15:40:20 -0400
Mike Gilbert wrote:
> I'm not sure what you mean by "stabilization graph". I'm guessing you
> mean the dependency graph for stable keywords?
>
> Valid dependency graphs are determined by whatever our tooling deems
> valid. The tooling could be updated to permit
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 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 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 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 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 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, 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 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 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 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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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: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
1 - 100 of 875 matches
Mail list logo
