Re: [gentoo-dev] open season on other-dev's packages -- policy change?

Tom Wijsman wrote: > For really severe bugs I think that pinging just anyone who is around > will do, alternatively you could ping the proxy maintainers herd. In > both cases there is most of the time someone available; so, it would be > a matter of minutes to have the patch applied. You're changi

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

Peter Stuge wrote: > It matters a whole lot if I have to wait for someone else to > unblock me, in practice that completely demotivates me to > contribute back, and I would simply work around the block. To clarify this point; contributing fixes back must always be the least effort of al

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

Alon Bar-Lev wrote: > >> It matters a whole lot if I have to wait for someone else to > >> unblock me, in practice that completely demotivates me to > >> contribute back, and I would simply work around the block. > > > > To clarify this point; contributing fixes back must always be the > > least ef

Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

Duncan wrote: > I believe the reason it wasn't done is because the default options > setting was added instead. Well that and the fact that (as covered > below), I guess most users setup their own scripts/aliases at some point, > at which point the existence of something that general-purpose de

Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

Alexis Ballier wrote: > its kind of common sense IMHO Unfortunately what makes sense to people is never common. :\ > there shouldn't be any time limit .. > in short: if a package requires version X then the ebuild should > require version X; it can be forgotten but it's a bug. +1 //Peter

Re: [gentoo-dev] removing vulnerable versions of dev-lang/v8

Diego Elio Pettenò wrote: > > Problem #1 is that sci-geosciences/osgearth-2.4 depends on > > =dev-lang/v8-3.18.5.14 (see > > for context). It > > doesn't work with more recent v8, but it can be made to not depend on v8. > > If "made not to depend" m

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

Michał Górny wrote: > Did you ever do any serious package work, or are just discussing theory? Michał, you're talking with a user. Please behave. Make a concerted effort to put yourself in his situation. Talking down to him ("did you ever do any serious work") is not helpful for your image, for t

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

Rich Freeman wrote: > >> Users who take advantage of new features in these kinds of states > >> are going to run into problems. That's just the cost of being on > >> the cutting edge. > > > > Why should a feature be allowed to cause problems? To me that just > > means that the feature isn't finish

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

Matt Turner wrote: > I think in large part recently it's because of use.stable.mask and > package.use.stable.mask. These really are a nightmare for users. .. > I think most of the confusion is caused by the necessity to put a > *stable* package atom into package.keywords to unmask a *USE* flag. A

Re: [gentoo-dev] Re: keep a gen 2013 snapshot on mirrors

Duncan wrote: > 3a) Accompany binaries/object code with complete source-code. .. > What that means is this: Every time and place gentoo distributes > binaries, we must make available sources as well. "accompany" !== "make available" > If we're giving away install-CDs at a conference, we better

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

Tom Wijsman wrote: > !!! Enabling --newuse and --update might solve this conflict. > !!! If not, it might help emerge to give a more specific suggestion. > > That together with ABI_X86="(64) (-32*) (-x32)" from the package line > makes it clear that it is trying to change that USE flag. I disagre

Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask

Martin Vaeth wrote: > Probably a lot of the confusion could be avoided if > /etc/portage/package.accept_keywords would not implicitly > unmask useflags. I think so too. Anything that happens implicitly where explicit knobs exist is really counter-intuitive. //Peter

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

Tom Wijsman wrote: > Does replacing this "explicit behavior" by "implicit behavior" make > sense for the users in general? Please don't warp the words. Maybe I misunderstand, but it seems like that's what you're doing. I'll try to clarify: With explicit I was refering to allowing manual setting

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

Tom Wijsman wrote: > I'm not sure if making broken (or experimental) things more easily > available or a suggestion would be a good idea; people already have > enough trouble as it is, adding more doesn't seem to be the right way. It's not about broken/experimental, it's about the logical conseque

Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

Tom Wijsman wrote: > > portage should say, with as similar wording as possible: > > > > "If you want to emerge libXt with those USE flags then you'll also > > have to set those same USE flags for libYt and libZt because libXt > > DEPENDs on them." > > > > Bonus points: > > > > "Would you like me

Re: [gentoo-dev] About preferred ntp provider

