[gentoo-dev] Re: Last rites: net-libs/libmirisdr, media-sound/deinvert, net-wireless/gr-m2k
On 3/16/22 18:01, Jakov Smolić wrote: # Jakov Smolić (2022-03-16) # -only ebuilds, various other QA issues (no python # 3.10, using deprecated EAPI, ...) # Removal on 2022-04-15. net-libs/libmirisdr media-sound/deinvert net-wireless/gr-m2k adding net-wireless/libm2k as well. This package was only added as a dep for gr-m2k.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: fcaps.eclass
On 02/19/15 06:38, Alexis Ballier wrote: > On Thu, 19 Feb 2015 19:34:28 +0800 > Patrick Lauer wrote: > >> On Thursday 19 February 2015 12:31:27 Alexis Ballier wrote: >>> On Wed, 18 Feb 2015 22:48:27 +0100 >>> >>> Michał Górny wrote: Dnia 2015-02-18, o godz. 16:11:53 "Mike Frysinger (vapier)" napisał(a): > vapier 15/02/18 16:11:53 > > Modified: fcaps.eclass > Log: > clarify USE=filecaps intention #540430 > > Revision ChangesPath > 1.11 eclass/fcaps.eclass Please commit the missing ChangeLog update and remember to update the ChangeLog after changing any eclass in any way. This is an official policy for any commits to the Gentoo repository [1] and a lack of consistency in entries to the ChangeLog is confusing to our developers and users. [1]:http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index. html >>> this policy is about packages; cvs log is *mch* better than any >>> global changelog for eclasses: who will dig into a thousand >>> changelog entries to find what changed in fcaps.eclass ? Noting in that policy limits it to packages. >>> >>> if you want changelogs in eclass/, make it per-eclass, like it is >>> already per-package. Our current policy is to enforce updating existing Changelogs at the lowest possible level. That means if you really feel strongly about a per-eclass Changelog that would be permissible per the policy. >>> >> >> We've had this discussion before ... so ... > > > what i remember of it is someone adding a ChangeLog file to eclass/ and > sending an email to ask people to fill it. Mind sharing a link ? > > I think I'll add ChangeLog to every category and ask people to fill it > whenever they make changes to a package in that category. This would > have the same level of usefulness as a ChangeLog in eclass/. This kind of comment isn't productive, let's stick to being productive. If you feel that the commit log is "good enough" then open a bug assigned to QA to remove the existing Changelog. If the existing Changelog is removed then our policy would be that it doesn't need to be updated anymore. Not sure how many people would need to sign off on that idea, but that would be the process. Thanks, Zero_Chaos signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Implicit system dependency
On 11/04/2014 08:16 PM, Michael Orlitzky wrote: > When I was taking my ebuild quizzes, I asked for someone to clarify the > implicit system dependency that we have enshrined in the devmanual: > > https://bugs.gentoo.org/show_bug.cgi?id=485356 > > There is... some agreement, but also special cases and special-special > cases that are folklore-only at this point. To me it seems like a fine > thing to ask the council to sort out, so I'm asking here for discussion. > > Can we come up with an idiot-proof list (or FLOWCHART, even!) of what > should and should not be excluded from *DEPEND? > > In my opinion, it's safe to ignore deps on glibc and gcc at this time, I personally don't ignore any other deps. On of my long term goals is to remove as much as humanly possible from the system set and replace it with the packages.default concept. I can't say we are far enough to actually do this yet, but that's why it's a long term goal. https://bugs.gentoo.org/show_bug.cgi?id=393445 -Zero signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Removing 'selinux? ( sec-policy/selinux-*)' from DEPEND
On 11/01/2014 03:36 PM, Sven Vermeulen wrote: > On Sat, Nov 01, 2014 at 01:52:57PM +0100, Michał Górny wrote: >>> Michał Górny told me on IRC that I might be approaching this incorrectly (or >>> at least, inefficiently). I was working on the massive bug-spree (right now >>> stopped around 22% of the packages to investigate) so I'm temporarily >>> holding off until I'm certain. >>> >>> The only change I want to instill on packages is to remove the USE="selinux" >>> specific dependency to a sec-policy/selinux-* package from the DEPEND >>> variable. So something like: >>> >>> DEPEND=" >>> foo >>> - bar >>> - selinux? ( sec-policy/selinux-bez )" >>> + bar" >>> >>> If I am allowed to do this change without revbumping, I can just stop making >>> massive bug reports and do the change(s) myself... >> >> You should have emphasized that the dependency will still be >> in RDEPEND. As I said with QA hat on, such a change is fine since it >> affects build-time dependencies only. People who installed the package >> already are not affected. > > Thanks. I'll do the necessary updates tomorrow then (without revbump) and > invalidate > the bug reports I already made. Just since you poked me on irc and I tend to yell at anyone who breaks to dep tree by making RDEPEND changes without revbump I agree with mgorny. I don't believe this change will cause any issues with the dep tree for people who aren't, or cannot, run dynamic deps. Please proceed to make your changes as desired, without revbump, and you may close your bugs. Thanks, Zero > > Wkr, > Sven Vermeulen > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Add gcc-specs-stack-check() to toolchain-funcs.eclass
On 10/12/2014 02:03 PM, Dan Douglas wrote:
> On Sun, Oct 12, 2014 at 11:22 AM, Anthony G. Basile
> wrote:
>> --- toolchain-funcs.eclass.orig2014-10-12 11:23:41.585182742 -0400
>> +++ toolchain-funcs.eclass2014-10-12 11:31:57.170205300 -0400
>> @@ -610,6 +610,12 @@
>> directive=$(gcc-specs-directive cc1)
>> return $([[ "${directive/\{!fstrict-overflow:}" != "${directive}" ]])
>> }
>> +# Returns true if gcc builds with fstack-check
>> +gcc-specs-stack-check() {
>> +local directive
>> +directive=$(gcc-specs-directive cc1)
>> +return $([[ "${directive/\{!fno-stack-check:}" != "${directive}" ]])
>> +}
>
> Am I missing something here? I don't see how any of the tests used in
> gcc-specs-* functions could possibly produce an output. The fact that this
> coincidentally works in Bash shouldn't be relied upon.
>
Portage specifically relies on and uses Bash. There is no
coincidence that we have a dep on bash, directly call bash (instead of
sh) and use things that don't necessarily work in other shells. This is
permitted and correct.
-Zero_Chaos
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Dropping GCC maintainership
On 10/05/2014 06:44 PM, Ryan Hill wrote: > Hey all, I'm stepping down as GCC maintainer. I haven't been reading > toolchain > bugmail since June, and keep telling myself I'll tackle it next weekend, which > never happens. To be frank, I'm kinda sick of Gentoo. I'm hoping it's > temporary but we'll see. In the meantime I don't want to be responsible for > holding up any work while I figure things out. > Thanks for your services, it's been great having you. I hope that you take a short break, and come back refreshed to have fun with gentoo after. -Zero signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Mix-in Support Tracker
On 09/17/2014 09:58 AM, Rich Freeman wrote: > There was a thread a while back about mix-in support and I think there > was genuine interest. For the most part we just need to do the work, > and the first step is identifying blockers. If some end up involving > PMS/etc then we may need to get the Council involved. > > Rather than hijacking every @system change discussion with this, I > created a tracker at: > https://bugs.gentoo.org/show_bug.cgi?id=523036 The funtoo mixin system has absolutely nothing to do with adding packages to stage3 that are not in @system. Primarily adding packages to stage3 (or stage4 if we choose to call it that) would only need us to agree on the packages.default bug: https://bugs.gentoo.org/show_bug.cgi?id=393445 The primary issue here is do we add the "default" packages to the world file or not. I'll provide an extremely biased reasoning for both sides: If we add packages to the world file, then the default programs won't be immediately eligible to depclean, and the user would have to manually ask portage to remove them if they don't want them. No package.provided hacks, just normal "emerge -C blah". The downside to this is that we would be shipping a stage with a populated world file. This solution provides a very simple opt out of the packages that the user doesn't want (just remove them) and no accidental removals. If we don't add packages to the world file, then the default programs will be immediately eligible to depclean, and may be accidently wiped EVERY time depclean is run unless the user does "emerge --noreplace blah" for every single package they want to keep. This solution may cause users to accidently depclean needed utilities from their systems and have difficultly getting them back. For instance if virtual/editor is removed from @system and moved to packages.default (it should be) then a depclean right after install would remove the system editor and leave the user unable to edit files until they rebuild it (assuming they don't need to edit any files like make.conf to do so). As I'm not a fan of crippling users by surprise, it should be obvious I think this idea is bad. Again, I'm incredibly biased, and as such, I've refused to work on this bug because there is no agreement on the solution and I refuse to help enable the solution where needed programs can be accidentally depcleaned (as with nano, openssh, etc, all would be after we remove them from the system set). I refuse to be responsible for people accidentally depcleaning things like openssh, I don't care that they didn't read the --depclean -p output, that's not a valid excuse to cripple users by default. > > If somebody beats me to it, feel free to dig through the past > discussions and add blockers. I know updating eselect is necessary. > I suspect portage will be fine if we just turn /etc/make/profile into > a directory and have it inherit other profiles. Actually creating > some mix-in profiles will need to be done, but probably not in the > main tree until we have more of the blockers resolved. We also need > to see how other package managers handle this, and work with them, > possibly including a PMS change. > > I'd like to get to a point where we can all have our cakes and eat it > too, and not have endless arguments about whether openssh or whatever > belongs in @system. No, we can move those arguments to if things belong in packages.default :-) -Zero_Chaos > > -- > Rich > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
On 09/07/2014 09:03 PM, Rich Freeman wrote: > Right now the general policy is that we don't allow unmasked (hard or > via keywords) ebuilds in the tree if they use an scm to fetch their > sources. There are a bunch of reasons for this, and for the most part > they make sense. Hard masking is a relic from the days that we didn't just have empty keywords, most of the VCS ebuilds in the tree just have empty keywords now and are not actually hard masked. I'd say if you set ACCEPT_KEYWORDS="**" then you get to keep the pieces. > > I was wondering if this policy still made sense in the case of scm > ebuilds that pull a particular git commit. While portage can't check > the Manifest, the fact is that git will in this case, and since we're > pointed at a content-hashed commit we can ensure that the package > never changes. We of course can't mirror it with the current setup > (there is no real reason we couldn't mirror git, but this is a > different problem). > > Tying ebuilds to a git commit has pros and cons, but I'm hard-pressed > to think of any actual QA issues. That is, something that would make > our tree inconsistent, or create a security vulnerability. Just use a snapshot tarball, it's not hard to do, it allows us to mirror the file, checksum the file, and users can reinstall while offline if they have fetched ones. > > Am I just not thinking of something? It would probably be most useful > for packages that track a backport branch or something along those > lines - where upstream does not regularly update their tarballs so > we're constant creating patchsets. In this case all we'd have to do > is bump the commit ID in the ebuild. > I make a lot of VCS snapshot tarballs, it's annoying, but the benefits to the users seem to far outweigh the 2-3 minutes of aggravation it takes me to make a tarball. -Zero > -- > Rich > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Update to the pax-utils.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/2014 06:23 PM, Anthony G. Basile wrote: > On 08/26/14 17:00, Alexander Tsoy wrote: >> On Tue Aug 26 22:27:36 2014 Anthony G. Basile >> wrote: >>> Hi everyone, >>> >>> I plan to update the pax-utils.eclass because of bug #520198. Can >>> people please review that bug and the latest suggestion for the eclass. >>> Since I'm inverting some if and for blocks, a diff isn't as useful as >>> just looking at the entire class. >>> >> What if scanelf will fail? Looks like pax-mark() will not report an >> error. > > scanelf doesn't return an error code on failing to pax mark. The paxctl > and paxctl-ng do. eg. Maybe we should read the pax marks back to verify if it works or not instead of trusting the return code? We could do it just for scanelf. - -Zero > > blueness@yellow /tmp $ rm -f abc > blueness@yellow /tmp $ touch abc > blueness@yellow /tmp $ scanelf -Xx abc >/dev/null ; echo $? > 0 > > If you want a more sophisticated example, remove the PT_PAX_FLAGS > program header from an elf and you get the same results. I don't think > its wise to change the behavior of scanelf because its used in portage > eg in constructing NEEDED.ELF.2. So its not clear what the unintended > consequences would be if we did report an error here. vapier would be > able to better address that. I just wrote the eclass following the > current behaviour. > >> >> And there are unused variables in pax-mark(): pt_fail* and xt_fail*. >> > > Thanks for catching the cruft. > > -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT/TKeAAoJEKXdFCfdEflKYB0QAKB/qpHKdqBkoG2lB9dH+1RG qIEyqHdf/SFDem31n1WO5On14enSn+cxafltTvg0emL34emg8v1Y0qD3s0CqXt4K juX3X8tCnT0CMME/Q4+mgs7aF2+/SLKliUQQ0H842xSSgBGS6uXy6hLa9p0wLOGL l9tzSjHGDBuTFdqZEqWiPVKOWw5loKZto0w8z6xHyFicEvNGGIaUZcpvvHs8dM26 aDICXrWqbU6dP8rU2AA8CSapEoFjuOQHQWPCzaIGlABSb9X9N/dbeS27bVQdiQm4 MBOEJHr9EPYwRRFJ8/XagCRDe3gUgh9p+WROnHZVblMkKRbUJvLqyYSLT220hdRi lwFJb8kiXfP446jk821wu2xbf0DYCuqOJFTUL/2lcXUO7atIQJqOlOYlpfL7IGSn RYKxDaJSoaxuGkMsqgKcp9gZ8AD/VT6uD1r6iTTkmCAnVQj4UB02XDc+r6+coyUc PTjyDiOeQHUhjvoWuJBxAT+TWNZRWXdIkIS1CzGHuCoovGyba+k9JfsOmmFX1HNR vFzSnOZ+AwIZSk0Mwbm7yeigrXlnPax3D7cRAACif9+fgkXolYr7NYZWgUuEYmDg 0BAjAsnK1Hr+UhQ6PmcLy8DH5svV9WaQcTWEGDHkEqavpZG3bqv/XKePXS//9MxK rq52G8MW2QlYGVFJd8ZR =5Kdh -END PGP SIGNATURE-
[gentoo-dev] Re: Clarifying if some arch teams allows maintainers to stabilize package on arches they can test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2014 09:55 AM, Pacho Ramos wrote: > Today some user on IRC noted that there were some doubts about if > developers are allowed to stabilize packages they maintain when they are > able to test on relevant arches (I guess this would benefit amd64 and > x86 mostly as it's likely more spread). > > If I don't misremember amd64 team allows that, but looks like devmanual > doesn't reflect that yet: > http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/ > > Then, I guess we would need a confirmation to fix devmanual and, in > advance, know more about if there is any other arch team allowing it > (x86?) > The current arm team policy is that anyone who tests on arm may mark ~arm, but only arch team members may mark things stable. That said, we do have a pretty lax policy for joining our team. Additionally, it should be noted that this policy is not meant to get in the maintainer's way when they truly do know best. If a maintainer were to need to introduce a fix to a config file, or some fix that didn't change any C code or whatever that maintainer thinks truly shouldn't affect compilation on any arch, then I think a stable bump is fine, and avoids undue stress on the arch teams. Thanks, Zero_Chaos Arm Arch Team co-Lead > Of course, developers stabilizing packages should still follow the usual > test procedures as arch teams members will do. > > Thanks a lot > > - -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT1R4ZAAoJEKXdFCfdEflKpPwP/jIDWm9GTczCQOopXSuM6EVS R29zcq8vgZJM1PuU3TKZ8CvcQFawrgckEUzMpDwKVo5mbCLKWrqbGbJFzk3jZusr DYcdWe/+XFjcCVoDOe3MazA0SO/VbXiIWhJYy6nqk/Y6VbkTyPaSuZTFuZztuJPf rSTlDQNJJSzY0A3axtqZxRXJsvYxvj54Rw3mGnqXtjhUJrwTurfb6P4qkH5TAPjG EfGqBUzCn9AsBGl8uxnHbBVMiBQWKwdYgg4rTnCYcrL/K3WocN3ix2Lwd+dZGmve fBUlqA2wMakjBlDn/1lb810+eOzXaatIw/BxWiO5RvManq5OEvKiehwjnK6vvC3c G/NsbnlFNRWtQPXVEgoNi/D8+vIidA+agCydAmmFzZOzHDjzbNG33TT6feq5C7fX 9dRmc/7+ZcdIPa+GCp9SEOEYF4qW1gMHYMFZi88Urerl3juItIEocXgWIESK/mFS E+vB8lEn/9GXdW8VRULkuHXpJXs/aiMGua58yWGk9D40Dj3sOSnT+4IC3oBD57Im IumIbMQ5BMS5WQDbOoClY8POVOly4UKa/xomYu+upISHXD2TABaFihke85zJAQaQ jFNzBEKfBn11ORcFGMEFmNeIBBcpjaFkK8m/GJNzg8c/aOkDtluchOpfBoOMcSRv EGkEWigXlNv81o72kxS7 =9bCP - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT1R4xAAoJEKXdFCfdEflKMj8P/3diO123jALGUQO29bsvjFaD vo7l/TvE6eXcR5rk6OoyGmHImClVD8t02BQ5xFdhzM0hr0fgOCH/c+/LLICIO6S8 0+gG8agXlBHc81RGJg6CXqDTKYe+hNdZ9s9eZEBDUk15HjPYEheIsijqnY5284bC aIp/yL+aOFOLBnZ0+CHBFncsK8bM/GfJdgAUBo6dd37erqYST9oF7nzxMMsSeiKQ 6VuWPe5zyeZfLjKKoJ/JGxCx8VLA9z+f03ybShAl/s/JKyNohCsVQtcjYnWI4oTu LSO2x/mH3KyUcvQbc38T4DssTjeQ0UNudNhSxD+jhZSdJ09jRuBQPIMhX57jeyBK /ERQwBJAFt1pD0cLKbhc0eUo+RJ6Pxye6xXY7ESGjWnPmlXtq+cBfamQApHVc0hR 48WR7wz3L9JysLRUR7/suj8qYqvH2I7Fljk1+d4iexZKuab+OOgNikcm1vO/zsVB XXMeXNrHHPmjBq0G2cXGUbNrPwziZVYFK2f9IUtoNSaWlFi4f/3YZdXIs/jwSIDp 3XeL1FtiDI4vxGKTrPVmXdtGmVMsqVGPXL+AX5rMrrnRbKydaUc/AaY0U69I5Xkh MSlGv28wBNMgICYNcuzk3+Rpic+WTdo6hbLzp0GqU8JWbYYJqEV+MtbkGtR1d5ut HB2FNyvVUOKJapOVNaK0 =oFlK -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2014 06:52 PM, William Hubbs wrote: > I'm picking a random msg to reply to. > > My concern about doing a revbump just because the deps change is that > the new revision has to be committed in ~arch, so we then have to hit > the arch teams, which we know are overworked anyway, with stable > requests just because we changed the dependencies. Isn't that causing a > lot of possibly unnecessary work for our arch teams? If you edit an ebuild in place, and that ebuild has stable keywords, how is that any different than revbumping it and keeping it with stable keywords? The two are functionally identical, people get a changed ebuild, and the arch teams do nothing. The only difference is that 1000 different ways dynamic deps are broken. And just for fun, since no one has mentioned it yet, dynamic deps don't work at all on binpkgs since the Packages file contains the deps (like vardb) and it doesn't get updated (just like vardb). Revbump or make dynamic deps actually work (ha). - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTzbjHAAoJEKXdFCfdEflKVL4P/2Sb88YYcbHJZ1pfnVukxvvi zYD00knmGiQOcmSxZMPnhVXjV+Z1SzyOPtmZa5KXLd2xwmVvNwJdUV0ssjfDi6Gg fxnAEWWuZ6xEvpIlm7WIXq5VFGL/AO4HUso6mHqSVZbbgYLPiFCooSAn291Epmjn vGIkUf5pNtRp6gLQFTqM2ksDzJWaOF9bmuapcCSumv3uhKK2Empy+6kHTKYVd/m5 Mvo10p7W8amozV+pl7Si7tWGOf/U+Xo3N0gt9VJzz8oxIpooXZ+nSB3p9bXSbKZN sspz9khHLKFyhOAfoBbtLB9cqwPfPqgMlt6h4n9l2uJ+E0nMz0vRIlQnMarKD2FE /3DG6zrvWU0eRuYM7c5iqOrlL1WYgAA3p6CEBo5U9+h+8eF2bgxAJt/c7txJG0Ws EpSlwOIFyfVOWaJeb1WpBt72sMH+URF/YRl6K0ZKmp7+X5Ga/39ZznRfhRblRp9h nBMyIer9Ai7wNbc7A1qMvjedqOknOwSJjKEDkaUAIn5RTFa5VmLAGURSeuQnIvjE ogel9ENjdoZJW0i8bEO8ArCS9X5vgdWiwZHcjZL62KNYoqc6ySrsTUm0Eo3vDevo wr782AzzLPVftPXNHMnEthBs5ztbLr6YlXv/V5jfCc1YRQGUeEMjBkny/Nxm1VLi /l1lbtaTcm5FcqSjen4Q =asgW -END PGP SIGNATURE-
Re: [gentoo-dev] splitting out arm keywords
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2014 09:48 PM, Matthew Thode wrote: > arm has a historical problem with stabilization, while keywording > doesn't require access to all arm sub-arches the problem with the > stabilization slowness causes running a full ~arm to become hard. By > that I mean that if someone keywords something for arm because it works > on armv7 and I run ~arm because stabilization takes forever then my > system may break because of both non-stabilized packages and because I > could be running armv6. > I admit the stabilization policy could use some work, however, arm isn't even the slowest of the minor arches. > In any case I propose splitting out arm into armv4, armv5, armv6 and > armv7. armv8 seems to be here already as arm64. > Just no. no. We support ~5 arm versions, and most of those can run softfloat, softfp, and hardfloat, all of which need testing. We are working on revising the stabilization requirements to be less stringent, but we are not splitting the arm team into 15 teams. > I think this would be beneficial because of not all developers that want > to help with arm have or what all the sub-arches necessary. It also > allows us to move faster on stabilization because most of us have access > to armv7 a bit easier. This would take some pressure off of the people > doing stabilization for older sub-arches, but not much. We have devices available to all developers for all supported arches, if you were even on the arm team, you would know this. > > > Some issues that need solving are as follows. > > [hard|soft]float differences. what stabilization means would need to be > clarified a bit here. > > additional overhead of multiple arm teams > > > Might be missing some points, but that's the main stuff I think > Maybe you should actually join the arm team and learn some of this really critical stuff that you are ignoring rather than just making insane suggestions on the ML? Thanks, Zero_Chaos Arm Team Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTvXBlAAoJEKXdFCfdEflKJxcP/1XujQ5lMEiEAm1qBZ+HWWLZ CqVrLeekrSYAT8vbfMeVO2b5Fpj4JruXInIm3WBozBRVI+r9Y2e4v8hS6bMKn/D6 L7C+29Lb0xnLJqQrIw/bR/lQxxuoIbrtmVMQxBaNese0pwOOAyYHG3EnLEIuMA2R sqh6RNhWIfPTdkOpeZAPo/Ql2z7WxxPnKDPP8w0/J0Hdhw3zrJCXlDfUq7g/RvBW 4jQd+Rabfla6BLQREipgdfZEHnaqH7KeJn7OkadRR77GKHkMgkz+aTgo0608FjEg HCmQ5cjWa6ZrKjbN9PZKEHcAuECR/Jo1Ro/Ybjxp1x9npQEaj4Zesu8QcoTP1UvO 67e3koGQ5C4wX47bnbR8GwZrPRCeO5+i40WKN6OB2qfK67LoedzMuzmsvRZN34yD 6NMlOaMP/kNJ8ISmj8y3Lf/21NeqRx4lVh4YUauUWE2Q48ckJDSBb5UXjkB+g+8T ra6yUNqUnJJVFnl+0gjS3X0TTDTBbfJHs5f9E2wd5cotGKAOaYjWF6WfSo3WSQMi sqADhiLKNrDOAqRBNkXGTg8S8d9YzoWLcfshETrT+FzYHmN9X+VZmwXUc4Aga9GM xC+AMzeBLX2zO/om5/u8qpmjZrx/B+57Lf6NSY+BJJOx6Vi8CvDMw0yF5kcTZYQq JNYq6FsIt8B9QUxgWs06 =7mPV -END PGP SIGNATURE-
Re: [gentoo-dev] Proposal of "uncooperative-root" in SUPPORTED_FEATURES
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/04/2014 12:25 PM, dREPLACEeLETTEReEjBYeLETTEReAatGMA ILcom wrote: It is incredibly hard to seriously review anything with this from email address. - -Zero > Hello to all, > > Summary: I have made many mods to sys-app/portage (2013 version). The result > is > a proposal of patch for latest sys-app/portage, see below. > > Main result of my mods to gentoo prefix: > > FEATURES=uncooperative-root emerge -bv =firefox-17 > > now works on EPREFIX on Android-4.1 ARM. I use neither fakeroot nor GNURoot. > root access never required. > > @dol-sen advised me one week ago on #gentoo-portage to post here a rebased > patch for HEAD of git.overlays.gentoo.org/proj/portage.git : I just hosted > this > patch on > sf.net/projects/gentooandroid/files/sys-app_portage-current-HEAD_patch/download > and it is also attached to this post. > > I request comments and discussions about this patch. Summary: > > pym/portage/const.py + (this is SUPPORTED_FEATURES+=uncooperative-root) > cnf/make.conf.example++ > bin/ebuild-helpers/emake > bin/ebuild.sh--+++ > bin/misc-functions.sh-+ > bin/phase-helpers.sh + > > My aim is to take your remarks into account, then to build an overlay (will be > hosted at endrood.sf.net) with up-to-date versions of all my mods. The final > result will be a tested version of above patch, together with lastest builds > for firefox, squeak, scala, gnucash, ... > > Thanks for you attention. > > Xdej. > -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTtu45AAoJEKXdFCfdEflKfD8P/jLdlFM94mIRExJLjf6snELd lKfKouTlv57gdgI0sp6+ptX56OPbPqfRMuBOToKdV5atbsdUY2T1nyE+3NaJw8C4 UjgaeEvZOzDYz5CgLYsdXvil24bBj5TJ7QYxKNFkBdWln7MF5blFeM37QioC82IA M1AHp/Ck8Q05WLuvjfKFpA5qCpXfDj7mdcOnqp2pf/CYCI45zsQoRnacDgi/VF3A vXBQeq2jcTfUb6kuZqqCuXEY0NcTcDAcJxhoPdIMFlnv19JQ0l3qnSwdvePxratU njR5dMP4rYrnY12AD60vNU0p7HaBF+9XMxWAef8aqc17+9j4bmciHTY1Ncre1mBo NH/9vHgFlCLYK+PjUzSags9EO5Oo+rEFf1muchjPnYAjEwVKou1pauNRaIRKX8g5 cyQAKu8fTJCvuPvLQRPNvxYk25ByV/a8Mbwi9UgB0C19hmFEP/GuujfNdqNSvzm/ lyOayX4La8XQFiD36AF6o8ro3L/8BtRmcumhJQXBXyXSHDbJumjlhDZ1IulLB6an oCpTjc0c68oMe5PXJVxjkXiZh1I2pXLLyTwqaqn15tg2zt8tbCC5FGplrx7/ejY5 MmP46+SUJQpJVuPWlY75Ks/756LIbswPo99Lx8tE5bUZQs8aS5LMmqhSrZ0bbUF6 ++2rrYvhdbZUxtSy+bR2 =vaB0 -END PGP SIGNATURE-
Re: [gentoo-dev] new profile layout with flavors and mix-ins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/02/2014 03:07 PM, Anthony G. Basile wrote: > On 07/02/14 14:41, Rick "Zero_Chaos" Farina wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 07/02/2014 02:10 PM, Rich Freeman wrote: >>> On Wed, Jul 2, 2014 at 1:54 PM, Michał Górny wrote: >>>> I don't feel like we ought to vote on something like this without >>>> understanding most of the current profiles. And I'm afraid there are >>>> only few people who have any idea about the current profile >>>> structure... >>> No argument there. >>> >>> We may very well still end up with something hierarchical, but we can >>> at least limit that to the parts of the profile where it matters. >>> Maybe x86/BSD and amd64/Linux and amd64/Linux-hardened need to be >>> interdependent. However, that still gets rid of need to deal with >>> desktop environments, init systems, arguments over what belongs in >>> @system, and so on. We could have a blocker mechanism to keep people >>> from mixing systemd with BSD, or we could just let people shoot >>> themselves in the foot. >>> >>> Sounds like a good time to start reverse engineering the profiles... >>> >> I've talked to the funtoo devs a few times about stealing their profile >> idea. A few things need to be done to make this happen, mainly eselect, >> catalyst, and repoman support. I can do the eselect and catalyst >> changes myself, however, I'll require some help for the repoman support >> most likely. I'll prototype this locally, see what I can make work, and >> then see about making it usable for others to test. >> >> - -Zero >> -BEGIN PGP SIGNATURE- >> > > I don't know how to get from here to there. The problem isn't just > constructing an alternative profile tree. We could even have > /usr/portage/profiles-r2 and switch between the two on demand. The > problem is there's a lot of memory with flags and masks and these only > make sense in the context of the current stacking profiles. > Disentangling this information and bringing it over to profiles-r2 is > going to be work. > I agree entirely. Right now the mixin style profiles are not supported in gentoo _at_all_, and if no one ever works on that, then we will never support it. I will work on the first step in a long road, that's all I'm talking about here. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTtFtTAAoJEKXdFCfdEflKDk0P/j6F/7ivY2HkbRV3Y60YiahE IbzwrZ7wQCap5sAELOtQaXTyTHuyTLkTrAqqM/r+/8a0/Ebm67yEALbzE4IOMAFL DoiS7mg0FZeq2Bm8AGKtYwmBHAiIYbGWX+XgxuFbwpHz4uilsVhQH9+e+rFlu6SN 22BDmW6tQSDL5a3C2Coqoq/KVH/heHu43w6/TuZmVVByLcABHrEG/KOnLRHSGfwF ps+R3UaMmFA9w6VGqGxlOXuIbF+cp//xOTfqmetYfe5kkOsls/ZAKou1MMCrCSI7 j6oJbH5q5Gn5W6vxctf8PJPI8R5NWZBOFwvDgkeJ9Zcsqhsinb19QQFVkG6HOrt1 2nSTOP9U/5d0wYn9P7cNgQsXjg8P2KwHfPXG8qZ8jx1CSM0T2bY4csjALgqAmvpz ATa9XbpGmcRMoldqiVZEVN2EqL1NWVXo0i490Y51noiLpNSiSO2XT4lbIj1fae+i yxt6RuJ04QltsQKKzH3swCqgFBUZmNZe2h0p0dt+GFOl9Pg0oa3QX3eGR0msgmEy Qti0JRZwQJrHkDCSzZP0OAI2RZDj5XxmhS1brTTvb7LnxFecWR760LfQ/bzJgqno M800gZKrJ9AjzC8lvzqWQrd39W4VYhcDn19S5zHtBPb3KK/4jC9J1TVwwgzbW7jb z6ytQ2biVKhkBPrec5tf =2WzO -END PGP SIGNATURE-
Re: [gentoo-dev] new profile layout with flavors and mix-ins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/02/2014 02:10 PM, Rich Freeman wrote: > On Wed, Jul 2, 2014 at 1:54 PM, Michał Górny wrote: >> I don't feel like we ought to vote on something like this without >> understanding most of the current profiles. And I'm afraid there are >> only few people who have any idea about the current profile >> structure... > > No argument there. > > We may very well still end up with something hierarchical, but we can > at least limit that to the parts of the profile where it matters. > Maybe x86/BSD and amd64/Linux and amd64/Linux-hardened need to be > interdependent. However, that still gets rid of need to deal with > desktop environments, init systems, arguments over what belongs in > @system, and so on. We could have a blocker mechanism to keep people > from mixing systemd with BSD, or we could just let people shoot > themselves in the foot. > > Sounds like a good time to start reverse engineering the profiles... > I've talked to the funtoo devs a few times about stealing their profile idea. A few things need to be done to make this happen, mainly eselect, catalyst, and repoman support. I can do the eselect and catalyst changes myself, however, I'll require some help for the repoman support most likely. I'll prototype this locally, see what I can make work, and then see about making it usable for others to test. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTtFI/AAoJEKXdFCfdEflK7GYP/0GS+Sh4odpHNMUfNfyU+q7F HpNuJ/OSnnNBRol4dDjcvhE3RFxIqU1DkC1atsl19K14vJXk+JBSKw8fgV4J6ous 0uOYqN472Noy7NxzmrbfrlR1PePG1b878ZpOMbGce1dgMfamoDwv48IjfcSwakcv 6HSy09xfr5O8xG+cSBqyVmaiDxsPHPQwv1s+/JUpcadBr4AmD7qc7yTZ5QjKJoIg o1eL/j//KiYxQywoQ1udqXwx/beBgYMQB4R5Vu4d1BBtIttnJdTHCZdAv6Uoi686 x4VWuvBPDaILojyhIYqpoMbKAu/c/AFRFkpFZXFVl5kWyolw/YuBg4RL21qecDvp 9qyoQFCzIWCSzXl747O4iFYjS1ACbMSUXOSDEecvnYuCsjvI+bpJT2pWVlAxIMUH 79IgKTu0+1LETl/lEeMN8ccrG8R2hhrYCxxyTw1nZfevN9SPC88RwEIcuBwVFHC3 NC7fpxKzDFy2+0ixBnLCQA7ICnvV5crF2Tt4/bg9Hbp2UP/QMmhxIwUbceRSDXc5 3c8nqsUGavLX8K9IE3IlI5ZYutmYJgJwfqX8yA6wdOeZgPvH59gypnBYFKJjO2DQ JZE+lVZ4vXLmgw1WTAdRUYFhLEqesioCAVH7Bm7gUnccCeWE4PFHr15BGhdh/Mw9 L88DkCnfAbLcSHRJS0Cx =iBrl -END PGP SIGNATURE-
Re: [gentoo-dev] The state and future of the OpenRC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/2014 04:59 PM, Anthony G. Basile wrote: > Related to this, I'd like to take care of sys-apps/gentoo-functions in > WilliamH's absence. There's a couple of items to fix and I'd like to > get them done. Any objections? > Knowing WilliamH fairly well, I'm sure he won't mind you closing bugs for him ;-) Please, continue the good work. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTk4Q7AAoJEKXdFCfdEflKJhMP/2c/ptkg8DF616YyCkz9EkBG +qo8s9mfB411MUHkod2I0KmHHzNbOPRd87DIjwmZJoAJSbg/ojrJwgLlsVK5e7bK qGIE/d2QdY3pi8Kiix1jx3sp9WVx1PXB8PnMmmEyzgzVNew7DVLI3gF7bZBCmIJA 7OscNOkGjq2MJNBH++p6fVjBpBAJVdZAr2WeFFqrIAgcS8fscC8lb1Ik/+xAeunk i6tFb+Uv5GHeckji1SqYzWkNFqwC2okNUNFUViYJLI9DMOP3FBImPAcTl2g4ks8Z 3m+Aa3b08et3+Hnbecr5YYO+myI/cQpFnj8axzoxExg4fQ7DDQIB/kPikRTcIEQP rCFzDrqwpUmDuq+1BjjC8ku4qokSC6WYn435KikDMGdtAVX3ViOcNjqyf7+4Jt20 mOKrm4vaSe8rLCyr3YS1iJYv2mahxF2ZIptKeyw3oT8KjXj7jW+89ruBwj71CPUN c93cvV4A8qAAblOHMJ5M3p1Ah2Q0+DHVguKql89BKFVXSCuUaReZvYoeoestc4m1 wxb6S1KNEhPVLouyGX+zYDoNhuOfHSZN5ZWyuZZkzBqR3uIojlygG3pj5jrebuWG ErEKhaUqYxH4SvokReU3DUR1HA1vCrx0WS5mhqcseKKGjvdOCe0dnLBHvzVQTXbE lwVhnlTRR2COb1xHtTRN =yT5C -END PGP SIGNATURE-
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/30/2014 01:39 PM, Fabio Erculiani wrote: > configs should have never gotten into genkernel in the first place. > it's each kernel pkg (or even version) that owns a valid config of > itself. > I am part of genkernel@ but I have no will nor time to fix it. And > when I have, I'd rather work on genkernel-next, that comes with a much > more readable initramfs code (that I managed to rewrite myself). > > Wiping the whole config files has been on my agenda for very long time > already. And replaced by what? defconfig? allmodconfig? - -Zero > > On Fri, May 30, 2014 at 6:32 PM, Rich Freeman wrote: >> On Fri, May 30, 2014 at 1:02 PM, Ben Kohler wrote: >>> As nice at it sounds to just DROP these configs, that option is not really >>> feasible considering the way we currently use genkernel in our handbook. >>> Relying on the kernel's own defconfig, "genkernel all" will NOT produce the >>> same mostly-usable-on-any-hardware result that we now rely on. >> >> Considering that the configs are more generically useful than >> genkernel, having them separately maintained sort-of makes sense. >> Then genkernel is a kernel build/install/initramfs tool, not a config >> management tool. >> >> I'd stick them someplace where any dev can get to them, and separate >> them from the genkernel functional code base. >> >> As far as who takes care of them goes - I suggest that this stuff >> comes out of the devmanual unless somebody steps up to take care of >> them. Those who take care of them become those who want to keep them >> around. You can't toss out a tool and ask for it to be a >> recommendation but point to others that you think need to maintain its >> configuration. >> >> Rich >> > > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiMbcAAoJEKXdFCfdEflKWGAP/3PwUkUTqUIQrORooQv4ZTR8 CX/oI8jmhA8o+3QELpti8JY0qP8rak45w++7Hofyg5MD8UimS3jhUr5jWwS3gGyS K/SWIPlDsSDIrp0hQO4oTqT2zw3m1C/A+zpdElF5wtNZrEsF86rcn1CeO9ZKMUUq pet3qjPHhzOtts9QoyejIyTtm+iIzig7RlbuIYQmf44C8I0ZHhXnDiKfLc8TFLYE N0gpm9GzMpIP60hbRRAKfCtNqjG0y3XvJJSgHm+tdlx6+1dQXkSJjrkvMvI/L7gH oLFqT8TYpHf9aMkr32Hy2LY/b1dwDZqqjXozB+/Sgdgvh7XWtALLJO6WJovuVst5 Bhv1ADlBA8w9FQLqwi0QMapqf94lslmqfr4QEmWz/QURv8CM2gSsTqfqouxlI+HB QPWzM/pzyAi3UW8nP7lTfC96SrSoy8Vsop2/CxJxzUW0y3VGoRi3Ckuo38MXKiXI aHkKL+UisOWbbPWtU6TphRrdmphEkICOSvIVzRFA84I9hIgQF6EPic2TyY/+G2xz gKORB0BeTA2SnOjZ3S5uJClHViVugCepGVpy2J1WkTIb0sBJwchV8t5ssN1Aa+Vm 9uAXkDCK0tw8jK3pgsa+zweBA22LYIisk3TYq27+zOh11uso0kE6XXT/sunQZKOz /j2iAIh3/rhC4Y/OMNal =hNQF -END PGP SIGNATURE-
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/30/2014 11:10 AM, Samuli Suominen wrote: > I can't find anyone with access that actually replies to mails, pings, > ... to genkernel repository for: > > https://bugs.gentoo.org/show_bug.cgi?id=461828 > > I'll p.mask it on amd64 profiles if noone replies soon :( > Please don't p.mask a working program because a config file is wrong. The arch teams think the genkernel team should be updating the kernel configs and vice-versa, so no one does it. I would be fine with entirely removing the kernel configs in genkernel, but I assure you a p.mask won't last long as it breaks releng and breaks users. I'm super happy for you that you like dracut, but gentoo officially uses genkernel and it shall not be p.masked due to an OPTIONAL config file. Thanks, Zero_Chaos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiLbuAAoJEKXdFCfdEflKF/8QAIGEAzU5xoMM1VU41FS9e/65 OcAAdW7wYTaXdAocwK72MenZbCk4IDitJK3dPaGH4gU/XUOImrntuecYKs+eDPg8 EbQUQoBeJg3zn31yParwq4BIicFsPczVyfb+YglkqZy3+D77t2HJmXg6DHilQyDb bPftBrMwOoohqotdvI7K7iADH+f3L6YjLcJ7ljCjMopMFUF4eBj3vcWegCX/CKYy JZHzzafSsj2eNT6m9nAcKZlxtW6a2LYMx8FHElUcBxqr9iD0ReCW58mwTqV6xBmX TubEiWCjnzWSL9PgOZSXbbWR9moFJP78E+u+okcpxvslZj4zdvPO46jimdfpIRYG dvooSYn8HQx8J8vYidCmqwrQFy87JF9xBmBqIsUF5jXYMRbF2Ce2zuSh1M9DFKZU FU8A18X8mbqaRFoJLksprBJx51pr1UlgnV8Rmqa3A2NWEHlZFc83q7wnRVyCwvm6 dTTK8iUzBCAIzujIRDsWNxza11FEAC2i2MAqzsXBvO1yFNFsNzDqlPfGG8xSJvh2 GN9tgvThu4KLChJgU9D5jtRYDFazSh8HhIC4MQWgJeSuDDbE4EzAuJTfsSmlAEfC IeDFZzcI5hUQ/y9qTdB8yU8rFgU+emwhwQTZGZbCJL/22+muNNHcL3aDcMJdEve+ wD2M2wcLLicDsalXvUJO =ABQe -END PGP SIGNATURE-
Re: [gentoo-dev] packages masked for removal in 30 days
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/23/2014 03:42 PM, Rémi Cardona wrote: > Le vendredi 23 mai 2014 à 22:57 +0700, gro...@gentoo.org a écrit : >> # Google closed free usage of the translate api >> # Masked for removal in 30 days >> app-text/qgoogletranslator >> >> # openmcl has been renamed to clozurecl >> # Masked for removal in 30 days >> dev-lisp/openmcl >> dev-lisp/openmcl-build-tools > > This is worthy of gentoo-announce@g.o > s/worthy of/required to cc/ Additionally, why mask and remove instead of just doing a pkgmove? Thanks, Zero_Chaos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTf6dbAAoJEKXdFCfdEflK5/oQAJInl5Epyq7ZQ87Jn1Vy23Md nfR0Bc6BfngtL4u0UcRcRxFe7VUTIvOjuiPWAUJQA8VmMeNjs03zCSRJ/n7BDpNR 4BmnP+mFSgXdutop6M64uxn8L8xuVLIl8yARRgqDhoz+hluW/+3NsW21bgu6m2TQ R2nKNNDS4xgVDifnW8a2UWmOMm6vYOpnmMJYmELsDcKa1+MoyaPtR/k2eTkQ7XzH aaQvjeWTA/OLD6M+ogaY97f5bIk4OMiV1yPWXZJEBC4kzEYujKnt3HVOIyUZwuSX FTE+HhgasaERWFVRQCrwUqHhn584Uy3xTCxCg2FaNq/YDnnZ8cz71q3o/K/PcpMg bIw1KfhT00pPk03Zp+JcK56/9SG9JMKsmc6h+tsQrlVKaldwY+W5mZZgChbS24wR 3EOF/YN0dJTTFEJfHzgQGiRvNVDiIranfcVTTzdsny7H8zdYcu+avxBM55fXC3O9 NCwz6+wqcwX9an8xulLXnOyqO236otHPaX8GZXmyedOoknAznU8VPqx1rWBPj7Kg m1bI/StwMv84LvKcJlHH1ddeWCKnECKNt4NPrYrDHMkXwk+HZYBG1t+D+dWBcPfX CrU+Oep4qdqE5E/+++F5y18GeAwmE/G+xK1jeMoCZ7//wnRXSer5TulZ0JFoMk/I Xz+XsE4KZJi0JMZgKIZR =a9i3 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/12/2014 01:08 PM, Michał Górny wrote: > Dnia 2014-05-12, o godz. 12:07:11 > "Rick \"Zero_Chaos\" Farina" napisał(a): > >> What about talking to local network resources? In my metasploit ebuild >> it has tests available which talk to a local database and are perfectly >> safe, however, if postgresql is started on the system the tests don't >> work, the ebuild needs to start it's own postgresql to run the tests. > > How can you assume that the tests are perfectly safe? What do the tests > do exactly? > As stated just below, the tests are not poorly written. All testing is done in a test DB which is different from the production DB. >> This seems a bit needless in my package, but likely saves others from >> poorly written tests. Do we want to allow access to system network >> services or block them? Right now they are blocked, and that's going to >> make the src_test function on my ebuild expand into near insanity to fix. > > I'd rather not get into allowing exceptions for the rule without > knowing a good use case first. I can expand on that once the previous > question is answered. > I wouldn't necessarily ask for this either, I'm just bringing to the attention of the ML as this could be an issue for more than metasploit and pymongodb. > I wouldn't call spawning a daemon that close to insanity. For those who > haven't seen such a thing yet -- dev-python/pymongo is an example where > I fixed a similar issue (writing into production database). Though it's > bit hacky since I needed a way to bind to a random free port -- with > network namespaces it'd be easier as Rich noted, since the ebuild would > have all ports free. > That would be nice, can we do the network namespaces so that I at least don't have to bind to a random port? That alone would be a major improvement in usability. Personally, I would love to be able to talk to localhost outside the ebuild, but if everyone agrees that is too dangerous then I don't feel I am qualified to disagree. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTcQNMAAoJEKXdFCfdEflKuNEP/34dIuiPCFLqLBUnCPJDQ3JW RVrhfOoqLyyixS18rYqTNeTDBDBrnICtsZ7T47ycs9fKbN81cgSUOrMQw/qai8/v jDBPUNb9YTs2BJ22GtNw0OBPbGc81GEBLc36P5etS5ymDPwbThSsSTo90cOiZweS IQgHkN0ZUDxmgG/q53GSU1IONZzNU3nSt+yrd90h40Vbo2PuAC4O+fz0m3jEGV5C WX+h5W+BCLStPerOV/VNySqQ3uo5poi3wXc3o4ojgpH1ejXo0dJ4fn6KHZxema52 JH3K3VSn2Mr60wo/43kDRmA4TtYSNbxMAH2aykAJ3WklZf3a82O0Z+++Sad84zTJ khpJwMHJkWAGTRibxpLIQ4lSjuCwAD/WCTHRw2i8PQPWtDJNGETaGFiBwtNZRexe 2kXZbpr3TqdwfY9WgDU4pB4QpRk7UYKSVgktSIU+yY4zGH6R2LaoUs/uQDntP/1F RYtdxV4glZ8qeOq9hmT3hnzVt/Pvj/sm+oPVJRRurz+X5FJIBGUkEFzqIXisE12E 3xUxsMQfjfOh4Io5y45iQjoYw30GdNU2t47IhTMHy1Cg9ZW5Lodx5qYiXy6JOww9 rLXVYa7u8f9emrQZChDd3+OeODU09O/YaakNhHv6gxpcVAOj9G9BMKMh0LHxSY6P X0lKgUDxyzYSDNBhaiCn =Vi4y -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/11/2014 05:42 PM, Michał Górny wrote: > Hi, everyone. > > Almost 9 months ago I've committed three new FEATURES for portage: > cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose > enabling at least the latter two by default. > > > Firstly, I'd like to shortly remind you what they do: > > 1. cgroup -- puts all processes spawned by ebuild to cgroup, and kills > all of them once phase exits (prevents leaving orphans), > > 2. ipc-sandbox -- puts all processes spawned by ebuild to a separate > IPC namespace, preventing them from interfacing other system services > via IPC (message queues, semaphores, shared memory), > > 3. network-sandbox -- puts all processes spawned by ebuild to > a separate network namespace with a private loopback interface, > preventing them from interfacing other system services, local network > and the Internet. > > > Secondly, the benefits of using the latter two include: > > 1. improved tree quality through more complete testing > > In the past, usually users with no or shoddy Internet access were > the first to notice ebuilds breaking with no Internet access. With > network-sandbox, the ebuilds fail consistently for everyone including > developers. They can notice the issues first hand and fix them before > committing the ebuild to the tree. > > 2. protection of user privacy (and security) > > Currently, programs spawned by ebuilds can submit any data > to the Internet, often unnoticed. While committing ebuild performing > malicious activity is unlikely, such uses as test suites sending > pre-defined data and possibly some system-specific data to remote > services happen. This affects user's privacy and we should prevent > ebuilds from doing that without user's approval. > > 3. preventing unsolicited (and possibly costly) Internet access > > Bear that Gentoo can be run on a machine with byte-paid or otherwise > shoddy Internet access (possibly with local distfile host or alike). > Ebuilds using network unwisely can reduce throughput of other local > services or even cause higher Internet bill. > > 4. improving security through preventing unsolicited access > > The build process (and especially tests) can spawn daemons and bind > them to network interfaces. Without network sandbox, other processes > (or systems if 0.0.0.0/:: is used) can access the spawned services > and possibly perform malicious operations. With network-sandbox, even > local users can't access the spawned daemons (due to private loopback > interface). > > 5. preventing data loss through thoughtless access to local services > > I have seen test suites that used production database servers running > on the host. You can imagine how much damage such a test suite could > cause by mistake. network-sandbox prevents the ebuild from accessing > local services, requiring it to run a safe, separate instance. > > > What do you think? > I love these new features, with one minor question: What about talking to local network resources? In my metasploit ebuild it has tests available which talk to a local database and are perfectly safe, however, if postgresql is started on the system the tests don't work, the ebuild needs to start it's own postgresql to run the tests. This seems a bit needless in my package, but likely saves others from poorly written tests. Do we want to allow access to system network services or block them? Right now they are blocked, and that's going to make the src_test function on my ebuild expand into near insanity to fix. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTcPGvAAoJEKXdFCfdEflKTRsQALVP4yDmT+KIbd5ZnEj0TlUf 6eiG2pVJ1XHun3cuil4Sm5AqbuehvhzCLzM8uLEZuTus8YIZqfO4XhiXjY70WyMM N1SdUMFucmokOvNG2RmTVt30VETAn2fOQakbpYu7KyR2N9lDtAi/UXfJJTGRe+m3 iilVZ8rRyQG903VRwJZoQsYPjv7qYwxC7I345u3jDpwwObnbvs9An5lE5A4gVSa/ oLHI636lkdO7e2egitewGEo96Xaa65CCVTt9w5BeT2Ovv3IwgxjD6UgO6hbYIHvg CsdnCUTd1o3BTasZgAwaJJv8FcJWdrpJsEk8Kowb42Mpy6kaz7ymaxbOye3i07jf MIdh+nbRUS3VRuUf14+8sda1/rCpgnOKIbGfNpfAuKFf/FNfTbLQET7cIv5oNAJE Kis0nfLCSdZTxV9qlLC/7cxC8MNSjYu1x/ynRQYmK1qUTGfiWUqMwdk3HBveVAI8 bfYTtoXbbuyGHU2hOxRPgYl/ynVoWRw65jYZR5gLekXlVJtbU3H76NpbKqkYXWtF l+u8ddJCGD3ghVUm8Sknk8E8uSGOxgHaRaIfj8HpVSKrn/BZkB8dnmTa15SvQYUf yBvuJTAMlSDkLXCvqJZJVK61iDc6eFPXXcsrOkrYNOpz3425AI4iuXHvtfpDJnGP UgnWgSfIJ9iN0jHz7n0e =uAgr -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/14/2014 04:35 AM, Alice Ferrazzi wrote: >> There are a list of packages up for grabs. I cannnot test anymore some of >> them, or i stopped use them. >> >> app-text/fbreader >> dev-libs/liblinebreak >> net-wireless/madwimax >> net-wireless/wimax-tools >> net-wireless/wimax >> net-wireless/wpa_supplicant >> sys-fs/ocfs2-tools >> www-apps/owncloud >> www-apps/rutorrent > > i will like to take > net-wireless/wpa_supplicant > wpa_supplicant has multiple active maintainers, but I don't mind you helping as long as gurligebis doesn't. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTS91ZAAoJEKXdFCfdEflKYdkP/Ri8dqjpGi4EiNhdTnXRfgug +JDgkRoqzy3ajNWWxwGK3dWgM2mbuZjUdN8x7G3SFJJu80irJv+y4PPVmbVVG2RE GL1bS6YokgeM5PGXVinyDqX2/xXf3zFgbYopxoooFO9+nV/ZEsh3yJG8VM4Vbw4S svYuuEQTFXTHAjY//TT4oO+Q6jobtWkjpBSV3O2uU4ltDKRvBdlwwkS96I5iYqAM le6Kpj4NVxxFx44NHoqk0wKHeKNW4zh1Hngr1eZnWfxdIFbTExr9cJ9D6KPfDF+X 09ry4X2nd4ApzQY5iIrT1DgQVtGeXiPLn7BY/J4Sg/1Y2X8+iIZaGaxObk/niN20 tpgRJ4Mw7cj6dn7DqkxODjkeAB9aDdRAeknAdDGPcTVw8r90XLch8vgATeF2/vhE 9mbdmoO1Oh5XROKdhSS4cNRpx7rv1EDJSsUqb76s5+Wk29b8neMoWKHXXSRZDNHo CcNzSHLG55e3vu33WLPq0dTjrVjO7Zoamp8hIKpBPnEgvIPvFKPz1EpKOTFkFt3N WOMIecy1PzWRf76iKUV6j22tm5slm3sZuZJFOhGTMcA2gi4tdIhxE+YaygxtID7N tp7/ONqf9FBgwt5xmYRGlBguyWGKMczDOc0PP+mhoi/wjycj8aNcR5PWFHGdu8Xw e5Kbp8ZA5NWVWLzFmUCF =rgsR -END PGP SIGNATURE-
[gentoo-dev] dev-util/dissy removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I forgot to send this out when I originally masked the package so the 30 days will start now. # Rick Farina (22 Mar 2014) # Upstream has replaced dev-util/dissy with dev-util/emilpro # Please switch to emilpro or report issues in bug #505380 # removal in 30 days. dev-util/dissy -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTSCSKAAoJEKXdFCfdEflKiAIQAItkrH7Z8vFUkpdM/8jmT057 bUAResYMiHZ3j5c7nLus5P1MxeYA0kdj6gWe1rqRVeD1NviHgjn3or4bZbjYl+oD akFFh3mA3kBP/uJYJim8JoqlhfX0N977cXNbgUblfI+4k3w64Y2b3hImy5XFPAmf ftHeRvLCWDTlxcschVwK2hWZQAK5xDvRKDSlLGMJE9YtodNYc/yJQi3JC1YB01Uv E8NrtEUnlVelNMLDm0rA/nNjnpR/ZRLgANxK1LzNt1ItZQzzMsnemDa5L7BNyTNG 0lbI3hoI06qyMFo0ZAKDO4pDFDy9+/9h8axDQD0jvrvaOw/fhl5bDUiMlf+YJ1hw kDoOkJ3qVbLXaeUXmWtBrNN/0cyXGVFDuQCbmG+bzVodMsD2hHIbQd1l3R+4ugW/ k1hh7A/TtlUg7vxdPpHr+mlvqBStHvQc2cbwGQCRCl/uJaVcSa/IV7aksHHaRc/W JGlmR+jyez/DuGaNu1UsNGu24qai66pKYSC+sKlkOf5Q3ZAW1WBLY8fDth/WnLaQ S9FGv4SZyfisIEo8AzELQQGPAjAN7IfCzhI8qQ/3ZRGhNwvMrTt2Oa+6YSgAIevc EbhAuQuIHCfowuawTmwSfSRRHkKgVeiyJud9HGFFamJgU1Ovx1OMH11NGGSsrVQO ufrRHFVP3/GWofJUY45m =ciwW -END PGP SIGNATURE-
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2014 02:40 PM, Mike Gilbert wrote: Gentoo typically tries to keep patching to a minimum in general. To be enabling something like this by default seems bad, the fact that it is openssh compounds that. +1 for removing the + and leaving this optional (default off). I see no reason to not allow users who want the feature to have it, but let's not pretend that openssh is not important enough to have a little special treatment. Openssh has a fantastic security record, let's see if we can keep it that way by default. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTRLh5AAoJEKXdFCfdEflKD/8P/AlFnU6zMowVgpMaqotg/CzV y8Wa06bO2b0r7us8tZjqM5+D7MhjxPReNQPhd8t4D691USVGV/hLlYziVP1LSQ2O TxlLK9rNw5EtVS3mfTrjPk5oQE+OC7gQ+7z3XENyZcd8BvXA/NTxJxDLMHKOETId PuV6ff9M6v/3g+WSoZzoPL5Co0nknmUiRhemUEopH/CgAsmng9+XWnbSvF7u8jtj l8kHMNAeA6+tm1JIIZwPdfTOOVwbkqTekjGRrl/t9Ozo3fOxJdt2KgDhGfoQkhHc cDdeRNT9Kg146EPzpvnV6yDpNARNLSMC5qVqWPHMBru4O5xxogYx13aaDSa+YhD6 P/kg03WwHPu0Z6iQZI8bebF8oe/vLDK++9wb6IMd4r5MI4i3jhEL/9eVD4GtyNNS 5Rv/cuhYT/Z3rNYfn1FZ9mtpcQXgW4mqAGZDv/ULy7MLg8lhk+aA38mKtYq9b1XU VK8BqW7F2dphOwC3r0gSojW5pk487WwerTIgRutRhX1ordL+M9Oic32OWe8eR2v+ MIKzLRboJt/J+eayGlOQ6boSBcf1BVpFDRkdnI+Qo6qm18faLc8796jaTnBEzR90 Sz/UF01a8lkjjdGr61p+kxNR0cqVXVHYuQFX5gdULGS9E4FLQNq7uz+a0fwFZCxy 0VPMvHuEExnokP3J7gUr =ZbJ3 -END PGP SIGNATURE-
Re: [gentoo-dev] Change or revert the "30 days maintainer timeout" stabilization policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2014 02:22 PM, Mike Gilbert wrote: > On Wed, Apr 2, 2014 at 12:52 PM, Samuli Suominen wrote: >> The "30 days maintainer time out" stabilization policy isn't working >> when package has multiple SLOTs, because >> the bugs are filed for only latest SLOT, where as some packages require >> stabilization in sync at both SLOTs >> >> Option 1: >> >> Either revert the whole policy, and never CC arches on unanswered bugs >> when the package has a maintainer, >> and let him do it when he finds the time himself, and if that doesn't >> happen, wait until it's dropped to maintainer-needed@ >> >> Option 2: >> >> Or, the person who is CCing the arches in 30 days timeout, needs to make >> sure the bug covers all SLOT at the same time >> >> >> The status quo no longer allows me to maintain stable version of >> dev-libs/girara, app-text/zathura*, and the issue needs >> to be addressed, see http://bugs.gentoo.org/502714 for what inspired >> this mail >> >> - Samuli >> > > If you want to prevent packages from being "timed out", just leave a > comment on the bug saying so. If you don't even have time to do that > within a 30 day window, why are you the maintainer? > > Another option would be to add some kind of notation to metadata.xml. > > I've long been a proponent of freeform notes in the metadata. I think leaving a note in there is very helpful for developers, however, in this case unless the note is standardized and the auto-stable script is updated I fear this won't help anyone. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQdvPAAoJEKXdFCfdEflKbdkQAIrG0LFuOMvmqopjGoAJcg4W 0YFqVl8uvKCokFfM3SxEkBoxK4R3Omi0YX2Gb0KKQR16+awKbqdwBlW6moilR8Ys jIqzMBFEK7G+XQZEHaiui0nLgBfJLqvXx/r+7Mz5hOogSqRi+/TAo9C6IqW4njXU YcC7KotCIRMCtwaqWCXq9F3nRY6LzRRaw6ADO7fLdJbkA2/hw2jdz+24QNz7NdfT trqLn/f6CXllMt3XQA9ZeX6Q9I8g8ojnjosn4LoGHKObQaImUa5HMT+0HKY5ySh4 AlaSFm5ZTyqn8vodrXGGFGQuaR1HGMFUkLqE8Wdd8XGfmbxKI5if3dRjV0a8vDiF nqS5CBFs9ssyDqMlWnDYwPRwDarULyvRSx5RTE63pTnm2A/ks3qr7wD5Z0ZYpKzZ Y7j63rXnVkGi/3gUgxJU1uJ552JuitYs/KNet8xMOXpytAkgK0SzQnEiHH/fXaPY oS0wASImAfNQc3dvGPithFlx4Su7vxqOB81Vs3dZIRSyNtQlEgnJ6oZCxH1UpUq5 agam16R2OpZ3JnlMkSV5jdh8RqZ9iCoyum2VzUJXGqMRlZ0l7gG8lwqRqa4z7brn CocnpCeJAecAdFYCSy0PIc0vfdb0K6f74Gkm7joM6tl5JFX3bbUJWVq/Pouf0BAg GBeKrQteNK13J5yF9BvE =k60D -END PGP SIGNATURE-
Re: [gentoo-dev] Make udev optional in net-wireless/bluez?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 07:29 PM, Gilles Dartiguelongue wrote: > Picking a random mail in the thread. > > Making udev dependency always on is a deliberate choice here, as noted > by Alexandre, the library will be most likely useless without it and we > simply don't want users to get confused about what might not work in the > stack when bluetooth isn't particularly easy to get going already. > > Anyway if there is a real point in having more possibilities to shoot > ourselves in the foot, please file a bug report. This is the usual way > to get this sorted out. > Picking the most appropriate mail in the thread to ++ ++ Honestly I'd rather see this split up into libbluetooth and bluez than make it possible to build a nearly entirely crippled bluez with no udev support. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPHKjAAoJEKXdFCfdEflKhX8P/1pwbM98aWmG/32a/U8cTit6 Zxjffk9XeXkFSGH9JJYNTPc6plK9fWtRYS4bxUA7tj0xYjN3N/xrAo42g5qZbVCc 1/TiN9iu+gLQmBlWi5JI1V0r/bdyK5UBYyl5PnW3oy+PSGoFMGEW+osql4jBzhVS QjHgxHEuG6dWJSlqtKtOHai7GPm4YDnAiry4QY5mMWMS6Y5Fy56ycp6pc20rN0nV gywiVJnRBEaHitJBwBICTwwXHK1dhcRH5WOJVTkyJ9ZFT1ZAERboPoXVlzYbyXxv JBGjaC5Llk2KtfPdtJLdlO7DZtTTZOQc2A6mwnsFDthD47UY1nlv4TyYY/MYTp77 59jel7GfboU3cP9ts0Gx/qwG4AsDKqTFHT5pq589usYGz4l/imvg32UdcoRJpJJf ZTYmtM30BiOV8lI3FwcztLjefFf6w0NiLqkVG8erLumo8by1lWvhHsRaXX/J98br XOSLEC26NU9fjH6PSMncgY6676ibFPoBWLzb/NUjs88MqSMWLzJY2m13TitVtXhQ K5OWjg8jfjXmF1fQXOlp2u8kGbIpG751ZznjGwwj3RaXeZeZcH2h3hMo9nAB1tqy YWv57ca+HcctSLma11ynDdyXpdxWhupLJH1RDqoc+6GUDdw8eojiIoLfgkmooQrQ w6TV7fYSgELApJ372/74 =iAla -END PGP SIGNATURE-
Re: [gentoo-dev] News item draft for >=sys-fs/udev-209 upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/24/2014 12:32 AM, Samuli Suominen wrote: > If it's okay, I'd want to post this fast, before adding KEYWORDS to > sys-fs/udev-209's ebuild > > Should means required now? Man if I only knew that last week... - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPG/gAAoJEKXdFCfdEflKPBUP/iRT+/nJ6Mv0Mv7R887sfLm2 /D4WbRClWyHVGt2SRW3+Cbspew0l5EicgqkBSJ/RLnm2WSB9cJDBaBURcq6yOA3f tPzbV0igAl5Ij89Ky8jloMv03WE/X9dMtXgM4eWnzOpZpGaTLGRBD+6bxEHnckyQ efgVEzWLcIuY8kbDebRlVkd1f0oGk72ctamKli0AbTl2LABz7eVGKT4yKmwpdQto E+D3JmbQbkstP4u2WEswZ6CuvQDHUBL3TiweVHGbR7gWbretwXHv6Z2WBG9ztqSS ilccz43b0ITNvDvXJOuwt8WrP8NBjPZ41BAMFNtVpw2EQ2wAqa/HbzUOqF/Lw6d9 azxm2TS3WHpbNrbmPMJzzUxlV2dk1i3uHFoYEYz3nuuTNBQ7cRyHhkXcmmvr5/Mf S2ZkUnB8srD0rlSkxBLBc0nnQvR16uLFXYqw5GHuSLE+6drm5G6LGPyjBISOQ+to 19zb7mDAIT60ZYvR+Z/qDy3VapxLysmb68BPwB7x9KRir9LlCWSkbVP86pLM2ogf jzNi/wnPCyGmH3eRWfS4W1dlBsJIX4UkmRiUkxQYrdmOuJ0W6NZ3goZcrMdE4bqe nNOqMmI6auAR3WeLs5wX+kOU4h0CkCJjPKXWACeT2/POEvF6QPoMrDF0BQqwHG1t MDbRCkyY3QrgPs45oW2Y =Wu3S -END PGP SIGNATURE-
Re: [gentoo-dev] New virtuals for libudev and libgudev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2014 02:00 AM, Samuli Suominen wrote: > > On 02/04/14 05:02, Matt Turner wrote: >> On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman wrote: >>> Projects like the Council, ComRel and QA are there to protect Gentoo; >>> and yes, people are (or should be) lining up to protect Gentoo. >> ... from QA. >> >> You don't seem to understand what Samuli is saying. QA is being used >> as an offensive weapon. It's a stick to bludgeon others with. >> > > Exactly. > > Anyone remembers what happened the last time this was tried? > > The "QA" attempted to force developers who didn't care if removed > ebuilds are recorded in the ChangeLog or > not, even while there was no policy in place that said they should be > recorded there, and nothing was ever broken. > People simply had different workflows. > > The whole existing team died with that debacle. I don't expect it to go > exactly like that, this time, as the issue and > people involved are different, but the point is, nothing good came out > of it. > If the people who insisted they should be recorded there had been in a > productive fashion drive repoman to be > patched for --echangelog, or discuss other solutions, we could have > skipped the useless mudslinging. > > Force is not hardly ever the correct answer. It might work in a > workplace, but not when people are contributing > for free. > So forcing changes into the tree by stabilizing a bunch of new virtuals and adjusting all the rdeps to use them is fine, but forcing discussion is completely inappropriate? Wow, now that I can see it your way I agree, I'm a horrible person. I'll stick to randomly changing the tree as I see fit with no discussion since forced discussion is so wrong. - -Zero > - Samuli > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPG34AAoJEKXdFCfdEflKYpUP/1ULS1KEdi2756pxr5Ay8k/G NZJ4LKfXzlAbVOlbhf3splq5NvWEDrItlexXp2rt2QhGUQoNl+4p5gtwPp9j9QBW 8h2OKpveeIF3mxvUnnOyapbeA9PBVoSd5cnRyvATv1g7QqvtFps0+5D61Pl/F9ii PYVbVuWt/FD4kCmNDCNVuwBt9ZR0eBk70cy482JNzJuH9TTFh/c3kU0PqA2CTkNy VVGX62/dWPLjKrJjKLaiRaVEtN7DDFC5yKJJn0wxa2TSg5SvwzZVlotcOE/DTwJv qu0tkBnoPiMnWIV5OWxTBPIOXGRKRXUD6zB3YzPdBISyHGMFsa2KDaDy4/DxsQPX brRg3Rr7D3l/vApFezYyTIC/SGmpGes4muZpI64WlMJf0LciUjocEJSqdxO3SMzo 0umuNi5FymPHnNrRjZV6MEQ6ft1J8QS1r6OPlKefzYV808D/hPV66F15m4CtvraQ DvTWCIAMtKpiLwuvCYSy77u//cLX3F+iLep7U6ciDXRTS7ccLLIW2dZV3C8e8aCA 2fvefbd90AzWG3YByNxMSNvE9GsgKyCWfNe9ndnlpE3Wra/4ROy+dV1MdpOTbfmW 595yRKSlLxqtg4cBFy9kaaHr5fQG+YA0QisnR2Z894VMwYt2+HGa55raGnCJw+Zv oEguJmsrxTKkLOXliLma =rTHl -END PGP SIGNATURE-
Re: [gentoo-dev] New virtuals for libudev and libgudev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/2014 02:41 PM, Samuli Suominen wrote: > > On 01/04/14 21:33, Tom Wijsman wrote: >> Okay, but this isn't what happened yet; because your plan was to send >> out a mail after stabilization for everyone to adapt the reverse >> dependencies, and I predict that that in its own would have lead to a >> discussion. > > Exactly. > > Discussion happens BEFORE a change. To stabilize something, and adjust rdeps all on your own and then "announcing" the changes is ramming a change down people's throat with now room for negotiation... that sounds vaguely similar to the kind of "abuse of power" you are accusing me of. This issue clearly isn't limited to udev, and sadly, until developers show each other some more respect, I don't see how this ends well. Making large changes to the tree and "announcing" them shows a complete lack of respect for the developer community, and I can't believe I'm the only one who feels that way. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPGz2AAoJEKXdFCfdEflKalgP/R8WlYTvlqXaaYzk0MMiXaJa QWBIaFka/AlYrOgTd0ktK0zow8x/cchD731cJ9qrtycUseB7M7c0sVM5Yc1FsfcY G8653AxaS2A6mIxB5zBQIm3BS97ze7GQjqN+o9XMhGC1hCt2KdJ0Fhz9EUQJhgTi mW1C7gYsB9T8fzo5nYJP8vn2+mTwGmz7TARNK2auCwlFsiT8VoapgaD86C4XXEO7 9gc2C209zipJTVEghXNlrzyzu8Wt60rXuN+Yce2rEOretJKkUxBT60R5aFOB9+/O hRXn4scYn1etB3hV7NeWF+Hjxf9T16ixBsrY0qz5raHz68KZ6PVLyvyca6TGtDZW KMlbwq5rHOr5zWgBi53ET3Xra2FeJyiOguQfBf3TivWmgXeoBldeb8aucNhjrDm8 6tjf2226uBXlE64em/p7wZ6dL6hbNMEUa1YmzMpXxjAhG1qafOrL+Wapq/iYilMc 0lJ7i2ZCXwaNaReGZV5T8wo0nI/iFXrcjlpqlXPmvfw4V4nd+Puobit/gie9pOio JxNigQUtwu2BlxF/aJjE/1TCEbcNuTt8ZhvWO8Rp0X+mWEtUZBAxrqopSvY/eIM/ gnDvk9oyAKtYKR74fivI7pKIJyy/e7VkC+TQHEdQtJEz6EYSSSWiCI1WoZfDSEKS NlkOIKUdq3fYCC9UQwR8 =tFuX -END PGP SIGNATURE-
Re: [gentoo-dev] New virtuals for libudev and libgudev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/2014 11:55 AM, Samuli Suominen wrote: > > On 01/04/14 18:28, Tom Wijsman wrote: >> On Tue, 01 Apr 2014 12:23:43 + >> hasufell wrote: >> >>> And this is going to get worse if people don't trust them. Currently >>> it looks more like a loose club, instead of a team with strong >>> hierarchical structure, which is the only thing that enables a quick >>> line of action if needed. And that is one of its purposes, afaiu. >> There is a strong structure present; for policy enforcement and >> breakage prevention, we have the ability to 1) act until there is > > And let's be perfectly clear here, nothing was, or is broken. Futher, > no policy was violated, none, whatsoever. > This is an individual, albeit a QA member, disagreeing with a design model. > > If joining QA team means you get to dictate, alone, how others do their > work, > even when they are not breaking anything while doing so, without the > rest of the > team, we'd be setting a bad precedence. > The QA membership is not a large trout you get to bash others with when you > feel like it. > Otherwise everyone would be lining up the QA team membership just to protect > their work from others. > Good one, 10 hours and 7 minutes of taking the good advice of comrel, then right back at it. I'm honestly a little impressed you made it that long. - -Zero > - Samuli > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTPGubAAoJEKXdFCfdEflK/XcP/RYca+zxRMqjjJOUrW3VNkRn lrfpRFdtPtxmoS4oU45TKwYNQRctJeARW+cBrr7yfKoge0v514FPwxg2GYQY1LuO x6nVS9UW7N6X2ytZGBAX07kLOqAD1xVAxUccSyQxuibOJO6RcdHOwHNGDdplQiIQ sLXc9xISNHlw4LsuonZdryGIV5abiOOa4sl3hfO5NPFblc+RixmsjN6VQjTYc/xY GyPYuTuMTWtRMfSeiqQQFFGA80XhKHuQ0CSMiSbnO88OQqQUTDV/Sn2rBRJPGnF2 3xscRztudUOG97fJe4EnHzcVjI99sRn1GnWMrYFdvw6NJCo+VbRfYp9Jw4MZ60ZN AcbnqvDLXjOHNPrQHOrCUlToXsc/Eqrhum3o4Jlh/XgPA4ObZz0B2tCamABrTaJv WGlWcHc5pB54Ll8oQej2eM9rOTm3A4Af/N1CDRf5U0PCgDFw4Xb0Y1KEkdqKM0RD 4hbH4TnnuLdoJYfKwvpE3Cb0NqQcqdGTFhxyP5hsLH1+P7ppz1c0NfIdWfAou9EN 9kWsiyQARTdiBPTN6E7aoFeQPyDv1xqcaMUvjrvhjtzb9TKjjCJqLmmE8O4YdVpt ENukW7ibtplbfQk8GALvXlfckJ1Gs871GJd1OgPlj6xnj8p5CLfGvLtc0/MppIDF 2ufWg5NdU43wm1inflgj =wJH8 -END PGP SIGNATURE-
Re: [gentoo-dev] New virtuals for libudev and libgudev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/31/2014 01:50 AM, Samuli Suominen wrote: > > On 30/03/14 23:45, Rick "Zero_Chaos" Farina wrote: >> >> Your input will be considered here with all the weight it deserves. My >> mask was to force this discussion on the list and it has done it's job >> well. > > So, you admit breaking the policy of gentoo-dev being a optional ML > for developers[1] > > I really dislike the recent trend of some newer developers trying to force > everything to be discussed here, even if the involved people have already > discussed it elsewhere with relavent people Given that the eudev maintainers already said these changes were made without discussing with them, clearly you missed some "relevant" people. Additionally, it was only after the added attention which I brought that it was noticed that the udev ebuilds had improper pdepends on the virtual. If not for the added eyes and attention who knows when that would have been caught, likely after stabilization. You are welcome for the bug fix. > > [1] > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?full=1#book_part1_chap3 > > "3.h. Mailing lists > All developers must be subscribed to the gentoo-core and > gentoo-dev-announce mailing lists. All developers should be subscribed > to gentoo-dev and gentoo-project," > > *should*, not *must* > > Likewise, http://devmanual.gentoo.org/general-concepts/virtuals/index.html > > "Before adding a new virtual, it should be discussed on |gentoo-dev|." > > *should*, not *must* > > You can't change the policies on your own without rest of the QA team, > rest of the council, and so forth. I didn't change the policy, I felt that your change was important enough that it deserved discussion, especially after bugs were found AND relevant people were mentioning on irc that they were unhappy about being left out. > > QA is for enforcing estabilished policies, not making up them as you go > based on your personal likes and dislikes. > > Futhermore no productive discussion has happened here as you masqueraded > the use of subslotting you supposedly want to be discussed, > to be somehow udev specific. I want the the fact that a single package now has one virtual per lib so that proper subslot rebuilds can happen to be discussed. Earlier in this thread, before you divulged into personal attacks, it was discussed lightly. Clearly, no one felt strongly against it, and with this discussion done, I am happy to be out of your way on this. > But that's not suprising as you yourself admitted you started all of > this only because you saw the word 'udev': > > Freenode, #gentoo-qa, at the same time you started this endeavour: > > 18:19 <@Zero_Chaos> granted, the udev changes sparked this line of thought. > I know english isn't everyone's first language, but even completely out of context this statement doesn't at all mean what you are claiming it does. I couldn't possibly care less that this was udev related. "the udev changes sparked this line of thought" means that the changes to udev made me think of how using virtuals in this new way could possibly be dangerous. I had previously not noticed the same was suggested (and shot down) for poplar, so this was a completely new idea which had not been discussed anywhere I have seen. Again, now that I brought it to - -dev (after you refused to do so) and no one else seems to care, I am out of your way, and I hope it goes as well as you believe it will. > So, congratulations for making the QA team look like a crapshoot once again. > > https://wiki.gentoo.org/wiki/GLEP:48 "In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council." Per GLEP 48 your actions of reverting the QA mask (the first time) was entirely inappropriate, and your personal attacks on me are even more so. While you flaunt the fact that the rules do not apply to you maybe you should be less concerned with how QA looks and more concerned with how your behavior makes you look. We can continue this pointless back and forth for as long as you like, but honestly, there will be no winner, only two losers. Let's just wait for comrel to resolve my complaint against you with no action and move on with our lives. I think we both have better things to do, I know I do. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTOdGAAAoJEKXdFCfdEflKdEYP/icwMgYxNfaUsqKJNFCznd7
Re: [gentoo-dev] New virtuals for libudev and libgudev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/29/2014 12:13 AM, Samuli Suominen wrote: > You broke the gentoo-x86 by masking these virtuals without the already > converted reverse > dependencies. No, I didn't, before accusing people of breaking the tree you may want to cvs up. > Plus I told you to not bother me about this until there is something > broken, or you get > this banned by the PMS, or you get this feature dropped from the PM. > Your input was considered. > I took the liberty to unbreak the tree for you. Don't ever touch my > packages again unless > they are broken. You didn't unbreak the tree, you reverted a QA mask without permission. A comrel bug was opened for this, I'm sure they won't care at all. Your input will be considered here with all the weight it deserves. My mask was to force this discussion on the list and it has done it's job well. Thanks, Zero > > > On 28/03/14 23:48, Rick "Zero_Chaos" Farina wrote: >> Recently, without discussion as suggested by the dev manual, new >> virtuals were added for libudev and libgudev. >> >> These virtuals are different than any virtuals use in gentoo in the >> past, and due to this, I fell the discussion step is critical. As such, >> I have put a temporary QA mask on these virtuals. >> >> All below information is based on my understanding of what is happening >> and why, since these new virtuals were added with no previous >> discussion, I can only guess why things were done as they were. >> >> These new virtuals represent a new idea in how to avoid needless subslot >> rebuilds. In this case, it occurs that libudev and libgudev (both part >> of the udev package at this time) can (and do) change soname separately. >> This means that it is impossible to perform just needed subslot >> rebuilds since the package udev can only have one subslot. >> >> To battle this, virtual/libudev and virtual/libgudev were introduced, >> each with the subslot indicating version of their namesake. In this >> way, packages which currently dep on virtual/udev can be adjusted to dep >> on one or both of the new virtuals and possibly avoid unneeded subslot >> rebuilds. >> >> All in all, this isn't a bad idea on the surface, but the first >> arguement shows immediately when this is scaled up. How many other >> packages have multiple libs with different sonames? Off hand, I can >> think of poplar, but I'm sure there must be more. Is it really >> scalable, desirable, or sane, to break each package on the system into >> multiple different virtuals like this? >> >> Discussion, go. >> >> Thanks, >> Zero >> > > > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTOIKAAAoJEKXdFCfdEflKq44QAJUOhKvqrVZKIEm074f6ozZF 0eo5dfAQTjcwdYWDWJQ8sKkc26rnrqQjHzGP/cm19lAQAzMceCIw5gKUNXovKwKi /Bl8u3oQIbwDqpqRQFs9kGcToLpyMgX8J+YhWg18IcfJvHWpdW5JR7/0Zuw8A+FI bqkRiXqBVe16uN0iy5JRVwYVcHxTvDCCU/oM+Vpy87+8FPUnzduh8HlY2NoH5nq/ D9TFISaNHkxuhTtVj+OahnHxP/9RkcaI3uZEoCKSEebSWKJ4kxlEoM2D7SBGjQWg kVcPsAddfVdumoShrQkEPEpS3jSlCKp9MP5MUur6xCPOOom/6XnOFQqO49MN2zjj udNWLY1c8pjAIwRLk9+CRCvwuiXfHxFh2FCDsf92LZ4D3Vwt2tb1tuXMllfMlmNL KcUV8GMRBE9Bwb8ovPvHCP78/tphLXr24OjoUhJw4UXa7lbSIVyXqjhTkTtkBWHb q6cIvmMvPdAkMttLKz+n5sNhYNeC+nR8L8y0uUayPuKGXWWwbvJz5Llfu6DcrrsA WkHBlywJz7sOwIHFTTHZqp4oijqHwdUCYiTGQ0GPbjQ7JW4HSEK9KX5MV1Jjr8lu nHdznf4LCLqY8NL56oHgwH0Y6fxlVne5JRW95R1ei5oL4yH5KgFg+fAA4/MH/bRN racYsCXksRf133Jv6etG =xzP+ -END PGP SIGNATURE-
[gentoo-dev] New virtuals for libudev and libgudev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Recently, without discussion as suggested by the dev manual, new virtuals were added for libudev and libgudev. These virtuals are different than any virtuals use in gentoo in the past, and due to this, I fell the discussion step is critical. As such, I have put a temporary QA mask on these virtuals. All below information is based on my understanding of what is happening and why, since these new virtuals were added with no previous discussion, I can only guess why things were done as they were. These new virtuals represent a new idea in how to avoid needless subslot rebuilds. In this case, it occurs that libudev and libgudev (both part of the udev package at this time) can (and do) change soname separately. This means that it is impossible to perform just needed subslot rebuilds since the package udev can only have one subslot. To battle this, virtual/libudev and virtual/libgudev were introduced, each with the subslot indicating version of their namesake. In this way, packages which currently dep on virtual/udev can be adjusted to dep on one or both of the new virtuals and possibly avoid unneeded subslot rebuilds. All in all, this isn't a bad idea on the surface, but the first arguement shows immediately when this is scaled up. How many other packages have multiple libs with different sonames? Off hand, I can think of poplar, but I'm sure there must be more. Is it really scalable, desirable, or sane, to break each package on the system into multiple different virtuals like this? Discussion, go. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTNe4mAAoJEKXdFCfdEflKDdAP/iZA0CcRY1TW8JYoZwWgkx6q KaY2jVRMVHDuIRHGv1IRPbhS0vhAxJ9ksX98gkV8fXyXaBrLe4CQbuRR5YhqHKiv Wlwn4V8yjT3VW+39Km3xUKSCqN+ERphMY1NXnu80Atx0cp6/kXPMPoxsUdvmFW// 0guIWQh7BamJF1T3U1GnuuexhHVnMBdsPPRn9AfpXSmUBUQ0C1E4l74Vkvwa6+7D +U0a8NDtiha7WreCt4e2luMTfmYUezv5uE5E+b/hZvCf9cg5BaPQMjQyldzqd+c0 kP29GsB6dxZ+BbDDlepvIll36gnAmgiYbipATmUxY9T2YY9dj34aLU/wdHjZJl5G 5NMDnhmkBTxmg5B5t5W+1JagMtFjNqPhayXcHYtU/0cinwWI2fG24rdiSRya30SX vVXzBUe7wMbYMe/mokjtPBraL1S4nL0Svvoft/qkvojy9hEezNX8caA/NkgEFJWO c1C920o8jrWB2MI5MnEnjs0DZRLI7MfXW2FOBtymignNjW7NSs/gZj62PM08pzD0 9vEBlw/Yku1s3uGmEYGECWTrZTqiYgMCHI50lw0hAmGF8L3OYO120j4Rybr1cqgV gmsFcHCGsUXlEyx+uIB1hF59w8vI0GzIDqwSDMtpQ8SlByrgKXd/B7Pzn1RZDMfO Fu7jIfz700SRT3hmnTDw =kF// -END PGP SIGNATURE-
Re: [gentoo-dev] Enabling EAPI 5 in arch profile directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2013 06:43 PM, Andreas K. Huettel wrote: > Am Dienstag, 31. Dezember 2013, 23:30:14 schrieb Mike Gilbert: >> I have noticed that the arch profile directories (profiles/arch/$ARCH) >> are not EAPI 5 capable. These profiles are inherited by both the default >> and hardened profiles and contain arch-specific settings. They are often >> used to override masks set in the base profile. > > [...] > >> Here are a couple of alternatives: >> >> 1. Add profiles/eapi-5-files/$ARCH. >> 2. Add profiles/$ARCH/eapi-5-files. > > Here's option 3: > In a few days the "one year waiting time" after making EAPI5 profiles the > default is over, and (pending revisit by the council and agreement) the whole > profiles tree can be switched to EAPI5. > This means the files from the eapi-5-files directory move to a more central > location and the eapi-5-files directory can be removed. > With that change the arch dirs automatically also become EAPI5 capable if > done > properly. > > See also > http://www.gentoo.org/proj/en/council/meeting-logs/20130108-summary.txt > > Best & a happy new year, > Andreas > To ease this transition, I've drafted a news item based on info from zmedico's blog about when eapi 5 was first supported. This is, in my eyes, the simplest way to transition users who may be on really, really, really outdated systems. It occurred to me I could make a minimal snapshot instead, but it seems much much safer to do this for now. Please review the news article. Thanks! Zero_Chaos PS> You can skip review of the body line lengths, I will adjust them to spec (72) as needed after the review, any and all current linewrap is from my email client. - -- Title: Profile EAPI 5 requirement Author: Zero_Chaos Content-Type: text/plain Posted: 2014-03-02 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: <2.2.0_alpha130 In its last session, the Gentoo council decided that the entire profile tree will be updated to require EAPI=5 support. http://www.gentoo.org/proj/en/council/meeting-logs/20140114.txt For all non-deprecated profiles this requirement has already been in place for over one year. If you have updated your system at any point during 2013, and followed the instructions in the profile deprecation warnings (which cannot really easily be overlooked), and are running an up-to-date portage version, there is absolutely nothing that you need to do now. If you are running an installation that has not been updated for more than a year, the portage tree you have just updated to is may be incompatible with your portage version, and the profile you are using may be gone. It is still possible to upgrade, if you follow these simple steps: 1.) Do not panic. 2.) Download a portage snapshot from http://dev.gentoo.org/~zerochaos/snapshots 3.) Unpack the snapshot to /tmp/ 4.) If you are not already, become root 5.) rsync --recursive --links --safe-links --perms --times --force - --whole-file --delete --stats --human-readable --exclude=/distfiles - --exclude=/local --exclude=/packages --verbose --progress - --omit-dir-times /tmp/portage /usr/portage 6.) If needed, set your profile to a modern one (typically named 13.0) 7.) emerge --update --oneshot portage Now that you have a modern copy of portage, you can go back to updating your system as usual. Please update your system at LEAST twice a year to avoid issues like this in the future. Thanks for flying Gentoo. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTEUvEAAoJEKXdFCfdEflK5lAP/RTivl0QjlB2kyWZbtVIURMR X6ELgIkBggrgYvwMqBdz8JG+YFc4Q0gi2xDz9QE+13ysUYCFUmibbasukb2WiVtA zNyoNHxoZQEmBuKzDNg3QzkcVsxD+SQ97fq3r2iRYN6tVXbDn5r+i4kCLivDws7y Knc3ankf9ShrY3qjJdH3M1xe4kRyX8RBeq2/5kvl43TLu1T3zLJ4bY+RlOX1lOJC MB01akcJ45gbJ1bAYrT0nN2Q0HC40tKV4I3uNFcllEkjOkv4vmMSQR2ZrcTo+f5C cAaiHTO4zDeHEKmmtI9j/t2ui3GVbelnooFPuH/6IS5NNmkILIo3a3UQsXgugzJX 7seAaGVzoxgMRUHoA9On5M1FWCFf6Z+JE/PbaJMhZUePVcivgGT8RvmnkSsIexHZ 4tjVlIjjULFLDz6i229K+RtmsO7b3EV+RXNw6hO8UIjz65QevZ84aNib8ipGJ+Lm b7xOCjIS7yNZAtb91PWiE/PoZC0MilAC2xBE6ex/dX1qZPCLpvCPTgQ7hu83GEBX h9gqYbMuL/Q+mHG/4PwKppMMmx///Hs/aowLRUGJdN61rxBu6VD69Shnxy3N4OO1 pTviiPh0xvv0HSHd61mX/8cdx7GEn39oyd3inwShFvE6cwtn1QqgbS0MZeMqQVX+ Ih3725/4uXsyM9NS0q3r =prsT -END PGP SIGNATURE-
Re: [gentoo-dev] Thank you
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/2014 06:00 PM, Denis Dupeyron wrote: > On Wed, Feb 5, 2014 at 11:30 PM, Canek Peláez Valdés wrote: >> Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs > > This is totally unacceptable. I demand you take your thank-yous back. > Who do you think you are to thank us like this, even with valid > reasons? Good manners will not be tolerated on this mailing-list. > > We have been trying very hard all these years to slack as much as > possible. Your public insinuations that any work gets done in Gentoo > are outright insulting. Since you have been using Gentoo for such a > long time, I dare you to try and become a developer to see if you can > compare to us. > > A good day to you nonetheless, sir. I agree, quit thanking us and join the dark side. Together we can rule the world as...well developer and developer I guess. - -Zero > > Denis. > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS98QWAAoJEKXdFCfdEflKuG0P/Ainh/i1CKZOv9fmnC07PhNu oec2SeXZjsnt3dv7tNGawt3XJLrzjN3N1OTflETAq0VfyYs8km93l3O131ROKhVL IVxsXJeW/tztYpArif+WzzkJJFfoy6fcINjh0KbLFv9s+R1URFpqhuCd43pdwOG+ JCP50BNuKxeb1iQzfW2H/aSKXQVTLP3ALCAIg3Bb3SH8RC9JZBFb1e79MnryKGme jLLOVpspy3CoiTM4nDadT+g4EHqxwOO5XEypmTPA5g1kfoJRtQjOcBEKwfK7M8sx KwLmcjjHAGfA+JJJrJJZkB1/NbkdCPjKvW8LyTkuu32NnthZipm7wUNjdIycYU68 HmluVChRG/WVuxUp9xOkSVJPscOLb0oEUaFM3LhsZu4WZhP6GuElweKJBfbm0+AE x2jmuBc4MAOzUOWqv1ySncXhK3fmcbrVn3I+TTh9C8scF52pDQjculwjx8ctjaXf Ny5xfftnXkPUQGnNIbaZfAarVM+80dlknHoxbxTxY4momVwNByfCAqS/d2JGl15g qu/f8SwNFBFydyMfAx+KlhDETEjZcIujbqRBRhli+5s5VERVWORGvZOe7DMPfkJl CPPHwBIWasqJ2VkjsyNxZ+pQTsdANsZcg7N4TV92oGfohm+wPJt0B39YEg7Fe1sq MOMVahen9J/uC2tdlVUy =vGp9 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/2014 07:48 PM, Tom Wijsman wrote: > On Wed, 05 Feb 2014 17:05:08 -0500 > "Rick \"Zero_Chaos\" Farina" wrote: > >>> >>> Yes, making the newest versions never available because the old >>> versions sink all your time really stops progress to a dead halt. >>> >> >> Your logic isn't flawed here, it's entirely missing. If version Y is >> stable on all arches but one, and that version is still using version >> X that doesn't affect any of the other arches at all. > > Can this be proven? Why are maintainers like WilliamH upset about this? > > Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063 I've already voiced my concern on his bug: https://bugs.gentoo.org/show_bug.cgi?id=500014 > >> If the maintainer doesn't wish to support version X any longer then >> they can close bugs wontfix. > > +1, but what about stabilization bugs that block other bugs? They stay open as a tracker, bugs track all arches. This doesn't prevent the work being done on the faster arches, all it does is leave bugs hanging around when certain devs think more closed bugs is more better. > >> Removing the last stable version on an arch from the tree is against >> policy. > > The QA policy meant to override this; to avoid confusion, I mean > including the proper workflow involved in this. But this has raised > concerns on IRC today, as it was made clear what the reasons are that I > was asking for; it's good that we do a new vote on this to properly > reflect what we really intend, rather than some poor voting that went > through a quick vote and didn't take everything in consideration. > Nothing in the QA policy says "ignore standard removal policy". Here is the standard removal policy, and I expect it to be followed: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html When a doctor tells you "go to the hospital as fast as you can" he doesn't mean "steal a faster car, speed as much as possible, and don't stop at red lights". Doing so would obviously be dangerous, and cause additional problems, just like ignoring the standard keyword/ebuild removal policy. >>>> Not the QA team's actions. YOURS. YOUR actions and responses in >>>> this thread. And the fact that the QA team allows you to continue >>>> to be on it, despite your obvious lack of interest in ACTUALLY >>>> having quality assurance. My actions are affected by it because I >>>> have to continue to attempt to discuss the issue with others who >>>> actually give a shit, and you just swoop in and say no, that >>>> absolutely is unacceptable as a solution >>> >>> The policy is made by the QA team; you are attempting to object to >>> the policy, therefore this is the QA team's action. This is their >>> action. >> >> Please don't claim you speak for the QA team when in fact, you have >> not discussed it with any of us, > > We did discuss this QA policy during the QA meeting. > >> and the QA lead told you to cool it on irc hours ago. > > That was minutes ago, you are replying to is written before that; > furthermore, I believe things are cool. Why do you think otherwise? > >> You are speaking for yourself here and no one else. > > I'm quoting QA team policy, agreed on by at least 8 individuals; that > policy can be read at the following URL: > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies > That policy doesn't permit removal of keywords/ebuilds without following gentoo standard policy, standard policy is available here: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html > If you still think so, can you show me where I did speak for myself? As I am also a member of the QA team, clearly there isn't a consensus on this topic. > >> There is NO policy that allows for dropping a stable ebuild without >> masks, discussion, and significant passage of time. >> >>> It is rather that I ask question to clarify what you are trying to >>> say as to get more useful and meaningful responses; but what I >>> receive in return is "pure and utter bullshit" on a "brick wall", >>> maybe someone else would say "no" here but if you take a closer >>> look this as well as the previous mail contains multiple questions >>> for you. >>> >>> These questions show interest in assuring quality here; it's >>> actually what makes up for a defensive style of discussion, making
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/2014 04:48 PM, Tom Wijsman wrote: > On Wed, 05 Feb 2014 10:07:22 -0600 > Steev Klimaszewski wrote: > >> Against my better judgment... >> >> On Wed, 2014-02-05 at 05:55 +0100, Tom Wijsman wrote: >>> On Tue, 04 Feb 2014 21:15:47 -0600 >>> Steev Klimaszewski wrote: >>> On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote: > On Tue, 04 Feb 2014 19:35:22 -0600 > Steev Klimaszewski wrote: > >> Alright, well, I've tried my best, I give up. Instead of >> having something working we should just remove ebuilds of >> working packages. > > s/should/could/ s/ebuilds/stable keyword or last stable version/ > > It is at the maintainer's discretion; and such decision is to > make it possible for a maintainer to move on when he or she can > no longer guarantee a working ebuild, to stop being > progress-blocked by it. > You know what - this is pure and utter bullshit. >>> >>> Why is this pure and utter bullshit? >> >> Because I'm attempting to have a discussion with a brick wall. > > Can you please keep yourself to responses about the subject as well as > give reasoning for them? That way, we can make the discussion feel > less solid and more fluent; I'll have to ask again, why a brick wall? > Keeping it around for "slower" arches does NOT block progress. >>> >>> Why is keeping it around for "slower" arches not blocking progress? >>> >> Let's see... having the software at least available, versus not having >> access to it at all... which one is progress... THINK TOM THINK. > > Yes, making the newest versions never available because the old > versions sink all your time really stops progress to a dead halt. > Your logic isn't flawed here, it's entirely missing. If version Y is stable on all arches but one, and that version is still using version X that doesn't affect any of the other arches at all. If the maintainer doesn't wish to support version X any longer then they can close bugs wontfix. Removing the last stable version on an arch from the tree is against policy. I have intimate knowledge with what ACTUALLY happens when people pull this bullshit - and that is a system that I can no longer actually work on. >>> >>> That is also what happens when a maintainer keeps around old >>> versions, as well as old bugs and support for those old versions; >>> as by doing so, the attention towards newer versions is lost which >>> causes much huger breakage than the one you have just brought up. >>> Manpower is limited. >>> >> >> And we attempted to come up with a solution for this, however due to >> the wording of a page on the interwebs that solution is 100% >> unacceptable *to you*, a person who is unaffected by it. > > The last discussion has shown policy breach by bending words around. > > Can you tell why it is acceptable in a way that doesn't breach policy? > And instead of working towards a fix that actually works for people who are ACTUALLY affected by the shitty policy, you hide behind definitions and pedantry. >>> >>> Why do you think this about the current and/or suggested >>> solution(s)? >>> I'm now going to take a break from Gentoo development because this thread has seriously caused my blood to boil based on comments from the peanut gallery (you) where things don't actually affect your day to day work, but your actions do affect mine. >>> >>> Why? How and why are your actions affected by the QA team's actions? >>> >> Not the QA team's actions. YOURS. YOUR actions and responses in this >> thread. And the fact that the QA team allows you to continue to be on >> it, despite your obvious lack of interest in ACTUALLY having quality >> assurance. My actions are affected by it because I have to continue >> to attempt to discuss the issue with others who actually give a shit, >> and you just swoop in and say no, that absolutely is unacceptable as >> a solution > > The policy is made by the QA team; you are attempting to object to the > policy, therefore this is the QA team's action. This is their action. Please don't claim you speak for the QA team when in fact, you have not discussed it with any of us, and the QA lead told you to cool it on irc hours ago. You are speaking for yourself here and no one else. There is NO policy that allows for dropping a stable ebuild without masks, discussion, and significant passage of time. > > It is rather that I ask question to clarify what you are trying to say > as to get more useful and meaningful responses; but what I receive in > return is "pure and utter bullshit" on a "brick wall", maybe someone > else would say "no" here but if you take a closer look this as well as > the previous mail contains multiple questions for you. > > These questions show interest in assuring quality here; it's actually > what makes up for a defensive style of discussion, making sure that we > keep ou
Re: [gentoo-dev] Re: [gentoo-dev-announce] All profile directories going EAPI=5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2014 01:42 PM, Rich Freeman wrote: > On Sat, Feb 1, 2014 at 12:35 PM, Rick "Zero_Chaos" Farina > wrote: >> >> I see exactly zero downside to doing this, so if whoever is going to >> actually do the editing of the profiles would like to work with me (to >> give me warning), I think I can manage the rest. > > I see no harm in this - it is just a tarball on a website somewhere > and a news item. > > I suggest you draft your news item so that it is bikeshed with time to > spare, then you can just substitute your intended URL inside at the > last minute, and then take the snapshot. I don't think you need to > worry about getting it down to the commit - just grab a snapshot > reasonably close to the profile change. > > Actually, I can't really think of a practical reason not to just do > the news/snapshot now. Nobody will see the news until they do an > emerge --sync, and if they do an emerge --sync a year from now it > makes little difference that the snapshot is an extra two weeks out of > date or whatever. Then there is nothing to coordinate. The coordination was more to make sure I had completed my tasks before the cutover ;-) I'm more worried about how long it takes me to learn how to news than the actual second the snapshot is taken. - -Zero > > Rich > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS78bkAAoJEKXdFCfdEflKyxMP/RMKtkoPP8es/EUPy7PxiorK wl6g2zmN3vM2OgCBmIIhC3upnz3teE/oMDEcTw0cMuFKHWjMcHb/h2kC0Lsm2SLM Re806U2xEJSKBgKtK5uesJYqzyDklVT6YLh58ELFCdBqIKHZ17SvDJ3L8xAecZsR mwNNoCvD0pjosDhfnTdpyS/QXKn+5iTW/1mbSNucZyvGtECrpTDDVtMZZT8le7kN Yx24PP3gVKn+G90dL8FzxXPtwhGpzSO9XPtuWsFc2D5UrtBfVoA6VwKrntCGxShw KaTDXCZU4kxyZZDAPIs6Ruzq5nSpiXRisj7BuorD0kNHaAiFPn2sM3TZNfizfHKs pfenXubvhe1UHtX8Frf4jpP0f98tEwf9yvGAavd4OoKdSzofCukzJ+AAbL7mrLTT d8VO4MetVkzFwSqoXpfcO6KSHJx3NmgxNiAEpPXzev3REL5jluHKxhm9Yb4s2LaU 9vLKRo2FSDuNwBrI78I7Jyuy5ByWxs5UPIiDhAvFOOoAN/aeOGd+ZhbgWVwMKuYP gbDNhXOPgIA2w3uh/n23+HGQqj/XV1uqFE1m+OomcvhjB5Xrq7P8tL3J688XTdz0 veKEesec4ND5zqgup98Pd3oH780BrBujxbnRVsqpUSGY96uly1pzzrHTpkHWgRBW uqbosEzrs31hNRG2VIOu =s5BQ -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] All profile directories going EAPI=5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2014 10:06 AM, Andreas K. Huettel wrote: > > Dear all, > > in its last session the Gentoo council decided that 30 days from now the > entire profile tree will be updated to require EAPI=5 support. > > For all non-deprecated profiles this requirement has already been in place > for > over one year. If you have updated your system at any point during the last > year, followed the instructions in the profile deprecation warnings (which > cannot really easily be overlooked), and are running an up-to-date portage > version, there is absolutely nothing that you need to do now. > > If you are running an installation that has not been updated for more than a > year, you have to update your portage version to current stable now, and > afterwards switch to a non-deprecated profile. I am 100% behind this idea and the council's decision, HOWEVER, I feel the most responsible way to transition would be to include a nice compressed "just before switch" portage snapshot. A news item could be drafted, that is shown to all users of portage versions which do not support eapi5 which directs them to the snapshot which they may need to use to successfully upgrade their systems. I see exactly zero downside to doing this, so if whoever is going to actually do the editing of the profiles would like to work with me (to give me warning), I think I can manage the rest. Thanks, Zero > > The deprecated 10.0 profiles will be removed after the update. > > Best, Andreas > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS7TB0AAoJEKXdFCfdEflKKxYP/R3Jh7LVgMt5Z9eAN4tBFOmB 7HHBAZ6RjAdbKR581IbfrCqnDLIZPy+M75s4yQ9NeoplBQQB5raYXl7Gs81ExQnh jO6Ytz8tT+z+DQlbJDmhPgknssilSE5eOU0iNkDvS3uh3ce4ScaL/D1KhlN7bi39 7T0Fvyi2+mfiOHMaB8044lsTjUAO2r/Qldv2+eZhGvUT5F/dBAUaa+wyBJNLM/Zi lp3PIVNuKzY3xmCdVAKmHRDp5xTvbGc6yS5rCbgWcJSsEGf7t47wVMT6yAopXnTb ofAmVF2KuzhoovmeE3R2x7oQ+wHGRT+l55RicacGez/6gZfgx9qkqtKuZEn5vwvM l8ZDEipYvgOGIzTOuWIOGFH0/u19zvp9oyTADkIxqIB8Jl/QwwS8EJKeekCG07NZ DxY2u+0LYc1FNHlr9/VA+Rph44T1Tm/SvdIXE/CUVPwA24yUx0s8iUBDkMZypRuT BlFSULe6BuJmzU0/+NKCalQXvLatVvzIEqwxjTple7K99PHe61JTUZ2HpMTe5bJ9 PU7o9afetJVUudYUOPYozG8CpQPzYM/uJtzmtGATqDdDw3rSsLCV4sEwyUfzmLDc mb/6iBfWJ8S75Qq5u1k7ewpg+x3CIbycgx0KRooU6GF8VmjYVg7eScJIQ9P09/M+ xxmnT+aZAFkOoWksnwi9 =BvZ6 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/10/2014 10:50 AM, Ryan Hill wrote: > On Fri, 10 Jan 2014 01:35:09 -0500 > "Rick \"Zero_Chaos\" Farina" wrote: > >> More to the point, "this specific use flag" appears to have no purpose >> what-so-ever. If a user can do exactly the same with >> CFLAGS=-fno-stack-protector in make.conf, and it would be INSANE for a >> package to dep on gcc[nossp] then this is has got to be one of the most >> useless use flags in gentoo. > > Having slept on it I'm starting to agree. My first argument was that on > hardened ssp is -fstack-protector-all, which is much more expensive, and it > adds -fstack-check and -z,now to the linker by default as well. The pie half > adds -fPIE but also a crtbeginP section for linking static libs with -pie. So > there are situations where you want to disable one or both, if only for > testing. But what I forgot is that hardened installs multiple gcc-config > profiles to switch these out on the fly. So there goes that idea. > > It might be useful to have these flags so we can mask them on archs that don't > support ssp/pie. But that's always been true and it looks like sh is the only > place we've bothered for some reason. > >> Not saying I would block this patch, not saying it has to be this >> second, but I see this use flag as a small example of things in >> toolchain which could probably be cleaned up if fresh eyes were to see >> things. > > Yes, and believe it or not I appreciate the input. I know I'm stubborn as > hell > but eventually common sense gets through. Well, that's why I asked for your opinion ;-) Now since I know you have plenty to do I'll leave you with this though bouncing around in there. When you are working on your updates, we would prefer that this "nopie" and "nossp" flags to bye bye. If you REALLY wanted a way to change the gcc profile then do for the normal users what the hardened team does and offer them multiple profiles. Obviously we should involved docs team at that point, but it makes much more sense to "gcc-config 3" than rebuild gcc with a different use flag. Again, doesn't have to be this second, but I want it in your head since I know you are working on this stuff right now. Thanks! Zero > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS0D3YAAoJEKXdFCfdEflK1HEP/jdF9nwxpDde8j4PMypeZSm8 FKG0l3MmMr6+2joKkgZSLqVebiTcc8OtCgpk6UJJVEWSpNMWqrjqX5oTkIBAJisr sGUVGJEAyDCCsNJwTtbW/sBKw5r5Xh1zLk92T55YhaWBMTJPc4UzSqhpr+TBZ8wJ T77XOIPtxOdZYjubGqIm4lSWsgT/o0F0S6kge75iYm81omuBtZpAze6ePE2DteTj IinauiMUhqkTYXv6AXdBNv4dDLiInyDrdlUIFbWlawxsx64Wpt77j3jA2fHrRmEf 8MPvoRzLpX/7DPMDaS3WyGBVpM8CPNTaxQiXjC+giXNj4jkJyop/m6Q4a00wYvQg C+1o6JMEsYNlrIuSooInFxQ5OqARzna4lFc7Jp6+eMaBE4NhYkPkxJ7KOerD3IvI yW1lSN5gte/zxgm3Ny/96Zw/6+Jx5ffQNc8bCgE2+TxDG0wwB5qZGn/w6dl6gFYX jXD5dFmw3C5T2HhTIZ6j9n8b0MNkT71CzFA2O4EzEyPrI3b8KTmU6PkppT/Vwlo4 EHc/EUWdjSCPH/FzzJdcNbFUdvLCigZQqvaggN3Qjh/YyJRECXz6Hy2M8VTOg18a XVE36Z5/DNeobeBQ5XaKLcb5po22wJueJzKFdEK+GaSewzn+FXsNCquVZV9Y3lZC epKNxmbxtX/Uqx8q9+74 =++P6 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2014 07:17 PM, Ryan Hill wrote: > On Thu, 9 Jan 2014 17:30:46 -0600 Ryan Hill > wrote: > >> On Thu, 09 Jan 2014 17:29:26 -0500 "Rick \"Zero_Chaos\" Farina" >> wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> >>> On 01/09/2014 05:21 PM, Michał Górny wrote: >>>> Dnia 2014-01-09, o godz. 17:06:52 "Anthony G. Basile" >>>> napisał(a): >>>> >>>>> On 01/09/2014 04:57 PM, Pacho Ramos wrote: >>>>>> What are the advantages of disabling SSP to deserve that >>>>>> "special" handling via USE flag or easily disabling it >>>>>> appending the flag? >>>>> >>>>> There are some cases where ssp could break things. I know >>>>> of once case right now, but its somewhat exotic. Also, >>>>> sometimes we *want* to break things for testing. I'm >>>>> thinking here of instance where we want to test a pax >>>>> hardened kernel to see if it catches abuses of memory which >>>>> would otherwise be caught by executables emitted from a >>>>> hardened toolchain. Take a look at the app-admin/paxtest >>>>> suite. >>>> >>>> Just to be clear, are we talking about potential system-wide >>>> breakage or single, specific packages being broken by SSP? In >>>> other words, are there cases when people will really want to >>>> disable SSP completely? >>>> >>>> Unless I'm misunderstanding something, your examples sound >>>> like you just want -fno-stack-protector per-package. I don't >>>> really think you actually want to rebuild whole gcc just to >>>> do some testing on a single package... >>>> >>> Or just as easily set -fno-stack-protector in CFLAGS in >>> make.conf. >>> >>> I never felt manipulating cflags with use flags was a great >>> idea, but in this case is does feel extra pointless. >>> >>> Personally I don't feel this is needed, and the added benefit >>> of clearing up a bogus "noblah" use flag makes me smile. >>> >>> Zorry, do we really need this flag? >> >> Yes, we do. I want a way to disable it at a toolchain level. > > Let me clarify. I would like to be able to disable it without > relying on CFLAGS or anything the user could fiddle with. I need a > big red off switch, at least for now. > > I think if you clarify this last statement a lot of the arguments will vanish. I believe most of us are happy to hear your thoughts in a little more detail, and will be swayed by them. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSz5W+AAoJEKXdFCfdEflKle4P/3pwjbSDuPy56TXvyH43/Ucg LvTtyycvGF5pw4UzNBPoao+E7F4E84MFIrfLGE3XpkH1J4v4SLXwh+CuHJHaSxJg Zx1C6zhk0HnAS2LZHDCuS14+zyOpF/VELOZAimr8V1UBTot3gyZUVvBIsXoJwKx6 3nb+abTHHIFDcSGJz6KM36dy67MMW2kpcKTx5Wu7W91232K8WY3v1KuNRtLBQkd/ /YNcpkW3fkA5Plk7sMTFb8iL6k2oajNw/3PKvX9L/MSBf+PmGKB7yA3Yt5Qu2Grw gUdUel/fCtXyhv1Had3pjeqZCgK7mFUuw6pAieQen2cYmAypLTC8D7JpaIBkJ9G0 cAz4lBB4EXc+l5mh2SS9D4LqL/4bWu3f7xFdeSuGcoxU1aL8/pgAvz0LpP7/o8ib BMdvwPcy5zn9W5+jkx5IZXidIpEBHzJKEnSR5+Mf39xn9z0nOrEvzGWxEHIerlWc hlHNU8x5wsZdnfJsY9tOfb5/hCOZW6uTtdvSR7eDFC6+xx2kBuiS+lC9Dtg76t1q VAiDOQIb1qgM9D6IUA+Q6WG2sWj3aTmZxfRYYQZ0DBGG266Rr2HaQaVDmWjU8W2u etxretxm0emYr8vHBPJD1XKwOCs577u4W5sVrQbZl+VutEVH+pqJTg0NOYxTeSTW CWAZGdV093+dQAa58/M4 =YP+O -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2014 07:12 PM, Ryan Hill wrote: > On Thu, 9 Jan 2014 17:41:08 -0600 > William Hubbs wrote: > >> On Fri, Jan 10, 2014 at 12:30:04AM +0100, Andreas K. Huettel wrote: >>> Am Freitag, 10. Januar 2014, 00:26:03 schrieb Ryan Hill: > Please avoid "noblah" use flags. > > http://devmanual.gentoo.org/general-concepts/use-flags/ > > ssp flag that defaults to on is fine. This flag already exists and has always worked this way. >>> >>> "already exists and has always worked this way" is not really a good >>> argument. The rest of the tree sticks to guidelines, so why not here? >> >> Agreed again. Saying that something has always worked a certain way in >> the past is not justification for keeping it working that way, >> especially when there are preferred ways of doing the same thing that >> are different. > > Sure, I'm just pointing out that nothing is changing here. It sounded like > people were objecting to the addition of a new no* flag. I agree we should > change them once we can but that shouldn't block this patch. To be clear, I don't believe the QA team has any desire to block forward progress including this patch. I think everyone is chomping at the bit here to see some improvement on toolchain getting more up to date, and more with the QA policies that have been in place for years. I realize eapi 2 wasn't "that long ago" for some of you, but seriously, it was that long ago. More to the point, "this specific use flag" appears to have no purpose what-so-ever. If a user can do exactly the same with CFLAGS=-fno-stack-protector in make.conf, and it would be INSANE for a package to dep on gcc[nossp] then this is has got to be one of the most useless use flags in gentoo. Not saying I would block this patch, not saying it has to be this second, but I see this use flag as a small example of things in toolchain which could probably be cleaned up if fresh eyes were to see things. - -Zero > > We don't have USE defaults yet. >>> >>> Now if you had said "we can't use USE defaults yet since current ebuilds >>> are still at EAPI=0"... that would have been slightly more informative. :) >>> >>> (Yes I've seen that there is work going on, and I think that's good. Being >>> careful when modernizing makes sense here of course.) >> >> Right, I thought someone had updated toolchain.eclass to use a modern >> eapi, but I hadn't seen any more on that in some time. What's the >> latest? > > I did, but I can't start using new features until I bring all the ebuilds up > to > a minimum EAPI. I'm going to start that this weekend. > > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSz5SdAAoJEKXdFCfdEflKq6wQAILiZN+BVZh+8XrEBsd4a0om aOk6Inj4zWMK2y5LvI+T29u1xMvko18lu4Vny4dv13w6OMXsE+nip+1nOhxNyJJG lCwiVWC603pzYw5am/q/XGg/GncjQFkx3FUSRlM8rJrRCQOyLinronojTtIG0GeV e4k4eHih+wx73agAHXdvLrXP0Ps11yYxY5+U1Rkjf9p4LwMCtJTAwidm0458YZSp 7+ZYJHiBQvLOpG+evcTx8r+7WqfROjIPpFsCXfuPvZiTbGalXK0hEp1rWZ3aDSsw wZyjo7cuucTGGDn58QRUIH5KLDZtPC0SVUZl9TVbT+rVbv/ugrboIH2rA33UxYr0 yUFj96gZCgVOHgmxsuOUhiR4R2yIDoFOFg7GEU1TL7ydnqPbxZ9FiYuwOTO5/6oN hqofWQgC9DgjVDB8V/9m4SON7xZbCsmUhlXM1BCCaDx4HlfsgyHn2QQThRwYM4Oq HHIA8dCBZytyhlZZ/E8qFlebkbBc7CmsU52htp/iI/eSVMBs7856ljzVbToyY95Q ClGHIF7zRRWW2tGNo9EurKt+U+esuJS6h2buRwRzWVW8nJYy3z11BnkzGp9vwTAc 1GO3kfruHDTtuvB7esSJAfCdz5WDQ/i7rdj5DkaSISrRL0sIQsgeGPDP2Z7+V4cq 0ItbZIIb/50u8JHNiucS =lrYq -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2014 06:09 PM, Anthony G. Basile wrote: > On 01/09/2014 05:29 PM, Rick "Zero_Chaos" Farina wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 01/09/2014 05:21 PM, Michał Górny wrote: >>> Dnia 2014-01-09, o godz. 17:06:52 >>> "Anthony G. Basile" napisał(a): >>> >>>> On 01/09/2014 04:57 PM, Pacho Ramos wrote: >>>>> What are the advantages of disabling SSP to deserve that "special" >>>>> handling via USE flag or easily disabling it appending the flag? >>>> There are some cases where ssp could break things. I know of once case >>>> right now, but its somewhat exotic. Also, sometimes we *want* to break >>>> things for testing. I'm thinking here of instance where we want to >>>> test >>>> a pax hardened kernel to see if it catches abuses of memory which would >>>> otherwise be caught by executables emitted from a hardened toolchain. >>>> Take a look at the app-admin/paxtest suite. >>> Just to be clear, are we talking about potential system-wide breakage >>> or single, specific packages being broken by SSP? In other words, are >>> there cases when people will really want to disable SSP completely? >>> >>> Unless I'm misunderstanding something, your examples sound like you >>> just want -fno-stack-protector per-package. I don't really think you >>> actually want to rebuild whole gcc just to do some testing on a single >>> package... >>> >> Or just as easily set -fno-stack-protector in CFLAGS in make.conf. >> > > I just reread this and we'd better be clear here. With ssp on by > default in gcc, if you put CFLAGS="... -fno-stack-protector" in > make.conf you will build your *entire* system with no ssp. You probably > don't want this. You'll probably only want ssp off on a per package > basis, in which case, add a line to package.env and set the CFLAGS for > only that package. > Of course this is EXACTLY the same as building gcc[nossp] which is what we are discussing. So afaict you and I are in total agreement on all fronts. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSzy6AAAoJEKXdFCfdEflKOY0P/2dfvjVAFTq9NyZqMgJe0j1/ sENGtTCAAxKWh3eoqPywDJpEarPYoIsctMUGbuM2Dx6kC1zv20klXiT9Oec5j8aG qnAogeCubAQD/AjDLI5VjDU5dAH7xUEEQKWPEEdjqfV1xWstW91f+tfPg2JkxpMS zeQtSAIhJJMRdcFXmmWIvbh8zAUczdxsEcdGBHSt97utbMnbJMOE1eGEWGqAfzWm vFYLnA8R/TZO//wkbkqNTAQjL3JV8DKScaqVyFxh5wQhTCLMN4QFVqnlSJGDiZPS bddylShRtMXXsqPmFmLIsFf9tY7N03+2U8Ex3l1ToEpBATK6kkwBtuVCv0tOPvp8 EYOOXjmHZSmsG37SUFMgZpsAfNCf6H030G1i9NEC2zOnW5i9vHWmL1rAVpVYGdu2 N3rW2QYPEQzIBjNOojsXp515okIzPt8biXcWGT1R+te2BUoEeNwLNco9zCJecL1H YZNSmmA0fwc/vgvKOh1kfV4VAFwmM/cHAlI7UPG9ypM6Fo/3dn7zZgUaXdQU2KeL g+UNaFDj2p8ob+2vIc5N0lNwSNgY/vms2DehXRAV52vwogxNBgTftJZwwQv+j25u g1JWGf/MOXbh7mfDDK5Xr10fHEui6hpeSofC3BZC8pQ6k1duB1rKituWhBzBJBPF w8AeXL74ZvsUwwUxwi4A =AtZz -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2014 06:01 PM, Anthony G. Basile wrote: > On 01/09/2014 05:21 PM, Michał Górny wrote: >> Dnia 2014-01-09, o godz. 17:06:52 >> "Anthony G. Basile" napisał(a): >> >>> On 01/09/2014 04:57 PM, Pacho Ramos wrote: What are the advantages of disabling SSP to deserve that "special" handling via USE flag or easily disabling it appending the flag? >>> There are some cases where ssp could break things. I know of once case >>> right now, but its somewhat exotic. Also, sometimes we *want* to break >>> things for testing. I'm thinking here of instance where we want to test >>> a pax hardened kernel to see if it catches abuses of memory which would >>> otherwise be caught by executables emitted from a hardened toolchain. >>> Take a look at the app-admin/paxtest suite. >> Just to be clear, are we talking about potential system-wide breakage >> or single, specific packages being broken by SSP? In other words, are >> there cases when people will really want to disable SSP completely? >> >> Unless I'm misunderstanding something, your examples sound like you >> just want -fno-stack-protector per-package. I don't really think you >> actually want to rebuild whole gcc just to do some testing on a single >> package... >> > Correct, you'd only want to turn off ssp per package and then only in > rare cases. You should never have to rebuild gcc for this. With ssp on > by default, gcc specs would add -fstack-protector to all builds. If you > don't want a package build with ssp, then just do > CFLAGS="-fno-stack-protector" and you're building without ssp. > This reads very much like "the nossp use flag is useless". Not that Zorry needs to fix that (preexisting and all that) but it sounds to me like it's safe to remove these types of use flags from toolchain. I'm really interested in dirtyepic's opinion though... sir? Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSzy0dAAoJEKXdFCfdEflKZJEP/3P/Gq3sD6aB9XDcsLxUAVqC vg10PuwhmNpJK6HiYO2F/C5TNv3J+hpkiYPDMgjChOTw+JvqGCeIYYKvKuumtIXV fjnHDW9IRD8BGHlNFF9xx3sGV9VMPYDNICkK3oeNQJPlZOVSbnVEWsaTju/CEA7e tMkeA93ULed9pSzSZ3OBAIwLH906Kh8hO+o/gcJDyBa9/tJrXKfS+jtd6zTMbVtO 8ruLjRUDTsYwt61uMFhV7R/eWlSagGIFDGbxop0JyhTZaB+zxvbm8wzmZck4Tc2J HFO4A289zFBVZESaDA4SHAYJHQTSMND1fzAB8X4sPEwNebmLwOinneuA7XYVRsHW svu/I3tUPjNTKimTSmjMySi7f+3QDYLIxQ8UY0PUCPKjdlNZMQruqCR52lTsjy8F n0EpLMqodD61B+aCkkBpdrt1sx/BJ4AISq8R51yiJecujPoSk1oj5gG1aFOPK/mG BIQqLL1c6TvbB4ECLVMh6YAfxRKcyCT8tlMZqu2rTRqtxQ+YlUnxwvIQV7ivQ5sL M8eC/HjVjd0In9v5GVxePa3NFfwwuswnFipi2mivniajmZYi8M8avSVLpv54Kvi0 cAysdf/FP4WA+iVCd5J+MKGygKKSmbyYZ9IHyE4yCyCNK+0+ZZcFm9YNy9nx8rAJ 4ctTVxoCTtA+B9p3MBnL =6a0w -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2014 05:21 PM, Michał Górny wrote: > Dnia 2014-01-09, o godz. 17:06:52 > "Anthony G. Basile" napisał(a): > >> On 01/09/2014 04:57 PM, Pacho Ramos wrote: >>> What are the advantages of disabling SSP to deserve that "special" >>> handling via USE flag or easily disabling it appending the flag? >> >> There are some cases where ssp could break things. I know of once case >> right now, but its somewhat exotic. Also, sometimes we *want* to break >> things for testing. I'm thinking here of instance where we want to test >> a pax hardened kernel to see if it catches abuses of memory which would >> otherwise be caught by executables emitted from a hardened toolchain. >> Take a look at the app-admin/paxtest suite. > > Just to be clear, are we talking about potential system-wide breakage > or single, specific packages being broken by SSP? In other words, are > there cases when people will really want to disable SSP completely? > > Unless I'm misunderstanding something, your examples sound like you > just want -fno-stack-protector per-package. I don't really think you > actually want to rebuild whole gcc just to do some testing on a single > package... > Or just as easily set -fno-stack-protector in CFLAGS in make.conf. I never felt manipulating cflags with use flags was a great idea, but in this case is does feel extra pointless. Personally I don't feel this is needed, and the added benefit of clearing up a bogus "noblah" use flag makes me smile. Zorry, do we really need this flag? - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSzyLGAAoJEKXdFCfdEflKo44QAJ4wYfgHdLYffTPaiXZe2ZJn 3jPxaZX47m7BjgdtePZZncClby5h84cG+Jchb0pn/a6K6TknpiFXLQzArsJbMH0N th7cuuuS4iFQMw2xq8hNAvGAdMF4R0+/OSpBkzlskakcCVRHgV+KCz9llimny4hB RbTXK9Irva0bwYb5IkmTq+/JVqHjB5DyXUYMu32vdvgz8uxTPXXHHO5HtPlkLeiq YsumFhnHFb5d+yPvPzZ3YSMJyuHHtBeZFCOJoirtxL08+yr5dZhgppEbqkMJcHIG r1xKxPqFSmccHSJ8mCZ+l3mvrSL7Akd7D9c7Rk6hZ8RpMQnxCTNb3/Twq6oqAqKm JfcU1B6rKIDz6eZOtMmVMyVcfnlo7MHO/resmFCS/BYN5AyqyfHgn+I4OU4IVCvQ 2jaZOwxeXGePgkwK37ebK/274N63lSkQAbaB0K43oqvsmtNuq+qZQQEm7jkY+0Vu SYKc3y4hXeLvexxteiR559fB7zJ1zPIsvvOWrqVP7euYezPMI7cjamz+7VHJYyH4 3RdGpro4Qg7OOTr42naBsWBW20nRTecWpm6kg0jyJo9eSD5YPzLq5r9ITcv7c6mB /6OxgqbVubzxpo9+kpY/11rEgQx5li4wKbLVsBY3n/f+tDCi1GNTu2k6ottdgrt2 XgsAKT4j/dUq8dhh80P7 =9pZW -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2014 03:58 PM, Magnus Granberg wrote: > Hi > > Some time ago we discussed that we should enable stack smashing > (-fstack-protector) by default. So we opened a bug to track this [1]. > The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc, > ppc64 and arm will be affected by this change. > > You can turn off ssp by using the nossp USE flag or by adding > -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same > patch as Debian/Ubuntu but with some Gentoo fixes. Please avoid "noblah" use flags. http://devmanual.gentoo.org/general-concepts/use-flags/ ssp flag that defaults to on is fine. Thanks, Zero > > The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and > ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard(). We will > make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn > it on or off with hardened_gcc_works() that will make some sanity checks. > > /Magnus > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSzxCAAAoJEKXdFCfdEflKohoP/iDVryOAlunTvMtrhHYlZAXn LTPbJRNMQ9bJB8bAd9ECRJ8Q92pAyQt+NyNgUFLtatI+UuiZM6t+dz4K0LcmMQka n5i6ILdJ14V0BRLGhRz+Xa0ZjpnYRJjCAWrFENTDY6wHc5ni0hSb32xBg84L6j/3 HzNFIWnQOp9dw3hH5OPNQrPXndPVYZMjYTfIADSGx8/4dL9A0GWPY6AXOz08NwuC oC+zkQi2xSXCb7eHTfkKcIW0TIOF7mFp8Z5LsdW5dm/8nCCLDVH7yxmxVyymyMpb RnraqCghiv5WOJVsysgivtNPzBwR3ATrNk4dl2qigZSGpJcDEgF2AtSv+YAVb1Ux wcGOJ5ZJizkMBdAo2pqUBeekXPT/LLWg1EtRvhFI3OLInhbwaHaF9kMWEmhwq2d9 sX6ZfoCmtvn4ZtG3fL++RqyK5QevKOXFCtN2pK9DVMjjgHgp6OtnmVXVCMuZTztI uqI3XGVvDc0dNIwgxI6KIEfV4/S05Q599hLI49YJVniPknp+sUnsYIdQ+mKztwDf XON5Fq/Yzt07G1FqZMutEpVMjeTjVckpcLgbFlWz+lO6/xIrqJUgnLUNTXTQf34r n54Rw+WWIGUWAQqwK3bDh9N2etLzG8p8TqhzEXSCMKXP0sjbX1zzJiYl1roMMpu3 nTFjVJbwpgoaw8OR6FW4 =tSUd -END PGP SIGNATURE-
Re: [gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/08/2014 03:27 PM, Robin H. Johnson wrote:
> On Wed, Jan 08, 2014 at 09:14:43PM +0100, Peter Stuge wrote:
>> Robin H. Johnson wrote:
>>> Comments:
>>> -
>>> In bug #4411, comment 43, vapier noted:
any package that does dlopen("libfoo.so") without the version info like
".so.X" is broken.
>>> In this case, the lt_dlopenext consumer is explicitly testing multiple
>>> versions of libusb at runtime, and picking the correct interface:
>>> it doesn't need to depend on a specific version.
>> vapier is still correct and the consumer is indeed broken, it does
>> too need to specify the .so version in the dlopen() call, at least
>> in the case of libusb.
>>> This is also because the lt_dlopenext interface does NOT accepted
>>> files versioned after the .so: it needs the filename with no extensions.
>> Hm, that seems limited?
> It's NOT calling dlopen directly. It's calling the lt_dlopenext
> interface from libtool. That iterates over the possible combinations
> that end with ".so", and never iterates over the numbered suffixes.
>
> lt_dlforeachfile actully complicates it even more, but also doesn't see
> the numbered suffixes.
>
> So should you're saying that we need to change libtool's code now?
>
Or we could just stop randomly moving libs across the system and
breaking things then hackmeating things back to a "working" state with
gen_ld_script.
The whole reason for having gen_ld_script is because people wanted
dynamic libs in / and static libs in /usr (which seems insane) and it
broke everything (because that idea is insane). Maybe we could just
install all the libs together (either / or /usr) and stop pretending
that what we are doing isn't wrong?
Just my 0.02$
- -Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSzbhaAAoJEKXdFCfdEflKsJ4QAIhT02bWH1FxtZG5ALMQcEmr
tnj9YeulX5zp7NCaX+k4MfUn/VgSCAlcjPcWhJW2D2nYIhAFs8uUUb75jhgaFiOr
CIE5PamUE4FeE5NJ3tp2W2T+OXECmo0D0FUBg1ceDBadXDHncwjHS7Go3jTKdcsP
BgVTda3kigoN2BTfj4Gd8WBL2qFMFbRSQlZ9RcmiWTKCNTRvp2bMovgCMpOSgTwg
wIozmzaBTcYJH3TVC2p+Vkf0EZI00nMHAsLVyI/hbT97YVAxZWJG7N5UayK6IxBs
zUxREifT8ZEDXliWuJLBIa6S6HiujViZeKty/1axuMPonM7oEBXeGKS6dT1IJz3J
Hq1HEdccu66rfY1q8BakbKoR4SH2jeQhjP3Uaf/1NXb0sTRRqd7M9rnoTgmMMTfk
HQw8iUWgrHoEkE/VV/2L8kAVAdYPP+Igpyqobib+2gLD6wiufCXRUog0jGtYMCZA
wmGi43zWbXSqDhZ8tsyFLaHVbSqBlNRdiSW3XDB4hIrrveEF4++Cd0ecl3VIyXii
gGxSNJajZxGXtDwQer2dF15J8GSi6inZ+ZJLSj30EcTnPzsLcdcZItnE9m/getQs
3OMMDqnTvfYw/HrT9xcnOhg+YP2+NuufpOXXbQTbJXyQm0uDn6iFKIXVUPhek9R7
SEtDxmqBYrL95+c9IvQq
=8D0j
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: new global USE flag "srcdist"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/01/2014 09:40 PM, Michael Orlitzky wrote: > On 01/01/2014 09:13 PM, Rick "Zero_Chaos" Farina wrote: >> >>> What use case is there for having the LICENSE apply to anything else? >> >> Some of us do redistribute the entire source package, so it does matter. >> If it doesn't matter to you as a user then you can always leave it >> unset and you remain completely oblivious to the change. > > I know, but if you take a pristine source tarball from upstream and > distribute it to some third party, why should portage be involved? Portage fetches the files for me, and I assume if I am not prompted for license issues when it does, then I can redist the source and bins. Clearly that is not always the case. - -Zero > > More metadata about the licenses is obviously a good thing and I'm not > saying we shouldn't figure out a way to make it available in the tree > (we should). But LICENSE is first and foremost a user interface to the > package manager. I don't like the idea of overloading the portage user > interface for use cases entirely outside the purview of portage. > > My objection is not strong, in any case, if this solves some real > problem and is the best available way to do it. > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSxNJvAAoJEKXdFCfdEflK2TsP/iIsgz/DQ8DEG7er+aqslg3z LJFbEQ0/lBJ5/eSWrDcPeFhgHrHkXIuliZFgQJ2saMqLY9FnyZA1vIHwOIHlC14E hs43qyU2rfT2VwzrUIMjvwOBP9EzDFi/dSEYWxy9WnLKSEWgXADGNLMw42LujAGg s2f3UFTULdTaQUr9lhrbx1Vh91WtJrUBTkbkks0u2yuJSHZBMNFDrPqJ/LhqjHda ZlhW18RXH/dsy/gCtYBfKysiiiY/jiKiAGMnVW5N597LO2jT7G3BBvexYe3tIyFi 96jhGLXQB2G1GzsNGw9f09VoCIvRz2OfXNZhHzMtDwIbjAvNxof9uAlHirAtlm7s 9K6OTdVt/zPsakosiCASQZm1mmde1rF0zy3x5/AKm6l9O3fuLZlJaQ60oJsVGKie z9FPJW9tJRRGNdHBzoL3PBuvavKQKlVF8IbhpE/7BCJQl5hcUmaV1K0when0FiGH koOLo4iR6llPfTMk17GMQ+RQINA9uauFJoSemUSjgM4haMxveZ8QcN+nXvJDUDX6 vbd4ywprX9S4/O5whk1M99CzvUJkjb9WjqGYtZgzxQy+THwnJ/O8CPCXSRa5Ig0Z KehsdJ6tf2U6y6BxBFSNaOTM56kSNijBg8hhtBXJEE/7JB+AEVDmRV3+psXIZSa9 PcJPp65fClCzPTa7fWU0 =CklE -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: new global USE flag "srcdist"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/01/2014 08:51 PM, Michael Orlitzky wrote: > On 01/01/2014 05:28 PM, Ulrich Mueller wrote: >> Hi, >> According to GLEP 23 [1], the LICENSE variable regulates the software >> that is installed on a system. There is however some ambiguity in >> this: should it cover the actual files installed on the system, or >> everything that is included in the package's tarball? This question >> was asked several times in the past and arose in bug 492424 [2] again. > > Why do I as a user care about the license of a package? I want packages > to be in @FREE in case I need to modify (and redistribute) them. But I > only need to modify the parts that I use. > > If an otherwise-GPL package pulls in the latest Justin Bieber CD with > USE=badtaste, that's not really an issue for me, because I'm not using > it. I'm happy to install the rest of the package with the USE flag > unset. The CD might as well be a separate package with a different > license as far as I'm concerned. > > In essence, I don't want to *use* code that isn't @FREE. This includes > the installed files, of course, but also the build system (that I use > temporarily). We could generalize this to "any file accessed during > emerge" to be on the safe side. That ensures that if I need to modify > (and redistribute) any part of the software that I use, I can. > > What use case is there for having the LICENSE apply to anything else? Some of us do redistribute the entire source package, so it does matter. If it doesn't matter to you as a user then you can always leave it unset and you remain completely oblivious to the change. - -Zero > > >> I've always preferred the first interpretation, because the second one >> would inevitably require us to repack many tarballs, in order to keep >> their license in @FREE. This would for example include the Linux >> kernel, where we could no longer use deblobbing, but would have to >> provide our own tarball with firmware blobs removed. Not sure if users >> would be happy if we wouldn't install from pristine sources any more. >> We also have mirror and fetch restrictions which allow us to control >> what tarballs we distribute, independent of the LICENSE variable. > > I think a better solution here, since these files are *installed*, is to > introduce a new local flag (e.g. unfreeblobs) for the kernel that would > append to LICENSE by the mechanism described below. > > >> Nevertheless, I also see the point for covering the distfiles >> contents. >> >> Within existing EAPIs we have only one LICENSE variable available. >> (Extending it would be possible in future EAPIs, but we would end up >> with a very long transition period.) USE conditional syntax is allowed >> in LICENSE, though. So I wonder if this couldn't be used for the >> intended purpose. For example, for specifying licenses of distfiles: >> >> LICENSE=" >> srcdist? ( )" >> >> This idea was discussed within the licenses team, and the overall >> reaction was positive. >> >> What do you think? >> >> Ulrich >> >> [1] http://www.gentoo.org/proj/en/glep/glep-0023.html >> [2] https://bugs.gentoo.org/show_bug.cgi?id=492424#c3 >> > > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSxMtZAAoJEKXdFCfdEflK4uIP/RAl9JWej7SInRWRkMRFTiWe SAGcvNUm7qbVKCPYWDKp82+3fN6wEXSWLRcB2nCS8jZy8adzEOF0Oqvym17J3sEI wfiB3lI5VNCkx7lX0wJiYIbCmKVR6PgwTdeBGcDIzdgU2TPygXLADbBu7n+54f7U XAWcKPQRcuAzBFxCzuL1yWQzBuovhTU9HMelPaYPkXUGvi+LWlfmDBXe2mG1gfD+ U8sNOyHjwuidR6slr9RjxFAkH5ItVzeRBMiE92kHurZpm06sVaqezj0Oj1PovgqS ap/S/ncTQa7BrhmdzEIAqaLko/bpxJkjdWvEhj+MPQ453Et5+RvztE1h5KUdXrFj QU/oKS2Pmh75cROlipSfN628cdBDYQ8x/eB8XIZDPKd4uc7i43tpYf8njbNNrLlG jdioBnXEowJ+UQ/5vDM1s8ev3FToIfZRU1nFxREdJEYXx4qVhrZ/8yBlv7RWGcbs IsCJEtbrUFAcNBMowQ6eN2SfWGrx8lpB+Qoh8WhsUR7XMuyBQYB0jCOOfeV8qDWd kZn/t2+0daTxo70KRTLiVutHbqAaBjG1BF0iwZhS5YGmDufc2hm0fKgu7tzZb/HU Q0jA9hgWLvAj4dqek7qp1j21af993tZadIR1gjU0WgY0HiEHFYmY1xqy8GF09ZgX 39Jvtx4tu9UEpgk0ERYA =aSba -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: new global USE flag "srcdist"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/01/2014 05:28 PM, Ulrich Mueller wrote: > Hi, According to GLEP 23 [1], the LICENSE variable regulates the > software that is installed on a system. There is however some > ambiguity in this: should it cover the actual files installed on > the system, or everything that is included in the package's > tarball? This question was asked several times in the past and > arose in bug 492424 [2] again. > > I've always preferred the first interpretation, because the second > one would inevitably require us to repack many tarballs, in order > to keep their license in @FREE. This would for example include the > Linux kernel, where we could no longer use deblobbing, but would > have to provide our own tarball with firmware blobs removed. Not > sure if users would be happy if we wouldn't install from pristine > sources any more. We also have mirror and fetch restrictions which > allow us to control what tarballs we distribute, independent of the > LICENSE variable. > > Nevertheless, I also see the point for covering the distfiles > contents. > > Within existing EAPIs we have only one LICENSE variable available. > (Extending it would be possible in future EAPIs, but we would end > up with a very long transition period.) USE conditional syntax is > allowed in LICENSE, though. So I wonder if this couldn't be used > for the intended purpose. For example, for specifying licenses of > distfiles: > > LICENSE=" srcdist? ( unused stuff in distfiles> )" > > This idea was discussed within the licenses team, and the overall > reaction was positive. > > What do you think? Assuming this flag is not set by default on user systems (since they obviously are not all distributing sources) I think it's a very positive change. I myself would need to have this flag set on my build box and it would help me better adhere to the correct licensing terms. - -Zero > > Ulrich > > [1] http://www.gentoo.org/proj/en/glep/glep-0023.html [2] > https://bugs.gentoo.org/show_bug.cgi?id=492424#c3 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSxL8cAAoJEKXdFCfdEflK4bQQAKwJmkeDgm3IBcX06QqcDmJ+ QqYyE+SLJdJw2Fs9iXExEDa+nc9/6QOZkE1E6AA4wji/jKHDpp7ddnXCVfgNALaS KaAlsG+eiJk27C/sfpyT+Nmvd+FPzLcm9cNp8YjOn50BlDfVFUxoE5M3woJiIn/m gRbwHZhNVWYnqzHjOwiEhs3mUC6quu9N3c3QPY2k0lKspGW+3yqEqy8wZng9Wli6 8nMa1DXg92fk9gcmgpHAYTl0+gBtvv0LVa70fYu5Y+aGJAQEUclaMAlSi0ES4DYi 7YpEjB2HJOWXFH30DJdhv2E4v5MTHzARgjCGHv6jXvHZfIoS7PbDIbQ2IBpkOpSP kyOF2Aj/bWoIvFKzMGPWcDzwQwnfvJ/M615NTgGMZL/Iv04Pdki8W2qTvxsH17m3 NvEtdoMrtyT1gvJaLg8/Vsx2EaBYp47iwK81vPHgqQ7TsypO2v5G70Nqk6ogARgF gqp524/LUca/mfhKp6LlWT9TXvu2QziE24QYtHQ0mlWer9+KBKX+++dcDyXmF+ww KAiz9wsHmMdXsCb5/C2xA3RQk+4lePlFJiYeYs4Ix6/CgdW35w+BjtfAiWNz5rpy M5IRAtKQO/VJQlLjfERDfyC2hdSPAqoW/wrmAZ15VqoPnsNabrp8O3fO0+j5kEWq WZS6YVfKSghARUAzyP4g =7nB6 -END PGP SIGNATURE-
Re: [gentoo-dev] dev-lang/go
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/30/2013 03:48 PM, Emery Hemingway wrote: > I really like working with Go, and would like to see a means of merging > Go packages with Portage. In short I am asking if anyone else is > interested in a Go project. > > > For those who aren't familiar with Go, I will sumarise why Portage and > Go do not play well together. You can fine go-mtpfs in portage already. I packaged it, with a lot of help. It's terrible. Worst part, it can't reinstall. You can install, and uninstall, but if it is installed you can't install again (so emerge - -e @world would fail). By all means, have fun. - -Zero > > Go is static linked by default. > The Go compiler creates static libraries and binaries. Libraries > compilied with different versions of Go (1.1/1.2) may not be linked > into the same binary. > > It is possible to compile dynamicly and that may involve using the > GCC frontend, which is probably less tested and less optimized. > > > Go libraries are usually unversioned. > Libraries outside the system library are resolved with an import > statement that specifies a source code repository, such as a git or > mecurial repository. Most often Go libraries are installed using the > 'go get' tool that clones a repository, and simply assumes HEAD/tip is > the best revision to build against. There is some support for using git > tags but it is not well documented. Often these libraries are very > small for the sake of reuse and to keep APIs simple. > > If all that sounds bad, thats because it is. Is it worth versioning > many tiny libraries or do we simply cache the repositiories and blame > upstream when things stop compiling? > > > A have made an eclass for Go and an ebuild for the bitcoin node written > in pure Go to atleast prove that all this is possible. These are in the > 'emery' overlay: > http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=eclass > http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=dev-go > http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=net-p2p/btcd > > The eclass it a bit of a mess but it works, having done that, I would > say that making ebuilds for every go library is tedious, but can be > done almost entirely with boilerplate, almost every time. > > The eclasss installs go source and static libraries > to /usr/lib/go/gentoo (source code and .a library are required to link). > The problem is when Go is updated, this folder may get wiped out, and > if it isn't, those libraries will be incompatable with the new release > anyway. > > The other solution I see is to make a Go directory in /var/cache or > something like it and just manage it as a cache. Libraries may come and > go but that is fine. Bare repositories may be cached in DISTDIR just > like the git and mercurial eclasses do. Doing things this way may > require a specific utility for Portage that wraps the Go toolchain, > which I would be willing to create. This utility could probably > automatically resolve and fetch the libraries that are required as > opposed to making an ebuild for each library, but that raises the > problem of assuming the developers of each library maintain consistant > quality and security. > > > The problem is Go makes it trivial to build from source, but it does > that in a very different and less precise way than Gentoo. There is > always the option of build bots and installing binaries to /opt... > > > Emery > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSweOYAAoJEKXdFCfdEflKaf4QAK2JNcVGg4eSvVXpkkgdwKlO xp3Dm8ao6Ly/DuqD1wSQUghsaCaw9yD0bzlnLOwGQkHhFhAxqj/wpyLdKAr6rQ64 YqtT5WIFdymuB/rSO+0D47zfyjQeFLUGbiiSLMTrTyqol2SexchlVu6mLKLDM0rX pJctl4iERzHKHF7/xdQv90vBkUgQsRlN/YlGYUXO/6P5CDJU+T2+rGlps7yN/z+h oaZrVJxNHExdTCbIhnpfKOVSiBisVG2dlwJKL0FFq9EhJph+hrxe9CaD8rMNKGkL Suc/6rT4vFmBmb32/Lzy4x9dfxD6n12vwQBn8ZctJnoqfniVx96S4xmwrBtG3hNH 7JenDriuVUuIkUut45+okBUu829PDt0qs+LRRBQejf4DdnkFKJGg1W+97IwVGlTc J/qz+sEdoLTD88zd145iMf79TonmDwDxGxoDEiGs69250TC0WWWnP0x799p0S7uq +2iOunm2oRB2HAiGg/T/rC+C00/pE441ZWX/zXtDphVe3oOsQ8ieZOL/U62+vb6e /VaUp9iTQrssRvRuIpvC0Oqt+2YGlUQHFEAHb/5HHTBFhrdZLyC3edai7+VNIEy3 UV6B82MY5sUDhHPY+b2RpVlrkuhN7AqZWebI7qapVzU3gg8liyE8LWW6uvgz7wTF 8BWuxvBPwaP/1RczKaeV =Yv0m -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/14/2013 07:59 PM, William Hubbs wrote: > You make some good points. I'll answer your questions as best as I can, > but we can consider this thread closed. I will not try to put the > virtual in, but I will come back to the list soon and start another > thread. > > In a nutshell, our networking is a beast, and we should try to simplify > it some how imo. I'll write out my thoughts about that when I start the > other thread. > > > On Sat, Dec 14, 2013 at 11:24:10AM -0600, mingdao wrote: >> (1) What is "the new network stack" provided by the newnet USE flag? > > That consists of the network and staticroute scripts which are part of > OpenRC. The network script sets up interfaces and configures static > addresses only; it will allow you to run any command at any point in the > process of doing this. What some people on Gentoo do not like about it > is it is all or nothing. You can't start/stop/depend on a single > interface. > > The staticroute script is used to configure multiple static routes once > the network script has set up the static addresses. > >> (2) Why is dhcpcd referred to as a "network manager" in the same context as >> wicd, networkmanager, connman, etc? In the sense that dhcpcd is not >> sufficient >> for security protected wireless alone, as is, say, wicd; and is not a >> replacement for true "network manager" apps. DHCP client != network manager >> app > > This is a good point, so I will drop putting dhcpcd on the list. So wait, who makes the call now? dhcpcd is totally a network manager for a lot of people who don't need wifi. It has init scripts and everything - -Zero > >> (3) Is udhcpc provided by busybox not sufficient in lieu of dhcpcd for >> stage3? > > I think udhcpc is what you get in stage 3; if dhcpcd is there, I have no > idea how it is getting there. > > William > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSr4GkAAoJEKXdFCfdEflKoacP/3SvAZCABR0uJnZtE5Om4ZLx qnT0Tmdh9asrSQZdfLykYVms8WXkmfG7S/C2O+acWxaTSHP5oNp1KrWufketuKob i+CS9PjnF/EsRyj1Xw/XmYUfOKzrOeob+ePS3iYIw+y8kegQp0A12O60jJhVEAtQ 0aK59HhOZtDPvdA0A2c8X3Ar1LEFy/TbuCB7wO7BhfMlNZMr86cdy2xVSGcZfAaT ri9B0qvK22L1HckN21nPbA7e9tM5DB9nio02YuB54Yng0Z2dS4wL5pdniftrIlMd ah3svtRozXcd3VyRJAu26ONKWzQCrUeqZN6qR/x5JSJBjElHbyN1ah0wMvhyujIV QfTyukokIEiSJSgGw5B5IhmnwBVXNVzZHVI5J7LwGOGzR1iNM3QIwuH54Ws7PLvs 62G4m+Lybl+tqkVOv/BZ8/xY1JxHARJYFIthjlRtQQyG6/aaFIxpbGmzso65gMyK 9Q9kSj3dppG9wAzrhEfQ17qEwfqfX1JhvBrPJdJxSIfHiiVS8kDBSXT5cWmA1GWG JVek8SBMCr92STEzfBd8vNE5UCcvrl5RO3uu1xZBIgK+gCNJEnbTKET5EHbuZrRJ 4s0JEDuXMGM82AaQC5O4DEpUH0d48O/IzmXey9UyExV3Vsu1BlIoOV7NFCfXX6Pd k44DP5R36SmSSsY3MYI8 =hl2B -END PGP SIGNATURE-
Re: [gentoo-dev] New global use flags: 3dnowext, mmxext, ssse3, sse4_1, avx, avx2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/15/2013 07:20 PM, Andreas K. Huettel wrote: > Am Montag, 16. Dezember 2013, 00:34:13 schrieb Matt Turner: >> 3dnow: Use the 3DNow! instruction set >> 3dnowext: Use the Enhanced 3DNow! instruction set >> mmx: Use the MMX instruction set >> mmxext: Use the Extended MMX instruction set (intersection of Enhanced >> 3DNow! and SSE instruction sets) (3dnowext or sse in cpuinfo) >> sse: Use the SSE instruction set >> sse2: Use the SSE2 instruction set >> sse3: Use the SSE3 instruction set (pni in cpuinfo) >> ssse3: Use the SSSE3 instruction set >> sse4_1: Use the SSE 4.1 instruction set >> avx: Use the AVX instruction set >> avx2: Use the AVX2 instruction set > > What's the point of these flags? > (or to be more precise, are they really justified whenever they are used?) > > Usually the set of cpu instructions should be controlled by your CFLAGS, and > I've been actively patching packages (that do not do manually coded assembly) > to make such flags unnecessary. > I think this is a great time to point out three things: TL;DR Some packages are sensitive, easier for binpkgs in certain cases, broken build systems may require it. 1.) Some packages have really sensitive cflags (mostly these packages offer USE=custom-cflags). Packages such as app-crypt/johntheripper offer a bunch of cflag options for optimization of supported cpu features while not actually using the user's full cflags which would yield poor optimization or broken code. I can't say I'm in love with this situation, but facts are facts, and turning on USE=custom-cflags seems to inevitably yield significantly slower benchmarks in the case of jtr while the use flags work well. 2.) Gentoo supports binary packages. In the case of apps like johntheripper (and a few other crackers who wish to remain nameless) these use flags are really helpful for the users as portage can automatically know it should rebuild the package for higher optimization or w/e. 3.) Broken build systems. Forgive me for the term, but packages like libpng seem to require arcane configure flags like "--enable-arm-neon=$(usex neon on off)" to enable my neon fpu despite passing -mfpu=neon. Retarded? Probably. Fact? Definitely. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSr4e+AAoJEKXdFCfdEflK9TkQAJ0AnIQMcvDKwo/WWLmsoZHh B5WD1WrXwTl2xkwBs64lRBw4tFl1zU14zHvFmC3T4rPd6aEA2J7DNiYAnztGGTNu RWeUWYL3Qs+RJ4jASssJrMQmc3aEHEEzqMBE/yFL+x3ioeTilrROq+P1UlwoyUBh 6wJtkFiuTE7/DeqxhSaE81JvPVxRVt/i0nJoTvN6Kd4WLOzHZejekANErXaDF9FA MFXLI9OpQ4lY5QrZMJ7msSZJA0DnGt9Hi16QHtaaDQ0MPlJmtoVJlulsc14QgCCk a73+ndo20apOqAUOTy1cxXGxbrnU4TcDB16e/Sfc4eqAWiDEugXT6NTH+hnTegQ5 qE3N6genNGvRTTchVmNemnSs90UPTFhKhC5fqOo7hyqokpK3mvbU+tKL4NoOKjIQ LyoaghSRfzFcQhpRaEGhviGnm+Mvs9wSglBonob4PShrlcB2mpoZicA7oPuaE6Wi UC52KoryvsXtVxe5djziwd/1kgaC60wF1LnJ9s0BzxSoWMyibuD7wv5+hI5G9sQf 0zg/uzGlFVrMKjwCFz0Vr4STDRVAIULeKlbfMACzOE1jUGw5TXLjdWq+yMCTN0eH jqYo15IkPEC/a9+P+3fMVOL+7ZvQj5neoqSn1d0dEqo3y5d8Z1lZIw/ZYosWWObd qr08PGwWw+fElOa5BnSj =hhoR -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/14/2013 04:57 PM, William Hubbs wrote: > On Sat, Dec 14, 2013 at 08:47:01PM +, Jorge Manuel B. S. Vicetto wrote: >> OK, I see what you mean. >> To be clear, I'm not ready to have a stage3 without netifrc. If / when we >> update catalyst so that the new stage3 is the sum of @system and >> additional packages, we can move netifrc to that list. > > Actually I'm not even sure how necessary that kind of update is. > > I didn't quite follow what the reasoning against my second proposal was. > > Once openrc-0.12.4 is stable everywhere it is going to go stable, I want > to add virtual/network-manager to the tree. This would contain a list of > network manager providers. > > I think adding it to the tree is good, because we have other virtuals > for multiple packages that perform the same function -- virtual/logger, > virtual/mta, etc. > Excellent idea. since busybox is in the stage3 and it provides udhcpc we don't really need dhcpcd or netifrc or even really iproute2. I have no problem distributing stage2's if everyone wants a crippled place to start from, but this talk of removing base net scripts makes no sense to me. It interferes with nothing. It blocks nothing. It takes almost no space at all. There is zero downside to keeping it. Until such time as someone tells me an actual downside to having netifrc in the stage3 I will be reverting any change which removes it as critical breakage. You will know when this statement no longer holds when I specifically state that on this mailing list that I agree, netifrc is a problem and needs to be removed. Until then, please, the bike shed is green. - -Zero > Once that is done, we could easily add it to @system then I would drop > the netifrc use flag. That would take care of the situation if netifrc > was the default provider. > > Then, if you decide to add the function you are talking about to > catalyst, we could look into dropping virtual/network-manager from > @system. > > I'll attach the ebuild below so everyone sees it. > > William > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSr4DpAAoJEKXdFCfdEflKXQgQAJvKeM+avFF381dem8FBpxBC FVRc7StBNwcaK3k0J3on32HXVAxLGAD+digxD/j1WYS3CUr5xkcM6JOKXAPXOnTr c6AKrWZpe7UjyqWNY94KVWV+IFXsOUwsaLND+llPVIi5Z+zy0/Cj5qOCQcy28QO2 csdPWykqeyaoD5pPLTXI8wSIm3AyMLryTYkBAiAR1k8CIbSodRK6Rfsb9f7jijTR 8Bm8/zpVZN+wBymzHExDENdNFuVZAr3b8Jz5jVqom+TbiWk2VpeDO2Oo3Pr62q+R 9briW7lE5pyn3GOj3YuRFCb8mUq/r961jCybXbTpm2UE2auh2jSW7yHvnV+yfEcl tlles7SF+xsb4FysKwNI08nTSGHpVR3j5LVBk21VvNtFtpoaczLhJYqXt29TmfQE WtUAe6M1c4BlOnJc1J1vsQiEJ/fWrByTXJavW7hxnb513gy2CC2wWY2d/3ROs7g1 iSZQC93W09WPpKu1TbBGd+sh3NdZHZYE9F5HLOKTrpOPOC38PDjJoqiM2h26lwqh YhA2jpxKvvpyrBgZPigIrlLHDv3n/nx44SRLc37SR2Y/sjVWU3EoI0JQ0LNsXVLP 7RwWyOPdkTsX38JP9JU6nQCQlHkY3NGcaJ3CXxEnCmnzn2XqXhKFd8Rg1Cj2U1ID AIJJuqOGJZxuwfoCbUhu =/wy0 -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/10/2013 01:46 PM, Steev Klimaszewski wrote: > On Tue, 2013-12-10 at 06:23 -0500, Rich Freeman wrote: >> On Tue, Dec 10, 2013 at 5:31 AM, Steev Klimaszewski wrote: >>> On Mon, 2013-12-09 at 20:33 -0500, Rich Freeman wrote: >>> You're thinking with your x86/amd64 hat on here. >> >> Actually, I probably just underquoted. I am well-aware that there are >> issues with ARM, hence my previous suggestion that it might make sense >> to vary this by profile. >> > > Definitely - but then we have to do everything in the profiles, and at > least for ARM, there are currently 6 profiles, and we're considering > introducing a 7th (neon), and we will need to add aarch64, which will be > at least 2 more. I suppose we could do it in the base arm profile... > >> Let me try my post again, with a bit more quoting: >> >> On Mon, Dec 9, 2013 at 2:56 PM, Rick "Zero_Chaos" Farina >> wrote: >>> What if he wants to >>> put a stage3 on a disk for his amd64 box from his arm box? I'd love to >>> see him emulate an amd64 from his arm to install dhcpcd. >> ... >>> I really don't like the idea of having no networking in the stage3 by >>> default, however, I'm becoming more open minded on what qualifies as >>> networking. What I'm wrestling with is this, what if I want to slap a >>> stage3 on a device and then access it from the network? >>> Almost nothing >>> in my place has a monitor (amd64 and arm alike) and I use one of my two >>> laptops to talk to everything else. >> >> Hit your head on the wall because it doesn't contain a kernel? >> Stage3s in general aren't functional systems. >> >> Insofar as much as he was talking about ARM I get the point. Insofar >> as he is taking about amd64, not so much. Which he was talking about >> in that paragraph I can only guess at. >> >> But as I later said in the same email: >> >> If it actually had collisions with other network managers I think >> there would be more of a case for removing it. >> >> After all, we stick openrc and portage (the PM) in the stage3 and you >> don't exactly need those in order to run Gentoo... >> >> Rich >> > While you don't need those specifically to run Gentoo, the point of the > stage3 is to have a workable base to start with. So people are very > much free to yank out openrc and put in, say, systemd, and rip out > portage and add in paludis, if they so choose, and make those available. > And from the traffic I've seen on the systemd list, it looks like they > are adding some sort of networking to systemd itself as well, so we > probably will need a virtual at some point. My specific point of the > email though, was you saying that a stage3 in general aren't functional > - but they are - they are the very base of a functional system, and you > simply add things on top, or replace things with your preferred methods. > A stage1 or a stage2 isn't particularly functional. > To be exact here, stage2 IS what is needed to bootstrap. stage3 is what is needed to have a semi-functional system. If everyone wants a *MINIMAL* tarball to start from I'm sure releng can put the stage2's onto the mirror so that people will leave my functional stage3 along and quit saying what they don't need. If you want nothing which isn't needed past the bootstrapping of the toolchain then stage2 is what you want. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSr3/KAAoJEKXdFCfdEflKWNkQAK0vLGjGN96EUimf8kXQxNYJ GSA9lOIGbdoaf0oG1917m56/4RoZfWJ4SH+5ylajIf0wBrZB+mrL+740msnq+XNz xUpFZjB/cliYprv5WxpH+HjsvD8/vOvDZ97nj4IfPwoT33ntu4aTeHbKQ9uCNkA4 FD/LJ+lZliPOIaeji0Gzmnp/B16s09W+Aa1F5gZ7TNCnNA3uchQPAZarT4BmThQB H88/Vo7s5SxfBTTuSv54lLdFPesTz65jTzBPIA35nggrCZHiCrc73zQ+gfiMDUuK q9eyA1MkvjX7NNdgL4hSFARUw+wYiq2mCaBc+rbG8x5xATR4P+U/NU9kU/ZbfcUQ tVUIQ6txuGhD3vyvxUYN4mWmuRyl9s9z9sUvVmGD7JRt9lCioLwN/IDz0CQpCVtD L+e68xrfcNR1vsc9isfo1wV5y9eVgenO8etq7xxQinXW8iEkSyPSablKcTrIRh3f U5b67wkikXP/Fhtvha6XGr/PYGCK2KTxc+Vo0a2r6aenJSk9WVDKlBcmIt92MKYh CZvzz1rNgtrbSvwY8f4YxXo4XGIUUYeQbj+DksCfVPaYXjvb75rC/axuYSMyGM+D 5WFDUoGdSOrXAI4hgvDLSp8aQvJ1mRq/8Uw7iR+KTxAEYXaIW3NFRhRGaz4iSe2I Amni8AvCnKWaEt5w57Ox =RxMv -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/09/2013 10:28 AM, Rich Freeman wrote: > On Mon, Dec 9, 2013 at 9:50 AM, Rick "Zero_Chaos" Farina > wrote: >> I can honestly say most of the time when setup my arm systems I'm >> unpacking the arm stage3 on an amd64 and then booting the arm device >> with the base stage3 and fixing things from there. I suppose it is >> possible to use qemu to install things, as long as I don't mind >> pretending it's 1999 due to the slow emulation speeds... Yeah, I really >> don't see an improvement here. It works fine for "I'm an amd64 user and >> that's all I'll ever use" but when you start talking about smaller >> arches it really starts to become a hassle imho. > > Ok, now the concern is becoming more clear. You're intending to boot > directly to the stage3 and not chroot into it, and so you want the > stage3 to be a fully-functional userspace, though you don't actually > need it to contain a kernel/bootloader. Correct > > How do you even log into the stage3? Do we not disable the root > password by default? No, we don't disable it. It's trivial to set without chrooting (steev has details in his response and that isn't he point of this thread) > > Can you boot off of the minimal install image instead? Not sure if we > have one of those for ARM. Actually, any boot image that sets up a > network and supports chroot would work fine for your purposes. I do > realize that many (all?) ARM platforms don't have a flexible > bootloader like x86 typically does - so I'll let you speak to what > makes sense here. Sadly no, again covered by steev in his response we don't off anything bootable for arm at all. > > Following the handbook, the network is established by the boot CD and > all you do before chrooting is copy over your resolv.conf. In that > environment there is no need to have a networking system pre-installed > on the stage3. Well hold on there... the handbook doesn't mention anything about emerging your choice of network manager just yet, and when everything including dhcpcd isn't in the stage3 you will need to do more than copy resolv.conf (which honestly I never do anyway) or it won't work very well. > > Oh, and if I'm not mistaken the stage3 is based on the system set > which is established by the profile, so if it made sense to keep > networking around for ARM that would be an option. > I grant this is an option, but what about guys like steev? He has a large stack of arm devices and like 1 amd64 box. What if he wants to put a stage3 on a disk for his amd64 box from his arm box? I'd love to see him emulate an amd64 from his arm to install dhcpcd. Now granted, that's being a little pedantic, as he could probably use one of the gentoo isos available to boot instead, but the point is we are removing software that gives the user a choice under the guise of giving the user a choice. I really don't like the idea of having no networking in the stage3 by default, however, I'm becoming more open minded on what qualifies as networking. What I'm wrestling with is this, what if I want to slap a stage3 on a device and then access it from the network? Almost nothing in my place has a monitor (amd64 and arm alike) and I use one of my two laptops to talk to everything else. Say I want to rebuild a headless machine, what am I supposed to do? Unpack a stage3, install some network manager manually (netifrc for me) and then boot? Granted, we already have to do this for any device which is wifi only as wpa_supplicant isn't in the stage3, but to remove this ability from wired devices as well I'm torn, I really don't think it's a great idea. I really feel that while the rest of the world is trying to get more functionality out of their hardware we are trying to save ~200k and possibly crippling user experience in the process. Is removing ~200k really worth the potential downside? Honestly, if we are going on the merits of smaller downloads let's argue about using xz instead of bzip2 for the stages... - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSpiBiAAoJEKXdFCfdEflKuWMP/j7S40wYWxGWbI34Ij2U5dSG l11wJYdAP0k9bLs4rhDvJG56EaTyBJJYvfDCz+W2XF01MyNcdQfH2BzqEifp0ZOD kI0x81xzIqpb4YC1KvJXQxStDvs1Nxp3KbCX+Jg2hdkMv4hlHR7NF/g1gUajC8eA 8tKdLcqIz822REqGtShGLYO9cjLaHZhGr/rFlxyK9ReQqj5cCdmEZ1MKN0Kb/DSa gQf+pmdecXXjCbF3N/5eihcQDrKe2UbXuKM/nNaiVw1ETnI+gjn815ofUNCc3Ynu jXZC4jse+MVQC6D6i3ZJi6o1VSlrGJmGDDxBSUtBPc7kSgFnaAz3AYC/izeIFtb9 VNQEmrcDjO5qKdZphc5ht2NW7uOBCZbpMoFmSj70cZK+NhJhaJPWqzUNu3mJLCUF 72W89HCC3oTbpPtMVQHz9F3nmzYhH+QfrEXGd96woTyjcsZYwXvY8UDm486gsdsR aGNJCN34RXQvsLrsJdxJWaHJex5w2UHkBsi5IQkJniD1grq+CModEWiaqfD6Fo/y WXT1LUr3/1cgsLFU3E5VhgdYl873z2oNUHisWR37XYDN/T3z4AZh1gEYUD30wILw vctPg/8dJAqcLQUkgqFvtAmlWeY/MPUaqpJLOkwcgN/Zmyw5LNfdyPH//5oT5G++ vYyFkaxsIzPnnAb5omme =6FAB -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/08/2013 05:25 PM, William Hubbs wrote: > On Sat, Dec 07, 2013 at 12:52:08AM -0500, Rick "Zero_Chaos" Farina wrote: >> 1.) If we are going to stuff this into @system then we probably want a >> USE=nonet flag to allow users to not pull anything in if they really >> don't want it. > > We don't have to put this in @system at all. We could just have a > virtual/network-manager, like we have virtual/cron, virtual/logger, > virtual/mta, etc. None of these are installed by default; you have to > choose one as part of your installation process. The more I read this > thread, the more I agree with this approach; let the user make the > choice as part of the installation process. > >> Just as a side note, after reading the thread up through this point, I'm >> terrified of the individuals who wish to remove networking support from >> stage3 entirely. If anyone wants to push that idea then that needs to >> be addressed by the council. Period. Such a major change is going to >> cause a holy war, and myself and others will actively revert any change >> which removes net from stage3 under the guise of "critical breakage" >> unless there is council direction that says we are no longer including >> net support in the stage3s. > > I am in agreement with Rich and Peter. This isn't a matter of breaking > the stages; it is a matter of us getting out of the way and letting the > users pick the network stack they want. We do this for the kernel, boot > loader, etc, so I don't understand why you feel we need council > direction to make a similar change for the network manager. I am softening a bit, but I'm really concerned that the stages all of a sudden not having net is going to be an issue for people. Maybe I'm mistaken, but it is hard for me to imagine that moving to a stage3 with no net anything is an improvement. I suppose you can't download a stage3 without net, so you should typically be able to just chroot in... I can honestly say most of the time when setup my arm systems I'm unpacking the arm stage3 on an amd64 and then booting the arm device with the base stage3 and fixing things from there. I suppose it is possible to use qemu to install things, as long as I don't mind pretending it's 1999 due to the slow emulation speeds... Yeah, I really don't see an improvement here. It works fine for "I'm an amd64 user and that's all I'll ever use" but when you start talking about smaller arches it really starts to become a hassle imho. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSpdiZAAoJEKXdFCfdEflKQ4kP/1RRWpXE2rN0Y74c9GW24l7W G3oFLQABgFd+8Osq+bKhFaY6uQ0pmV5Cz+a1cj9fa0LnyCumiEL+k+Z6LnuCdqat rZCQugvP3shvcWYVxKPjR6FEfXjGE8cPm+C32vV9oo0sDfAwjcflYFrXoeTTF07E Tp/r318TllEQ50KdeLzD9uBBxePFFClygYvppVEWfNUbSSWiB+rkvN2dF6LDCLBi lpYsozOEpRAoyCQYePQ/eo6iRHmWu39iq4qARek3UXKvZk6h+4qr4/EVtrG3v0A1 0d9mmMAySDQwLPR+CrpN19MD+4qgFjPPIVmdfG5sSU4CM3jf4elap55X6aircWzf m1CsIPxaBmOicNUNr3OMPn1vr/Sufd1jgC6wwaZRp77POqlpzEqKM9y6JCkF7xy8 2z8Enl7TvwIzre4f7qK7u/HXSvaUX8F97TI09XkzuMlrk69WMMzsmxLtngZy0I96 egKCsGsKKF8k0biolM0hav4R7RPTVdK+/3U6SJwF+QSTZay/dyQpG4543reNuarr y8uoeIrXA03RE71BRBeRArgBeR7PpoUld59IP+XzCdCWb5GqZYAuE7zmfFvvctnk Z+M3KhwSzyqA8Pie6YTTlTyBl7uyr6Hqs0vfiP14ctVKtIkiayE8Q2XjW9i+zODA EjwJy84Q3uQXjU2kxIDU =WYkG -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2013 07:42 AM, Rich Freeman wrote: >> Honestly, I'm not really sure why anyone would want to make stage3 less >> functional than it already is but honestly net isn't something I'm ready >> to give up just yet. > > It isn't about making the stage3 less functional, but about giving the > user a choice. We don't stick a kernel in stage3, despite the fact > that everybody needs one. We don't stick an MTA in the stage3 despite > the fact that one of those is pretty hard to live without. > > Now that Gentoo apparently offers a wide selection of network > managers, perhaps it makes sense to have the user pick which one they > want to use. Choice is fine, I love choice, but to have a user unpack a stage tarball and find no way at all to handle their networking that's just ugly. I mean we could just have dhcpcd in @system and let people figure it out from there (wouldn't be my first choice but it would work) but I would say it is rare enough to not need net that removing all networking options from stage3 is near suicidal. I can do all kinds of amazing things on a system without an MTA. But if I have no net I can't even install net - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSoy8/AAoJEKXdFCfdEflK+a4P/056EtlWAr12QT7HdeoLhL2d +OQ2P53jd+fChB5NlrxKLot/+hvf+0PuJXkJU76hDBJ+1g9UkjSsYy1YGhPQ0rTU d5Ugqn0ZWIrON5QLx4CKH9XUjuN0jW2IlXXGpQApCrsBKv28vRM/oTi9jvC27IAP IdvD7QBUyN4L+K9z8cOWa1jckZahCrNrsWzgfoCDyJfDep+qeRXe0EbriHvXyfBm iT295qLUWjR1577bPRNwe7/H0tAe+yoexcJa/M3U4KiSX5qxlqwxr0aN6lFRNevj 1hB7xONTLa08sjx/NxzTID0zMoiZSlmkBLk/V3rj6uYkaFsjo89NvAfNhKZXerWf sLG/ivFKLFdeghZe6ItTDxIToTm0EnMPI8by8ZRD/xZ6MMre1QnDhODrVx0uMPl2 DRcoe3wItI1ZlX33I+ktF7iP5QZUvL59k15jBCoSnmU8mxSyM+REB/5O7IgLJvGI +SMoQB14+WwE/jDvz3HVqCifkwU2GDg3t3NT7lUq8yinovGjISufSuDdPY/croFl kgCLJ5JlEkHkv3EQPyce0ad6zkf6gpc4rWKv3hxxpSNDkKQ7CJyd51zF9S0bWztx 4KjAB5GJRNVxCEcWuh6F8/cSlh3yGTxrbJRh8M3SL1l3JPAo+xcK5nFwZ9Wz/ubk 3jpHrLIuH6+71NPsbZc/ =8QVC -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/03/2013 04:11 PM, William Hubbs wrote: > I would like to add a virtual/network-manager package to @system which > has the following rdepend settings: > > RDEPEND=" || ( > net-misc/netifrc > >=sys-apps/openrc-0.12[newnet] > net-misc/badvpn > net-misc/dhcpcd > net-misc/netctl > net-misc/NetworkManager > net-misc/wicd )" > > Does anyone see an issue with setting it up this way? > > William > I see two issues here. Both are rather trivial to solve imho. 1.) If we are going to stuff this into @system then we probably want a USE=nonet flag to allow users to not pull anything in if they really don't want it. 2.) having dhcpcd in this list will cause everything else to be cleaned out that that is bd. imho, dhcpcd shouldn't be on this list at all purely from a safety perspective. The stages will have dhcpcd so they wouldn't end up with netifrc afaict. Just as a side note, after reading the thread up through this point, I'm terrified of the individuals who wish to remove networking support from stage3 entirely. If anyone wants to push that idea then that needs to be addressed by the council. Period. Such a major change is going to cause a holy war, and myself and others will actively revert any change which removes net from stage3 under the guise of "critical breakage" unless there is council direction that says we are no longer including net support in the stage3s. Honestly, I'm not really sure why anyone would want to make stage3 less functional than it already is but honestly net isn't something I'm ready to give up just yet. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSoreIAAoJEKXdFCfdEflKKdIP/3fhppSUlXv60Ah1T1AECisC ssISEgKx5RsW608NnfpaYpmXdLgpDW5aSZDqXsIIBUP4/E4gTdP/gJqP36A4wsM3 HOwckcbsbTwtMquVngnpJ/stSCdzN/67lUelVxQwE+e90kZjihJnzRk1jhr8Ejxm 6J7G4m71T/OeE4ldZ/HeCliFpT5gPJNA1JVTcZoXkNIrggbvHFI8aQnLEDF6lX2E 1WjiW3Vq4Quz5cLNi1rE8di+HMRVZQVC4M1m6TtzyQP2Zzic3pwR4cGM/F2hLTvL EhQeZQpIix8qzd0MTonCEhOGpMcWBEBvI8+8gZNp9xeZ6ibBY8fRheT+OlVCXpVF +m07KABgiMRqQQHsMOgJRNSl9hocIjDEUQaxmvvTqXIDeElEEy7MOKdST7okWtrb bI5GNBrYc0JPEroi0uE6pvI7W8g9vS1y6hBQcpIQXxgJCccVx2TTUhF65on6tzNx NTqph2WAWtrPS3oIjGfbbOk4bujSP/OaOBN2HAuimZ4PW2hbOoW0mtSNUItGWXGY o+8OnIrday7aWloT6CLByqWNLqfgTWFEJvBzVd5vuLAlkVUWCQgGx0XWgeEJHEeQ zAxX9rcn6z4ACB9v+Xs96lkxHcjNPrHcjRfaQYDlm/OxliDe3FrryfrRtxjGKbws ZQYvnajkTjK4UYEEF8zf =eY8S -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2013 03:28 PM, William Hubbs wrote: > On Sun, Dec 01, 2013 at 11:20:15AM +0100, Alessandro DE LAURENZIS wrote: > > *snip* > >> The other two cases need a clarification: >> 3) -netifrc -newnet: no network stack?!? > > That's correct, you do not need one if you are using something like > networkmanager or dhcpcd in master mode. > >> 4) netifrc newnet: ??? > > Both would be installed, but you still have to configure the one you > want to use. > > Also, the other message in this thread is correct; the netifrc use flag > is temporary. > > I originally planned to release openrc-0.12.x along with a newsitem that > instructed you to emerge the netifrc package if you want the legacy > network stack, but some users/devs felt that Ishould go further to make > sure netifrc remains installed on their systems. > As one of those devs, I feel now may be a good time to ask What are we doing about this? In my opinion, anyone removing net support from the stage3's should be killed with fire. That said, I don't care if it's netifrc or whatever as long as it is properly documented and actually usable. Thoughts on how we move forward? Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSnPlzAAoJEKXdFCfdEflKX04P/jV742c4/2/T+LKqpNiu4Q1V tRRjBxbAo679MkjMdSsETzeT87jE5QtGGmsua9lcIP93WU28Qik8PRtXl74mpJav 83leOqnI5iis1TJml1MHoco5FIFIB5cC/QQ5xOFTgaEZhY+f9r8/hzxG+xXRyaW/ X+PRmj167rTrs9Yzp7VINjbo+EqUxtOUqzFQySK6uW89cQB1HUDgZ9SKIey3f1PY KiTQbb16o7a6XXP3CwQOZGinwo8VJvIdxx9CypSdBXoIE6A/G2ux0HSjzs+8HeWO s9OO3Pa9ptX8JxyRtd2Y18CYLoAmc7ecLupyOqpvLptVG7r38iaP93D6+89IN7Kp WYv/UBbyMOLE4voZotRUHeKb5Dtl69nir9JvfohQTavs7gXLQca3BHAXMLOfbjYf jokGdE5OqQQHwn1Bokl2+4blIYY+FDKrh+0osqe4T2Nk02wli5/6IiThVk5kttJl MXzqh2+1Oz+jtp1F2pTsP3hJUuV6sdtHiunXNKicyDSCYrZIadXtA+DB2gImmvHD HWnfomYlqZnKUs+lxwh4FM56O5NzpVnWxiA4Xx8K8Rgq5i8bCUiluxZgKTwBPyk8 c4EUllyp7u0mZCNL90XH6aeLIWXcI8vPW7K4sgsG0fhxWSGDQCIYQLRe/86MCWKh bCCtQC4u5/IlGO5NDKw5 =ripZ -END PGP SIGNATURE-
Re: [gentoo-dev] Canonical order to profile stacking.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2013 12:28 PM, Anthony G. Basile wrote: > Hi everyone, > > I'd like to bounce a question of the community regarding the order of > profile stackings. We have a suggestion in hardened to re-introduce the > hardened desktop profile. This was deprecated because controlling the > profile stacking order is very difficult. Specifically, if we set > > .. > ../../../../targets/desktop > > in $PORTDIR/hardened/linux/amd64/desktop/parent (taking amd64 as an > example), then we get a stacking order where targets/desktop overrides > hardened/linux/amd64. This causes problems because of flags we need to > mask in hardened. > Right, targets/desktop overriding hardened is undesirable, that is the main problem with this stacking order. > A suggestion was forwarded to switch > $PORTDIR/hardened/linux/amd64/desktop/parent to the following > > ../../../../targets/desktop > .. > > This, however, puts targets/desktop before even base which is > problematic. In fact, the resulting stacking order is: > > /usr/portage/profiles/targets/desktop > /usr/portage/profiles/base > /usr/portage/profiles/default/linux > /usr/portage/profiles/arch/base > /usr/portage/profiles/features/multilib > /usr/portage/profiles/features/multilib/lib32 > /usr/portage/profiles/arch/amd64 > /usr/portage/profiles/releases > /usr/portage/profiles/eapi-5-files > /usr/portage/profiles/releases/13.0 > /usr/portage/profiles/hardened/linux > /usr/portage/profiles/hardened/linux/amd64 > /usr/portage/profiles/hardened/linux/amd64/desktop > > The concern with this stacking order is that, with all the later > subprofiles overriding targets/desktop, we have breakage waiting to > happen when changes are made in arch/amd64 or default/linux. Since the > whole community takes care of those profiles, this seems like a question > for everyone. Do people assume a particular order to stacking when they > commit to arch/ or default/linux? > So the main problem with the old hardened desktop profile is impossible here, right? So in what world is this worse than having no hardened desktop profile at all? At worst I can imagine something from targets/desktop being overridden which, yes, leaves one more use flag for the user to set, but breaks nothing and can be easily fixed in the new hardened desktop profile > The issue is being tracked in bug #492312. I give an example of my > concern there. > So for the 300th time, why exactly is this a bad idea? I've yet to hear a single person willing to bother testing, and everyone is just terrified that "omg, what do you mean base isn't first???" - -Zero_Chaos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSkqsuAAoJEKXdFCfdEflK2e4P/idmJZFtMhLMom6oV2vgiZJ5 NEyhqzfeDObvoz+RFasUW5FJWuoF2tRKQ5YeqN/OqBooW7T2nfuYHUHBYKk5XXPf giYLLe8uTorPdEVoKcyB6gLJm4miVNrVP4GwiRiKn3UwIDN7WWUQkf6SX4ki8bgR t7DVHfc490xwlxe7iTRW3usRJPW3fs1RJ6giMGFe5Y7ddtyC3XyojEBJvaJejZfJ YoRLcyonEiwoEBnYdpV4LKBI85ZCmevLs8CatYZ6tdwvoUtam5fsZ7QNeFtgp4qd YJAMkux+CXB+2BP0xant8f/TA4xzPSoGGRxxLs+r8a9vDbZ0lm9FjCUYHEKR3iSG Z38xFiaWwh2VJ73sNTrJ52KNpfWmtpAqSHFmgZci8157y7H+3uYZDTFhYfKsB5xN JCXiTWOJ5fKK0QKxf4PDWp6yAQNO8Ef7ObMkA96a+1JfCZXkFROCkpuKh+I7OD1J Fhyx9yN3axLuo77YjjO+H00rL4qbDMhujX8ZXUqWxwZYSY6o1sCh2fvKZWIAstgf rhENd2R5Ae7I0PxCjID29BS2TjQz+z7o0kQz4FEm4zlJm7Qt29QrYSENkXpZw6rZ 5L20FtSjJx6IfBbsdGIyFTANV0B7fPht8peoSoMggfvFAVNps6bVGzEMuoowWwSX QYBPkyLcLJ8Tnl3dnTcK =fiGs -END PGP SIGNATURE-
Re: [gentoo-dev] How to obsolete this python-exec news & fix the issue automatically for users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/16/2013 10:28 AM, Anthony G. Basile wrote: > On 11/16/2013 04:11 AM, Ulrich Mueller wrote: >>> On Fri, 15 Nov 2013, Robin H Johnson wrote: >>> Add this line to the dev-lang/python-exec ebuilds: >>> PDEPEND=">=dev-python/python-exec-1:$SLOT" >> This looks wrong to me. On a newly installed system, currrently only >> dev-lang/python-exec:2 would be installed. Adding above PDEPEND would >> unnecessarily pull dev-python/python-exec:2 and dev-lang/python-exec:0. >> >> And IIUC, the idea was to eventually get rid of dev-python/python-exec. >> >>> If there are no objections, I'd like to do this to the affected ebuilds >>> in a few hours. >> Please don't. >> >> Ulrich >> > > If I recall correctly, this did not work for me in my mips stage builds. > This works on amd64 and x86 stage building. If anyone wants to make a change, you make sure it doesn't break stage building, again. I'm available for testing, as is anyone else on releng@g.o Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSiRo5AAoJEKXdFCfdEflKTYMP/AjBFl4YV+lzC+8wpGTQDbcj Tx/e3FkWgIiyNJNbxJ0VOnrzx0CtnNvp1fFmBAeJVOZHCVWDJ2mLcn+2qc2T8Lmb UYOcYDRluecax9iKLM1eUcn6e++lhyduCDsW4cA9PFyLNSvSibj4JxzDvICy71pr 1V5CgOl62i6C1ho+HeO0cl+Ym9mkhHF/cc8fPpn09glxWN2LM7FHS3JCk3fwtrcL Ow1uXpDXjq1+kngrnpNwWe/JH8F/Ejl+pH1XaZ5GK8cz95jolexx0vOkYN+tojVP 53Sn3bvQtmVBSnL97Eyt8+QOwgJ/6HHAdJi5W3EfpfrzTc8Jq6Q00YmOnX48t79O VmPRy9eguior+IIE60r3uD849959HP6gZynwBq4QgAYrVjzk+zSu69kyAwcoXrRt 0qhr8CG9eO6e4ajmlumdtqraQpSH2097BgWhuB77Bz5HBTB4bSjQQdsfeYmd0a/R IpDCh/09Aahb3zR7RsDz9beoTohsv9xD2956086WmEGu/t074R4Yk2N/0qe+Ajzx 8YhQ6+lDNa/sWsrqNfYr4uMbTSuR5B+weBkFMfVzLX561axoFm8xISHW2swAlgD/ ukEqQvmZXehC8t3Qa8GiK1jl0JCzsGiBQZrSRQWiz43u0Ez9zpEyHeNBOBMbiarL ignVeEammo84QeKdV46m =JLDT -END PGP SIGNATURE-
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/13/2013 01:58 PM, Francesco R. wrote: > > long story short having a portage-20130126.tar.bz2 snapshot > (before the EAPI 5 switch) greatly simplified the upgrade of an old > server on a client. > > Why not keep a copy on the servers? I mean > http://distfiles.gentoo.org/snapshots/ > The goal is to be able to update a device for a year. Not updating at least once a year is not supportable, and should be discouraged. I'm sorry for your pain, I really am, but I hope that it pushes you to update twice a year instead of zero times. Thanks, Zero > thanks, Francesco Riosa > > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSg9AVAAoJEKXdFCfdEflK+OMQAICBP5TQOdOCIi1SZqnyfPgH y6UhoLLbvbpuhjLmGFlbVi9uj+zeSArGI8dY795ayS34LDjXgMPkAnFRN/xOiaPq 3SQpRc20YB6dD9GmB3f+7DNGZJFORft9eINsSgFlgiDu4fOsk3vjNuqEHgBI+ld2 8gXcEMsiAK2yq0FXdSyaeoyOpBquVYJTsP1qVFayEFNIo6ZWe7gGex5g+CMpJ/XN j5cWqtRiaQ1dQKUASs8sxfN0WG/hVY4hLuBnhgblTkrvtK69el0nWRm3e47g14SL bh2ZG3ViBlNqGBhAZqWNlwll3PbU0SVp1B8k1KTHfaXBwW+n3xO7KJw3ablV7tri x+wUsbKozwRv1XruL+b0+WNBXBFOuLwq8Acomq7nXELzyLOz5smrzA6eYuz7/ck0 sZbWwbTVNsMm8EE3ZXZZRpbNc6cy2SFAV+UFSt6IJD+19dK6rARTM88yE/ACAhn7 V7EL+KKk1ilOGZXV6vrsBv9jm5aAueauiMDz6uE/yeVPddl1Wb7M1rgiGDQ2R5Ie CKNKZjkU1s0a644BeaNOX2Mow9rQp68Tvb0s+sTiT1PZnStBmUuuocYCbAvDhbt3 QvuIUKA3b6ddbJ1ynNg7FYWmLXtcZGbf7zMOZSLZLMybonvBsrfE+adVLEb+11Z8 3UeBxk5EF3KrtXSHLyM5 =Rg4r -END PGP SIGNATURE-
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2013 06:09 PM, yac wrote: > On Sat, 02 Nov 2013 16:57:07 -0400 > "Rick \"Zero_Chaos\" Farina" wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 > >> On 11/02/2013 04:35 PM, yac wrote: >>> On Sat, 02 Nov 2013 15:20:41 -0400 >>> "Rick \"Zero_Chaos\" Farina" wrote: >>> >>>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA1 >>> >>>> On 11/02/2013 11:03 AM, Michał Górny wrote: >>>>> Dnia 2013-11-02, o godz. 14:51:26 >>>>> Tom Wijsman napisał(a): >>>>> >>>>>> On Sat, 02 Nov 2013 09:16:45 -0400 >>>>>> "Anthony G. Basile" wrote: >>>>>> >>>>>>> This is a followup to a discussion on IRC yesterday regarding >>>>>>> breakage that's occurring to catalyst builds as a result of the >>>>>>> recent move from dev-python/python-exec to dev-lang/python-exec. >>>>>> >>>>>> This has been happening to users as well, for example: >>>>>> >>>>>> http://forums.gentoo.org/viewtopic-t-973998.html >>>>>> http://forums.gentoo.org/viewtopic-t-974412.html >>>>>> >>>>>> To move forward and get this resolved, some questions: >>>>>> >>>>>> 1. Has this been resolved for users? Do they just need to sync? >>>>>> 2. If not resolved for users, what is the best temporary >>>>>> workaround? 3. Are you able to fix this? Do you need help to fix >>>>>> this? 4. Depending on the nature of the fix: Would a news item be >>>>>> needed? >>>>> >>>>> From what I heard, most of people get this working through a >>>>> plain: >>>>> >>>>> emerge -Du @world >>>>> >>>>> If someone is really reluctant to world updates, it is enough to >>>>> upgrade dev-python/python-exec to 1.*: >>>>> >>>>> emerge -1v dev-python/python-exec >>>>> >>>>> I was considering writing a news item for it but we discussed it >>>>> on IRC and decided that users are really expected to be able to >>>>> handle themselves, especially wrt to: >>>>> >>>>> 1. using 'emerge -Du @world' to upgrade their systems, >>>>> >>>>> 2. reading the blocker output to see that it states >>>>> ' which suggests: what if I >>>>> upgrade to 1? >>>>> >>>>> If you believe that a news item would be helpful, I'm happy to >>>>> write it. Just please make sure that we're all in agreement over >>>>> the method of handling the issue. >>> >>>> A news item isn't enough for breaking autobuilds. If we can't >>>> find a way to do this properly so portage knows how to upgrade >>>> then it is being done WRONG. >>> >>>> Autobuilds break, gentoo can't be installed, the distro dies. I >>>> know, sounds like I'm making something out of nothing but every >>>> time people look at the stages and notice they are months out of >>>> date we find another blog post announcing how gentoo is dead. >>> >>>> Honestly, if I knew a way to fix this I would have already made any >>>> changes needed to fix it. Please fix this, because if you don't, >>>> eventually I'll find a way and I doubt you will like it. >>> >>> I guess you can run a basic QA like that the image boots and gets >>> the network up with openQA (or using the same method) at least to >>> detect such breakage. >>> >> I think everyone involved knows that manual intervention is needed to >> resolve this dep. I'm sure that things were tested before they were >> commited, which leads me to believe that the commiter didn't care that >> manual intervention is required. Sadly, we at releng do. I am >> actively seeking a resolution for this, let's see who commits it >> first. > > I don't know how this releng stuff works. I bet there is lot of devs > who don't. > > Also I think your response is also completely unrelated to my > suggestion. My suggestion is about acting proactively > instead of reactively - automatically testing eg. the image of livecd > iso that ge
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2013 04:35 PM, yac wrote: > On Sat, 02 Nov 2013 15:20:41 -0400 > "Rick \"Zero_Chaos\" Farina" wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 > >> On 11/02/2013 11:03 AM, Michał Górny wrote: >>> Dnia 2013-11-02, o godz. 14:51:26 >>> Tom Wijsman napisał(a): >>> >>>> On Sat, 02 Nov 2013 09:16:45 -0400 >>>> "Anthony G. Basile" wrote: >>>> >>>>> This is a followup to a discussion on IRC yesterday regarding >>>>> breakage that's occurring to catalyst builds as a result of the >>>>> recent move from dev-python/python-exec to dev-lang/python-exec. >>>> >>>> This has been happening to users as well, for example: >>>> >>>> http://forums.gentoo.org/viewtopic-t-973998.html >>>> http://forums.gentoo.org/viewtopic-t-974412.html >>>> >>>> To move forward and get this resolved, some questions: >>>> >>>> 1. Has this been resolved for users? Do they just need to sync? >>>> 2. If not resolved for users, what is the best temporary >>>> workaround? 3. Are you able to fix this? Do you need help to fix >>>> this? 4. Depending on the nature of the fix: Would a news item be >>>> needed? >>> >>> From what I heard, most of people get this working through a plain: >>> >>> emerge -Du @world >>> >>> If someone is really reluctant to world updates, it is enough to >>> upgrade dev-python/python-exec to 1.*: >>> >>> emerge -1v dev-python/python-exec >>> >>> I was considering writing a news item for it but we discussed it on >>> IRC and decided that users are really expected to be able to handle >>> themselves, especially wrt to: >>> >>> 1. using 'emerge -Du @world' to upgrade their systems, >>> >>> 2. reading the blocker output to see that it states >>> ' which suggests: what if I >>> upgrade to 1? >>> >>> If you believe that a news item would be helpful, I'm happy to write >>> it. Just please make sure that we're all in agreement over the >>> method of handling the issue. > >> A news item isn't enough for breaking autobuilds. If we can't find a >> way to do this properly so portage knows how to upgrade then it is >> being done WRONG. > >> Autobuilds break, gentoo can't be installed, the distro dies. I know, >> sounds like I'm making something out of nothing but every time people >> look at the stages and notice they are months out of date we find >> another blog post announcing how gentoo is dead. > >> Honestly, if I knew a way to fix this I would have already made any >> changes needed to fix it. Please fix this, because if you don't, >> eventually I'll find a way and I doubt you will like it. > > I guess you can run a basic QA like that the image boots and gets the > network up with openQA (or using the same method) at least to detect > such breakage. > I think everyone involved knows that manual intervention is needed to resolve this dep. I'm sure that things were tested before they were commited, which leads me to believe that the commiter didn't care that manual intervention is required. Sadly, we at releng do. I am actively seeking a resolution for this, let's see who commits it first. - -Zero >> - -Zero >>> >>> Additionally, the news item would state how to get rid of the old >>> deps. This will presumably involve something like: >>> >>> emerge -1v $( qdepends -NCQ dev-python/python-exec ) >>> >>> Please note that 'equery d' from gentoolkit is currently broken due >>> to some random magic inside portage and doesn't list all the >>> packages correctly. >>> >>> However, for the latter it would be probably preferred to wait with >>> it till python-exec:2 is stable on all arches to avoid rebuilding >>> packages twice in a short time. >>> > >> > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSdWcjAAoJEKXdFCfdEflK2vYP/Rf2I3SSAm0ZwxJRqYl2Lv+y TrYscC0ekWn3Z0+FwUz9rhfhWJwoCjCEv7zsxq0UQiQu+xK+DmqXcgw38zYGb6Wv bPvq8JMpcSa4tz1wW+wbepS31fXq/WlV1E03BRAbUrM1bhxyS2qia8S0AkTyN4xt UlleZb8Ep0NrlX1JAx/EgLCBmA61xj5ONdIPlyni5RCtnFZIPnMRTVhlFARaWXQJ coFztk/ke7B43p2Q6wGR6zHRNdnH59gHg6FwDxXsys/AajSDFrR9Id5GoAgOiqPW 9eqbwyR50Csd3H3UKdmit7Tdn80TSt4qWs/NXSrvG+38TVm1U6hY6rVSSHHuUXba b3QqT/jx7GzUa3GtKp7QD5ZcKk/F2d7z/oOeGUodGNJ8P+5cQHHb96z0vKR6D2lU DPpH8v5EWAY01PLW/1240mTljT6/30GPNxEgR1oj2GxOUR+gUnVXFARcorP4R5Ek qv2jLp1SZgQDAht8RfvR1ngXIpQmNyUvYCKQuxu3fwhANxu0T1DqLfO0shxg9FnZ HrOzlZvsmOtf4dPjJ9kuWPhbRD10VPqy8dzis1jzb9ucSgCP96y1UzbSjuLI183B gsHfJSERKNZ9E1qWEL5OZ/qv7Q7+zsgG7XTo8/12AQUFIIkA8l7qEvZ0AiOXNxwQ rHEvm115H5ic0gQ8bG6I =Y0pJ -END PGP SIGNATURE-
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2013 11:03 AM, Michał Górny wrote: > Dnia 2013-11-02, o godz. 14:51:26 > Tom Wijsman napisał(a): > >> On Sat, 02 Nov 2013 09:16:45 -0400 >> "Anthony G. Basile" wrote: >> >>> This is a followup to a discussion on IRC yesterday regarding >>> breakage that's occurring to catalyst builds as a result of the >>> recent move from dev-python/python-exec to dev-lang/python-exec. >> >> This has been happening to users as well, for example: >> >> http://forums.gentoo.org/viewtopic-t-973998.html >> http://forums.gentoo.org/viewtopic-t-974412.html >> >> To move forward and get this resolved, some questions: >> >> 1. Has this been resolved for users? Do they just need to sync? >> 2. If not resolved for users, what is the best temporary workaround? >> 3. Are you able to fix this? Do you need help to fix this? >> 4. Depending on the nature of the fix: Would a news item be needed? > > From what I heard, most of people get this working through a plain: > > emerge -Du @world > > If someone is really reluctant to world updates, it is enough to > upgrade dev-python/python-exec to 1.*: > > emerge -1v dev-python/python-exec > > I was considering writing a news item for it but we discussed it on IRC > and decided that users are really expected to be able to handle > themselves, especially wrt to: > > 1. using 'emerge -Du @world' to upgrade their systems, > > 2. reading the blocker output to see that it states > ' which suggests: what if I upgrade to > 1? > > If you believe that a news item would be helpful, I'm happy to write > it. Just please make sure that we're all in agreement over the method > of handling the issue. A news item isn't enough for breaking autobuilds. If we can't find a way to do this properly so portage knows how to upgrade then it is being done WRONG. Autobuilds break, gentoo can't be installed, the distro dies. I know, sounds like I'm making something out of nothing but every time people look at the stages and notice they are months out of date we find another blog post announcing how gentoo is dead. Honestly, if I knew a way to fix this I would have already made any changes needed to fix it. Please fix this, because if you don't, eventually I'll find a way and I doubt you will like it. - -Zero > > Additionally, the news item would state how to get rid of the old deps. > This will presumably involve something like: > > emerge -1v $( qdepends -NCQ dev-python/python-exec ) > > Please note that 'equery d' from gentoolkit is currently broken due to > some random magic inside portage and doesn't list all the packages > correctly. > > However, for the latter it would be probably preferred to wait with it > till python-exec:2 is stable on all arches to avoid rebuilding packages > twice in a short time. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSdVCJAAoJEKXdFCfdEflKLiwP/AjlCVUKeHo7wI8FO6W/VE4u 2Pv2VqaRGQ3KDn/yvHfClfXib8Eu4/KE1cc8kUoP4vspRQLiCz3qMqtYqFy9Y3DF fPYbBL5w4Z1V/sAho9pd3f2XHAOYwM/G1cD2GfbEHY5XdR4rk8w3AzK8cTCO5gL4 DmbBS1t/G3fLoNBud4pCpM+QCD1edwHWSptjWS2lQN9hNI9VwOBrXmuBKLPHR05F JyLWiiTbHPD6y/UquVa9uqdcHRJ5uTAyu9CZPu4CDrC3sJuFYuZxYZc2s4VjqyLo YKXhp5RJjFJT23ZNhM1eAUCH2jxiJM8JoTRC1gYY1mKuWqL3gLojPDjTqS5ukya6 C8mZ9dqEtqEisJuUQPBkuhfKfClmk0sDCTwrtEJCe4day7gX9w5uPZO1oFrJ+/8Y 6M0chyaU33XaZBIRLMo/KaCg0MccW3Oob2AVo8pesrPrmQwPnXnGvps8rlbrkpv+ lFdx1yh/phW2oWq3yVHf4LlPgrajDrgLzDgcVXYKByG/Nd2pKkkbzq/JfAwtfzck fpufYDbWF3j8ErVGjzWWQLR4NOzf01NC5Q/U4dCVR+Yy4+a0joSuTB6fz2+eFjz8 6NCr7i+lYPcrnnlvf97XBvXhbsf0NIhwiJtMkLi72LKgI+Wn3D/Xc3H62KqjsXDf Hc3RqAPCSO/GAqf5hqVl =VeiN -END PGP SIGNATURE-
Re: [gentoo-dev] Reminder: open season on robbat2's packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > net-analyzer/sslsniff #zerochaos seems to have this as well, I can > co-maintain :D be my guest - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSccFgAAoJEKXdFCfdEflKY3cP/REftlb2J5DTdWNzBFPBB8J8 /QAGTyd+RXro37n3drB544Ofop/UPrMaHHeaMuRFSf58JqNGTW6RZ4Oj7daLrUWV /lHSpUDUDul0O3pnFbjrQ50ndAArSo1VFtmAlPeGwVAMwORLbr1Ul3oPb7JIODJn C2gHNwPNUPEYQ4u5wImsCMA1OWOyoLNMGr/GYNgoAk/SeN8ZjVo9zeH2xfO9ckBV QVgaN48IcsHPi/m0YbY5NhN8oVWVYSTwJLw7hqF14i+CNkYxLOz0at+XvUxgjXFA 5Z/7S5742zBFfzm2vTcEKtROAYiw2QjV2i6BTNByPZHYaGMKZsYP1QQl2dvKJl54 s9bG+eeJ3458IzR4vVexqgfUim3wHueqQfOtU7+/hvuN7PA0S9YYLxnPYk0aCy+w jO3fJ5tBLOhzTDCyQBSFhhr1Z9kH0H5eWFLuk4H+VYg5wBwHbrgRQKP6zJ5/IhPT 6h4oWsUG80jmnXs6muzc05ma4ce0xLzb0NAoiuFatWSYzkz+3BzpxAMhghLC50fO 8Uzm/hjR4PO6Xs96thY8WiqKLAA2JDVbyiWU4BK4o2/cNW4ozBbGcSrRXMAzRxR9 LI6hNhuvj+SSIwZGoN+6VxBbsZRtIp/cEySuXvLu3tNBXVjy/f0j87hau8QOxpSl fhlOdQ1mwnX0dkT4RhZf =T40+ -END PGP SIGNATURE-
Re: [gentoo-dev] Adding large files to the mirrors?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/2013 07:29 PM, Vicente Olivert Riera wrote: > Can't the users download and install those tables manually from the > official ophcrack website/server? If so, maybe adding the instructions > in the pkg_postinst() phase of app-crypt/ophcrack ebuild would be > enough. In that case, it wouldn't make sense having > app-crypt/ophcrack-tables in the portage tree and should be treecleaned. I think this may be the sanest option *for the large tables*. The small tables are great, and you can einfo a message about the large ones. - -Zero > > ** > Vicente Olivert Riera > Gentoo Linux Developer > ID GnuPG: 5AE9E7B2E9BBCBA8 > ** > > On 10/16/2013 01:20 AM, Mike Auty wrote: >> Hi there, >> >> I'm updating the app-crypt/ophcrack-tables package to include the new >> tables available from their site. These are basically just additional >> data packages that can be useful with the app-crypt/ophcrack package, >> but they're very large. Including all of them will come just short of >> 30Gb. I don't know whether it's ok to add that to our mirrors, or add >> RESTRICT="mirror"? >> >> Also, these take up a lot of space in distfiles. Does anyone know of >> a clever way to allow them to be installed without also stashing a >> copy in distfiles (symlinking to the distfiles directory is a no go, >> because each "set" needs its own files to have the same name as the >> other sets)? >> >> I guess it's a bit of an infra question, but thought I'd ask here in >> case anyone else has found themselves in a similar situation. For >> more specifics about what the package is like/for see the test ebuild >> at [1]... >> >> Mike 5:) >> >> [1] >> http://git.overlays.gentoo.org/gitweb/?p=dev/ikelos.git;a=blob;f=app-crypt/ophcrack-tables/ophcrack-tables-1.1.ebuild >> > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSXertAAoJEKXdFCfdEflKICcP/2I+L61IWFk2Ackp+SqGgCHV NKuqCAFeoGywXIIgoFI/eWrOfHBQwyNKrNL6lRcBcYQXJy96yR/caRSPS+zPsEoU B4pJ13KJg0ipCriZUXHMtAOGcBOJRr40ItW0L3qT8ICl8TIFHeaDuqx5Sbl7GuHQ Ewqt5CdN4g7lpp5XROmz/LKHr3fHi+KNMPj7GrKd/guoALqmJvclmyWmmrovzr91 1ueSPghfSF78AHjEj8X7H7702/waLeOpww2MZkXfAY+H3Chw2AuTR0JC7xiSpMvX Dq4rtLUmdeobozBwNDkczoVGcfxoR+AguNlZUIz2Vij2A3XxVznqEYHY+VIbwZVm o5ut+P58GJBBct5TSi1IMdq2Rfrg7xP16e757Ki1FDSbQamaDhl8SETPbPQ0YrjV J9m8JQ2tlvgMi20Z+UA5QVWT9jZq8s8/26eDkeZNzYilmNZ8sSWUAlpNOgC0xsSG n4RN1COEVcpyxhyFjjMLB+GjxVa14fCgpZ+mcd/VwRmxU7scnw8YweWALamnAEbB FmcBB6tedeeA6TWcXtr3HGbfwt37KdHHo8xDJpJVl42dk08FKtV5sSY4vA2MDkL9 pyI4r4qo076KT9N4ZIsljPf3pGAYe3ERnIdNFgEci8UJBapoHh2GnLuTAN+EFjDt GcEiQLGWWMK9TuVL/9Jj =kOqk -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.13.ebuild wireshark-1.8.5.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/11/2013 12:07 PM, Jeroen Roovers wrote:
> On Fri, 11 Oct 2013 18:00:33 +0200
> hasufell wrote:
>> I c. Woukd there be a way to change the plugin dir, so it is not
>> version specific anymore?
>
> Yes, we could call wireshark's configure with
> --with-plugins="${libdir}/wireshark/plugins" . It defaults to
> '${libdir}/wireshark/plugins/${VERSION}'.
>
> But now, would there be ABI changes?
>
>
Based on nothing but testing in the past, they only break ABI across
major versions, so we could simply subslot properly (instead of the
current ${PV}) and it would work fine.
Also since (afaik) libbtbb is the only external wireshark plugin in the
tree, it seems my risk to take and I'm willing to accept it.
Up to you guys.
- -Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSWCSaAAoJEKXdFCfdEflKd3wQALrl7+X3nolkqtk3yZp1OhWU
aSUB9wVG2wHi/NjzIVh0IADxXhhd4xoYCH7cdIVhJ3HBIsfM3nMruSenILbBQyBI
oLHseaiygKvARFZkP/vCtIqB6bCmEbYqQ1l74V2WFC6hv3hQj454dojvZbNCrTZm
8dZplYSNi3CjgR+KlOf7CU6c1VQZ5nEPQlyPwd/vydC+sse/0KM6Ld3Vw4yhWfR6
18S17miy72EDF20f37bkcVaavGs2YejPY8XBZwPZuZWkiCs62CJS+JahO+j23FHo
Bn/QKpXcqhPfbvwONaN8JJeX6we0l48Zbt0Io+zajOLwvgz3BeD/x4Nvfp1LY39X
4X+dRjxcjdnNLZHrX14zQ0ukFufqondkFZQL6PHrx8quwGEOix8WTcoNmOedxf8/
Z7321w357f9d3tOGWEzwfkyiYOSXxXpCM3xdApzje2eU28eJUQpkz+hdlyCoP4Yw
D2LUjo5avstc99SebU1KGOpm3Zk+6S7A7mKuYNpyRzPJwhGV+Gw4Yl2auuIGlPc9
FcD+Yzs2tulLX67NXj+RiPgj/59q0KSUZd0vZu6gRfKlAxkmlYK8a1S7Yh36ky8Q
YJRRTYHKWtF6dHfkdmAH2tnDx6lc14uZGPts0L4JTyx9O6yUYEzapS5d7facOeDN
fr19Zs2p34ZxoKCcnrvh
=XmRp
-END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/wireshark: wireshark-1.6.13.ebuild wireshark-1.8.5.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/11/2013 11:42 AM, hasufell wrote:
> On 01/30/2013 05:28 AM, Richard Farina (zerochaos) wrote:
>> zerochaos13/01/30 04:28:06
> [...]
>
>> LICENSE="GPL-2" -SLOT="0" +SLOT="0/${PV}" KEYWORDS="~alpha ~amd64
>> ~arm ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86 ~x86-fbsd" IUSE=" adns
>> +caps doc doc-pdf geoip gtk crypt ipv6 kerberos libadns lua +pcap
>
> [...]
>
> does net-libs/libbtbb (dep of wireshark) need a rebuild ony any
> version bump of wireshark, no matter if ABI compatibility is actually
> broken or not?
>
Wireshark doesn't have a dep of libbtbb Are you asking about
libbtbb's dep on wireshark? If so then YES, it must be rebuilt every
version because as far as I know the directory that plugins are loaded
in is versioned so even if the built files would work, they are now in
the wrong place.
- -ZC
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSWCCiAAoJEKXdFCfdEflK+3UP/RDecT/L+K0mdE1CJkvgPffm
+tWak3O8kiGr9lpnAAmh0yTfMnT9eayTecCQZJbZ+7B6XrxflcfX+A9qHFWvAXUd
uQK+XM0darzOhdtPHkHNF4i0dR21AqLXABAMlVKYlg6qKxIQfHOOAPgamSSQt5Fc
OXUQnzt1ShdtywHKFm4FjmnKlMX/yLGAyUmc6tRu04yR7/skBgSXAtlBn92Gh0Dp
c6Xdl5zG+b+Ev7E1gv0u4zphsljAaBmvlE3/f699jvKZDDRLlhQH50WTn4s0so5x
YgC7KbiywJFOqoEeCro1OVDx7xbIjtUpmngW71mFb2V/VnqbwZbRaz6v5pqRgu6Y
/X29DgqfqRFKfY+5ncNtCQy8p7J/RF4rlcBm5NkNWbQ6sUw2CRohVjuatsRwqxBQ
vCSnxbiC3fMB2Wxa2sfyRllGFVRirbdO/HrV8EvQ/BDtMyoJvXiHeHuGOVrtK8x7
G633iGwg+jvzN8WP3YaGxfIDlvaobhp6XVLUun6PBKNadLvJgTRmZYyZktRksEi6
Y/CKV5/2Y45z8tJDFu5RAMNwbgmFlGVO7BUE1rhcENtrcvngKMR0/qrYgI73GOUD
vZ5e4RXPMf1yC4m85FcYC/omyewvNmTGi3mr2AeohoLyGFj9jZhg6bGz+RbuTeru
o3VciUTZf5x5u84YtXv9
=cJo2
-END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2013 10:12 PM, hero...@gentoo.org wrote: > "Rick \"Zero_Chaos\" Farina" writes: > >> On 09/28/2013 03:00 AM, Ulrich Mueller wrote: >>>>>>>> On Sat, 28 Sep 2013, heroxbd wrote: >>> >>>> I am revisiting this topic based on previous discussions[1,2,3]. >>> >>>> There seems to be a constant need for toolchain with a new EAPI. The >>>> only block is "how can we upgrade from an ancient system?", "don't >>>> bump or the upgrade path will be break". Let's figure out a solid >>>> upgrade path consciously, with a test farm of ancient systems, and >>>> then bump the EAPI of toolchain. >>> >>> The upgrade path is not at all what is blocking this. In its 20130409 >>> meeting, the council has (unanimously) decided: "EAPIs 0 to 2 are no >>> longer required for the upgrade path of users' systems." >>> >>> The reason why toolchain packages are still at EAPI 0 was explained in >>> this posting: >>> http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377 >>> >>> AFAICS, changing that is entirely the task of the toolchain team. > > Thank you for the clarification, Ulrich. > >> Yes, it is entirely the task of the toolchain team, and looks like >> heroxbd joined the toolchain team and would like to push the rest of his >> team for this update. Something I greatly thank him for. >> >> I don't think any dev wants to (or really could) force toolchain to >> update individually, however, if motivated people want to join the team >> and help, his question appeared to be will it be permitted to be >> updated. > > Can't agree with you more. > > It's just a starting point, though. I still don't have a clear plan yet. > > After reading carefully the thread Ulrich pointed out, it seems that > refactoring ebuild/eclass is invevitable, which calls for an overlay to > carry it on. > While I'm not nearly good enough to detail how this should happen exactly, please, may I beg, do an eclass revision for this. The fact that this hasn't been done clearly implies it is a lot of work. Let's not risk stable, let's simply make toolchain-r1.eclass or whatever, and bump that to eapi5. At the end of the day, this allows working and testing without odd issues, and if everyone really hates that idea you can simply drop the changes into the original eclass when it's all done. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSR5V3AAoJEKXdFCfdEflKDcMP/0B01NSlVaTEM6oDIF324YNP p1G1vNVh86avVCL+0sLfmDPID547qWZOfemoids94xemrvyVYnJFccvtg7KBH+ck k4h/LJ2pTEvCGiL3KyUngYc6XN3YMwOHJsRD+jr0cmYG+GG0Lm5UUb73PPhgLtOv Ltrm4B68w3x1qqucrd3/PgBF7tfjoBdvB8XqkJ+u9RoMFfFb2BUH3n6VZ2Ngkzup BU5PaakC8tBGhZvkLrd81RHTY7iHuM5HGh4ZK0GSfVsq+pYIwFpWztKGcSQmEpxe oLgMZD2g5GAykkUhzcrvc6p091wsOylenAgnhZZL2cy2pZE99TLTUw6y/Q7+HUiN mKdXG/JbXQ/FmkhqVivvWM43g3bumEvYub5EegUa6MGrHjCqRjsO+GQq68CGTbMq TYpZXUGtCdAdMIyvk6wMhTWlrO2TQmakkj/tqHif1TsyVIIYZlTKLosftqxVbpxd 54Mr1oI+LM7oHGghy5/7BJz0V0U7BWIXiDBBf4HJ1k4gybkRBqCx7I+YSYib9ZZg jvHwJv9kiksduO5dQk/NmKgWgmyBTaYzZYPvxJyXp2uzk3Nmgf7JAwN2AHuUrFXZ 5LLwPC36bwEyAdKABHwIZsVdquBm2smFLIFy4oMoxcmEHBaOmOKBSrIKN0iLPYnD ZfpgorrlwCLdiqV+VeKU =jY8E -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2013 03:00 AM, Ulrich Mueller wrote: >> On Sat, 28 Sep 2013, heroxbd wrote: > >> I am revisiting this topic based on previous discussions[1,2,3]. > >> There seems to be a constant need for toolchain with a new EAPI. The >> only block is "how can we upgrade from an ancient system?", "don't >> bump or the upgrade path will be break". Let's figure out a solid >> upgrade path consciously, with a test farm of ancient systems, and >> then bump the EAPI of toolchain. > > The upgrade path is not at all what is blocking this. In its 20130409 > meeting, the council has (unanimously) decided: "EAPIs 0 to 2 are no > longer required for the upgrade path of users' systems." > > The reason why toolchain packages are still at EAPI 0 was explained in > this posting: > http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377 > > AFAICS, changing that is entirely the task of the toolchain team. > Yes, it is entirely the task of the toolchain team, and looks like heroxbd joined the toolchain team and would like to push the rest of his team for this update. Something I greatly thank him for. I don't think any dev wants to (or really could) force toolchain to update individually, however, if motivated people want to join the team and help, his question appeared to be will it be permitted to be updated. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSRwnhAAoJEKXdFCfdEflKVycP/RrDx0riRF9HO8yjMlPxPRmX Fm4xl+KdGNiKIxHDKVKGehyHDGyEVxUq8ZtrNqkQurtgibhtI2eErOjWYVHsV2Yj A2lW8JubwvYn14Qk0Pem9jg5cGTbo1mEA4UGG2XMWYzyGJkXi/m+alJYTQfZpbGk VKwll6wAMpPpVoV/xAA/mHX5AJrALQrP9/0xqOtvcSSvJTZvu4rpLFPWRlUf6Q6C Z+0grxc3x6Nq6Ryn6f39KLRYgXv6AEwx9ieajKu7ES+rBbTWsJCHtPD+H3zZbJI8 g+/2GPMgDmQ9tMQwuBwPdylUzGhPwd8Gmd6546mnBPOlZZNsJxBc/Cqt1paMyaPy sZp2igbXR5B9ha6Tg5bW7j6WDKqr9QZAslGYrXJa25wwmvcBQV+EsJrmmpQbDCdi todWjippnmJATDHVsHR1tW11/iO0t6UUKI8jLZm7HCaGXRptILWfICYYXAM19ntq 9DWpA4BIpQzZx0s3cQZ1eIB3lHxPL387UWitAI9zW23Q0VYfddQgbLKbAo76GkR7 3ta6wjvIJ2vPBgxvv5Eo/hfKMUtxxyGeA/Jp6+zRMKPxcsqBocQXMs7pdmTON3Mb ddDLJ88tPc9QenHzE4PwCiTjSPDCSQRzrhmzt1iQEsIitVXDnL5kXGt38MfxT9We 7p2PfdN8P4VekqKIcEVT =ROKo -END PGP SIGNATURE-
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2013 04:41 PM, Markos Chandras wrote: > On 09/23/2013 09:31 PM, Alexis Ballier wrote: >> On Mon, 23 Sep 2013 22:03:49 +0200 >> Agostino Sarubbo wrote: >> >>> Hello, >>> >>> the council has decided[1] to drop m68k, sh, s390 to unstable. If >>> someone has something to say about, this is the last opportunity or >>> in few days I will start to mark them as ~arch. >> >> is there a need to waste your time on this ? >> >> when mips was moved to ~arch it was done progressively: packages are >> moved to ~arch (~all) with new versions/revisions, no new stable >> keywords are added and old versions get removed. >> > I agree. There is absolutely *no* reason to drop the keywords on > existing packages and cause massive downgrades/upgrades for people > (unless of course you want to increase your number of cvs commits which > is a worrying argument on its own) > The mass upgrades will happen when the profiles change ACCEPT_KEYWORDS from arch to ~arch no matter what. Fixing existing keywords just make things tidy. And ffs, ago has more commits than half the gentoo developers already, I'd be more worried if he wanted less commits. Ago, please keep up the good work, but after the profiles are updated. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQLYxAAoJEKXdFCfdEflK1XIQAJbGU2RKcAJi814P+PqPe4qU p/uC3Tlg06Sa5yHw/BvW1OXOj6Ah/RncRiiQKymQ4CxIp0cbFx4JJZMT3X4KoMMc Skw3u2JjQ3EQaxSpRF2pj1YMuwrajO7jS7143BwfKtH8diIfT5So5xCe05Mz2D2y QYusPIBAHsV4xU+DvCPYQ6cJvOqxXzcqqBLTGP6j27EnWgDuKfTrf5JI0FW5fYbD 4dSEMyyhfh2wgAilLjT63rspZgHajYTo6oVeE6Fv8RqXSotaGqTHiNT9HI8J3Q6S uQUiB3vGl0Af06SGBePvYNizhzklUTf6zlhNkSNg2yRG0ihFOmz4DrtLvhNnJfBJ mF/Mihlq3e0uNbxDag81v66vFnEJcrdZvgk8ty2Mdyc/Wo9HwQyY4p8g3tMtUJe+ B9jaIXD1HENQ9XkmqQrN9HJvgxw3S6eiqCBkgJ+3nUcjfUNbm9U2jbnmoQeZSYJt 5SPC42hbz5vZhdznhxvx24FgOyDHR1hgKHXYJJXqBGs91zYMz3f1lpw08ZLWM3F9 7NbPeDZ7YAhV5MeyjK5NAg/zrcJjHRCptc3WITR8u3mY48tzK+vLPqS1UVYxOfmV keJiN3k+lLgBlJzDfKfeEM7CZkOTNd7ADAkcdrC9eV5iprCfHzKaPm2jCjP24eC1 T/pgVMGmrpGPLOErHYGX =weaO -END PGP SIGNATURE-
Re: [gentoo-dev] Re: sys-kernel/tuxonice-sources up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/21/2013 08:44 AM, Pacho Ramos wrote: > El sáb, 21-09-2013 a las 14:42 +0200, Pacho Ramos escribió: >> I don't have time for it for a long time (since I switched to official >> suspend time ago and moved back to gentoo-sources then), updated patches >> are periodically generated and put at: >> http://tuxonice.nigelcunningham.com.au/downloads/all/?C=M&O=D >> >> Feel free to get it if you want > > It goes with tuxonice-userui > > > Is any of this really needed anymore? I suspend/hibernate/resume with gentoo-sources and hardened-sources Does it really make sense to hold on to tuxonice still? - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSPjgiAAoJEKXdFCfdEflK54UQALldtJRXIqg80NQ9RfR8GVQt SK+4j/F8UBbcludvEp2cB+BmTY827njNsB3PdnyYg0TfRAacAH95weXdz8G1zils 2VR85NLYyd+mBkCzF2DVRA3pEFqy5DDezsAzwzjBsqC2TIq2Pu7ihaZKVH4TII/4 8bbjpdVaO/Q07yi8XU62skNNWAB1LPF3o7/4IMF8TxBUhDJnHJy1nDrax05dAKuu 7ufEENq7zC6y/LQhNblwkVbSmCb3Y0Mo4WJsqPXFiIs8KM3pfjGgxttJ9osTT5aJ 2BIvtfOSjq9Bhiwvv6d0YZZ/nKZDB129VaDMWht1273SITiHeLdG7m1/h6/l1aeA 2PUmnyIjKM4URUEX93ZQlMvY+WpRyKmP+womWcXiXRoAHOYLxDHT1dK0VmjDZ6SW wvFGI9foP3w8CBIQ2OC65pgm1n7mNVIYMGzTaPNXNFZyGlkUsDUzZPdOZcKJPLc9 XCb8G8vYYgtjmz17ZLU/2vsRVpanUjlEfrn3i1wvVSF9oD5qOcU7LamBiOxdbtMR UTVusffsoUd1G87hFAcg3P7l2dc3LYdVNUpV+9kz5nBqR6dNRzW7IIuZhp3QhEm1 xO6i2aUko+GnF99SnWt7sgvkDvCbJq/blVRwEEhCOOb6Q7THKi0qAXw+34s0DF4t MPi4jG5lATVAOVuAGrt8 =tZda -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Improve the security of the default profile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/07/2013 05:11 PM, Ryan Hill wrote:
> On Sat, 7 Sep 2013 18:10:42 + (UTC)
> Martin Vaeth wrote:
>
>> Ryan Hill wrote:
>>>
>>> * -fstack-protector{-all}
>>> No thank you. -fstack-protector has very limited coverage
>>
>> I'd say it covers most cases where bugs can be made,
>> practically without a severe impact on execution time or code size.
>
> The numbers I've seen show a maximum of 5% coverage for code that has a large
> number of functions containing char arrays on the stack. Most code doesn't
> fall
> into that category. Coverage of perl was 0.5%, xorg 5%, kernel 3%. Those are
> really old numbers though. The most recent I've seen is Chromium's coverage
> is
> <2%. There is an upper bound of 8% performance overhead using
> -fstack-protector
> according to the design spec. If you guys are okay with that then we can try
> enabling it for 4.8.1.
Personally I think this would be a great stepping stone. If we add
- -fstack-protector to 4.8.1 it will improve security (only a little I
know) and give us an idea of what issues we may have. After a short
enjoyment of fixing any issues which come up we could more to
- -fstack-protector-strong in 4.9.
Personally I'm using the hardened profile already and find the
performance penalties negligible for a desktop user, and someone trying
to run realtime on defaults is likely suicidal anyway.
Thanks,
Zero
>
>>> * -Wl,-z,relro
>>> Enabled by default since binutils 2.18
>>
>> This gives its real impact on secutiry only when combined with
>>
>> * -Wl,-z,now
>>
>> The latter is not enabled by default AFAIK.
>
> That's a bit misleading. Immediate binding does allow the GOT to be made
> readonly but relro does a lot more than that. In any case this is a firm no.
> The increase in loading times for apps that link lots of libraries is
> significant (if it wasn't, we wouldn't need lazy loading :p). If you want
> full
> relro, enable it yourself or use hardened.
>
>> I would like to suggest also another flag
>>
>> * -Wl,-z,noexecstack
>>
>> This should be the default, but e.g. some broken gcc versions
>> forgot this default when using -flto.
>> I am using this flag since I realized this -flto bug and never
>> had any problems with it.
>
> Well, portage will already tell you if your package installed any binaries
> with
> executable stacks and I don't see many of those warnings that aren't binary
> packages so I think we're good.
>
>>
>>> * -Wl,--hash-style={both,gnu}
>>
>> I don't know what this has to do with security.
>
> I'm just responding to the list on the Ubuntu page.
>
>> However, isn't it time to use "gnu" now for all users? Except for
>> very strange binary-only code it should not cause any problems.
>> The majority of users would not realize a difference but profit
>> from smaller binaries.
>
> Sure, but the sysv hash is teeny and backward compatibility is always nice if
> it's next to free.
>
> Here are some more resources if anyone is interested:
>
> https://wiki.debian.org/Hardening
> https://bugs.archlinux.org/task/18864
> https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart
> http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSK7IJAAoJEKXdFCfdEflKdIkP/3dQpOuzSlzMcXD68oD2L5HP
1ZrgAZzPkBKUOEvlH6WuCIC48k0GdeWCojz4kgo6LM8O3rsn3WRBO1iWbUjSxFja
P8W6bsLJw4t9Tuwk6GJvW0blM66lwQub2+MOynv8DRKloIoQ7yJZmlS1MurcNZFk
AQhl+3xoBpwkXIoR5zCJg0ipMuLV5PdqrtFp7VlPrs3yQfuFw/dxU2+sjo6Kau4a
WvPHzZWco328jVwPHh9F+nFD4F8jKXmBKwy3moOwFkh5a9XnJH3amG7sK37oNWVx
OkQ1pRPaBUyTvNOpA83kQFoa0I6ZWDLK/sCtxtNjadGBKHRwdMWBGN+iZWYH3CEv
uNJBxrJkMbubEpvRK/3nf+fvfa8ChNBbbZlOxyaZ50UCT7KtQ9S0VQWVjYuNYLQy
k9Yzc9jNcEilY5ux0RYqaAosZKso3ePkmbBfZLUs8E2F2C7NwJkhj5tv0AGAWt+n
kN+9MlL/rQhlVh6FtobZVs2DfVxfC87vA0MKJFOoqsOR1w5p2f+mKAUMqJi4jEHJ
ElyJdgIP3KegBIRVp1N9URofA8mIA1fh0Ef3JMx6020LVFXBuO5lihtrLCLR+t5h
PmHrmfbLS1SS/qsN/OavGaYjOhMExcJwNFnuguhNFIcQUdLUmTRzXf7uQ9b1zrbg
ZxLySFNAMubNMQf9Q9j/
=TPkK
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Improve the security of the default profile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/07/2013 01:25 PM, Ryan Hill wrote:
> On Thu, 05 Sep 2013 12:13:28 +0200
> Agostino Sarubbo wrote:
>
>> Hello,
>>
>> during an irc debate, me and other people just noticed that the default
>> profile could use more flags to enhance the security.
>>
>> An hint is here:
>> https://wiki.ubuntu.com/ToolChain/CompilerFlags
>>
>> Please argue about what we _don't_ use.
>>
>> Note: please CC me in your response.
>
> * -fstack-protector{-all}
> No thank you. -fstack-protector has very limited coverage (which is why
> Ubuntu felt they needed to mess with the min size) and -fstack-protector-all
> has enough overhead that every distro that experimented with it dropped it in
> the end. If security is important enough to you that you are willing to take
> the hit then you should be using hardened where it's the default.
>
> There is a new option, -fstack-protector-strong, that's intended to be a
> balance between the two extremes and something that distros can enable by
> default. It was just added to mainline so it should be in GCC 4.9. So let's
> revisit this a couple years down the line.
>
> * -D_FORTIFY_SOURCE=2
> Enabled by default since gcc-4.5.0 (patch)
>
> * -Wformat -Wformat-security
> Enabled by default since gcc 4.3.3 (patch)
>
> * -Wl,-z,relro
> Enabled by default since binutils 2.18 (and as far back as 2.15 for the HJL
> releases). (patch)
>
> * -Wl,--hash-style={both,gnu}
> Enabled by default since binutils 2.18 except on mips where it is unsupported.
> (patch sets it to "both", developer profiles set it to "gnu" for ignored
> LDFLAGs
> detection)
>
> * -Wl,--no-copy-dt-needed-entries/-Wl,--no-add-needed
> Enabled by default since binutils 2.22. (upstream default)
>
> * -Wl,--as-needed
> Enabled by default since July 2010 (in profiles). I think this is the
> upstream
> default now as well.
>
> In addition to these we also enable -Wtrampolines and warn on DT_TEXTRELs.
>
>
>
Thank you so much for spelling it out for us. I don't even know where to
begin looking for how some of this stuff is enabled so you telling us
what is enabled makes a huge difference.
I'm semi-familiar with -fstack-protector-strong and I look forward to
revisiting that at a later date (and I'd love to help do the testing so
hold me to if if you like).
Thanks,
Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSK4OVAAoJEKXdFCfdEflK/N4P/3zPgskznIRwgkEVmqJgOGKL
jUQSva6zOptAGUX3TBdmxppERiWwRR+qh00+JdRP34rH+yEaU3THyjoSreTzunXW
+oFcBeNR6qiiYGTKoGwQTtM0gxbkFvCx6fe/AAGkwYinTrorL8eo3VmnjBvzvBP4
Gmw138SMA/JGLG4A2s5vQBlBZlwvFOyNwP6RzAt9SoNsYVuskDMnFiw77pnqbEYT
OwdkGRwG29995L+p3O4lbsj7UjLx7S4/SpFfh9OK2EObQ7IKTb4M/y7TUv4vMSxG
b4uEtNRH2ymr/u8kHOLeVBFBvKbtB35hE1ubLN0ugtuAvQKyD/tECC1msXuKidqi
vjrhxqtMG4c9+7yY1My0S9CkFqR015ReiC9mFgbVO588XKDOCT7QtcCqGVfvEOrS
/CNh0qMS5JeBwAya4rmiZpGkc0LTW3rjzLsJfu3sVAd6nvHh1923gSpnJpnd7u9X
EpGORP29NUyu3W7zggJm36JEX+pNvTlG1NmR7ux9NWVFKVfUVBU/wAnfHmCpTHo8
O8FI2Z3GlEwXNXL9nvDn7DJRVsC4TOl6SbHteVRY0soGmyoQhf9I1D0idLFLv88k
HHeTzhVt0dl0OiWBs8n7AU42bA/QMUvLF4wUJM+zBjkZHNgWvbL895eyAOJdGAyo
2HEguV/K746RLBHhRRTe
=gq9h
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Improve the security of the default profile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/05/2013 07:06 AM, Mike Frysinger wrote: > On Thursday 05 September 2013 06:13:28 Agostino Sarubbo wrote: >> during an irc debate, me and other people just noticed that the default >> profile could use more flags to enhance the security. >> >> An hint is here: >> https://wiki.ubuntu.com/ToolChain/CompilerFlags >> >> Please argue about what we _don't_ use. > > the only thing we don't use by default is SSP. and we have hardened for that. > > fairly certain the other flags we've been using in Gentoo for years. > -mike > Since I don't see this in the profile and I know almost nothing about how the toolchain works, perhaps you could grace us with how to see the fact that "we've been using in Gentoo for years" :-) Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKqIYAAoJEKXdFCfdEflKCwkP/Rdlo2rk+g8qyfB9SlsFgoP0 4b+/qkB8WmwNBEURhR7kwF/SJa6kh0BOcorz33e/YO4jayn/yW1ve36HrKOGR52G 56oNWWtRYzsiscObpOVxf+JM9EMm2RVrhfM1Z9FIP8pTFS8gj31fR8caPJssjUGv xl0wSUahs1+q44xOX+NB+7y47nhrjwfq2OTUHsekMdOWt43MoLp86qEMJKlPFG9a djEpkshTpE2pZZMQ8jGGASmITcWlHhuipeWkwDCblcxMMCWgFr+CfovEqJXeoz5I jI4rtpe4QNl7QA+eXY1fygiAiVgx15BYq2SIBC51AluvVgaYRw8ANr8qSUhCakXM Af49vhzp8/Id3/aytOrllprucPHTICMARKbYhAJyGtfJtKkQ3iGHHOlrIN2ufnrO gO/EZUqb+NRlHrv845a0HQA3zmYDNBJw5zu6GymV4aMsUcVQE/uSbqAZ7BxuWlV2 LxLvE9pn48WvcvBYp4R36DRQg955D34GKI1VRojgESsyLIgq4Q0wLjarY1fsG4O/ iUZRyXOI5erVCiOGey42kCr19fw1ta35XtKrEQPwWJkb2na1RB7PHbGBdVBlU/Lq mLAWFSCwocg+wNBuBWcpJlFdLV4eQYxSqyTqeFdxYBv9qxvqqLzkGUxqDy8L4bAT KglCdavI5Y2UBcFuv4/w =yb4E -END PGP SIGNATURE-
[gentoo-dev] ruby_targets_ruby20 missing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > ozzie src # emerge -vp ruby > > > These are the packages that would be merged, in reverse order: > > Calculating dependencies... done! > > emerge: there are no ebuilds built with USE flags to satisfy > ">=dev-ruby/rake-0.9.6[ruby_targets_ruby20]". !!! One of the > following packages is required to complete your request: - > dev-ruby/rake-0.9.6::gentoo (Change USE: +ruby_targets_ruby20) > (dependency required by "dev-lang/ruby-2.0.0_p247-r1" [ebuild]) > (dependency required by "ruby" [argument]) So, um, why exactly is ruby 2.0.0 stable if I can't even update my system anymore? I'm having the same issue across 3 systems so I'm assuming it's not a bad sync. Whatever the current "solution" to not adding ruby20 to RUBY_TARGETS is, it's not work for me. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSI9EQAAoJEKXdFCfdEflKPjAQAICCV5hwk8bJNSBvmaoR9t+k r7fAVnAZtDMFgMK6LBUIlsJU7/Z2YjpuTU25My0aRJEQODUSusYO7YFys6QosnnA hy5651Nj4PL2Zk2PFSfGRTjMyyc32kGJTqaCbOXiBVsKSbKpxzjcyp6HKsbZ/n3m FHHk/NAYOqI11BzB1N9Pet3wYwvj+tJ4Ao+Liu3WrqnfJxo7TTVTZAiTCxrfE1l7 PMsBoGkf7IqrFIC/HoBEE8um3PhSQQmyxXvr49+0MWRhlkQZXKVgD33lQen12jZ0 JBRQQYsLwNPFrSwc4/Y4Us44A3+36eBmVHPQs+EkFKzf5+fO8Ppot0vzmTE4HhHA BkpWp2QKKC9W7UlEq7VenydN+erQ6j+BwqKT4+5sMmczLd+5dNsg4aPAIVRVXrqm AyvoMP7qv6K+jnPOLvg1md7LJpsrSYV9VeKwR2d+mPA+PZWzRfI3O7AwpDVXbAyP VnO7VgebPbpwsW8GXHyq/8P5QuWcSdQbt+pO3j7Lzevb9bAakU43d13WINhEWyMG Tw9FioslSTHKFR5TUvKYD5XgqFB/flUzkJNBH7MhPGpIAYpnAdRwfgPakNt6uTSK VIdRx+6wjeKtlQVBeUt/9iQ34HjGEtT+6XFyXp9iuP/X6h+HInXmCYsguMt8FMvn M+7cUXZYoz4VzHh3qtry =x1aK -END PGP SIGNATURE-
Re: [gentoo-dev] Moving more arches to dev profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/22/2013 07:24 AM, Rich Freeman wrote: > On Thu, Aug 22, 2013 at 6:19 AM, Markos Chandras wrote: >> On 22 August 2013 11:01, Rich Freeman wrote: >>> I think the result of a policy like this would be that stable keywords >>> would get dropped on most peripheral packages, but system packages >>> might still keep them. >> >> What's the point of that? Most users need more than what @system >> provides so after they deploy the 'stable' stage3 they will >> start pulling ~arch packages that were never tested against the stable >> tree. It so much better if stage3 was also ~arch. > > Do we actually have examples of this happening? I've never had > problems with a mix of stable and ~arch keywords. Granted, I'm not > running ~arch on most libs. > > I've seen lots of talk about stable being less reliable than ~arch, > and ~arch applications on a stable core being unreliable, but I've > never actually seen any real evidence that either is true. Granted, > I'm not necessarily expecting a scientific study, but I haven't even > heard anecdotes. I can't offer much personally - I only really use > stable to any extent and I find it works just fine other than the > occasional need to unmask something. > I unmask/keyword things as needed for Pentoo and I can't say I've ever noticed a lack of stability due to it. I have a (mostly) stable base of @system packages and key things like DE's most of the time, but I also randomly mix in an ~arch package or two when I need to. Almost all of the security tools I put on Pentoo are ~arch, and many of them pull in some random ~arch libs, etc. I can't say I've never had an issue but as long as we all keep the deps are correct as possible it really isn't an issue. Just my $0.02 - -ZC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSIpI3AAoJEKXdFCfdEflKbHUP/RIPo/Z28yv627LU52VlQ9aP +GkEcCEi8Ae55GHaTvLWQqc1Qn03jqffKKp383XN3CyOp1dpQAFsgygcP29FJWTk KwXQtoSrOPrdt2lXsm3CEqE+NFD1SpuycZ/7nu/W1bhEgML7XdmAKKOwdfX/5FpK WVU4pXoU7it2/hCkScOBTGyjb8ULOKUmX6JH9JG1D2vGk2PAulHpAyD1ovlQYZTL lBWkYh6q8Bwf4aTPksmBc6ADfp4EmNJdh018l4OEyrj9uCyaXFB6BmHlMZJMCvk9 jBJngTj5driIhlPjVmyHbZvRcjbfyJskpUAbeDhQ1R+XSyx2hGLRPCEl66XvYpcQ aCFfYCncyvqPRR7Hcfh+xlOsXZMQZFTJSsFriudByC9Q/5V0mpL7F4OWUDsmDqRD l4k1MERDlbXTBfBVEaPTYsS5KtHZD+mYlERO+hmmJCjCB2WDMfE6Y1ItnQjN4Khh qZzeTm9UyHg0iViGQ6Fezt+ahMhYVVLZKm8a9n3J10AOiDjtsCPhDR/itH/ndNL3 tFir2pG/7cWisLHAISPhKO/e34liU/+QC1RHLxxGpaHciBYJISATMnQzqfv59eHL 3WUEMSOo6kTTEdIdTerMo3k0mZiILALACrwKcoK7lBhNrmyoPQynjKUqsw+Ry4S+ oPPZD+G+GEjW2XKZTZFk =5WWm -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/31/2013 03:57 PM, Tom Wijsman wrote: > On Sat, 31 Aug 2013 20:45:00 +0200 > Pacho Ramos wrote: > >> El sáb, 31-08-2013 a las 12:37 -0400, Rick "Zero_Chaos" Farina >> escribió: [...] >>> I know we are a little OT here but the fifth type of recruit is >>> someone who is very excited, very dedicated, and completely unable >>> to find a mentor. That is where I was for a long time, no one >>> seemed to have the time to mentor me. Personally I think that is a >>> big issue in the growth of gentoo, if we all take a little time out >>> to be mentors there will be more gentoo devs and we will get more >>> done. >>> >>> -ZC >> >> I guess we should have a official contact or mail alias to let them >> contact. If they don't even contact me, I cannot know about them and >> then mentor them :/ > > Ah, I like this idea better than the "list on Gentoo Wiki" I was trying > to approach; the only downside I can imagine if it were a single person > that might not respond in time (busy / devaway / MIA), so I think we > should at least aim to make it a mail alias with multiple persons. > > We could then list people on some project page; but, only their > forenames or nicknames and not their actual full name and e-mail such > that their private details can stay private if they wish to. > I remember actively seeking out mentors and recruiters on irc for a while and not getting very far. I think that exposing recruitment to a wider audience than just the recruiters is a good idea, why limit ourselves to their bandwidth? This isn't a remark on the performance of the recruiters, just a note that more people means more bandwidth. I like the idea of having a wiki page of people willing to be mentors for each area (or in general). - -ZC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSImdFAAoJEKXdFCfdEflKq+cP+gIhD2zAR6CnVFVx7hmYvPKa n8Jkg5oCPgchqVPN3AtDqPXwTELSPXTasRJCToaembKYuhPiyO6py/dpo6nIeg/P 4WiLZb+ehCSWAUBMmAemsDoL3WftwrV9w6h1bWBytpbrJ6YZEyumVvHNqMi3r7vI +k54LZc+uurUEHFtPP6SC6kCHj9n0lD/4Biq1lsY/vwZFViHzuBhnTHBYBohy4lo rkB2/k/KvrJ6F9MXfc87A/PUxkU29+WKiul9A9te/X97QheeXXWptI4gEYFevVgT aUP8AfaY0YAD1+RpjyxDPxJ4cTqcL38Wic8ql6pzlV9nwAnN3/fHFQEKJ477UWO4 YLGkdQ0BX4y0WkJH0H5fi3zuU80iHvLw0I0U1rVOP861IrlYxKMPuXUn6F1vGCpq Huzx7pbLcLE0GTYU6Sq5Li4zdMxW7Lre2oqIAD9smj1Fx2VpQp35lFI01TKfAbdb dP08EBfI/c15C6O8v1UooDYjwM7JV1EjoZW+OcPO8rLdahakzS6VhTs6JRMKH+UM X1xqX1Grj5dRUIt2KHGPtCxHAI9VuMQqWDNEv8qmDCzenL4WOcd2TCYL5HNofAbH lWJdKYL3m6OhEVH8e7qaOIbm0hShJBqY90kJWbyowJgbPSllaPepbBNuys3iq4dM eToDKW2TXa4ELG6Xc5vl =eFsz -END PGP SIGNATURE-
Re: How to find a mentor, WAS: [gentoo-dev] rfc: stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/31/2013 01:29 PM, Jeroen Roovers wrote: > On Sat, 31 Aug 2013 12:37:58 -0400 > "Rick \"Zero_Chaos\" Farina" wrote: > >> I know we are a little OT here but the fifth type of recruit is > > Yes. > >> someone who is very excited, very dedicated, and completely unable to >> find a mentor. That is where I was for a long time, no one seemed to >> have the time to mentor me. > > Your recruitment bug disagrees with you here in that you had a mentor > right from the start. > > The netmon@g.o alias never saw mail from you before your recruitment > bug was openend, so how could anyone have known you were trying to > attract a mentor and do netmon stuff? > > I don't see any mail on gentoo-dev or gentoo-project either. > > There are exactly *nill* bugs that you reported and were (subsequently) > CC'd or Assigned to netmon@g.o. > > You have only yourself to blame. > Always a pleasure my friend. - -ZC > > jer > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSImbCAAoJEKXdFCfdEflKi1sP/1lXGfpuM6u55OcAtvhiQFE4 CL5Zff1vHdLXv1/3JOz9WyVn6D5cmo2zF0Da3IIVYfbnEIU7TDTkdGUrGz/xnTJi wjbmbLQqxIrB5HYMMHVoa7JFsotkV8c4Tnwg2J81HcuQOQpJMb19xlkLHI0fNbrh 8r8Ac2MPGDdx3kwlq7K5zi85scYXGBJN7rR4Ok4y01AGZlrKLan2GH473/eoE8DD 8iLcm9tc2fvN/PWtAO2J0UvpqPbQOx9DF0ttWzVCA/RV/KAtf90p3Exf+uWCy8ru HHCxlo4hG9q3q5ehuJMYXw6cqql5RIB7s6HeJKM9lFXukaOxmW7+xiqo0ne22ePD Novpuip4rd5Brir2QKDLMPu8feQ+PJwkQU+U/q/K6KsSrTT2AYVnZR3SuiykjxG6 4AjBMF4KLVWLhOcYlmtCTg0XWBwqyN7+KBfiAVOKBwX0NZcUp8ILnd0C34I/Cqp+ YGPlY2JCpeWCU4XVJo++RhOtNZP9pnPFATcW+a2bdjMfTOQ9Z7Sjy3bn8r9d1TMe PMLEwVWKQkoreK8w1MNKoxU1x2UGkj82Fal/WEf8OLXev6hdzZOZ1tb/S91KRZT6 OoN7zQy8TpkFqqbNWRsIao4J6V9kW+4RKMCTAJKSqH/Ere1AoJje/WSkly+vuL++ SIVKdElbXczHu482qm6W =aN4N -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/21/2013 05:13 AM, Tom Wijsman wrote: > On Wed, 21 Aug 2013 12:32:35 +0400 > Sergey Popov wrote: > >> 21.08.2013 12:13, Tom Wijsman пишет: >>> Recruiting shows to be a hard task; so, the suggestions I am doing >>> are assuming that that doesn't work out. In which case, I wonder >>> what "by some other ways" you would think of... >> >> Dropping some keywords to unstable on minor arches. > > If we grow (like you said below), then doing less seems like a decision > that we shouldn't take; it is rather about "doing it different" to use > our resources in a better way. Crowd sourcing users is an option here... > >> And about recruiting, it is the only way we can keep moving with >> getting distro, which makes bigger and bigger all the time. > > Yes, but apart from recruiting you can make the resources used better; > if the current way of using our resources isn't sufficient, we can > improve that as well. Improving both is going to make the difference. > >> I would have joined recruiters unless i knew how difficult job they >> are doing. > > Yes, I am interested in both mentoring and recruiting and I need to > contact them again; but I do not really intend to point at "recruiters" > here or how hard that is, what I intend to point at with recruiting is > finding those users that are willing to learn to write better ebuilds > and are willing to become a Gentoo Developer. They are hard to find; > and in order for them to be found, a mentor has to find them somewhere. > > Came across three types of people already trying to find a mentee: > > 1. The first one doesn't want to go through the amount of time it takes; >this depends a bit on the queue, but it can take months. > > 2. The second one's interest to become a Gentoo Developer depends from >time to time; so, tries to start over and over to become one. > > 3. The third one writes a lot of ebuilds (and has an overlay that >looks like a gold mine), but there is a language barrier that keeps >the user from contributing; so, we take things slowly instead... > > 4. The fourth one leaves a message on IRC and quits before you return. > > 5. ... I know we are a little OT here but the fifth type of recruit is someone who is very excited, very dedicated, and completely unable to find a mentor. That is where I was for a long time, no one seemed to have the time to mentor me. Personally I think that is a big issue in the growth of gentoo, if we all take a little time out to be mentors there will be more gentoo devs and we will get more done. - -ZC > > So, recruiting in the terms of "finding recruits" appears to be hard. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSIhvmAAoJEKXdFCfdEflKwykP/32wuUhRfcwYZsq5pZDMhj3e KVDrODlnNt9gsLU3nWj4CuOil5IecWzaODmrejN9bWjW9xEPHGYhs6WfUkGL+8Bm wVg7yun1v/ACNynraLi9F3YimDeFruFSLMeYttaxb04KJVGdCETXQN4/qiKGqRl5 p4o1kEQUAWie0DURKm1rO1z7zdBOJczdk70QAcwO/5t80gCyrIlWFor/jZ1Nvk05 TASTs25Jxd5hQ+FZsqeIem458eQj3j+OvuJBgcBT34+7ka1nsP7ZWmLBVBEvejGC If3D0xaDQD0Rjxf6jtnt8vILSzQTq7UUkGLIvRGlxiA7fFSLxMrQHz2UDo1pxKfg BbQZ4ftm7icjum/DE5XyGWRHlbVE5Zvi/joV+pKoLw2BaDZrxTqGgDjqLGPpP5W4 P7/+3+PH8x9GZKgco1d34eFA9oXdGVorRDybuOb33Hy/CgUvAr+n9tLfPOjHW1Ye U09BTRzlceJQmp3KLHvdmYLIm9THsdI7YfjlSxPyaDKykiFNwRCfRPMvp2FTqBNr doVm8dyX8+4FqtW+BkwdUZjTVEv5AQv9jdqx/rfNy9UJ8qWfLTPXWcHrJWu8gOsv 3G+mAGvqKMXkJWarguydGf3q8QJzmPXscps4vPq9AcTpWldPLQW8lxPzic4IpYjN O3TUqhO0KX9NejKTO6Ef =yG20 -END PGP SIGNATURE-
Re: [gentoo-dev] git-r3: initial draft for review
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/30/2013 07:37 PM, Michał Górny wrote:
> Hello, all.
>
> After a few days of thinking, discovering and working, here it is.
> The first working draft of new git eclass codenamed 'git-r3'.
>
> First of all, the name is not final. I'm open to ideas. I'm open to
> naming it 'git-r1' to put it in line with my other -r1 eclasses :).
> I'd definitely like to avoid 'git-3' though, since that version-like
> naming was a mistake as almost-'python-2' eclass shown.
>
Seems to be a lot of schizophrenia in versioning here. I can honestly
tell you that git-2 is greater than git-r3, so I really caution against
this.
> Secondly, it's not even final that there will be a new eclass. Most
> likely I will commit it as a new eclass since that way is easier for us
> but if you prefer I may try to get it and git-2 more API-friendly
> and work on making it a almost-drop-in replacement. Since, after all,
> internals have actually changed much more than the API.
>
>
> And now for the major changes:
>
> 1. The code has been split into clean 'fetch' and 'checkout' pieces.
>
> That is, it is suited for distinct src_fetch() and src_unpack() phases
> that we'll hopefully have in EAPI 6. What's important, the checkout
> code does not rely on passing *any* environment variables from fetching
> code. It is also made with concurrency in mind, so multiple ebuilds
> using the same repository at the same time shouldn't be a problem.
>
> 2. Public fetch/checkout API.
>
> git-2 has a lot of private functions and just src_unpack(). git-r3 has
> git-r3_fetch() and git-r3_checkout() which are public API intended to
> used in ebuilds that need more than plain fetch+unpack. While this
> isn't exactly what multi-repo support pursuers wanted, it should make
> supporting multiple repos in one ebuild much cleaner.
>
> 3. Clean submodule support with bare clones.
>
> Since the submodules are very straightforward in design, I have decided
> to move their support into the eclass directly. As a result, the new
> eclass cleanly supports submodules, treating them as additional
> repositories and doing submodule fetch/checkout recursively. There is
> no need for non-bare clones anymore (and therefore their support has
> been removed to make code simpler), and submodules work fine with
> EVCS_OFFLINE=1.
>
> 4. 'Best-effort' shallow clones support.
>
> I did my best to support shallow clones in the eclass. The code is
> specifically designed to handle them whenever possible. However, since
> shallow clones have a few limitations:
>
> a) only branch/tag-based fetches support shallow clones. Fetching by
> commit id forces complete clone (this is what submodules do BTW).
>
> b) there's EGIT_NONSHALLOW option for users who prefer to have full
> clones, and possibly for ebuilds that fail with shallow clones.
>
> c) if shallow clones cause even more trouble than that, I will simply
> remove their support from the eclass :).
>
> [see notes about testing at the end]
>
> 5. Safer default EGIT_DIR choice. EGIT_PROJECT removed.
>
> Since submodules are cloned as separate repositories as well, we can't
> afford having EGIT_PROJECT to change the clone dir. Instead, the eclass
> uses full path from first repo URI (with some preprocessing) to
> determine the clone location. This should ensure non-colliding clones
> with most likeliness that two ebuilds using the same repo will use
> the same clone without any special effort from the maintainer.
>
> 6. Safer default checkout dir. EGIT_SOURCEDIR removed.
>
> git-2 used to default EGIT_SOURCEDIR=${S}. This kinda sucked since if
> one wanted to use subdirectory of the git repo, he needed to both set
> EGIT_SOURCEDIR and S. Now, the checkout is done to ${WORKDIR}/${P}
> by default and ebuilds can safely do S=${WORKDIR}/${P}/foo. I may
> provide EGIT_SOURCEDIR if someone still finds it useful.
Thank you so much. I've wanted to do this forever.
>
>
> API/variables removed:
>
> 1. EGIT_SOURCEDIR:
>
> a) if you need it for multiple repos, use the fetch/checkout functions
> instead,
>
> b) otherwise, play with S instead,
>
> c) if you really need it, lemme know and I'll put it back.
>
> 2. EGIT_HAS_SUBMODULES -> no longer necessary, we autodetect them
> (and we don't need that much special magic like we used to).
>
> 3. EGIT_OPTIONS -> interfered too much with eclass internals.
>
> 4. EGIT_MASTER -> people misused it all the time, and it caused issues
> for projects that used different default branch. Now we just respect
> upstream's default branch.
>
> 5. EGIT_PROJECT -> should be no longer necessary.
>
How so?
Thanks,
Zero
> 6. EGIT_DIR -> still exported, but no longer respects user setting it.
>
> 7. EGIT_REPACK, EGIT_PRUNE -> I will probably reintroduce it, or just
> provide the ability to set git auto-cleanup options.
>
> 8. EGIT_NONBARE -> only bare clones are supported now.
>
> 9. EGIT_NOUNPACK -> git-2 is only eclass calling the default. D
Re: [gentoo-dev] [RFC] git.eclass, git-2.eclass... git-r1.eclass?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> The new eclass is supposedly used by 732 in-tree packages [1],
> and possibly a few dozens out-of-the-tree. Some parts of the eclass API
> are barely used. I would really prefer to avoid yet another eclass
> migration.
that's a shame, I don't think it is avoidable with the changes you are
suggesting
> However, I would like to do a few breaking changes to simplify
> the eclass and its maintenance:
>
> 1. Make EGIT_SOURCEDIR default to ${WORKDIR}/${P} rather than ${S}
>(to support setting S to subdirectory of git repo),
>
> 2. Kill EGIT_HAS_SUBMODULES and autodetect submodules,
>
> 3. Kill EGIT_OPTIONS since it limits the possibility of changing eclass
>code,
>
> 4. Kill EGIT_MASTER (it's more trouble than benefit),
>
> 5. Possibly kill EGIT_PROJECT -- it won't be good enough anymore,
>
> 6. Kill EGIT_NONBARE and support bare checkouts only. Supporting two
>different layouts introduces a lot redundant code.
>
> 7. Kill EGIT_NOUNPACK -- possibly replace it with proper fetching
>function, or just src_fetch(),
>
> 8. Kill EGIT_DIR -- it supposedly should not even be overriden.
>
These changes will cause significant breakage. That is fine for
migration, but not for in place eclass changes.
>
> But it's not all removing. There are also a few things I would like to
> change/add:
>
> 1. Replace 'git clone' with 'git init' + 'git fetch' that would be
>a bit simpler,
>
> 2. Add complete & working support for shallow clones, and make it the
>default. This means a lot of space-saving for people who only use
>the repos for ebuilds.
>
> 3. Add complete & proper support for submodules. Currently, submodules
>enforce non-bare clones and are fetched during unpack. After
>the change, they will be fetched and unpacked like normal repos.
>
>
> The use of API features in *.ebuild maps like the following;
>
> EGIT_REPO_URI 521
> EGIT_BRANCH 66
> EGIT_SOURCEDIR21
> EGIT_PROJECT 17
> EGIT_HAS_SUBMODULES 15
> EGIT_COMMIT 12
> EGIT_BOOTSTRAP12
> EGIT_MASTER 7
> EGIT_NOUNPACK 2
> EGIT_STORE_DIR1
> EGIT_NONBARE 1
> EGIT_DIR 1
> EVCS_OFFLINE 0 // these are for make.conf
> EGIT_REPACK 0
> EGIT_PRUNE0
> EGIT_OPTIONS 0
>
> I will need to take a look which of those cases can be replaced easily.
>
>
> How should I proceed? Assuming that git-2.eclass is used by live
> ebuilds only, and those ebuilds can be subject to random breakage,
> I could supposedly just start changing API of the eclass.
>
negative, breaking ebuilds is different than upstream breaking things
and needing ebuild fixes. Randomly breaking 700+ ebuilds isn't cool.
> On the other hand, I could also go for beautiful git-r1.eclass,
> and cleanly switch the packages.
>
> Then, I could go for something involving the two -- create a new
> git-r1.eclass that has API fully stripped, and start deprecating
> features from git-2.eclass. We would be able to switch to git-r1 to
> test offending packages safely, then do a big switch of remaining
> packages and make the two eclasses temporarily equivalent.
>
> What are your thoughts?
>
I have a VCS ebuild for nearly everything I officially maintain and
almost everything in the pentoo overlay. If you change the eclass in
place that will break dozens of ebuilds just for me. Please don't.
- -Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSIYESAAoJEKXdFCfdEflKdXUQAI3Rwqyku4FCgO/3uivB/ltN
+pDlw0DCHt9IlBK1Jh3t+ohXVdXhi6iZyQ7ly+t+5phA3zhR79yTJWkxmXq8E7br
TM99Fsfd3Cqmdc54F4uA6MHI9MQj7efCkE3mas9bks8SPBnNTVwWmjVYUxBXZXfm
J94+tcCEdesVqz2/iivm0iQ6W7EraCTG+umz/wz1urqIfDQBO8mDLHoM+jiovnUb
tArOZ3GIhS/Rj+S/ZtH4VpvarFrH5ZzfO1GpNAvaFS8kGLRdEoUnMYk6K+WNdbkZ
SYldaL8M/gNKWfmRU+j8OGK7bsNJx43Bqei7oUyMqkUVsTBpjmkPvw59aFKVlb7J
kdfeoobpFsuAcxaQfWU1J8map82N8McdVOYMkEkC3HJP33TeymZKSUcU2/iMxr1W
+kU0C2L7A9oXzWwkmiQ9WxAQ5KTYzyh5AzaaN45pju+QlFc2T4P4AZ4oqy+Zzzi2
CH2JZBPdv9+jMQLcwhpVoDsOPbbLGrx/aJEARwKvgs2fF+WYllraOu7uMPnaoYWw
wNK9JYyhncx2pfG23PG7Uo3RtN8Aks0tptsHosOmB9ZArtnhYL2SxlotAoef+9X7
2qxFm59D9koW5FF0arnzzF/ul2zzos7NZRwJ1bwR1gYocxvN6Yqfg0zeX6uC+sDW
dSukBOrVEuyftf+KurL9
=harh
-END PGP SIGNATURE-
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2013 06:26 AM, Michał Górny wrote: > Hello, fellow developers. > > I've added a few new fancy features for Gentoo developers to portage > git. Sadly, since Zac isn't planning another release until 2.2.0 goes > stable, you need to switch to - to use them. But I say to you, it's > worth the hassle. Any idea on an eta for that? This is some fantastic looking stuff. I'm really looking forward to using these features. Thanks, Zero > > The features are off by default since they need proper testing and can > break a lot of ebuilds. And FEATURES=network-sandbox does. > > It should be noted that all of the features follow the systemd idea of > supporting Linux only and require fancy kernel features. > > > The following new FEATURES have been added: > > 1. FEATURES=cgroup > > Requires: CONFIG_CGROUPS > > Applies to: all src_* phases > > Enables long-awaited cgroup support in portage. Each ebuild is confined > within a control group and all spawned processes are tracked. Once > the phase exits, all remaining orphans are killed. > > This helps especially with multiprocessing/multibuild stuff and some > test phases that need to spawn servers. It ensures that portage does > not leave any orphans that would otherwise need to be separately > tracked and killed. > > Control groups are applied to src_* phases only, since we expect that > pkg_postinst() may restart external daemons, and those could end up > being attached to the cgroup. > > I doubt this could break something. > > > 2. FEATURES=network-sandbox > > Requires: CONFIG_NAMESPACES, CONFIG_NET_NS > > Applies to: src_* except for src_unpack > > This one uses the unshare() syscall to detach the build process from > host's network stack. This effectively means that each of the listed > phases will be able only to access a detached, 'local' loopback > interface and nothing else. > > This has a few implications. First of all, ebuilds that used to access > the Internet won't be able to do that anymore. In the Python world, > this would mean that some packages will start to fail properly instead > of downloading missing dependencies. It will also break or skip all > the tests that rely on the network being available. > > Secondly, this will prevent any kind of communication between host > network and ebuild, including services running on 127.0.0.1. That is, > ebuild will no longer be able to access production services running > on the host. This affects e.g. old mongodb frontend ebuilds which used > to run tests on the live database server (yep, create and delete > databases there). > > Thirdly, this will prevent the daemons spawned within ebuild from being > publicly accessible. That is, if test phase spawns some kind of TCP/IP > server, even local users won't be able to connect to it (outside of > the namespace). This should improve the security. > > This does not apply to pkg_* phases where networking may be needed for > some kind of IPC, and src_unpack where it is used for VCS fetching. If > we introduce separate src_fetch in a future EAPI, the exclude will > move there. > > This one's going to trigger a lot of breakage in ebuilds. Therefore, > I'd appreciate if developers started using it early and fixing > the ebuilds. > > > 3. FEATURES=ipc-sandbox > > Requires: CONFIG_NAMESPACES, CONFIG_IPC_NS > > Applies to: src_* > > This one separates the ebuild's *nix IPC stuff from host. This includes > semaphores, shared memory etc. Similarly to network-sandbox, this could > prevent ebuilds from communicating with some production servers. > > But honestly, I have no idea if anything really does it or relies on it. > I doubt this could break something but it's worth testing. > > > I'd really appreciate some testing and feedback. Thanks. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSE4Q3AAoJEKXdFCfdEflKB+wP/3ZYGqcdOz+ojIx5+7DT+OBY qJEz8oIDI73P/Bn6VsLAeq2bO5RaLLB1rIqB4cxbIncxLb/Vwsuk6VgryPNxaH7C +2ctSZEaUSo+2Kg2sVrHxd+n0kC19GrZOXr9y5HvKSWofMYP2My67xAoRrg0/qe8 7A1jjMKbh29L+rt8krnSNYHt9EoUe7soeNEcCcVYkyRUkoQnkOy0qqBBvAUB8Ggy Gt0M3zZ9aHYTCcFbVv/JW7kntMt601AMMfsz/zK2dcBu2nyPCz1oOFgsfz23qPTw GYh2iJxMekWihxU/fJHGJIlXnNxhRHxCB7tKojgYiREqbVcBEWSr9S7QoNKL9Lts ZZ2ubSXuwjpcyGn4ih2lWdBFb7vvG5lKVoFpQimG1/sNLTgtLCejZ05IFvd08zyo UNpp2/lZpJuBsGi8zXVhUlDz8Fe4itNBHjXq90LqWDsQlp3h4BmYjxdrygG5LPMt +S/6hK24muE27FDEFLGEMNl71DZykETPq6YYFgqvQpmhgTVtDBUHCQ8L1UpQwBIE PMwEnwTJtezsfKhPR+OTNBRTAVHRL4/MF7lL3wVrLHJ3wpyFVEec2ixJ3vK5ap6Q TgPzMm2QhYS1ncCNCt4Gwxs0DyHuZrSrkWKLlWW8o6A2qWp3TxCeaEfkfca5nn/e 9IzX5hSKEbHlyHBmm467 =4jTs -END PGP SIGNATURE-
Re: [gentoo-dev] Patch applying function for EAPI 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/18/2013 12:39 PM, Ulrich Mueller wrote: > Hi all, > > For EAPI 6, introduction of a patch applying function to the package > manager itself is being discussed. This would serve two purposes: > - support for PATCHES variable in a default src_install phase > - a function to apply user patches Isn't src_install a bit late for most patches? > > In bug 463768 the conclusion so far was that implementing the full > epatch function in the package manager is not feasible. Therefore, > the package manager's implemention would have reduced functionality. > The current epatch() would remain available in eutils.eclass for cases > where its more advanced modes of operation are needed. > > The feature list we came up with (see bug 463768 comment 32) includes > support for regular patch files, of course. It also includes support > for directories, with patches applied in lexical order of their > filenames (only files named *.diff and *.patch). > > So, the questions that I'd like to ask are: > 1. Is the above set of features reasonable? > 2. Should the function do automatic -p* detection, or should it >default to -p1? Both would be overridable by an explicit -p* >option. There are good arguments for either variant (see the >above-mentioned bug). Pretty please autodetection. It's a very nice feature that we seem to already have sanely implemented. Thanks, Zero > 3. So far, we don't have a good name for the function. > > Ulrich > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEQM5AAoJEKXdFCfdEflKGqUP/iBvycWstFl33uNSLLgYTFbt joA3Q6hmEjQmOJSqmSSazJzvKzvlVF2PlShKq2SzHcTr7WPXCXVcZuC1DbKZEnA1 ZHPgYrxb+KN7/V+Eh7i4CEslhnf9DPqBsHZc5dh/tX3jHeVPcSphDrz96TVnEtT/ FIY0RPIYCfDOPjQHQaeCorNoZNTU54box2iCj0UwwWRLQeMDyuS9LAT0BNUBBi4M 9q6dCAZe+Z1hUgDE93VxeT4a7h4ytlYlfi8COQxZubqhOczXLL7p5UobUy6QuqLY TiUAvd+c69iU7zvhERKiEJcxapDhfxFqqYL1m+Zs+0ZAVEaMQkeHnWFY+Rdz8an5 iOnqW6r8LYit2upqyUS582gyTkw1+3aYBOITtSxHvZq4JSSCNuc7rp8HXMjYMaUh TN10qb4/PtbRkJDnALH/3+F3Dzu55ujSJgn0QH4+5+Ect82NjlSPD1jBRsHkATq+ 04kHeGuvj2yp6UuT9Qt5ndbDEzy7eSVCrIeXx4J7YgCj6xU1cAl3X7QjCD+yx/K6 xNd6swsvjiBPdDSzSiBxDDTdvFj9585Zw4iT+uIm7MMXKM7thNEJK6yuVLkOU1Gh kahndJdAQkE5t09tMr5c0wdvD0fXGXQNk2nMaykLbXwAF3zJRccP1enytufdxgQR WyaQpr7+jTp851spxxgm =NTh+ -END PGP SIGNATURE-
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/13/2013 01:21 AM, heroxbd wrote: > Dear Fellows, > > Canonical is raising money by pushing their concept of Ubuntu for > Android[1][2]. The idea is to put GNU environment (esp. Ubuntu userland) > in parallel to Android to drive the external HDMI output with X11 > protocal, so that desktop applications can run on the smartphone. > > The idea is cool, but not new. The idea is general to all android > devices, while Canonical is binding the concept with its own new device. > > The project is developed underground by Canonical, so far nothing, not > to say repository, is available except advertisements and the call for > people to donate. > > As a natual consequence of the on-going Google Summer of Code project, > Gentoo on Android[3], we can run native Gentoo on *all* the Android > devices. Compiling out an Xorg and output to HDMI has no theoretical > difficulty. Furthermore, sharing of graphic output with Android (instead > of a separate HDMI output) can be explored with wayland x11[4]. > > I feel sorry to the behavior of Canonical. We, people from the Gentoo > community, can show the general public what is the cooperative way to > develop desktop/smartphone hybrid to benefit all. > > I would like to kick out a sub-project of Gentoo targeting smartphone > and tablets. It would be nice to find out a solution based on Gentoo for > desktop/smartphone hybrid *before* Canonical's release. > > Comments welcome. > You know what I've done with this kind of thing already. I am at your disposal. If you want to publicly embarass canonical by releasing something awesome (either first or better) I can find the time to help. You know where to find me ;-) - -Zero > Cheers, > Benda > > 1. http://www.ubuntu.com/phone/ubuntu-for-android > 2. http://www.indiegogo.com/projects/ubuntu-edge > 3. http://www.awa.tohoku.ac.jp/~benda/projects/android.html > 4. http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29 > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSDbFuAAoJEKXdFCfdEflKiJMQAKlQtLQUBsWeCqI4YgYOsmX0 x9laSSQARdmfLC7Gt57ab4GBveZmwPAVjKi3KkIHZ3rUDrC2UehMYM/x8OMygLbJ tc8yec60KzG0AZ2GKcdvb7pZu1fM+gzw6qpFItqZ89YL/KN5ECdyNeTQz14QGuLY SzckuuDI8KO3WlFw8sQHic3gTd+r2+WSMNTvj1ln9M91sYjKy40Um6c6z/rpjJsm osHfKYKpiuGNEwAa/ptRwcxPmLWWyp0m38zl43vrBli+esHQYbS+zK1tX/xh4dxY Sj7CZc5DgUTfEmRL50U+gGx9wcQ5oMrVT7r4WK8I1O42tnoTQuRSqbNhYbrCHUCr ionaFAE4oKjJEOnjBwC9zA7p2OBJmtO9aXkQ5Wr51TtWN8xMC3wYCPCJgsy1Vo0H fjECKuoB1zNrhlYeDFAD13f5+2nYsxK3Y0qp1w4/KHsaZkqgg4acsF3hjGE8cMFR 3Z+72bebAi0QbgmFp1pY3BurptypvNuHpU+ErYEO8uI5+TwUrc4d6k6kvm353D/3 u6Xk5h74Xex/H4N33pytnYBxV6sNoMQiE3I3GCwe0y7LeZuWbe1Yz1PBjZULwW0u Uw8WAkPxPMHGDhB/78BLoO6Oc2JTjFA6ps5MKz/AaBjgv7u/HQ+tlPt9lHGhRCYm bmEznQB+UdpH9mI6DKTk =ZPJo -END PGP SIGNATURE-
Re: [gentoo-dev] systemd team consensus?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/11/2013 04:30 PM, Michał Górny wrote: > Dnia 2013-08-11, o godz. 20:59:01 > Tom Wijsman napisał(a): > >> On Sun, 11 Aug 2013 13:29:16 -0500 >> William Hubbs wrote: >> >>> I am splitting this to a separate thread, because it could become a >>> long thread pretty easily. >>> >>> On Sun, Aug 11, 2013 at 07:14:00AM -0400, Rich Freeman wrote: On Sun, Aug 11, 2013 at 3:51 AM, Samuli Suominen wrote: > I've been considering packaging systemd in sys-fs/udev with > USE="systemd" and use of 'if' and 'else' plus creating > virtual/systemd for proper / installation and some other minor, > but bad design choices done in the systemd packaging What is the consensus of the systemd team regarding those choices? Would it make more sense to just fix the packaging rather than forking it? I'm not sure what all the issues are, or how widespread the disagreement is. >>> >>> I am a member of the systemd team, and I know what needs to be done. I >>> have offered patches multiple times the last few months to fix the >>> packaging, only to have them refused, >> >> Why were they refused? > > Because it introduced QA violations and unnecessary backwards migration > for our users. I'm not really into moving files every second month, > and so far the main argument was 'I have the citation here'. > >>> even though I have presented, >>> multiple times, strong recommendations from systemd upstream that I am >>> correct, as well as making it clear that I would take responsibility >>> for breakages the change would cause. Originally, we did install >>> systemd correctly, but that was changed some time back, >> >> Why was it changed? > > Because systemd executables linked to a number of libraries in /usr > and moving those libraries to rootfs is not really an option. systemd > officially doesn't support running with separate /usr not mounted > at boot, and there's no point to pollute rootfs with a dozen > of late-use libraries. > >>> before I >>> joined the team. All Samuli and I have asked is that the change we >>> made that puts everything in /usr be undone. >> >> Why is the change refused to be undone? > > Why should it be undone? Changing things back to a broken state is > called a regression. If upstream doesn't support something it's not a regression. This upstream removes features all the time in the name of progress. Either get on the train or get run over by it. If /usr isn't mounted at boot then systemd team doesn't what your system to boot, so either don't run systemd or catch up with the rest of the world and learn what an initramfs is. - -Zero > >>> 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. >> >> For what reason did these specific state changes happen to this bug? > > Because I am *really* tired of replying to the same request over > and over again. WilliamH is continuously bombarding me with the same > request on mail, IRC, bugzilla and mailing lists. And almost every time > he pretends that I hadn't given him any arguments. > >>> my personal efforts to advocate for this specific change got me this >>> comment as well [2]. This bug, and others like it, would never have >>> come up if we were installing systemd the way upstream recommends. >> >> Why was the / -> /usr change so necessary that it causes bugs like this? > > Installation in a different prefix doesn't *cause* bugs. In the worst > case, it triggers them. Bug was reported upstream and fixed. Upstream > didn't doubt this is their fault. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSDa7YAAoJEKXdFCfdEflKVjAQAKcSbuo6aG4zk83tyOE80t80 woin3mxHIuN8x7smp7/qa8mXEeTHMnnlROIr8VbZDwz3S9e2ewfS34MM9R7ZrjLX VKFNGNfcTmwdqREIpuqthq309DP0NUjf3j3GnzQvyukVjbmshoZbd6pvVwxFfQJq OiGmL9e2v2IUnjrZvnytMIKHvdPCrYjhvRKu8afUUPgNAbd6PasO8jM0Hwo/n46V egOt6KpAnC5dS35mKWp32NKdKMQm4eMuwWlbRXWolX/9RheJnw9cKYPkqE0JiRPR 17SKq8NBXnuTaJ++MbOh5JTLr8BOaBaxo0I8kjnsjDIbR84/wEkomCXv9YK5EO35 f4Pz3iMxbXVW4LrKHRRikD7IYCaekPnZz0adISPRqdrfJbnY7WYIt2CDPD+dolLc HEyo2+11hq8XrbmYB96dObF4jmW4fSV5NUBsP3d0RZyHpD8snGy3XgVJQWmXJ+LO CGq4WQk6ZMnNKb8jjNn5e79aC5YUL9Z9u+sDHz1ku8LQZaNiqRAN10QPIENcLH7S 6Ox5j5j7XtuPFKFe8rd+uFCyoqbq0zXpiPg39k/lxvd+RkG
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2013 12:08 AM, Matt Turner wrote: > (I sent this to gentoo-releng@. Resending to gentoo-dev@ for a wider audience) > > Can we make autobuilds go to /experimental and then only move them to > /releases when someone actually tests them? > > Looking at bugzilla and listening in #gentoo-releng, it's kind of > embarrassing how often someone downloads a Live CD only to find out > that networking is totally broken by a udev upgrade, or something to > that effect. > > We don't commit version bumps straight to stable; I don't see why we > do with release media. > It's been an odd week for me agreeing with people but yeah, I completely agree. I think we *need* to keep the autobuilds going as often as possible to detect obvious breakage, but there is no reason they shouldn't be marked experimental. The real question is, how realistic can we make a process of testing and moving to stable? - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR80jxAAoJEKXdFCfdEflKhGYP/At7Xtd4bWcY1wrxl1oPYdNr vVfgqhmnveNqwhdERcp8InGLGoCDt+O3hvSzq4kX8qJXqizxPonP9ef1hJsnz0iw NgjMHiGiYp2NgmU6DB7X/VLH3RNF96WJMK/R2Qtk1tuN+Ftu1D6T5hP4MmTOuvta T2CvfYGFVAPZiY9+GLAmbe1LhjwlbJ8DnhbaamA7bK1D0ZhApWtRVtjk6unu+D5w XRG8tIDml5gUkZRVl4d9Bg1wxuMoPtOuY2ANr+RCJPRVMkexB1XCdAVzPF73EFx+ 0Ns5TKi+vWyhzY6PElvA0xClj2wAK/enAkAmPZ8OvagnCLfmoqZUNyr4+Eupxclt 54pFMzpdR2KntmmFqS5ZBF8Q6nxz8GDhSm0H8+d1xTKxNcwKSlaAI7JkzBByWhKt MjFYNTVz7MD/MFpvpRt2tKg3BI6m/ZcgCQwnAJ9QjdtyhLA8/Km5+AA2tnN457V7 qlpf+ipjDzb3G5Po1JXSMUidy8Uu6SvqHu8TwiJUy/mlKxjmPmrPPGfRpR32pWNT d/jE6IQAmiVjXWTDDBi0uZY8oUl5H0uroLFuA+//NtmGD8DWmV1fK0PYKLjUsE4X nWaCKn2qlF7d16mnJh1RweBjQjMmvRYutg62A3Jb9Ek9jXBIC4bYJa2VS2xoPpWy qZv8oon/9z336E5Uvamj =KaUO -END PGP SIGNATURE-
Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2013 01:28 PM, Zac Medico wrote: > On 07/25/2013 08:29 AM, Rick "Zero_Chaos" Farina wrote: >>>> Shall we revisit that, and try to make portage behave more correctly, >>>> even if it means more revbumps / rebuilding? >> >>> Just set EMERGE_DEFAULT_DEPS="--dynamic-deps=n" in make.conf if you'd >>> like to test it. >> >> >> What (if anything) does that break or slow down? I've had all kinds of >> recent issues with updates breaking my autobuilds due to these issues. > > If you use --dynamic-deps=n then you are likely to experience more > dependency conflicts (or unsatisfied deps) triggered by installed > packages that have since had their dependencies changed without a > revision bump. These dependency conflicts are like the ones that you've > experienced with binary packages [1], but they will apply to installed > packages instead of binary packgaes. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=282927 > So I replace one set of dependency errors with another? This doesn't seem all that useful... Perhaps we need to reevaluate how we handle these things. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR8W56AAoJEKXdFCfdEflK1oMP/39a2my+nZ0rLkp3kgkWiPAT eWT9q9SABvbyc7S93zAF+YVqTzma3a9B+EpqOiujmggF5QgioMWlfpIpPLgdo5TX hoj7UfHncCZS+B8jprFbptJy6E63N020hUATH45RO0yCO+yzd4n1T+Lub7qiZ9jU NbETsndPbXC0i7HWJ4xUK00B8P1FFFVtJBVTVq050L/OKKz+t6xC6zw/vmFubs65 vPO0oHPWJuyfPQb25zD0+LO+3YUbjkI5caUuNInxIXxI15azIyUX2V5Cbd5e4Cq6 6TH2PSTcugo34IukWKJqQYRm4JO095HvukIK40taS7c4I50ToTVMyNjXn8h/FqKH s+IG2amnwdW2MiJT/PhFAyB++QUfxo3i5OVnhezJea1SYkI6rrBjbdef+Hgl1b5R MEPNBuJlteWcn+51JD17dbdJK7i9BZlPo7jDV/OxWymtLtHduiFzkf/z/lffKqqx 0dX2d0mX1pFvnSzVHeN9loOc9vek/yq/P3Utwn4gS9X8VnY0I9ytKUC+Djud5/OB C6o7+xilk7RH3JTHezgUit2jtL0YyPOHkhJ5T2eL9P8YigH/vz2nmmKlPY6OK6c4 Tu/EzPvisuaBTLOWvW5kpBDR0jv4iKRiS6JzcZchEqHuX6u7vjInP8MavZPsGlLC QbUSEcKWSf4vJXTf3h0y =le9R -END PGP SIGNATURE-
Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> Shall we revisit that, and try to make portage behave more correctly, >> even if it means more revbumps / rebuilding? > > Just set EMERGE_DEFAULT_DEPS="--dynamic-deps=n" in make.conf if you'd > like to test it. > > What (if anything) does that break or slow down? I've had all kinds of recent issues with updates breaking my autobuilds due to these issues. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR8URsAAoJEKXdFCfdEflKftIP/0w86aBoN8bO5WbJ3VAs4Q1L n50uLzcmo+mvU/1suL8oI8KEjUyIKHO6pItkJICwnb3BWzrrI0KJVf6xfkevd48e 3sQE6c16hzxiU/fEghMiJ2tq8IcC+n/iIZ817Mo3OLw9hV5Fo3duj5JGM3MyQceW cUI1VlIgCm0z6a4TqmwAUXfyTBbYXVLfJF+MyRPIR2PcOGYtFNQ9O7CK0nET5TVw f4eTViXjOGs2EMHDLbkUvmeNZgfmqDbQojWqPFjmu6Zot4VemvF2D5PjjBdd1Lt6 wKC6ZDxTVZp020haHrY+eu2ly6Ue6rno8rePhNmtM6sdW2hXyyE1OdB+dPKoaCwZ 2GfD//6r2J1BKk4QMGeSapH9xj5N4rDaz71N9lYtW1wkRErgLgbYeix4cFduaU4M L0nHmDrIDffmUBkK8c1igcsas5s9VAub4tYPerCsXF5re8W6zojt5a9OVYqwFjem 8KEyJ/OH7oAstyCgyRoLECLvrjfJejEM3iO1FHcjnkXBhG29OK8eLK8Ao+cF5int Qxu7xHPcL/ekr5caI7ONAWTgjv5mkLtr2aO/TP/EhnLyIk58ROfogpSit034BnZp wVwGdUAPuJG5ATv8MWNfW8ukQcNkdSfbxgxiSe72MVjzUy2Pd5kEpzrGZArW1obM ATULUhIeHMe8lLaVfEpg =BMh2 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/24/2013 03:18 PM, Ciaran McCreesh wrote: > On Wed, 24 Jul 2013 21:17:26 +0200 > Michał Górny wrote: >> Other thing is that Portage explicitly ignores PMS in this matter >> and uses dependencies from ebuilds rather than recorded ones. This is >> supposedly wrong, supposedly slow but allows us to be lazy. > > It's not slow. It's just wrong, and intermittently leads to very > strange behaviour. > ++ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR8HcOAAoJEKXdFCfdEflKsT4P/iU2JsDexTxUZ2IJzfTmXG80 1j1RL8fnisQ9Jq83xHE45yUpQzMYbvWqSCayu56WRzmwYmGQgRvysCg749HI3KVV lWRxrY28psGoXplwJf0VKUhBTXo6sp6Yb9Xnhgd2nHg5aPTb9SFYpfg8wnreUXuo OnQ7/EVN+9ZwVqWABRPIrSX9k1byexKRz1JdkNyWyuTDwwQw6GUHIjWet5uvy0tC Wd8NZ8Ow5JA3HB5rfolTdl4fYTKCLMqwVkqOTOr37lBSx4gzu8w9hPAy5SenWcMl wbbB8uKktdcSUE46UHPuxM21D+mYjMP+YzU2MecZVe5pUoHaCvmVBCpDrXf68/Jt wRbZRn5F3I8WJUQe82xR1VRjmwbmMx+mqvdJlQO3VSEF7EcXZiYKt6EyLfz869e+ 57EvlwktW1yh/x4WIJeYfU+KJHKDLMJCbUxn4mmcZBowY0Qiif8vzGhT4r5kdDqo 1ewLImqvgE5o7zzNiPFx2M43ikbWwnU4KCm4nTi5rYdB5+y4D2FzXZyCz/UBGmYZ JvuRteriNwUcF2rW8Mzw2+SP2wxcxyC/8CbJOC2Df8qj/XOWkY9N/0u6Mrj4NmXs OD1Ner2fXfed2xybbC8QIuRQlduspBR+lHU08AYbWH46Q3tbhS7HPdcGF6IO3EPb Dnb8zJNZK5cXe0FanC3a =wstY -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/23/2013 03:37 PM, Roy Bamford wrote: > On 2013.07.23 01:57, Rick "Zero_Chaos" Farina wrote: > [snip] > >> I think the real difference [between the foundation and council] is >> that most of the devs don't care what the >> foundation does as long as it keeps the lights on around here. Most >> of us, on the other hand, seem to care greatly about the >> development >> process and key decisions around that. If the trustees need to take >> emergency action to keep the lights on I trust them to do the right >> thing. If the council has to take emergency action to allow systemd >> units to be added without maintainer approval well, you see how >> stupid that sounds? >> >> -Zero >> > [snip] > > Rick, > > The council should not be denied the ability to reach decisions > between meetings for the few times it will actually be needed. > I know of no current rules one way or the other on this topic, that means the council can and will choose their own path. If it isn't abused, people are unlikely to complain. It's been years and never had an issue that I know of, so perhaps this is all a waste of bytes. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR7t60AAoJEKXdFCfdEflKouwQAJqW55EfU0v/7UEQxlg+P4rB 7islrd2CWabtMnplHgT6lSOwM/zvXnk7cNj5QWn0T3i0jh9DreoVl2iiBBWHmuCO GZkUGBI+q5Mwx28ffBitht+jy15JnjdpKB/rQcMaGkuyzYa973QwWVzztA5McWnV nnQEUYO4ub/IBC0C8UPB/Uw9LKrDnJo93gtDnj4K9egtlu06xOUT7dWuDDVljncO MdI4q+MsMyrM9QUKuZI3rCM/IDsJmr4lwmgSgMTuH9VWN5lPyjBkPsq/fNHFMfwW pnaGQjcbrIOnaVp04lDiQ67DK+LmDuF694PnXRLcI4PfKpjN1Fep+Eq6eVtnPKf1 xeEt6xrrALAHbo5xX0IZjIJtBIyFya1dA1fSFJEq4BN3mVgpn874zKl/xsRMetcp 9rQIrWkzsLoez58czqk5102TJQYHquLpiFfF9pRF4QQbiF6KRRcMeiglX0X5oRn3 LUvo0VOiU1+CoMSjZkxbtwWZxIrbaIkRfGwY4A0SQ3jjT3et+JPK7alrXXxgfhO/ BHg3rMMkgAz6i4ZHd+TiFFnxl60mGDZsYAexd4YsHrtK0+Ue1tSvI2hLJJf1AIVz dR/kO30/BDfal3UZxTym7pzWJ5eJVfJWJaUuUYxFXA2MjAJ+5cqHozx2bkmOiwZB ZuxoOKUm1axxin+h9w8A =4wKL -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/22/2013 07:05 PM, Rich Freeman wrote: > On Mon, Jul 22, 2013 at 6:35 PM, Rick "Zero_Chaos" Farina > wrote: >> The council really doesn't have the ability to just instantly vote on >> things outside of a meeting. The transparency of the body requires >> announcements about meetings, and their topics, with a reasonable amount >> of notice. It simply isn't possible to maintain these things and have >> the flexibility to instantly vote on things. Emergency action can be >> taken by many bodies, devrel, userrel, but the council is not expected >> to be the "quick fix" for things. > > I find it interesting that the Trustees, which are a legally regulated > body, can take action between meetings, but we feel that the Council, > which is not a legally regulated body, cannot. Legally the foundation > can even take action without any of the trustees present (it just > requires a LOT of members to support it). > > I'm not suggesting that we should just issue rapid decisions in the > middle of a flamewar. However, if we feel that all sides of a debate > have spoken we can perhaps announce a pending decision on -dev, > evaluate any responses, and then vote. Council members who do not > feel sufficient time has passed to evaluate the situation can vote to > postpone the decision. In order to pass a majority would still be > needed, so if 2 people vote aye, 3 vote nay, and 2 vote delay, then we > delay until one side or the other obtains a majority (as with any > body, the default is basically no action until there is a majority in > favor). > I think the real difference is that most of the devs don't care what the foundation does as long as it keeps the lights on around here. Most of us, on the other hand, seem to care greatly about the development process and key decisions around that. If the trustees need to take emergency action to keep the lights on I trust them to do the right thing. If the council has to take emergency action to allow systemd units to be added without maintainer approval well, you see how stupid that sounds? - -Zero > I don't suggest that this should be the ideal method of operation. I > just see it as an option. It wasn't even my idea... > > Rich > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR7dTxAAoJEKXdFCfdEflK0l4QAKlVFy6xHHXnIlTzYzciCWvS qKq9v9tssIty//FvFYUlSv4cpudbO8jzThp2N9aB+2oMswT6vFaf+JlTIjZj4nvo fVW9pRzBPxmyLvQySW4YprpoUFYTKPDkEyxqT2wERPHEehY3mnw5b+6FKmWJRRgs v/XPCbuasV+HVHeLu2uIim4YtQcFcpuXF7E9qD7K7CTgUz0ZITDCyJG59N8jxlFE 8//hVKIxe8LTuRm08WQDFWr4veqOdCyZACGz8/PJP8SeSgJ65kKt7j6i77OywwRe TnmcYlR2eHFLtFUd64blFoURLfhirZj/AFknURX7U54mdkXFxLYWYCnBj+ZzQibP Lb3h0Uh0DLgDw2QMVDYwfgjueqtmd+urQn+0cAmRs8r8HjQvPJeA7Rwl6KYIC7DG rIN7GyYKR5IFX4ISKgy4fZPh37rJ74v52bCNBKtVxRWz8oQpna09m+pQRGdgHXIx fbkTGIwiYr+X7cbTx6XBCNXl6KJjZ6hhgjj/EQ77Q+PIms6JebvgwosvF6fYxs/M 1f+V2tGlHNbYgptoeoi/MTzqE+x1sQZZ0TDm/FImzp+ei4TfzZzUehwdh0fgAoLJ KLE7/NBy222NeX8WS8inj/sa0DHE/xSSsgpvKDiUcHFUA3nVGIBmWJqbKfEBYkos 8gUik9Q03vXz7cwFMi2M =NYxW -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/22/2013 05:51 PM, Rich Freeman wrote: > On Sun, Jul 21, 2013 at 4:20 PM, Roy Bamford wrote: >>> - vote for holding meetings every 2nd Tuesday of the month at 2000 >>> UTC >>> (or >>> 1900 UTC depending on daylight savings) >> >> In any timezone in particular? >> > > Don't care much, but agree we should pick one. > >> >> The open floor is a part of the openness and approachability of the >> council. Its 60 seconds well spent, even if nobody says anything. > > The concern that was raised was that when it does get used it is rare > for anything to get accomplished. The desire is to have issues raised > and debated on the lists first. > > I don't have a big problem with open floor - I just think it is a bit > of a waste of time. If somebody wants to raise an issue they need > only ask. > >>> - vote on meeting format 2: "shift council votes to mail instead of >>> IRC" >> >> Please keep voting in public. Its good for accountability. >> If not in IRC, find a way to publish who voted and now. >> Council do not get a secret ballot. > > Agreed. I don't think the intent of that item was ever to REPLACE > in-person voting with email. I think the intent was to allow for it > so that when a critical issue comes up a week after the agenda is > already set that everybody doesn't have to wait 5 weeks for the > following council meeting. It seems really odd to have a 100-post The council really doesn't have the ability to just instantly vote on things outside of a meeting. The transparency of the body requires announcements about meetings, and their topics, with a reasonable amount of notice. It simply isn't possible to maintain these things and have the flexibility to instantly vote on things. Emergency action can be taken by many bodies, devrel, userrel, but the council is not expected to be the "quick fix" for things. - -Zero > flamewar with no immediate action, and then to dredge up the topic a > month later and vote, and then have another 100-post flameware to talk > about the outcome. I don't think we need off-the-cuff decisions, but > if a topic is ripe for a decision we should have a way to actually > take care of it. > > Public debate and votes only make sense. Bugs might be a useful way > to record this (much as is done with the trustees). > > Rich > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR7bOzAAoJEKXdFCfdEflK82cQAK+f6sdWek9P2b23JYWb8Xm9 HzH+rc+NrfvbLo6pwINdzuVkNQnvIWwKZbyl9/03kuZeB3PytvVFLMAEk9pMlRnk rBVvcpuYU8m4OHWWQBPRyNw7qKlGW15AkVZ1+syCaBQiVyj6atniKUf3xV97IKVe GE9frmWp3mQeeDbFu78+PrKBs6jIPf7D6QJNSjPYrntK+vg90G53zqXOvOvFUPji StldpXAfRK4GTsdDChf8HPOtMB3IsFvnLuO91U16AQqgb5ydw4AlCT+0WEeZCoUR fgXe5QdvMEoWiFsVB17fE2foyFVGHnq72/oXJwvued2D47D+1SQxmo1fYb+OOwbi KgSFIWK3DYgC1QbH8l96QRxFfEPbiwO19ATJT2ed5ak8E7a829FQOBcOOCZZ8FeT qbqaPVwfWpKh2xjYXBhczsOZyPjYSL3UMH276HjujUPsFJGoTgiQjhLYdZ4ofkL3 bsmC3ZxufLesl3cPSxCkJ58WQeSK/jF4kGxUvj5FaD2GkHs03z3/2nHQ82jUgb4s flfkaQICLFljt65574zNNLCh2UQVvvIf0UKNjiq1BoIZVg4cuzjUYVlmTJ6fXXDA qiHffsusKdD9rToBYGCdQuO9RfZCUj9kAlVqvX92U27jn+vyb59ImnteeGML1wNs SoNwdjL8XHhxPyf+SJKP =7jYm -END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass and bug 475502
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/17/2013 05:47 PM, hasufell wrote: > On 07/17/2013 11:42 PM, Rick "Zero_Chaos" Farina wrote: >> On 07/17/2013 05:34 PM, hasufell wrote: >>> On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote: >>>> On 07/17/2013 05:17 PM, Chris Reffett wrote: >>>>> On 07/17/2013 04:57 PM, hasufell wrote: >>>>>> I know there was an announcement about the upcoming change >>>>>> to cmake-utils.eclass, however... it is not enough to give >>>>>> a deadline without caring if people actually fixed it by >>>>>> then. > >>>>>> By doing that you risk breaking stable packages which is >>>>>> not trivial. > >>>>>> You _must_ do a tinderbox run, test that stuff in an >>>>>> overlay or whatever. You are responsible for ALL reverse >>>>>> deps. > >>>>>> The way it was done... was not appropriate. Please be more >>>>>> careful next time. There are still incoming bugs about >>>>>> broken base_src_* calls. (see the tracker) > > >>>>> I discussed this with hasufell on IRC, but I'll lay out the >>>>> response on the list too. Yes, this was my fault. We (KDE >>>>> team) tested in our overlay, but none of the packages there >>>>> use the base_src_* calls, which is why it didn't come up in >>>>> testing, and I did not realize that there were packages that >>>>> did rely on the implicit base inherit to call base_src_* >>>>> directly. > >>>> ...and that is why it isn't permitted to directly use an >>>> eclass that you don't inherit. While I agree testing could >>>> (should) have been better, the fact that people ignore the >>>> rules for writing ebuilds shouldn't entirely fall on the KDE >>>> team. > > >> Considering this is a QA violation, perhaps it is possible to add a >> check in repoman for using something from an eclass which you >> didn't inherit. I doubt the slowdown would be horrible and clearly >> it would catch a huge number of QA violations. > > > That will yield false positives. Some eclases are explicitly designed > in a way that you do NOT need to directly inherit it's helpers such as > python-r1 and python-utils-r1. > > It is my understanding that if you directly use a function from an eclass you are REQUIRED to inherit that eclass. Given that kind of sanity would have prevented these failures I find it difficult to believe my understanding is wrong, but I am willing to learn. I think I'll start inheriting base.eclass so I can use multilib functions. I mean, base.eclass inherits eutils.eclass which inherits multilib.eclass so it should work out fine, right? - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5xLGAAoJEKXdFCfdEflKe/sP/jo7mFijN9jzpbK4/4IAigR/ CuF+gyMh6r8fxDRCKBZ02T04hMhM6XDbafNKGaDstXbLLI6o6xAgGLboeZxo6tj+ GFD+u4gqjN4EWRGeuHS+bzJErEBEt1XpMecaPHyNs6CZF+/XTL6zOZOsKWYAELzO 1mlTLp5dn4XCbtC8llsgey1sxq42kuN93JWRqODVPlU5lwZD7cbTpgVV6nQrz36n NeS0FfjIs/UN8/Rix0xaC4frEG86Zv+ES1R/HB6UqDhx+P1hdRpBGVTNF6eLOMvV JJA735pWeN6xgcdrcOrCIGVQTfptaD+tlYfSjL1aeN/Bw1LemyChwsCHd5PE8sgv z63zTiMvR4Mm12KG8xYtm2ygTSdrjCvZz5/ZaX6wnJuCAALGs6Z2dTa27YQBBtlD z4UXXG1fWImcYL1J26rMzapzSzQeXPYThedpCSRIiIs876RQhuE/M7/ZACNveTAR I5QwxY9ZOtol9+ucvRn+8BqS24pRw0DwlWEUTYOWxHcgcMHFw3EzH0Zy0AUYj7yc JrawQlWrhtSYSzScEpEvwlbU+zvZbWi/BXo+K8gUGq+hqseq2vLcfAyTzUA/lyYS oBeAlJVBxFBKsO/64byItWY0la5E4w8T6qy+sgFvlnoFG3rO+/jWSfiEhDOSffCS BLycpk3pzcBSOmTBnJrf =Xgsq -END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass and bug 475502
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/17/2013 05:34 PM, hasufell wrote: > On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote: >> On 07/17/2013 05:17 PM, Chris Reffett wrote: >>> On 07/17/2013 04:57 PM, hasufell wrote: >>>> I know there was an announcement about the upcoming change to >>>> cmake-utils.eclass, however... it is not enough to give a >>>> deadline without caring if people actually fixed it by then. > >>>> By doing that you risk breaking stable packages which is not >>>> trivial. > >>>> You _must_ do a tinderbox run, test that stuff in an overlay or >>>> whatever. You are responsible for ALL reverse deps. > >>>> The way it was done... was not appropriate. Please be more >>>> careful next time. There are still incoming bugs about broken >>>> base_src_* calls. (see the tracker) > > >>> I discussed this with hasufell on IRC, but I'll lay out the >>> response on the list too. Yes, this was my fault. We (KDE team) >>> tested in our overlay, but none of the packages there use the >>> base_src_* calls, which is why it didn't come up in testing, and >>> I did not realize that there were packages that did rely on the >>> implicit base inherit to call base_src_* directly. > >> ...and that is why it isn't permitted to directly use an eclass >> that you don't inherit. While I agree testing could (should) have >> been better, the fact that people ignore the rules for writing >> ebuilds shouldn't entirely fall on the KDE team. > > > It doesn't matter in the slightest whos fault it is or who should be > blamed. > > It is about maintaining stability for the user. Especially when it > comes to stable ebuilds. > > That means the methods for eclass changes must be more thoroughly. > I completely agree with you, the changes should have been tested better. The ebuilds with these errors popping up ALSO should have been tested better. Considering this is a QA violation, perhaps it is possible to add a check in repoman for using something from an eclass which you didn't inherit. I doubt the slowdown would be horrible and clearly it would catch a huge number of QA violations. I'm not saying this isn't bad, I'm not saying KDE team didn't mess up, I'm saying a lot of people messed up and the not well enough tested eclass change found a lot of QA violations which should have been caught much earlier. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5w/IAAoJEKXdFCfdEflKUQ4P/24f/wkmQHCFskq2P+b8xgpY PpRkE4XV/AV4oYRFWJ0HNmPcx1gqNVHdjED8yhQ8JqEPFJbgMWRMa1vfkY84Qkqb b4CIDcmCd1A9jkdFtP6llgCSP/ub0cokB9O1Cb5kAZrDy+VzctB81x6X2uuUF53N dcoVEga4gqZf5W4RBBE5R7yneB92K5bZjulQsPG22pAfWmKCoVUoaPOh4c104mXt r+qMboTdHhfNldYdTykKQy5wSMERpKxzPBw9sG3ON96qajSD9nnmVzCVmWZrixfG WJWf2G5RhLoIjjGPR0d9wUp5w212W7E6OVIpbeye5nX/YpePEYL4YAboAPbBs9Ws XRWJOpy+/+W4Wr7J+pic41S96w2r31kBoXRpR6+Qrn+JZAaWbRBMadqVhHnYJx+w cxOFhpKnJRF7l0t76wRevUMoD4aMRi3ZqEjH6SdqIJ9QHq40k6fITrmahq5k8Y24 TZOsGVpGi1XhrjrSfNXnVy9Dstjf5D6W39nzYQI+AaXURynV276fb/BPABHdoRuR 4eITAA6vIQ6rxoTAsOjmy+w2ySOzJkEVK0WrrcaJJAxhu1+ztjmcaq9d5kO7mdIt 5iyEcgNielhrf7wkpe+yM0SwhE5h1/+znhMRgxMAwuktWxK43KMBV39G28b9XMb6 LjG8NvQO4K4LGeNOhWAA =elf2 -END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass and bug 475502
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/17/2013 05:17 PM, Chris Reffett wrote: > On 07/17/2013 04:57 PM, hasufell wrote: >> I know there was an announcement about the upcoming change to >> cmake-utils.eclass, however... it is not enough to give a deadline >> without caring if people actually fixed it by then. > >> By doing that you risk breaking stable packages which is not >> trivial. > >> You _must_ do a tinderbox run, test that stuff in an overlay or >> whatever. You are responsible for ALL reverse deps. > >> The way it was done... was not appropriate. Please be more careful >> next time. There are still incoming bugs about broken base_src_* >> calls. (see the tracker) > > > I discussed this with hasufell on IRC, but I'll lay out the response > on the list too. Yes, this was my fault. We (KDE team) tested in our > overlay, but none of the packages there use the base_src_* calls, > which is why it didn't come up in testing, and I did not realize that > there were packages that did rely on the implicit base inherit to call > base_src_* directly. ...and that is why it isn't permitted to directly use an eclass that you don't inherit. While I agree testing could (should) have been better, the fact that people ignore the rules for writing ebuilds shouldn't entirely fall on the KDE team. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5wyLAAoJEKXdFCfdEflK0LsP/3nXF+sRXcrRBmkysF7mLGjP 7iJ9Wwh2VkJyPihYxvG1O7YQkoMr+ohiQvMg6a0SbK6CPzND6Wu2d80r9/5DUUOx NUqvtbX+SdNIj/VgoYC4aDuS6ln+3BDENR5JT90jfs1v7HNh1G/bSA78ppj1cDS7 Hsnym7pQxRYLnQuDbitVeFKp2UHBchXAkoaW8QJ/pf4FQwiXX0JXmOdt+ogCICGC W6YP4fbt4zv4zKpt3AFD9jKXle4wcCoAXjixOIfdWSURy+BFWGDJXOKuPsqaXFki U4qlbOI6xrf7l5ApmjZOndfarqGiwSfxV3qOLKglyHQp3I63FXfAqiVvH6uz8g2L YVXqZ7BrkZKMADfR+Ha8nHbyW0CX0Z4iK62P/BPH4aLfLPzJKZa6804++a2i7Vx/ 0EfB4rSSYC6IAMWhSxCJD5SL0q1MBefNAGFttVO5gGMUbyoIZ2YGd4fNW6bLFffu Ca3twnU5yvvjn9auofWsh6Mji6U76L4xcVN/SUSI4ASC1q0GtPs6BbHI+WY4mo40 lYJUe3wXK3LgUfdDcrw9LennsO71lE96OuM1dhwxqrnIexAyKKIBMQtzIzYekBJx Q3D6s3sCtxgOOhbDpWFp1rEohmHLY6SJzbMW9+BbN6+rEqZw0o11DYivOfiwSwso wgRZQ55XSKzpZVPdifhp =q7zW -END PGP SIGNATURE-
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2013 10:03 PM, Robin H. Johnson wrote: > On Fri, Jul 05, 2013 at 09:27:46PM -0700, Brian Dolbec wrote: >> The other thing we needed to do was completely remove the use of >> or building of binpkgs during the update_seed stage. Portage has >> no capability to check binpkg linking to ensure the binpkg was >> properly usable. > Can somebody actually please implement this, to run before the > binpkg merge phase? > Please be more specific, this is currently implemented... - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR3ihMAAoJEKXdFCfdEflKH4sP/1dswIQytHVOXtI6mqzntqjy 9rBl2tkBft2gdQp7Vru3d4s0HiicpeLImSyvIM8H2FVmbEVutMwOOUWp2tllOUNh bb98BnrAoSMz4GEPtcS2d0vmZ3HdDj99mrnkOOWcqvHRPMn/J0KogAyrCVRa0+Pb bNEo2dU5g4Jegs8gl4l1ilH0hIyb7uqurwjd5G8NayJIs0U5gIpTHZzPvRJo0B98 tnzEsoSTY0JekgSGC+8xgR4ijmR0AicF5nCciKUjFf7OjEDitK6sF6g3m92zM8hU fjPLTW0vjR63KbtOJNgw992DpQoUfRj2jYn4ErjDB1jKz5+xvLy0+rpwZPYA4hgf QNck4OnLRqK6rMy45Tzu58gfUsH1GIdmdH0JJ0x2rBLu89GHB4HSR+UlE5ugxmvj uzs2ZJ8MPIT7mYnrqJ8XbiMzDmkvspkixbi6YpbiNCi76R08ljNXFjT0Ju5nI29u W+6p/we4FMPLo47W5zSAS4Csa0reIayaIpJTbeyfHVe88DcS6jO+JAs416mod9ec 1SYogk+SFrmFC0PyW9uQeP0gE12U20bw0NCI0R5+PmXIs54jrowIJgjB8hPH8Cpz df7+ZNGuDaOqQnJT5j1EwzfAPEGVHmHtIaMu3bRMv0EJZj3WMa1rABtFFX+65S1x dz87xG1hys5ZZmz8IzOQ =+Lzs -END PGP SIGNATURE-
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2013 03:08 AM, Matt Turner wrote: > On Fri, Jul 5, 2013 at 7:18 PM, Rick "Zero_Chaos" Farina > wrote: >> When we then move onto stage 2, it uses just the packages built during >> stage1 (/tmp/stage1root becomes /). This means, if seed stage has >> mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in >> stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed. >> >> To combat this kind of failure we are currently running "emerge --update >> - --deep --newuse --complete-graph --rebuild-if-new-ver gcc" which could >> just be "emerge --update gcc" if eapi 5 subslots were used properly. > > The best solution to this is, and has always been, just updating gcc's > deps during update_seed. Or am I misremembering something? You are misremembering that we are using preserve_libs to save our butts when mpc is updated and gcc is still linked to the old mpc. I feel very uncomfortable as the recommendation of preserve-libs is to remerge as soon as possible not "build a whole system like this". Is there an actual failure here? Not that I've seen yet, but it's an awkward way to build in my opinion. - -Zero > > As far as I know, you don't need to waste time rebuilding the seed > stage's gcc, since gcc is rebuilt in stage2 and then everything is > built by it in stage3. > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR2DeYAAoJEKXdFCfdEflKDwwP/1Pr2eB9GjSKncEabiB9WkEb eziSaccKcsmjdXq9Svg0dfTM9m9rgroK0iM15IWLHhbAoU/5beVPv4bOYVYejYkP NBMWp2+MoIE7VRhziFToj7tHxTnXsUg1l3dMFWECewWpMewo9lZw1eYTn/iaUGaI tkfNi7iQV9PvfknUgtQZ8lfgSUjUz2CdtjCyjaoMpO+vls+gVvH74vGETIMMrHWr CN7iMfx7F6FGpc1+FxZ0CJ1zKSifY/1R+dLABass8xaLRMPNqTIpm8b37xD2tHOA f2pfzCIgkwLEo8moJrmkl21CqC2CjqZ0HPqd3dd/wSTg2x1ccslNHVOUf8+mZu1I 4zwJUwS7e2w8rxcq/UTu9x3J18D2doFjLg1mLUtWgmptn9Tydr/GYL+yYJei0yK+ MiADpdK+UI5frUo1B8bZ+Gs0N5IIh2pcGkjdupz4HXRAeD+2VN5G0HBpTZ8I4vNI rK9wRQN1iyxb4sn0Wr0n+GwSlxyTao6yuUSJwT5nfD1k9gSGI9Zh7tERlD/D9ceN Vfvv0No+ikh47TDjm3hSmz2fdbTT5vxKecnXT72EpYQwIZFoVMo7tnRVwxd4gBbM Fx4LDUaSn3ommMBZF/jRt5zsn+cGMB/7qHkNo1DPIbKgXgExEQWRz7Lxhy8Hm4er YYVhPl4Zhc0/BCBwBpK/ =zakW -END PGP SIGNATURE-
