On 3 January 2012 01:58, Rich Freeman wrote:
> On Mon, Jan 2, 2012 at 6:47 AM, Sven Vermeulen wrote:
> > And how does dracut know which files it needs to mount my /usr?
>
> I assume based on the selection of modules that you enabled when
> building/running it.
>
> I believe dracut builds static
2012/1/5 Ulrich Mueller
>
> > On Wed, 4 Jan 2012, Michał Górny wrote:
>>
> There's really nothing pointless or blurry about this separation.
> The FHS has a nice definition: "The contents of the root filesystem
> must be adequate to boot, restore, recover, and/or repair the system."
>
Given t
On 13 February 2012 21:35, Markos Chandras wrote:
> This field wont be useful to users but to GUI applications that want
> to show a pretty name instead of a weird PN. It would be fully
> optional but it would have a standard syntax. You can't use
> for that to extract the real package name becau
On Tue, 3 Jul 2018 12:39:43 -0500
William Hubbs wrote:
> I don't care that we have a wiki, but can we please look into killing
> mediawiki and look at something with a git backend? It would be very
> nice to be able to edit wiki pages in markdown or another similar format
> and use git to control
On Wed, 4 Jul 2018 12:44:11 -0500
William Hubbs wrote:
> Yes I would benefit from this change, but it is not a case of optimizing
> for one. It is a case of opening up the use of the wiki to the largest
> audiance possible. This is just good universal design.
Unfortunately, my experience with w
On Fri, 06 Jul 2018 01:55:32 +0200
Gerion Entrup wrote:
> Would it possible to take the bare repo (< 600 MB) and only mount the latest
> checkout (with fuse eg)?
That would incur performance problems, because packed objects are
stored as differences to other objects ( similar to how later piece
On Thu, 5 Jul 2018 12:44:42 -0500
William Hubbs wrote:
> Have you even looked at gollum for example? it can support mw markdown.
I've looked at it, but none of my reading of online material indicates
whether it supports more than the existing media-wiki *syntax*.
For instance, Gollum states sup
On Thu, 5 Jul 2018 12:32:20 -0500
William Hubbs wrote:
> I looked at this first, and it is very hard on the server.
> Every pull or clone you do to update things works like an initial clone,
> so it takes pretty massive resources.
Surely, then the recommended approach involves:
1. Selecting pag
ing at Oct 2015, but git
shows my first commit in July 2016?
git log --reverse --committer=ken...@gentoo.org| head -n 10
commit 320e968c60cbdb948aeff915f2405bcc4d1d0967
Author: Kent Fredric
Date: 2016-07-09 19:26:39 +1200
git log --reverse --author=kentfred...@gmai
On Mon, 09 Jul 2018 10:40:22 +0200
Michał Górny wrote:
> Hi,
>
> We currently don't enforce any particular standard for e-mail addresses
> for developers committing to gentoo.git. FWICS, the majority of
> developers is using their @gentoo.org e-mail addresses. However, a few
> developers are u
On Thu, 12 Jul 2018 08:35:57 +0200
Michał Górny wrote:
> ...and the git hook would've rejected them because they aren't signed
> by a Gentoo developer.
Fair enough. I suspect in line with the other comments, it would be
optimal if said commit hook mentioned something along the lines of:
"Perha
On Wed, 18 Jul 2018 13:47:03 +0100
"M. J. Everitt" wrote:
> - Line one is limited to / and some Key Word that defines
> the type of change made, similar to bugzilla perhaps eg. "REVBUMP,
> VERBUMP, EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get
> around the issue of long package-name
On Wed, 22 Aug 2018 07:26:24 -0500
Ben Kohler wrote:
> Thoughts?
Is there a good reason we can't have a legacy profile for this?
Or perhaps, a new (exp) arch entirely dedicated to legacy x86?
The latter would be ideal for ensuring everything we *claim* works on
i486 does indeed work there, and
On Tue, 21 Aug 2018 22:29:29 -0400
Mike Gilbert wrote:
> Setting RESTRICT="!test? ( test )" is generally sufficient.
But that would require setting that virtually *everything* that has
both tests, and required dependencies for tests.
Which, in my experience, is practically everything with tests
On Fri, 24 Aug 2018 10:13:42 -0400
Rich Freeman wrote:
> I think an exp arch is also overkill. How many packages simply can't
> be built for i486? I think a profile+masking makes a lot more sense
> than an entire new level of QA that touches every ebuild in the tree
> because there might be a f
On Fri, 24 Aug 2018 10:27:01 -0400
Mike Gilbert wrote:
> If you want to define behavior that can be relied upon in ebuilds, it
> should be specified in PMS. PMS does not define any meaning for the
> "test" USE flag.
We should eschew idealism about how the world *should* behave, and avoid
making
On Sat, 22 Sep 2018 15:36:23 -0500
Matthew Thode wrote:
> My hand slipped. What ever happened to assuming the best :( Are you
> going to ping the list every time my hand slips up and I mistype
> something? Not sure you'll have time for it :P
Personally, I would love it if more people tried har
On Sun, 23 Sep 2018 17:45:27 -0500
Matthew Thode wrote:
> On 18-09-24 09:27:57, Kent Fredric wrote:
> > On Sat, 22 Sep 2018 15:36:23 -0500
> > Matthew Thode wrote:
> > > My hand slipped. What ever happened to assuming the best :( Are you
> > > going to ping
On Mon, 24 Sep 2018 10:59:40 -0400
Alec Warner wrote:
>
> So e.g.:
>
> "Bump to x.y.z for bug 12345"?
>
> Is there an annotation for "this commit is relevant to bug X, but does not
> close bug X?"
>
> I'm less sure we need the metadata all in the summary (because its supposed
> to be a summar
On Mon, 24 Sep 2018 07:59:46 +0200
Michał Górny wrote:
> I'm against dumb timeouts. Good timeout = die if nothing happens for T.
> Bad timeout = die if process doesn't finish for T (yet it may still be
> doing something).
Could you perhaps adjust it so that when the timeout limit is exceeded,
On Wed, 17 Oct 2018 16:14:37 +
Michał Górny wrote:
> Dnia October 17, 2018 4:03:17 PM UTC, Michael Haubenwallner
> napisał(a):
> >On 10/15/2018 08:05 PM, Michał Górny wrote:
> >> On Mon, 2018-10-15 at 13:34 +0200, Michael Haubenwallner wrote:
> >>> Hi,
> >>>
> >>> in pkg_nofetch, beyond
On Sat, 20 Oct 2018 12:41:03 +0200
Michał Górny wrote:
> We seem to have a lot of global flags that are used only by a few
> packages. How about moving them to local flags? List of flags with
> less than 5 packages using them, ordered by use count, follows. Where
> applicable, local flag descr
On Sun, 18 Nov 2018 12:00:48 +0100
Fabian Groffen wrote:
> Your point is that the format is broken (== relies on obscure compressor
> feature). My point is that the format simply requires a special tool.
> The fact that we prefer to use existing tools doesn't imply in any way
> that the format i
On Tue, 27 Nov 2018 15:10:36 -0500
Rich Freeman wrote:
> Also, GLEP 76 as it is written says: "Projects using this scheme must
> track authorship in a VCS, unless they list all authors of
> copyrightable contributions in an AUTHORS file."
Idea: How about using VCS as a defacto set of AUTHORS, bu
On Tue, 27 Nov 2018 12:51:00 -0500
Rich Freeman wrote:
> As others have pointed out, it seems like other projects are moving
> away from AUTHORS files in favor of git.
"Other projects" don't typically have repos so large that a simple
application of a git filter-branch could take weeks.
That
On Tue, 27 Nov 2018 16:01:15 -0500
Rich Freeman wrote:
> Our repo is a linked list being constantly manipulated from the head
> backed by a hashed object store for the contents. For that use case
> it is probably the ideal data structure. Since our use case is
> actually the typical use case, i
On Wed, 28 Nov 2018 10:11:32 +1300
Kent Fredric wrote:
> Just don't try using filter branch on a whole gentoo repository, you'll
> quickly learn why. ( You'll find yourself having to employ lots of
> tricks with git fast-export instead just to avoid projected times in
On Mon, 03 Dec 2018 14:29:12 -0500
Craig Andrews wrote:
> Should the tracker have 0 issues blocking it?
Yes, because setting a date won't put a fire under upstreams ass.
And I imagine lots of the blocking status is in upstreams hands.
( I mean, if we can fix it ourselves, great, but if we were
On Fri, 14 Dec 2018 18:00:55 -0800
Georgy Yakovlev wrote:
> Good candidates for adding to that file are:
>
> virtual/rust
> llvm ?
> dev-util/meson
> dev-util/ninja
I'm really not sure these are widespread enough to justify putting
those details in the ouput of every emerge --info.
Instead, it
On Fri, 14 Dec 2018 15:04:22 +0100
Jeroen Roovers wrote:
> According to Nvidia these are former "Short Lived" branches that are no
> longer supported.
>
>
> # Jeroen Roovers (14 Dec 2018)
> # Deprecated short lived branches
> # https://www.nvidia.com/object/unix.html
> # File a bug report if y
On Sun, 16 Dec 2018 20:41:49 +0100
Jeroen Roovers wrote:
> No, 390.87 is the latest for your chip and is not masked for removal.
>
> The 396 branch has seen no updates since 10 April 2018 while the 390
> branch was last updated on 27 August 2018. Higher major versions do not
> mean you have some
On Thu, 3 Jan 2019 00:25:29 +0100
Jonas Stein wrote:
> git log | grep "Author: "| sort | uniq | sed "s/Author: //g" | wc -c
That's a rather round about way of doing :
git shortlog -e -s | cut -f 2
git shortlog -e -s | cut -f 2 | wc -c
37471
git shortlog -e -s | wc -l
998
pgpFfkBYRuopC.
On Sat, 29 Jun 2019 13:23:10 +0200
Jonas Stein wrote:
> By the way, you can get a formatted string of now in UTC with:
> date -u +"%Y-%m-%d"
Or just:
date -uI
pgpiM0RFr3T2z.pgp
Description: OpenPGP digital signature
# Kent Fredric (2019-07-10)
# Dead upstream, no remaining revdeps.
# Masked for removal after 2019-08-09, bug #631300
dev-perl/File-Slurp-Unicode
pgpQ7M83y3pe1.pgp
Description: OpenPGP digital signature
# Kent Fredric (2019-07-14)
# Broken since 2007, Upstream not seen since 2004.
# Removal after 2019-08-13
# Bug #635792
dev-libs/libvorbis-perl
pgpITJNsE2V5F.pgp
Description: OpenPGP digital signature
On Mon, 15 Jul 2019 05:34:17 +1200
Kent Fredric wrote:
> # Kent Fredric (2019-07-14)
> # Broken since 2007, Upstream not seen since 2004.
> # Removal after 2019-08-13
> # Bug #635792
> dev-libs/libvorbis-perl
I cocked up the mask, this is now fixed.
# Kent Fredric (2019-0
On Wed, 17 Jul 2019 15:25:10 +0200
Michał Górny wrote:
> What are your comments?
I think there's a situation not covered by this prose which is in a bit
of a grey area as per the intentions behind it, (but I would argue is
otherwise fine).
Some systems ship multiple types of documentation, and
On Sat, 20 Jul 2019 22:22:39 +0200
Michał Górny wrote:
> Yes, I get it. User experience is not important if it would mean
> developers would actually do anything but the bare minimum to get
> from one paycheck to another. The usual Gentoo attitude.
You of course realise putting more demands on
On Mon, 22 Jul 2019 11:00:42 +0200
Jaco Kroon wrote:
> USE flag to enable/disable bundled packages. Any packages that gets
> committed with this USE flag goes off to a build server that builds the
> package and prepares an install (without bundled) and then the man pages
> can be scraped from
On Mon, 22 Jul 2019 09:18:38 -0400
Rich Freeman wrote:
> So,
> there is a relationship between packages that need to have manpages
> pregenerated and the package manager.
My objection re: pollution is more to the point that this propagation
of mechanisms that are inherently "package manager con
On Mon, 22 Jul 2019 21:04:07 -0400
Aaron Bauman wrote:
> I am going to divert topics here... "freedom"... like freedom to post on a
> mailing list without restriction (e.g. whitelisting) ?
Please don't, this ain't going anywhere.
pgpPhG_Z53cgV.pgp
Description: OpenPGP digital signature
On Mon, 22 Jul 2019 21:08:51 -0400
Aaron Bauman wrote:
> 1. I want some documentation
> 2. It doesn't ship from upstream (without crazy extra deps)
> 3. Gentoo guy hooked me up and packaged it pre-built with it
> 4. Thanks!
The proposal as-stated is:
1. Documentation requires even 1 additional
On Tue, 23 Jul 2019 13:38:28 +0200
Gerion Entrup wrote:
> What about a compromise?:
> Deliver a (prebuild) manpage as package maintainer by default, but keep
> a use flag "man-build" (or whatever) that builds the man page for everyone
> (also the maintainer herself) with use of the crazy extra d
On Tue, 23 Jul 2019 14:39:16 +0200
Michał Górny wrote:
> > Failure to do this will mean you're shipping out-dated documentation to
> > the user.
>
> I fail to see how this could happen, unless you'd be using terrible
> hacks.
What part in my series of steps did you not understand?
All that h
On Tue, 23 Jul 2019 23:56:52 -0400
desultory wrote:
> avoid optional documentation,
> while the proposal in question explicitly would
I assume you meant 'optional dependencies' here right? :)
pgp36j4n0ZoM_.pgp
Description: OpenPGP digital signature
On Thu, 25 Jul 2019 00:10:49 -0400
desultory wrote:
> The user-side effects pf the proposal in question, were it to become
> policy, would be that anyone seeking to not install what is presently
> optional documentation would either be:
> (1) wasting build time and space (and, depending on implem
On Thu, 25 Jul 2019 16:05:16 +0200
Michał Górny wrote:
> Thirdly, I've implemented filtering by maintainer.
>
> To get reports for developer foo, append ';maintainer=foo', e.g.:
Thanks very much :). This will come in *very* handy for me :)
pgp_LVJov6dDk.pgp
Description: OpenPGP digital signat
On Thu, 25 Jul 2019 23:56:33 -0400
desultory wrote:
> Since when is anyone proposing extirpating man pages on the whole? I am
> simply making the rather simple suggestion that pulling in more packages
> to support presently optional documentation as newly mandated
> documentation when such docume
On Sat, 3 Aug 2019 01:20:34 +0200
Jonas Stein wrote:
> I am no fan of the descriptions in the form "please CC: If the bug is
> about x but not y and the moon is in the third house of the lion"
You could stipulate that in order to be added as a "watcher" in
metadata.xml, you must agree to accept
On Sun, 04 Aug 2019 18:49:30 +0200
Ulrich Mueller wrote:
> Alternatively, how about calling that type "upstream" instead of
> "watcher"?
Mostly, because the term "upstream" doesn't communicate any useful
information about what it is expected to mean, and, it reduces the
usefulness of this field
On Sun, 04 Aug 2019 18:49:30 +0200
Ulrich Mueller wrote:
> > And yes, I'm talking about real life situation when the only
> > in the package left was this 'upstream watcher'.
> > I suppose an alternative solution there would be to return to explicit
> > logical marking as .
>
> Many metadata
On Sat, 3 Aug 2019 00:07:13 +0100
James Le Cuirot wrote:
> Any better?
I think I would be personally aided by a description of what sort of
environment is expecting the various values, eg:
I know if I build for a target that I'll eventually have to "chroot" to
get into, paths that get "made con
On Tue, 06 Aug 2019 09:45:18 +0200
Ulrich Mueller wrote:
> > All fit within
> > , but not all
> > fits within
>
> Can you give an example of a maintainer in the watcher \ upstream set?
>
> Ulrich
all maintainers who aren't upstream are just maintainers
all maintainers who are upstream ar
On Tue, 06 Aug 2019 18:53:33 +0200
Ulrich Mueller wrote:
> Yes, I know how elementary set theory works. :) I had asked for a
> concrete _example_ in the outer set but not in the inner.
Easy:
- You maintain a package that depends on this, and you want to be kept
"in the loop" on changes/bugs ju
On Wed, 7 Aug 2019 11:32:43 -0400
Brian Evans wrote:
> I object to this as I feel they can incorrect such as on prefix.
>
> Also, this goes against the established practice of committing directly
> to stable. These are exactly the same as virtuals as "they install
> nothing" and "just run a scr
On Wed, 07 Aug 2019 17:55:21 +0200
Ulrich Mueller wrote:
> Plus, the eclasses explicitly allow KEYWORDS to be overridden by the
> ebuild:
>
> : ${KEYWORDS:=alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 ~riscv
> s390 sh sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~x86-fbsd ~amd64-linux
>
On Sun, 11 Aug 2019 14:53:34 +0200
Michał Górny wrote:
> The use of term 'magic' for file type recognition by magic bytes is well
> established. Standing on your head and trying to invent an alternative
> is not going to help anyone, and only confuse people.
Fun fact: when I saw this Subject on
On Sun, 11 Aug 2019 17:53:44 -0500
William Hubbs wrote:
> , since he says we can add more fields in the future,
> you either have to escape whitespace in the notes field or quote the
> field.
This was originally what I was going to comment on when the proposal
first hit the list.
But then I rea
On Mon, 12 Aug 2019 09:52:40 -0700
Alec Warner wrote:
> CSV, JSON and YAML are both popular machine-and-people readable
> specifications with broad support.
No, not CSV. There isn't really "a spec" for that. Even though there is
a "proposed spec", "CSV editors" and things that emit CSV just make
On Mon, 12 Aug 2019 11:20:01 -0700
Alec Warner wrote:
> >
> > As for JSON/YAML, ... eh... that may be the case for like, 4 line files.
> >
> > But once you have hundreds of entries, that becomes less true.
> >
>
> What becomes less true?
In that it ceases to be a human-editable format.
Its e
On Mon, 12 Aug 2019 11:20:01 -0700
Alec Warner wrote:
> > And both of those can have "Fun" merge conflict issues due to the
> > requirements around record delimiters and syntax,
> >
>
> And this means what? That I might check something in that is broken?
> How is this not true for any syntax w
On Tue, 13 Aug 2019 20:39:01 +0100
James Le Cuirot wrote:
> Unfortunately there's currently no way to say that the versions of a
> package across BDEPEND, DEPEND, and RDEPEND must be (roughly?) equal so
> there's nothing to stop an ancient Perl in / building a module for a
> newer Perl in ROOT bu
On Wed, 14 Aug 2019 10:16:57 +0100
James Le Cuirot wrote:
> Yes, I thought that was probably the case. Python is more forgiving in
> this regard.
In perls case, some of that unforgivingness is upstream dev's stuffing
custom logic into Makefile.PL that calls "die", when EUMM will
automatically wa
On Sat, 17 Aug 2019 10:35:29 +0200
Ulrich Mueller wrote:
> For example, "nobody" lives in /var/empty but cannot write to it, and
> that dir is owned by root.
What ensures that the permissions on /var/empty are correct for this
scenario?
Possibly having acct-* create a /var/lib/nobody or a /var/
On Thu, 5 Sep 2019 09:04:23 -0500
Gordon Pettey wrote:
> You'll note the bit you quoted in defense of skipping review says
> "changes", and the bit about new eclasses says "do not skip this step".
Emphasis added:
-
BEFORE committing a NEW eclass to the tree, it SHOULD be emailed to the
gent
On Thu, 05 Sep 2019 21:47:11 +0200
Michał Górny wrote:
> So to summarize, instead of working together in order to follow a well-
> established policy,
You're reading it wrong. If its "established policy", dev manual must
reflect that.
If the dev-manual writes "should" in one place, and implies
On Fri, 6 Sep 2019 20:02:05 +0100
Michael Everitt wrote:
> so that the original source makes sense when reading it
> without external tools ? Thoughts?
The source still makes sense without external tools.
You just need to understand the syntax :p
- @FUNCTION @USAGE
And @FUNCTION is *right th
On Mon, 9 Sep 2019 12:34:18 -0500
William Hubbs wrote:
> There is another option I want to try which is adding "go mod vendor" to
> src_unpack for go packages.
Is it infeasible to write a tool that you execute as a maintainer, that
simulates
what "go mod vendor" would do, but instead emits a li
On Mon, 9 Sep 2019 16:46:16 -0500
William Hubbs wrote:
> will list the dependencies of a module, but that doesn't look like it
> can be translated into src_uri format.
If you use the mirror as mentioned in
https://blog.golang.org/module-mirror-launch
Then you should be able to do it in a strai
On Tue, 10 Sep 2019 13:31:01 -0500
William Hubbs wrote:
> It looks like we would also need a way to honor the GOPROXY environment
> variable as well.
Or ... mirror://goproxy/
pgpSON8XaRx39.pgp
Description: OpenPGP digital signature
On Wed, 11 Sep 2019 12:47:20 -0500
William Hubbs wrote:
> Sorry, That train already left the station with the golang-* eclasses
> and there is nothing we can do about it.
Saying "this creates a legal problem" followed by "eh, nothing we can
do about it, carry on" really doesn't work in reality,
Currently, to the best of my understanding, QA policies are spelt out
scattered amongst the devmanual.
This makes it very hard to:
- Know what policies are in place
- Know how to conform to each policy
- Cite a given policy
- Interpret a given policy unambiguously.
Most of the dev-manual is writ
On Thu, 12 Sep 2019 12:52:31 -0400
Michael Orlitzky wrote:
> Subslots do this already. Portage does this already. We have this "tool
> that people would want," but only if developers can be bothered to
> package things.
For some things (go, rust), using dynamic linking for all dependencies,
and
On Thu, 12 Sep 2019 19:03:02 +0200
Michał Górny wrote:
> ebuild spire-0.8.1.ebuild fetch
> tar -xf ${DISTDIR}/spire-0.8.1.tar.gz
> cd spire-0.8.1/
> go mod vendor
> cd ../
> tar -cf spire-0.8.1-vendor.tar spire-0.8.1/vendor
>
> Now you don't need special src_prepare() to unpack it.
Of course, t
On Wed, 11 Sep 2019 17:28:22 -0700
Alec Warner wrote:
> I don't care if you strip or not (I'm not even sure portage knows how to do
> it for go binaries) but I'm fairly sure the reason isn't because "upstream
> does not support stripping go binaries" because they clearly do...unless
> upstream is
On Thu, 12 Sep 2019 23:12:52 +0200
Michał Górny wrote:
> Since when it is a bug that when you strip debug info, you don't have
> debug info? I thought that's precisely what stripping debug info means
> but maybe in the special Go world it is different, and debug info is
> expected to remain afte
On Thu, 12 Sep 2019 17:58:08 -0400
Michael Orlitzky wrote:
> What kind of math would convince you that an idea with all "cons" and no
> "pros" is bad?
Is "upstream tooling doesn't work without static compilation" or
"built packages tend to need exact version matching at runtime to work"
( which
On Fri, 13 Sep 2019 19:44:55 -0400
Michael Orlitzky wrote:
> They silently get something less than
> they're expecting. We would be better off telling people to run "go
> whatever" themselves, or by putting this stuff in an overlay where
> expectations are clearly defined.
That suggestion actua
On Fri, 13 Sep 2019 12:50:48 -0400
Michael Orlitzky wrote:
> The rule "don't copy and paste code" applies to your
> linker just as much as it applies to the first program you wrote in
> CS101, and for the same reasons.
My experience has taught me to ignore the rule as written, and consider
it m
On Fri, 13 Sep 2019 17:37:54 +0200
Michał Górny wrote:
> Hi,
>
> The following packages are up for grabs due to prolonged inactivity
> of dracwyrm:
>
> app-misc/ddcutil
> media-libs/opencollada
> media-sound/tuxguitar
---
On Mon, 16 Sep 2019 00:05:02 +
"Robin H. Johnson" wrote:
> The at
On Sat, 21 Sep 2019 22:58:03 +0200
Ulrich Mueller wrote:
> If the goal of this exercise is to do an audit of ebuilds labelled as
> "GPL-2", then a less intrusive approach (which I had already suggested
> when this issue had last been discussed) would be to add a comment to
> the LICENSE line, eit
One of the recurring problems we face in #gentoo is end users coming
to us with confusing problems, and their problems are exacerbated
because their default workflow ended up with them unmasking some **
version of perl.
There is already a bug for this behaviour [1], and comments say that
portage d
On Wed, 9 Oct 2019 19:45:34 -0700
Zac Medico wrote:
> I'd prefer to disable --autounmask by default and include warnings about
> harmful behavior in the documentation.
I think autounmasks behaviour with regards to USE flags is useful,
(heh), its just everything else it does tends to violate stab
On Thu, 10 Oct 2019 04:35:22 +0100
Michael Everitt wrote:
> Is there any mileage in something as ridiculous as AUTOUNMASK_EXCLUDES ?
Would depend on what that means, where that variable was used, and what
it contains
But the sort of breakage type it can trigger is not limited to any
specifi
On Sun, 20 Oct 2019 16:57:54 -0400
Joshua Kinard wrote:
> I know we've got a ton of Perl packages for the core set of Perl modules,
> but doesn't the CPAN eclass also have the capability to auto-generate an
> ebuild package for virtually any Perl package distributed via CPAN? Can
> that logic be
On Sun, 20 Oct 2019 20:05:40 -0400
Joshua Kinard wrote:
> Longer-term, I think this entire approach should be revisited by the TeX
> team to make it behave more like Perl or Python packages by having discrete
> ebuilds for these modules. That's not exactly a small undertaking, but
> this current
On Mon, 21 Oct 2019 19:37:28 +0200
Piotr Karbowski wrote:
> This is a bit unhealthy, especially when some developers that maintain
> packages are out of reach, or the patches to update ebuild just rot on
> the bugzilla and are not taken in by maintainers.
IME this is far from the norm and should
On Mon, 21 Oct 2019 17:58:51 -0700
Matt Turner wrote:
> I'm not sure what this is in reference to so it seems to be a
> non-sequitur, but I like the policy of at least waiting a day for
> review of non-critical fixes. Phrased another way, let people in every
> timezone have a chance.
Its not aim
On Fri, 25 Oct 2019 03:03:26 +0100
Michael Everitt wrote:
> Forgive my lack of git-fu, but which commit did this? Can we name & shame
> the author and committer publicly, and in front of QA, so that this kind of
> violation is highlighted to all, and noted for future reference?
I think you can b
On Fri, 25 Oct 2019 18:16:30 +0200
Ralph Seichter wrote:
> Personally, I interpret a bug status of IN_PROGRESS as "somebody is
> working this bug", not "the assignee is working this bug". The latter
> is not as important to the bug state anyway, don't you think?
If you want the "somebody is work
On Fri, 25 Oct 2019 15:03:39 -0700
Georgy Yakovlev wrote:
> not used anymore
>
> Closes: https://bugs.gentoo.org/695698
> Signed-off-by: Georgy Yakovlev
Its likely this removal will cause the same kinds of problems faced by
the recent virtual/pam removal, just its more insidious, as the
depen
On Sat, 26 Oct 2019 08:34:50 +0200
Francesco Riosa wrote:
> So basically the eclass should be bumped, with the old one deprecated?
I don't think rev-bumping the eclass is a useful way to fix this either.
It could work, but I suspect it just expands the problem slightly.
pgp4WzprN2xLh.pgp
De
On Sat, 26 Oct 2019 14:24:22 +0200
Jonas Stein wrote:
> Here is an example:
> https://bugs.gentoo.org/683184
> In this case it is still quite tidy, but other TRACKERS will become
> unreadable by that.
I think in that case the PR bot should tell people:
- Find / Open the relevant bug
- Link to t
On Sat, 26 Oct 2019 18:55:11 -0500
William Hubbs wrote:
> Sure, but rebuild changes are exactly what you would want. that's how
> software written in go gets rebuilt for example, which is exactly what
> you want when go is upgraded.
>
> I agree that some rebuilds might be unnecessary, but if yo
On Sun, 27 Oct 2019 12:05:02 -0500
William Hubbs wrote:
> If a build dep of something changes, the correct response with
> --with-bdeps=y is to rebuild everything that depends on the changed dep.
Unfortunately, my learned experience of portage is the "correct
response" is not something portage w
On Wed, 23 Oct 2019 01:16:51 -0400
Joshua Kinard wrote:
> And for Perl or Python, I think we should be making an effort to leverage
> their respective mirroring systems first before putting their distfiles onto
> our mirrors. Perl's got CPAN, and Python has pypi. For things that don't
> exist o
On Mon, 28 Oct 2019 10:34:40 -0500
William Hubbs wrote:
> Let's go ahead and do the change and file bugs against portage if there
> are issues.
Any time I find something that I'd imagine portage could fix, I file a bug.
But I already have so many open bugs for things portage does wrong that
hav
On Mon, 28 Oct 2019 18:46:15 +0100
"Haelwenn (lanodan) Monnier" wrote:
> Wouldn't a Erlang project be better, specially as there is the Perl and
> Python projects which are there for probably the same reasons?
I think a "jabber" project would be a more suitable fit for this than
"erlang".
Then
On Tue, 29 Oct 2019 12:27:49 -0500
William Hubbs wrote:
> No, I'm just saying this:
>
> We don't know that there is a portage bug from what I'm reading in this
> thread. We are talking about possible bugs, but a possible bug isn't a bug.
> If there is an issue cite it otherwise move on.
>
> -
On Wed, 30 Oct 2019 09:26:09 -0500
William Hubbs wrote:
> I don't know portage internals, so I have no idea what the deal with
> this is or how to fix it.
>
> Did you report it to the portage team?
Report what?
1. Didn't have access to the box
2. No way to even conceive of producing enough inf
601 - 700 of 875 matches
Mail list logo