Pacho Ramos wrote: > El lun, 11-11-2013 a las 22:13 +0100, Pacho Ramos escribió: > > Reading: > > https://bugs.gentoo.org/show_bug.cgi?id=489044 > > https://bugs.gentoo.org/show_bug.cgi?id=489040 > > > > I don't know what should be preferred > > Any thoughts? :/ I like OpenNTPD. //Peter

Re: [gentoo-dev] logging in openntpd 20080406-r3+

Paul B. Henson wrote: > In openntpd ebuilds starting with version 20080406-r3, logging was changed > from using the default standard syslog to running the daemon in debug mode, > logging to stderr, and having start_stop_daemon background the process > itself and redirect the output to a log file.

Re: [gentoo-dev] logging in openntpd 20080406-r3+

Dirkjan Ochtman wrote: > for my use case, it is not all that important that the time error is > minimized before resuming the boot process, but I really wanted to > minimize boot delays. Most servers really do need accurate time. But your servers, your call. NTP always takes a long time to adjust

Re: [gentoo-dev] logging in openntpd 20080406-r3+

Paul B. Henson wrote: > If openrc has issues managing services that don't drop pid files, maybe > that should be looked into, or maybe openntpd could be patched to drop > a pid file. Conditionally patching openntpd in the ebuild if a system is using openrc is certainly the way to go. > But runni

Re: [gentoo-dev] logging in openntpd 20080406-r3+

Diego Elio Pettenò wrote: > > Conditionally patching openntpd in the ebuild if a system is using > > openrc is certainly the way to go. > > You mean unconditionally here, right? No. > Because pid files should be there, full stop. With openrc sure but neither want nor need them with service sup

Re: [gentoo-dev] logging in openntpd 20080406-r3+

Peter Stuge wrote: > Diego Elio Pettenò wrote: > > > Conditionally patching openntpd in the ebuild if a system is using > > > openrc is certainly the way to go. > > > > You mean unconditionally here, right? > > No. Or maybe yes. :) The condition I refere

Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up

Rich Freeman wrote: > Now that Gentoo apparently offers a wide selection of network > managers, perhaps it makes sense to have the user pick which > one they want to use. +1 Rick Zero_Chaos Farina wrote: > Choice is fine, I love choice, but to have a user unpack a stage tarball > and find no way

Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up

Rich Freeman wrote: > I can see the argument in making the installation of a network manager > part of the handbook. We already have a whole page on how to set up > the network for the install CD itself assuming dhcp doesn't just work. I think the handbook should at a minimum have a recipe for re

Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?

Pacho Ramos wrote: > Last time I checked, vixie-cron upstream was died while cronie > forked it fixing some bugs :/ > > What do you think? I think that nobody who is not intimately familiar with the development in both projects can think anything that is actionable. It's insulting to see how peo

Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?

Markos Chandras wrote: > > Last time I checked, vixie-cron upstream was died > > If vixie-cron upstream is dead as you say Define dead? //Peter

Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?

Sergey Popov wrote: > >>> Last time I checked, vixie-cron upstream was died > >> > >> If vixie-cron upstream is dead as you say > > > > Define dead? > > Bugs are not fixed for a very long time, no answers on private > e-mails or in maillists. Define very long time? //Peter pgpf3lhVFAsOu.pgp

Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?

Markos Chandras wrote: > Please do not let Peter render another thread useless. Isn't it obvious that the discussion about forks is both related to cron *and* useful on its own? It's not really possible to view an entire thread as a single item. Life is more complicated than that, for good and ba

