Re: [gentoo-dev] separate /usr without initramfs
On 27/10/19 16:12, Matt Turner wrote: > On Sun, Oct 27, 2019 at 3:06 AM James Le Cuirot wrote: >> On Sun, 27 Oct 2019 05:38:48 -0400 >> Joshua Kinard wrote: >> >>> Why do I not like an initramfs, though? Well, for one, it complicates the >>> kernel compiles (and it makes them bigger, something which is an issue on >>> the old SGI systems at times). Two, it's another layer that I have to >>> maintain. Three, it violates, in my mind, the simplicity of keeping the >>> kernel and userland separated (e.g., kernel does kernel-y things, userland >>> does userland-y things). >> You make it sound like the initramfs has to be built into the kernel >> image. It can be but it usually isn't. I suspect you know that though? >> Admittedly that does depend on support from your bootloader. While GRUB >> and U-Boot have supported this for years, I forget what oddball >> bootloaders your hardware may be using. > Though he's likely not using it, GRUB2 supports all the platforms he > mentioned (x86, amd64, sparc64, [sgi] mips). > FWIW, I do believe I saw LILO mentioned .. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On 27/10/19 00:55, William Hubbs wrote: > On Sun, Oct 27, 2019 at 12:14:59AM +0100, Michael Everitt wrote: >> On 26/10/19 23:35, William Hubbs wrote: >>> On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote: >>>> On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: >>>>> On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: >>>>> >>>>>> On Fri, 25 Oct 2019 15:03:39 -0700 >>>>>> Georgy Yakovlev wrote: >>>>>> >>>>>>> not used anymore >>>>>>> >>>>>>> Closes: https://bugs.gentoo.org/695698 >>>>>>> Signed-off-by: Georgy Yakovlev >>>>>> Its likely this removal will cause the same kinds of problems faced by >>>>>> the recent virtual/pam removal, just its more insidious, as the >>>>>> dependency on the virtual is hidden away inside an eclass. >>>>>> >>>>>> But this still means that anything users have already installed will >>>>>> still depend on this, and without --changed-deps=y, it will break >>>>>> portage's resolution of anything currently installed using this crate. >>>>>> >>>>>> You can work-around this by -r1 bumping everything that used this >>>>>> eclass but this just goes to show why there's policy against >>>>>> eclasses changing the dependencies of their consumers without any >>>>>> consumer involvement. >>>>>> >>>>> In most if not all cases, this is just a build-time dependency. Do we >>>>> really have all these problems for build-time only dependencies? >>>>> >>>> Yes. Because of --with-bdeps. >>> I disagree, build-time dependencies can change in place because they >>> only affect the build. The problem with virtual/pam was that it was a >>> runtime dependency as well. >>> >>> William >> The problem is that portage defaults to --with-bdeps=y, so any emerging of >> packages now triggers anything that has a build-dep change, unless, as >> previously stated, you exclude that case or change the defaults. > Sure, but rebuild changes are exactly what you would want. that's how > software written in go gets rebuilt for example, which is exactly what > you want when go is upgraded. > > I agree that some rebuilds might be unnecessary, but if you don't like > compiling/building software Gentoo isn't for you. > > William > There's a subtle difference between compiling for compiling's sake, and compiling with good reason .. especially for those who don't have copious quantities of free cpu resources at their disposal 24/7/365 ... just sayin' ... And not everyone is using rust, go, java and systemd as their prime movers, even if you are .. *shudders* signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On 26/10/19 23:35, William Hubbs wrote: > On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote: >> On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote: >>> On Sat, Oct 26, 2019, 05:59 Kent Fredric wrote: >>> On Fri, 25 Oct 2019 15:03:39 -0700 Georgy Yakovlev wrote: > not used anymore > > Closes: https://bugs.gentoo.org/695698 > Signed-off-by: Georgy Yakovlev Its likely this removal will cause the same kinds of problems faced by the recent virtual/pam removal, just its more insidious, as the dependency on the virtual is hidden away inside an eclass. But this still means that anything users have already installed will still depend on this, and without --changed-deps=y, it will break portage's resolution of anything currently installed using this crate. You can work-around this by -r1 bumping everything that used this eclass but this just goes to show why there's policy against eclasses changing the dependencies of their consumers without any consumer involvement. >>> In most if not all cases, this is just a build-time dependency. Do we >>> really have all these problems for build-time only dependencies? >>> >> Yes. Because of --with-bdeps. > I disagree, build-time dependencies can change in place because they > only affect the build. The problem with virtual/pam was that it was a > runtime dependency as well. > > William The problem is that portage defaults to --with-bdeps=y, so any emerging of packages now triggers anything that has a build-dep change, unless, as previously stated, you exclude that case or change the defaults. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On 26/10/19 04:59, Kent Fredric wrote: > On Fri, 25 Oct 2019 15:03:39 -0700 > Georgy Yakovlev wrote: > >> not used anymore >> >> Closes: https://bugs.gentoo.org/695698 >> Signed-off-by: Georgy Yakovlev > > Its likely this removal will cause the same kinds of problems faced by > the recent virtual/pam removal, just its more insidious, as the > dependency on the virtual is hidden away inside an eclass. > > But this still means that anything users have already installed will > still depend on this, and without --changed-deps=y, it will break > portage's resolution of anything currently installed using this crate. > > You can work-around this by -r1 bumping everything that used this > eclass but this just goes to show why there's policy against > eclasses changing the dependencies of their consumers without any > consumer involvement. tl;dr - play with fire .. you're gonna get burned .. :] Good luck with the core aim .. there is probably a slow-and-steady approach that will win through .. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Editing RDEPEND without a new revision (again)
On 25/10/19 14:43, Michael Orlitzky wrote: > On 10/24/19 10:03 PM, Michael Everitt wrote: >> Forgive my lack of git-fu, but which commit did this? Can we name & shame >> the author and committer publicly, and in front of QA, so that this kind of >> violation is highlighted to all, and noted for future reference? >> > I left it out on purpose. This isn't a one-person problem, and my anger > isn't only targeted at the last person who was unlucky enough to do it > right before I snapped and wrote the email. > > This comes up on the -dev list several times a year. We've fought about > ecosystems adding dependencies to stable packages via eclass USE flags. > We fight about the revision policy in the devmanual. We've been fighting > about dynamic dependencies in the package manager for 10+ years. The > portage team basically quit once over this. A few years later we fought > about it again and finally turned them off, but the commit got reverted > when users complained that developers were constantly breaking things. > That contributed to a fork of the package manager... > > Point is, it's not a new thing. And it's a huge waste of time for > everyone involved. It's also simple to avoid. Just make a new revision > when you change something. You shouldn't be changing stable ebuilds > *anyway*, but if you're already going to violate that policy, it doesn't > do any more harm to move it to -r1 in the process. > I think the policy on this in the devmanual/etc is a little too vague. My impression is that changes to an ebuild which make a material difference to the files installed, should definitely be rev-bumped, but certain other changes, and bug fixes, don't need this as they result in missing functionality being rectified/restored. Personally, because I have yet to see any revbumps beyond about -r5 I don't think we would have a problem in reality if everyone bumped the revision *regardless* on *any* change, and we dealt with the consequences *that* way. When/If we get to -r99 on a package perhaps we can revisit this topic, and why so many updates are necessary to a "stable release" (!). I sense that the problem boils down to a lack of 'warm bodies' and people making poor decisions or lazy decisions because of a need to move something forward, without properly considering the wider implications of their 'shortcuts'. This isn't a problem likely to be solved soon, however, and becomes a meta-problem of another sort. However, I'm noting a number of quite angry posts arriving on the public lists, because we have Hard Problems that are creating issues for those attempting to contribute. I think that if you find you're reaching this threshold, perhaps its time for you to take a break, get some air, and consider whether you have the resources to fix the underlying problem, or whether you can tolerate the status quo. Nothing is going to change fast, and will likely require a lot of compromises on the way. That said, there is no harm in trying new things, and accepting that some ideas may have to be reversed. But let's not continue to throw too many daggers across the lists, as it doesn't do anybody any favours, beyond venting frustrations. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Editing RDEPEND without a new revision (again)
On 24/10/19 23:04, Michael Orlitzky wrote: > Here we go again. All week I've been trying to update @world. I'm trying > to troubleshoot a portage bug[0], deal with portage taking forever to > fail, and now I've got to deal with the fact that someone was too clever > to follow the PMS and replaced virtual/pam with sys-libs/pam across the > entire tree (and immediately masked the package that we all have > installed) without creating any new revisions. > Forgive my lack of git-fu, but which commit did this? Can we name & shame the author and committer publicly, and in front of QA, so that this kind of violation is highlighted to all, and noted for future reference? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] uid/gid request for www-apps/redmine
On 24/10/19 18:58, Azamat Hackimov wrote: > Hello. > > As per https://github.com/gentoo/gentoo/pull/12807 I need UID/GID for > web-application Redmine. Could I please get those for it? Any available > number will OK. > > -- > From Siberia with Love! Check https://api.gentoo.org/uid-gid.txt .. give it a couple of weeks, if nobody objects, post a confirmation.. voila! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Disable --autounmask auto-unmasking keywords / masks by default
On 10/10/19 03:57, Kent Fredric wrote: > On Wed, 9 Oct 2019 19:45:34 -0700 > Zac Medico wrote: > >> I'd prefer to disable --autounmask by default and include warnings about >> harmful behavior in the documentation. > I think autounmasks behaviour with regards to USE flags is useful, > (heh), its just everything else it does tends to violate stability > assumptions. > > For instance, I can see why automatically escalating "arch" to "~arch" > may be useful in some cases, but its a very dangerous default, > *especially* for perl. Is there any mileage in something as ridiculous as AUTOUNMASK_EXCLUDES ? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: multiple unfetchable packages (games-*, net-print/adobeps, sci-chem/xdsstat-bin, sci-libs/{openfoam,parmgridgen})
It looks like your GPG setup isn't quite working .. your key is attached,
but your messages don't appear to be being signed, if that was your
intention :) just a FYI!
On 28/09/19 21:13, waebbl wrote:
> Version 7 doesn't require parmgridgen. I has dependencies on scoth,
> paraview and cgal, all of which are available in the tree.
>
>
> Am Sa., 28. Sept. 2019 um 21:50 Uhr schrieb Michał Górny
> mailto:mgo...@gentoo.org>>:
>
> On Sat, 2019-09-28 at 20:57 +0200, waebbl wrote:
> > > sci-libs/openfoam
> >
> > sci-libs/openfoam is available at https://github.com/OpenFOAM,
> including
> > old versions for slots 2.{2,3,4}, each in it's own repository. I
> haven't
> > checked whether those ancient version still compile, with the
> sources from
> > github, but I've started working on a bump to current version 7,
> some time
> > ago, after I noticed that parmgridgen isn't building and I didn't
> find any
> > updates for it.
> > I would consider taking responsibility of the package for the new
> versions,
> > once my ebuild is ready and get's accepted into the tree, as it's a
> package
> > which can be supported by freecad, on which I'm actively working
> for almost
> > a year now.
> >
>
> OpenFOAM is not the problem -- parmgridgen is. OpenFOAM apparently
> requires it unconditionally.
>
> --
> Best regards,
> Michał Górny
>
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [PATCH] tmpfiles.eclass: fix @USAGE to not include function name
On 06/09/19 20:09, Kent Fredric wrote: > On Fri, 6 Sep 2019 20:02:05 +0100 > Michael Everitt wrote: > >> so that the original source makes sense when reading it >> without external tools ? Thoughts? > The source still makes sense without external tools. > > You just need to understand the syntax :p > > - @FUNCTION @USAGE > > And @FUNCTION is *right there* ;) psh .. my organic parser is deficient, clearly .. :P signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] tmpfiles.eclass: fix @USAGE to not include function name
On 06/09/19 20:00, Georgy Yakovlev wrote: > On Friday, September 6, 2019 11:52:53 AM PDT Michael Everitt wrote: >> On 06/09/19 18:27, Ben Kohler wrote: >> >> This series seems super counter-intuitive to me .. surely all usage >> examples (in Linux/etc in general) utilise the command itself to provide >> context of how to invoke the function/etc ?? or am I [once again] mistaken? >> >> Perhaps the series should be to *add* the function across the tree, rather >> than remove it? > Command itself is already added by magic awk, Ben just removing duplicates. > > for example, desktop eclass man page right now > > make_desktop_entry make_desktop_entry(, [name], [icon], [type]... > > after the change > > make_desktop_entry (, [name], [icon], [type], [fields]) > > > > check app-doc/eclass-manpages awk magic file how the pages are generated. Thanks for that, Georgy! Perhaps I should re-word the request to remove the awk magic from the eclass-manpages, so that the original source makes sense when reading it without external tools ? Thoughts?! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] tmpfiles.eclass: fix @USAGE to not include function name
On 06/09/19 18:27, Ben Kohler wrote:
> Signed-off-by: Ben Kohler
> ---
> eclass/tmpfiles.eclass | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/tmpfiles.eclass b/eclass/tmpfiles.eclass
> index 68478ffbcd6..360c5e3b816 100644
> --- a/eclass/tmpfiles.eclass
> +++ b/eclass/tmpfiles.eclass
> @@ -63,7 +63,7 @@ esac
> RDEPEND="virtual/tmpfiles"
>
> # @FUNCTION: dotmpfiles
> -# @USAGE: dotmpfiles ...
> +# @USAGE: ...
> # @DESCRIPTION:
> # Install one or more tmpfiles.d files into /usr/lib/tmpfiles.d.
> dotmpfiles() {
> @@ -84,7 +84,7 @@ dotmpfiles() {
> }
>
> # @FUNCTION: newtmpfiles
> -# @USAGE: newtmpfiles .conf
> +# @USAGE: .conf
> # @DESCRIPTION:
> # Install a tmpfiles.d file in /usr/lib/tmpfiles.d under a new name.
> newtmpfiles() {
> @@ -102,7 +102,7 @@ newtmpfiles() {
> }
>
> # @FUNCTION: tmpfiles_process
> -# @USAGE: tmpfiles_process ...
> +# @USAGE: ...
> # @DESCRIPTION:
> # Call a tmpfiles.d implementation to create new volatile and temporary
> # files and directories.
This series seems super counter-intuitive to me .. surely all usage
examples (in Linux/etc in general) utilise the command itself to provide
context of how to invoke the function/etc ?? or am I [once again] mistaken?
Perhaps the series should be to *add* the function across the tree, rather
than remove it?
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On 05/09/19 20:47, Michał Górny wrote: > On Thu, 2019-09-05 at 15:14 +0200, Thomas Deutschmann wrote: >> On 2019-09-05 06:02, Michał Górny wrote: In my case I am working on a new mysql eclass to outsource pkg_config function which is shared at least between dev-db/mysql and dev-db/percona-server (and maybe dev-db/mariadb). For this new eclass I would say it's a "per-package" eclass and would probably have skipped mailing list review, too. >>> Everyone can skip as many paragraphs as they want, and then apply what's >>> said later to something said way earlier. >> Could you please stop adding any bad interpretation? >> >> That was a serious question. For you, it's pretty clear. I am showing >> you, that for me, it isn't pretty clear. When you believe I skipped >> important lines in my quote please outline what I have missed and I will >> take the blame. >> >> If you want to make it clear, change "should" to "must" and maybe clarify per-package exception and limit to update case if you believe that really *all* *new* eclasses must be send to mailing list. >>> Submit a part. This is a community effort. Nitpicking and complaining >>> doesn't make things better. Fixing them does. >> Sure, but at the moment *you* are the one who are saying it's a MUST. I >> don't understand it that way and I am fine with my understanding that >> per-package eclasses *should* but *must not* get reviewed through >> mailing list. In other words I am asking you to show us where it's >> written that *all* *new* eclasses *must* get reviewed through mailing >> list. I cannot find something like that in current devmanual (the link >> you showed). >> >> Maybe I am still missing something after reading >> https://devmanual.gentoo.org/eclass-writing/ 3 times... >> >> In case I am not missing anything I suggested to improve devmanual in >> case you believe this should be a hard requirement. Because at the >> moment I don't believe it should be a hard requirement, *I* will not >> propose any changes. >> > So to summarize, instead of working together in order to follow a well- > established policy, you prefer to do whatever you find convenient > at the moment, as long as you justify it by finding some document whose > wording does not perfectly prevent you from bending the policy? Yes, > that sounds like a very good attitude for a Council member. > Pot meet Kettle .. signature.asc Description: OpenPGP digital signature
