[gentoo-dev] [PATCH 1/1] profiles: unset USE=session in default/linux/make.defaults.

The "session" USE flag has been enabled by default for all linux profiles in default/linux/make.defaults since 2010. According to the comment in that file, the flag was added for dev-lang/php where session support is near-critical. But, now that we have an IUSE default, the global setting is

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

On 12/21/2017 02:27 PM, Jeroen Roovers wrote: > On Thu, 21 Dec 2017 10:10:30 -0500 > Michael Orlitzky <m...@gentoo.org> wrote: > >> The "cracklib" USE flag ... this commit removes it from base/make.defaults. >> >> Closes: https://bugs.gentoo.org/63569

[gentoo-dev] Last rites: sci-calculators/qalculator, x11-misc/basqet, x11-misc/okindd

# Michael Palimaka <kensing...@gentoo.org> (22 Dec 2017) # Dead upstream. Requires dead Qt 4. # Masked for removal in 30 days. sci-calculators/qalculator # Michael Palimaka <kensing...@gentoo.org> (22 Dec 2017) # Dead upstream. Requires dead Qt 4. # Masked for removal in 30 days. x11

[gentoo-dev] Last rites: x11-misc/qsynergy

# Michael Palimaka <kensing...@gentoo.org> (22 Dec 2017) # Dead upstream. Requires dead Qt 4. # Masked for removal in 30 days. x11-misc/qsynergy

[gentoo-dev] Last rites: app-editors/znotes

# Michael Palimaka <kensing...@gentoo.org> (22 Dec 2017) # Dead upstream. Requires dead Qt 4. # Masked for removal in 30 days. app-editors/znotes

[gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

The "cracklib" USE flag has long (since 2007ish) been enabled by default for all profiles. But, the features that it provides are not critical for any of the packages that use it: typically, the library is used to evaluate a candidate password and to prevent the user from choosing a weak one.

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

On 12/20/2017 02:41 PM, Virgil Dupras wrote: > > Maybe some kind of official overlay for packages needing love? We > could send outdated packages there to die or to be born again if the > right person picks it up. > > The overlay could have more relaxed rules (not malicious and looking > good?

Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged

On 11/27/2017 10:16 AM, Mike Gilbert wrote: > On Mon, Nov 27, 2017 at 6:46 AM, Aaron W. Swenson > wrote: >> >> You should now be able to do compilation and tests without having the >> user/group created. For example, dev-db/postgresql doesn’t need the >> postgres system

[gentoo-dev] [PATCH 1/1] profiles: unset default USE=justify in hardened profiles.

The "justify" USE flag is local to only app-editors/nano, but it was enabled by default in two hardened profiles, * hardened/linux/amd64/make.defaults * features/hardened/amd64/make.defaults The reasoning for that is lost to time, but probably dates back to when nano was part of the @system

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

On 12/12/2017 01:24 PM, Rich Freeman wrote: > > As far as I'm aware the standing policy already exists that > maintainers can stabilize their own packages on amd64. https://bugs.gentoo.org/510198 is this thing on

Re : Re: [gentoo-portage-dev] Constraint-Based Dependency Solver for Portage: a prototype

repository, you could directly ask me Does anyone have suggestions on that topic? Again, many thanks. I really hope that with everyone's feedback, suggestions, and help, we could make something useful from this prototype. Michael Lienhardt PS: I forgot in my previous mail to talk about the other

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

On 12/09/2017 04:00 PM, Michał Górny wrote: > > rm -r /lib.{old,new} /usr/lib.{old,new} > It probably won't hurt anything, but that should be run in BASH.

[gentoo-portage-dev] Constraint-Based Dependency Solver for Portage: a prototype

or missed. Best Regards, Michael Lienhardt PS: list of uninstallable packages: dev-java/jruby-1.7.12 media-video/nvidia-settings-340.58 dev-ruby/bitescript-0.0.9 dev-java/spring-core-3.2.4 app-i18n/ibus-table-code-1.2.0.20100305 dev-ruby/weakling-0.0.4 sci-libs/ogdi-3.1.5-r1 dev-java/jcs-2.0

[gentoo-dev] Last rites: net-ftp/oneclickftp

# Michael Palimaka <kensing...@gentoo.org> (07 Dec 2017) # Dead upstream. Requires dead Qt4. # Masked for removal in 30 days. Bug #640138. net-ftp/oneclickftp

[gentoo-dev] Last rites: dev-vcs/qct

# Michael Palimaka <kensing...@gentoo.org> (07 Dec 2017) # Dead upstream. Requires dead Qt4. # Masked for removal in 30 days. Bug #640138. dev-vcs/qct

Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?

On 12/02/2017 03:43 PM, Alon Bar-Lev wrote: > Hi, > Any reason we do not publish hardened/no-multilib? > I see we have[1] in place and is working if explicitly added. > Thanks, > Alon > > [1] profiles/features/hardened/amd64/no-multilib > I'm not sure if anything is using that particular

[gentoo-dev] Last rites: dev-vcs/qsvn

# Michael Palimaka <kensing...@gentoo.org> (02 Dec 2017) # Depends on dead Qt 4. Dead upstream. # Masked for removal in 30 days. Bug #639252. dev-vcs/qsvn

Re: [gentoo-dev] NEWS item for games destabling

On 11/27/2017 03:37 PM, Arve Barsnes wrote: > > Sounds kind of weird? If he has keyworded the game package, shouldn't it > just never install that version if it depends on an unstable package? That's right, but if there are two available ~arch versions, one of which has all stable dependencies

Re: [gentoo-dev] Re: cmake + ninja vs autotools

On 11/19/2017 01:00 PM, William L. Thomson Jr. wrote: >> >> This is broken: Static metadata like DEPEND must not depend >> on dynamic data like environment variables which are supposed >> to change at emerge time. > > I wondered about that. I guess adding to DEPEND via eclass is bad then. > So

[gentoo-dev] Re: cmake + ninja vs autotools

On 11/16/2017 02:27 PM, William L. Thomson Jr. wrote: > It maybe worth considering switching the default generator in the > cmake-utils.eclass from the default of emake to ninja. > > - : ${CMAKE_MAKEFILE_GENERATOR:=emake} > + : ${CMAKE_MAKEFILE_GENERATOR:=ninja} > > For those with cmake ebuilds

[gentoo-dev] Re: Open Build Service

Hi, another two cents: On 11/10/2017 12:03 AM, Samuel Bernardo wrote: > Hi, > > I send this email to know the devs opinion about Gentoo integration with > Open Build Service[1]. > > When creating specialized images and using an automated process for > testing before deployment, I think that

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/12/2017 10:21 AM, Ulrich Mueller wrote: > >> * Change the PMS to remove "undefined behavior" and replace it with >> "empty directories must be tracked, and may only be removed once no >> installed package is using them," or something along those lines. >> That leaves the

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/12/2017 08:43 AM, Michał Górny wrote: > > I'm not convinced a QA warning is valid, given that not every empty > directory is meaningful. You're going to either cause people to create > unnecessary 'keepdir's, or to be swamped by false positives. The warning would essentially be saying,

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/11/2017 02:26 PM, Michał Górny wrote: >> >> As far as the actual implementation goes, I'm not sure that >> automatically-generated ".keep" files are better than having the package >> manager maintain its own database. The latter would be more complex, but >> would avoid littering everyone's

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/11/2017 02:58 AM, Michał Górny wrote: >> >> Certainly "keepdir" will make the directory non-empty, but with the >> additional (unwanted) side-effect that the directory won't be removed >> when the package is uninstalled. > > Wrong. It creates a dotfile inside it, and removes it along with

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/10/2017 04:36 PM, Damo Brisbane wrote: > > Re for...keepdir, I found removing it then the /var/log/fabio folders > were not getting created, so keeping it in there. You need to tell the ebuild to create that directory one way or another. The "dodir" function will create the directory, but

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/09/2017 11:08 PM, Damo Brisbane wrote: > I've run up a couple of golang based ebuilds - for the fabio load > balancer. My first run at it, not completely sure of any follow up > process, mentor? other posting, overlap with existing work? Anyway, > would appreciate the feedback. Your

Re: [gentoo-dev] [RFC] GLEP 65 v2: Post-install QA checks (now with post-merge checks)

On 10/25/2017 03:18 AM, Michał Górny wrote: >>> ... >>> The QA checks can inspect the installation image or live system >>> respectively, >> >> Respective to what? > > To the type of check, as explained later? If you want to help, then > please be specific instead of asking questions and

Re: [gentoo-dev] [RFC] GLEP 65 v2: Post-install QA checks (now with post-merge checks)

On 10/17/2017 02:12 PM, Michał Górny wrote: > > Abstract > > > ... > The QA checks can inspect the installation image or live system respectively, Respective to what? > output and store both user- and machine-oriented QA warning logs, manipulate > the files and abort the install, as

[gentoo-dev] USE flags in base profiles

The following USE flags are enabled by default in our base/linux profiles. I think they can be disabled, possibly turning them on in package.use (or in the ebuilds) if they are important. Yes, no? 1. USE=cracklib (base/make.defaults) This might belong in the hardened profile, but it doesn't

Re: [gentoo-dev] Manifest2 hashes, take n+1-th

On 10/19/2017 06:32 PM, Hanno Böck wrote: > > Counterproposal: Just use SHA512. > > There isn't any evidence that any SHA2-based hash algorithm is going to > be broken any time soon. If that changes there will very likely be > decades of warning before a break becomes practical. > Every WiFi

Re: [gentoo-dev] pkg_rm_pretend?

On 10/11/2017 12:20 PM, Kent Fredric wrote: > 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?" > This might also scratch the itch

[gentoo-dev] Last rites: media-sound/lastfm-desktop

# Michael Palimaka <kensing...@gentoo.org> (01 Oct 2017) # Fails to build (bug #622632). Requires dead and vulnerable qtwebkit4 # (bug #620710). Masked for removal in 30 days. media-sound/lastfm-desktop

[gentoo-dev] Last rites: net-misc/dnetstats

# Michael Palimaka <kensing...@gentoo.org> (30 Sep 2017) # Depends on dead qt4. Dead upstream. # Masked for removal in 30 days. net-misc/dnetstats

[gentoo-dev] Last rites: app-office/qcharselect

# Michael Palimaka <kensing...@gentoo.org> (30 Sep 2017) # Depends on dead qt4. Dead upstream. # Masked for removal in 30 days. app-office/qcharselect

[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected

On 09/29/2017 10:33 AM, Marty E. Plummer wrote: > On Fri, Sep 29, 2017 at 08:29:07AM +0000, Michael Haubenwallner wrote: >> On 09/29/2017 03:36 AM, Marty E. Plummer wrote: >>> On Thu, Sep 28, 2017 at 07:35:20PM +, Mike Gilbert wrote: >>>> On Wed, Sep 20, 2017

[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected

On 09/29/2017 03:36 AM, Marty E. Plummer wrote: > On Thu, Sep 28, 2017 at 07:35:20PM +, Mike Gilbert wrote: >> On Wed, Sep 20, 2017 at 10:01 PM, Marty E. Plummer >> wrote: >>> arfrever suggests I send a mail here, as there are other packages which >>> may be affected

[gentoo-dev] Last rites: kde-misc/konstruktor

# Michael Palimaka <kensing...@gentoo.org> (26 Sep 2017) # Requires dead Qt 4. Dead upstream. # Masked for removal in 30 days. kde-misc/konstruktor

[gentoo-dev] Last rites: kde-misc/kookie

# Michael Palimaka <kensing...@gentoo.org> (26 Sep 2017) # Requires dead Qt 4. Dead upstream. # Masked for removal in 30 days. kde-misc/kookie

Re: [gentoo-dev] Reviving the Sandbox project

On 09/22/2017 05:51 PM, R0b0t1 wrote: > On Thu, Sep 21, 2017 at 2:56 PM, Michał Górny wrote: >> [1]:https://wiki.gentoo.org/wiki/Project:Sandbox >> > > I think I understand, in principle, why a sandbox could be useful, but > would it not be more productive to follow up with

[gentoo-dev] Last rites: media-libs/herqq

# Michael Palimaka <kensing...@gentoo.org> (21 Sep 2017) # Requires dead Qt 4. Dead upstream. # Masked for removal in 30 days. media-libs/herqq

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

On 09/12/2017 09:50 AM, Michał Górny wrote: > > If you consider doing 'rst2html.py glep-0001.rst > glep-0001.html' hard, > then I'm afraid I won't be able to ever satisfy you. > Does that command produce something that looks as good as this?

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

On 09/11/2017 05:06 PM, Michał Górny wrote: > > Example of GitHub rendering: > https://github.com/mgorny/glep-draft/blob/preamble-test/glep-0001.rst > > IMO this beats the preview/editing capabilities MediaWiki gave us. > If that's how we get an offline preview, I'm not sold =P I can run

Re: [gentoo-dev] [RFC] Reinstating old-school GLEPs masterplan

On 09/11/2017 01:08 PM, Michał Górny wrote: > Hi, > > TL;DR: I'd like to reinstate the old-school GLEPs in .rst files rather > than Wiki, put in a nice git repo. > I generally agree with you that wiki markup is terrible and that a text editor and a git repo is The Right Way to do things (with

[gentoo-dev] Last rites: app-editors/qwriter, dev-util/kscope, dev-util/monkeystudio, dev-util/universalindentgui

# Michael Palimaka <kensing...@gentoo.org> (11 Sep 2017) # Requires dead Qt 4. Dead upstream. Fails to build with new x11-libs/qscintilla. # Masked for removal in 30 days. Bug #628224. app-editors/qwriter # Michael Palimaka <kensing...@gentoo.org> (11 Sep 2017) # Requires dead Qt 4. D

[gentoo-dev] Last rites: app-text/kding

# Michael Palimaka <kensing...@gentoo.org> (09 Sep 2017) # Requires dead Qt 4. Dead upstream. # Masked for removal in 30 days. app-text/kding

[gentoo-dev] Last rites: sys-process/procexp

# Michael Palimaka <kensing...@gentoo.org> (09 Sep 2017) # Requires dead Qt 4. Dead upstream. Unmaintained. # Masked for removal in 30 days. sys-process/procexp

[gentoo-dev] Last rites: x11-apps/python-whiteboard

# Michael Palimaka <kensing...@gentoo.org> (09 Sep 2017) # Requires dead Qt 4. Dead upstream. Unmaintained. # Masked for removal in 30 days. x11-apps/python-whiteboard

Re: [gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed

On 09/06/2017 02:39 PM, Chris Mayo wrote: > > I believe @EXAMPLE is only for the first documentation block introducing the > eclass. > > At least where it is used for functions the text doesn't show up in the man > page. > e.g. prefix.eclass hprefixify() and prefixify_ro() > Looks like

Re: [gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed

On 09/03/2017 11:56 AM, Chris Mayo wrote: > # > # The following snippet would suggest app-misc/foo for optional foo support, > # app-misc/bar or app-misc/baz[bar] for optional bar support > Would the @EXAMPLE tag[0] make sense here? [0] https://devmanual.gentoo.org/eclass-writing/index.html

[gentoo-dev] Last rites: dev-qt/qtphonon

# Michael Palimaka <kensing...@gentoo.org> (03 Sep 2017) # Dead upstream. Use media-libs/phonon instead. # Masked for removal in 30 days. Bug #629144. dev-qt/qtphonon

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 10:24 AM, Michael Orlitzky wrote: > On 08/30/2017 10:10 AM, Ian Stakenvicius wrote: >> >> I wonder though, per the original idea, wouldn't it make more sense to >> allow uninstallation to continue and just very verbosely >> warn/log/document what the pa

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 10:10 AM, Ian Stakenvicius wrote: > > I wonder though, per the original idea, wouldn't it make more sense to > allow uninstallation to continue and just very verbosely > warn/log/document what the package removal didn't do, so that it can > be done later by hand as needed? > My

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 09:46 AM, Ian Stakenvicius wrote: > > For adding this to FEATURES and RESTRICT, are we moving into PMS > modification territory? And if so, is this something we want to do > just for this? > The new RESTRICT value would need a PMS update, but the "just for this" part is where it

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 09:26 AM, Ulrich Mueller wrote: > >> 1a. If you try to uninstall a user package, it should die(), because >> calling userdel can be a security risk if the user still owns >> files. > > This rather sounds like a case for package manager support with > some property

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 05:25 AM, Michał Górny wrote: > > This package does not belong in Gentoo. We do packaging, not some ugly > malware that prevents users from uninstalling itself. Every package must > be uninstallable. Even if it destroys my system, developers have no > right to prevent valid

Re: [gentoo-dev] Of death and prerm

On 08/30/2017 04:04 AM, Alexis Ballier wrote: > > Is there any point in dying in any phase after (or during) > pkg_postinst ? > files are already live by then; what would this achieve ? > I was hoping that die() called in pkg_prerm would have a similar effect as pressing Ctrl-C when portage is

[gentoo-dev] Of death and prerm

What should happen if an ebuild calls "die" in pkg_prerm? The issue arose while trying to create a package that could not be uninstalled except as part of an upgrade. The first thing that came to mind was to have it die in pkg_prerm. What portage does is *appear* to crash, but then continue

[gentoo-dev] Last rites: media-gfx/kgrab

# Michael Palimaka <kensing...@gentoo.org> (27 Aug 2017) # Requires deprecated Qt/KDE4. Dead upstream. Use kde-apps/spectacle instead. # Masked for removal in 30 days. media-gfx/kgrab

[gentoo-dev] Last rites: kde-misc/colibri

# Michael Palimaka <kensing...@gentoo.org> (27 Aug 2017) # Doesn't work with Plasma 5. Dead upstream. # Masked for removal in 30 days. kde-misc/colibri

[gentoo-dev] Last rites: media-gfx/kflickr

# Michael Palimaka <kensing...@gentoo.org> (27 Aug 2017) # Doesn't work anymore. Dead upstream. # Masked for removal in 30 days. media-gfx/kflickr

Re: [gentoo-dev] Guidelines for dangerous USE flags

On 08/22/2017 02:44 PM, Robin H. Johnson wrote: > From a Gentoo Infrastructure team perspective, we'd strongly prefer USE > flags, because that fits better into existing configuration management > tools, almost none of which have handling for EXTRA_ECONF or rebuilding > after EXTRA_ECONF changes

[gentoo-dev] Guidelines for dangerous USE flags

The net-analyzer/nrpe package has a ./configure flag: --enable-command-args allows clients to specify command arguments. *** THIS IS A SECURITY RISK! *** Read the SECURITY file before using this option! Back in nrpe-2.x, it was available via

Re: [gentoo-dev] Re: Revisions for USE flag changes

On 08/14/2017 08:01 AM, Jason Zaman wrote: > > I'll give an example where revbumps are significantly inferior to > --changed-use. > > ... With --changed-use, only the people who need it (ie selinux > users) will rebuild and everyone is happy (selinux users because the > program now works and

Re: [gentoo-dev] Revisions for USE flag changes

On 08/13/2017 12:06 PM, William Hubbs wrote: > > There is a down side you didn't talk about -- more work for the arch > teams and for us in terms of stabilizations. > > When we revbump, a new revision automatically gets ~ keywords on all arches > unless we make an exception. If a revision

Re: [gentoo-dev] Revisions for USE flag changes

On 08/13/2017 01:01 AM, Hans de Graaff wrote: > On Sat, 2017-08-12 at 05:58 -0400, Michael Orlitzky wrote: >> >> I simply overlooked the global USE change in make.conf because IMO >> it's a nonsense operation. > > This also happens routinely as new python and ruby v

Re: [gentoo-dev] Re: Revisions for USE flag changes

On 08/12/2017 10:52 PM, Duncan wrote: > > How so? Are you arguing that deciding to system-wide switch to/from > pulseaudio, systemd, or gstreamer is nonsense? > The meaning of any one USE flag varies widely across packages. I could never say "I want to enable USE=gstreamer" for every package

Re: [gentoo-dev] Re: Revisions for USE flag changes

On 08/12/2017 10:32 PM, Duncan wrote: >> >> What if you fix a runtime issue by dropping a flag? It's more confusing >> than it has to be: the USE flag exception interacts weirdly with all the >> other rules. > > Bad example as it's a security vuln, which requires masking/removing > vulnerable

Re: [gentoo-dev] Revisions for USE flag changes

On 08/12/2017 06:29 AM, Rich Freeman wrote: > > My gut feeling is that the change you want is probably a good thing, > but it will never happen if you can't provide a single example of > something bad happening due to the lack of a revbump. There's an unfixed security vulnerability with USE=foo,

[gentoo-dev] Re: Revisions for USE flag changes

On 08/12/2017 08:29 PM, Rich Freeman wrote: > On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky <m...@gentoo.org> wrote: >> On 08/12/2017 03:03 AM, Michał Górny wrote: >>> >>> Please provide some examples of recent in-place USE changes that benefit >>> f

[gentoo-dev] Re: Revisions for USE flag changes

On 08/12/2017 08:16 PM, Michael Orlitzky wrote: > On 08/12/2017 12:22 AM, Michael Palimaka wrote: >> >>> Q. But what if I maintain firefox, and I need to change IUSE? >>> >>> If the IUSE change isn't important, just make the new revision in a >>&

Re: [gentoo-dev] Re: Revisions for USE flag changes

On 08/12/2017 12:22 AM, Michael Palimaka wrote: > >> Q. But what if I maintain firefox, and I need to change IUSE? >> >> If the IUSE change isn't important, just make the new revision in a >> branch and wait to commit it later when there are more changes >&g

Re: [gentoo-dev] Revisions for USE flag changes

On 08/12/2017 04:39 AM, Paweł Hajdan, Jr. wrote: >> >> The option is the same as --newuse except it ignores functionality that >> you suggest to remove. You could certainly deprecate one option or the >> other if they became the same. But the core functionality of >> system-wide USE changes (by

Re: [gentoo-dev] Revisions for USE flag changes

On 08/12/2017 03:03 AM, Michał Górny wrote: > > Please provide some examples of recent in-place USE changes that benefit > from revbumps. > There is no single example. Things only get simpler if *all* USE changes come with a new revision.

[gentoo-dev] Re: Revisions for USE flag changes

On 08/12/2017 09:50 AM, Michael Orlitzky wrote: > Q. But what about the rebuilds? > > For most packages, the rebuilds simply don't matter. Unless you're > the maintainer of libreoffice, firefox, chromium, etc. -- just do the > revision and forget about the (quick) rebuilds.

Re: [gentoo-dev] Revisions for USE flag changes

On 08/11/2017 08:59 PM, Michael Orlitzky wrote: > > Does --changed-use help there? I can see the argument for --newuse, but > I thought --changed-use only applied to flags that were added or removed > to installed packages (which becomes impossible, if we require new

Re: [gentoo-dev] Revisions for USE flag changes

On 08/11/2017 08:45 PM, Brian Evans wrote: > > I disagree about removing --newuse and --changed-use from portage. > This is not their only use. > > If you happen to change the effective use system wide, USE= in make.conf > for portage, these options scan the entire system for such changes. >

[gentoo-dev] Revisions for USE flag changes

We have a pull request for the devmanual that will update the revision documentation; namely, when to create a new one: https://github.com/gentoo/devmanual.gentoo.org/pull/67 The comments bring up an issue that I think can benefit from some hindsight. Specifically, the PR says that it's OK to

[gentoo-dev] Re: Gentoo QA Help

On 08/11/2017 12:30 AM, Michael Mair-Keimberger wrote: > Hi Gentoo Team, > > As some of you may noticed i started to clean up some old patches in the > gentoo portage tree. I did so already a while ago, and like before I'm > using a small script in order to identify unused patches.

[gentoo-dev] Gentoo QA Help

e ${MY_PN} gonna be still a problem... The 000.txt file contains usually homepages who timed out. Usually i try 10 seconds to get an httpcode before giving up. Comments, suggestions and even patches are welcomed. :) I hope someone can use these findings. Kind regards, Michael Mair-Keimberger signature.asc Description: Digital signature

[gentoo-dev] Re: sys-boot/plymouth needs major fixes/maintainer

On 08/05/2017 12:37 AM, Mart Raudsepp wrote: > On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote: >> I am looking into this for openrc. I copied it over to my personal >> overlay. > > Ok, how about I mark myself as maintainer then and add you as co > -maintainer for OpenRC aspects, and you can

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

On 08/04/2017 02:50 AM, Michał Górny wrote: > > Why is it fine for you to handicap everyone else for your personal > laziness? As it's been told more than once, you write ebuild *once*, > people read it *multiple times*. Look, I'm sorry if I've been overly confrontational. I emailed angry and I

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

On 08/03/2017 06:33 PM, Ulrich Mueller wrote: >>>>>> On Thu, 3 Aug 2017, Michael Orlitzky wrote: > >> The developer handbook that I just said didn't mention variables in >> HOMEPAGE at all. > > It did, even back in 2004: > https://sources.gentoo.org/cg

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

On 08/03/2017 03:39 PM, Mike Gilbert wrote: >> >> (The old handbook never mentioned variables, from what I can see.) >> > > The developer handbook was also a "policy" manual of sorts when it existed. The developer handbook that I just said didn't mention variables in HOMEPAGE at all.

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

On 08/03/2017 02:57 PM, Mike Gilbert wrote: > > It's in the devmanual, which imposes gentoo-specific policy on top of PMS. > It would be nice if that were true, but there's a lot of junk and/or personal preference documented in the devmanual, and a lot of actual-policy that's still missing

Re: [gentoo-dev] Allow variable refs in HOMEPAGE

On 08/03/2017 11:33 AM, Mike Gilbert wrote: > I would like to remove the ban on variable references in the HOMEPAGE > variable in ebuilds. > What ban are you referring to? The Portage Manager Specification doesn't say anything of the sort. Seriously though, whatever sort of tricks your

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

On 07/25/2017 04:29 PM, Mike Gilbert wrote: > > I don't feel I should be obligated by policy to support this use case. > One revbump per push seems sufficiently safe for 99.9% of users. > > If you want to do more revbumps, you are free to do so. > Can I also delete packages and break the tree

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

On 07/25/2017 09:23 AM, Michał Górny wrote: > > How is that relevant? Revision bumps are merely a tool to encourage > 'automatic' rebuilds of packages during @world upgrade. I can't think of > a single use case where somebody would actually think it sane to > checkout one commit after another,

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote: > First, the assumption in our processes seems to be that many or > important bugs will be due to architecture-specific differences, and I > wonder if that assumption really holds up. Do arch testers for a smaller > arch often find problems that were

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

On 07/25/2017 07:22 AM, Sergei Trofimovich wrote: > 2. Q: How to make arch testing faster and easier? > >A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing > required" will be automatically tested and keyworded. > > [handwave] automated tinderbox setup would help a

[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

On 07/25/2017 06:05 PM, Michał Górny wrote: > Hi, everyone. > > There have been multiple attempts at grasping this but none so far > resulted in something official and indisputable. At the same time, we > end having to point our users at semi-official guides which change > in unpredictable ways.

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

On 07/25/2017 07:52 AM, Michał Górny wrote: > > I have no clue what you mean. I'm just saying that if you push 10 > changes in 10 commits, you don't have to go straight to -r10 in a > single push. > Exactly. Do that instead of hoping that no one checks out your intermediate commits. There's no

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

On 07/25/2017 04:05 AM, Michał Górny wrote: > > Here's the current draft: > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git > It's mostly fine, but there are two changes I disagree with: > When doing one or more changes that require a revision bump, bump the > revision in the commit

[gentoo-dev] Re: taking a break from arches stabilization

On 07/12/2017 07:26 AM, Kristian Fiskerstrand wrote:> That presumes that the maintainer is the one calling for the > stabilization, and it is not an automated procedure simply due to 30 > days in ~arch. In this particular case, look for the number of bug > reports filed in Gentoo for the issue.

[gentoo-dev] Re: taking a break from arches stabilization

On 07/12/2017 12:25 AM, James Le Cuirot wrote: > On Tue, 11 Jul 2017 16:15:51 +0200 > Kristian Fiskerstrand <k...@gentoo.org> wrote: > >> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote: >>> On 07/11/2017 03:47 PM, Michael Palimaka wrote: >>>> The

[gentoo-dev] Re: taking a break from arches stabilization

On 07/12/2017 12:15 AM, Kristian Fiskerstrand wrote: > On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote: >> On 07/11/2017 03:47 PM, Michael Palimaka wrote: >>> The main risk of breakage of a package moving from testing to >>> stable is always at build time an

[gentoo-dev] Re: taking a break from arches stabilization

On 07/12/2017 12:13 AM, Kristian Fiskerstrand wrote: > On 07/11/2017 03:47 PM, Michael Palimaka wrote: >> The main risk of breakage of a package moving from testing to >> stable is always at build time anyway. > > citation needed > Based on my experience doing package

[gentoo-dev] Re: taking a break from arches stabilization

On 07/11/2017 11:06 PM, Rich Freeman wrote: > On Tue, Jul 11, 2017 at 8:59 AM, Michael Palimaka <kensing...@gentoo.org> > wrote: >> On 07/11/2017 09:29 AM, Andrew Savchenko wrote: >>> >>> Even if such stabilization is allowed, there are unanswered >>&g

[gentoo-dev] Re: taking a break from arches stabilization

On 07/11/2017 09:29 AM, Andrew Savchenko wrote: > On Mon, 10 Jul 2017 22:17:34 +0200 Kristian Fiskerstrand wrote: >> On 07/10/2017 10:02 PM, Rich Freeman wrote: >>> On Mon, Jul 10, 2017 at 3:57 PM, Andrew Savchenko >>> wrote: On Mon, 10 Jul 2017 13:49:40 -0400 Rich

[gentoo-dev] Re: stabilization candidates, July 2017

On 07/10/2017 06:41 PM, Paweł Hajdan, Jr. wrote: > Hey folks, > > If you'd like to help Gentoo stable be more up to date, please read on. > > See > > for potential stabilization candidates (over 1000 of them). > > These

<    3   4   5   6   7   8   9   10   11   12   >