Re: [gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

Robin H. Johnson wrote: > Comments: > - > In bug #4411, comment 43, vapier noted: > > any package that does dlopen("libfoo.so") without the version info like > > ".so.X" is broken. > In this case, the lt_dlopenext consumer is explicitly testing multiple > versions of libusb at runtime, and

Re: [gentoo-dev] Question, Portage QOS

Igor wrote: > Let's agree on following - I'll design the system in details on paper. > When it's ready (~ 1.5 months) I'll get back here and share the details. You might be surprised how little people care about good design. They choose kindof-working implementation every time. //Peter

Re: [gentoo-dev] RFC: storing predefined INSTALL_MASK directory lists in repos

Michał Górny wrote: > INSTALL_MASK="systemd bash-completion" > > What are your thoughts? It seems like this will generally duplicate all -USE flags. Would it make sense to instead have a single setting which changes the meaning of USE to be that everything not USEd is install-masked? Rather t

Re: [gentoo-dev] Re: RFC: storing predefined INSTALL_MASK directory lists in repos

Duncan wrote: > >> INSTALL_MASK="systemd bash-completion" > >> > >> What are your thoughts? > > > > It seems like this will generally duplicate all -USE flags. > > > > Would it make sense to instead have a single setting which changes the > > meaning of USE to be that everything not USEd is in

Re: [gentoo-dev] Portage team, Zac's development break and stepping down as lead

Tom Wijsman wrote: > So, yes, we need more people on pkgcore; no, we can't just leave > Portage behind, as it still is the beating heart of Gentoo for now. I guess the point is that it might continue beating long enough mostly on its own. //Peter pgp_E4oOCUrAm.pgp Description: PGP signature

Re: [gentoo-dev] rfc: revisiting our stabilization policy

Sergey Popov wrote: > As i said earlier, problem begins when we NEED to stabilize > something to prevent breakages and arch teams are slow. Isn't that simply a matter of assigning and respecting priority on bugs properly? //Peter pgpNUTerDIRPI.pgp Description: PGP signature

Re: [gentoo-dev] rfc: revisiting our stabilization policy

Rich Freeman wrote: > >> As i said earlier, problem begins when we NEED to stabilize > >> something to prevent breakages and arch teams are slow. > > > > Isn't that simply a matter of assigning and respecting priority on > > bugs properly? > > Are you suggesting that we should forbid people from w

Re: [gentoo-dev] rfc: revisiting our stabilization policy

Alan McKinnon wrote: > "Respecting bug priority" feels like that corporate BS I have to put up > with every day. Gentoo is incorporated so maybe that fits. ;) On a more serious note, please try to understand what I meant rather than just what I wrote. I wrote both "assigning" and "respecting"; y

Re: [gentoo-dev] rfc: revisiting our stabilization policy

Rich Freeman wrote: > I get what you're saying, though there is still a cost to leaving the > bug open to years. In this case it means an old package stays in the > tree marked as stable. That either costs maintainers the effort to > keep it work, or they don't bother to keep in working in which

Re: [gentoo-dev] rfc: revisiting our stabilization policy

Alan McKinnon wrote: > > I wrote both "assigning" and "respecting" > > I reckon the cardinal rule is "avoid as much as possible having priority > set by someone who is not solving the problem". I think that comes close > in my words to what you are saying. Yes that's exactly what I mean. Thanks f

Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas

Michał Górny wrote: > What do you think? Excellent. I think it could quickly become the prefered protage storage format, although a loopback mount is needed. //Peter pgpZaqbTCHide.pgp Description: PGP signature

Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas

Michał Górny wrote: > > > What do you think? > > > > Excellent. I think it could quickly become the prefered protage > > storage format, although a loopback mount is needed. > > You can use sys-fs/squashfuse :). > > Though honestly I'd prefer if portage was able to take squashfs image > path in

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

Tom Wijsman wrote: > > Anyone who cares about quality will be frustrated by others who do not. > > We have policies to enforce quality, thus frustration is optional. :) Policies don't enforce quality, people enforce quality. And doing that is quickly frustrating. If enforcing quality would be a

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

Tom Wijsman wrote: > Of course one could see QA as defending the Portage tree with our heart; > but not that literally, at least not up to the point that one gets > painfully hurt or even just frustrated... Anyone who cares about quality will be frustrated by others who do not. //Peter pgp8g2z

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

Tom Wijsman wrote: > you shoot down solutions Maybe it wasn't a very good solution that deserved to be shot down. //Peter pgpWdBSgiDfHp.pgp Description: PGP signature

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

Duncan wrote: > My point being... yes indeed, there's a LOT of folks for whom gentoo > without a stable tree would be a gentoo freed of a to-them useless > weight, allowing gentoo to move even faster, and be even better in areas > that are already its strength, heavily automated leading edge rel

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

Rich Freeman wrote: > It seems like the simplest solution in these cases is to just have > them focus on @system packages for the stable tree, and let users > deal with more breakage outside of that set Why not make stable completely optional for arch teams? //Peter

Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy

Rich Freeman wrote: > > Why not make stable completely optional for arch teams? > > Stable already is completely optional for the arch teams, and that is > why we have concerns over stable requests taking forever on minor > archs in the first place. If the package wasn't marked as stable in > the

