Re: [gentoo-dev] EAPI 2 must die
On Thu, Jun 6, 2019 at 8:07 AM Andreas K. Huettel wrote: > Hi all, > > for the package maintainers among you, here's the list of remaining EAPI=2 > packages. Please help getting the number down to zero soon!!! > > Cheers, > Andreas > > media-fonts/culmus-0.120-r4 > > Done.
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Wed, Apr 24, 2019 at 5:19 PM Rich Freeman wrote: > Well, in that case recommendations for how to generate a key that > complies in software would be helpful. There used to be a wiki > article on it, but it is marked with various warnings saying it isn't > recommended to follow it, and has seemingly vanished with a note that > it moved somewhere. Please wait for me to receive mine... :) In the meantime, I think that you may find the following commands useful... $ gpg --expert --full-generate-key $ gpg --expert --edit-key ${MASTER_KEY_ID} gpg> addkey Regards, Alon
[gentoo-dev] app-crypt/openssl-tpm-engine mask for removal in 30 days
Upstream is dead. Package does not support openssl-1.1, significant change to package. Removal in 30 days.
Re: [gentoo-dev] Changing policy about -Werror
On Sat, Sep 22, 2018 at 1:33 AM Chí-Thanh Christopher Nguyễn wrote: > > Richard Yao schrieb: > > >> To make code behave differently it needs substantial amount of code > >> to provide you an example. You need to him O2<->O3 behaviour delta > >> after all. But I will try (for a different warning, it should not matter > >> much). > > Thanks. I had been incorrect about -O3 giving not us some additional > > information for warnings. My apologies for the confusion. > >> > >> Below is a reduced example of a larger C++ program. > >> Many thanks to Ulya for providing recent example! > > Not that it matters now, but there are examples of packages building at -O2 > but failing to build at -O3 optimization levels, due to -Werror. > > One is dev-libs/libcss: https://bugs.gentoo.org/626752 > It is matter, and shows that for selected packages in which upstream has strict policy of no warning, each warning should be investigated as it may be a true issue. The tool compiler provide to find these edge condition should not be ignored nor overridden. The fact that a package "builds" does not mean it is free of bugs. Regards, Alon
Re: [gentoo-dev] Changing policy about -Werror
On Sat, Sep 15, 2018 at 1:14 AM Richard Yao wrote: > > On Sep 14, 2018, at 5:28 PM, Fabian Groffen wrote: > > > > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote: > >>> > >>> Perhaps, if one persists on going this route, only do this for platforms > >>> that upstream supports, such that arches which will suffer from this > >>> (typically ppc, sparc, ...) don't have to be blocked by this. > >> > >> Exactly in these cases the -Werror is useful as if upstream expects no > >> warnings then any warning should block installation and trigger bug > >> report. In Gentoo in many cases we use packages on platform has no > >> access to, our feedback to upstream is valuable. A great example is > >> gnutls in which we collectively (maintainer, unstable users, > >> architecture teams, stable users) found issues on architectures that > >> almost nobody other than Gentoo has access to. > >> > > > > I don't believe Gentoo users are (supposed to be) an extension of > > upstreams. If upstreams insist on that, they should make their software > > non-free, adding a non-modification clause or something. In any case, > > it is not Gentoo's job IMHO. In the end it is Gentoo who needs to care > > for its users. I prefer we do that by giving them an option to become > > that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo > > disables by default. > I am in complete agreement on this. Users should not be guinea pigs to help > upstream unless they opt into it. A new release of upstream is out, early adopters (what we call unstable users) are guinea pings. A new release is stabilized, users are guinea pings. A new toolchain that upstream did not test, users are guinea pings. A new dependency version or a Gentoo virtual with "compatible library", users are guinea pings. Let's say upstream does not have access to architecture X we at Gentoo decide to support this architecture, maintainer do not have access to this architecture as well, architecture team is guinea pings, but it does not actually use the package, then back to early adopters and users. This process has nothing to do with -Werror, our process relays on users as guinea pings, by definition developers and arch teams cannot test entire software and all permutation of the software. The -Werror (if supported by upstream and downstream, I outlined the conditions many times) is a tool (among other) to help stop the process at early stage when suspicious finding is there to allow deal with the situation to make sure that the software is compatible with an environment or permutation that upstream and maintainer do not have direct access to. It is a tool to help users to have better system integrity (once again, provided some conditions apply).
Re: [gentoo-dev] Changing policy about -Werror
On Sat, Sep 15, 2018 at 12:29 AM Fabian Groffen wrote: > > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote: > > > > > > Perhaps, if one persists on going this route, only do this for platforms > > > that upstream supports, such that arches which will suffer from this > > > (typically ppc, sparc, ...) don't have to be blocked by this. > > > > Exactly in these cases the -Werror is useful as if upstream expects no > > warnings then any warning should block installation and trigger bug > > report. In Gentoo in many cases we use packages on platform has no > > access to, our feedback to upstream is valuable. A great example is > > gnutls in which we collectively (maintainer, unstable users, > > architecture teams, stable users) found issues on architectures that > > almost nobody other than Gentoo has access to. > > > > I don't believe Gentoo users are (supposed to be) an extension of > upstreams. This is exactly what I think that is special about Gentoo, and the reason I use Gentoo. Unlike other distribution Gentoo is the closest thing of using upstream. A maintainer in Gentoo who is not see himself part of the upstream packages he maintains has far less impact than a maintainer who does see himself as part of upstream or is upstream. Per your statement, we should not allow any architecture or setup that upstream, such as exact versioning, architecture or toolchain. > If upstreams insist on that, they should make their software > non-free, adding a non-modification clause or something. In any case, > it is not Gentoo's job IMHO. Then we cannot re-distribute or patch, how is it related to the discussion? We are talking about open source projects and I know it is cliche... the "greater good" and helping the "free open source movement" a a viable alternative. I thought this is what unite us here. > In the end it is Gentoo who needs to care > for its users. I prefer we do that by giving them an option to become > that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo > disables by default. Do you think someone do not care about the users? Do you actually think upstream does not care about users? I do not understand this statement. If downstream maintainer believes that upstream is friendly for the Gentoo overhead (which is higher than binary distributions) or create the relationship in which Gentoo is 1st citizen at upstream, why do you think users cannot use vanilla upstream? > As maintainer and/or enthusiastic user, like you wrote for gnutls, I > would be more than happy to provide build logs/errors for all the arches > I have access to. So like I wrote before, I think we should consider > case-by-case basis to make it easy to do so. This entire discussion is to allow case-by-case and not black and white approach recently enforced. Regards, Alon
Re: [gentoo-dev] Changing policy about -Werror
On Sat, Sep 15, 2018 at 12:02 AM Fabian Groffen wrote: > > On 14-09-2018 16:29:43 -0400, Rich Freeman wrote: > > On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky wrote: > > > > > > On 09/14/2018 03:58 PM, Richard Yao wrote: > > > >> > > > >> No one has answered the question: what do you do when a stable package > > > >> breaks because of a new warning? > > > >> > > > >> ...> > > > > Wouldn’t this be largely covered as part of GCC stabilization? We could > > > > reserve the right to kill -Werror in a package where it blocks GCC > > > > stabilization if the maintainer does not handle it in a timely manner. > > > >> > > > > > > They would be uncovered during GCC stabilization, but then you're right > > > back in the original situation: how do you fix the stable package? The > > > only answer that doesn't violate some other policy is to patch it in a > > > new revision and wait for it to stabilize again. > > > > > > Other questions arise: Do we block stabilization of clang et al.? > > > > > > > Presumably we could make it a blocker, so then portage won't install > > the new stable toolchain. That buys time and only affects users of > > that particular package. But, as I pointed out before you can do that > > without using -Werror - just block installation with an unqualified > > toolchain. > > > > You would only use an approach like this for packages where QA was > > fairly important, so the inconvenience would be worth it. > > Perhaps, if one persists on going this route, only do this for platforms > that upstream supports, such that arches which will suffer from this > (typically ppc, sparc, ...) don't have to be blocked by this. Exactly in these cases the -Werror is useful as if upstream expects no warnings then any warning should block installation and trigger bug report. In Gentoo in many cases we use packages on platform has no access to, our feedback to upstream is valuable. A great example is gnutls in which we collectively (maintainer, unstable users, architecture teams, stable users) found issues on architectures that almost nobody other than Gentoo has access to.
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 10:53 PM Sergei Trofimovich wrote: > > On Fri, 14 Sep 2018 19:40:13 +0300 > Alon Bar-Lev wrote: > > > > > No dependency of toolchain nor annotations. > > A strict policy of no warnings will require changes as dependencies > > including toolchain are progressing. > > This creates an overhead for selected packages. > > A maintainer and the non-stable team should be able to know the package > > status. > > Preferably this may be done by automation, I appreciate the work of > > Toralf Förster with tinderbox to automate check various cases. > > When a new slot of toolchain is available, maintainers should check > > their packages in any case, there are other issues and side affects > > that we experienced, especially in C++ packages. > > For these packages usually there are 3 for each slot: the current > > stable, the next stable and the non-stable, so the overhead is > > constrained. > > Sorry. I'm afraid I missed your answer. I'll restate the question again: > > If you do it then what is your workflow to fix breakages > appearing in stable packages caused by minor environment > changes like toolchain tweaks? > > I mean mechanically as a package maintainer. > > Since you did not mention it I see a few alternatives: > - revbump a package with a backport of a local fix and fast-track > stabilization without usual soak time in ~arch Fix in place if false positive. Revision bump if positive. > - pull new upstream version and fast-track stabilization without > usual soak time in ~arch No reason to wait for upstream if obvious positive just like any bug fix. > - no revbump, apply the patch as-is and hope it does not break > existing users. Correct. > - anything else? Patching the package (stable and unstable) to remove -Werror if too many of them and downstream maintainer reaches to a conclusion that the overhead is too high and benefit is little and provide this feedback to upstream to work together on a new release of upstream which resolves all warnings with newer toolchain. > > > > Unused variable is a good example of typical benign warning: > > > it was there all the time, it's not a new bug and does not > > > warrant need for an immediate fix. > > > > Unused variable is a good example of CRITICAL potential issue > > I understand you point. I disagree with it. > > My litmus test: if behaviour of the package did not change after > the fix then the issue was not real. But how can you get the report to evaluate if it is real or not? I fail to understand this argument that is repeated over and over. Everyone is smart after the did... while we are looking for the trigger to evaluate. > > > Toolchain just happend to get better at control flow graph > > > analysis. Fix can easily wait for next release and save > > > everyone's time. > > > > Once again, the number of permutation of build and architecture may > > reveal issues that are cannot be detected on maintainer machine. > > If a fix is a real issue that is found in stable package, do you > > suggest to wait for next release to save whose time? > > It's up to maintainer to decide on how to resolve the issue once > maintainer understands the scope of the problem. Correct. My believe is that it is up to maintainer to decide. > > Once again I outlined the cases in which -Werror can be preserved, I > > will repeat... (a) upstream has strict policy of no-warnings, (b) > > upstream added -Werror, (c) downstream opinion is that upstream is > > following the policy, (d) upstream is friendly, (e) downstream accepts > > the potential maintenance overhead. > > Your proposal is clear. Thanks for restating it. > > I still think keeping -Werror enabled by default makes more harm > than good. Yes, but we are not talking about by default, right? > > > Gentoo does not normally run tests on user's systems either. > > > Tests are arguably a lot more precise in pointing out real > > > problems in software. > > > > Correct. I believe that this may be revisit as well, for selected > > packages in which tests are stable run them on user machines. There is > > no reason why we cannot add a directive to ebuild to enable tests by > > default and let user to disable this to save CPU/time of build. > > Additional thanks for considering an option to disable tests back. > Any mechanism that is fully supported by upstream and downstream maintainer find it stable should be enabled by default. I do see the benefit of disabling tests not because they may break as per the same argument I would like to have these reported and investigated, but to save resources (time and CPU) which may be significant. Thanks, Alon
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 8:53 PM Michał Górny wrote: > > On Fri, 2018-09-14 at 20:48 +0300, Alon Bar-Lev wrote: > > On Fri, Sep 14, 2018 at 8:33 PM Michał Górny wrote: > > > > > > Let's do this the other way around and be react based on facts and not > > > > speculations. > > > > Let's change the policy for a year for selected packages as I > > > > outlined, monitor bugs and after a year see response times, affected > > > > users and if downstream patches are accumulated. Then we can decide if > > > > we need to patch upstream packages. > > > > If we need to patch upstream package anyway, not follow upstream > > > > policy and not accepting input for various of permutations and > > > > architecture from all users, this discussion is nearly void. > > > > > > > > > > ...and for how long did you exactly ignore the standing policy that > > > suddenly we need a new testing period? How about we do the opposite > > > and you prove a *single* bug found downstream using this method so far? > > > > > > Because so far this discussion is not much different than "let's make > > > the ebuild fail for some values of ${RANDOM}, and add extra values when > > > users complain". Though the variant with random has probably a greater > > > chance of failing when *actual* security issues happen. > > > > OK, back to personal discussion, unfortunately you question this in > > this principal thread. > > > > Personal response: > > In all my years in Gentoo, I've never thought the maintainer lose his > > judgement of how to maintain a package as long as the he/she provide a > > great service to users. > > I've never thought or read this (and other) paragraph as a strict > > white and black nor the holy bible , but a suggestion of how to > > provide a great service to user with the least overhead to maintainer, > > the best practice, the common case. > > I believe there was no complains from users about these packages, on > > the opposite users report issues and are happy when resolved after > > proper investigation. > > I guess something had changed recently in Gentoo in which QA try to > > take the maintainer judgement try to enforce a black and white > > perspective and without looking at bug history and other sources. > > I believe this is a regression and not a progression, I was very > > disappointed to see this new side of Gentoo in which common sense for > > a specific case cannot be discussed individually, nor that a fixed bug > > is hijacked to discuss a principal issue without opening a separate > > formal QA request to discuss properly, address some of the argument > > raised by fellow developers and the reaction of requesting to ban > > developers without any mature discussion. As you can see this in this > > thread is not black and white. > > > > I should point out *once again* that: > > a. nobody requested banning developers, > > b. Bugzilla access suspension was requested because of your hostility > in closing the bug and not the technical issue in question -- > or in other words, to prevent you from closing the bug again. > > However, if you continue spreading harmful misinformation about my > intentions in attempt to prove your point in technical matter, then > I believe we have much more serious problem to address here. Unfortunately you still continue the personal discussion in principal thread. I will not cooperate with that as it missing the point. Throw the entire process you are trying to enforce your view and your interpretation of the process as if enforcing that may have benefit. Your request to ban via bugzilla access was rejected with explanation. The bug that was closed was fixed, if you wanted to have a principal discussion you should had opened a different principal one and discuss the issue in opened mind, reaching to a conclusion that we need to escalate the discussion together. I beg you as I beg you in bugzilla, please do not turn this thread to personal one, it is not productive.
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 8:33 PM Michał Górny wrote: > > Let's do this the other way around and be react based on facts and not > > speculations. > > Let's change the policy for a year for selected packages as I > > outlined, monitor bugs and after a year see response times, affected > > users and if downstream patches are accumulated. Then we can decide if > > we need to patch upstream packages. > > If we need to patch upstream package anyway, not follow upstream > > policy and not accepting input for various of permutations and > > architecture from all users, this discussion is nearly void. > > > > ...and for how long did you exactly ignore the standing policy that > suddenly we need a new testing period? How about we do the opposite > and you prove a *single* bug found downstream using this method so far? > > Because so far this discussion is not much different than "let's make > the ebuild fail for some values of ${RANDOM}, and add extra values when > users complain". Though the variant with random has probably a greater > chance of failing when *actual* security issues happen. OK, back to personal discussion, unfortunately you question this in this principal thread. Personal response: In all my years in Gentoo, I've never thought the maintainer lose his judgement of how to maintain a package as long as the he/she provide a great service to users. I've never thought or read this (and other) paragraph as a strict white and black nor the holy bible , but a suggestion of how to provide a great service to user with the least overhead to maintainer, the best practice, the common case. I believe there was no complains from users about these packages, on the opposite users report issues and are happy when resolved after proper investigation. I guess something had changed recently in Gentoo in which QA try to take the maintainer judgement try to enforce a black and white perspective and without looking at bug history and other sources. I believe this is a regression and not a progression, I was very disappointed to see this new side of Gentoo in which common sense for a specific case cannot be discussed individually, nor that a fixed bug is hijacked to discuss a principal issue without opening a separate formal QA request to discuss properly, address some of the argument raised by fellow developers and the reaction of requesting to ban developers without any mature discussion. As you can see this in this thread is not black and white.
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 8:16 PM Richard Yao wrote: > > On 09/14/2018 12:40 PM, Alon Bar-Lev wrote: > > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich > > wrote: > >> > >> On Tue, 11 Sep 2018 12:44:38 +0300 > >> Alon Bar-Lev wrote: > >> > >> I'm personally in favour of not allowing -Werror > >> to be in build system unconditionally. > >> > >> Maintainer is free to implement --enable-werror any way > >> it's convenient to run on their own extended sanity checks > >> and optionally expose it to users. Be it USE flag or > >> EXTRA_ECONF option. > > > > This discussion is not for downstream to have a more strict policy > > than upstream. People try to hijack discussion and introduce noise to > > de-focus the discussion. > > > > Downstream policy cannot be more strict than upstream as then every > > change upstream is doing downstream need to rebase and invest in even > > more changes. > > > > This discussion is to follow upstream strict policy if upstream proves > > that it stands behind it and downstream is willing to follow. > I don't think we should do that unless we provide a USE flag for users > to opt into the behavior. Forcing it on users is problematic for the > reasons others stated. However, letting them opt into the behavior is > reasonable. > > In the case of sys-fs/zfs, enabling -Werror (which includes -Wall) on > USE=debug is following upstream's wishes to build debug builds with -Werror. Let's do this the other way around and be react based on facts and not speculations. Let's change the policy for a year for selected packages as I outlined, monitor bugs and after a year see response times, affected users and if downstream patches are accumulated. Then we can decide if we need to patch upstream packages. If we need to patch upstream package anyway, not follow upstream policy and not accepting input for various of permutations and architecture from all users, this discussion is nearly void.
Re: [gentoo-dev] Changing policy about -Werror
On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich wrote: > > On Tue, 11 Sep 2018 12:44:38 +0300 > Alon Bar-Lev wrote: > > I'm personally in favour of not allowing -Werror > to be in build system unconditionally. > > Maintainer is free to implement --enable-werror any way > it's convenient to run on their own extended sanity checks > and optionally expose it to users. Be it USE flag or > EXTRA_ECONF option. This discussion is not for downstream to have a more strict policy than upstream. People try to hijack discussion and introduce noise to de-focus the discussion. Downstream policy cannot be more strict than upstream as then every change upstream is doing downstream need to rebase and invest in even more changes. This discussion is to follow upstream strict policy if upstream proves that it stands behind it and downstream is willing to follow. For your question: No. Downstream should not add -Werror to upstream package, not in a parameter or USE flag, as this will probably break and cause a queue of downstream patches. > > I would like to suggest a modify our policy with the following > > exception clause: Package maintainer may decide to keep upstream > > -Werror as long as he is willing to resolve all issues resulting from > > -Werror as if it was a blocker bug. > > Do you intend to keep -Werror for case when ebuild goes > stable as well? Correct. > If you do it then what is your workflow to fix breakages > appearing in stable packages caused by minor environment > changes like toolchain tweaks? Correct. > Add another round of stabilization on each arch team? It > sounds like your default assumption that code needs to be > changed in a semantically significant way: add annotations > that might not like some toolchains, remove unused code. No dependency of toolchain nor annotations. A strict policy of no warnings will require changes as dependencies including toolchain are progressing. This creates an overhead for selected packages. A maintainer and the non-stable team should be able to know the package status. Preferably this may be done by automation, I appreciate the work of Toralf Förster with tinderbox to automate check various cases. When a new slot of toolchain is available, maintainers should check their packages in any case, there are other issues and side affects that we experienced, especially in C++ packages. For these packages usually there are 3 for each slot: the current stable, the next stable and the non-stable, so the overhead is constrained. > Or patch package in-place without bumping? None of options > sound optimal compared to dropping -Werror. Success of build is not the only concern although I see people here that are interested only in that. Patching upstream package and/or change upstream quality policy is something that we should avoid as well to maintain upstream warranty. > > The package maintainer decision may be based on the package state and > > the relationship with upstream, but basically, it is his decision as > > long as issues are fixed in timely manner, it is his overhead after > > all. > > I agree that maintainer's will and upstream's will should be > respected and it's not something needs to be absolutely > enforced all the time. > > Personally I disagree -Werror on end-user machine is worth > it (or cppcheck, or coverity round-trip run is worth running > on user's machine unconditionally). > > Unused variable is a good example of typical benign warning: > it was there all the time, it's not a new bug and does not > warrant need for an immediate fix. Unused variable is a good example of CRITICAL potential issue, the bug that triggered this this discussion has a return code that was not used. The permutation was not tested by upstream as it rarely used, it was not tested by me either by the same reason, both is a mistake. Fortunately, someone else tested this permutation and his build failed, triggered a bug. If -Werror has not been used we would not have known about this issue. In many cases these happen in architecture that maintainer nor upstream have access to. In this specific case I went over the code history to the time the return code have been used and determined that this indeed should be ignored, imagine the opposite. A patch was submitted to upstream to confirm resolution as any issue in code, upstream confirmed and merged this in timely fashion. Bottom line we all (Gentoo, upstream and any other distribution) enjoy better quality. > Toolchain just happend to get better at control flow graph > analysis. Fix can easily wait for next release and save > everyone's time. Once again, the number of permutation of build and architecture may reveal issues that are cannot be detected on maintainer machine. If a fix is a real issue that is f
Re: [gentoo-dev] Changing policy about -Werror
On Thu, Sep 13, 2018 at 7:20 PM Fabian Groffen wrote: > > > To illustrate harmless: > > > warning: this statement may fall through [-Wimplicit-fallthrough=] > > > The warning message already has it in it that it's just a pure guess. > > > > One that exposed a lot of unintentional fallthoughs which were fixed > > when reporting to upstream. > > Sure that's why the warning is there. But you ignore the point that the > same code compiled fine and ran fine for years without problems. The fact that something is compiling and running fine meaning there are no issues (bugs) within code? Seriously? Even after no-warning with multiple compiler vendors, code coverage, unit testing, test on various of architecture developer has access to, static code analysis and running for years, bugs are there. Any method to help detect suspicious code, even if it produces amount of false positive, must be embraced of those who care about quality. New toolchains, new scanners, new architectures all can help to improve quality to make sure great service is provided to users. In Gentoo language, all these issues should be detected for selected packages by non-stable users, on architecture and permutations that upstream do not have access to, and to help upstream to filter false positives and find the positives ones. Even one case of funding real issue is sufficient to justify the maintenance costs, once again for selected packages in which upstream following strict quality policy and downstream follows. Once policy is applied, the amount of noise is very little, toolchain evolution is not as it was 10 years ago. Regards, Alon
Re: [gentoo-dev] Changing policy about -Werror
On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen wrote: > > On 12-09-2018 17:46:03 -0700, Matt Turner wrote: > > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote: > > With new GCC comes new warnings, and harmless as the vast majority are > > they cause the build to break with Werror. > > To illustrate harmless: > warning: this statement may fall through [-Wimplicit-fallthrough=] > The warning message already has it in it that it's just a pure guess. One that exposed a lot of unintentional fallthoughs which were fixed when reporting to upstream. Once again... we should discuss to leave -Werror when policy of upstream to have no warnings and is maintaining that policy properly while we at downstream may cooperate and avoid patching upstream but discuss issues when found.
Re: [gentoo-dev] Changing policy about -Werror
Hi, I was the one that (re)trigger this discussion, I thank bircoph for opening this up. First, let me apologize that I did not test the capi USE for long time, as this option is not used for long time by users, I am also apologize of treating bug from anyone (may it be user, developer or even qa) at the same SLA. It took one hour from report to fix including evaluation of the issue and submitting the fix to upstream. The package is non-stable for four months and stable in amd64 for a while without users reporting that because as expected feature is seldom used. Please avoid flaming me for this and address the principal subject at hand as it is important. I would like to suggest a modify our policy with the following exception clause: Package maintainer may decide to keep upstream -Werror as long as he is willing to resolve all issues resulting from -Werror as if it was a blocker bug. The package maintainer decision may be based on the package state and the relationship with upstream, but basically, it is his decision as long as issues are fixed in timely manner, it is his overhead after all. I am maintaining selected packages in which upstream is fully aware of -Werror implications, accepting any patches to resolve issues found by anyone. My judgment as Gentoo developer for these selected packages is to absorb additional overhead in maintaining these packages while helping upstream and users to enjoy higher quality. I've never assumed that an effort individual project is willing to invest is something that overrule by any other project as long as users receives a great service (bugzilla stats are available). I believe that a maintainer in Gentoo is a special role, we not only helping users, but we also help upstream to improve their packages. We are unique as permutations and architectures that are used by Gentoo users are so diverse that we find issues that nobody else finds. In addition to these, we also use latest and greatest toolchains, tools and utilities, this triggers issues at Gentoo even before other distributions. Gentoo non-stable users are a great asset as they are willingly helping to find these issues, with the understanding that their system may break. A good relationship between Gentoo downstream maintainer and upstream actually helps to find fixes long before other distributions are affected. Even when I was in Red Hat, my policy was Gentoo first, as a package that is built in Gentoo without tweaks will be built successfully in all distributions (except of Java maven packages in which we are far behind). Over the years, many Gentoo developers, I included, have built relationship with most active upstreams in my slot to push Gentoo interests into upstream, I invite you to portage tree to see in how many packages we drag patches from one version to another or to evaluate ebuild tweaks. This mutual respect also suggests that if upstream has a -Werror policy, in which every issue as minor as it can be must be taken care of before package is considered to be usable, I as downstream maintainer should help and apply the policy to help upstream to improve its policy. More and more upstream developers are aware of static code analysis benefits, they use every source of information possible, opening coverity to opensource made a great difference, the -Werror is yet another tool to find unexpected issues. The collective mindset was progressed greatly since 2009 where flameeyes opened bug#260867. At least once per 10 years one should re-evaluate his policies, the industry is changing. When upstream policy is to have zero warnings policy, suppressed by explicit suppression (code or compile argument), and when upstream is friendly and actively following the policy of investigating each incident and fix it properly, we can help for selected packages. ARGUMENT: If a package compiled in the past using toolchain X then it must continue to do so with any future toolchain. I do not understand when "build" is the test for runtime, for 30 years I tell my developers and students that "It compiles" and "It works" are two different statements. One should only be thankful for any tool to detect issues hidden within code, stop and re-evaluate when new issues are found. Let's take two recent examples from my queue: bug#665464 in which there was unused return code variable, this made me look into source code of upstream from master back in time until code was introduced to find out when return code was used and why it was removed, reaching to a conclusion that indeed return code should be ignored and submitting a patch to upstream to validate that, upstream confirmed and merged. Imagine what would happen if I would have found that it is a real issue and should be addressed? Both users and upstream would have benefit from finding and fixing the issue. bug#664198 in which -Werror found mismatched memcpy, this was an actual bug that must be fixed. Based on the above we have in recent month one false posi
Re: [gentoo-dev] Packages up for grabs: sys-apps/fakechroot, sys-apps/fakeroot-ng
I can take them. On Sun, Aug 19, 2018 at 11:24 AM Jonas Stein wrote: > Dear all, > > The following packages are up for grabs: > > sys-apps/fakechroot > sys-apps/fakeroot-ng > > after retirement of the proxied maintainer. > It was defacto maintained by various gentoo devs. > > https://packages.gentoo.org/packages/sys-apps/fakechroot > https://packages.gentoo.org/packages/sys-apps/fakeroot-ng > > -- > Best, > Jonas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [gentoo-dev] [News item review] Portage rsync tree verification (v2)
On 26 January 2018 at 00:21, Robin H. Johnson wrote: > On Thu, Jan 25, 2018 at 11:55:58PM +0200, Alon Bar-Lev wrote: >> I did not looked into the detailed implementation, however, please >> make sure integrity check handles the same cases we have applied to >> emerge-webrsync in the past, including: > Gemato is the implementation of GLEP74/MetaManifest, which DOES > explicitly address both of these concerns. Good! Thanks. > >> 1. Fast forward only in time, this is required to avoid hacker to >> redirect into older portage to install vulnerabilities that were >> approved at that time. > Replay attacks per #1 are addressed via TIMESTAMP field in MetaManifest. Interesting, I tried again to understand how it is working without performing rsync to a temporary directory, compare the timestamp and reject if unexpected. Are we doing multiple rsync for the metadata? Long since I used this insecure rsync... For me it seems like webrsync and/or squashfs are much easier/faster to apply integrity into than rsync... :) Regards, Alon
Re: [gentoo-dev] [News item review] Portage rsync tree verification (v2)
Hi, On 25 January 2018 at 14:35, Michał Górny wrote: > > Starting with sys-apps/portage-2.3.22, Portage enables cryptographic > verification of the Gentoo rsync repository distributed over rsync > by default. This aims to prevent malicious third parties from altering > the contents of the ebuild repository received by our users. I did not looked into the detailed implementation, however, please make sure integrity check handles the same cases we have applied to emerge-webrsync in the past, including: 1. Fast forward only in time, this is required to avoid hacker to redirect into older portage to install vulnerabilities that were approved at that time. 2. Content integrity, especially removal, as far as I understand, the mechanism will not enable to detect authorized removal of content. Regards, Alon
Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?
On 2 December 2017 at 23:08, Michał Górny wrote: > > W dniu sob, 02.12.2017 o godzinie 22∶43 +0200, użytkownik Alon Bar-Lev > napisał: > > Hi, > > Any reason we do not publish hardened/no-multilib? > > I see we have[1] in place and is working if explicitly added. > > > > One reason might be that: Thanks. > > 1) there's barely any use for it, Well, I think that whoever use hardened barely use multilib. > 2) we have too many profiles, and This has not stopped us so far. > 3) every added profile slows down repoman & pkgcheck seriously. Only when using '-d', no? Anyway, probably the default of hardened should be multilib so we end up with the same number. > > [1] profiles/features/hardened/amd64/no-multilib Regards, Alon
[gentoo-dev] profiles 17.0 hardened/no-multilib missing?
Hi, Any reason we do not publish hardened/no-multilib? I see we have[1] in place and is working if explicitly added. Thanks, Alon [1] profiles/features/hardened/amd64/no-multilib
Re: [gentoo-dev] dev-libs/cryptlib masked for removal in 30 days
On 8 September 2017 at 22:44, R0b0t1 wrote: > > On Fri, Sep 8, 2017 at 2:40 PM, Alon Bar-Lev wrote: > > Complex build system, hard to maintain, no dependencies in tree, upstream > > does not cooperate (Bug#630420). > > Removal in 30 days. > > > > I don't have any reason to disagree with this but I expected a > citation for those things to be in the bug you referenced. They're > not, and I don't see any bugs on the tracker. The effort of upgrade per each version is becoming greater. Previous and next versions required significant work, issues reported to upstream with the hope of a change, but most is rejected. The build system is so complex that is specific to gcc/ld and hard-coded dependencies locations and cflags/ldflags magic. Unless we have a very good reason (important dependency), my suggestion is to drop it. Do we have such a reason?
[gentoo-dev] dev-libs/cryptlib masked for removal in 30 days
Complex build system, hard to maintain, no dependencies in tree, upstream does not cooperate (Bug#630420). Removal in 30 days.
[gentoo-dev] sys-auth/pam_pkcs11 masked for removal in 30 days
Upstream no longer maintain (Bug#628908). Removal in 30 days.
[gentoo-dev] Call for help in testing - sparc + gnutls-3.5
Hello, I am looking for someone that is using gentoo on sparc and is willing to help out to resolve an issue[1] of gnutls-3.5 with sparc so that we can drop gnutls-3.3 from tree. I tried to create a bootable sparc qemu gentoo image and failed, so need someone with a live system. Regards, Alon [1] https://bugs.gentoo.org/show_bug.cgi?id=613418
Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine
On 18 May 2017 at 07:10, Marty Plummer wrote: > On Thu, May 18, 2017 at 06:53:48AM +0300, Alon Bar-Lev wrote: >> On 18 May 2017 at 06:54, Marty Plummer wrote: >> > Greetings, >> > >> > As the subject states, compiling dev-libs/libressl for x86_64-w64-mingw32 >> > target via crossdev ends up calling wine to run checks, which fails with >> > an access violation, and as such emerge cannot finish. >> > >> > Would it be an acceptable change to disable emake check for mingw-w64 >> > crossdev targets? >> > >> >> Why do you enable tests? >> > I did not, there is no use flag for dev-libs/libressl I can use to > disable tests. if there is a global flag I should disable, I'd be > greatly appreciative of it. > If you enable tests globally, then you can disable them for a specific build using: FEATURES="-test" emerge ...
Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine
On 18 May 2017 at 06:54, Marty Plummer wrote: > Greetings, > > As the subject states, compiling dev-libs/libressl for x86_64-w64-mingw32 > target via crossdev ends up calling wine to run checks, which fails with > an access violation, and as such emerge cannot finish. > > Would it be an acceptable change to disable emake check for mingw-w64 > crossdev targets? > Why do you enable tests?
Re: [gentoo-dev] mingw-w64 crossdev prefix?
On 18 May 2017 at 06:46, Matthias Maier wrote: > [2] I had to manually disable libsanitizer for gcc-6.3.0. Just set > EXTRA_ECONF="--disable-libsanitizer" via env/package.env for the > cross-x86_64-w64-mingw32/gcc package. Hi, You should use the USE flags and not apply such workarounds, for example: USE="-sanitizer" crossdev ... Alon
Re: [gentoo-dev] mingw-w64 crossdev prefix?
Hi, You can emerge crossdev and then run crossdev -t x86_64-w64-mingw32 or crossdev -t i686-w64-mingw32 Alon On 18 May 2017 at 01:25, Marty Plummer wrote: > > Greetings, > > So, I'm a relatively new gentoo user (as of 2016-12) coming from arch, > and one thing I've noticed is the relative difficulty of setting up a > mingw-w64 cross-compile toolchain and libraries. > > I'm considering the idea of setting up a sort of prefix specifically > with the intent of being used on a 'normal' gentoo system with the sole > purpose of creating 'normal' windows binaries; does anyone have > suggestions/objections about the idea? > > As it currently stands I have to use an archlinux chroot to do my > cross-compiling, and I'd really enjoy to be able to do this sort of > thing without depending on an auxiliary distro. > > Marty. >
[gentoo-dev] gnutls-3.5 last remaining issues - please assist
Hello, I would like to push gnutls-3.5 into stable per[1]. Below are known related issues we still have, please help to push these forward. If anyone wishes to help testing before we progress, please move to non-stable gnutls and report back any issue. Please also emerge using the following settings and report back any failure: USE="test-full" FEATURES="test" emerge gnutls Thanks, Alon [1] https://bugs.gentoo.org/showdependencytree.cgi?id=612340&hide_resolved=1 --- url: https://bugs.gentoo.org/show_bug.cgi?id=595952 desc: net-libs/glib-networking-2.48.2 with net-libs/gnutls-3.5.4[-sslv3] fails test... owner: gnome If it is only test issue, we should disable the test. url: https://bugs.gentoo.org/show_bug.cgi?id=613418 desc: net-libs/gnutls-3.5.10 fails cert-key-exchange tests on sparc owner: sparc We have outage of sparc machine, if anyone with sparc can help it would be great. url: https://bugs.gentoo.org/show_bug.cgi?id=615008 desc: =sys-devel/autogen-5.18.4 - please add slot operator for guile owner: toolchain As the guile tests requires guile-2, it will be nice if we can have this to allow seamless upgrade/downgrade of guile without experiencing autogen issues. url: https://bugs.gentoo.org/show_bug.cgi?id=612348 desc: =app-admin/gkrellm-2.3.10 stable request owner: hppa, ia64, sparc gnutls-3.5 compatibility url: https://bugs.gentoo.org/show_bug.cgi?id=612344 desc: =mail-client/cone-0.92 stable request owner: ppc gnutls-3.5 compatibility url: https://bugs.gentoo.org/show_bug.cgi?id=391463 desc: Please stabilize =dev-libs/iksemel-1.4 owner: ppc gnutls-3.5 compatibility, a patch is available to fix test failure on ppc.
[gentoo-dev] dev-libs/engine_pkcs11 masked for removal in 30 days
Replaced by dev-libs/libp11 unmaintained by upstream. Bug#609668. Removal in 30 days.
[gentoo-dev] net-misc/gnutls-3.4 stabilization
Hi, I would like to start stabilizing gnutls-3.4. If anyone is aware of an issue please speak up. Thanks! Alon
Re: [gentoo-dev] RFC: Future EAPI version operator changes
On 6 November 2016 at 12:52, Michał Górny wrote: > Hi, everyone. > So, what are your comments? Hi, Just my 2 cents... I kinda love the prefix nature of the expressions which is consistent and easier to parse. Using infix only for versions and leaving all the rest prefix will create abnormality. Regards, Alon
[gentoo-dev] dev-python/pssi package masked for removal in 30 days
# Alon Bar-Lev (05 Nov 2016) # Masked for removal in 30 days, bug#598982. # Upstream does not publish releases, no tags, last publish is on # google code, no dependencies. dev-python/pssi
[gentoo-dev] app-crypt/scl011-bin package masked for removal in 30 days
# No upstream, no maintainer (bug #592164) # Package will be removed from Gentoo in 30 days. app-crypt/scl011-bin
[gentoo-dev] app-crypt/bcrypt package masked for removal in 30 days
# Weak cryptography (bug #592114) # Package will be removed from Gentoo in 30 days. app-crypt/bcrypt
Re: [gentoo-dev] Last rites: kde-apps/ksnapshot
On 14 July 2016 at 23:15, Johannes Huber wrote: > Am Donnerstag 14 Juli 2016, 21:47:10 schrieb Alon Bar-Lev: >> I have only three: Application, Global, Web >> Shouldn't it be integrated into Global? > > Maybe this helps: > https://bbs.archlinux.org/viewtopic.php?id=206600 yes, I saw that, I thought it is older version of plasma as. I tried to installed khotkeys before I sent my question and it did not show the new tab, now I tried again just to make sure and it does, strange. When I installed it it created the ~/.config/khotkeysrc without the spectacle profile, I had to remove it logout/login in order to make it work. please consider making khotkeys a dependency of spectacle. Regards, Alon
Re: [gentoo-dev] Last rites: kde-apps/ksnapshot
I have only three: Application, Global, Web Shouldn't it be integrated into Global? On 14 July 2016 at 21:44, Johannes Huber wrote: > Please check systemsettings -> shortcuts -> 4th tab. > > Greetings, > Johannes > > Am Donnerstag 14 Juli 2016, 21:26:04 schrieb Alon Bar-Lev: >> Just tried to switch. >> Print-Screen shortcut is not working, any idea why? >> Saw some similar issues, but could not find out what is wrong as most >> of the fixes are embedded. >> Thanks! >> >> On 14 July 2016 at 20:33, Johannes Huber wrote: >> > # Johannes Huber (14 Jul 2016) >> > # No longer released upstream. Use kde-apps/spectacle instead. >> > # Masked for removal in 30 days. >> > kde-apps/ksnapshot > >
Re: [gentoo-dev] Last rites: kde-apps/ksnapshot
Just tried to switch. Print-Screen shortcut is not working, any idea why? Saw some similar issues, but could not find out what is wrong as most of the fixes are embedded. Thanks! On 14 July 2016 at 20:33, Johannes Huber wrote: > > # Johannes Huber (14 Jul 2016) > # No longer released upstream. Use kde-apps/spectacle instead. > # Masked for removal in 30 days. > kde-apps/ksnapshot
Re: [gentoo-dev] dev-util/nsis: Maintainer request
Can you please check it out? I had no time nor setup. On 12 June 2016 at 14:49, M. J. Everitt wrote: > Cheers Alon, > > Michael. > On 12/06/16 12:43, Alon Bar-Lev wrote: >> Hi, >> I've revbumped this package. >> Regards, >> Alon >> >> On 6 June 2016 at 03:23, M. J. Everitt wrote: >>> On 05/06/16 22:55, Kristian Fiskerstrand wrote: >>>> dev-util/nsis curretly has no maintainer. It has a [critical security >>>> bug filed against it]. Does anyone want to pick it up? if not we'll >>>> start a last rite process for it. >>>> >>>> [critical security bug filed against it] >>>> https://bugs.gentoo.org/show_bug.cgi?id=568398 >>> Per conversation in #g-p-m I'll take this on via proxy if nobody else >>> volunteers in the next 7 days (w/e 12th June) to start with, as I'm >>> pretty sure a colleague is using it on a project, and we could do >>> without losing it from the tree .. ! >>> >>> Quick glance at the project page, and bug suggests revbump, stabilise >>> and drop old version might cure the existing issue, but will investigate >>> further. >>> Cheers, >>> Michael. >>> > >
Re: [gentoo-dev] dev-util/nsis: Maintainer request
Hi, I've revbumped this package. Regards, Alon On 6 June 2016 at 03:23, M. J. Everitt wrote: > On 05/06/16 22:55, Kristian Fiskerstrand wrote: >> dev-util/nsis curretly has no maintainer. It has a [critical security >> bug filed against it]. Does anyone want to pick it up? if not we'll >> start a last rite process for it. >> >> [critical security bug filed against it] >> https://bugs.gentoo.org/show_bug.cgi?id=568398 > Per conversation in #g-p-m I'll take this on via proxy if nobody else > volunteers in the next 7 days (w/e 12th June) to start with, as I'm > pretty sure a colleague is using it on a project, and we could do > without losing it from the tree .. ! > > Quick glance at the project page, and bug suggests revbump, stabilise > and drop old version might cure the existing issue, but will investigate > further. > Cheers, > Michael. >
Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support
On 20 April 2016 at 18:52, Ian Stakenvicius wrote: > > Hi everyone: > > After doing some experimentation with a mingw crossdev, I found that I > needed to do a lot of EXTRA_ECONF settings in combination with > USE="aqua" in order to get packages supporting a win32 API to be > configured appropriately. In order to support this situation better, > I propose adding a new global flag 'win32', modelled after the 'aqua' > flag, that can be used instead to provide this configuration directly > in ebuilds. > > Just like USE="aqua", the flag will be use.mask'ed in base/ so that > users don't erroneously enable it. I didn't un-use.mask it anywhere > yet since (A) I don't have a prefix/windows environment to test, and > (B) the mingw-based crossdev environments use profiles/embedded by > default, which doesn't inherit from profiles/base and so doesn't have > the use.mask restriction. > > The attached patch lists the necessary changes to profile/ as well as > the addition of USE=win32 to *ONE VERSION* of gtk+:2, gtk+:3 and cairo > (the actual commit will include more versions). > > Comments? You should be able to achieve similar behavior by looking at libc and/or CHOST without introducing new USE flag, just like we do for aix/solaris/freebsd etc...
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 14 February 2016 at 22:23, Mike Frysinger wrote: > udev: it's the default in every major distro that everyone tests and > develops against. > > eudev: no one of any relevance outside of Gentoo runs it. I honestly don't understand this argument that pops over and over. No "major distro" using udev without systemd, so OpenRC people are already using udev in unsupported setup. Better to use a tool that is tested and supported in this setup. Or maybe I do not understand and mission is for us to switch to systemd? Systemd users/developers should not mind what the default is as they are forced to use one variant anyway, these users/developers should not force their opinion upon others. Thanks, Alon
Re: [gentoo-dev] Changing order of default virtual/udev provider
On 9 February 2016 at 13:59, Rich Freeman wrote: > > On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile > wrote: > > On 2/8/16 10:09 PM, Rich Freeman wrote: > >> How many of those 14 distros have more than 14 users? > > > > gentoo is very unpopular as a distro. however, it excels as a meta > > distro. if you marginalize its special features, you take away all its > > charm. > > The controversy comes in when you want to make it a default, and start > arguing that it is somehow better than the solution everybody else is > using. > > Outside of Gentoo people either aren't concerned at all with eudev (it > probably isn't even in their distro repositories), or they're a tiny > distro whose main purpose in life seems to be to avoid installing > systemd. Of course you're going to get praise from them. > > I've always supported having eudev hosted by Gentoo. I just don't > support it being the default udev provider. > I too support eudev as default for openrc people, Gentoo is about choice, and OpenRC eco-system should get rid of all systemd related dependencies. This is a choice we provide. eudev should stand as its own and provide a service for the non-systemd users, these users actually care about what we provide, Gentoo is one of the last distros that enables that. I use eudev since its first beta, and these guys provides good service. I also mask all systemd files that somehow find their way into my system thanks to your past decisions as systemd supporter, instead of installing these only when systemd USE flag is set and adding openrc USE flag for the systemd users folks. It may in future that udev will completely relay on systemd and we left with eudev as the only choice for non systemd-eco system, it is better to start building this eco-system now, make sure we have a working solution at any given point in time. Alon
Re: [gentoo-dev] [RFC] name of smartcard support USE flag
On 13 December 2015 at 19:30, Alon Bar-Lev wrote: > On 13 December 2015 at 19:28, Gilles Dartiguelongue wrote: >> Le dimanche 13 décembre 2015 à 18:25 +0200, Alon Bar-Lev a écrit : >>> On 13 December 2015 at 18:20, Gilles Dartiguelongue >>> wrote: >>> > >>> > I was trying to cleanup my local USE flag settings and stumbled on >>> > the >>> > following three: smartcard, pcsc-lite and pkcs11. >>> > >>> > Knowing all 3 are related, I greped use.local.desc to see what each >>> > meant for different packages. To sum up what I found: >>> > * pcsc-lite is basically: enable smartcard support through >>> > sys- >>> > apps/pcsc-lite >>> > * pkcs11: enabled PKCS#11 (smartcard) via $pkg >>> > >>> > These look like the same thing to me so I propose we merge them all >>> > into USE=smartcard as this is the feature being enabled, not the >>> > lib or >>> > the standard being used to access the hardware if any. >>> >>> pcsc-lite and PKCS#11 interfaces are both related to smartcards but >>> different unrelated interfaces. I am unsure merging them will serve >>> the purpose for applications that are capable of supporting more than >>> one interface. >> >>> also, please notice that PKCS#11 is not all about smartcards, but an >>> interface to any cryptographic hardware. >> >> I agree with your points, my point is that it seems most of the time, >> both use flags are used in place of smartcard (or another name if this >> one does not fit in your opinion). >> >> According to local description, app-mobilephone/gnoki, net- >> libs/libosmocore and net-misc/rdesktop at least should be using >> USE=smartcard instead of USE=pcsc-lite > > rdesktop - I agree. BTW: why don't you use net-misc/freerdp, works better to me and does have smartcard USE :) > I do not know the other packages.
Re: [gentoo-dev] [RFC] name of smartcard support USE flag
On 13 December 2015 at 19:28, Gilles Dartiguelongue wrote: > Le dimanche 13 décembre 2015 à 18:25 +0200, Alon Bar-Lev a écrit : >> On 13 December 2015 at 18:20, Gilles Dartiguelongue >> wrote: >> > >> > I was trying to cleanup my local USE flag settings and stumbled on >> > the >> > following three: smartcard, pcsc-lite and pkcs11. >> > >> > Knowing all 3 are related, I greped use.local.desc to see what each >> > meant for different packages. To sum up what I found: >> > * pcsc-lite is basically: enable smartcard support through >> > sys- >> > apps/pcsc-lite >> > * pkcs11: enabled PKCS#11 (smartcard) via $pkg >> > >> > These look like the same thing to me so I propose we merge them all >> > into USE=smartcard as this is the feature being enabled, not the >> > lib or >> > the standard being used to access the hardware if any. >> >> pcsc-lite and PKCS#11 interfaces are both related to smartcards but >> different unrelated interfaces. I am unsure merging them will serve >> the purpose for applications that are capable of supporting more than >> one interface. > >> also, please notice that PKCS#11 is not all about smartcards, but an >> interface to any cryptographic hardware. > > I agree with your points, my point is that it seems most of the time, > both use flags are used in place of smartcard (or another name if this > one does not fit in your opinion). > > According to local description, app-mobilephone/gnoki, net- > libs/libosmocore and net-misc/rdesktop at least should be using > USE=smartcard instead of USE=pcsc-lite rdesktop - I agree. I do not know the other packages.
Re: [gentoo-dev] [RFC] name of smartcard support USE flag
On 13 December 2015 at 18:20, Gilles Dartiguelongue wrote: > > I was trying to cleanup my local USE flag settings and stumbled on the > following three: smartcard, pcsc-lite and pkcs11. > > Knowing all 3 are related, I greped use.local.desc to see what each > meant for different packages. To sum up what I found: > * pcsc-lite is basically: enable smartcard support through sys- > apps/pcsc-lite > * pkcs11: enabled PKCS#11 (smartcard) via $pkg > > These look like the same thing to me so I propose we merge them all > into USE=smartcard as this is the feature being enabled, not the lib or > the standard being used to access the hardware if any. pcsc-lite and PKCS#11 interfaces are both related to smartcards but different unrelated interfaces. I am unsure merging them will serve the purpose for applications that are capable of supporting more than one interface. also, please notice that PKCS#11 is not all about smartcards, but an interface to any cryptographic hardware. Regards, Alon
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgcrypt/files/, dev-libs/libgcrypt/
On 2 December 2015 at 21:52, Michał Górny wrote: > On Wed, 2 Dec 2015 21:48:24 +0200 > Alon Bar-Lev wrote: > >> On 2 December 2015 at 21:45, Brian Evans wrote: >> > >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA1 >> > >> > On 12/1/2015 1:45 AM, Alon Bar-Lev wrote: >> > > Yes, sorry my bad, repoman did not complain. >> > >> > This is still not working because some packages, i.e sys-fs/ntfs3g, >> > have a dependency like > >> in this specific case ntfs3g-2014.2.15-r1 is stable the previous >> versions should be cleaned up. > > It is *your* responsibility to ensure that previous versions are > cleaned up *before* you remove libgcrypt. Also, I'm more worried about > sys-power/suspend where the stable version still requires it. And yes, > you've broken the stable tree and I'd really appreciate having it fixed > right away. OK, done. > > -- > Best regards, > Michał Górny > <http://dev.gentoo.org/~mgorny/>
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgcrypt/files/, dev-libs/libgcrypt/
On 2 December 2015 at 21:45, Brian Evans wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/1/2015 1:45 AM, Alon Bar-Lev wrote: > > Yes, sorry my bad, repoman did not complain. > > This is still not working because some packages, i.e sys-fs/ntfs3g, > have a dependency like
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgcrypt/files/, dev-libs/libgcrypt/
Yes, sorry my bad, repoman did not complain. On 1 December 2015 at 08:44, Michał Górny wrote: > On Tue, 1 Dec 2015 06:16:40 + (UTC) > "Alon Bar-Lev" wrote: > >> commit: 1519f072b810c69428badbe5fc54960f1a2a12b3 >> Author: Alon Bar-Lev gentoo org> >> AuthorDate: Tue Dec 1 06:16:26 2015 + >> Commit: Alon Bar-Lev gentoo org> >> CommitDate: Tue Dec 1 06:16:26 2015 + >> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1519f072 >> >> dev-libs/libgcrypt: cleanup >> >> Package-Manager: portage-2.2.20.1 >> >> dev-libs/libgcrypt/Manifest| 1 - >> .../libgcrypt/files/libgcrypt-1.5.0-uscore.patch | 33 - >> .../files/libgcrypt-1.5.4-clang-arm.patch | 84 >> -- >> dev-libs/libgcrypt/libgcrypt-1.5.4-r1.ebuild | 57 --- >> dev-libs/libgcrypt/libgcrypt-1.5.4-r100.ebuild | 58 --- > > Isn't the point of compatibility slots like :11 there that they should > be kept for binary packages to work? Because you just removed that, > plus all 1.5* versions, effectively causing huge breakage: > > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/2.html#l1193 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/2.html#l1219 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1082 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1108 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1134 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1997 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l208 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l234 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l249 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l460 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/12.html#l898 > https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/12.html#l2088 > > Please fix this ASAP and next time check reverse dependencies before > removing packages. > > -- > Best regards, > Michał Górny > <http://dev.gentoo.org/~mgorny/>
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
On 30 July 2015 at 19:15, Ian Stakenvicius wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 30/07/15 01:55 AM, Duncan wrote: > > Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as > > excerpted: > > > >> On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev > >> wrote: > >> > >>> On 29 July 2015 at 23:20, William Hubbs > >>> wrote: > >>>> > >>>> so that there is a better idea out there of what I'm talking > >>>> about, the OpenRC github repository now has a mount-service > >>>> branch. > >>> > >>> But I still trying to figure out why do we need to keep fstab > >>> around. It is pure legacy. > >>> > >>> > >> On what planet is fstab pure legacy? Many utilities use it and > >> expect it to exist. For example the ability to do "mount /foo" > >> requires a properly configured fstab file (also mount -a). > >> > > I think there are two meanings of the word legacy here. > > #1, /etc/fstab on linux is not legacy, and I don't think anyone here > (except possibly for WilliamH as I can't actually tell from his > statements) has been calling it 'legacy' in this context. /etc/fstab is legacy in the sense it did not evolve since early days of UNIX. Imagine /etc/crontab was left the same single file, but it at least evolved to usr /etc/cron.*/ to ease management of multiple sources and ease packaging/maintenance without need to parse and rewrite single file when provisioning. Nobody ignores /etc/fstab existence, I provided solutions of how /etc/fstab can be read in flexible method as netifrc does (which was actually the core idea of this move), doing so will make the service much simpler as it can use external helper scripts to provide the data out of whatever source, please re-read my message. However, having the option *NOT* to use /etc/fstab has many advantages in security (storing credentials in own files), provisioning (no need to race parse/rewrite), dynamic (define the location of nfs server based on logic) and many more. I do not understand why people are so sensitive for a change that does not effect the outcome of their need, all that I recommended to add is driver: mount_driver_\${NAME}=fstab mount_mountpoint_\${NAME}=/mnt/auto driver will be executed by the service, in this case: openrc-mount-helper-${openrc_mount_driver_\${NAME}} ${mount_mountpoint_\${NAME}} the output will be evaluated. This simple solution will enable the service to be generic and provide flexible pure configuration (whatever we choose), while support any source of information that is capable of constructing this configuration. Loose nothing gain some, simpler service and constraint fstab within driver. Another drive I can think of is UPnP. Regards, Alon
Re: [gentoo-dev] rfc: openrc mount service prototype
On 30 July 2015 at 01:33, William Hubbs wrote: > On Wed, Jul 29, 2015 at 05:22:54PM -0500, William Hubbs wrote: >> On Thu, Jul 30, 2015 at 01:11:30AM +0300, Alon Bar-Lev wrote: >> > On 29 July 2015 at 23:20, William Hubbs wrote: >> > > >> > > All, >> > > >> > > so that there is a better idea out there of what I'm talking about, the >> > > OpenRC github repository now has a mount-service branch. >> > >> > Nice! >> > >> > But I still trying to figure out why do we need to keep fstab around. >> > It is pure legacy. >> >> Is it? I have heard different people say it is, and it isn't, so I have >> no idea. >> >> If fstab is truly legasy, I'll look into that. > > It seems that it is not legasy... > > For example, what happens if you do: > > mount /foo/bar > > and don't have fstab? > > William > if I choose to not use fstab, I will not use mount /foo/bar Why will I do that? For example, I can put passwords in different ACL. I can add logic, for example dynamic mount point. This is why using netifrc like configuration is so great. I can choose to use fstab, then I lost all these goodies but can do mount /foo/bar...
Re: [gentoo-dev] rfc: openrc mount service prototype
On 30 July 2015 at 01:22, William Hubbs wrote: > On Thu, Jul 30, 2015 at 01:11:30AM +0300, Alon Bar-Lev wrote: >> On 29 July 2015 at 23:20, William Hubbs wrote: >> > >> > All, >> > >> > so that there is a better idea out there of what I'm talking about, the >> > OpenRC github repository now has a mount-service branch. >> >> Nice! >> >> But I still trying to figure out why do we need to keep fstab around. >> It is pure legacy. > > Is it? I have heard different people say it is, and it isn't, so I have > no idea. > > If fstab is truly legasy, I'll look into that. for what it worth, a fstab.d would have been something usable... :) but if you are providing netifrc like configuration, there is no need to split configuration between the layout and the fstab, everything should be at one place if possible. maybe we can have some intermediate options... to bridge the gap, but all are in the scope of conf.d, examples: eval $(openrc-mount-helper-fstab ${NAME} /mnt/auto) or... builtin mount_driver_\${NAME}=fstab # will call eval $(openrc-mount-helper-${openrc-mount-driver-\${NAME}} ${NAME} "$@") mount_mountpoint=/mnt/auto but this fstab usage is optional.
Re: [gentoo-dev] rfc: openrc mount service prototype
On 29 July 2015 at 23:20, William Hubbs wrote: > > All, > > so that there is a better idea out there of what I'm talking about, the > OpenRC github repository now has a mount-service branch. Nice! But I still trying to figure out why do we need to keep fstab around. It is pure legacy. There can be a migration script to generate /etc/conf.d/* configuration once, but there is no need to keep it around. The conf.d can contain everything that fstab contains. mount_mountpoint_\${NAME}= mount_type_\${NAME}= mount_fs_\${NAME}= mount_opts_\${NAME}= mount_dump_\${NAME}= mount_pass_\${NAME}= There can even be a script to set above environments from fstab as pure utility given mountpoint as parameter. This will simplify the service as it will always accept the variables at one form. Regards, Alon
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On 28 July 2015 at 01:26, William Hubbs wrote: > The proposal in [3], on the other hand, is to create a mount script that > works like netifrc. It would mount a single file system, which would be > determined by the link it was called from, much like how netifrc > determines which interface to work on. Hi, This is great and consistent with all other services. What I would like to see is how to not relay on /etc/fstab content, if possible. If it is like netifrc, there can be fstab module that provides entries for fstab. It can be in /etc/conf.d/filesystem.@name@ instead of openrc core. for example: --- modules="fstab" config__usr="fstab" # replace /->_ --- Regards, Alon
Re: [gentoo-dev] Git, GPG Signing, and Manifests
On 17 July 2015 at 15:36, Rich Freeman wrote: > On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec wrote: >> >> I don't know tbh, most are already signed, with the git migration, the >> strongly recommended commit signing will become MANDATORY. >> >> So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys >> listed in LDAP that fail to meet the new spec. PLEASE fix them or >> create new keys... > > How does somebody know whether their key meets the spec or not? I > looked at the gentoo-keys website and didn't see any simple way to > check. > > There was documentation on the gkeys utility for checking keys, but I > ran into a few issues with this. First, it can't be installed on a > stable system with mirrorselect. The use of keys should be by counter signature, when pushing the counter signature service should check if signature is valid and dev key is valid using the internal ldap for example, and counter sign with its own key and add timestamp. Users should trust only the counter signature service key which is formal and should be valid for long time. This is yet another reason why it is best to not use signature within git but remain the signed manifest. When commit one can sign the manifest, send the manifest to the counter signature service and obtain a formal signed manifest to be committed into tree. Using signed manifest also reduce the merge conflict, survive rebase, enable code review without loosing original signer and will enable future migration to other technology. Regards, Alon
Re: [gentoo-dev] Git workflow
On 4 July 2015 at 23:28, Alexandre Rostovtsev wrote: > > On Sun, 2015-07-05 at 02:16 +0700, C Bergström wrote: > > 2) I don't understand your comment about signatures. > > Gpg commit signatures [1] which are a requirement for any gentoo git > workflow. Rebasing breaks the author's signature afaict, so the user > who is doing rebasing needs to re-sign the commit using his own key. > > [1] https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work#Signing-Commits > Maybe this is the root cause of all issues, and simpler was to remain with signed manifests. Just a thought... Not every git feature out there should be actually be leveraged. Doing so would enable rebase without loosing data, more secure (than SHA-1) signatures, using code review tools such as gerrit without an issue, migration out of git in future and probably more.
Re: [gentoo-dev] News item review: SquashDelta syncing support
On 15 May 2015 at 17:51, Michał Górny wrote: > Please note that the current syncing code does not verify the OpenPGP > signature to confirm the authenticity of fetched snapshots and deltas. > This feature will be added as soon as gentoo-keys support in Portage is > available. These are great news! We can retire the webrsync. Why not sign it similar to the portage snapshot are signed for now? The webrsync signature validation is quite simple. Just a reminder: please note the rollback prevention mechanism in webrsync, it is not enough to check signature, but also prevent older snapshot to be used. Regards, Alon
Re: [gentoo-dev] bugs.gentoo.org and dnssec
On 21 April 2015 at 20:40, James Cloos wrote: >>>>>> "AB" == Alon Bar-Lev writes: > > AB> When using bugs.gentoo.org with dnsmasq and dnssec enabled, I cannot > AB> access attachments. > > It works here using a local unbound. > > But dnsmasq had some growth pains when it added dnssec verification, due > to its bottom-up rather than the ususal top-down approach. > > AIUI, the current release should work. > > If you see that issue with 2.72 or later, they'd like to hear about it. > > Their list is: dnsmasq-disc...@lists.thekelleys.org.uk > Thanks! I suspected that. Yes, I am using 2.72, I will send message.
[gentoo-dev] bugs.gentoo.org and dnssec
Hi, Not sure where the problem is... maybe others can reproduce this. When using bugs.gentoo.org with dnsmasq and dnssec enabled, I cannot access attachments. The attachments are forwarded to a CNAME, for example: --- 546330.bugs.gentoo.org. 60 IN CNAME bugs-gossamer.gentoo.org. bugs-gossamer.gentoo.org. 300 IN CNAME gannet.gentoo.org. gannet.gentoo.org. 604800 IN A 204.187.15.4 --- When trying to access without dnssec all is ok: --- Apr 21 20:19:04 [dnsmasq] query[A] 546330.bugs.gentoo.org from 127.0.0.1 Apr 21 20:19:04 [dnsmasq] forwarded 546330.bugs.gentoo.org to 192.168.1.1 Apr 21 20:19:04 [dnsmasq] validation result is INSECURE Apr 21 20:19:04 [dnsmasq] reply 546330.bugs.gentoo.org is Apr 21 20:19:04 [dnsmasq] reply bugs-gossamer.gentoo.org is Apr 21 20:19:04 [dnsmasq] reply gannet.gentoo.org is 204.187.15.4 --- When trying to access with dnssec, notice the "validation result is BOGUS", no result is returned: --- Apr 21 20:09:33 [dnsmasq] query[A] 546330.bugs.gentoo.org from 127.0.0.1 Apr 21 20:09:33 [dnsmasq] forwarded 546330.bugs.gentoo.org to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] gentoo.org to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DS] gentoo.org to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] org to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DS] org to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] . to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] reply . is DNSKEY keytag 19036 Apr 21 20:09:33 [dnsmasq] reply . is DNSKEY keytag 48613 Apr 21 20:09:33 [dnsmasq] reply org is DS keytag 21366 - Last output repeated twice - Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 3213 Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 21366 Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 9795 Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 34023 Apr 21 20:09:33 [dnsmasq] reply gentoo.org is DS keytag 46873 - Last output repeated twice - Apr 21 20:09:33 [dnsmasq] reply gentoo.org is DNSKEY keytag 52980 Apr 21 20:09:33 [dnsmasq] reply gentoo.org is DNSKEY keytag 46873 Apr 21 20:09:33 [dnsmasq] validation result is BOGUS Apr 21 20:09:33 [dnsmasq] reply 546330.bugs.gentoo.org is Apr 21 20:09:33 [dnsmasq] reply bugs-gossamer.gentoo.org is Apr 21 20:09:33 [dnsmasq] reply gannet.gentoo.org is 204.187.15.4 --- Maybe it is local issue of the dns I am using (I have no access to it), but maybe there is a issue at infra. Regards, Alon Bar-Lev.
[gentoo-dev] New sysfs based battery monitor widget for kde
Hi, I had some time to resolve the long outstanding issue I had with loosing upower to systemd. The only feature I personally had was the battery monitor stopped working, yes, I did not install pm-utils either... So after few times my battery went empty while I worked... decided that enough is enough and I need to learn how to write kde plasmoid. Documentation of kde plasmoid is not great, especially when using scripts, but after looking on various of valid examples, I managed to produce a new battery monitor[1][2] which is very simple and looks decent. All that it does is once per interval read the /status and /capacity and update the images within widget, it does not create a load nor adds dependencies. Install to user home by: $ plasmapkg -i kbatsysfs-1.0.0.plasmoid I hope someone will find this useful, Alon [1] http://kde-apps.org/content/show.php/kbatsysfs?content=168436 [2] https://github.com/alonbl/kbatsysfs
Re: [gentoo-dev] Re: git security (SHA-1)
On Sun, Sep 21, 2014 at 2:13 PM, Ulrich Mueller wrote: >> On Sun, 21 Sep 2014, Michał Górny wrote: > >> Do you really consider keeping a key open for machine signing >> somewhat secure? > > You mean, as compared to manifests (or commits) signed by 250 > different developers' keys? > > Ulrich Unrelated to git discussion, in the past we discussed co-sign, so that developer signs using short term key, and infra co-sign using long term key if the developer sign is valid at that time. Portage infra should relay on infra key signature, while tractability is available up to developer. I will take the opportunity of responding to write that my preference is to keep the manifest signature detached from the version management technology, with no git specific feature usage, nor git specific development (signed hrefs). It will enable much easier use of each technology, one for file management and the other for security, while enabling rebase and reorg without effecting integrity. If we can establish co-sign I will be very happy. Regards, Alon
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default
Hi, I do not know if this came up... glibc must be bumped first[1]. Alon [1] https://bugs.gentoo.org/show_bug.cgi?id=504032
Re: [gentoo-dev] Re: Banning modification of pkg-config files
On Mon, May 12, 2014 at 9:48 PM, Peter Stuge wrote: > 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: ' for >> static linking, there has been multiple bugs lately, > > I honestly don't think that it's Gentoo's place to fix those issues. > > Just error out. Make users complain to upstream when upstream has a > problem. Don't hide the problem and amass a huge support workload. > >From my experience, there are lots of issues in upstream projects' build system, most of the these result from lack of knowledge. Up until now, downstream patches that were actually used by users found their way better into upstream than just complaining that stuff breaks, as upstream honestly does not have the knowledge to fix. It also gives a chance to test them properly before submitting. There are projects that will not accept any patch regardless of the problem it solves, unless it is for their own favour distribution and packager, so not providing solution for our users does not makes sense to me. Regards, Alon
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs wrote: > > On Fri, Feb 28, 2014 at 09:57:15PM +, David Leverton wrote: > > William Hubbs wrote: > > > The reason the split happened is pretty straight forward, and every other > > > "justification" for continuing it was come up with after the fact. > > > > I keep hearing this, but I really don't see how it's relevant. I'm sure > > you'll find lots of things in your life that you use for some purpose > > other than what they were originally invented for¹, and there's no > > reason why /usr should be any different. All that matters is whether or > > not the newer reasons for having separate /usr actually provide a benefit. > > And I would argue that the maintenance cost of having separate /usr in a > general sense is much higher than the benefit it provides. > > The problem with it is that it is next to impossible nowadays to define > what should go in / vs what should go in /usr. > > William Now it is difficult as too much time it was ignored. In the past it was quite simple, everything that requires a server to reach default runlevel. The problem is that instead of telling users: "If you are using special user mode devices, such as bluetooth keyboards, please make sure /usr is mounted at boot", we enforce all that configuration, so now initramfs should contain all that once was / with much harder maintenance. Alon
[gentoo-dev] Commit into profiles fails
Hi, Long time since I done this... maybe something had been changed. $ cvs commit -m "thirdpartymirrors: fixup gnupg mirros, bug#494842, thanks to Ben Kohler" cvs commit: cannot exec /var/cvsroot/CVSROOT/cvslogdate: Permission denied cvs commit: cannot exec /var/cvsroot/CVSROOT/checkgroup.pl: Permission denied cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! It looks like something is wrong in remote, but I see people succeed in committing today... What's wrong? Thanks, Alon
Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC
On Wed, Dec 11, 2013 at 10:41 PM, William Hubbs wrote: > > All, > > We got a request from Debian to rename the "rc" binary of OpenRC due to > a naming conflict they have. They have a port of the at&t plan 9 shell, > which has a binary named "rc" as well[1]. > > My thought is to rename our "rc" to "openrc", since that would be > unique. > > I know at least one thing that will break is everyone's inittab, so > should I sed their inittab in our live ebuild or expect them to fix it > and give a warning? I know that once OpenRC with this change is > released, it will need to probably be p.masked until there is a new > release of sysvinit that updates the inittab. > > I'm not sure what else will break. > > Does anyone have any ideas wrt other things to look for, or should I > make the changes upstream and have people let us know what > else breaks? are you going to rename also rc-service and rc-update? > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=493958
Re: [gentoo-dev] open season on other-dev's packages -- policy change?
On Fri, Nov 1, 2013 at 10:06 PM, Peter Stuge wrote: > 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 effort of all ways to implement the fix in my own system. >> > Optimize for the (desired) common case. Anything else pushes >> > contributions away. >> >> Just for me to understand, do you suggest everyone can commit into >> the tree? >> >> Or do you want to join in as a developer? >> >> Or something else? > > I'm discussing the policies for Gentoo developers, stating my > preferences and opinions under the assumption that my contributions > to such a discussion are receivable and maybe even appreciated > regardless of whether I ever become a developer or not. > Sure, but I may missed what you recommended... not exist in the thread... Blind commit without review of maintainer? More maintainers? More proxies? I understand that you want to shorten the time between bug opening and commit... but I do not understand what you suggest... > > //Peter >
Re: [gentoo-dev] open season on other-dev's packages -- policy change?
On Fri, Nov 1, 2013 at 9:53 PM, Peter Stuge wrote: > 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 all ways to implement the fix in my own system. > Optimize for the (desired) common case. Anything else pushes > contributions away. Hi, Just for me to understand, do you suggest everyone can commit into the tree? Or do you want to join in as a developer? Or something else? Regards, Alon Bar-Lev.
Re: [gentoo-dev] systemd team consensus?
On Mon, Aug 12, 2013 at 2:08 AM, Gilles Dartiguelongue wrote: > Le dimanche 11 août 2013 à 22:09 +0300, Alon Bar-Lev a écrit : >> On Sun, Aug 11, 2013 at 9:59 PM, Tom Wijsman wrote: >> > On Sun, 11 Aug 2013 13:29:16 -0500 >> > William Hubbs wrote: >> > >> >> You may ask why I have offered patches instead of just fixing the >> >> ebuild since I am a team member. That is because even team members >> >> aren't allowed to touch bugs assigned to syst...@gentoo.org [1], >> > >> > Well, if there are conflicts within a team then I can agree that no >> > member is allowed to touch the bug without a collaborative decision; >> > but from what it appears this bug has been handed in a way that one >> > member appears to take all decisions and the other member has nothing >> > to say. In particular, comments 5 and 11 change the state of the bug >> > without giving any reasoning about why that change in state was made; >> > this is unacceptable, it gives us no reason to believe the state change. >> >> This is expected, as it is similar to how systemd/gnome is managed :) > > I hope you are not talking about the Gentoo Gnome team as this would be > very wrong. Every team member is heard on the team. I was talking about the designated upstreams. Regards, Alon
Re: [gentoo-dev] systemd team consensus?
On Sun, Aug 11, 2013 at 9:59 PM, Tom Wijsman wrote: > On Sun, 11 Aug 2013 13:29:16 -0500 > William Hubbs wrote: > >> You may ask why I have offered patches instead of just fixing the >> ebuild since I am a team member. That is because even team members >> aren't allowed to touch bugs assigned to syst...@gentoo.org [1], > > Well, if there are conflicts within a team then I can agree that no > member is allowed to touch the bug without a collaborative decision; > but from what it appears this bug has been handed in a way that one > member appears to take all decisions and the other member has nothing > to say. In particular, comments 5 and 11 change the state of the bug > without giving any reasoning about why that change in state was made; > this is unacceptable, it gives us no reason to believe the state change. This is expected, as it is similar to how systemd/gnome is managed :) Regards, Alon Bar-Lev.
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Sat, Aug 10, 2013 at 1:59 PM, Rich Freeman wrote: > On Sat, Aug 10, 2013 at 6:51 AM, Patrick Lauer wrote: >> not must, but if I choose to run the official supported configuration, >> well, then telling me to go to an unsupported state is quite confusing >> and sends the wrong signal. >> > > There is no one official supported configuration of Gentoo. Nobody > has to agree to make systemd an official supported configuration, > because OpenRC isn't an official supported configuration either. At > least, not in the way that the terms seems to be being used. There is > no policy that requires packages to run when OpenRC is the service > manager, and there is no policy that requires packages to supply an > OpenRC init.d script. Every long lawyer like response make me re-check my sanity. The split of openrc was done by Roy in the past to be usable by other audiences, especially busybox and *bsd configurations. OpenRC is baselayout-1, just packaged in different way. Gentoo, well up to now, did have a policy that packages should support the baselayout which was single one, no alternatives where formally supported. The fact that OpenRC is now provided as own package (technical bit) could not have changed the policy of providing stable coherent solution for users. The fact that someone decided that init system may be virtual means nothing if the implications of users and developers were not been understood. Of course it matches the gnome and affiliated vendor agenda but for that do we break the entire tree and produce extra load for developers who maintain unrelated packages? Alon
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 5:57 PM, Chí-Thanh Christopher Nguyễn wrote: > Alon Bar-Lev schrieb: >>> I think there may be a misunderstanding here. He only said that if you >>> want to run Gnome 3.8, then switch to systemd. Because the Gnome team >>> will not support any other configuration. >>> >>> He did not say that everyone should install systemd, nor that you need >>> to support such a configuration. >> So users will have gnome working but not any other component? How can >> this a good service for users? > > I am not sure what you mean by that. But every developer is free to > commit and support in Gentoo whatever package he wishes to, within > limitations set by policy. > And when a package is 30 days in tree and there is no objection from QA > or security teams then it can go stable. This is so narrow interpretation of the policy. You talk about a process, and user do not care about the process. 30 days? and what if a user has an issue 31 days after? And what if QA decides that now systemd must be supported? so we delay stabilization? People here tend to forget that Gentoo is not just ebuilds, but also an organization which requires a policy for the sake of its *USERS*. Regards, Alon
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 5:44 PM, Chí-Thanh Christopher Nguyễn wrote: > Alon Bar-Lev schrieb: >> On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman wrote: >>> On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer wrote: >>>> You just removed the upgrade path for users. >>>> >>> Just install systemd. There really isn't any practical alternative. >>> Gentoo with systemd is as Gentooish a configuration as Gentoo with >>> OpenRC, or Gentoo with libav, or Gentoo with emacs. >> Again, I repeat my-self. >> >> Please stop writing these statements! >> >> There was no decision to support Gentoo using any other layout than >> openrc (baselayout). > > I think there may be a misunderstanding here. He only said that if you > want to run Gnome 3.8, then switch to systemd. Because the Gnome team > will not support any other configuration. > > He did not say that everyone should install systemd, nor that you need > to support such a configuration. So users will have gnome working but not any other component? How can this a good service for users?
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 4:49 PM, Samuli Suominen wrote: > On 09/08/13 15:36, hasufell wrote: >> >> On 08/09/2013 12:27 PM, Rich Freeman wrote: >>> >>> On Fri, Aug 9, 2013 at 5:30 AM, hasufell wrote: >>>> >>>> On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote: >>>>> >>>>> It is not a regression if a new version of gnome mrequires systemd >>>>> and does not work with OpenRc; it is a design choice. >>>> >>>> >>>> We are not just talking about random ebuild features here that have been >>>> dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a >>>> _regression_. >>> >>> >>> How does not supporting OpenRC matter for Gentoo? >> >> >> The question puzzles me. For one it is >> * an implementation of virtual/service-manager which is in @system >> * it is the default init system in stage3 >> * OpenRC is developed by gentoo devs, which means we especially want to >> make/keep it a usable tool. If we can't, then there is a regression. It >> doesn't matter whose fault it is. This is not about blame. > > > baselayout-1, then later baselayout-2 and OpenRC were all created because > there was an need and no suitable ready solutions > systemd however is starting to look like a viable ready solution to switch > to > it's definately not an regression to switch to actively maintained software, > it's more of an improvement because OpenRC has been stalled ever since Roy > stopped hacking on it (all work put in by vapier, WilliamH, and others is of > course appericiated) > you know it's true if you have been with gentoo enough long > At least we know what ssuominen thinks... some prople are trying to hijack the Gentoo project at the excuse of Gnome to switch into specific vendor solution, and be on its mercies from now on. This was the exact plan of whoever put all these $$ in udev/systemd/gnome/fedora and effect the entire ecosystem, and slowly own the entire solutions. As Linux userland become more and more monolithic per the plan of that vendor, and if we yield, there will be no real difference between Fedora and Gentoo, so what have we accomplished? There come the new Microsoft and conquered the free open source world using $$ and ambassadors. What we basically say is that Gentoo cannot have their own agenda and now submit to dictation of a single vendor of how Linux should be managed and run. To provide good service to our users we need a clear stand, what will developers (throughout the tree) will be maintaining. If a user installs a component he does expect it to work and maintained. And we cannot force all developers to support two different layouts, and we cannot allow developers to support layout of their choice, as users will get a totally broken solution, because of the aspirations of developer/herd they get different level of support. I don't care if systemd is worked on by people, however it must be clearly mark as unstable as long as there is no decision to switch. Regards, Alon Bar-Lev
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman wrote: > On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer wrote: >> You just removed the upgrade path for users. >> > > Just install systemd. There really isn't any practical alternative. > Gentoo with systemd is as Gentooish a configuration as Gentoo with > OpenRC, or Gentoo with libav, or Gentoo with emacs. Again, I repeat my-self. Please stop writing these statements! There was no decision to support Gentoo using any other layout than openrc (baselayout). There is *HUGE* difference between optional components and core components. Claiming that Gentoo can use alternate layout is same as alternate that freebsd port is stable or that intel icc can be used as compiler. It has broad implications, which is far from the actual component usage or its own dependencies. If you have the agenda to switch to systemd, and you hide your intention in the argument of supporting multiple layouts, please do not hide and state so clearly. But do not claim that Gentoo with different layout than baselayout is still formal Gentoo, and is supported by the Gentoo developers. Regards, Alon Bar-Lev.
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 9:58 PM, Samuli Suominen wrote: > On 08/08/13 21:23, Alon Bar-Lev wrote: >> >> On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen >> wrote: >>> >>> On 08/08/13 20:57, Alon Bar-Lev wrote: >>>> >>>> >>>> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman wrote: >>>>> >>>>> >>>>> Stability is about the quality of the ebuilds and the user experience >>>>> in general. It is not a statement that all Gentoo developers think >>>>> that the package is useful. Many would say that nobody should be >>>>> using MySQL/MariaDB for production work, but that has nothing to do >>>>> with its stability as a package either. >>>> >>>> >>>> >>>> This is not entirely correct. >>>> >>>> If from now on, a bug with systemd of new version of a package blocks >>>> that package stabilization, it means that all developers must support >>>> systemd. So having systemd stable is a decision that should be made by >>>> the entire community, and have huge overhead on us all. >>> >>> >>> >>> That's not really true with systemd when the unit files (and related) are >>> in >>> a format that they can be carried also by upstream and can be shared >>> between >>> distributions. They are comparable to logrotate or bash-completion files. >>> >>> You don't necessarily use distcc, ccache, clang, ... and yet you let >>> people >>> compile packages you maintain using them. >>> You don't necessarily use uclibc, yet you allow users to compile the >>> packages against it and expect them to file bugs if something is broken. >>> You don't necessarily use selinux and yet support building against >>> libselinux where possible. >>> You don't necessarily use zsh as your shell and yet let zsh-completion >>> files >>> to be installed when requested. >>> >>> Yet any of the mentioned packages can be stabilized, what makes systemd >>> so >>> special that it can't follow the same rules as other packages? >> >> >> logrotate, autocompletion are not functional dependencies. >> >> uclibc - is not mainline, people who use it for embedded are aware the >> it may be broken every bump. >> >> autocompletion, distcc, ccache etc... are optional components which >> can be disabled, while having usable system until issue is resolved. >> >> selinux - if a package breaks selinux it will be reverted (if >> maintainer care about his users) until resolution is found. >> >> as you may have unusable system if a bump does not support specific >> stable init layout, you do expect rollback similar to libselinux >> issue. init layout is not optional package nor optional feature, it >> how the system operates. > > > > > I guess that's why we call Gentoo a meta-distribution instead of > distribution since we are not bound to one certain type of system operation > like eg. Debian is or any other binary distribution is. As this alternate layout did not exist at that time, I don't think it had not been the reason for this term.
Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations? (was: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8)
On Thu, Aug 8, 2013 at 9:47 PM, Tom Wijsman wrote: > On Thu, 8 Aug 2013, 20:57:18 +0300 > Alon Bar-Lev wrote: > >> If from now on, a bug with systemd of new version of a package blocks >> that package stabilization, it means that all developers must support >> systemd. So having systemd stable is a decision that should be made by >> the entire community, and have huge overhead on us all. > > On Thu, 8 Aug 2013 21:23:29 +0300 > Alon Bar-Lev wrote: > >> selinux - if a package breaks selinux it will be reverted (if >> maintainer care about his users) until resolution is found. >> >> as you may have unusable system if a bump does not support specific >> stable init layout, you do expect rollback similar to libselinux >> issue. init layout is not optional package nor optional feature, it >> how the system operates. > > Reverting and rolling back isn't really the good way going forward, it > implies waiting and that's going to certainly make people sad because > they need to wait for something that doesn't affect the package > combination that the user uses; we need to look at a different approach. > > What if we could stabilize package combinations instead of packages? Or > rather, when during stabilization it was found that a certain package > combination doesn't work, exclude that combination from stabilization? > > This is a concept that shouldn't be too hard to implement; it could > even be implemented using existing USE flag mask opportunities, although > we probably would have to figure out a solution for those occasions > where an USE flag is not present. > > Perhaps specify in the ebuild that the package shouldn't be regarded as > keyworded for a certain dependency? > > Since it's just an idea that jumps to mind, I'm not sure if this is the > best approach to do this; but we'll probably want to start brainstorming > in this field if this is going to stay or become a big problem. > > Multiple implementations shouldn't block Gentoo going forward. > > We need to come up with a solution similar to the above to avoid this... This is called a 'profile'. You can have systemd and openrc profiles, and then able to mask specific packages... It is a technical solution, but won't make lives much easier in this regard. Regards, Alon Bar-Lev
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 9:26 PM, Tom Wijsman wrote: > On Thu, 8 Aug 2013 20:57:15 +0300 > Alon Bar-Lev wrote: > >> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman wrote: >> > Stability is about the quality of the ebuilds and the user >> > experience in general. It is not a statement that all Gentoo >> > developers think that the package is useful. Many would say that >> > nobody should be using MySQL/MariaDB for production work, but that >> > has nothing to do with its stability as a package either. >> >> This is not entirely correct. >> >> If from now on, a bug with systemd of new version of a package blocks >> that package stabilization, it means that all developers must support >> systemd. > > This is not entirely correct either. > > Not necessarily, one can opt to mask this combination and stabilize > this combination later by removing the mask; it's an implementation > detail, but certainly there's no need to imply that they must. > > Another example is that when you add a package to the tree, you are not > required to initially commit both an OpenRC unit and systemd service > file; you are suggested to provide them for the convenience of the > user, if you don't know systemd service files then you aren't obligated > to support them as far as I am aware of. There are people that can help > you in supporting them as well as following up on their bugs; and if > you wonder, the ebuild change to support a systemd service is trivial. 1. There is huge difference between adding a new package that lacks feature and maintaining existing features. 2. When people say that something is trivial, my immediate reaction is fear. systemd is far from being trivial, but let's don't get into that one again. > >> So having systemd stable is a decision that should be made by >> the entire community, and have huge overhead on us all. > > systemd is already stable, it has not found to be an huge overhead; > whether it should have been a decision made by the entire community, I > doubt it, it neither seems to show any problematic wide spread problems. > >> So apart of the politic message, there are implications of maintenance >> efforts, stabilization efforts. > > Agreed; though, they are quite small and shouldn't be a bother. It's > worth doing these small implications to provide choice to our users... > >> I appreciate the discussion at debian, it is not wise to support [I am >> adding: at stable] more than one solution for layout. > > Can you share the link? I'm yet to see good reasoning why it's not wise. Latest[1], you can search for "debian openrc" for more. [1] http://www.marshut.com/rnvrp/survey-answers-part-3-systemd-is-not-portable-and-what-this-means-for-our-ports.html > -- > With kind regards, > > Tom Wijsman (TomWij) > Gentoo Developer > > E-mail address : tom...@gentoo.org > GPG Public Key : 6D34E57D > GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen wrote: > On 08/08/13 20:57, Alon Bar-Lev wrote: >> >> On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman wrote: >>> >>> Stability is about the quality of the ebuilds and the user experience >>> in general. It is not a statement that all Gentoo developers think >>> that the package is useful. Many would say that nobody should be >>> using MySQL/MariaDB for production work, but that has nothing to do >>> with its stability as a package either. >> >> >> This is not entirely correct. >> >> If from now on, a bug with systemd of new version of a package blocks >> that package stabilization, it means that all developers must support >> systemd. So having systemd stable is a decision that should be made by >> the entire community, and have huge overhead on us all. > > > That's not really true with systemd when the unit files (and related) are in > a format that they can be carried also by upstream and can be shared between > distributions. They are comparable to logrotate or bash-completion files. > > You don't necessarily use distcc, ccache, clang, ... and yet you let people > compile packages you maintain using them. > You don't necessarily use uclibc, yet you allow users to compile the > packages against it and expect them to file bugs if something is broken. > You don't necessarily use selinux and yet support building against > libselinux where possible. > You don't necessarily use zsh as your shell and yet let zsh-completion files > to be installed when requested. > > Yet any of the mentioned packages can be stabilized, what makes systemd so > special that it can't follow the same rules as other packages? logrotate, autocompletion are not functional dependencies. uclibc - is not mainline, people who use it for embedded are aware the it may be broken every bump. autocompletion, distcc, ccache etc... are optional components which can be disabled, while having usable system until issue is resolved. selinux - if a package breaks selinux it will be reverted (if maintainer care about his users) until resolution is found. as you may have unusable system if a bump does not support specific stable init layout, you do expect rollback similar to libselinux issue. init layout is not optional package nor optional feature, it how the system operates. >> So apart of the politic message, there are implications of maintenance >> efforts, stabilization efforts. > > > Just the normal efforts. > > >> >> I appreciate the discussion at debian, it is not wise to support [I am >> adding: at stable] more than one solution for layout. >> >> Regards, >> Alon Bar-Lev. >> > >
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman wrote: > Stability is about the quality of the ebuilds and the user experience > in general. It is not a statement that all Gentoo developers think > that the package is useful. Many would say that nobody should be > using MySQL/MariaDB for production work, but that has nothing to do > with its stability as a package either. This is not entirely correct. If from now on, a bug with systemd of new version of a package blocks that package stabilization, it means that all developers must support systemd. So having systemd stable is a decision that should be made by the entire community, and have huge overhead on us all. So apart of the politic message, there are implications of maintenance efforts, stabilization efforts. I appreciate the discussion at debian, it is not wise to support [I am adding: at stable] more than one solution for layout. Regards, Alon Bar-Lev.
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani wrote: > Moreover, the lvm problem is caused by a very ancient and ill decision > about doing what upstream tells you to avoid: have mdev in the > initramfs and udev on the final pivot rooted system. This was just > looking for troubles but the smarties at the time decided that they > knew better... And now, tadam, the bug is served... > People can use genkernel-next, which comes with _proper_ udev support > (see --udev). I won't comment about the entire gnome monolithic windows like, vendor controlled system that we cooperate with. But the above statement is way too much... there should be nothing wrong in having mdev during boot. initramfs should be simple as possible and busybox provides this functionality well. The problem is in udev not in any other component, that probably expects now to run first and have total control over the boot process. I hope eudev does not suffer from this. If genkernel will start using udev instead of busybox, it will probably be the last day of me use it. I am just waiting for the point in which you claim that systemd should be run at initramfs, because of the dependency lock-in, so you have almost the entire system within initramfs. Regards, Alon
Re: [gentoo-dev] renaming gentoo-oldnet
On Sun, Aug 4, 2013 at 11:37 PM, William Hubbs wrote: > > Doug and Brian, I'm going to reply in a little more detail. > > On Sat, Aug 03, 2013 at 07:38:04PM -0700, Brian Dolbec wrote: > > On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote: > > > On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs wrote: > > > > On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote: > > > >> On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs > > > >> wrote: > > > > > >> OK... so gentoo-networking? or just come up with own name? > > > >> best-networking? > > > > > > > > > You and I have had this talk more times than I can remember at this > > > point. Using the name "oldnet" sucks and was one of the worst choices > > > possible. Looking through our IRC chats, I had also suggested > > > gentoo-networking. > > I thought about gentoo-networking, but that sucks in a way too because > it implies that everyone on gentoo should be using it. > > That's not quite right because we have at least five network stacks I > can think of off the top of my head, and OpenRc upstream supports > another. > > - OpenRc upstream supports newnet, which I have played with, and I > believe people on Gentoo are using successfully. > - what we have been calling the oldnet stack, which most gentoo users > have been using. > - dhcpcd in standalone mode. > - wicd > - NetworkManager > - badvpn I do not understand... the 'old net' which is actually gentoo networking for years, are fully functional script to manage and create a lot of configurations, and one of the advantages we have at Gentoo over other distributions. The only reason why this is called old net is because Roy switched to *BSD. What you call new net requires vast knowledge in network tools usage and interaction, which makes life very difficult. Some examples I managed to document: http://alonbl.tropicalwikis.com/wiki/Gentoo/Firewall_Using_Firehol http://alonbl.tropicalwikis.com/wiki/Gentoo/OpenVPN_Server http://alonbl.tropicalwikis.com/wiki/Gentoo/OpenVPN_Non_Root http://alonbl.tropicalwikis.com/wiki/Gentoo/Vpnc_Non_Root http://alonbl.tropicalwikis.com/wiki/Gentoo/VM_Tap_Networking http://alonbl.tropicalwikis.com/wiki/Gentoo/PPP_Client http://alonbl.tropicalwikis.com/wiki/Gentoo/PPPoE_Client > As I have said before, none of this is an attempt to kill or deprecate > anything. It is just re-arranging things by moving the old gentoo > network stack into its own package. There are no plans to stop you from > using it if you want to use it. There is definitely nothing being said > here about the state of OpenRc in general. >From behind the words it indeed looks like there is a change coming. Alon
Re: [gentoo-dev] renaming gentoo-oldnet
On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs wrote: > Hi all, > > I'm splitting the thread because this is a separate subject. > > On Sun, Aug 04, 2013 at 12:59:56AM +0300, Alon Bar-Lev wrote: >> I do understand why Roy refer this as oldnet... but why in Gentoo do >> we keep the term old? The functionality of these script is huge, and >> is better than most distros out there. Do we want keep users out of >> it? are we going to obsolete this huge work? If we don't I suggest to >> remove the 'old' implication, to something like openrc-gentoo-net. > > Actually the plan is to generalize it so that it works with other init > systems. Right now it is very tightly integrated with OpenRc, but there > is interest in changing that, so adding openrc to the name would be > misleading eventually. OK... so gentoo-networking? or just come up with own name? best-networking? However, I do not understand how you can port it without changing the notations... or lowering features... example: rc_net_*_provide, rc_net_*_need, or the rc_config, rc_use, rc_net_*_provide="!net" etc... Do you think systemd users can understand that /etc/conf.d/net is actually a shell script? I hope this is not going to be eliminated, as I use it a lot. Regards, Alon Bar-Lev.
Re: [gentoo-dev] OpenRc-0.12 and gentoo-oldnet-0.1 keywording question
On Sun, Aug 4, 2013 at 12:44 AM, William Hubbs wrote: > All, > > one thing that is going to be different about OpenRc-0.12 is the oldnet > scripts (net.* and /lib*/rc/net/*) are going to be split out into their > own package, gentoo-oldnet-0.1. This will be brought in by a pdepend > initially to make sure everyone who doesn't have newnet gets the > package. Hi, I do understand why Roy refer this as oldnet... but why in Gentoo do we keep the term old? The functionality of these script is huge, and is better than most distros out there. Do we want keep users out of it? are we going to obsolete this huge work? If we don't I suggest to remove the 'old' implication, to something like openrc-gentoo-net. Regards, Alon Bar-Lev.
[gentoo-dev] Goodbye
Hello, I guess I am tired of fighting with people here. I am too old for this crap. There are few brutal developers here that make Gentoo a terrible place to be. Well... I can handle few developers, but when devrel enters the picture with arguments such as "volunteers can do crappy job as long as they have fun" enough is enough. I signed-up to work on distribution if I have fun in the process it is great! But always keep in mind the delivery I provide to users. Gentoo has some fundamental issues, the obvious one is lack of leadership. There is *NOBODY* that formally responsible or cares about the delivery Gentoo (AS A WHOLE) provide to its users. The council is just a political body that discuss the void issues. As a result the laud and brutal developers dictate the tune. With no proper mechanism to decide if a decision that was taken aligns with Gentoo goals. The devrel process is ridiculous, as proxy between developers without ability to determine anything does not help anyone. During the short time I was around Gentoo lost some of the best developers that were around, due to similar reasons. If Gentoo community cannot provide its own goals, at least it should embrace standards. Compliant to standards may resolve many conflicts. Roy worked hard to make Gentoo POSIX shell compliant, but this was not accepted, but imagine fully Gentoo work with busybox based system, isn't this an advantage we have? especially on small systems. I appreciate flameeyes work on reducing the system size, I am aware how hard it is. There are new violations of HFS in Gentoo, but nobody cares. Jacub, one of the best developers around that actually cared about the service we provide to our users was suspended while trying to do so, and now he is not active anymore. There are some more examples... The brutal developers remain, the quiet leave. Gentoo is built on a lot of inexperienced students, but the backbone of core developers with real-life experience is very weak. I think that current approach of the developers community will not able to resolve this, as a result Gentoo community will not mature. Gentoo has a great piece of technology (portage), this is unique and with the right leadership may be the tool to make Gentoo more stable and popular, as a result extending the user community and gain more resources. But leadership derives goals, goals derive complaint, complaint derives means of enforcement. None of these currently available in the community. Personal note on leadership: vapier - you are good, so good that many envy you. But this does not give you the right to not being nice. You are on of the few people here that can take at least partially resolve the leadership issue. With a little patience and care. (Just to make it clear: I am not leaving because of vapier). Packages to reassign: mobile: dev-libs/libx86 sys-power/suspend sys-power/hibernate-script antivirus ./sys-fs/dazuko misc: net-misc/openvpn media-sound/mp3unicode I am available at email:[EMAIL PROTECTED] Have fun, Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: qemu -> add gcc-3.x dependency
On 5/5/08, Jan Kundrát <[EMAIL PROTECTED]> wrote: > Hi Enrico, it is usually a good idea to search through the Bugzilla before > asking for some feature, chances are that it has been already requested (in > this case, you're looking for bug 190102). FYI, at least some of qemu's > features were ported to gcc4 -- for example, see the kvm-qemu ebuild from > bug 157987. I also waiting for gcc-4 enabled qemu for long time... The problem that "emerge --emptytree world" will not work when packages are compiled in different gcc versions. The kvm-qemu is not relevant if you don't have the hardware. One solution I saw is to compile gcc-3 as part of the qemu build process, and make the qemu use this gcc-3 instance. This way you can have qemu up and running while the system is configured for gcc-4. It is very disappointing that upstream does not allow gcc-4 configuration so long after gcc-4 release. Alon.
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On 4/30/08, Fabian Groffen <[EMAIL PROTECTED]> wrote: > I think in that sense Cygwin is more Open Source, because how you get > the primary shell/environment is available too. However, for me that > doesn't matter, as the OS itself is inherently non-free in that sense, > so that's what you have to accept first thing anyway. I separate operating system and applications... Just like you run on HPUX or AIX... There is Windows. > Just for your information, we don't do stages at the moment, not in the > forseeable future from my point of view either. Binpkgs are in the > planning. In general we just do a full bootstrap, on Interix you need > extra help from "prefix-launcher". This is sad... I would really like to see fully operating portage on Windows... It was more important to me in the past when I actually used this OS... I this sense [1] was a great idea! You could always use quickpkg to extract binaries. Alon. [1] http://gentoocygwin.sourceforge.net/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On 4/30/08, Fabian Groffen <[EMAIL PROTECTED]> wrote: > On 30-04-2008 19:51:42 +0300, Alon Bar-Lev wrote: > > On 4/30/08, Denis Dupeyron <[EMAIL PROTECTED]> wrote: > > > It's my pleasure to introduce Markus Duft (mduft) as a new developer. > > > He will go among us under the name of mduft, and will work in the > > > Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that > > > means Gentoo on Win32. > > > > Welcome! > > > > I will love to see Windows support via cygwin and not commartial product. > > Something like [1], [2]. > > > Interix is free and these days bundled with Windwows, IIRC. I couldn't understand it from [1], anyway the source is unavailable right? > Why do you want it to run on Cygwin? (Honest question...) It is the only project I know providing good support for POSIX Windows platform while having Open Source license. But if you are correct and a good POSIX layer is provided built-in in Windows, I will be happy to see stage3 for Windows. Alon. [1] http://www.interix.com/products_services.htm -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On 4/30/08, Denis Dupeyron <[EMAIL PROTECTED]> wrote: > It's my pleasure to introduce Markus Duft (mduft) as a new developer. > He will go among us under the name of mduft, and will work in the > Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that > means Gentoo on Win32. Welcome! I will love to see Windows support via cygwin and not commartial product. Something like [1], [2]. Alon. [1] http://gentoocygwin.sourceforge.net/ [2] http://gentoo-wiki.com/HOWTO_Gentoo_on_Cygwin -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New global USE flag: keyring
On 4/20/08, Gilles Dartiguelongue <[EMAIL PROTECTED]> wrote: > for what it's worth, as a gnome dev I didn't see any convincing > arguments as to why it should be renamed. Gnome makes things optional > for other to reuse (like xfce) but afaik no other "keyring" like > programs are optional deps of another package in portage. Let's not cast > a simple change into breakage for users already using it (even in > stable, and yes I'm lazy :D). Lazy is the word. I cannot argue with this one, I just know that it won't be the gnome herd who do the work when the time come to fix this (resolve conflict). The gnome herd will re-introduce the lazy ticket, and make other herd use yet another confusing USE flag. This is not the right way to maintain long term constants. You asked for objections... You got some. You can leave this local USE flag, and stay with generic term. Or you can rename it when it goes global so it have proper name. You can also ignore this and force gnome onto all users. Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: New global USE flag: keyring
On Sun, Apr 20, 2008 at 7:06 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: > I'd say we should convert it to a global use flag now with a good > description and change it to gnome-keyring later in case we really have a > package which needs 'keyring' for something else. If we know there may be a future problem, why make the next *VALID* addition perform extra work? This is gnome specific feature, should have gnome explicit mark. If we have keyring in KDE, or keyring in kernel or any other "generic" keyring. The extra work should be done now, so we have less conflict in future. Alon ���^�X�����(��&j)b�b�
Re: [gentoo-dev] Re: New global USE flag: keyring
2008/4/20 Peter Weller <[EMAIL PROTECTED]>: > On Sun, 2008-04-20 at 18:32 +0300, Ali Polatel wrote: > > Alon Bar-Lev yazmış: > > > I suggest gnome-something as it is gnome feature. > > > > How about gnome-keyring? :) > > > > Why? All the ebuilds currently using the 'keyring' use flag are using it > for gnome-keyring. As long as there is a proper description of the USE > flag, there should be no confusion caused. Because it may be confusing. As long as it is local flag for gnome packages, the gnome is implicit. If you want it to be global, gnome should be explicit. Alon
Re: [gentoo-dev] New global USE flag: keyring
This may be confusing with Linux key store. I suggest gnome-something as it is gnome feature. Alon On Sun, Apr 20, 2008 at 5:45 PM, Peter Weller <[EMAIL PROTECTED]> wrote: > Unless anyone has any objections, I'll magically turn 'keyring' into a > global USE flag tomorrow evening: > > [EMAIL PROTECTED] ~/gentoo/cvs/gentoo-x86/profiles $ grep ':keyring' > use.local.desc > app-crypt/seahorse:keyring - Enable gnome-keyring support for storing > passwords > app-text/evince:keyring - Enable gnome-keyring support for storing > passwords > gnome-base/gvfs:keyring - Enable gnome-keyring support for storing > passwords > gnome-extra/evolution-data-server:keyring - Enable gnome-keyring support > for storing passwords > media-sound/rhythmbox:keyring - Enable gnome-keyring support for storing > passwords > net-im/gossip:keyring - Enable gnome-keyring support for storing > passwords > net-im/telepathy-mission-control:keyring - Enable gnome-keyring support > for storing passwords > net-misc/twitux:keyring - Enable gnome-keyring support for storing > passwords > net-misc/vino:keyring - Enable gnome-keyring support for storing > passwords > [EMAIL PROTECTED] ~/gentoo/cvs/gentoo-x86/profiles $ > > -- > gentoo-dev@lists.gentoo.org mailing list > > -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On 3/24/08, Mike Frysinger <[EMAIL PROTECTED]> wrote: > how much do we want to help the user ? if they have USE=filecaps, then dont > perform any checking ? we'll need a kernel with file capabilities turned on, > otherwise the prog wont work unless it's setuid ... so do we perform checking > and drop the setuid bit on the post sly ? i'd prefer we just make the > filecaps desc verbose: dont set this unless you have new enough kernel with > options enabled, otherwise things may stop working properly as non-root. I also prefer descriptive warning and not runtime checks. Worse case scenario, system will be usable for root only. root can remove this USE flag and emerge --update --deep --newuse world. Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On 3/24/08, Mike Frysinger <[EMAIL PROTECTED]> wrote: > Diego and i were talking ... we're going to go with USE=filecaps because it's > so new and doesnt require the libcap library in order to work at runtime. > probably be worthwhile to put together a little eclass of functions to make > people's lives easier ... Great!!! You write eclass, me start patching ebuilds and open bugs against maintainers :) Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On 3/23/08, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > Why? A simple USE flag should be enough, if set use caps, if not use > > current. > > > A user turns the use flag on, the ebuild creates files using caps > rather than set*id, the package manager merges it by copying the file > and the installed file ends up with no caps and no set*id bit. File system attributes already supported for selinux. I also checked this with capabilities and it works with portage. Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [SECURITY] Minimizing the suid usage
On 3/23/08, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sun, 23 Mar 2008 20:21:29 +0200 > "Alon Bar-Lev" <[EMAIL PROTECTED]> wrote: > > linux-2.6.24 supports file based capabilities via: > > CONFIG_SECURITY_FILE_CAPABILITIES > > > > > This will provide more secured installation for users with a little > > effort, less usage of root user. > > > > What do you think? > > > Needs package manager support. Effectively this requires an EAPI bump, > since ebuilds need to know whether they can rely upon caps being > preserved across a merge or whether they have to degrade to a setuid > bit. Why? A simple USE flag should be enough, if set use caps, if not use current. Alon. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] [SECURITY] Minimizing the suid usage
Hello All, linux-2.6.24 supports file based capabilities via: CONFIG_SECURITY_FILE_CAPABILITIES This enables the use of filesystem attributes in order to store per executable capabilities list, more information at [1]. This enables improved security level for people who don't wish to move into SELinux or similar. I think a new global USE flags (or use current caps) may enable ebuilds to set correct capabilities on files. On my system at least: ping, ping6, tcpdump, wireshark, samba, ntpd, rlogin, vmware may enjoy this and drop the root suid. In order to make it simple for everybody, a new eclass may be introduced to force dependency on >=libcap-2 and provide some atoms. This will provide more secured installation for users with a little effort, less usage of root user. What do you think? Alon. [1] http://www.friedhoff.org/fscaps.html -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
Check out OpenRC it is baselayout successor and works great! On 2/29/08, Ed W <[EMAIL PROTECTED]> wrote: > Is it dead..? Is anyone still working on it? > > I have had a lot of success using it for linux vservers and in an > embedded build. Would really hate to see it stall though...? > > What are the big picture items still missing? Seems that it's close to > becoming a stable upgrade? I have filed a few minor bugs against it > (some more to come) - is there anything I can do to help progress > development further? > > Cheers > > Ed W > > -- > gentoo-dev@lists.gentoo.org mailing list > > -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Upcoming Infra maintenance/downtimes: anon{cvs,svn,git}, archives, bouncer, overlays
On 1/19/08, Mike Frysinger <[EMAIL PROTECTED]> wrote: > using https:// to secure your data here is the wrong way to go. if you have a > man-in-the-middle attacking you, they can do a lot more than inject crap into > your syncs, some of which you wouldnt even notice. for the topic at hand, > this topic does not matter i think. The https solves man-in the middle for svn/git sync. There is an option for rsync people (not to use it): http://bugs.gentoo.org/show_bug.cgi?id=130039 Best Regards, Alon Bar-Lev. -- gentoo-dev@lists.gentoo.org mailing list