Re: [gentoo-dev] FEATURES=splitdebug and debugedit
2017-10-13 4:05 GMT+02:00 M. J. Everitt :
> On 12/10/17 22:24, Francesco Riosa wrote:
> > hi,
> >
> > FEATURES=splitdebug at the moment require package dev-util/debugedit
> > which is a lagging behind upstream.
> > However package app-arch/rpm (from which debugedit is forked) always
> > install the same binary in ${ROOT}/usr/libexec/rpm/debugedit.
> >
> > In 2017 I don't see much value in maintaining a fork from a package
> > (rpm) that weight less than 3MB when the functionality we need is
> > already all upstreamed. But if there is someone willing to keep it up to
> > date, that's totally fine.
> >
> > Provided we^W you keep dev-util/debugedit indefinitely it's possible to
> > provide more useful choices to the users with at least two courses of
> > action:
> >
> > 1) instruct ${package_manager} to search for `debugedit` first in
> > ${PATH} _and_ then in /usr/libexec/rpm/debugedit.
> > This way dev-util/debugedit take precedence, if it's not installed and
> > app-arch/rpm is, then the latter will be used.
> >
> > 2) optionally (via useflag) create a symlink in /usr/bin to the libexec
> > debugedit when installing rpm. Obviously the two package must block each
> > other.
> > the rpm package implementing this solution (revbumped to latest) is
> > available here:
> > https://github.com/vivo75/vivovl/blob/master/app-arch/
> rpm/rpm-4.14.0.ebuild
> >
> > thanks for reading and please share your thoughts
> >
> > -- Francesco (vivo) Riosa
> >
> Sounds to me like a potential case of a 'virtual/debugedit' package,
> depending on one of rpm or debugedit to be installed, perhaps?
>
> MJE
>
It would be, but debugedit has no dependency in tree, so it's all
manageable from the messages portage send to the user.
[gentoo-dev] Re: RFC v2: news item for the 17.0 profiles
Andreas K. Huettel posted on Fri, 13 Oct 2017 00:51:23 +0200 as excerpted: > Am Mittwoch, 11. Oktober 2017, 06:24:44 CEST schrieb Alec Warner: >> >> "Please upgrade away from the 13.0 profiles in the next six weeks." >> >> > Good idea. Here's what I wrote: > > Please upgrade away from the 13.0 profiles within the six weeks after > GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles > will be deprecated then and removed in half a year. Looks good. =:^) > [I'd very much like to remove them faster, but am not sure about upgrade > paths and recommended deprecation times. It may become necessary to mask > more and more packages in the 13.0 tree over the half year since devs > will start to depend on c++11 only libraries...] Ouch. Good reason to ensure the upgrade is done, and a total of 7.5 months from the last arch upgrade does seem reasonable. Tho gentoo has historically tried to ensure at least a year's upgrade path, for those who have a year's military or volunteer service, during which they're away from their gentoo machines, for instance. Personally, I have occasionally upgraded (secondary, off-net) machines after even longer (to 2.5 years, IIRC), but that has been while keeping my main machine current, so I had a memory of how to fix breakage and the configuration of the updated machine to reference while bringing the secondary machine current, a few packages at a time. And my own position, based on that experience, is that if you've not been doing /any/ gentooing for anything close to a year, it's very likely that simply starting over with a new stage3, probably in a chroot so you can use the existing install until the new install is up and running, is going to be easier. So 7.5 months does seem reasonable, to me at least. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] FEATURES=splitdebug and debugedit
On 12/10/17 22:24, Francesco Riosa wrote:
> hi,
>
> FEATURES=splitdebug at the moment require package dev-util/debugedit
> which is a lagging behind upstream.
> However package app-arch/rpm (from which debugedit is forked) always
> install the same binary in ${ROOT}/usr/libexec/rpm/debugedit.
>
> In 2017 I don't see much value in maintaining a fork from a package
> (rpm) that weight less than 3MB when the functionality we need is
> already all upstreamed. But if there is someone willing to keep it up to
> date, that's totally fine.
>
> Provided we^W you keep dev-util/debugedit indefinitely it's possible to
> provide more useful choices to the users with at least two courses of
> action:
>
> 1) instruct ${package_manager} to search for `debugedit` first in
> ${PATH} _and_ then in /usr/libexec/rpm/debugedit.
> This way dev-util/debugedit take precedence, if it's not installed and
> app-arch/rpm is, then the latter will be used.
>
> 2) optionally (via useflag) create a symlink in /usr/bin to the libexec
> debugedit when installing rpm. Obviously the two package must block each
> other.
> the rpm package implementing this solution (revbumped to latest) is
> available here:
> https://github.com/vivo75/vivovl/blob/master/app-arch/rpm/rpm-4.14.0.ebuild
>
> thanks for reading and please share your thoughts
>
> -- Francesco (vivo) Riosa
>
Sounds to me like a potential case of a 'virtual/debugedit' package,
depending on one of rpm or debugedit to be installed, perhaps?
MJE
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC v2: news item for the 17.0 profiles
Am Mittwoch, 11. Oktober 2017, 18:45:37 CEST schrieb Robin H. Johnson: > On Wed, Oct 11, 2017 at 08:10:02AM -0400, Aaron W. Swenson wrote: > > Some of these can take a while. Maybe we want to spell it out: > > > > for p in sys-devel/gcc:6.4.0 sys-devel/binutils sys-libs/glibc; do > > emerge -1 $p || break > > done > > Is gcc-config/binutils-config needed in this sequence as well? I don't think so. Magnus? -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC v2: news item for the 17.0 profiles
Am Mittwoch, 11. Oktober 2017, 06:41:06 CEST schrieb Walter Dnes: > > 1) Will 6.3.0 be skipped for stabilization? Yes. (Actually I'd prefer to drop it yesterday, but didn't manage to wake up enough toolchain team members for that.) > > 2) If someone decides to override and set "-pie" in USE, will their > current systems continue to function? Yes. (Though technically if you override masked/forced flags you lose your warranty. :) Depending on your system the fallout from 1) switching pie on and 2) *not* rebuilding *world* *may* be rather small. You'll get some spurious link errors, especially when static libraries are involved, and may have to manually rebuild dependencies. If you're willing to deal with that (and promise not to file bugs) ... > On a new install I'll go with > the default, but "emerge -e" takes a long time on my current machine. > It's an ancient 2008 CORE2 with 3 gigs of ram, but it works fine for > me, including Youtube 1080P streaming. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC v2: news item for the 17.0 profiles
Am Mittwoch, 11. Oktober 2017, 06:24:44 CEST schrieb Alec Warner: > > "Please upgrade away from the 13.0 profiles in the next six weeks." > Good idea. Here's what I wrote: Please upgrade away from the 13.0 profiles within the six weeks after GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles will be deprecated then and removed in half a year. [I'd very much like to remove them faster, but am not sure about upgrade paths and recommended deprecation times. It may become necessary to mask more and more packages in the 13.0 tree over the half year since devs will start to depend on c++11 only libraries...] -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] FEATURES=splitdebug and debugedit
hi,
FEATURES=splitdebug at the moment require package dev-util/debugedit
which is a lagging behind upstream.
However package app-arch/rpm (from which debugedit is forked) always
install the same binary in ${ROOT}/usr/libexec/rpm/debugedit.
In 2017 I don't see much value in maintaining a fork from a package
(rpm) that weight less than 3MB when the functionality we need is
already all upstreamed. But if there is someone willing to keep it up to
date, that's totally fine.
Provided we^W you keep dev-util/debugedit indefinitely it's possible to
provide more useful choices to the users with at least two courses of
action:
1) instruct ${package_manager} to search for `debugedit` first in
${PATH} _and_ then in /usr/libexec/rpm/debugedit.
This way dev-util/debugedit take precedence, if it's not installed and
app-arch/rpm is, then the latter will be used.
2) optionally (via useflag) create a symlink in /usr/bin to the libexec
debugedit when installing rpm. Obviously the two package must block each
other.
the rpm package implementing this solution (revbumped to latest) is
available here:
https://github.com/vivo75/vivovl/blob/master/app-arch/rpm/rpm-4.14.0.ebuild
thanks for reading and please share your thoughts
-- Francesco (vivo) Riosa
0xB39B85C4.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: openrc 0.33 "service" binary removal
All, if there are no objections to this, I would like to publish the newsitem tomorrow and release OpenRC 0.33 at the same time. If I do not see any responses by 24 hours from now I will do so. Thanks, William signature.asc Description: Digital signature
[gentoo-dev] newsitem: openrc 0.33 "service" binary removal
All, OpenRC 0.33 will remove the "service" binary, which is currently a copy of the "rc-service" binary. The reason for this is that "service" will be provided by sys-apps/init-system-helpers. Here is the news item: Thanks, William Title: OpenRC "service" binary removal Author: William Hubbs Display-If-Installed: <=sys-apps/openrc-0.33 Content-Type: text/plain Posted: 2017-10-15 Revision: 1 News-Item-Format: 1.0 OpenRC 0.33 will remove the "service" binary, which was just a copy of the "rc-service" binary. If you only use rc-service this will not affect you. However, if you still need the "service" command, you should install sys-apps/init-system-helpers. signature.asc Description: Digital signature
Re: [gentoo-dev] Checking if a package respects LDFLAGS
On Sun, 01 Oct 2017 09:02:19 +0200 Michał Górny wrote: > W dniu sob, 30.09.2017 o godzinie 21∶49 +, użytkownik Robin H. > Johnson napisał: > > On Sat, Sep 30, 2017 at 08:05:50PM +0200, Andreas K. Huettel wrote: > > > Am Samstag, 30. September 2017, 19:03:59 CEST schrieb Keri Harris: > > > > Hi, > > > > > > > > Is there a recommended method for testing if a package respects LDFLAGS? > > > > > > > > Arch testers are encouraged to add -Wl,--hash-style=gnu to LDFLAGS > > > > [1],[2] and portage uses scanelf to check for .hash sections. However it > > > > appears that ld defaults to using a .gnu.hash section: > > > > > > That test used to work, but it's broken now. We need a new one. > > > > How about something similar to Fedora's binary annotations work, or > > injecting a .note.gentoo section into binaries (containing literal > > C/CXX/LDFLAGS would be useful). > > > > Portage team is always happy to accept any patch for this. Tracking bug: https://bugs.gentoo.org/455232 -- Sergei pgpQYqMnpKnpG.pgp Description: Цифровая подпись OpenPGP
[gentoo-dev] Re: pkg_rm_pretend?
Kent Fredric posted on Thu, 12 Oct 2017 05:20:24 +1300 as excerpted: > This is especially annoying as: > > 1. Its very easy to overlook one package in a 400 package depclean > notice. 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, in part to avoid such huge and confusing backlogs when it is run. > Related: > > It would also be nice if pkg_pretend ( or something like it ) happened > *BEFORE* offering the [Y/N] prompt with `emerge -va `, not, as it > currently does, wait until after you press "y" to execute those checks. That has irritated me a few times as well, tho I know /why/ it works that way. As the name suggests, pkg_pretend is /supposed/ to be run at pretend time, thus before the --ask prompt, both as originally designed and as speced by PMS. The problem the portage implementors apparently ran into is that some of the pkg_pretend stuff ends up being a bit expensive to run just to get the initial listing, so the (controversial) decision was made to run it /after/ the go-ahead. If it's going to double the processing time just for a pretend... Which kind of defeats the purpose I think, but... Maybe what we need is a two-stage pretend/ask, a first stage that does the minimum dependency graphing, etc, and a second stage that does the pkg_pretend. Then an --expensive flag could be added to enhance --pretend and --ask, that would run the second stage too, before the prompt for --ask. Maybe --expensive could automatically double backtrack count as well, so people could run with a lower backtrack by default and choose whether to run --expensive or deal with it manually if the lower backtrack didn't propose a satisfactory solution. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: RFC: news item for the 17.0 profiles
Duncan posted on Wed, 11 Oct 2017 03:31:55 + as excerpted: > Andreas K. Huettel posted on Tue, 10 Oct 2017 21:02:32 +0200 as > excerpted: > >> Switching the profile changes the settings for building gcc (it >> switches a use-flag from forced-off to forced-on). A gcc-6 built with >> the 17.0 profiles will produce PIE executables by default, a gcc-6 >> built with the 13.0 profiles will not. >> >> I've added this paragraph: >> # Switching the profile modifies the settings of GCC 6 to generate >> # PIE executables by default; thus, you need to do the rebuilds >> # even if you already used GCC 6 beforehand. > > Thanks. Much clearer now. =:^) > > (And I'll have some rebuilding to do.) Actually it seems not. I had forgotten this from my /etc/portage/profile/package.use.mask (along with the appropriate system- wide USE flag): # 2017.0513 Now that I have gcc-pie enabled, don't want # the new profile package.use.mask. See the # "[PATCH] profiles: update pie use-flag masks for sys-devel/gcc" # thread, OP on Thursday, 11 May 2017 # by Mathias Maier
Re: [gentoo-dev] GLEP 66 [git workflow] for another review round
W dniu śro, 11.10.2017 o godzinie 18∶33 -0400, użytkownik Mike Pagano napisał: > On 10/11/2017 05:19 PM, Michał Górny wrote: > > Hi, > > snip > > > - ``Reported-by: Full Name `` — usually indicates > > full review, > > snip > > Hi, > > Is that was Reported-by usually indicates? I use it as upstream kernel and > even github indicates, and thought this was the more common and documented > use. > Thanks for catching this. It seems that I've accidentally collapsed Reported-by and Reviewed-by while converting. Fixed now. -- Best regards, Michał Górny
