Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-09 Thread Peter Stuge
Andreas K. Hüttel wrote: > it's probably time to deprecate the amd64 17.0 profiles! I for one am not so excited about the amd64 17.1 profiles. On the surface it appeared to me that one developer has "taken over" just about everything, which (regardless of the individual) can't be a good thing..

Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Peter Stuge
Michał Górny wrote: > Read: it's important to slap users to satisfy developer's wannabes. LOL! Michał, you managed to squeeze both misrepresentation and ad hominem into so few words. Please take care. Anyway, you missed my point: It's important that (the project) developers set accurate

Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Peter Stuge
Joonas Niilola wrote: > some of you may already have seen the new packages.gentoo.org page, >   https://packages.gentoo.org/ I had not seen that - that's wonderful! I would just request that /packages/ is removed from the start of package URLs. I understand how this makes request routing more

Re: [gentoo-dev] Last-rites: dev-libs/liboobs

2020-08-03 Thread Peter Stuge
Jimi Huotari wrote: > # Jimi Huotari (2020-08-04) > # No consumers since 2015, and no known stand-alone use. > # Removal in 30 days. > dev-libs/liboobs Wut - isn't that a really poor reason to remove from the tree? :\ Why not just keep it unless there is an actual technical problem? (Security,

Re: [gentoo-dev] Last rites: */* More Py2 only items

2020-07-21 Thread Peter Stuge
Remco Rijnders wrote: > I'd like to volunteer myself as proxy maintainer for this package. As > this would be the first package in gentoo I'd be working on, I ask for > advice on the following two points: Note that I'm no developer but have been proxy-maint for some time. > - Can the removal of

Re: [gentoo-dev] Gentoo/OpenBSD current status

2020-06-01 Thread Peter Stuge
Benda Xu wrote: > > I was wondering if the openbsd prefix support is something > > that is still garnering any interest from gentoo? > > There is still interest in Gentoo. But no one seems to have energy to > take care of it. FWIW I have interest in this as well. > Your contribution is

Re: [gentoo-dev] [RFC] Anti-spam for goose

2020-05-24 Thread Peter Stuge
Kent Fredric wrote: > > While services such as reCAPTCHA are (as said) massively intrusive, there > > are other, much less intrusive and even terminal-compatible ways to > > construct > > a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle > > for a human above the

Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel

2020-05-24 Thread Peter Stuge
Michał Górny wrote: > Hence my question: do you find 'do not remove kernels listed > in bootloader config' feature useful? Do you think it should remain > the default? Do you think it is worthwhile to continue supporting it? I continue to use LILO because simpler and more mature code is good,

Re: [gentoo-dev] [RFC] Anti-spam for goose

2020-05-22 Thread Peter Stuge
Stop motivated attackers or keep low barrier to entry; pick any one. :) Michał Górny wrote: > CAPTCHA > == > A traditional way of dealing with spam -- require every new system > identifier to be confirmed by solving a CAPTCHA (or a few identifiers > for one CAPTCHA). > >

[gentoo-dev] user.eclass ignores ROOT/SYSROOT

2020-05-05 Thread Peter Stuge
Hi, I'm trying something out over here and I'm surprised to find that acct-group/* do not work with ROOT+SYSROOT != "/". Should I file yet another bug about this? I suppose the limitation is in user.eclass, but what about the 11 bugs already filed about exactly this problem? They are easy to

Re: [gentoo-dev] zoom concerns

2020-04-08 Thread Peter Stuge
Kent Fredric wrote: > Syntax above not expected verbatim, just food for thought, I think this is a really good and useful idea. I would love to see it. > the nature of this metadata is that it SHOULD NOT be in the ebuild > itself, as it is inherently "repo based", the installed values of >

Re: [gentoo-dev] ceph's static-libs

2020-04-05 Thread Peter Stuge
James Le Cuirot wrote: > Damn, I realised just as I hit send that there's a caveat here and > that's sub-dependencies. If you're building a partially static binary > then I think you're okay. A fully static binary obviously needs all its > dependencies to be static and that includes any

Re: [gentoo-dev] Use acct-* for qmail users

2019-09-15 Thread Peter Stuge
Mike Gilbert wrote: > Do the users actually need home directories? Technically probably no, but ~qmail is easier to type than /var/qmail. TBH I actually always type it out anyway. Mike Gilbert wrote: > If you don't want to maintain them, you'll need to find someone else > to do it. If noone

Re: [gentoo-dev] Gentoo i486 support

2018-08-22 Thread Peter Stuge
Rich Freeman wrote: > Is there a large population that actually runs x86 on modern > hardware, or is ancient hardware a significant use case? There are current products with pre-686 instruction sets. Companies such as DM still produce 586-class SoCs for embedded and industrial. These[1][2] are

Re: [gentoo-dev] News item review: OpenSSH LDAP support

2018-08-06 Thread Peter Stuge
Hi Thomas, I suggest some improvements.. Thomas Deutschmann wrote: > Title: OpenSSH LDAP support Perhaps qualify this a bit, e.g. "Migration required for OpenSSH with LDAP" > When your sshd authenticates against LDAP, you have to migrate your s,When,If, > current setup to a new one using

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Peter Stuge
Mart Raudsepp wrote: > > * USE=udev means different things for different packages. You think > > it "makes udev work" or whatever, but nobody has any idea what it > > does for half of the packages that use it. The meaning is package- > > specific, so the default should be package-specific. >

Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?

2018-07-18 Thread Peter Stuge
M. J. Everitt wrote: > I'm thinking something along the lines of the following: > - Line one is limited to / and some Key Word that defines the > type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP, > EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the > issue

Re: [gentoo-dev] x11-terms/xterm up for grabs

2018-06-25 Thread Peter Stuge
Johannes Huber wrote: > I will take it. Thanks. I can help as proxy-maintainer if you like. //Peter

Re: [gentoo-dev] newsitem: baselayout 2.5 changes (round 2)

2018-02-13 Thread Peter Stuge
William Hubbs wrote: > The first change is that ROOTPATH is no longer set. This means all of > the *sbin directories will be added to the default path for all users > instead of just the root user. Maybe add a sentence about why this is changing or even neccessary, to avoid perception of weakened

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

2018-01-11 Thread Peter Stuge
Maybe this is a discussion for -project, then? Andreas K. Huettel wrote: > a few outside trolls who > * keep pushing their personal agenda in endless threads, > * confuse their own inability to contribute with being a mistreated underdog, > * and keep commenting opinionated on technical things

Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)

2017-12-08 Thread Peter Stuge
Andreas K. Huettel wrote: > > Independent of whether William now unsubscribed or not, he's now enjoying a > lengthy (1 year until review) vacation from all Gentoo communication channels. > I don't understand two things about Gentoo: 1. style: How can anyone consider "enjoying a vacation" to

Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-05 Thread Peter Stuge
Daniel Campbell wrote: > On Sun, Dec 03, 2017 at 12:18:04AM +0100, Michał Górny wrote: > > I'd like to establish the following changes to the mailing lists: > > > > 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be > > initially restricted to active Gentoo developers. > > I

Re: [gentoo-dev] We Are All wltjr On This Blessed Day

2017-12-05 Thread Peter Stuge
William L. Thomson Jr. wrote: > No one questions why I stepped down. I have wondered what happened, but haven't felt able to investigate. Please know that I wouldn't take sides without investigating, and I think that an overwhelming majority is also like that. A problem is that you'll only ever

Re: [gentoo-dev] We Are All wltjr On This Blessed Day

2017-12-04 Thread Peter Stuge
I'm quite unimpressed by how mgorny and jstein behave there. I wouldn't accept that, were I leading the project. //Peter

Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-03 Thread Peter Stuge
Hi Michał, Michał Górny wrote: > major problems with some of the posters for more than a year. Please believe me when I say that I know what this feels like. I want to applaud and thank everyone who has been tackling/discussing this issue in private, and I especially want to applaud taking

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

2017-11-24 Thread Peter Stuge
William L. Thomson Jr. wrote: > Or uber minimal, can't get much smaller still 5.20s > https://travis-ci.org/Obsidian-StudiosInc/asspr#L165 > https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac Consider AM_INIT_AUTOMAKE([foreign no-define no-installinfo no-installman]) foreign

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

2017-11-24 Thread Peter Stuge
William L. Thomson Jr. wrote: > Or uber minimal, can't get much smaller still 5.20s > https://travis-ci.org/Obsidian-StudiosInc/asspr#L165 > https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac That takes 2.0s here, on quite old hardware, though with primed cache. >

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

2017-11-24 Thread Peter Stuge
William L. Thomson Jr. wrote: > I cannot understand why systems get faster, yet configure seems to > take the same amount of time and is super slow. The generated configure scripts can be fork intensive, which is still fairly expensive. But I think the problem is more with poorly written

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

2017-11-23 Thread Peter Stuge
Martin Vaeth wrote: > > 1. Doing a full clean build [..] the speed of make or ninja is hugely > > offset by the compilation speed, and their overhead is negligible. > > It depends on the definition of negligible. For huge projects like > boost or chromium it is several minutes It's arguably a

Re: [gentoo-dev] Java 9 on Gentoo

2017-11-17 Thread Peter Stuge
William L. Thomson Jr. wrote: > > If you have any suggestions as to what I should look at to better > > understand the OpenJDK build system I would very much appreciate > > them. .. > Build OpenJDK stand alone. Get familiar with that. It used to be that one could not build OpenJDK without already

Re: [gentoo-dev] Package up for grabs

2017-08-23 Thread Peter Stuge
Michał Górny wrote: > W dniu nie, 23.07.2017 o godzinie 16∶13 +0200, użytkownik Manuel Rüger > napisał: > > dev-libs/libgit2 > > I'm going to co-maintain this with the full set (-glib, pygit2). I've > used it in the past, and I think it'll still come in handy > in the future. I too have some

Re: [gentoo-dev] Changing PMS to Portage Manager Specification

2017-08-14 Thread Peter Stuge
Alexander Berntsen wrote: > While the PMS perhaps hasn't been an unequivocal success, it's still a > good effort with some success. I would be disappointed to see the > proposed change, and view it as a bad sign for Gentoo. As far as technical documentation about how ebuilds work (the core of

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

2017-08-04 Thread Peter Stuge
Michael Orlitzky wrote: > All this is to say that "easy to read" is in the eye of the beholder. > For ebuilds in the tree, the beholder is usually the maintainer, which > is why I think the choice should be left up to him. I think what mgorny says is that locality of ebuilds is an important

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

2017-07-25 Thread Peter Stuge
Michael Palimaka wrote: > The 30 day waiting period is useful for smoking out major upstream bugs, > but can't replace stabilisation integration testing. For example, > package foobar may build fine in ~arch but fails in stable because it > needs a newer libbaz. So that's either because of an

Re: [gentoo-dev] New eclass: opam.eclass

2017-07-25 Thread Peter Stuge
Good work on the refactoring! Alexis Ballier wrote: > > > if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then > > > > It’s always been recommended to me that we should use the [[ … ]] > > form. > > Doesn't make much difference here Some; you need neither quote nor {} in expansions within [[

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

2017-07-24 Thread Peter Stuge
Thank you for working on this. Sergei Trofimovich wrote: > Can this proposal make a difference and make gentoo better and > easier to work with? > > Does it try to attack the right thing? > > Does it completely miss the point? I hold a perhaps radical view: I would like to simply remove

[gentoo-dev] Sanity check: enewuser in binpkg with portage-utils

2017-07-20 Thread Peter Stuge
Hi, I have some ebuilds which use enewuser to create groups and users in pkg_setup(), and make use of those groups and users in src_install() in exeopts, insopts etc. Is there any reason that this would not always work reliably with binpkgs? Ie. regardless of whether I am using portage or

Re: [gentoo-dev] Integrating Ada into toolchain.eclass, again

2017-05-20 Thread Peter Stuge
Luke A. Guest wrote: > Thoughts? I can't comment on your strategy, but I do agree with and support your goals of being able to use more Ada in Gentoo. Thanks to you and others for your work on this! :) //Peter

Re: [gentoo-dev] [RFC] Master plan for fixing elibtoolize

2017-03-18 Thread Peter Stuge
Alexis Ballier wrote: > > If elibtoolize results in different binaries being produced, then it's > > done wrong in the first place. AFAIU the primary goal of elibtoolize > > logic is to fix issues on recent systems with outdated build systems. > > Which is certainly not something that needs to be

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-11 Thread Peter Stuge
Anthony G. Basile wrote: > >> I proxy maintain bitcoins for luke-jr. He wants to propose a patch > >> against the bitcoin eclass. The following is his proposed change. > >> I'll commit it after review. > > > > Please do not do that, Anthony. > > I don't have time nor the familiarity to

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-07 Thread Peter Stuge
Anthony G. Basile wrote: > I proxy maintain bitcoins for luke-jr. He wants to propose a patch > against the bitcoin eclass. The following is his proposed change. > I'll commit it after review. Please do not do that, Anthony. > Bitcoin Knots includes a number of enhancements users may find

Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Peter Stuge
Peter Stuge wrote: > --8<-- mount(8) .. > portable. The mount(8) command internally uses udev symlinks > -->8-- That's of course only the mount in util-linux. //Peter

Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Peter Stuge
Ian Stakenvicius wrote: > > WilliamH wants everyone using /dev/disk/by-label/ > > paths in fstab to instead use LABEL= , to avoid issues if udev > > doesn't create the symlinks before localmount tries to use them. .. > UUID is the same situation in this case -- in fstab you can do it by > UUID= or

Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Peter Stuge
Rich Freeman wrote: > We give you the tools when you install your system, and we give you > the tools when it is time for renovations... On that note - thank you very much to everyone who contributes to Gentoo! <3 //Peter

Re: [gentoo-dev] Commented packages in the @system set

2016-10-26 Thread Peter Stuge
waltd...@waltdnes.org wrote: > For a build-from-source distro like Gentoo, gcc and associated > tools are a vital part of the distro. A stage4 created (and updated) on a catalyst build farm doesn't need to have gcc, but may still need libstdc++. //Peter

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

2016-10-26 Thread Peter Stuge
Rich Freeman wrote: > I think you could make an argument that voluntarily placing that > header on your work is an assignment of copyright. > You could also argue otherwise. Especially in jurisdictions where copyright can not be assigned. //Peter

Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Peter Stuge
Ian Stakenvicius wrote: > by mount and works regardless of device manager, therefore removing > the the dependency of having udev-settle before mounting these paths. the the Looks good. Thanks. //Peter

Re: [gentoo-dev] Commented packages in the @system set

2016-10-26 Thread Peter Stuge
Raymond Jennings wrote: > Why exactly isn't libstdc++ a separate package anyway? I guess because it has no separate upstream. I think a separate package would be a fantastic improvement though. //Peter

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

2016-10-18 Thread Peter Stuge
Patrice Clement wrote: > We should strive for keeping a clean and linear history. I agree with you. > Cherry-picking is not my go-to solution as far as I'm concerned. > It requires a bit of setup and is clearly tedious: you must know > in advance the full SHA-1 of commit(s) you want to

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

2016-08-06 Thread Peter Stuge
Peter Stuge wrote: > How can I help improve ..? Michał Górny wrote: > people focused on preaching and/or implementing random crap-based > solutions without even stopping for a few minutes to consider what > we exactly need. You could interpret my question as "what e

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

2016-08-06 Thread Peter Stuge
Michał Górny wrote: > Or file a pull request @ https://github.com/gentoo/gentoo/pulls. > That's the most convenient solution for most of proxy-maint team members. How can I help improve that problematic situation? It's not cool to gravitate the project towards GitHub Inc. //Peter

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

2016-08-06 Thread Peter Stuge
Felix Janda wrote: > I'd like become a proxy-maintainer for app-editors/nvi. Sweet! If there are some open bugs then please upload patched ebuilds and other neccessary files to the bugtracker, ideally as output by git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode to get

Re: [gentoo-dev] Packages up for grabs

2016-08-06 Thread Peter Stuge
Andrew Savchenko wrote: > On Sat, 6 Aug 2016 13:37:19 +0000 Peter Stuge wrote: > > Hi Pacho, many thanks for your work, but.. .. > > ..do you think you can arrange to post everything in one mail, > > instead of 14 different ones in a single day? > > I suppose these po

Re: [gentoo-dev] Packages up for grabs

2016-08-06 Thread Peter Stuge
Hi Pacho, many thanks for your work, but.. Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho

Re: [gentoo-dev] Package up for grab

2016-08-03 Thread Peter Stuge
Daniel Campbell wrote: > Tox .. > All it needs is feature parity with video, voice, and file sharing. And a new name. :) //Peter

Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-05 Thread Peter Stuge
Rich Freeman wrote: > > do not be shy to suggest reading materials .. > Do NOT skip descriptions of blobs/trees/commits/objects/reference/etc. > If you don't understand the data model, you'll never get it. I have an intro here: http://peter.stuge.se/git-data-model //Peter

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-13 Thread Peter Stuge
Consus wrote: > This is how overlays work right now. What are suggesting to change? Technically not a lot in terms of how packages get installed. It's more about offering support and/or visibility for overlays. So technically it's about hosting user repos, making the ebuilds within easily

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread Peter Stuge
Alexander Berntsen wrote: > It would be fruitful to encourage every single Gentoo user to have > their own repository. And this repository should be publicly available. .. > What are your thoughts? Genius. This is exactly what I have been doing for many years, but I couldn't have expressed it as

Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

2016-05-18 Thread Peter Stuge
Cool! aide...@gentoo.org wrote: > +_find_dep_version() { > + local pn="$1" > + local p > + > + pushd "${EPREFIX}$(get_erl_libs)" >/dev/null > + for p in ${pn} ${pn}-*; do > + if [[ -d ${p} ]]; then > + echo "${p#${pn}-}" > +

Re: [gentoo-dev] Reminder: ALLARCHES

2016-05-04 Thread Peter Stuge
Mike Gilbert wrote: > "doing your job" Remember that everyone is a volunteer. > dropping stable keywords on everything but the bare necessities Gentoo magically does a number of things which upstream never intended and do not intentionally support. It is amazing, and thank you so much to

Re: [gentoo-dev] Last rites: app-cdr/webcdwriter

2016-01-26 Thread Peter Stuge
James Le Cuirot wrote: > # James Le Cuirot (26 Jan 2016) > # No new release since 2008. Removal in 30 days. > app-cdr/webcdwriter Is there a problem with it? I don't use it and have no interest in this particular package but merely lack of release is not a valid reason to

Re: [gentoo-dev] USE=desktop-file request

2016-01-06 Thread Peter Stuge
Rich Freeman wrote: > I'm not sure it is really worth trying to control this via a USE flag > for such a light dependency. I don't care how light dependencies are - I want to be able to choose every single one that is optional. That is Gentoo's killer feature, and I am thoroughly disappointed

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-04 Thread Peter Stuge
Michael Orlitzky wrote: > If anyone has a concrete idea that works better, it's not too late to > change it. Add code to init script and service file to check the config before starting the program, and react if PHP5 is still set. //Peter

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-04 Thread Peter Stuge
Kristian Fiskerstrand wrote: > Maybe I'm thinking things too difficult, why not just define both -D > PHP and -D PHP5 in the transition period and suggest this config for > any change? Because it mostly just defers the problem. If the desire is to move away from PHP5 then I would suggest to

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-04 Thread Peter Stuge
Michael Orlitzky wrote: > >> If anyone has a concrete idea that works better, it's not too late to > >> change it. > > > > Add code to init script and service file to check the config before > > starting the program, and react if PHP5 is still set. > > Which init script? For Apache. > It's

Re: [gentoo-dev] [PATCH 0/5] python-r1 suite: python_gen_impl_dep() function

2015-12-24 Thread Peter Stuge
Michał Górny wrote: > Please review the patches sent in reply. The changes look good to me, but maybe the function should have 'use' in its name; it's not obvious that the parameter is about USE as opposed to PN. //Peter

Re: [gentoo-dev] Re: repo/gentoo.git, or how committing is challenging

2015-12-22 Thread Peter Stuge
Patrick Lauer wrote: > my time, spent to work around deficiencies I shouldn't even see - > if other people had done their job. Ah but that's the thing - it *isn't* their job. They are volunteering. That's a very different construct. And yes, you do have to work around deficiencies created by

Re: [gentoo-dev] Re: repo/gentoo.git, or how committing is challenging

2015-12-21 Thread Peter Stuge
Ryan Hill wrote: > You want me to use a potentially unstable live ebuild instead? > Well, no, that's not gonna happen. Are you demanding that someone else produces for you, and refusing to do anything but consume? If the stable version is broken and if needing to use ~ or live is not up to your

Re: [gentoo-dev] repo/gentoo.git, or how committing is challenging

2015-12-14 Thread Peter Stuge
Patrick, Patrick Lauer wrote: > Like seriously, every time I try to approach this set of problems I > run into enough stupidity Stop the silly complaining and help work on solving the problem instead. If you can contribute then do so. If not, your options are to hire someone who is, or await

Re: [gentoo-dev] Breakage and frustration

2015-12-14 Thread Peter Stuge
Rich Freeman wrote: > a big question is how to make it happen without just throwing > complaints on the folks who are trying their best to keep it all going. The answer to this is the same as it has always been: Demonstrate that you are capable and reliable and given social compatibility then

Re: [gentoo-dev] Use GLEP27!

2015-12-14 Thread Peter Stuge
Ulrich Mueller wrote: > (If directories are really needed, we could use the scheme foreseen > in [1] for package.* and use.* files.) So package.{users,group} ? > Also a mechanism how a subprofile could undefine a user or group > defined in its parent seems to be missing. Maybe set the id to -1

Re: [gentoo-dev] git update hook: detecting missing Manifest DIST entries

2015-12-07 Thread Peter Stuge
Robin H. Johnson wrote: > 1. Script #1 (helper), that given an ebuild, spits out the filenames of the >distfiles. >- Use an explicitly specified PORTDIR for eclasses. >- Must NOT rely on the ebuild directory structure (i'd love to give >it the ebuild via stdin and tell it the

Re: [gentoo-dev] RFD: Replacement for versionator.eclass in PMS (for EAPI 7?)

2015-11-29 Thread Peter Stuge
Ulrich Mueller wrote: > 1. Will these three functions be sufficient, or have we overlooked >anything important? Something that comes to mind as probably being semi-frequent is to transform a version number component into a Gentoo -p number. Or do you suggest doing that by replacing the

Re: [gentoo-dev] rfc: adding sbin directories to PATH for all users

2015-11-26 Thread Peter Stuge
Mike Gilbert wrote: > > I would like for us to discuss adding the sbin directories to PATH for > > all users. > > I support this idea. The distinction between bin and sbin is stupid. I support it too FWIW. //Peter

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

2015-11-18 Thread Peter Stuge
Peter Stuge wrote: > Robin H. Johnson wrote: > > However, the largest sticking point, even with parallel threads, is that > > it seems the base ChangeLog generation is incredibly slow. It averages > > above 350ms per package right now (at 19k packages in a full cycle,

Re: [gentoo-dev] Re: ChangeLog

2015-11-14 Thread Peter Stuge
Michael Orlitzky wrote: > Once users have the full git repo on their machines, they have two > options. They can update it efficiently with `git pull`, or they can > update it with rsync by using `emerge --sync`. You can even mix the two, I don't think you can mix the two, because how my local

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

2015-11-14 Thread Peter Stuge
Robin H. Johnson wrote: > However, the largest sticking point, even with parallel threads, is that > it seems the base ChangeLog generation is incredibly slow. It averages > above 350ms per package right now (at 19k packages in a full cycle, it's > a long time), but some packages can take up to 5

Re: [gentoo-dev] Revision diffs

2015-11-06 Thread Peter Stuge
Michael Orlitzky wrote: > after making those three revbumps, what I see is that I added and > removed the entire ebuild three times. True, but useless. Try git show/log -M //Peter

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

2015-10-16 Thread Peter Stuge
Anthony G. Basile wrote: > if you emerge when using a vanilla kernel or some other which doesn't > support user.pax.* on tmpfs, then you'll loose those markings. Would it be at all possible to add the markings after/as files land on the destination filesystem instead? It's not really intuitive

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

2015-10-16 Thread Peter Stuge
Anthony G. Basile wrote: >> Would it be at all possible to add the markings after/as files land >> on the destination filesystem instead? .. > since we sometimes have to do pax markings during src_compile() or > src_test() or early during src_install() etc, the safest approach is to > preserve

Re: [gentoo-dev] www-apps/otrs: needs new maintainer

2015-09-15 Thread Peter Stuge
Stefan G. Weichinger wrote: > * the former dev has removed himself as maintainer > * the package is rather outdated now in portage > * there are some ebuilds already which could be considered to be added > (at least as unstable, sure) > > pls advise, If you have interest in this package then you

Re: [gentoo-dev] Better way to direct upstream bugs upstream?

2015-08-30 Thread Peter Stuge
upstream hat on Kent Fredric wrote: I've always seen it as a case where Gentoo devs stand as a layer of sanitization between downstream and upstream. This is the last thing I want. Did you play the whisper game as a kid? I want direct contact with the user who can reproduce the problem in the

Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

2015-08-15 Thread Peter Stuge
Hi and happy Git days! :) Robin H. Johnson wrote: It expands to the hash of the blob of that file; and from that, you can identify which commits the blob exists in. $ git ls-tree HEAD README 100644 blob 08ae16956b8944da2fef75fee892dcba457cf4f0README $ $ (stat --printf='blob %s\0'

Re: [gentoo-dev] Re: useflag policies

2015-08-12 Thread Peter Stuge
Sergey Popov wrote: qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) Fine by me, if you would ask. May I suggest instead: qt? ( qt5? ( dev-lang/qt$something:5 ) qt4? ( dev-lang/qt$something:4 ) ) Alexandre Rostovtsev wrote: qt? ( qt5? (

Re: [gentoo-dev] rfc: openrc mount service prototype

2015-07-31 Thread Peter Stuge
William Hubbs wrote: [1] http://www.semver.org Major version zero (0.y.z) is for initial development. Anything may change The problem is that version 0 hit stable Just treat version numbers as the meaningless counters they are. I can't just randomly break things from 0.17 to 0.18 for

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

2015-07-09 Thread Peter Stuge
Rich Freeman wrote: I suspect that trying to force it would basically end up putting the entire distro on hold until most of the current devs quit, I think you're right. I also think those developers should quit right here and now. I don't think they will. //Peter

Re: [gentoo-dev] Re: Git workflow

2015-07-06 Thread Peter Stuge
William Hubbs wrote: I think I understand what he's asking for... I think he is asking the question, What changed in commit hash. If you use the hash of a merge commit with git show, you get nothing, so the merge commit is useless in terms of following changes. I have explained why merge

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

2015-07-06 Thread Peter Stuge
Alec Warner wrote: Its difficult to make a large change like all commits require review, particularly for long-time contributors who are expecting to move quickly. I think it's a character flaw (maybe hubris due to lack of experience and/or ignorance?) to lack the humility to say that I would

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

2015-07-06 Thread Peter Stuge
hasufell wrote: that said... I don't think it currently makes sense to enforce a strict global review workflow. For the record, neither do I, and I never proposed that it should hold up starting to use Git. //Peter

Re: [gentoo-dev] Git workflow

2015-07-05 Thread Peter Stuge
C Bergström wrote: 3) Ever tried to make a patch of the *actual* merge commit? Can one of the advocates of merge show me the git command to do that? (Sure you can diff between 2 commits, but the merge commit likes to avoid being seen) If there are no conflicts when merging then the

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

2015-07-04 Thread Peter Stuge
William Hubbs wrote: If we do add a code review system, it should be fully accessible from the command line. Pybugz is almost there for bugzilla; the only thing it lacks is the ability to reply to specific comments. Gerrit is also almost there, it has an ssh interface which is very usable for

Re: [gentoo-dev] Git workflow

2015-07-04 Thread Peter Stuge
C Bergström wrote: To start I hate git.. I have used it for years now and the multitude of ways that are possible to accomplish nearly the same thing are *annoying* at best.. I'd be interested to hear a couple of examples of what you mean, perhaps in a private mail. Tack på förhand. :)

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

2015-07-04 Thread Peter Stuge
NP-Hardass wrote: or do they typically restrict review to a certain class of users? Hm, why would that end up happening? I'm not saying it can't, just that I don't understand why it would. What do you have in mind? Well, it was just proposed earlier in the thread that it could be used

Re: [gentoo-dev] Git workflow

2015-07-04 Thread Peter Stuge
C Bergström wrote: 1) Rebase doesn't obscure history, That's plain wrong. Rebasing changes the parent of your commit. That means that others can no longer see the history of your commit, specifically its original parent. Sometimes the parent is irrelevant, sometimes it is critical. (Unless

Re: [gentoo-dev] A few mgorny/ projects for upstream-grabs

2015-06-15 Thread Peter Stuge
Michał Górny wrote: dev-util/atomic-install A nice one -- tool to quasi-atomically install files from $D to live system. The idea is to replace live files as fast as possible, and quickly revert that if it fails in the middle. I like the idea, but I would personally like to see it

Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml

2015-06-08 Thread Peter Stuge
Duncan wrote: The point you made here was console-based workflow, as quoted above, and that's what I addressed, arguing that even if was valid at some point, it's no longer the factor it once was. For you, that is. Be aware that this creates your bias. You can't extrapolate from your own

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

2015-05-12 Thread Peter Stuge
Rich Freeman wrote: I find email an incredibly frustrating experience all-around. It works great as long as everybody doesn't use anybody for hosting who isn't in the top-10 provider list, and doesn't use a mailing list. DMARC marks top-10 essentially creating their own walled email garden.

Re: [gentoo-dev] RFC: c++14 global USE flag

2015-04-25 Thread Peter Stuge
Anthony G. Basile wrote: The way gcc is dealing with this is that it is NOT bumping the soname so we can get libraries linking aginst libstdc++.so with the wrong abi and you get breakage. .. I'm not sure how to solve this one Is there any alternative to implementing the different sonames in

Re: [gentoo-dev] CI services for Gentoo Social Contract meanings of dependant notifications on depgraph breakages

2015-04-16 Thread Peter Stuge
Rich Freeman wrote: Jenkins, Buildbot and others are existing libre options in this ecosystem, but aren't keeping pace with development. Politics that somehow matter usually require compromise. The (rhetorical) question is, what is most important? .. The only choices we actually have

Re: [gentoo-dev] CI services for Gentoo Social Contract meanings of dependant notifications on depgraph breakages

2015-04-15 Thread Peter Stuge
Robin H. Johnson wrote: Why should we not be able to benefit from really good closed-source CI tools that are offered for free to the open-source community? Because it may not be in line with Gentoo politics. Jenkins, Buildbot and others are existing libre options in this ecosystem, but

  1   2   3   4   5   >