[gentoo-dev] Last rites: dev-perl/Apache-SessionX

# Kent Fredric (14 Oct 2017) # 12 years without upstream responding to bugs, code almost # irredeemably unmaintainable and with no way to demonstrate it # actually works. Bug #634244 # Masked for removal in 30 days. dev-perl/Apache-SessionX pgphHSq8ody1m.pgp Description: OpenPGP digital

Re: [gentoo-dev] Re: pkg_rm_pretend?

On Thu, 12 Oct 2017 07:50:38 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Wow. How'd you ever get a backlog of 400 packages in your depclean list, > including critical ones you know you want to keep? These days portage > even strongly suggests running depclean after an --update @world,

Re: [gentoo-dev] Re: pkg_rm_pretend?

On Sun, 15 Oct 2017 04:17:49 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > I can also imagine doing something drastic like hourly depcleans, if > that's what it too, too, after dealing with a 1900-pkg-depclean! Yikes! It does sound like a lot, but when you have minimal chroots with only 9

Re: [gentoo-dev] git checkout in ebuild?

On Mon, 16 Oct 2017 13:31:53 +1000 Damo Brisbane wrote: > Hello, > > I am wanting to make an ebuild for Intel's (Apache 2 licensed) snap > monitoring framework (https://github.com/intelsdi-x/snap). It seems the > current version (2.0.0) does not compile the golang binaries with some type > of re

[gentoo-dev] Last rites: dev-perl/File-Stat-Moose

# Kent Fredric (21 Oct 2017) # Has not been usable since we cleaned the last Moose it worked on back # in 2012. Removal in 30 days. Bug #634938 dev-perl/File-Stat-Moose pgpLCMq5sFeDL.pgp Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-perl/Mail-SPF-Query

# Kent Fredric (22 Nov 2017) # Long deprecated upstream in favour of dev-perl/Mail-SPF # Masked for removal in 30 days. Bug #638432 dev-perl/Mail-SPF-Query pgp6PtgkgQgsP.pgp Description: OpenPGP digital signature