Re: [gentoo-dev] Dealing with XDG directories in ebuild environment

Mike Gilbert wrote: > It would really nice to have a solution for the few users who do > have this set that does not involve adding code to random eclasses, > or leaving things broken for X months/years until all ebuilds can > be bumped to EAPI 6. Is there any other solution for users than fixing

Re: [gentoo-dev] Catalyst news item

Jorge Manuel B. S. Vicetto wrote: > +After many years of stalled development I'm quite allergic to statements like this. Remember that you may not really be representing everyone when you express your own opinion - even if it is shared by many. "many years of stalled development" can only be tru

Re: [gentoo-dev] January 2014 QA Policy Updates

Chris Reffett wrote: > - -The QA team policymaking workflow will look like the following: .. > If we think a developer's actions are causing problems, we may ask > them to stop/undo pending discussion by the QA team at the next meeting. plus > - -Rules for the QA team editing peoples' packages: .

Re: [gentoo-dev] January 2014 QA Policy Updates

Alec Warner wrote: > > hmm? > > To be fair, I had a long discussion with this regarding when QA has the > authority to temporarily ban a developer. Cool. > In the case where policy is missing, QA does not have a clear case > of authority there. It becomes a more murky area. I've tried to > very

Re: [gentoo-dev] Re: Re: dropping redundant stable keywords

I'm firmly with Steev and Matt in this thread as well as in at least a few others where Tom has participated intensely. Tom Wijsman wrote: > > Thanks for putting up with it, but it's a huge waste of your time. > > Why? Because you seem to have a completely different mindset than everybody else,

Re: [gentoo-dev] [OT] Re: dropping redundant stable keywords

Please stop writing so many and so long emails. Tom Wijsman wrote: > Fwiw, the very same person I made that single one-word "Why?" to > has previously appreciated that I asked him. You can not extrapolate from that, and can certainly not assume that I will appreciate that you ask "Why?" in respon

Re: [gentoo-dev] New global USE flag called "qrcode" for QR code support

Samuli Suominen wrote: > New global USE flag 'qrcode' for the http://en.wikipedia.org/wiki/QR_code > (sorry, page didn't load for me so I hope it's okay) > I propose 'Enable support for 2D QR Codes' ? .. > And app-office/glabels has USE="barcode" but it also pulls in > app-text/barcode, so likely i

Re: [gentoo-dev] [OT] Re: dropping redundant stable keywords

Tom Wijsman wrote: > > > Fwiw, the very same person I made that single one-word "Why?" to > > > has previously appreciated that I asked him. > > > > You can not extrapolate from that, and can certainly not assume that > > I will appreciate that you ask "Why?" in response to something I > > express

Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

Tom Wijsman wrote: > I'd say that if around 7 people vote on the matter that that is > based on a necessary amount of understanding. That is just incredibly naïve. In another project five people reviewed an experimental change written by me that someone else proposed for inclusion into the projec

Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

Tom Wijsman wrote: > > > I'd say that if around 7 people vote on the matter that that is > > > based on a necessary amount of understanding. > > > > That is just incredibly naïve. .. > > You need to learn to respect what you don't know that you don't know. > > Or you apply knowledge codification

Re: [gentoo-dev] Re: RFD: new global USE flag gtk3

Tom Wijsman wrote: > > > > You need to learn to respect what you don't know that you don't > > > > know. > > > > > > Or you apply knowledge codification and mark it as experimental. > > > > No, that's what you *know* that you don't know. > > Exactly, which effectively keeps us away from unknown

Re: [gentoo-dev] RFC: git-r3, additional clone types

Michał Górny wrote: > Mirror clone > Single branch clone Look fine. > Shallow clone > - > - EGIT_COMMIT can only name tags (using a hash auto-forces higher mode), Hm, why is that? This seems like an unfortunate and inconvenient limitation which might actually reduce usefulness of sh

Re: [gentoo-dev] RFC: git-r3, additional clone types

Michał Górny wrote: > > > Shallow clone > > > - > > > - EGIT_COMMIT can only name tags (using a hash auto-forces higher mode), > > Limitation of git design. You can only fetch remote refs, you can't > fetch an arbitrary hash. Ok. Boo git. > > If it's the same local repo then at leas

