On 7 August 2012 19:52, Michał Górny wrote:
> Hello,
>
> Right now, every time a bigger bunch of stuff (installed by various
> packages) needs to be moved around the filesystem, we have a lot of
> work to handle it somehow. And finally, users end up having to either
> rebuild a lot of packages to
On 8 August 2012 01:58, Michał Górny wrote:
> I don't think that's possible. Much like with other kinds of updates,
> the packages in the tree would be updated to install in the new
> location anyway.
Sure, but the question is "when does this happen". Users are expecting
such changes when they em
On 8 August 2012 22:55, Duncan <1i5t5.dun...@cox.net> wrote:
> LOL! THAT's what it was! Along the same lines...
>
> ...senil emas eht gnolA !saw ti tahw s'TAHT !LOL
>
> http://www.textreverse.com/
>
> (While the link I had saved was stale it did mean I still remembered
> enough about it to plug
On 9 September 2012 15:53, Matthias Bethke wrote:
> I think Gentoo of all distributions should aim to provide software as
> "original" as possible. If there are any reasons that I have ignored so
> far why people would want the current behavior, how about I make this
> patch conditional on a new
On 11 September 2012 14:16, Brian Harring wrote:
> On Fri, Sep 07, 2012 at 04:14:17PM -0400, Ian Stakenvicius wrote:
>> Is there anything in particular in the spec/proposal for DEPENDENCIES
>> that would exclude the addition of individual "build: app-cat/myatom"
>> "run: app-cat/myatom" deps by an
On 14 September 2012 10:17, Brian Harring wrote:
>> All you need is something in bash that can parse DEPENDENCIES and
>> populate *DEPEND , and the underlying guts could be done in
>> practically any language without requiring PM specific
>> implementations.
>
> You've got it inverted; if any auto
On 15 September 2012 08:51, Rick "Zero_Chaos" Farina
wrote:
> ozzie eclass # grep 'DESCRIPTION="Based on the ' *.eclass
> cannadic.eclass:DESCRIPTION="Based on the $ECLASS eclass"
> confutils.eclass:DESCRIPTION="Based on the ${ECLASS} eclass"
> embassy.eclass:DESCRIPTION="Based on the $ECLASS ecla
On 11 November 2012 00:27, aranea wrote:
>>
>
> It's been 3 months since I filed this bug, and one month ago I sent a
> reminder to the gentoo-perl ML. There haven't been any reactions. I
> also couldn't reach anyone on IRC. Is this herd dead or what?
https://en.wikipedia.org/wiki/Warnock%27s_Dil
The issue is basically, as you'll see in my comments on the updated
bug, Perl virtuals are not very trivial, and every perl release
results in a nightmare of fixes we have to apply to every Perl virtual
in tree, so we don't , at present, want more virtuals than necessary.
I'd personally love to ha
On Thu, 2 Feb 2017 18:01:54 -0600
Gordon Pettey wrote:
> If you want to keep this kind of thing in the ebuilds, IUSE="+blah" doesn't
> allow any granularity. Another variable USE_PROFILE should be added
> analogue to DEPENDS:
> IUSE="gnome-keyring gtk-theme kwallet pulseuadio qt-theme
> annoyingU
Does anyone have existing collections of git hooks they use locally on portage
to prevent themselves making dumb mistakes?
For example, one I just discovered I made back in December was I accidentally
keyworded a package for arches I don't have while doing an edit, and I'd imagine
the cause was bl
On Sat, 04 Feb 2017 12:44:38 -0500
"William L. Thomson Jr." wrote:
> The question to ask is who do you want to create more work for?
> People maintaining packages, or people maintaining profiles.
I would probably say "yes" to both of those, because the main objective here
is to create less work
On Sat, 04 Feb 2017 16:05:50 -0500
"William L. Thomson Jr." wrote:
> Putting increased requirements on the maintainers may be demotivating, and
> create other problems. New profile added they are not aware of. Now they have
> to go add IUSE defaults etc. There are a fair amount of profiles.
>
On Sat, 4 Feb 2017 14:00:04 -0800 (PST)
Alex Alexander wrote:
> To view the bug queue, click here: http://bit.ly/m8PQS5
>
> Thanks!
Errant thought: It may be useful for the tool that you use to generate this
mail to
embed a list of bug summaries, in the hope it will generate more interest and
On Tue, 7 Feb 2017 08:52:06 +0100
Ulrich Mueller wrote:
> I see no point in discouraging IUSE defaults, given that they are
> purely advisory for the package manager:
>
> "[...] any use flag name in IUSE may be prefixed by at most one of a
> plus or a minus sign. If such a prefix is present, the
On Tue, 14 Feb 2017 20:19:54 +0900
Jaewon Choi <1500...@dwight.or.kr> wrote:
> 8) Is there anything else you would like to tell me about systemd?
Side note, as its not clear from the nature of the question if this factor is
known:
Gentoo is one of the few distributions that supports *not* using
# Kent Fredric (18 Feb 2017)
# Renamed upstream to Monitoring::Plugin due to Trademark dispute.
# Please use dev-perl/Monitoring-Plugin instead. Bug #575986.
# Masked for removal in 30 days.
dev-perl/Nagios-Plugin
pgpOJzt3gGudu.pgp
Description: OpenPGP digital signature
On Mon, 20 Feb 2017 18:27:22 +
"M. J. Everitt" wrote:
> Nice .. esp. coming from a QA dev ...
It makes sense though how it could happen, given:
- Its a - package
- packages are typically keyworded as ""
- repoman pretty much ignores they're even there
Also, given its a - packa
On Wed, 22 Feb 2017 03:08:38 +
"M. J. Everitt" wrote:
> find me another category without X-Y pattern?
cat /usr/portage/profiles/categories | grep -v '[-]'
virtual
pgpyWRFPdbHbr.pgp
Description: OpenPGP digital signature
On Thu, 23 Feb 2017 18:02:10 +0100
Michał Górny wrote:
> ---
> eclass/perl-functions.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/perl-functions.eclass b/eclass/perl-functions.eclass
> index 1542b98cd45f..85907354a309 100644
> --- a/eclass/perl-function
On Fri, 24 Feb 2017 05:36:51 +0300
Andrey Ponomarenko wrote:
> I'd like to present a new project called "ABI Navigator" for searching binary
> symbols (functions, methods, global data, etc.) in open-source libraries:
> https://abi-laboratory.pro/index.php?view=navigator
>
> The project allows
On Fri, 24 Feb 2017 14:11:57 +0100
Michał Górny wrote:
> If there is no hurry to the other changes, maybe either of us could
> commit them all at once along with all those eval patches (say, in 6
> days)? The eutils change is going to cause almost everything to be
> regenerated anyway ;-).
If it
On Mon, 27 Feb 2017 23:44:26 +0300
Andrew Savchenko wrote:
> Maybe. But splitting documentation of one issue into several
> documents may confuse readers. We already have "hyphen" in a
> category name being mentioned in the PMS, so this should be either
> clarified in the PMS or moved completely
On Tue, 7 Mar 2017 16:40:06 -0600
William Hubbs wrote:
> What I need is a way to force all go programs on your system to rebuild
> when the version of dev-lang/go on your system changes, and this method
> with virtuals is the only way I can think of to make that happen and
> allow you to remove d
On Thu, 09 Mar 2017 16:34:20 +0100
Michał Górny wrote:
> 1. classic forks -- package B is forked out of A, and the development of
> both continue independently (eudev/systemd, ffmpeg/libav);
>
> 2. large patch sets / continuously rebased forks -- where the particular
> set of changes is usually
On Thu, 09 Mar 2017 18:16:51 -0500
"William L. Thomson Jr." wrote:
> That would likely be an incorrect ebuild and should not have been committed
> to
> tree.
If people didn't accidentally overlook problems where variables contained the
wrong
contents and tried to access files they shouldn't,
On Thu, 16 Mar 2017 23:42:43 +0100
"Andreas K. Huettel" wrote:
> # Andreas K. Hüttel (16 Mar 2017)
> # Replaced by dev-perl/Monitoring-Plugin, bug 575986
> # Removal in 30 days
> dev-perl/Nagios-Plugin
...
# Kent Fredric (18 Feb 2017)
# Renamed upstream to Monitoring::P
On Sun, 26 Mar 2017 13:04:18 -0700
Brian Dolbec wrote:
> While this can be read and split easily in python code. It
> is not future proof for additional data being added and/or removed.
This is why in my earlier comments to this proposal, I asked for
a: more descriptive terms than 'stable',
On Sun, 26 Mar 2017 22:10:23 -0400
"Walter Dnes" wrote:
> Hopefully, there's no need to go JSON format (bleagh). To simplify
> parsing, fields for one arch should be clustered together.
"should be committed only after running it through sort with LC_ALL=C"
pgpH0WtqWRRt_.pgp
Description: Open
On Tue, 28 Mar 2017 00:00:30 +0100
"M. J. Everitt" wrote:
> 'unstable' should surely be applied to masked packages, no? Everything
> not-stable and not-unstable becomes therefore 'testing' ...
Nah, he's trying to make the phrase "stable arch" mean something
in a way tools can understand.
Becaus
On Sun, 9 Apr 2017 12:15:56 -0400
"William L. Thomson Jr." wrote:
>
> The approach mentioned above, if the packages do not have issue. I
> could go ahead and switch to ruby24 and pyton 3.6 across the board.
> Which I cannot do now till a bunch of ebulids have their targets
> increased.
>
This
On Sun, 9 Apr 2017 22:04:13 -0400
"William L. Thomson Jr." wrote:
> This has never been the case with Java.
Its not a problem with C binaries either, because you have a discrete
compile time, and language level interop between compiled binary forms.
Meanwhile, you cannot build two parts of a gi
On Mon, 10 Apr 2017 11:52:02 -0400
"William L. Thomson Jr." wrote:
> >
> > Meanwhile, you cannot build two parts of a given python dependency
> > chain with different pythons, nor different perls.
>
> True but this is not changing how things work, just reversing.
You mean going back to the ol
On Mon, 10 Apr 2017 12:03:51 -0400
"William L. Thomson Jr." wrote:
> That is ALLOT of work to fiddle
Unrelated to thread and is not intended as a "I'm better because I grammar
well" thing,
but this drives me nuts and I've bitten my tongue on it for months.
But you use that word that isn't a w
On Mon, 10 Apr 2017 16:01:55 -0400
"William L. Thomson Jr." wrote:
> You still have
> adding new, and the end user experience.
You're running ~arch, I recall.
This means adding new is slow for arch users.
But it also means there's a clear line in the sand when something can be
stabilized.
~a
On Tue, 11 Apr 2017 03:29:25 +0700
"Vadim A. Misbakh-Soloviov" wrote:
> The purpose of TARGETS is that package holds only that TARGETs that it was
> tested to work against
Targets are more than that.
Targets also regulate compilation stage for concurrency.
For instance:
If you have 2 pythons
On Mon, 10 Apr 2017 18:35:13 -0400
"William L. Thomson Jr." wrote:
> Have you worked with paludis? If you can get that setup it should give
> you more useful output in less time. Ciaran would know there, and maybe
> some others.
>
> > Hence, that's the sort of problem I'm more inclined to throw
On Thu, 20 Apr 2017 10:49:04 -0700
Christopher Head wrote:
> >Usually when writing new code, you use the latest version of stuff. Not
> >always but usually best. If anything make code support older while
> >targeting newer.
>
> No, not how I develop. I always start by determining my target aud
On Thu, 27 Apr 2017 16:14:13 +0200
Michał Górny wrote:
> What do you think? Any other ideas?
I personally think that "test" being exposed as a useflag is a hack that
shouldn't be perpetuated further.
I'd rather have the ability to check for the flag the same way as we check for
arch, but with
On Fri, 28 Apr 2017 15:37:15 +0200
Michał Górny wrote:
> Congratulations, you've just completely discouraged me from pursuing
> this any further. I don't have the time or the resources to solve all
> the problems in the world, especially if I don't give a damn about
> them.
Its not that I don't
On Fri, 28 Apr 2017 16:39:45 +0200
Michał Górny wrote:
> Change the unset value tag to '@DEFAULT-UNSET' to ensure consistent
> use of hyphen/underscore throughout eclassdoc. Before, one tag
> (@ECLASS-VARIABLE) has used hyphen while also one (@DEFAULT_UNSET)
> used underscore. Unify them to use t
On Sun, 30 Apr 2017 09:48:58 -0400
Brian Evans wrote:
> If they want to enable a flag to apply system-wide, then it does not
> matter where the description is. To users, a USE flag is a USE flag.
Terminology wise, this is more a side effect that users are exposed to
global methods of setting use
On Mon, 01 May 2017 12:05:06 +0200
Ulrich Mueller wrote:
> Please make this DEFAULT_VALUE, in oder to be consistent with the
> existing DEFAULT_UNSET. Otherwise, nobody will be able to remember
> when to use a hyphen and when an underscore.
Initial version did use _, but mgorny seems to be push
On Mon, 01 May 2017 12:14:01 +0200
Michał Górny wrote:
> Any reason you can't just eat_line?
Would require me to reflow the entire function, eat_line calls getline for you.
Here, that would mean it would call "getline", and then the loop would continue,
and then it would call getline a second t
On Mon, 01 May 2017 18:02:56 +0200
Michał Górny wrote:
> In other words, I don't think that:
>
> DIST_TEST (UNSET -> "do parallel")
>
> is more readable than:
>
> DIST_TEST (UNSET)
> ...
> If unset, "do parallel" is assumed.
>
> --
(This time on list)
If I were to take a
On Tue, 2 May 2017 09:25:52 +1200
Kent Fredric wrote:
> You may note the value map for DIST_TEST as stated is more-or-less
> already in place for perl-module.eclass, albeit its just a hand
> formatted table.
oh ... and this strategy kinda fails if you render the manpage to PDF.
Becaus
On Sun, 07 May 2017 22:53:52 +0200
David Seifert wrote:
> This is probably the smaller problem. The link shows a bug where none
> of the aforementioned arch teams have keyworded the requested packages
> in 4 months. How would the arches.desc proposal fix "dead arch teams"?
> Sure, it will make ma
On Wed, 10 May 2017 09:23:04 +0200
Alexis Ballier wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1238804 (building perl with
> pie seems to make some perl packages fail at runtime)
If that's really the case, can we *not* do this right now?
There's one thing Perl team don't need right now
On Fri, 19 May 2017 19:27:15 +0200
Kristian Fiskerstrand wrote:
> As far as I can see you were never the maintainer of at least
> app-misc/elasticsearch (I didn't check other possibly related
> packages), it was first proxied maintained through chainsaw, then
> later through proxy-maintainers her
On Tue, 16 May 2017 21:36:15 +0200
Fabian Groffen wrote:
> Hardware or more deltas to
> download by users? Just wondering.
Both.
- End users using git end up having to do massive metadata-updates.
- Infra needs to have massive hits to metadata regeneration
- End users using rsync have to fetc
On Sun, 21 May 2017 19:34:26 +0200
Michał Górny wrote:
> Like, by not using eclasses and instead inlining all the stuff?
I'd personally suggest we endeavour towards making systems in place so
that the performance overheads of metadata generation is much lower, to
the point it can be done efficie
On Mon, 22 May 2017 06:10:11 +0200
Patrick Lauer wrote:
> ... Now that we know how it goes we can skip the rest and just glare
> at Michal for not being a reasonable person once more, and just
> continue doing useful stuff.
Were this an actual office, this would be better solved with a "ok,
we'v
On Mon, 22 May 2017 14:24:24 +1000
Sam Jorna wrote:
> I suspect it's likely a misunderstanding - without notification, all
> anyone from Proxy Maint sees is proxy-maint being removed. An E-Mail
> to proxy-maint@g.o explaining that you've spoken to and are taking
> over proxying of the package wo
On Tue, 23 May 2017 21:31:18 +0200
Michał Górny wrote:
> - public (open subscription), initially we may optionally copy all
> subscribers from gentoo-dev so that they do not miss discussion,
What would be the result if somebody replied to a g-dev-internal ML
without permission?
I think there sh
On Tue, 23 May 2017 15:52:52 -0400
Philip Webb wrote:
> Is this proposal itself not just a waste of valuable developer time
> in moderating, censoring & deciding who is a sheep & who is a goat ?
Its not censorship, because censorship is the practice of preventing
something from being said in ent
On Tue, 23 May 2017 20:32:03 +
Erik Närström wrote:
> I'snt the idea of creating a new mailing list to let gentoo-dev be
> mesy?, in that case we could simply redirect all non-aproved posts
> from gen-int to gen-dev.
I mean, messy in the sense you'd have replies, but no obvious parent
for th
On Wed, 24 May 2017 14:21:13 +0900
Benda Xu wrote:
> 2. Useful discussion are diluted from 1 list into 2 lists.
I think dilution is the point, but the problem is not useful
discussions.
Its the useless ones that are targeted for dilution, so that the useful
ones can stop drowning in them.
pgp
On Mon, 29 May 2017 17:33:13 +0200
Michał Górny wrote:
> Automatically solving USE constraints solve all three fore-mentioned
> issues with REQUIRED_USE. By default, no user intervention is required
> to solve USE constraints and package.use needs to be modified only to
> enforce a non-standard s
On Tue, 30 May 2017 09:56:07 +0100
Ciaran McCreesh wrote:
> 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.
I get the impression that this is harder to solve in Gentoo than it has
to be, because my impression of po
On Wed, 31 May 2017 23:54:59 +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.
+1
pgpmXJgzQwGtk.pgp
Description: OpenPGP digital signa
On Thu, 1 Jun 2017 23:18:22 +0200
Jonas Stein wrote:
> A space separated list of the corresponding debian packages should be
> written in the field
>
Why space separated?
Its already legal to specify the field multiple times, and it should
work better that way for consistency with things that
On Thu, 1 Jun 2017 09:38:01 -0400
"Walter Dnes" 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 b
On Thu, 1 Jun 2017 18:36:24 -0700
Daniel Campbell wrote:
> +1. Otherwise sounds good. But if we do this for Debian, will there be
> movement to add in package names for rpm-based distros? Arch? BSD?
> Slackware? Where do we draw the line?
I'd say "as need be". Here we have a few extra benefits f
On Fri, 02 Jun 2017 14:07:44 +0700
"Vadim A. Misbakh-Soloviov" wrote:
> Shouldn't we mention "debug" USE-flag in this context somehow?
Not sure it should. Even though one package may be the logical equivalent
of a handful of debian packages, doesn't mean there's going to be a useful
USE <-> pack
On Fri, 02 Jun 2017 16:51:25 +0200
Michał Górny wrote:
> ...so if a Gentoo package is split into 40 packages in Debian, are you
> going to list all of them?
If it would be useful to do so, maybe.
But its a text file, people are capable of making judgements about
adding 3.2k of text, I hope. ( w
On Sat, 03 Jun 2017 09:58:28 +0200
Michał Górny wrote:
> and that's a small one. I guess we could avoid this if you restricted
> those remotes to the source package used to build them all.
I think in the event they're a form of conventional
foo
foo-dev
foo-dbg
etc, under the knowledge t
On Sun, 4 Jun 2017 13:56:52 +0100
Andrey Utkin wrote:
> You have searched for packages that names contain libavcodec in
> suite(s) stable, all sections, and all architectures. Found 4
> matching packages. Package libavcodec-dev
> Package libavcodec-extra
> Package libavcodec-extra-56
> Package li
On Mon, 05 Jun 2017 09:11:27 +0200
Hans de Graaff wrote:
> # Hans de Graaff (05 Jun 2017)
> # Bundles obsolete and vulnerable webkit version.
> # Upstream has stopped development and recommends using
> # headless mode in >=www-client/chromium-59.
> # Masked for removal in 30 days. Bug #589994.
>
On Mon, 5 Jun 2017 11:40:15 -0400
Alec Warner wrote:
> Do we really need to store and distribute this data though?
Aggregating this kind of data by cross-referencing multiple providers
and then trying discovery against debians equivalents of that, while
workable, would be likely fragile and unpr
On Mon, 5 Jun 2017 13:42:50 -0400
Michael Orlitzky wrote:
> Hans was
> attempting to fix it, but now that upstream is dead, it will remain
> insecure forever.
IME, as long as that's clear from the pmask, and its clear what those
security vectors are, as long as an end user makes sure those vecto
On Tue, 06 Jun 2017 07:28:00 +0200
Hans de Graaff wrote:
> What kind of timeframe do you propose?
>
> > 1.5 Months from "We're not working on this" to "its dead jim, kill
> > it from orbit"
> > is a bit fast for anything entrenched.
>
> The problems were there a lot longer so for me at least
On Sun, 11 Jun 2017 08:38:26 +0200
Hans de Graaff wrote:
> I've updated the proposed timeframe in the mask to 90 days.
That's reasonable.
Thanks :)
pgpFU7aP7HlSq.pgp
Description: OpenPGP digital signature
On Mon, 10 Jul 2017 10:41:11 +0200
"Paweł Hajdan, Jr." wrote:
> Feedback about next steps would be welcome.
>
> Paweł
I'd say hold of on anything Perlish unless strictly necessary. Trying
to keep the stable requests down to only what is *needed* for now
prioritizing for a future where Perl 5.26
On Mon, 10 Jul 2017 13:43:43 +0200
Pacho Ramos wrote:
> Yes, but it's similar as the cases when we need to fix our packages
> to work with a newer library they depend on. In this case it would be
> even easier as we can have multiple python versions and switch to the
> newer one for testing while
On 11 Jul 2017 01:41, Kristian Fiskerstrand wrote:
>
> On 07/10/2017 03:35 PM, Kent Fredric wrote:
> > On Mon, 10 Jul 2017 13:43:43 +0200
> > Pacho Ramos wrote:
> >
> >> Yes, but it's similar as the cases when we need to fix our packages
> >>
On Thu, 3 Aug 2017 19:21:12 +0200
Jonas Stein wrote:
> We have already some HOMEPAGES which are constructed by eclass magic
> [2]. These do not link to a useful website usually.
Statistically, that 99% of perl-module.eclass consumers do just this in
a useful way with factoring in ${PN} automatic
We're finally at a point where we're nearing the unmasking[1] of Perl
5.26 and making it visible to ~arch users, and a "news item" on this
matter will appear shortly.
Due to a collection of various problems faced in this version,
extensive amounts of work has been needed to simply deliver an ~arch
On Thu, 24 Aug 2017 03:06:13 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> nrpe-command-args-SECURITY-HOLE
> or just
> nrpe-GAPING-SECURITY-HOLE
That's probably excessive, if you set that USE flag globally, you
deserve what you get.
And if you are responsible and you know what you're gettin
On Wed, 30 Aug 2017 14:01:08 -0400
"William L. Thomson Jr." wrote:
> Examples
> x11-libs/gtk+
> x11-terms/terminology
"desktop" came to mind for me for some reason.
"desktop-apps/"
"desktop-libs/"
"desktop-terms/"
"desktop-themes/"
All appeal more to me than
"gui-apps/"
"gui-libs/"
"gui-terms
On Sun, 3 Sep 2017 23:37:34 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Vague/generic agreed in general. I'm not sure enough what you meant
> by double-dipping (tho I have a couple ideas) to say I agree there.
Yeah. To an extent these days its just "app" practically *implies* a
GUI.
It
On Mon, 4 Sep 2017 12:27:35 -0500
R0b0t1 wrote:
> Up until now I had not been sure my messages were readable.
Take it as a compliment, at least 1 of the possible warnock[1] reasons
are favourable :)
> us·er ex·pe·ri·ence
> noun: user experience; plural noun: user experiences
> the overall e
On Mon, 4 Sep 2017 15:16:46 -0400
"William L. Thomson Jr." wrote:
> Maybe just UI but that maybe to generic.
> https://en.wikipedia.org/wiki/User_interface
As a side question, what does "xui" mean in this world?
I went googling and all I could find was "X User Interface"
And all I could find t
On Tue, 5 Sep 2017 16:59:39 +0200
Alan McKinnon wrote:
> "xui" is a nice descriptive name and gets the point across in a
> reasonably unambiguous way. wayland is not X11, but it comes from a
> desire to do what X11 does without X11's problems.
And I have a few other perks of xui too.
we could i
# Kent Fredric (05 Sep 2017)
# Broken since Perl 5.16 circa 2012, no longer maintained upstream
# Bug: https://bugs.gentoo.org/623900
# Bug: https://rt.cpan.org/Public/Bug/Display.html?id=85991
# Removal in 30 days
dev-perl/XML-AutoWriter
pgpyRkSHi3ju8.pgp
Description: OpenPGP digital signature
On Thu, 7 Sep 2017 17:56:32 -0400
Rich Freeman wrote:
> And how would I figure it out, considering that simply asking on the
> list doesn't seem to yield a straight answer? Do you really need me
> to put it on the Council agenda? Or do we unmask it, let QA mask it
> 10 minutes later, then go ba
On Fri, 8 Sep 2017 10:11:51 -0500
R0b0t1 wrote:
> Then I'm quite confused as to why people seem to be extremely attentive to
> copyright infringement (besides an immediate payout). In the US they cite
> the reasoning I gave, from memory.
>
> Maybe that was for trademarks?
This is one of those p
On Fri, 8 Sep 2017 11:10:54 -0500
Gordon Pettey wrote:
> 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?
I've seen terms that state people aren't allowed to re
On Fri, 8 Sep 2017 20:33:49 -0500
R0b0t1 wrote:
> In any case it is my understanding that the issue is that simple. It's
> the reason torrents and magnet links exist, and why there are no legal
> claims possible against websites which host magnet links.
The entire court case against PirateBay wa
On Fri, 8 Sep 2017 13:19:23 +0200
Michał Górny wrote:
> a. getting wider review and some real-life testing before
> the specification is set in stone, and
Any thoughts on a function that would represent a dotted-decimal style version
as a floating point string?
eg:
ver_float 0.1.0-> 0.
On Sat, 09 Sep 2017 17:54:52 +0200
Michał Górny wrote:
> I'm not sure if there's a serious proposal behind all this but I suppose
> it's all just perl-specific insanity that is of no value to everyone
> else.
Yeah, some of the stuff I suggested there are generalisations, because
it doesn't make
# Kent Fredric (18 Sep 2017)
# Dead upstream, requires Module::Install. May be kept
# if somebody can make an argument for it. Bug #631334
# Masked for removal in 30 days.
dev-perl/PerlIO-via-symlink
pgpPGyHsnkTUN.pgp
Description: OpenPGP digital signature
# Kent Fredric (19 Sep 2017)
# Dead upstream, broken on Perl 5.26. Bugs #631302, #623116
# Masked for removal in 30 days.
dev-perl/Syntax-Highlight-Engine-Simple-Perl
pgppKLltnJg_z.pgp
Description: OpenPGP digital signature
On Tue, 19 Sep 2017 14:44:44 +0100
Tony Vroon wrote:
> We have similar workflow issues with this, and as a consequence our
> software team has asked me to step up. I can present an at least vaguely
> maintainable ebuild on:
> https://bugs.gentoo.org/572824
>
> I am aware that some of the patches
# Andreas K. Huettel (23 Sep 2017)
# Broken on Perl 5.26 (bug 623096), no fix in sight. No consumers.
# Removal in 30 days.
dev-perl/rpm-build-perl
pgpb_78D4NCaV.pgp
Description: OpenPGP digital signature
On Tue, 19 Sep 2017 17:23:50 +1200
Kent Fredric wrote:
> # Kent Fredric (19 Sep 2017)
> # Dead upstream, broken on Perl 5.26. Bugs #631302, #623116
> # Masked for removal in 30 days.
> dev-perl/Syntax-Highlight-Engine-Simple-Perl
Just as a follow up, this one got reneged on as some
As advised in the previous email[1], Perl 5.26.1 is scheduled to be
unmasked and available to ~arch come October 7th.
All the major blockers of known serious defects are fixed[2], but
there's still quite a number of lower-severity issues that are still
yet to be addressed[3]
Stabilization of Perl
On Sat, 07 Oct 2017 17:03:44 +0200
"Andreas K. Huettel" wrote:
> See plaintext below and identical attached file.
>
>
> ===
> Title: Perl 5.26 update: possible breakage
> Author: Andreas K. Hüttel
> Posted: xxx
> Revision: 1
> News-Item-Format: 2.0
> Dis
On Sat, 7 Oct 2017 12:15:14 -0400
"Aaron W. Swenson" wrote:
> This reads kind of awkwardly. Maybe something along this lines of:
>
> This release brings several incompatible changes as a result of
> deprecations coming to term [#] and mitigating a potential security
> issue [#].
>
>
On Mon, 09 Oct 2017 22:58:22 +0200
"Andreas K. Huettel" wrote:
> Please consider switching from your current 13.0 profile to the
> corresponding 17.0 profile soon after GCC-6.4.0 has been
> stabilized on your architecture. The 13.0 profiles will be deprecated
> and removed in the near future.
TL;DR: It would be very nice if when I did:
emerge --depclean -va
That important packages like say, Postgres could go "hey, that's ...
probably gonna break things, you haven't migrated, are you sure?"
Seeing notices *after* removing postgres that my system is now broken is not
too inspiring.
101 - 200 of 875 matches
Mail list logo