Re: [gentoo-dev] Last Rites: Ancient x11-drivers/*

On Fri, 24 Nov 2017 06:52:59 + Richard Bradfield wrote: > I guess I should put my hand up and admit to being "the one user" for > this driver. I've got an ancient netbook with an Intel GMA3600, for > which there is no accelerated Xorg driver, which means I'm stuck with > xf86-video-modesettin

Re: [gentoo-dev] Packages up for grabs: robbat2 edition

On Thu, 30 Nov 2017 18:19:23 + "Robin H. Johnson" wrote: > dev-perl/MogileFS-* On behalf of the Perl team I can keep this on life support till it ceases to be maintainable. ( And Perl is already on its maintainer list ) pgpsJ59UMf60E.pgp Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

On Wed, 13 Dec 2017 21:58:05 +0100 Thomas Deutschmann wrote: > b) Because not all devs care about stable Gentoo, I would recommend > auto-stabilization: I.e. if a package is in the repository for x days > build bot would try to build the package and mark the package stable > if everything passes.

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

On Sat, 09 Dec 2017 11:26:36 +0100 Michał Górny wrote: I ran this on a chroot. > 5. Run 'unsymlink-lib --migrate'. > > 6. Reboot your system and see if it still boots, possibly test if > important programs work. Also check if emerge starts but don't install > anything. If your system is now bro

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

On Fri, 15 Dec 2017 21:09:15 +0100 Michał Górny wrote: > Sounds like you've put some awful self-symlink into this directory. > The script incorrectly follows top-level symlinks when removing, I'll > fix that. If it helps, this is on a no-multilib install, and the tree if I roll back to its stat

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

On Thu, 14 Dec 2017 16:04:17 -0600 R0b0t1 wrote: > Can you be specific? Human memory is biased towards negative > experiences. If it's hard to actually describe the multitude of issues > that mixed systems cause then it is very likely mixed systems do not > cause many issues. We have mixed syste

Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

On Tue, 19 Dec 2017 20:11:04 -0600 R0b0t1 wrote: > I forgot most files were mirrored. So the infrastructure that is the > answer to my question is already in place. Consequently, I don't think > there's any reason to argue against this, unless it ultimately ends up > being a ton of work to packag

Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

On Thu, 21 Dec 2017 12:25:11 -0600 William Hubbs wrote: > I think there's some confusion here. I'm not trying to change the bar > for ~arch, just trying to understand what that bar is supposed to be. The bar for ~arch is "end users should have reasonable expectations that it mostly works for mos

[gentoo-dev] Last-rites: dev-perl/SVN-Simple

# Kent Fredric (10 Jan 2018) # Dead upstream, Broken since 2009. # Bug #644146. Removal in 30 days dev-perl/SVN-Simple pgp1f0Hmg13QE.pgp Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: Portage Dynamic Deps

On Mon, 22 Jan 2018 16:45:13 + Ciaran McCreesh wrote: > perl-cleaner is rather strong evidence that the Perl situation needs a > major change anyway... perl-cleaner is now *mostly* redundant. Its only residual use is catching circumstances where slot dependencies weren't adequately provided

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

On Sat, 27 Jan 2018 12:41:58 +0100 Michał Górny wrote: > find -name 'foo.tar.gz' Other than being *worse* than the current "ls" situation due to the existence of distfiles/git3-src/ and distfiles/git-src/ pgpyYGhahM8Dq.pgp Description: OpenPGP digital signature

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

On Sat, 27 Jan 2018 13:24:44 -0500 Michael Orlitzky wrote: > Fetch instructions for app-cat/pkg: > * > * Please download file1 from: > * wherever file1 can be found > * and move it to $DISTDIR/subdir1 > * > * Please download file2 from > * wherever file2 can be found > * and move it to $D

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

On Sun, 28 Jan 2018 14:03:07 +0100 Ulrich Mueller wrote: > How about "consecutive non-negative integer keys"? "Unsigned" ? pgpbMe9DskHZO.pgp Description: OpenPGP digital signature

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

On Tue, 30 Jan 2018 08:25:28 +0100 Michał Górny wrote: > W dniu wto, 30.01.2018 o godzinie 14∶21 +1300, użytkownik Kent Fredric > napisał: > > On Sat, 27 Jan 2018 12:41:58 +0100 > > Michał Górny wrote: > > > > > find -name 'foo.tar.gz' > &g

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

On Mon, 5 Mar 2018 17:52:54 -0800 Matt Turner wrote: > EAPI 2 removal bug: https://bugs.gentoo.org/648050 > > It seems like tons of churn to update old stable ebuilds to a new > EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for > example. New ebuild added with EAPI 6 bumped fr

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

On Tue, 6 Mar 2018 14:13:11 -0800 Matt Turner wrote: > The long tail of packages were packages that by definition didn't > require any maintenance or add to our collective cognitive overhead. > :) In some cases, they "didn't require maintenance" because nobody was using them. And because nobody

Re: [gentoo-dev] Integrating Portage with other package managers

On Wed, 7 Mar 2018 11:06:47 -0500 anote...@teknik.io wrote: > Having used Gentoo for a few years now, one thing that has been annoying > to me is the tremendous duplication of effort and uphill battle of > creating ebuilds (build recipes) for language-specific packages that > already have their ow

Re: [gentoo-dev] Integrating Portage with other package managers

On Wed, 7 Mar 2018 14:55:43 -0600 R0b0t1 wrote: > I think you missed my point: Why are they easier to use? Because it decouples your projects requirements from your OS and Vendor requirements. This becomes really useful if your OS/Vendor wishes to upgrade things and force people to upgrade thin

Re: [gentoo-dev] Functional portage with namespace

On Mon, 12 Mar 2018 07:55:46 +0900 Benda Xu wrote: > Ha, indeed many packages hardwrites "date of build" alike. That is a > hard question to define reproducibility. I would rather ignore the > timestamps when comparing two binaries. If a hard-timestamp is to be used, assuming you have portage

Re: [gentoo-dev] bug queue size over time

On Mon, 19 Mar 2018 19:33:11 -0700 "Paweł Hajdan, Jr." wrote: > Is it possible to get graphs of bugs.g.o bug queue size for certain > query (e.g. by assignee) over time? > > Best, > Paweł > The *data* is there to do it, but its a bit of a pain, you have to extract all the individual "changed"

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

On Tue, 20 Mar 2018 14:48:29 -0400 Michael Orlitzky wrote: > There's a real technical problem hidden in there. Since npm > (recursively!) bundles every dependency, nobody worries about > compatibility in their JS packages. You'll quickly find yourself stuck. Honestly, I expected at some point we

[gentoo-dev] Last rites: dev-perl/WWW-Bugzilla

# Kent Fredric (21 Mar 2018) # Not usable with versions of Bugzilla shipped by Gentoo since 2013, # Dead upstream. Use dev-perl/BZ-Client instead. # Removal in 30 days. Bug 651056 dev-perl/WWW-Bugzilla pgpOQtW1bOeQa.pgp Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

On Wed, 21 Mar 2018 01:44:11 + Herb Miller Jr. wrote: > If I am, then yes, some kind of automation > would be the only sane way to keep up In my experience you can't *really* rely on automation 100% for this sort of thing. Not while achieving quality results. Its viable for an overlay where

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

On Fri, 23 Mar 2018 11:53:40 +0100 Ulrich Mueller wrote: > Still, masking is the wrong way to express such preferences. If you > package.mask sys-devel/gcc then you say that something is wrong with > that package. Which I believe is not what you want to express here. I might have a better usecas

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

On Sat, 24 Mar 2018 09:02:20 +0100 Michał Górny wrote: > ...except that it is also used to say 'this is experimental version, > unmask at will' and Portage wants to unmask stuff for you anyway. Well, > I mean the default configuration of Portage, not mine. Yeah, that default I find incredibly st

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

On Sat, 24 Mar 2018 11:27:20 -0700 Zac Medico wrote: > The defaults certainly do not work perfectly in all situations. However, > there are a vast number of situations where using --autounmask-continue > will make appropriate package.mask changes without the need for any user > intervention. Its

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

On Sat, 24 Mar 2018 13:44:49 -0700 Zac Medico wrote: > That only happens when dependency satisfaction fails by normal means. And when that happens, it is better to bail and go "Uh oh, something bad", not "oh, right, lets install something that will likely make things worse and additional work to

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

On Sat, 24 Mar 2018 21:43:41 -0700 Zac Medico wrote: > But if the majority demographic is as you describe, then they shouldn't > be using anything having dependencies that require package.unmask or ** > keywords changes. Again, they *dont*, the problem is portage makes the mistake of thinking th

Re: [gentoo-dev] rfc: virtual/init for init process

On Thu, 26 Apr 2018 13:35:15 -0700 Zac Medico wrote: > emerge --depclean, resulting in an unbootable system. Just say-in. And depclean being very verbose doesn't do many favours here either. ( I regularly do >500 package depcleans and spotting things that aren't meant to be culled amongst tha

Re: [gentoo-dev] [RFC PATCH] profiles/base: Set initial ENV_UNSET (EAPI 7)

On Wed, 2 May 2018 17:42:19 +0200 Michał Górny wrote: > Now that EAPI 7 is accepted and implemented in Portage, provide > the initial environment blacklist for coming EAPI 7 ebuilds. The list > is based on existing eclasses, xdg-utils mostly. Rationale is provided > in the comment above ENV_UN

Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?

On Wed, 9 May 2018 18:12:32 +0100 "M. J. Everitt" wrote: > > On Wed, May 9, 2018 at 12:34 PM, Matt Turner wrote: > > It's worth noting that the default rules shipped with udev assign mode > > 0666 to the /dev/dri/renderD* device nodes. So, outside of a sanbox > > environment, any user may acce

Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?

On Wed, 9 May 2018 19:54:16 +0100 "M. J. Everitt" wrote: > Do correct me if I'm mistaken ... Right, just the statement of: "I wonder how that pans out for other init systems" Understandably introduces some confusion, when udev is not an init system, and is frequently used in conjunction with

Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation

On Sat, 16 Jun 2018 21:40:10 -0700 Matt Turner wrote: > Hello, > > VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and > some others in media-libs/mesa's VIDEO_CARDS. radeon and intel > corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has > meant classic r100, r200

Re: [gentoo-dev] Idea for a new project: gentoo-libs

On Fri, 22 Jun 2018 21:50:50 -0500 "Marty E. Plummer" wrote: > So, as you may be aware I've been doing some work on moving bzip2 to an > autotools based build. Recently I've ran into app-crypt/mhash, which is > in a semi-abandoned state (talking with the maintainer on twitter atm), > and I was th

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

On 4 February 2016 at 23:27, Jason Zaman wrote: > > www-servers/nginx nginx_modules_http_access nginx_modules_http_auth_basic > nginx_modules_http_autoindex nginx_modules_http_browser > nginx_modules_http_charset nginx_modules_http_fancyindex > nginx_modules_http_fastcgi nginx_modules_http_geo

Re: [gentoo-dev] Automatic Bug Assignment

On 31 January 2016 at 06:45, Alex Brandt wrote: > Would there be an > issue with adding a bug modification hook to bugzilla or a daily > job to re-assign bugs to ebuild owners (if a CPV is in the > subject)? I would argue the reason this probably isn't already in place might be related to how us

Re: [gentoo-dev] Automatic Bug Assignment

On 6 February 2016 at 06:41, Alec Warner wrote: > ; but 5% of the time is wrong. Just here, in the "5% are wrong" case, instead of the problem being resolved by bug wranglers, ... the problem has to be resolved by whoever got assigned. And they might not even be around in the next 2-3 weeks. Wh

Re: [gentoo-dev] Automatic Bug Assignment

On 6 February 2016 at 07:19, Rich Freeman wrote: > 'd be all for automated bug assignment. Usually when this comes up a > bunch of hero bug wranglers step up and say it isn't needed, because > we have hero bug wranglers. As long as people keep stepping up to do > that I'm not going to tell them

Re: [gentoo-dev] Automatic Bug Assignment

On 6 February 2016 at 09:47, Rich Freeman wrote: > That was my thought around having a query for bugs filed in the last > 24h. Basically they'd be auto-assigned, but people could choose to > review recent bugs to see if any were mis-assigned, and no action is > necessary if they're OK. The idea

Re: [gentoo-dev] Automatic Bug Assignment

On 6 February 2016 at 10:10, Michael Orlitzky wrote: > How about, if there's (exactly) one portage-compatible atom > in the summary and that package has (exactly) one maintainer, we > auto-assign it? Otherwise, leave it to the bug wranglers. One of my conceptual misgivings is in practice, there'

Re: [gentoo-dev] Automatic Bug Assignment

On 6 February 2016 at 11:19, Michael Orlitzky wrote: > > You also have to take into consideration how many of them have a valid > package atom in the summary, and how many of those would have exactly > one maintainer. That's a very-sub subset of the full list. Yeah. Now that I've gotten most of

Re: [gentoo-dev] Automatic Bug Assignment

On 7 February 2016 at 04:26, William Hubbs wrote: > One concern I see with making this part of the web ui for Bugzilla is > that Bugzilla would have to be able to parse the metadata.xml files in > our portage tree to find the maintainers. You could simplify it with a cron job that parses metada

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 9 February 2016 at 01:46, Michał Górny wrote: > 1. It is a conflict-induced fork. As such, it will never be merged > upstream and it will never be supported upstream. In fact, it is > continually forces to follow upstream changes and adapt to them. eudev > is more likely to break because of the

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

On 9 February 2016 at 10:41, Michał Górny wrote: > Well, the real issue here is that people are using USE_EXPAND as some > kind of 'here, upstream give us some grouped options, let's > thoughtlessly expose them all in some fancy USE_EXPAND without thinking > about usability of the solution!' > > O

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

On 9 February 2016 at 11:44, James Le Cuirot wrote: > nginx is monolithic, if a package per module is what you meant. Yeah. That's what I was afraid of. Given what you're doing there, there's practically no other way. Other than to tell Gentoo users that you're giving them the "Maximal power to

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

On 9 February 2016 at 11:59, Luis Ressel wrote: > Thanks for citing this, I think it demonstrates mgorny's point rather > nicely; we have global USE flags for many of those modules: > > * nginx_modules_http_perl -> perl > * nginx_modules_http_auth_pam -> pam > * nginx_modules_http_auth_ldap -> lda

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 9 February 2016 at 16:09, Rich Freeman wrote: > There will always be a > "poppyseed linux" whose purpose in life seems to be to preserve linux > without sysfs or some other obscure practice. This seems to be an attempt at painting the "stick with eudev" model as an "old fogies who are afraid

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 9 February 2016 at 18:27, Anthony G. Basile wrote: > all the vitriolic attacks i get about eudev come from the gentoo > community. outside of this community i get praise. In case my earlier messages stating a desire to exercise much caution gave the wrong impression, I just want to state fo

[gentoo-dev] "Lazy" use flags?

There's a frequent irritation I experience with the revolving door of REQUIRED_USE -> auto-unmask: There's no mechanism in place to automatically stop using a "REQUIRED" use flag when it ceases to be necessary. So you find yourself doing things like: - I want X - X only supports python 2.7 - X t

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 02:14, Daniel Campbell wrote: > Another concern, though, is it'd result in something similar. Instead > of "cat/foo bar baz" and later removing 'baz', you'd have "cat/foo bar > ~baz" (with '~baz' as 'enable this if you need to'). You'd still have > cruft left in your p.use f

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 02:22, Daniel Campbell wrote: > I can certainly see the benefit here, but wouldn't that still result > in (arguably) unnecessary (re)builds? If implemented well it'd also > result in depcleaning them when they're later unneeded, too, so I > guess it's a wash in that sense.

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 09:35, Róbert Čerňanský wrote: > > The question is whether you really need to specify the lazy use flag > explicitly. I would say that any flag which user did not set > explicitly to -baz or baz could be considered as lazy use flag. > > So if I'd have 'baz' set in /etc/port

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 14:12, Rich Freeman wrote: >> I'd personally rather the list of "automatically turn this on if >> required" be something I had the power to restrict than have a blanket >> "autodostuff", because in the event some USE can't be satisfied, the >> first time that USE flag was de

Re: [gentoo-dev] "Lazy" use flags?

On 11 February 2016 at 13:42, Rich Freeman wrote: > I'm not sure why I'd want to set a preference and then just have the > system ignore it without telling me. If I tell it I want a flag > on/off then yell at me if it is a problem. I "prefer" not to pull in python packages and build python supp

Re: [gentoo-dev] "Lazy" use flags?

On 11 February 2016 at 13:42, Rich Freeman wrote: >> soft disable = Disable, unless it would break a dependency > > I don't really see why these are needed. Just do what we are already > doing - use the settings in the profile and package defaults. And soft-disable would be for things where IU

Re: [gentoo-dev] "Lazy" use flags?

On 11 February 2016 at 15:51, Rich Freeman wrote: > In this case you just wouldn't enable python 2.7 support, but you > wouldn't disable it either. Portage would just pull it in where it is > needed. But you still need a mechanism in place if you *dont* want that to happen. I might choose to f

Re: [gentoo-dev] "Lazy" use flags?

On 12 February 2016 at 02:54, NP-Hardass wrote: > Just a slightly OT side note... Quite, these are the *sorts* of things I've been mulling over for a bit without coming to a concrete implementation idea. > I split mine off into a separate file (using a directory for package.use > ). > I proposed

Re: [gentoo-dev] "Lazy" use flags?

On 12 February 2016 at 03:19, M. J. Everitt wrote: > I would avoid complicating the USE flag system .. it's straightforward > as it is, and has already been 'tweaked' by the auto-unmask feature, > leading to large package.use files and has no support of per-category > files (that I know of). Aut

Re: [gentoo-dev] "Lazy" use flags?

On 12 February 2016 at 03:48, M. J. Everitt wrote: > Well, that's obvious Makes more sense if you read this: > Any file in this directory, directories of other profiles or top-level > "profiles" directory that begins with "package." or "use." > can be more than just a flat file. I

Re: [gentoo-dev] "Lazy" use flags?

On 12 February 2016 at 03:43, M. J. Everitt wrote: > auto-unmask has a very inconsistent, unstable way of > working with a package.use folder not file ... auto-unmask consistently adds items to the file with the highest dictionary sort. So if you name all the files with numerical prefixes, 00 .

Re: [gentoo-dev] Re: "Lazy" use flags?

On 12 February 2016 at 18:56, Duncan <1i5t5.dun...@cox.net> wrote: > So my USE="-* ..." (without letting portage do autounmasking) would > continue to work just like it does now, correct? I would hope so. And obviously, this feature would be potentially tenous, and might be wise to only activate

Re: [gentoo-dev] Uncoordinated changes

On 15 February 2016 at 00:37, Patrick Lauer wrote: > Or JSON, or YAML, or whatever > is trendy now. I would love a JSON form. I tried doing my own stuff with XML and I gave up in the complexity factory I found myself building around it :( Just ... not YAML. The YAML spec is much less well defin

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

On 24 February 2016 at 17:24, Duncan <1i5t5.dun...@cox.net> wrote: > Particularly when the basic changelog information is there, it's simply > quibbling about chronological or reverse-chronological order we're doing > now, and people who /really/ care about it by rights should be going > straight t

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

On 24 February 2016 at 20:29, Duncan <1i5t5.dun...@cox.net> wrote: > I guess another way of putting it in the context of changelogs, would be > that if gentoo were using git merges correctly, a changelog summary > generator could simply take the high-level merge summary comments and > turn that int

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

On 25 February 2016 at 18:03, Duncan <1i5t5.dun...@cox.net> wrote: > Which I am (running from the git repo), and that ability to (as a user, > easily) actually track all that extra data was one of my own biggest > reasons for so looking forward to the git switch for so long, and is now > one of the

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

On 25 February 2016 at 21:02, Consus wrote: > Well, we do have one > > https://gitweb.gentoo.org/repo/gentoo.git/log/dev-lang/perl > > I bet folks want to check out what's new in their local copy of Portage > tree. With a custom, portage oriented, on-demand log generator you could produc

Re: [gentoo-dev] XML Schema files for metadata.xml, projects.xml and repositories.xml, for review and testing

On 7 March 2016 at 07:12, Justin wrote: >> Slots are not accepted in elements? Is that intentional? If so, >> is there something else we can use? >> > > We should definitely include SLOTs in the allowed syntax. Enable HTML5 audio/video support via media-libs/gstreamer:1.0 Enable HTML5 audi

Re: [gentoo-dev] CVS headers in ebuilds

On 4 April 2016 at 08:57, Ulrich Mueller wrote: > Does anyone still use the CVS $Id$ keywords that are in all ebuilds' > headers, or are they being expanded anywhere? Or is there any other > reason why they should be kept? Last time this came up, a sole example case was mentioned, but it might h

Re: [gentoo-dev] CVS headers in ebuilds

On 4 April 2016 at 14:43, Robin H. Johnson wrote: > We'd have to find all of those files and explicitly create .gitattribute > files, per directory, for them. I was under the impression that a .gitattribute file in the root directory sufficed? ( I maybe have misinterpreted what you said, but th

Re: [gentoo-dev] Migrate to Phabricator

On 18 April 2016 at 23:44, Jonas Jelten wrote: > especially to dump bugzilla. Dumping bugzilla at this time would be a regression really. "Lets just discard millions of bugs and their history and important context" is not really an option for a web accessible opensource project with lots of inbou

Re: [gentoo-dev] Migrate to Phabricator

On 19 April 2016 at 01:19, Kristian Fiskerstrand wrote: > References: > [0] > https://archives.gentoo.org/gentoo-dev/message/f74961c953d5ffedd1af9a67fdda6407 Based on the comments in this thread, I'd say I was not entirely unfounded in being pessimistic. Two trends struck out at me, and assumin

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

On 21 April 2016 at 06:38, Ian Stakenvicius wrote: > Well so far the only needs I have run into for the win32 flag has > been in relation to choosing UI toolkit support for cairo and gtk+ > (and possibly others in the future), which is why I saw the parallel. Given you're not using the flag to i

Re: [gentoo-dev] Reminder: ALLARCHES

On 4 May 2016 at 16:46, Matt Turner wrote: > Having built many stages for an "unstable" arch (mips) has taught me > one thing: it's awful being unstable-only. There's no end to the > compilation failures and other such headaches, none of which have > anything at all to do with the specific archite

Re: [gentoo-dev] Re: On banning merge commits

On 8 May 2016 at 20:58, Duncan <1i5t5.dun...@cox.net> wrote: > Or to put it a different way, if we're not going to use git's rich > distributed branch development and tracking, forcing everything to single > chain on the main tree, why did we bother switching to git in the first > place? That was

Re: [gentoo-dev] On banning merge commits

On 8 May 2016 at 23:57, Rich Freeman wrote: > How does a merge make it any easier/harder to mess up the entire tree? > I can see how they can make the history easier/harder to read but in > the end I believe the content of the tree itself ends up being > whatever was in the index when you made th

Re: [gentoo-dev] On banning merge commits

On 9 May 2016 at 00:09, Anthony G. Basile wrote: > 1. announce to gentoo-dev@ the intention to start a branch intending to > merge > > 2. hack hack hack > > 3. test the merge for any conflicts etc, > > 4. announce to the list a date/time to merge > > 5. if okay, ermge I think that's a bit excess

Re: [gentoo-dev] On banning merge commits

On 9 May 2016 at 05:03, Alexis Ballier wrote: > I was under the impression that merging is needed in order to preserve > commit signatures when e.g. merging someone else's work. Correct, but if the person applying the commits to tree is in fact reviewing them as they go, then the fact they re-si

Re: [gentoo-dev] On banning merge commits

On 10 May 2016 at 00:23, Rich Freeman wrote: > which introduces some of the uncleanliness of non-rebased > merge commits. In general I'm a fan of rebasing merge commits. Non-rebased merge commits are worst when the merge involves a collision resolution. While you can in theory rebase merge co

Re: [gentoo-dev] On banning merge commits

On 11 May 2016 at 00:04, Alexis Ballier wrote: > well, then I can commit crap with --author m...@gentoo.org and claim he > made me rebase it :) Well, if you're going down that line ... You don't rebase it, you just merge it, than then mrp claims obama forced his hand to write the commit at gunp

Re: [gentoo-dev] On banning merge commits

On 11 May 2016 at 22:21, Alexis Ballier wrote: > > yes, and it was meant to be :) > > > my point was more that if we want signed commits, then better have > author sign it, and thus use merge Eh, I see it more a "signed commits don't really add any value to this discussion". Both signing on mast

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 17 May 2016 at 19:37, Pallav Agarwal wrote: > For normal users we wouldn't. But currently, arch-testers need to make a > judgement call on what to test when a stable-req bug is filed. Tests run in > src_test are provided by upstream, and does not guarantee that a package > that has been merged

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 17 May 2016 at 20:46, Tobias Klausmann wrote: > And as for my pet peeve, tests that are known to fail, can we > also annotate that somehow so I don't waste hours running a test > suite that gives zero signal on whether I should add the stable > keyword? Even a one-line hin in the stabilization

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 18 May 2016 at 04:05, Sébastien Fabbro wrote: > Basically CI for ebuilds: it could be implemented as a script living > in the package directory, something like a .travis.yml in the GitHub > repositories or may be an EAPI change. Debian has a similar project > [1]. Upstream could provide CI test

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 18 May 2016 at 12:35, M. J. Everitt wrote: > Yes, whilst that's a special case, it would be desirable to collaborate > with another maintainer/team/project to devise a test schedule that was > independent from the target language, if possible. But there will always > be exceptions and issues an

Re: [gentoo-dev] Proposal for enhancement to PMS/EAPI7+

On 18 May 2016 at 17:40, Ulrich Mueller wrote: > Only two lines. Do you think this is untidy? It only becomes untidy where you don't already have a src_install. Then it becomes 4 lines. 4 lines of which 3 are redundant and simply re-codify existing behaviour. -- Kent KENTNL - https://metac

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

On 21 May 2016 at 19:41, Michał Górny wrote: > Hello, > > > Those of you who read my blog post on LINGUAS [1] may already know > what's going on. For those who didn't, short summary: > > In EAPI 5 and newer, all variables listed in USE_EXPAND are supposed to > be unconditionally exported with thei

Re: [gentoo-dev] Re: [RFC] How to deal with LINGUAS mess?

On 21 May 2016 at 21:00, Ulrich Mueller wrote: > Why would users have to rebuild more often? Language support in a > package will change with a version bump, when they must rebuild in any > case. But changing IUSE would cause users to cause rebuilds under --new-use, even though no actual changes

Re: [gentoo-dev] please remove me off your mailing list

On 24 May 2016 at 08:08, Dale wrote: > Nope. It doesn't work that way. Try this: > > List-Unsubscribe: > > Send a empty email to that and I think you have to confirm. > > Dale A nice approach I recently saw to this problem on another mailing lis

Re: [gentoo-dev] please remove me off your mailing list

On 24 May 2016 at 09:22, Kristian Fiskerstrand wrote: > give a man a fish and he has food for a day, teach a man to fish and he > has food for a lifetime But if you feed a man while you teach him, he's better equipped to learn. :p Hence, the suggestion includes both. - Solve the immediate issu

Re: [gentoo-dev] please remove me off your mailing list

On 24 May 2016 at 11:19, Vadim A. Misbakh-Soloviov wrote: > > As a father of 3 kids, I'd say: if you'll teach while feeding, he would say > "yes, I understand", but will not really study anything, and would *claim* you > to feed him again next time... Sure, that is a risk, but its kinda differen

Re: [gentoo-dev] What are eblits?

On 27 May 2016 at 10:28, rindeal wrote: > > 1) what are they? > 2) why are they used? My best explanation is its a way to re-use very large amounts of code between 2 ebuilds, without resorting to: a) Copying the whole ebuild and hoping you find the relevant part in diffs b) Not needing reams of

Re: [gentoo-dev] Re: What are eblits?

On 28 May 2016 at 05:35, rindeal wrote: > This whole concept, however, raises the question (as suggested by > Ciaran McCreesh and Duncan) if it's allowed to split ebuilds to > several bash scripts and what have QA and dev-manual got to say in > this regard? Personally I'd say the biggest risk fr

Re: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems

On 2 June 2016 at 07:33, Martin Vaeth wrote: > > I prefer to have at least 5% of the ebuilds working and the other > being fixable (if their maintainers want to spend the effort) > than to remove a concept which breaks also these 5% and turns > all ebuilds non-fixable, in principle. Changing the

Re: [gentoo-dev] Repo mirror & CI project news: 'stable' gentoo branch, new repo stats, faster CI

On 6 June 2016 at 04:31, rindeal wrote: > Isn't no commit approach better than having broken commit + revert > commit? Huh? Its doing "replicate to github on pass using a merge commit". -- Kent KENTNL - https://metacpan.org/author/KENTNL

<    1   2   3   4   5   6   7   8   9   >