Re: [gentoo-dev] News item draft for >=sys-fs/udev-209 upgrade

Lars Wendler wrote: > >> - try to prevent most naming pollution of pure udev with systemd > >> crap. > > > >childish. me don't like pink ponies. pink too much. pony okay. > > Riiight... as udev has anything else to do with systemd other than > being uselessly integrated into systemd whereas it can

Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)

Joshua Kinard wrote: > Most future Linux systems that are based off of mainstream > distributions will *have* to use systemd+udev in order to > achieve maximum functionality. Certainly! And I think the reason systemd gains traction is that such maximum functionality can easily include various thi

Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)

Everyone on this list really except perhaps Duncan really needs to learn to trim quotess. Kthx. Gilles Dartiguelongue wrote: > Sure at some point you have to make things evolve but this upstream > solution simply isn't nice for its users. That may be, but I don't think it's a distribution's respo

Re: [gentoo-dev] Make udev optional in net-wireless/bluez?

Gilles Dartiguelongue wrote: > Making udev dependency always on is a deliberate choice here I thought Gentoo was about users having choice? Sad face. > we simply don't want users to get confused That's not helpful, when the premise is to deliver choice. I hope someone does apply the patch.

Re: [gentoo-dev] Make udev optional in net-wireless/bluez?

Joshua Kinard wrote: > I guess this is more of a question to be asked to the bluez developers > why they even allow the bluez configure script to make udev optional. Isn't the maintainer supposed to already know? //Peter

Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

Mike Gilbert wrote: > On Mon, May 12, 2014 at 12:46 PM, Ciaran McCreesh > wrote: > > Why, though? > > We should probably emit an error message advising the user to enable > the kernel option or disable the network-sandbox feature. This should > happen when we call unshare() and that fails with e

Re: [gentoo-dev] Re: Banning modification of pkg-config files

Rich Freeman wrote: > > Longterm, this makes it year after year more difficult to develop > > software for "Linux". > > I'm with you here, but what is the solution? > > If we say we stick to upstream then we don't provide pkg-config files > at all (in these cases). I think this is a sane default

Re: [gentoo-dev] Re: Banning modification of pkg-config files

Samuli Suominen wrote: > >> If we say we stick to upstream then we don't provide pkg-config files > >> at all (in these cases). > > > I think this is a sane default. > > Except having pkg-config is the only way to fix some of the build > issues we are seeing today, like getting 'Libs.private: ' f

Re: [gentoo-dev] Re: Banning modification of pkg-config files

Tom Wijsman wrote: > besides a temporary fix downstream it should go upstream; I think there is agreement that this is the ideal, and that the discussion is about what to do when that seems out of reach. > > My key point is that it isn't Gentoo's responsibility or duty to fix > > problems introd

Re: [gentoo-dev] Creating a USE_EXPAND for ssl providers

Anthony G. Basile wrote: > 2. migrate curl and all its dependencies to the SSL use expand. > > 3. Migrate over all consumers of ssl to the new SSL use expand system. As long as consumers can support only a few of the expansions that just seems to tidy things up, which is a good thing. //Peter

Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers

Ian Stakenvicius wrote: > If a user has i.e. SSL="polarssl" in make.conf and emerges things that > don't have polarssl on their list, then those things won't have SSL > support at all, right? Wrong; I would expect emerge to throw an error at me and exit, rather than to fail (build the package with

Re: [gentoo-dev] RFC: news item for upower

Steev Klimaszewski wrote: > Instead of belittling the users because they are wasting so much of > your time Causing a rougher transition than neccessary is a waste of users' time. I don't think that's awesome. //Peter

Re: [gentoo-dev] The state and future of the OpenRC project

Rich Freeman wrote: > likely bikeshedding .. > Or we can just accept that those using overlays will have them > break from time to time. Maybe there's an in-between. It's very reasonable to ask from an overlay maintainer that they run overlint now and then. If overlint can be taught to report when

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

Alexandre Rostovtsev wrote: > current crossdev versions blindly install their > /usr/bin/i686-pc-linux-gnu-pkg-config wrapper script, overwriting > the binary belonging to pkgconfig[abi_x86_32]. Thanks for getting to the point. It seems silly for two toolchains (abi_x86_32 and a crossdev i686 too

Re: [gentoo-dev] package.mask vs ~arch

Rich Freeman wrote: > If we're going to define ~arch as basically stable, and arch as > out-of-date, then we might as well drop keywords entirely. I actually don't think that would be such a bad thing. I only consider ~arch relevant, because it is the closest to upstream. I want the distribution

Re: [gentoo-dev] Making a common sub-profile for no-multilib

Michał Górny wrote: > The arch/ tree starts with 'generic' subdirectories matching main > arches -- like arm, mips, x86, sparc, powerpc, s390 (but not amd64). I like this idea, but.. > Each of arch trees contains an 'abis' subtree that contains mix-ins ..please please call this 'abi' instead.

Re: [gentoo-dev] Making a common sub-profile for no-multilib

Michał Górny wrote: > > abi/x86 can't be both a file and a subdir. > > Profiles are directories... Doh, yes of course. :\ abi rather than abis is still important. :) //Peter pgp7Suon0xtIh.pgp Description: PGP signature

[gentoo-dev] find ${D} -delete in src_install() ?

I came across this in sys-power/pm-utils-1.4.1-r2.ebuild src_install(): # NetworkManager 0.8.2 is handling suspend/resume on it's own with UPower find "${D}" -type f -name 55NetworkManager -exec rm -f '{}' + This seems baroquely reckless, but it has been like that since 2010 with one revbump and

Re: [gentoo-dev] find ${D} -delete in src_install() ?

Samuli Suominen wrote: > > Is it really acceptable for an ebuild to delete all files in $D > > which have a particular name? > > Of course, why wouldn't it be? $D is the image directory of the > package before it's merged to actual filesystem, Ah yes! Of course - no problem! > and even if it we

Re: [gentoo-dev] Re: don't rely on dynamic deps

Ciaran McCreesh wrote: > Uh huh, so you add an overlay, and suddenly the dependencies for a > random subset of your installed packages change in ways that don't in > any way reflect what you have installed. How is this the desired > behaviour? There are several different cases of dependency data w

Re: [gentoo-dev] don't rely on dynamic deps

Ciaran McCreesh wrote: > Rich Freeman wrote: > > What would you do away with? Being able to virtualize packages > > without recompiling everything that depends on them? > > Well that's never worked properly or consistently to begin with Please answer the question? //Peter pgpNaSXskEzkH.pgp

Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined

Manuel Rüger wrote: > virtual/libusb-1-r1 depends on either dev-libs/libusb or > sys-freebsd/freebsd-lib. The latter one is only compatible with > libusb-1.0.9, You should know that it's the other way around. freebsd-lib isn't to blame, but >=dev-libs/libusb-1.0.18 is. //Peter pgpDwzxkEwu11.pg

Re: [gentoo-dev] don't rely on dynamic deps

Ciaran McCreesh wrote: > Peter Stuge wrote: > > Ciaran McCreesh wrote: > > > Rich Freeman wrote: > > > > What would you do away with? Being able to virtualize packages > > > > without recompiling everything that depends on them? > > > > &g

Re: [gentoo-dev] don't rely on dynamic deps

Michał Górny wrote: > Consider the following: > > 1. A depends on B, both are installed, > > 2. dependency on B is removed, emerge --depclean uninstalls B thanks > to dynamic-deps, > > 3. B is treecleaned (nothing depends on it), So far I follow. > 4. old version of A is removed (user doesn't

Re: [gentoo-dev] Re: don't rely on dynamic deps

Martin Vaeth wrote: > The user has to put a corrected ebuild into his overlay and must > reemerge the package (currently, the latter could be skipped with > dynamic deps). > In fact, no matter whether you have static or dynamic deps, this is > the only way to cleanly avoid the problems if you want

Re: [gentoo-dev] Re: don't rely on dynamic deps

Martin Vaeth wrote: > > The user's vardb could then automatically receive the last state of > > the ebuild, before it was removed. > > It doesn't help reliably, either, since the last state of the ebuild, > before it was removed, will be outdated at some point, too. Sorry, I don't see how. Can yo

Re: [gentoo-dev] Re: don't rely on dynamic deps

Martin Vaeth wrote: > >> > The user's vardb could then automatically receive the last state of > >> > the ebuild, before it was removed. > >> > >> It doesn't help reliably, either, since the last state of the ebuild, > >> before it was removed, will be outdated at some point, too. > > > > Sorry, I

Re: [gentoo-dev] Re: don't rely on dynamic deps

Samuli Suominen wrote: > let users do the rebuild (which is the obvious answer > to the output you posted) Reality check time, Samuli. Unless emerge says "Your dependencies are b0rk, please rebuild $P to fix it." that answer is nowhere near obvious. Watch out with the tunnel vision. //Peter

Re: [gentoo-dev] Re: Repoman check and QA policy for slot deps/operator

Duncan wrote: > (Hmm... my client's warning says I'm not verbose enough, too much quoted > text for my reply. /That/ doesn't happen very often! After adding this > note it's the "continue anyway" button. =:^) Here is a friendly reminder for everyone; Please remove more quoted text. Full-quote

Re: [gentoo-dev] minimalistic emerge

Kent Fredric wrote: > dependencies are forward specifications from upstream telling > us what their software needs to function properly. Unfortunately that's not the full story. :\ ebuilds often (for me) have artificial dependencies, when the actual version required is too old to be in the tree,

Re: [gentoo-dev] minimalistic emerge

Rich Freeman wrote: > If upstream happens to say it requires foo-1.5, by all means just > take their word for it and list it, Don't take their documentation's word for it however, but look at what the build actually requires. (E.g. configure.ac.) //Peter

Re: [gentoo-dev] Re: minimalistic emerge

Duncan wrote: > Red Hat is the gold standard, very long term commercial support, > IIRC 10 years, and very good community relations I've heard this on occasion, but reality is actually quite different. Red Hat is a software service provider. They do whatever their paying customers ask for. They d

Re: [gentoo-dev] Early idea: install_qa_check() refactor and 'public API'

Michał Górny wrote: > ( source "${f}" || die "sourcing ${f} failed" ) > > 2b. Unless someone knows a way around this, this means that the check > -- unless 'die'-fatal -- needs to ensure non-zero status of last > comment, likely via some trailing 'true' or ':'. Since we can't > distinguish betwe

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

Jauhien Piatlicki wrote: > Emerging live ebuild usually is quite a risky thing, I don't know. It depends on the culture of the particular repository, and while it is true that many open source repos are utter crap I'm not sure if that is the common case? I like to believe that developers actually

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

Jauhien Piatlicki wrote: > The question is not about crap in the upstream, but about changed > dependencies, behavior, whatever else. That's a good point. > E.g. we in downstream have some patches, when upstream changes > related code (e.g. applying our patches), ebuild fails to build. I conside

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

Michał Górny wrote: > What I need others to do is provide the hosting for git repos. I'm happy to set up repos on my git server with custom hooks and accounts as needed. It's probably not what we want long-term, but it might be useful as proof of concept, so that infra only needs to do setup one

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

Patrick Lauer wrote: > > > That'd mean I need half a dozen checkouts just to emulate cvs, which > > > somehow doesn't make much sense to me ... > > > > Unlike CVS, git doesn't force you to work in "Keep millions of files in > > uncommitted states" mode just to work on a codebase, due to the commit

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

Rich Freeman wrote: > If you just want to do 15 standalone commits before you push you can > do those sequentially easily enough. A branch would be more > appropriate for some kind of mini-project. .. > That is the beauty of git - branches are really cheap. > So are repositories And commits. Not

Re: [gentoo-dev] git security (SHA-1)

Rich Freeman wrote: > If you want to satisfy yourself I believe you can get git to dump > the contents of any object without formatting/etc. git ls-tree HEAD . git show $blobhash git show --pretty=raw HEAD //Peter

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

Diamond wrote: > I stumbled over this problem when started to use git for packages. Use git show -M to unstumble yourself. //Peter

Re: [gentoo-dev] Git copy detection (was: My masterplan for git migration...)

Diamond wrote: > we probably can arrive at a conclusion that git itself isn't good > at all for package management. I don't think we can. Please stop the nonsense, at least until you have created something superior to git. //Peter

Re: [gentoo-dev] Re: git security (SHA-1)

Rich Freeman wrote: > I sill think it makes more sense to start with a threat model and go > from there. I agree. It's a great project to tackle after the migration. For migrating I agree with you that it's fine to do whatever. Really. This year. As in before 2015. There are three more months.

<    1   2   3   4   5   6   >