Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 05/23/2012 07:54 AM, Johannes Huber wrote: > Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: > Hi, > > i've looked at the blockers of "[TRACKER] portage migration to git" > [1] and want to discuss "testing git-cvsserver" [2]. > > There are two proposed scenarios how to migrate the developers write > access to the portage tree. > > "Clean cut" turns of cvs access on a given and announced timestamp, > rsync-generation/updates is suspended (no input -> no changes), some > magic scripts prepare the git repo (according to [3], some hours > duration) and we all checkout the tree (might be some funny massive load). > > "testing git-cvsserver" proses "Clean cut" with the additional ability > to continue using cvs update/commit, - in best case - on the old > checkout w/o alteration on the developers side. > > "Clean cut" forces us to clean up out dirty checkouts (I have some > added directories, added ebuilds i hesitated to `repoman commit`). > Plus we have to alter all our hot-wired portage mangling scripts from > cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs > checkout + egencache for checkout) and have an automated google-chrome > bump script). But this can be accomplished on a per developer basis, > and slackers don't stall the process. > > "testing git-cvsserver" forces us all to test these cvs'ish scripts > and behaviours against a git-cvsserver and report. > We all know that this test-runs will never happen, stalling this bug > till infinity. > Plus infra/"subset of devs marshalling the migration" get stuck > between fixing git issues and git-cvsserver. > > *if you still read this* *wow* > > Please discuss my arguments and come to the conclusions to > RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove > this bug from the blockers of "[TRACKER] portage migration to git". > > My lengthy 2 cents. > > [1] https://bugs.gentoo.org/333531 > [2] https://bugs.gentoo.org/333699 > [3] https://bugs.gentoo.org/333705#c2 > > I support RESOLUTION WONTFIX, if nobody cares about the bug since it was > opened it is obvious out of interest. There is no reason to support jurassic > software. > > Clean cut++ > > Cheers clean-cut++ -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing
On 06/04/2012 07:34 AM, Rich Freeman wrote: > On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman wrote: >> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel >> wrote: >>> However, then the "committer" of the contributed commits before the merge is >>> then the user, I guess? >>> >>> (The rule meaning as suggested by Robin >>>> - if you include a commit from a user: >>>> author := non-@gentoo >>>> committer := @gentoo >>>> signer := $committer >> >> I guess, I'm not sure how the committer thing works in git. >> > > Well, only Robin can explain exactly what he meant, but it sounds like > we don't want the committer field to ever have a non-gentoo email in > it, and signatures should be gentoo as well. So, if a dev just > applies a patch to their tree/etc then there is no issue (just set > author). If a dev wants to actually pull in a commit they'd need to > edit the fields accordingly and re-sign it. Not sure offhand how to > best do that (I assume it is possible - probably with some variation > on rebase or something rebase calls). > > I don't think the intent is to snub non-devs. The issue is what is > the purpose of the signatures and committers field in the first place. > The signature verifies that the commit is intact, and you can only do > that if you have a key to check it with, and you can trust that key. > If the signer is a dev then we already have policy that the keys need > to be published, and we have a list of key IDs on our website. I'm > sure that could be improved on. If we stick non-dev signatures in the > tree then that becomes more of a problem (though it clearly is > possible - maybe something to think about). I assume the committer > denotes a layer of accountability, and having a dev in that spot makes > sense (devs who are proxies are accountable for oversight at some > level - though I'd personally give them the benefit of the doubt since > we want to encourage the proxy role). > > I think the key with git is to not let the perfect be the enemy of the > good. We don't have an unbroken signature chain on our current > portage tree, so I don't think we need one to move to git. As long as > git is at least as good as what we have now, then we should accept it. > We should of course strive to improve, but let's not keep the almost > completely unsigned cvs around for another 10 years while we argue > about signatures. > > Rich > I think the intent is to only have commits and signoffs come from @gentoo, but we need a way to give attribution to users who send stuff in that gets committed. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 12:24 AM, Arun Raghavan wrote: > On 15 June 2012 10:26, Greg KH wrote: >> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: >>> On 15 June 2012 09:58, Greg KH wrote: >>>> So, anyone been thinking about this? I have, and it's not pretty. >>>> >>>> Should I worry about this and how it affects Gentoo, or not worry about >>>> Gentoo right now and just focus on the other issues? >>> >>> I think it at least makes sense to talk about it, and work out what we >>> can and cannot do. >>> >>> I guess we're in an especially bad position since everybody builds >>> their own bootloader. Is there /any/ viable solution that allows >>> people to continue doing this short of distributing a first-stage >>> bootloader blob? >> >> Distributing a first-stage bootloader blob, that is signed by Microsoft, >> or someone, seems to be the only way to easily handle this. >> >> Although all BIOSes will have the option to turn secure boot off, I >> think it is something that we might not want to require for Gentoo to >> work properly on those machines. >> >> Also, some people might really want to sign their own bootloader and >> kernel, and kernel modules (myself included), so just getting that basic >> infrastructure in place is going to take some work, no matter who ends >> up signing the first-stage bootloader blob. > > I hadn't thought of that. I imagine the hardened team might be > interested in making such infrastructure easily available as well. > >> Oh, and on the first-stage bootloader front, I already know of 2 simple, >> and open source, examples that will work for Linux, so getting something >> like that signed might not be very tough. It's the "where does the >> chain-of-trust stop" question that gets tricky... > > For validating the chain of trust, it might be useful to make it > possible for anyone to generate the same bootloader and verify the > hashes themselves. For the truly paranoid maybe a signed stage3 + > portage snapshot to generate the bootloader image from scratch. > >>>> Minor details like, "do we have a 'company' that can pay Microsoft to >>>> sign our bootloader?" is one aspect from the non-technical side that I've >>>> been wondering about. >>> >>> Sounds like something the Gentoo Foundation could do. >> >> Can they do that? I haven't been paying attention to if we are really a >> legal entity still or not, sorry. > > I believe so, but quantumsummers is likely the best person to confirm. > I've already taken a look at some of this, I think our best bet is to figure out how to use efi_stub and simply sign the kernel itself (since it can run directly from uefi now). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/14/2012 11:45 PM, Greg KH wrote: > On Thu, Jun 14, 2012 at 09:28:10PM -0700, Greg KH wrote: >> So, anyone been thinking about this? I have, and it's not pretty. >> >> Should I worry about this and how it affects Gentoo, or not worry about >> Gentoo right now and just focus on the other issues? >> >> Minor details like, "do we have a 'company' that can pay Microsoft to >> sign our bootloader?" is one aspect from the non-technical side that I've >> been wondering about. > > Oh, and for those that don't know, I did a lot of UEFI secure boot work > in the past at SUSE, and should be soon a member of the UEFI > "organization" through my work at the Linux Foundation, so I do have a > basic grasp of the issues involved, and have a chance to get changes > made, if needed, and possible, to the spec itself. > > greg k-h > One of these days I'd like to pick your brain about some hardened UEFI interactions I've seen (with pipacs watching). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] sys-auth/nss-ldapd is looking for a maintainer
On 07/14/2012 02:49 PM, Doug Goldstein wrote: > sys-auth/nss-ldapd is looking for a maintainer. This is the > "preferred" NSS LDAP by RHEL6. I just haven't been using it and > haven't been keeping up with releases. I'm only aware of two bugs: > > https://bugs.gentoo.org/show_bug.cgi?id=287727 > https://bugs.gentoo.org/show_bug.cgi?id=234555 > > One is asking for a bump and one is asking for some USE flag fixes. > I'll take it, starting with the bump and hopefully getting upstream to accept a --enabled/disable for kerberos. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] sys-auth/nss-ldapd is looking for a maintainer
On 07/14/2012 09:17 PM, Doug Goldstein wrote: > On Sat, Jul 14, 2012 at 6:25 PM, Matthew Thode > wrote: >> On 07/14/2012 02:49 PM, Doug Goldstein wrote: >>> sys-auth/nss-ldapd is looking for a maintainer. This is the >>> "preferred" NSS LDAP by RHEL6. I just haven't been using it and >>> haven't been keeping up with releases. I'm only aware of two bugs: >>> >>> https://bugs.gentoo.org/show_bug.cgi?id=287727 >>> https://bugs.gentoo.org/show_bug.cgi?id=234555 >>> >>> One is asking for a bump and one is asking for some USE flag fixes. >>> >> I'll take it, starting with the bump and hopefully getting upstream to >> accept a --enabled/disable for kerberos. >> > > Thanks a bunch Matt. > also getting proper selinux support for it :D -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
On 08/28/2012 10:35 AM, Sylvain Alain wrote: > Hi everyone, I don't want to start a flamewar on that subject, but I would > like to know if there's any official position about the current situation. > > I saw on the forum this thread : > https://forums.gentoo.org/viewtopic-t-934678-highlight-.html and maybe it > could be part of a solution to have OpenRC and udev together. > > So, is there any developments lately ? > > Thanks ! > > d2_racing > Maybe something to get at least some general direction from council, though probably too technical. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] spotify license
It's looking hard to be able to add the spotify ebuild to tree because of licensing concerns. http://www.spotify.com/us/legal/end-user-agreement/ 10:02 < prometheanfire > do you have a plaintext version? I can copy the text, but just thought I'd ask :D 10:02 < dan^spotify > No, and copy+pasting it into a text file isn't something we really want you to to do, since it changes from time-to-time 10:04 < prometheanfire > ok, I'll see what the proper course of action is, I think you have us accept the license on first start right? 10:04 < dan^spotify > Correct 10:04 < dan^spotify > Well, first login 10:05 < prometheanfire > just as good probably 10:05 < dan^spotify > If you've already accepted the most up-to-date license on another machine, you won't be prompted again https://bugs.gentoo.org/show_bug.cgi?id=373093 They want it to be accepted through the app. Is there a way this is compatible with Gentoo? Any advice would be appreciated. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: spotify license
On 10/29/2012 09:52 AM, Ulrich Mueller wrote:
>>>>>> On Mon, 29 Oct 2012, Matthew Thode wrote:
>
>> It's looking hard to be able to add the spotify ebuild to tree because
>> of licensing concerns.
>
>> http://www.spotify.com/us/legal/end-user-agreement/
>
> This concerns not so much the client software, but their "service" and
> the contents provided through it.
>
>> 10:02 < prometheanfire > do you have a plaintext version? I can copy
>> the text, but just thought I'd ask :D
>> 10:02 < dan^spotify > No, and copy+pasting it into a text file isn't
>> something we really want you to to do, since it changes from time-to-time
>> 10:04 < prometheanfire > ok, I'll see what the proper course of action
>> is, I think you have us accept the license on first start right?
>> 10:04 < dan^spotify > Correct
>> 10:04 < dan^spotify > Well, first login
>> 10:05 < prometheanfire > just as good probably
>> 10:05 < dan^spotify > If you've already accepted the most up-to-date
>> license on another machine, you won't be prompted again
>
>> https://bugs.gentoo.org/show_bug.cgi?id=373093
>
>> They want it to be accepted through the app. Is there a way this is
>> compatible with Gentoo?
>
> We need a plaintext license file for the client that we put in
> ${PORTDIR}licenses/, so users can look at it before they install the
> package.
>
>> Any advice would be appreciated.
>
> Maybe it would make more sense to add one of the free alternatives?
>
>http://despotify.se/
>https://gitorious.org/libopenspotify
>
> media-sound/despotify is already in Sunrise, bug 307795.
>
> Ulrich
>
This makes me think that it covers the client as well. They did say
that if we tried to keep this up to date that would be good enough.
Third party software libraries included in the Spotify Service are
licensed to you either under these Terms, or under the relevant third
party software library’s licence terms as published in the help or
settings section of our desktop and mobile client and on our website.
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: spotify license
On 10/29/2012 03:32 PM, Matija Šuklje wrote:
> On Ponedeljek 29. of October 2012 15.52.20 Ulrich Mueller wrote:
>>>>>>> On Mon, 29 Oct 2012, Matthew Thode wrote:
>>> It's looking hard to be able to add the spotify ebuild to tree because
>>> of licensing concerns.
>>>
>>> http://www.spotify.com/us/legal/end-user-agreement/
>>
>> This concerns not so much the client software, but their "service" and
>> the contents provided through it.
>
> Well, the “Spotify Software” is included at least it §4 and also in general
> included in the “service” term. The license agreement is lacking though.
>
> In any case Gentoo can’t be the 3rd party here and therefore not redistribute
> it.
>
>>> 10:02 < prometheanfire > do you have a plaintext version? I can copy
>>> the text, but just thought I'd ask :D
>>> 10:02 < dan^spotify > No, and copy+pasting it into a text file isn't
>>> something we really want you to to do, since it changes from time-to-time
>>> 10:04 < prometheanfire > ok, I'll see what the proper course of action
>>> is, I think you have us accept the license on first start right?
>>> 10:04 < dan^spotify > Correct
>>> 10:04 < dan^spotify > Well, first login
>>> 10:05 < prometheanfire > just as good probably
>>> 10:05 < dan^spotify > If you've already accepted the most up-to-date
>>> license on another machine, you won't be prompted again
>>>
>>> https://bugs.gentoo.org/show_bug.cgi?id=373093
>>>
>>> They want it to be accepted through the app. Is there a way this is
>>> compatible with Gentoo?
>>
>> We need a plaintext license file for the client that we put in
>> ${PORTDIR}licenses/, so users can look at it before they install the
>> package.
>
> Yup.
>
> They probably deem §§ 3 and 4 to be the license, but it’s quite lacking IMHO.
> So since full copyright is default, this means that we’re not allowed to
> redistribute it. RESTRICT="mirror" we have to do here.
>
> As a sub-optimal solution, Rich’s idea to create a Spotify license and point
> the users to the actual EULA.
>
> But unless they clarify the software license for their *client*, I’d rather
> we
> don’t include it. Too messy.
>
>> Maybe it would make more sense to add one of the free alternatives?
>>
>>http://despotify.se/
>>https://gitorious.org/libopenspotify
>>
>> media-sound/despotify is already in Sunrise, bug 307795.
>
> Seems a better idea IMHO.
>
>
> cheers,
> Matija
>
> P.S. As Rich mentioned, the difference between a (real) license and “license
> agreement” is that a license grants you more rights then you get by law and
> therefore you don’t have to agree to it, since your rights are not
> diminished;
> a so called license agreement (EULA, ToS, whatever_agreement) has nothing to
> do with a (real) license apart from the falsely borrowed name and you have to
> agree with it, since your statutory rights are diminished/voided.
>
Ya, I've asked for clarification there, unless we get something more
explicit it stays out of tree.
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: spotify license
On 10/29/2012 03:32 PM, Matija Šuklje wrote:
> On Ponedeljek 29. of October 2012 15.52.20 Ulrich Mueller wrote:
>>>>>>> On Mon, 29 Oct 2012, Matthew Thode wrote:
>>> It's looking hard to be able to add the spotify ebuild to tree because
>>> of licensing concerns.
>>>
>>> http://www.spotify.com/us/legal/end-user-agreement/
>>
>> This concerns not so much the client software, but their "service" and
>> the contents provided through it.
>
> Well, the “Spotify Software” is included at least it §4 and also in general
> included in the “service” term. The license agreement is lacking though.
>
> In any case Gentoo can’t be the 3rd party here and therefore not redistribute
> it.
>
>>> 10:02 < prometheanfire > do you have a plaintext version? I can copy
>>> the text, but just thought I'd ask :D
>>> 10:02 < dan^spotify > No, and copy+pasting it into a text file isn't
>>> something we really want you to to do, since it changes from time-to-time
>>> 10:04 < prometheanfire > ok, I'll see what the proper course of action
>>> is, I think you have us accept the license on first start right?
>>> 10:04 < dan^spotify > Correct
>>> 10:04 < dan^spotify > Well, first login
>>> 10:05 < prometheanfire > just as good probably
>>> 10:05 < dan^spotify > If you've already accepted the most up-to-date
>>> license on another machine, you won't be prompted again
>>>
>>> https://bugs.gentoo.org/show_bug.cgi?id=373093
>>>
>>> They want it to be accepted through the app. Is there a way this is
>>> compatible with Gentoo?
>>
>> We need a plaintext license file for the client that we put in
>> ${PORTDIR}licenses/, so users can look at it before they install the
>> package.
>
> Yup.
>
> They probably deem §§ 3 and 4 to be the license, but it’s quite lacking IMHO.
> So since full copyright is default, this means that we’re not allowed to
> redistribute it. RESTRICT="mirror" we have to do here.
>
> As a sub-optimal solution, Rich’s idea to create a Spotify license and point
> the users to the actual EULA.
>
> But unless they clarify the software license for their *client*, I’d rather
> we
> don’t include it. Too messy.
>
>> Maybe it would make more sense to add one of the free alternatives?
>>
>>http://despotify.se/
>>https://gitorious.org/libopenspotify
>>
>> media-sound/despotify is already in Sunrise, bug 307795.
>
> Seems a better idea IMHO.
>
>
> cheers,
> Matija
>
> P.S. As Rich mentioned, the difference between a (real) license and “license
> agreement” is that a license grants you more rights then you get by law and
> therefore you don’t have to agree to it, since your rights are not
> diminished;
> a so called license agreement (EULA, ToS, whatever_agreement) has nothing to
> do with a (real) license apart from the falsely borrowed name and you have to
> agree with it, since your statutory rights are diminished/voided.
>
Got confirmation via irc that the license is for the client as well,
dunno if that's good enough...
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] spotify license
On 10/29/2012 09:17 AM, Matthew Thode wrote: > It's looking hard to be able to add the spotify ebuild to tree because > of licensing concerns. > > http://www.spotify.com/us/legal/end-user-agreement/ > > 10:02 < prometheanfire > do you have a plaintext version? I can copy > the text, but just thought I'd ask :D > 10:02 < dan^spotify > No, and copy+pasting it into a text file isn't > something we really want you to to do, since it changes from time-to-time > 10:04 < prometheanfire > ok, I'll see what the proper course of action > is, I think you have us accept the license on first start right? > 10:04 < dan^spotify > Correct > 10:04 < dan^spotify > Well, first login > 10:05 < prometheanfire > just as good probably > 10:05 < dan^spotify > If you've already accepted the most up-to-date > license on another machine, you won't be prompted again > > https://bugs.gentoo.org/show_bug.cgi?id=373093 > > They want it to be accepted through the app. Is there a way this is > compatible with Gentoo? > > Any advice would be appreciated. > One option that's been presented to me is to add restrict mirror (I don't think restricting fetch is needed, but meh what do I know). That sound acceptable? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] spotify license
On 11/06/2012 12:32 PM, Rich Freeman wrote: > On Tue, Nov 6, 2012 at 1:08 PM, Matthew Thode > wrote: >> One option that's been presented to me is to add restrict mirror (I >> don't think restricting fetch is needed, but meh what do I know). That >> sound acceptable? > > The last time I looked at the ebuild that was already done. We have > no other choice unless there is a clear statement that free(TM) > redistribution is permissible, and I don't see that in the > "agreement." > > As to what the license is, I'd probably just point people to it and > tell them they're on their own. We wash our hands and have no part of > it - hence no mirroring. Gentoo is not bound by agreements we are not > a party to. > > Rich > So you think we need to restrict fetch so we can let the user know about the licensing thing? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-office/lyx: lyx-2.0.5.ebuild ChangeLog
On 11/22/2012 10:45 PM, Patrick Lauer wrote: > On 11/20/12 21:57, Alexis Ballier wrote: >> On Fri, 16 Nov 2012 09:10:51 + (UTC) >> "Patrick Lauer (patrick)" wrote: >> >>> patrick 12/11/16 09:10:51 >>> >>> Modified: ChangeLog >>> Added:lyx-2.0.5.ebuild >>> Log: >>> Bump >>> >> >> >> >> While the bump was fine, please read the damn metadata.xml when you >> touch a package you're not used to. Pavel has been doing a very good >> job in (proxy) maintaining lyx since years and you do not seem to have >> contacted him before doing the bump, which is a bit disrespectful for >> him IMHO. > > I disagree. A fix is a fix, a bump is a bump, no ego involved. > >> If you want to help in having things done quicker because I'm not >> always responsive enough, then please do it correctly and ask Pavel to >> CC you when he sends me instructions for lyx. > I dislike this territorialism. Why add a single point of failure to > package maintenance? (What if you or Pavel "disappear" for any reason?) > > Have fun, > > Patrick > > Generally I think contacting the maintainer is nice, I typically set a timeout (depending on severity) so that if they don't respond you do what is needed. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] New global use-flag [pax_kernel]
pax_kernel is used by 21 packages. The description would generally be 'make changes to the package so it works under a pax enabled kernel'. Currently it is used to either patch or (inclusive) to pax mark. What think you? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New global use-flag [pax_kernel]
On 11/25/2012 07:02 PM, Alec Warner wrote: > On Sun, Nov 25, 2012 at 3:57 PM, Matthew Thode > wrote: >> pax_kernel is used by 21 packages. The description would generally be >> 'make changes to the package so it works under a pax enabled kernel'. >> Currently it is used to either patch or (inclusive) to pax mark. >> >> What think you? > > This seems more like a profile mixin flag than a normal flagis it > set in the hardened profile already? > > -A > it is defined here, but if you use a pax kernel (you don't have to use the hardened profile, though you probably should) you should probably set this flag. /usr/portage/profiles/hardened/linux/make.defaults >> >> -- >> -- Matthew Thode (prometheanfire) >> > -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On 11/28/2012 09:05 AM, Richard Yao wrote: > On 11/28/2012 09:17 AM, Maxim Kammerer wrote: >> On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao wrote: >>> We could slightly simplify the handbook installation procedure if we >>> told people to use emerge-webrsync to fetch the initial snapshot. >> >> Using emerge-webrsync also makes the installation process more robust, >> since it only requires HTTP access (whereas many firewalls restrict >> RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think >> that it should be the primary recommended portage tree synchronization >> method. >> > > The only downside of which I am aware is increased network traffic. > However, we could redesign emerge-webrsync to take advantage of GNU > Tar's incremental archive functionality. > > That would permit us to mirror compressed diffs in addition to regular > portage snapshots. Doing that well could reduce bandwidth requirements. > weekly fulls and daily diffs? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Introducing stable profiles for arm64 (aarch64)
On 02/03/2017 11:26 PM, Mart Raudsepp wrote: > Hello, > > I am working towards having a clean deptree for arm64 and afterwards > marking the non-hardened 5 arm64 profiles stable (or 4 - I don't see > value in the developer profile without the desktop specific > subprofiles, until there are mix-ins). > It's good to hear that I'll soon be able to get some of my packages stable on arm64, that'll encourage me even more to switch some of my smaller servers to it (for power/heat reasons). :D -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Printer drivers and net-print
On 02/20/2017 03:47 PM, Andreas K. Huettel wrote: > Hey all, > > 1) Putting printer drivers into "net-print" is silly. > > Something that converts format a to device-specific format b has absolutely > nothing to do with network. > So, a new category "sys-print", emphasizing that it's hardware drivers, (or > "cups-drv"?) (or maybe "media-print"?) might make sense. > > 2) After introducing that, however, "net-print" becomes nearly empty. > > On a quick glance, the only *network*-specific packages in there are cups and > lprng. Maybe one or two more which I dont recognize. > > So move cups and lprng to "net-misc" and drop "net-print"? > Or move them to new "sys-print" as well? > > What do you think? > > Cheers, > Andreas > Moving stuff around seems sort of like busy work. I can see the reasoning and as mjeveritt mentioned in the other email a full category rename may work just as well (instead of moving a couple of packages and also a rename). The question to me is 'is there a great enough need to go through the pain of this?'. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Openstack ocata available
First, Openstack Ocata is available as openstack-meta-2017.1. (installs the services from stable branches). Tags for each of the services are available if needed as well. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] packages up for grabs
My mentee has decided to not pursue Gentoo any more and as a result there is one package up for grabs. games-arcade/savagewheels -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Updating the puppet portage package provider
Currently puppet is fairly simple in how it handles portage packages. It doesn't handle package (un)install options, package sets or purging of packages. Also, iirc, uninstallation is fairly limited in what it can handle (can't handle uninstalling a slot iirc). The new version fixes these limitations. I'd appreciate review of the code and possible testing of this change by others using puppet. (and reviews by ruby devs). If people know of other lists to ask for review for this on let me know. https://github.com/puppetlabs/puppet/pull/5498/ -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 03/26/2017 02:50 PM, aide...@gentoo.org wrote: > Hi, > > The following packages are up for grabs: > > app-admin/hddtemp > app-backup/burp > app-crypt/md5deep > dev-python/appdirs > dev-python/husl > dev-python/pyro > dev-python/selectors34 > sys-apps/biosdevname > > These packages are quite easy to maintain, so if someone cares about any of > these, don't hesitate! (-: > > I will reassign to maintainer-needed if noone will take a package in > a while. > > Cheers, > -- Amadeusz Żołnowski > I took dev-python/appdirs as it's used by openstack somewhat. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] last rites: app-text/acroread
On 06/08/2017 07:17 PM, Jason A. Donenfeld wrote: > RIP acroread. > > The only PDF reader on linux that can properly parse PDF Reference XObjects. > > Thou shall be missed. > I'm not sure if it works, but qpdfview is the best alternative that I've found so far. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs
On 17-07-30 14:24:50, Daniel Campbell wrote: > On 07/23/2017 07:13 AM, Manuel Rüger wrote: > > The following packages are up for grabs: > > > > app-admin/gixy > > app-admin/mei-amt-check > > app-admin/ngxtop > > app-admin/passwordsafe > > app-arch/lz5 > > app-crypt/acme > > app-crypt/certbot > > app-crypt/certbot-apache > > app-crypt/certbot-nginx > > app-crypt/easy-rsa > > app-crypt/libmd > > app-crypt/manuale > > app-crypt/pgpdump > > app-emulation/docker-gc > > app-misc/jira-cli > > app-misc/pdfpc > > app-text/blahtexml > > app-text/itex2mml > > app-text/mathtex > > dev-go/cli > > dev-go/delve > > dev-go/go-gitlab-client > > dev-go/glide > > dev-go/toml > > dev-python/parsley > > dev-python/safety > > dev-python/txsocksx > > dev-python/vcversioner > > dev-libs/libgit2 > > dev-lua/luadbi > > dev-lua/luasocket > > dev-lua/lua-zlib > > dev-util/bloaty > > dev-util/cookiecutter > > net-analyzer/linkchecker > > net-libs/libssh2 > > net-misc/kafkacat > > x11-misc/flow-pomodoro > > x11-plugins/pidgin-opensteamworks > > x11-plugins/pidgin-xmpp-receipts > > > > There is another set of packages, which have a backup project > > maintaining it. Please talk to the respective project if you're > > interested in maintaining those: > > > > app-office/texstudio > > dev-python/cookies > > dev-python/freezegun > > dev-python/future > > dev-python/hiro > > dev-python/hvac > > dev-python/parsedatetime > > dev-python/parsley > > dev-python/pyhcl > > dev-python/pykka > > dev-python/pyrfc3339 > > dev-python/pytest-capturelog > > dev-python/pytest-localserver > > dev-python/responses > > dev-python/vcrpy > > dev-python/zope-component > > dev-python/zope-event > > net-firewall/nftables > > net-libs/libnftnl > > > > Best regards, > > Manuel Rüger > > > > > I have a machine using certbot (Rpi 3 Model B) now that I might be > switching to Gentoo in the future. I'd be willing to co-maintain > app-crypt/certbot with other interested developers. The catch is I don't > use Apache or nginx; others would need to maintain certbot-apache and > certbot-nginx. > > Anyone interested? > > -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 > I could probably help with that (certbot-nginx). I don't use it in particular, but could probably set up one of my test domains with it. I imagine that we'd be co-maintaining certbot and acme then? I'd be intrested in co-maintaining nftables (or may just take it), seems like something we should want to keep around... -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] New package neomutt
On 17-07-31 09:11:19, Nicolas Bock wrote: > Hi, > > I would like to add neomutt to the tree. This new package is meant > as an alternative and not a replacement of the existing mutt > package. > > Thanks, > > Nick > > -- > Nicolas Bock It was my understanding that neomutt was mainly mutt with a bunch of patches added on, from what I can see, those patches are already handled by use flags in the mutt package itself. https://www.neomutt.org/about.html describes itself as a large set of feature patches and not a fork as well. Are there missing patches that need to be added to the mutt package? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer
On 17-08-04 17:17:05, Mart Raudsepp wrote: > On K, 2017-07-26 at 11:56 +0200, Pacho Ramos wrote: > > sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions > > where having > > important bugs that were fixed in 0.9.x, but 0.9 is also plenty of > > issues. Then, > > either this is adopted by someone able to handle all that issues or > > we will need > > to finally treeclean (and drop its support for dependant packages) > > So despite this thread, this got suddenly p.masked. > > It seems most issues are related to usage with OpenRC, plus some > stopping issue with sddm. > > I can soon look into the systemd aspects, but are there anyone > interested in the openrc use case, to help out there? > > > Mart > I've reverted the p.mask commit and added myself to the metadata for plymouth (not the openrc plugin). I've also poked upstream for a new tag since it's been a while and they are active... -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer
On 17-07-26 11:56:39, Pacho Ramos wrote: > sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions where > having > important bugs that were fixed in 0.9.x, but 0.9 is also plenty of issues. > Then, > either this is adopted by someone able to handle all that issues or we will > need > to finally treeclean (and drop its support for dependant packages) > > Thanks > I did take sys-boot/plymouth, set up notifications for new releases so packaging will be somewhat automated. Also prodded upstream to release 0.9.3 (which they did) and packaged it. Updated to eapi6 as well, tested booting on systemd, worksforme. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: PowerPC Resources at OSU
On 17-09-12 10:44:42, R0b0t1 wrote: > On Mon, Sep 11, 2017 at 11:29 PM, R0b0t1 wrote: > > Hello, > > > > (This will be almost a duplicate on the PPC list, but now having more > > information I am sending it to the BSD list as well.) > > > > I apologize in advance if I did anything improper. I misunderstood > > desultory when I asked him what to do earlier. Originally I was > > unwilling to try to associate myself with Gentoo for the purpose of > > this request but I wasn't referred to anyone who could fill out the > > form "for" me. > > > > Having requested OpenPOWER hosting from OSUOSL on Gentoo's behalf, I > > was informed that hosting is already provided to the project. > > Consequently I have two questions: > > > > 1) May I have access to a/the POWER server, or some other suitable > > POWER resource? If not, > > 2) is anyone available to verify that I am associated with the project > > or that I will use the resources for project related work? > > > > > > For any comment to OSU, such as to request closure of the ticket or > > that they go ahead with allocating the VM, please comment and I will > > forward the support ticket to you. > > > > > > My intent is to experiment with the PowerPC architecture, specifically > > features found on newer POWER processors and servers. It is unlikely I > > will ever get to do this on my own as the machines run $10k-$30k. I > > requested services from OSU because GCC was not able to accommodate my > > request for hypervisor access on their system. > > > > However, having finally found the resources I've been looking for this > > whole time, it looks like OSU's nodes are virtualized and won't be > > able to do exactly what I want anyway (i.e. the GCC sysadmin was > > misinformed), so I may have accidentally wasted people's time and > > potentially tarnished Gentoo's reputation. I will make amends as best > > I can. > > > > IBM is willing to fund a node for my use and OSU is willing to deploy > > it pending contact from Gentoo leadership. If there is a machine that > > already exists that I would not disrupt, I would have no problems > > working on existing resources instead if that seems reasonable. The > > GCC server(s) are probably adequate, however I am having lots of > > problems setting up a prefix on those systems because they use CentOS. > > I am trying to fix bugs as best as I am able but it is starting to > > look hopeless. > > > > Excess resources on the donated OSU OpenPOWER machine could be offered > > to other developers or used to run a Tinderbox. It may be a good idea > > to do those things on the already existing machine(s). > > > > Respectfully, > > R0b0t1 > > I am in no great hurry to get things moving and don't mind being told > "no," but at a certain point I feel like I will have to tell OSU that > I couldn't figure out who controls their current donation. > > Respectfully, > R0b0t1 > I have access to it (can spin up servers and whatnot), but it doesn't sound like that's what you are looking for (needing a non-virtualized system). What specific features are you looking for? Are you looking for rack space to put a donated IBM system in or what? I'm not certian what you are looking for. I'm on irc (as prometheanfire) if you want to talk. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Java 9 on Gentoo
On 17-11-16 15:17:15, William L. Thomson Jr. wrote: > Just as a heads up, pass it along. For anyone interested. It will be > some time before Java 9 is available on Gentoo. It will take > considerable work to get it unmasked and safe for use. > > Once in tree masked, it will likely be very painful for anyone who does > unmask. You have been forewarned!!! > > NOT FUD! > Constructive heads up as to the factual state of things. If > you would like to see them change. Talk to Chewi/James Le Cuirot. He > will need lots of help! Even with others I guestimate a month or more > before it can be unmasked. Once its added to tree... > > -- > William L. Thomson Jr. You seem to know a bit about this, has there been a bug made outlining the troubles we will encounter as you know them? It's nice to have a warning, but sounding alarmist without concrete help doesn't actually help all that much. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] First (experimental) 17.1 profiles news item for review (v2)
On 17-12-21 08:34:31, Michał Górny wrote: > W dniu czw, 21.12.2017 o godzinie 05∶29 +, użytkownik Duncan > napisał: > > Michał Górny posted on Wed, 20 Dec 2017 14:40:27 +0100 as excerpted: > > > > In all this I don't see an answer to one question: > > > > Will this eventually be the only supported choice, or is the > > compatibility-symlinked version going to be supported going forward too? > > If it's to be only-supported, what's the timeline? > > The former. We'll make a timeline when the profiles are tested > and stable. > What group are the ones making this decision? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] First (experimental) 17.1 profiles news item for review (v2)
On 17-12-21 09:10:09, Mike Gilbert wrote: > On Thu, Dec 21, 2017 at 2:44 AM, Matthew Thode > wrote: > > On 17-12-21 08:34:31, Michał Górny wrote: > >> W dniu czw, 21.12.2017 o godzinie 05∶29 +, użytkownik Duncan > >> napisał: > >> > Michał Górny posted on Wed, 20 Dec 2017 14:40:27 +0100 as excerpted: > >> > > >> > In all this I don't see an answer to one question: > >> > > >> > Will this eventually be the only supported choice, or is the > >> > compatibility-symlinked version going to be supported going forward too? > >> > If it's to be only-supported, what's the timeline? > >> > >> The former. We'll make a timeline when the profiles are tested > >> and stable. > >> > > > > What group are the ones making this decision? > > The decision was effectively made by vapier in 2014 (see bug 506276); > mgorny is the one doing most of the work in 2017. There's also a group > of us who have been following the bug and experimenting with our own > systems since then. > > If you disagree with this plan for some reason, please start a new thread. > Nope, just curious :D -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Personal Gentoo Installer project pre-alpha release
On 18-01-14 13:57:56, Christopher Díaz Riveros wrote: > Good day devs, and users: > > generate: produces a stageX tarball. StageX contains some of > the needed files to install and configure Gentoo linux, right > now these files include: > > /etc/portage/* > /etc/timezone > /etc/locale.gen > /var/lib/portage/world StageX sounds like stage4 :P -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] reproducible builds
On 18-02-04 19:20:33, Marc Schiffbauer wrote: > * Matt Turner schrieb am 04.02.18 um 19:04 Uhr: > > On Sun, Feb 4, 2018 at 7:25 AM, Samuel Bernardo > > wrote: > > > Hi, > > > > > > I send this email to know the opinion of gentoo developers about > > > registering gentoo profiles in the context of reproducible-builds.org > > > > Reproducible builds makes sense when you're distributing binaries to > > users. > > +1 .. and I just wanted to add that this might be something very > valuable if you want some sort of public binhost like it is the case in > another current thread on this list. > > I would think of a giantic cache. If someone else already has built a > reproducable bin-package of an ebuild with the exact same > profile/USE/binutils/gcc/... combination that I am using too, then this > would be something very useful IMO which saves a lot of buildtime and > energy. > Yes, I think a lot of the same stuff could go into our build system. Simple stuff like using the same date for things for instance. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] SAT-based dependency solver: request for test cases
On 18-02-06 11:52:10, Michael Lienhardt wrote: > Dear all, > > With the help of some friends and colleagues, I am working on an SAT-based > dependency solver for portage. > We need your help to test it and possibly improve in the long run the already > great portage toolset. > > To help, you can send us the tar generated by this bash script: > https://raw.githubusercontent.com/HyVar/gentoo_to_mspl/master/benchmarks/get_installation.sh > This bash script extracts your world file, the USE flags and keywords > configuration of your system and the list of installed packages you have (it > should not take more than few seconds). > With this, we will see if our solver is able to recreate your system and how > much time it takes. > > You can send everything to my professional email: mlien...@di.unito.it > > > The goal of this alternative solver is to overcome some of the limitations of > emerge. > Thanks to some users of the forum and the gentoo-user mailing list, I already > tested the solver on 8 systems, and the results for now are: > - emerge is not able to recreate any of these systems (i.e., 'cat > world_of_test_configuration | xargs emerge -vp' on a gentoo osboxes VM does > not succeed, even with the right /etc/portage/package.* files) > - our solver takes 2 minutes in average (with little variation), and gives > either a yes answer (with what to install, which USE flags to set, which > packages to keyword) or a no answer (with the set of conflicting constraints) > for every systems > - we solved one bug in our solver (a behavior of emerge that seems > documented only in the PMS document, not in devmanual nor in the wiki, and > that is visible only in 15 packages), but at least one seems to still be > around. > > I started discussing this on the gentoo-portage-dev and the gentoo-user > mailing lists (sorry for the duplicates), and on the forum with three posts: > - https://forums.gentoo.org/viewtopic-t-1074170.html about the documentation > I collected to implement the solver > - https://forums.gentoo.org/viewtopic-t-1074202.html about the solver and > its motivations > - https://forums.gentoo.org/viewtopic-t-1075286.html about the tests I'm > doing > > > About me: > I'm a researcher in computer science, about formal methods, concurrency and > software engineering. > Friday, I will present my first paper on portage, showing that its packages > and their dependencies constitute what is called a "Multi-Software Product > Line" in software engineering. If you skip the algebraic definition, it > should be readable ^^: http://www.di.unito.it/~mlienhar/vamos.pdf > In 2013, I designed and contributed to the implementation of a dependency > solver for dynamic cloud architecture (currently maintained by Jacopo Mauro > https://bitbucket.org/jacopomauro/zephyrus2/src ) > I'm a gentoo user since 2007, and I'm very happy by this opportunity to > contribute back :). > > This sounds intresting, I wonder how it'd handle things like sys-cluster/openstack-meta which can sometimes require masking a package (gentoo stablizes a package ahead of what openstack has tested support for). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
On 17-12-09 16:29:24, Daniel Campbell wrote: > On Fri, Dec 08, 2017 at 09:22:32PM +0100, Andreas K. Huettel wrote: > > Am Donnerstag, 7. Dezember 2017, 19:06:36 CET schrieb William L. Thomson > > Jr.: > > > > > > The day everyone wanted has come, after this message. I will > > > unsubscribe not to return. You all won in 2008, and again in 2017. > > > Though this time I will not be back. I tried more than most anyone else > > > would for a very long time. Gentoo wins I lose, I am fine with that. > > > > > > Please do not contact me off list in IRC or at all. I am done with the > > > Gentoo community! > > > > > > Independent of whether William now unsubscribed or not, he's now enjoying a > > lengthy (1 year until review) vacation from all Gentoo communication > > channels. > > > > > > -- > > Andreas K. Hüttel > > dilfri...@gentoo.org > > Gentoo Linux developer (council, perl, libreoffice) > > So, mgorny threatened to leave if something wasn't done, right? I saw > the IRC conversation about unsubscribing from gentoo-dev, as well. IRC > is not private, for the record. Other developers are required to > subscribe to -dev, and are expected to follow it so they stay informed. > If they missed something covered on the list, they are directed to the > archives and (usually) laughed at. I see no reason for this expectation > to be waived for any single developer. Do I get a free pass if I don't > like what someone says? > > It's not enough to let wltjr leave on his own; you had to create a ban > and add a smug, tongue-in-cheek mail to it to maintain the image of > doing something. Quite hypocritical of comrel's attitude of secrecy to > suddenly announce a ban. It seems to me that secrecy is only adopted > when it suits those who stand to benefit from it. > > Great things coming from Gentoo "leadership" here. What will you do when > mgorny starts targeting developers and pitching tantrums over them, too? > Are we going to stratify developership further, too? It seems rather > clear to me that a few individuals see themselves as the owners of this > distro and bend it to suit their whims, using bureacracy to obscure > their actions and motivations, segment the community, and block those > less experienced. This is precisely why we have unmotivated developers > and a bevy of unmaintained packages; nobody wants to contribute to a > distro that treats its users (and developers) so poorly. > > A distro should never bend its entire social structure to protect the > feelings of one surly developer (or his/her entourage), but naturally > since every council member is friends with mgorny and comrel is afraid > to take any action against him, they'll make exceptions to established > procedures and ignore any complaints about the way he treats others. > > Software cannot fix wetware. Plenty of developers get to deal with > mgorny's aggressive and insulting tone, yet nothing happens. Gee... I > wonder why. Maybe because the upper parts of Gentoo are riddled with > cronyism. > > "Rules for thee, not for me." > > It's clear to anyone with eyeballs that there is preferential treatment > and inconsistent enforcement of rules in this community, and the people > in a position to fix it, won't, because they in fact benefit from this. > > Unfortunately, GLEP 39 does not have a section on recalling or > impeachment... This whole situation highlights why the Council has no > business sticking its head into non-technical matters. It's clearly not > up to the task. It's no surprise, since technical skill does not > guarantee or even imply social skill. (or vice-versa) > > I'm tired of people beating around the bush and the facile attempts of > tact: why do you give special treatment to certain members of this > community? Would you have done anything different if it were me or some > other developer who was proposing this change? > > It wouldn't have made it to the Council agenda if he didn't write it, > period. Everyone else would've been told to suck it up and deal with it. > And knowing how the Council is, in a few days we'll all get to deal with > the churn of mailing lists to protect one person's ego. Sad. > zlg has made comments about mgorny that he as been asked to verify. As there has been no response to the request for more information, the Trustees are retracting the comment and wish to apologize to mgorny for the inconvenience. -- Matthew Thode (prometheanfire) President, Gentoo Foundation signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On 18-03-10 15:52:21, Pacho Ramos wrote: > This packages are now up for grabs: > app-text/pspdftool > app-admin/supernova > dev-python/args > dev-python/attrdict > dev-python/behave > dev-python/clint > dev-python/dockerpty > dev-python/doublex-expects > dev-python/doublex > dev-python/expects > dev-python/ghp-import > dev-python/linecache2 > dev-python/livereload > dev-python/mamba > dev-python/mando > dev-python/mkdocs-bootstrap > dev-python/mkdocs > dev-python/monotonic > dev-python/mypy > dev-python/nose2 > dev-python/os-client-config > dev-python/paramunittest > dev-python/parse > dev-python/parse-type > dev-python/pycallgraph > dev-python/pyhamcrest > dev-python/pytest-raisesregexp > dev-python/python-termstyle > dev-python/radon > dev-python/sphinxcontrib-cheeseshop > dev-python/sphinxcontrib-newsfeed > dev-python/sphinxcontrib-spelling > dev-python/stormpath > dev-python/texttable > dev-python/torment > dev-python/traceback2 > dev-python/typing > I took app-admin/supernova and dev-python/os-client-config for openstacky stuff -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] bug queue size over time
On 18-03-19 19:33:11, Paweł Hajdan, Jr. wrote: > Is it possible to get graphs of bugs.g.o bug queue size for certain > query (e.g. by assignee) over time? > I suspect it's up and to the right. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Mailing list moderation and community openness
On 18-03-20 23:17:52, Michael Palimaka wrote: > I see that in bug #650964[1] Council is pushing forward again with > implementing user whitelisting on this mailing list (ie. anyone that is > not "approved" will have their mail rejected). > > Could someone please explain how this doesn't directly contradict the > core tenets of an open and inclusive community? > > 1: https://bugs.gentoo.org/650964 > While I personally do no agree with mailing list moderation infra has been tasked with moving forward on it. In that vein, this is what we are proposing. Install and configure mailman3/hyperkitty/postorius once they all support python3. Specifically we wish to use docker-mailman for this so we can easilly redeploy this on diferent machines as needed. mailman3 gives us two good things, it has support for moderation (for better or worse) and it handles senders using dmarc. There are still some issues with it infra side (archiving will still have to use the old system) and moving mailing lists is going to be fun, but them the breaks. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-dev] multi-backend support for ssl/tls in curl
The short of it is that curl supports having multiple backends. I'd like to have that feature enabled so libraries and userland can choose the backend they wish to use. https://bugs.gentoo.org/653076 has the specifics, but I cannot see a reason why we are artifically limiting the backed to just one. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] multi-backend support for ssl/tls in curl
On 18-04-23 02:57:50, Gordon Pettey wrote: > On Mon, Apr 23, 2018 at 1:26 AM, Michał Górny wrote: > > W dniu nie, 22.04.2018 o godzinie 09∶34 -0500, użytkownik Matthew Thode > > napisał: > >> The short of it is that curl supports having multiple backends. I'd > >> like to have that feature enabled so libraries and userland can choose > >> the backend they wish to use. > >> > >> https://bugs.gentoo.org/653076 has the specifics, but I cannot see a > >> reason why we are artifically limiting the backed to just one. > >> > > > > How would you solve the problem of packages requiring specific SSL > > backend? Currently they enforce it via USE dependency on cURL. > > Perhaps with exactly the same USE dependencies that already exists, > just without the at-most-one limitation on curl itself? > Yep, as described in the bug, there if a program requires use of a specific backend it's able to request it. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] multi-backend support for ssl/tls in curl
On 18-04-23 17:00:45, James Le Cuirot wrote: > On Mon, 23 Apr 2018 17:47:27 +0200 > Michał Górny wrote: > > > W dniu pon, 23.04.2018 o godzinie 02∶57 -0500, użytkownik Gordon > > Pettey napisał: > > > On Mon, Apr 23, 2018 at 1:26 AM, Michał Górny > > > wrote: > > > > W dniu nie, 22.04.2018 o godzinie 09∶34 -0500, użytkownik Matthew > > > > Thode napisał: > > > > > The short of it is that curl supports having multiple > > > > > backends. I'd like to have that feature enabled so libraries > > > > > and userland can choose the backend they wish to use. > > > > > > > > > > https://bugs.gentoo.org/653076 has the specifics, but I cannot > > > > > see a reason why we are artifically limiting the backed to just > > > > > one. > > > > > > > > How would you solve the problem of packages requiring specific SSL > > > > backend? Currently they enforce it via USE dependency on cURL. > > > > > > Perhaps with exactly the same USE dependencies that already exists, > > > just without the at-most-one limitation on curl itself? > > > > This doesn't guarantee that the required backend will actually be > > used. Well, unless it blocks any other USE flag from being enabled > > but that defeats the purpose. > > Proprietary software that's linked against a specific backend usually > links to libcurl-gnutls.so.4 or whatever specifically as that's what > Debian provides. If it points to just libcurl.so.4 but only works > against a specific backend then we could use chrpath to change it to > the specific name. > The way that curl installs it's libs for multi-backend (I'm currently using the proposed patch) is to still just install a single library. To get something like debian does with libcurl-gnutls we'd need to do separate builds. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Openstack Summit MeetUp
On 18-05-13 13:11:30, Jack Morgan wrote: > Gentoo, > > I will be attending the Openstack Summit in Vancouver, BC. The > conference is May 21-24th. I would like to organize a Gentoo meetup for > those attending or living in the area. I personally will be there from > May 20th - 26th. > > Please reply if you are interested in meeting and which day(s)/time(s) > you are available. I'm looking forward to it! > This is the ONE summit I'm not going to :( I do plan on attending the PTG in Denver and the Summit in Berlin though. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Python 3.5 -> 3.6 switch
On 18-05-15 07:38:36, Michał Górny wrote: > Hi, everyone. > > In no less than 30 days, we will be switching the default Python targets > from CPython 3.5 to 3.6. The new values will be: > > PYTHON_TARGETS="python2_7 python3_6" > PYTHON_SINGLE_TARGET="python3_6" > > If you haven't ported your package to Python 3.6, please look into doing > it now. Helpful lists: > > packages missing python3.6 support: > list: https://qa-reports.gentoo.org/output/gpyutils/35-to-36.txt > graph: https://qa-reports.gentoo.org/output/gpyutils/35-to-36.svg > > packages needing stabilization: > l https://qa-reports.gentoo.org/output/gpyutils/35-to-36-stablereq.txt > g https://qa-reports.gentoo.org/output/gpyutils/35-to-36-stablereq.svg > > At the same time, I'd like to remind you that Python 3.4 reaches end-of- > life in March 2019. For more details, see [1]. > > I'll submit a news item for users for review today. The switch will be > postponed to account for its publication. > > [1]:https://devguide.python.org/#status-of-python-branches > lol, when it gets to nova. The state for openstack is that upstream currently only tests on 3.5. They are just starting to test on 3.6 with the stable release with that testing probably going to occur for the 2019.1 release. Until then, most of openstack will be mainly on python 3.6. That said, there are not expected to be any problems with openstack on py36, so moving over sooner may make sense (I was hoping that py36 would be in the rocky release). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] gcc-7 going stable now
On 18-06-18 23:58:51, Andreas K. Huettel wrote: > Hi all, > > just to give a general heads up, sys-devel/gcc-7.3.0-r3 is now getting > stabilized on all arches in bug 658444. > > Cheers from the toolchain team, > Andreas > Good to hear, been using that version (and previous revbumps) for the last few months. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Reminder: ALLARCHES
On 04/30/2016 07:53 PM, Daniel Campbell wrote: > On 04/30/2016 02:16 PM, Andreas K. Huettel wrote: >> >> Hi all, >> >> just as a small reminder, to ease the load on all arch teams: >> >> If a stablerequest has the keyword ALLARCHES set, then >> * the first arch that tests successfully and stabilizes >> * can and *should* immediately stabilize for all requested arches! >> >> Whether this keyword is set on a bug is decision of the package maintainer. >> >> For example, Perl team sets ALLARCHES normall for all pure-perl packages >> (i.e., no compilation / gcc involved). >> >> Here's an example how this was used: >> https://bugs.gentoo.org/show_bug.cgi?id=578408 >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44c2d31dfc61bb3e2aee3709cb5a784b213511fa >> >> Cheers, Andreas >> >> > > A package working on one arch won't necessarily guarantee that it works > correctly on all other arches. Shouldn't we at least make sure we're > testing on the relevant arch? For example, I don't have any hppa > hardware. If I stabilized for amd64, why should I stabilize for hppa? I > can't in good faith claim that it'll work fine for hppa because I've not > tested it. > > As you said, however, it's a choice of the maintainer. Things like Perl > and Python may be less prone to this issue since they're meant to be > portable. > > My apologies if my concern is misplaced. > > ~zlg > Yes, this is mainly for interpreted languages (python/perl/ruby/etc) -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] USE flag proposal: memcached
On 05/14/2016 10:19 AM, Dirkjan Ochtman wrote: > All, > > I want to add a "memcached" USE flag to mail-filters/rmilter. Before > doing so, I looked if there was a global USE flag. There is not, but I > though see usage across 14 packages: > > dev-db/pgpool2[memcached]: Use memcached for query caching > dev-php/pecl-mysqlnd_qc[memcached]: Use > dev-libs/libmemcached as a storage handler > mail-filter/opendkim[memcached]: Add support for using > dev-libs/libmemcached > mail-mta/postfix[memcached]: Add support for using > net-misc/memcached for lookup tables > net-analyzer/graphite-web[memcached]: Enable memcached support > net-analyzer/munin[memcached]: Install the packages required for > memcached monitoring. > net-mail/automx[memcached]: Enable memcached support > sys-auth/keystone[memcached]: Installs dependencies needed for using > memcached as a backend > sys-cluster/cinder[memcached]: Installs the memcached server > sys-cluster/gearmand[memcache]: Support memcache daemon (via > dev-libs/libmemcached) for the queue storage. > sys-cluster/nova[memcached]: Installs the memcached server > sys-cluster/swift[memcached]: adds memcached support > www-servers/lighttpd[memcache]: Enable memcache support for mod_cml > and mod_trigger_b4_dl > > Most of these seem to depend on dev-libs/libmemcached or > net-misc/memcached, with a few packages depending on language-specific > stuff (e.g. dev-perl/Cache-Memcached or dev-python/python-memcached). > > I suppose the description can just be "Enable memcached support". > > Any objections? > > Cheers, > > Dirkjan > +1 from me :D -- -- Matthew Thode (prometheanfire)
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Do not modify the HOME variable
On 05/06/2016 08:25 AM, Mike Gilbert wrote:
> This was only necessary when we ran phases in parallel.
> Also, PMS says this variable should not be modified.
> ---
> eclass/distutils-r1.eclass | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 7965e91..497bed5 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -628,12 +628,6 @@ distutils-r1_run_phase() {
> # in the sys.path_importer_cache)
> mkdir -p "${BUILD_DIR}/lib" || die
>
> - # We need separate home for each implementation, for .pydistutils.cfg.
> - if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
> - local -x HOME=${HOME}/${EPYTHON}
> - mkdir -p "${HOME}" || die
> - fi
> -
> # Set up build environment, bug #513664.
> local -x AR=${AR} CC=${CC} CPP=${CPP} CXX=${CXX}
> tc-export AR CC CPP CXX
>
Thanks for this, think I reported it a while ago, can't find the bug though.
--
-- Matthew Thode (prometheanfire)
Re: [gentoo-dev] Package up for grab
On 08/02/2016 04:15 PM, Amy Winston wrote: > net-im/skype > > Anyone interested? > > I feel like this is a trick question :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: /etc/hostname on gentoo
On 08/22/2016 10:58 AM, William Hubbs wrote: > All, > > it looks like app-emulation/docker expects /etc/hostname to exist. > > On Gentoo, this file does not exist, so I'm wondering how we can make it > exist? > > I know in OpenRC I can read it and use the value there as the hostname > instead of /etc/conf.d/hostname if it exists,but I'm not sure whether > OpenRC should populate /etc/hostname if it does not exist or whether > something else should do that. > > Thoughts? > > William > I'd like us to populate the file in some way (symlink to /run or otherwise). Just keep in mind that the format is different than /etc/conf.d/hostname when considering your options. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: /etc/hostname on gentoo
On 08/22/2016 10:58 AM, William Hubbs wrote: > All, > > it looks like app-emulation/docker expects /etc/hostname to exist. > > On Gentoo, this file does not exist, so I'm wondering how we can make it > exist? > > I know in OpenRC I can read it and use the value there as the hostname > instead of /etc/conf.d/hostname if it exists,but I'm not sure whether > OpenRC should populate /etc/hostname if it does not exist or whether > something else should do that. > > Thoughts? > > William > Secondarily I'd like /etc/hostname to be seen as a source of truth. Having to write wrapper scripts to fix /etc/hostname issues can suck (cloud-init and glean). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] nftables
On 09/08/2016 07:31 PM, Ian Bloss wrote: > Anyone actively using nftables for their firewall over iptables? > Considering giving it a go as the syntax looks much nicer than iptables. Openstack uses nftables if it's available. So kinda. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
I've been using the curl into git am method for a while now, it's nice to see it's not just me :D Does pram allow you to pass options to git am (signedoffby for instance)? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 01:00 AM, Robin H. Johnson wrote: > One of the downsides both the git-am and cherry-pick workflows are that > they invalidate or otherwise omit commit signatures. > > git-merge on the other hand does preserve the signature as the original > commit is intact, and the merge commit is where the signature of the > gentoo developer is introduced. > > I agree clean history is valuable, but verifiable attribution may in > fact be more important. > Yes, I don't like this aspect of any workflow that breaks history but I personally feel that for the sake of both 'cleanliness' and ease of use that the git am (or cherry-pick) workflow is best. I could possibly see the possibility of tampering with the patch could be a problem (attribution as you say) but in the end a developer still committed it. Authored-by and Committed-by being different fields I feel the main one infra needs to worry about is Committed-by. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 04:10 AM, Ulrich Mueller wrote: > Maybe I have missed something, but why would one use --signoff for > a Gentoo commit? Personally I use it as 'I sign off on the Author's work'. I suppose the commit itself is good enough for this but I personally prefer verbosity. It also calls out that it wasn't my work. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On 10/19/2016 07:15 AM, Kristian Fiskerstrand wrote: > On 10/19/2016 02:13 PM, Matthew Thode wrote: >> On 10/19/2016 04:10 AM, Ulrich Mueller wrote: >>> Maybe I have missed something, but why would one use --signoff for >>> a Gentoo commit? >> >> Personally I use it as 'I sign off on the Author's work'. I suppose the >> commit itself is good enough for this but I personally prefer verbosity. >> It also calls out that it wasn't my work. >> > > This sounds more like a reviewed by or acked by? > > Yep, but do either of those have a simple switch I can use (-s)? :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please retain authorship of contributed patches
On 11/30/2016 03:23 PM, Andrey Utkin wrote:
> I'm quite sure this angry rant won't be pleasant to read for anybody,
> but still I believe this post serves the good of Gentoo and this issue
> is technical enough to be discussed on gentoo-dev. Also gentoo-pr list
> seems retired anyway.
>
> This is a second time I've got into a situation when a new ebuild
> submitted by me gets to mainline with minimal changes but not retaining
> my authorship at all.
>
> First time it was here: https://github.com/gentoo/gentoo/pull/361 and my
> rant was endorsed by monsieurp and the committer made excuses.
>
> This time the discussion between me and the committer has never
> happened.
>
> My PR: https://github.com/gentoo/gentoo/pull/2765
>
> My bugzilla ticket linked to it:
> https://bugs.gentoo.org/show_bug.cgi?id=599088
>
> After my pull request from Nov 6, the following commit gets into mainline:
>
> commit e19f46dfca967f4195eedf3f37a7882fbb37b796
> Author: Matthew Thode
> Date: Tue Nov 15 13:55:17 2016 -0600
>
> dev-python/secretstorage: adding for keyring
>
> Package-Manager: portage-2.3.0
>
>
> The difference between my submission and final variant by Matthew is big
> in number of lines, but is trivial in content as you can see below, so I
> don't believe that Matthew has written his variant from scratch on his
> own (he hasn't given any note on tickets on bugs.g.o or github), it
> seems more like intentional swapping and amending original lines
> retaining identical outcome.
>
> Not that authorship of one or two commits is so crucial for me, or that
> I'm the most ambitious wannabe-contributor. Hell, there's not much of
> code at all in the ebuild - it's trivial; but also not much is needed
> here to give credit. I have contributed to quite some FOSS projects, and
> have run into theft of my patches a couple of times, and it never was by
> pure accident.
>
> I beg affiliated Gentoo developers to stay sane and be thinking not just
> about numbers of your commits, but also about community spirit and
> relationships. Of course inexperienced contributor gets things not right
> first. In such cases, great maintainers fix that and retain original
> authorship; good maintainers request for changes and resubmission.
>
> In no way I'm going to drift away from Gentoo because of this issue, no
> alternatives around. (I even have a gradually maturing idea to become
> Gentoo contributor on regular basis.)
>
> Just for record, a list of projects I've contributed to: FFmpeg, Linux
> kernel, VLC, GStreamer, Kamailio, Mcabber, Gajim, v4l-utils.
>
>
> diff --git a/336a45f661 b/98c5361d66
> index 336a45f661..98c5361d66 100644
> --- a/336a45f661
> +++ b/98c5361d66
> @@ -1,19 +1,27 @@
> -# Copyright 2016 Gentoo Foundation
> +# Copyright 1999-2016 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Id$
>
> -EAPI="6"
> -PYTHON_COMPAT=( python2_7 python3_{3,4,5} )
> +EAPI=6
> +PYTHON_COMPAT=( python{2_7,3_4,3_5} )
>
> inherit distutils-r1
>
> -DESCRIPTION="Python bindings to FreeDesktop.org Secret Service API"
> -HOMEPAGE="http://pypi.python.org/pypi/SecretStorage";
> -SRC_URI="mirror://pypi/${PN:0:1}/${PN}/${P}.tar.gz"
> +MY_PN="SecretStorage"
> +
> +DESCRIPTION="Python bindings to FreeDesktop.org Secret Service API."
> +HOMEPAGE="https://github.com/mitya57/secretstorage
> https://pypi.python.org/pypi/SecretStorage";
> +SRC_URI="mirror://pypi/S/${MY_PN}/${MY_PN}-${PV}.tar.gz"
>
> LICENSE="BSD"
> SLOT="0"
> -KEYWORDS="~amd64 ~x86"
> +KEYWORDS="amd64 ~arm64 x86 ~amd64-linux ~x86-linux"
> +IUSE=""
> +
> +DEPEND="dev-python/setuptools[${PYTHON_USEDEP}]"
> +
> +RDEPEND="
> + dev-python/cryptography[${PYTHON_USEDEP}]
> + dev-python/dbus-python[${PYTHON_USEDEP}]"
>
> -RDEPEND="dev-python/dbus-python[${PYTHON_USEDEP}]
> - dev-python/cryptography[${PYTHON_USEDEP}]"
> +S="${WORKDIR}/${MY_PN}-${PV}"
>
While I did see your PR and bug if I remember correctly I didn't
actually use your commit or your ebuild to source it. I added it based
on the bug iirc (which is still waiting on the link it seems). I should
have mentioned that bug at the very least though and/or worked with you
on the ebuild.
Generally if committing from the community I will cherry-pick, which
does retain authorship.
Again, sorry about not updating the bug or waiting to work with you on
the PR. If there's something else I can do for this let me know.
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [rfc] New global USE flag: rbd
On 12/26/2016 02:17 AM, Daniel Campbell wrote: > On 12/25/2016 11:45 PM, Andrew Savchenko wrote: >> Hi all, >> >> 8 packages are using either rbd or rados USE flag for Rados >> Block Device support: >> >> use.local.desc:app-backup/bareos:rados - Enable rados storage backend >> use.local.desc:app-emulation/ganeti:rbd - Enable rados block device support >> via sys-cluster/ceph >> use.local.desc:app-emulation/libvirt:rbd - Enable rados block device support >> via sys-cluster/ceph >> use.local.desc:app-emulation/qemu:rbd - Enable rados block device backend >> support, see http://ceph.newdream.net/wiki/QEMU-RBD >> use.local.desc:net-analyzer/rrdtool:rados - Enable support for librados from >> sys-cluster/ceph >> use.local.desc:net-libs/xrootd:rbd - Enable rados block device support via >> sys-cluster/ceph >> use.local.desc:sys-block/fio:rbd - Enable Rados block device support via >> sys-cluster/ceph >> use.local.desc:sys-block/tgt:rbd - Add support for ceph block devices >> >> Suggested description: >> rbd - Enable rados block device support via sys-cluster/ceph >> >> Best regards, >> Andrew Savchenko >> > > Do we expect the list of packages using RBD to grow? If so then sure, if > for no other reason than to give a consistent description. > I think sys-cluster/cinder and maybe nova/glance could use it. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On 01/03/2017 09:11 AM, Damien LEVAC wrote: > But routine auditing, while being wishful thinking in the open-source > world (even when the projects are alive), are not meant to find those > kind of bugs anyway (and wouldn't be effective at doing so either). > I think it's wishful thinking in every world :P > I would argue that those concerns apply to every packages to different > degree and you might not be safer (on the contrary) with a maintained > but more experimental package... > > Even if just for the sake of stability, shouldn't there be a policy of > inertia? I.e. if it is not broken it does not need fixing, or something > like that? Like you said, this topic comes every once in a while and > every time it is a waste of time. Unless there is an unknown maintaining > cost in having it in the tree unmaintained? -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On 01/03/2017 09:10 AM, Kristian Fiskerstrand wrote: > On 01/03/2017 03:57 PM, Michael Mol wrote: >> For security's sake, even mature software needs, at minimum, routine >> auditing. >> Unless someone's doing that work, the package should be considered for >> removal. (Call that reason # π, in honor of TeX.) > > A distinction here likely needs to be made between actively maintained > upstream and actively Gentoo maintained as well. Actively maintained > upstream might not be an issue for a feature complete package, but if it > lacks a Gentoo-maintainer in addition it is worrying. > Agreed, the main thing a package needs is a responsive packager. If the packager finds an issue with a package that they can't fix and upstream is non-responsive then the packager is probably responsible for tree-cleaning themselves. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About ALLARCHES
On 01/24/2017 07:54 AM, Agostino Sarubbo wrote: > We are working to provide some tools for the stabilization process. > > > > > > Unfortunately, there isn't atm something able to manage the requests > with the ALLARCHES keyword, > > > > So, *everyone* with the commit access can keyword for all after a > stabilization/keyword happened at least for one arch. > > > > Thanks. > So, to be clear, we need to wait for an AT to mark stable for one arch on an ALLARCHES package. Once that is done any dev can mark the rest of the arches stable. -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] up for grabs: openvswitch and ovs
Hi all, I've left net-misc/openvswitch and dev-python/ovs to rot more or less since I've started using them a lot less over the last couple of years. If anyone wishes to take maintainership of these packages I would appreciate it. net-misc/openvswitch dev-python/ovs I expect there will be other packages that will need the same treatment. -- Matthew Thode (prometheanfire)
Re: [gentoo-dev] Some packages up for grabs
On 12/01/2012 03:59 AM, Wolfram Schlich wrote: > Hi! > > Feel free to take care of the following packages that I used to > maintain a while ago but don't anymore due to change of interest: > > - RAID controller utils: > > sys-block/afacli (older Adaptec) > sys-block/dellmgr (older Dell-branded LSI MegaRAID) > sys-block/hpacucli(HP/Compaq Smart Array) > sys-block/lsiutil (LSI MegaRAID) > sys-block/megacli (LSI MegaRAID) > sys-block/megactl (LSI MegaRAID) > sys-block/megamgr (LSI MegaRAID) > sys-block/megarc (LSI MegaRAID) > sys-block/tw_cli (3ware) > > - Other packages: > > app-arch/afio > app-misc/digitemp > app-text/utrac > dev-db/maatkit > dev-db/mysql-proxy > dev-libs/cyberjack > dev-util/sel > media-gfx/dcraw > net-analyzer/nmbscan > net-analyzer/portbunny > net-dns/fpdns > net-misc/radvd > net-misc/wol > sys-block/spindown > sys-fs/inotify-tools > sys-fs/owfs > sys-process/fcron > > If you're interested in any of these, just contact me directly. > > Thanks! > > Cheers, > Wolfram > I'll take net-misc/radvd -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some packages up for grabs
On 12/12/2012 05:54 PM, Michael Weber wrote: > On 12/12/2012 06:21 PM, Matthew Thode wrote: >> I'll take net-misc/radvd > Welcome, co-maintainer ;-) > > > ya, I say you in the metadata :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages with optional test dependencies
On 01/06/2013 06:56 AM, Diego Elio Pettenò wrote:
> I forgot to mention that (a) is what the Ruby team has been doing up
> to now -- it feels a bit more cumbersome in some cases, but it's
> definitely easier to spot the problems from the start than finding
> them months after adding the package of the tree.
>
> Especially if you change your mind and decide that you want to add the
> dependency _after_ the package has been keyworded by half the arches
> out there.
> Diego Elio Pettenò — Flameeyes
> flamee...@flameeyes.eu — http://blog.flameeyes.eu/
>
>
> On Sun, Jan 6, 2013 at 1:50 PM, hasufell wrote:
>> I agree with "a".
>> A problem with "b" is: the user might install one of those "optional
>> dependencies" later, but that will not trigger a rebuild of the other
>> package and another run through the test phase.
>> I would find "c" a bit confusing.
>>
>> The most elegant way would probably be to trigger a remerge of package
>> a, when you want to emerge package b which is also an optional
>> dependency of package a (in case package a has a test phase ofc). But I
>> don't see a clean and easy way to do that.
>>
>> On 01/06/2013 01:28 PM, Diego Elio Pettenò wrote:
>>> Go for a. The widest and more consistent the testing, the better.
>>>
>>> Otherwise the day after tomorrow you'll get a bug from me that with
>>> $foo installed, $bar fails tests.
>>> Diego Elio Pettenò — Flameeyes
>>> flamee...@flameeyes.eu — http://blog.flameeyes.eu/
>>>
>>>
>>> On Sun, Jan 6, 2013 at 11:38 AM, Michał Górny wrote:
>>>> Hello,
>>>>
>>>> There are some Python packages which have a bunch of optional tests
>>>> utilizing external packages. For example, the dev-python/logilab-common
>>>> runs a few additional tests if dev-python/egenix-mx-base is installed;
>>>> if the package is not installed, it just skips those tests.
>>>>
>>>> Those tests can't be really considered 'heavy' or in any way suggesting
>>>> use of an additional USE flag.
>>>>
>>>> Do you believe that the ebuilds should:
>>>>
>>>> a) depend on all optional test dependencies conditionally to USE=test,
>>>>therefore always requesting the widest (and consistent) testing,
>>>>
>>>> b) not depend on the optional test dependencies, resulting in less
>>>>dependencies for most users but also a bit inconsistent test
>>>>experience,
>>>>
>>>> c) put the optional test dependencies behind an additional USE flag?
>>>>
>>>> --
>>>> Best regards,
>>>> Michał Górny
>>>
>>
>>
>
This is what I have been doing with my python packages. ('A', that is.)
--
-- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] removing the server profiles...
On 01/16/2013 01:18 PM, Doug Goldstein wrote: > On Wed, Jan 16, 2013 at 8:16 AM, Ian Stakenvicius wrote: > On 16/01/13 08:32 AM, Panagiotis Christopoulos wrote: >>>> On 00:36 Wed 16 Jan , Andreas K. Huettel wrote: >>>>> several people have pointed out to me that the 10.0 -> 13.0 >>>>> transition would be a good moment to finally remove the (also in >>>>> my opinion rather useless) server profiles. >>>>> >>>> >>>> The server profiles are not useless, if we can maintain them, and >>>> if they actually are, nowadays, they shouldn't be. >>>> >>>> -1, unless other profile options being offered are "minimal" enough >>>> for the job and enabling certain things that someone may need in a >>>> server. >>>> > > Just to summarize the last massive thread on this: > > 1 - they aren't maintained; they haven't changed for years > >> I think you're confusing updates with maintenance. They work fine as >> is therefore no need for updates. > > > 2 - the only difference between server profiles and the base profile > is USE="+snmp" and maybe one other flag > >> USE="-perl -python snmp truetype xml" > > > 3 - there isn't any general consensus on what makes a server, as such > there isn't any consensus on how to make server profiles more useful. > >> Just make the base profile as minimal as possible and people will be happy. > > > > ... i think that's about it? > > PS: +1 from me. >> > > > Agreed on making the base copy as minimal as possible. (which it is, at least good enough for me). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due lack of time
On 02/03/2013 12:46 PM, Pacho Ramos wrote: > Due matsuu lack of time the following packages are up for grabs: > app-admin/augeas > app-admin/puppet > dev-ml/ocaml-augeas > dev-python/python-augeas > dev-ruby/facter > dev-ruby/hiera > taking these :D -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due lack of time
On 02/03/2013 01:18 PM, Matthew Thode wrote: > On 02/03/2013 12:46 PM, Pacho Ramos wrote: >> Due matsuu lack of time the following packages are up for grabs: >> app-admin/augeas >> app-admin/puppet >> dev-ml/ocaml-augeas >> dev-python/python-augeas >> dev-ruby/facter >> dev-ruby/hiera >> > > taking these :D > Also, if anyone else wants to help me with these it would be appreciated. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due lack of time
On 02/04/2013 09:54 AM, Theo Chatzimichos wrote: > On Sun, Feb 3, 2013 at 2:28 PM, Matthew Thode > wrote: >> On 02/03/2013 01:18 PM, Matthew Thode wrote: >>> On 02/03/2013 12:46 PM, Pacho Ramos wrote: >>>> Due matsuu lack of time the following packages are up for grabs: >>>> app-admin/augeas >>>> app-admin/puppet >>>> dev-ml/ocaml-augeas >>>> dev-python/python-augeas >>>> dev-ruby/facter >>>> dev-ruby/hiera >>>> >>> >>> taking these :D >>> >> Also, if anyone else wants to help me with these it would be appreciated. > > Puppet and friends are not unmaintained. Ruby and sysadmin herds are > taking care of these already. No problem having you as co-maintainer > there though, just let us know before you do any major changes (most > of us are in #gentoo-infra) > > Theo > Ya, I didn't plan on anything major at all. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] !!! ERROR !!!
On 02/07/2013 11:07 AM, Stefan Ehret wrote: > > == > > > !!! ERROR !!! SYSTEM ERROR !!! SYSTEM FAIL !!! > > > == > > > > > NOT IT!!! -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On 02/24/13 20:25, Michael Mol wrote: > (I really don't have time to actively participate on this list right > now, but I believe that if I bring it up on b.g.o, I'll be directed > here, so...) > > So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to > enable kerberos system-wide on my server. > > No joy, as net-fs/nfs-utils has an explicit dependency on > app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on > app-crypt/heimdal (for reasons noted in bug 195703, comment 25). > > Questions: > > 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 > and kerberos demands that things with explicit dependencies on mit-krb5 > either be fixed or not used at all. > > I'm the first activity on bug 231936 in two years...could someone please > look into that one? > > 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them > through a virtual? My suspicion is "no", but I don't know enough about > kerberos to say whether or not it would work, even as a hack. > > I'm sure explicit dependencies on mit-krb5 and heimdal will continue to > crop up, so (and forgive the nausea this might cause) it might help to > slot mit and heimdal, and have virtual/krb5 depend on the presence of at > least one. > so, read the thread so far, and I think you are over-complicating things with slotting. I use kerberos at home (more or less just to learn it, worksforme, etc). I chose MIT. From what I understand MIT and heimdal are mutually exclusive (can not operate with eachother) and that heimdal is what windows uses. What this seems to be is a simple case of blockers. So, the quesiton is, are you going to be using kerberos in nfs? if not, masking the flag may be what works for you (in the short term at least). Longer term it sounds like maybe seperate use flags are in order (or something, dunno). I don't think samba will support MIT, since it's kinda windows focused. On another note, I can't find bug 231936. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GCC 4.7 unmasking
On 02/24/13 23:45, Alex Alexander wrote: > On 25 Feb 2013 06:53, "Ryan Hill" wrote: >> >> I'm going to be unmasking 4.7.2 later this week. There are still 47 open > bugs >> blocking the 4.7 tracker, so if any are yours now would be a good time >> to take a look at them. >> >> https://bugs.gentoo.org/390247 > > Can't you just smell all those Gentoo systems gearing up for long emerge -e > sessions? xD > > Thanks for working on this. > > Alex | wired > Some of us are already on it :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] kerberos, virtuals, rattling cages
On 02/25/13 01:43, Alec Warner wrote: > On Sun, Feb 24, 2013 at 11:21 PM, Matthew Thode > wrote: >> On 02/24/13 20:25, Michael Mol wrote: >>> (I really don't have time to actively participate on this list right >>> now, but I believe that if I bring it up on b.g.o, I'll be directed >>> here, so...) >>> >>> So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to >>> enable kerberos system-wide on my server. >>> >>> No joy, as net-fs/nfs-utils has an explicit dependency on >>> app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on >>> app-crypt/heimdal (for reasons noted in bug 195703, comment 25). >>> >>> Questions: >>> >>> 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 >>> and kerberos demands that things with explicit dependencies on mit-krb5 >>> either be fixed or not used at all. >>> >>> I'm the first activity on bug 231936 in two years...could someone please >>> look into that one? >>> >>> 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them >>> through a virtual? My suspicion is "no", but I don't know enough about >>> kerberos to say whether or not it would work, even as a hack. >>> >>> I'm sure explicit dependencies on mit-krb5 and heimdal will continue to >>> crop up, so (and forgive the nausea this might cause) it might help to >>> slot mit and heimdal, and have virtual/krb5 depend on the presence of at >>> least one. >>> >> so, read the thread so far, and I think you are over-complicating things >> with slotting. I use kerberos at home (more or less just to learn it, >> worksforme, etc). I chose MIT. From what I understand MIT and heimdal >> are mutually exclusive (can not operate with eachother) and that heimdal >> is what windows uses. > > This is incorrect, or at least, was incorrect last time I looked > (circa...uhh..2009?) well, that was right around the time I installed it, so guess that makes sense. > > They work 'ok' together. Heimdal clients could talk to MIT servers at > least. Of course, there were quirks, and incompatible command line > syntax, hence my fierce recommendation to 'not do that.' > >> >> What this seems to be is a simple case of blockers. So, the quesiton >> is, are you going to be using kerberos in nfs? if not, masking the flag >> may be what works for you (in the short term at least). Longer term it >> sounds like maybe seperate use flags are in order (or something, dunno). > > Do not use Kerberized NFSv3. I'm unsure if nfsv4 is any better :/ > > -A > >> >> I don't think samba will support MIT, since it's kinda windows focused. >> >> On another note, I can't find bug 231936. >> >> -- >> -- Matthew Thode (prometheanfire) >> > -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] gentoo-openstack project
Starting up a new project (gentoo-openstack). It is currently a subproject of virtualization and our project page can be found here. http://www.gentoo.org/proj/en/virtualization/openstack/ The current goals are to flesh out the support for Openstack on Gentoo (we have the ebuilds in tree, but initscripts and the like need some work). We also want to maintain better security release upstream (as they do not make interim security releases during their release cycle. We have a bug alias as well as a list (openstack and gentoo-openstack respectively). Any advice is welcome :D -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] gentoo-openstack project
On 03/11/13 08:02, Erik Mackdanz wrote: > At Sun, 10 Mar 2013 16:57:07 -0500, > Matthew Thode wrote: >> >> Starting up a new project (gentoo-openstack). It is currently a >> subproject of virtualization and our project page can be found here. >> >> http://www.gentoo.org/proj/en/virtualization/openstack/ >> >> The current goals are to flesh out the support for Openstack on Gentoo >> (we have the ebuilds in tree, but initscripts and the like need some >> work). We also want to maintain better security release upstream (as >> they do not make interim security releases during their release cycle. >> >> We have a bug alias as well as a list (openstack and gentoo-openstack >> respectively). >> >> Any advice is welcome :D >> >> -- >> -- Matthew Thode (prometheanfire) >> > > I'm interested in this, and I think a lot of folks are. > > I've noticed there's a pretty thorough, active overlay in the wild: > https://github.com/hyves-org/openstack-overlay > Have you reached out to that guy? > > Erik > Ya, I've talked to him. At first that is where I based some of the ebuilds I used, but it is all in tree now. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On 05/01/13 05:04, Fabio Erculiani wrote: > PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. > THIS IS NOT A POST AGAINST OPENRC. > > With the release of Sabayon 13.04 [1] and thanks to the efforts I put > into the systemd-love overlay [2], systemd has become much more > accessible and easy to migrate to/from openrc. Both are able to > happily coexist and logind/consolekit detection is now done at > runtime. > It is sad to say that the "territoriality" in base-system (and > toolchain) is not allowing any kind of progress [3] [4]. This is > nothing new, by the way. > > There are several components that need patching in order to work as > expected with systemd: > - polkit needs a patch that enables runtime detection of logind/consolekit > - pambase needs to drop USE=systemd and always enable the optional > module pam_systemd.so > - genkernel needs to migrate to *udev (or as I did, provide a --udev > genkernel option), mdev is unable to properly activate LVM volumes and > LVM is actually working by miracle with openrc. Alternatively, we > should migrate to dracut. > - networkmanager need not to install/remove files depending on > USE=systemd but rather detect systemd at runtime, which is a 3 lines > script. > - openrc-settingsd needs to support eselect-settingsd, which makes > possible to switch the settingsd implementation at runtime, between > openrc and systemd. This also removes the silly conflict between > openrc-settingsd and systemd friends. > - genkernel should at least support plymouth (work in progress my side) > - other ~490 systemd units are missing at this time and writing them > could also be a great GSoC project (don't look at me, I'm busy > enough). > > All this would come with no cost for the current openrc state > (actually, my initramfs speed improvements patches in genkernel.git > also benefit openrc). > If Gentoo is about choice, we should give our users the right to > choose between the init system they like the most. > > It looks like there is some consensus on the effort of making systemd > more accessible, while there are problems with submitting bugs about > new systemd units of the sort that maintainers just_dont_answer(tm). > In this case, I am just giving 3 weeks grace period for maintainers to > answer and then I usually go ahead adding units (I'm in systemd@ after > all). > > The only remaining problem is about eselect-sysvinit, for this reason, > I am probably going to create a new separate pkg called > _sysvinit-next_, that contains all the fun stuff many developers were > not allowed to commit (besides my needs, there is also the need of > splitting sysvinit due to the issues reported in [4]). I am sure that > a masked alternative sysvinit ebuild won't hurt anybody and will make > Gentoo a bit more fun to use. > > The final outcome will hopefully be: > - easier to migrate from/to systemd, at runtime, with NO recompilation > at all (just enable USE=systemd and switch the device manager from > *udev to systemd -- unless somebody wants to drop the udev part from > systemd, if at all possible) > - we give the users the right to choose without driving them nuts with > weird emerge-fu. > - we make possible to support new init systems in future, and even > specific init wrappers (bootchart anyone?) > - we prepare the path towards a painless migration from consolekit > (deprecated for long time now) to logind (we probably need to fork it > off the systemd pkg -- upstream projects are _dropping_ consolekit > support right now!) > - we put back some fun into Gentoo > > If you want to see a working implementation of my systemd-love > efforts, just go download [1] and see things working yourself. > > [1] http://www.sabayon.org/release/press-release-sabayon-1304 > [2] https://github.com/Sabayon/systemd-love > [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236 > [4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615 > > Cheers, > Isn't there a tracker (and if not, why have you not created one yet :P ) -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On 05/15/13 16:01, Ciaran McCreesh wrote: > On Wed, 15 May 2013 22:56:21 +0200 > Alexander Berntsen wrote: >> On 15/05/13 17:10, Luca Barbato wrote: >>> Those that can't use systemd: - those not using a recent linux >>> kernel > >> And let's not forget those who aren't using Linux at all. > > Why not? > > Troll mode engaged? -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On 05/15/13 19:27, William Hubbs wrote: > On Wed, May 15, 2013 at 10:16:01PM +0800, Ben de Groot wrote: >> We don't control upstreams, but we still have choices. At this point I >> only see Gnome and udev upstreams who are forcing their users to use >> systemd. (There may be other projects too that I'm not aware of.) > > Udev doesn't force anything. In fact upstream makes it > clear that udev can be run without systemd. > > William > so then we should decouple logind from udev downstream (packaging) :D -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On 05/15/13 20:20, William Hubbs wrote: > On Wed, May 15, 2013 at 02:18:13PM -0400, waltd...@waltdnes.org wrote: >> On Wed, May 15, 2013 at 03:41:31PM +0200, Fabio Erculiani wrote >>> Are we realizing that in order to keep systemd out of our way, we're >>> currently writing and maintaining drop-in replacements for the >>> features that systemd is already providing in an actively maintained >>> state? openrc-settingsd was the first thing that we as Gentoo >>> developers (Pacho?) had to write in order to merge GNOME 3.6 into our >>> tree. >> >> So Redhat, who are heavily into GNOME >> ( http://fedoraproject.org/wiki/Red_Hat_contributions#GNOME_developers ) >> decided to make GNOME depend on other Redhat-developed software (systemd >> and pulseadio). Well... like... do... >> >> Question... when Sun made OpenOffice depend on Java (also a Sun >> product) did Gentoo developers run around suggesting that Java be made a >> part of the core Gentoo base system? I don't think so. If a user wants >> to run GNOME badly enough, he'll switch to systemd. I don't see why the >> rest of us (i.e. non-users of GNOME) should have to follow along and >> reconfigure our systems. This is a case of the tail wagging the dog. > > I don't interpret what he is saying that way. I think what he is > talking about is that we are trying to get teams to support non-systemd > setups when upstreams do not, like with gnome. > > Gnome now has a hard dependency on systemd (for gnome newer than 3.8). > Some folks want to use gnome without systemd and are putting that under > the gentoo is about choice banner and want us to support them. > >>> So what do we want to do then? Isolate from the rest of the world? >>> (It's not a sarcastic question). I hope that everybody does their >>> own reality check. >> >> You are effectively calling not-using-GNOME isolationist. Let's just >> say I disagree with you on that. BTW, see my sig. > > See above. > > William > If upstream gnome has that dep on systemd then I kinda think we should too (technical decision, not one I like personally) -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eselect init
On 05/25/13 05:25, Peter Stuge wrote: > Luca Barbato wrote: >> - init gets effectively switched only at boot/reboot > > Please not on reboot, because an unclean shutdown shouldn't leave the > system in limbo. > > On boot could work, except that it does add more steps (= more > fragility) to the boot process, which I think everyone wants to > avoid. > > I would actually expect the change to take effect immediately. > > > //Peter > the final action before / is remouted ro at shutdown would make sense to me. It's either that or first action at boot. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/20/2013 03:39 AM, Fabio Erculiani wrote: > The final outcome I would love to see is that everybody eventually > graduates from kindergarten :-) > And perhaps introduce a "culture-fit" score in the recruiting, > mentoring process. > As an employee that works for a company that requires a culture fit (very important to us). This helps a ton. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/20/2013 07:49 AM, Petteri Räty wrote: > On 20.6.2013 14.01, Matthew Thode wrote: >> On 06/20/2013 03:39 AM, Fabio Erculiani wrote: >>> The final outcome I would love to see is that everybody eventually >>> graduates from kindergarten :-) >>> And perhaps introduce a "culture-fit" score in the recruiting, >>> mentoring process. >>> >> As an employee that works for a company that requires a culture fit >> (very important to us). This helps a ton. >> > > Sounds good in theory but how do you calculate that score? In companies > there's much more interactions that allow to accumulate information for > such things. > > Regards, > Petteri > We do it during the interview process. I kinda think the best analog we can do is to watch both before and during the probation period to see how well they fit. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/20/2013 08:11 AM, hasufell wrote: > On 06/20/2013 03:07 PM, Matthew Thode wrote: >> On 06/20/2013 07:49 AM, Petteri Räty wrote: >>> On 20.6.2013 14.01, Matthew Thode wrote: >>>> On 06/20/2013 03:39 AM, Fabio Erculiani wrote: >>>>> The final outcome I would love to see is that everybody >>>>> eventually graduates from kindergarten :-) And perhaps >>>>> introduce a "culture-fit" score in the recruiting, mentoring >>>>> process. >>>>> >>>> As an employee that works for a company that requires a culture >>>> fit (very important to us). This helps a ton. >>>> >>> >>> Sounds good in theory but how do you calculate that score? In >>> companies there's much more interactions that allow to accumulate >>> information for such things. >>> >>> Regards, Petteri >>> >> We do it during the interview process. I kinda think the best >> analog we can do is to watch both before and during the probation >> period to see how well they fit. > > > Maybe that period should be extended. Longer period -> more carful > thinking of your own actions -> becomes a habit. > That might be a good idea. I just wish that we could do some sort of culture fit before they get devship (should be a prerequisite). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/20/2013 08:32 AM, Michael Weber wrote: > [talking about recruiting] > > Please don't focus on new arrivals, we should all be under investigation. > > I don't know the distribution of dev-ship-duration, but (hopefully) > it's long enough to justify a look at the stock. > > And it's not fair to pick on the candidates by putting them under > close watch (mentor ship, probation already in place) and let the > established ones walk away. > > True, I'm just saying that we can help prevent this from happening if we screened our candidates a little better. We should keep going with policing our existing devs as well of course. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Reminder: open season on robbat2's packages
On 10/30/2013 05:10 PM, Robin H. Johnson wrote: > Hi all, > > Since it's been nearly a year since I last sent this email (and I got poked > with a stick about this), it's time for a reminder. I hope that in future, if > we get a non-maintainer update GLEP [1], this will become unneeded, as it can > be on api.gentoo.org. > > 1. http://thread.gmane.org/gmane.linux.gentoo.devel/86359 > > Over the years, I've come to be the maintainer a huge number of packages > (300+) > Many of them are from inheriting packages when other developers have retired - > the upstream may also be dead, but there is nothing that supersedes the > functionality of the package, so if I use it, it lives. > > If you're a developer waiting for an action on one of them, and you've > attached > a fix to a bug, you should mostly feel free to go ahead any just apply your > patch. If you break it, I'll hunt you down. > > If you think you want to take over the package instead, or it should go for > last-rites/tree-cleaners etc; please claim it here or drop me an email; or for > the last category: just take it and leave a note. > > Notable changes from last year: > - I'm releasing mogilefs and perlbal. > - new category of stuff people are welcome to take. > > Exceptions: > dev-db/mariadb, dev-db/mysql - mysql herd > sys-libs/db - base-system > sys-fs/lvm2 - please be careful! > > Packages where I am the upstream, and feature requests probably won't go far > without large good patches: > app-admin/diradm > app-shells/localshell > sys-apps/readahead-list > dev-perl/WattsUp-Daemon > > Packages for tree-cleaner consideration: > dev-vcs/gitosis > dev-vcs/gitosis-gentoo > net-mail/vqadmin > > Here's a list of every package where I'm a maintainer and there is no herd > listed (but their might be other maintainers), and I slightly care about the > package: > app-admin/cancd > app-arch/duff > app-arch/unadf > app-backup/mirdir > app-crypt/af_alg > app-crypt/gpg-ringmgr > app-crypt/mhash > app-misc/ddccontrol > app-misc/egads > app-misc/g15composer > app-misc/g15daemon > app-misc/g15macro > app-misc/g15message > app-misc/g15stats > app-misc/gcalcli > app-text/sloccount > app-text/unrtf > dev-libs/libg15 > dev-libs/libg15render > dev-libs/libmcal > dev-libs/libmelf > dev-libs/libmemcache > dev-libs/libmemcached > dev-python/google-api-python-client > dev-vcs/cvs2svn > dev-vcs/git > net-analyzer/ipaudit > net-analyzer/ipv6-toolkit > net-analyzer/poink > net-analyzer/raddump > net-analyzer/sslsniff > net-analyzer/thrulay > net-dns/ndu > net-misc/adjtimex > net-misc/aggregate > net-misc/aggregate-flim > net-misc/ifenslave > net-misc/memcached > net-misc/netdate > net-misc/nstx > net-misc/pcapfix > net-nds/nsscache > net-wireless/bss > net-wireless/spectools > sys-apps/clrngd > sys-apps/input-utils > sys-apps/linux-misc-apps > sys-apps/usbmon > sys-auth/icmpdn > sys-auth/nss_ldap > sys-block/btrace > sys-block/fio > sys-block/scsiping > sys-block/scsirastools > sys-block/seekwatcher > sys-block/tw_cli > sys-power/iasl > sys-power/nut > sys-power/pmtools > sys-process/audit > > Items in this list, you're welcome to take them, just leave a note; they will > still work last I checked, and I do use them occasionally, but I'm not fussy > about them. > app-emulation/qenv > app-misc/dnetc > app-misc/interceptty > app-text/binfind > app-text/convmv > dev-cpp/threadpool > dev-db/libdbi > dev-db/libdbi-drivers > dev-lang/snobol > dev-libs/bglibs > dev-libs/OpenSRF > dev-libs/yaz > dev-lua/lgi > dev-util/checkbashisms > dev-util/fuzz > dev-util/idutils > dev-util/its4 > dev-util/mpatch > dev-util/pscan > dev-util/rats > dev-util/re2c > dev-util/sgb > dev-util/wiggle > media-gfx/monica > media-gfx/springgraph > net-firewall/ipset > net-libs/cvm > net-misc/dcetest > net-misc/openrdate > net-misc/rdate > net-misc/tiers > net-misc/valve > net-misc/vmnet > net-misc/vmpsd > net-misc/zsync > net-nds/led > net-proxy/piper > sys-apps/hwinfo > sys-libs/openhpi > > dev-libs/libmemcache #ok dev-libs/libmemcached #so dev-vcs/git #I will need help with this 600+ line ebuild... net-analyzer/sslsniff #zerochaos seems to have this as well, I can co-maintain :D net-misc/ifenslave#I'll take it net-misc/memcached#And this sys-auth/nss_ldap #and this sys-block/fio #... sys-power/nut #wellnow sys-power/pmtools #I ran out of things to say I will be taking these unless someone wants to yell at me (tomorrow or so). I welcome all help :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
Rackspace (where I work) currently has a developer discount program. I think we also host some open source stuff for various projects. Right now you can try to use http://developer.rackspace.com/ but if we want to make this more official I can ask around. Let me know if we want this as a more official thing (rackspace donating compute resources), no guarantees though :D. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 12:26 PM, Markos Chandras wrote: > On 11/07/2013 02:48 PM, Matthew Thode wrote: >> Rackspace (where I work) currently has a developer discount program. I >> think we also host some open source stuff for various projects. Right >> now you can try to use http://developer.rackspace.com/ but if we want to >> make this more official I can ask around. Let me know if we want this >> as a more official thing (rackspace donating compute resources), no >> guarantees though :D. >> > To be honest, I would like Gentoo infra to come up with a solution > sometime... Last time (a year ago) i asked them about this, they said > they have a cluster/big box for this purpose but they just didn't have > the time to deploy it properly or something. > Not everyone can afford paid solutions when it comes to contributing to > free software > iirc, we give $200 if infra for developer accounts for a couple of months. If a deal is struck it would likely be more and forever or something. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 03:07 PM, Denis M. wrote: > On 11/07/2013 09:18 PM, Rich Freeman wrote: >> On Thu, Nov 7, 2013 at 3:08 PM, Denis M. wrote: >>> On 11/07/2013 08:59 PM, Matthew Thode wrote: >>>> iirc, we give $200 if infra for developer accounts for a couple of >>>> months. If a deal is struck it would likely be more and forever or >>>> something. >>> I've been running my VM for Ago for 13 months now (started on september >>> 2012), where are my >$200? ;-) >>> >> Can't argue with that. :) >> >> Seriously, though, I'd love to see these needs better supported. I >> think we need to start by defining what the needs actually are (less >> redundancy, more consistency, etc). Then we figure out how to best >> address them. It could be individuals donating VMs, or it might be >> Gentoo buying resources from any number of vendors, or it could be >> Gentoo going out and looking for donors. I suspect that if we went >> out with something specific in mind we might be able to find a sponsor >> - but it is always best to have some idea just what we're going to be >> using any donations for (this will be our stage3 builder which cranks >> out a new stage3 every 20 minutes and reports build failures to double >> as a tinderbox, etc). >> >> Rich >> > > Currently Diego's tinderbox does something like that AFAIK. Compiles > things and (almost?) automatically submits bugs against the packages > with the relevant logs, etc... > > The initial idea behind my suggestion was that the devs would have the > enough system resources to address these bugs (and the ones reported > from the users, of course). > > An example here could be the following: finding/confirming a compilation > bug for a package with ~10 USE flags could take tatt quite some > compilations depending on the USE flag's combinations (this is actually > what arch testers do in order to stabilize/keyword a package). Another > example would be, as I mentioned in my previous mails to this thread - a > new glibc version comes out and (as you know) quite some packages fail > to compile against it. Having the resources, it would be possible to > track these packages faster instead of relying on random users/testers > to report them to bugs.g.o. And a last one would be testing new > KDE/GNOME/whatever-meta-with-huge-number-of-packages. > > As an AT member myself I could only give examples on how using such > system of donating/providing instances would be a benefit. For a > comprehensive list of the tasks (for consistency as you said), I'd wait > for actual devs to enumerate their needs. > > I doubt this will go as further as Gentoo actually *buying* resources. > The reason is obvious - "things have been going fine till now, why throw > monnies for something as 'unnecessary'" (which is why I haven't received > a penny for it, hehehe), that's why I came with the > donorship-of-instances version. I believe the 'going out looking for > donors' part you said is basically what I'm suggesting here, although I > believe you meant donors = huge companies providing clusters, and I > doubt that'll happen. > > From my observation, you can get a lot of work done on a simple > 2GB-ram-4-cores VirtualBox VM. Not to talk that lots of people nowadays > have these resources to spare. That's why getting actual people (and not > companies or whatever) to donate their system resources is easier to > get/reach. > > > Regards, > Denis M. > I may also have a small openstack cluster I can let people use soonish. Working on a backlog of issues now. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 11/09/2013 09:20 AM, Diego Elio Pettenò wrote: > Seems like I forgot to select reply all earlier. > > I'm going to look into that next week. I failed to resetup my monitoring > after I left my previous customer and I've reinstalled icinga just this > week. > > I don't understand people's insistence with a single product herd given we > don't have enough manpower yet and I don't want to have an explosion of > aliases I need to subscribe to, the spam is enough as it is. > If you are interested in co-maintaining with me I'd be interested in helping with the plugins (nrpe/nsca agent/plugins and pnp4nagios). I already do the icinga packages but I feel like I am starting to spread myself thing with openstack and everything :( -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/15/2014 10:57 AM, Tom Wijsman wrote: > On Wed, 15 Jan 2014 15:33:28 +0400 > Sergey Popov wrote: > >> 15.01.2014 06:42, Tom Wijsman пишет: >>> And for that occasional mis-guess, *boohoo*, the user can just file >>> a bug; which ironically even happens occasionally for stable >>> packages. >> >> If we blindly approves increasing of such mis-guesses, then our QA >> level in arch teams will down below the apropriate level IMO. And >> this is not good first of all for our stable users. > > What I'm saying is that even on arch team stabilized ebuilds bugs > getting filed happens as well; so, it happening for a maintainer > stabilized ebuild wouldn't be so problematic from that perspective. > > But, indeed, it depends on which arch team procedure efforts the > maintainer actually applies; on an own arch it is quite possible for > the maintainer to be near the QA level of the arch team, whereas not > having access to a certain architecture can indeed become problematic. > > So, for the arches the maintainers do have, it depends on what the > maintainers do as much as what the arch teams do; and to be realistic > arch teams might not always do everything as intended, especially under > time pressure. In my opinion, a maintainer would even spend more time. > > As for arches the maintainer does not have, the available machines > might be usable; though the doubt is whether they have enough power. > > Most of this discussion is hypothetical assuming stabilization stays > (or continues to grow to be more) problematic; who knows we might get > to see the opposite effect that this thread yields some new arch team > members, which could make what we've discussed here not necessary in the > short term run. It is clear everyone wants to hold on to the arch teams. > I would like to see the ability for devs to become arch testers for the packages they own on the architectures they have access to. The hard part is enforcing the arch testing guidelines, so maybe this can be considered 'arch tester jr.'. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 06/04/2014 12:44 PM, Jesus Rivero (Neurogeek) wrote: > Due to a mix of "not currently using them", "not much time available" > and "Upstreams has a completely different concept of packaging", the > following packages have been marked maintainer-needed and are up for grabs: > > net-libs/ptlib > net-libs/opal > net-voip/ekiga > app-admin/chef > app-admin/chef-expander > app-admin/chef-server > app-admin/chef-server-api > app-admin/chef-server-webui > app-admin/chef-solr > > Hoping these poor souls find a new, loving, home. > > Cheers, > > -- > Jesus Rivero (Neurogeek) > Gentoo Developer I've thought about packaging chef (I do cookbooks for a living more or less), but each time I do I back away because of ruby and how much fun it is to package (the only sane way would be gems I think...). I really want to use it at home, but can't (wont) if it's not a system package, so stick with puppet I will (both maintaining it and using it at home :D) -- -- Matthew Thode (prometheanfire)
[gentoo-dev] splitting out arm keywords
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. In any case I propose splitting out arm into armv4, armv5, armv6 and armv7. armv8 seems to be here already as arm64. 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. 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 -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Call for help: app-admin/chef
On 07/26/2014 08:38 AM, Manuel Rüger wrote: > Hello, > > app-admin/chef and its related packages are currently maintainer-needed. > > So if you're using chef on Gentoo, this is your chance to step up! > > These packages have some restricting dependencies (e.g. > Currently two version bumps (one major, one minor) are missing [1]. > > Ruby herd is willing to assist and help to work with ruby eclasses. > > Feel free to ping me on IRC (#gentoo-ruby) if you want to help out, > otherwise we will have to treeclean it sooner or later. > > Cheers, > > Manuel > > > [1] > https://bugs.gentoo.org/buglist.cgi?quicksearch=app-admin%2Fchef&list_id=2433248 > I'm going to be working on app-admin/chef (client), might make a package for omnibus-install type thing from the deb they provide for the server. -- -- Matthew Thode (prometheanfire)
Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs
On 18-07-04 12:54:50, Michał Górny wrote: > W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian > Fiskerstrand napisał: > > On 07/04/2018 12:23 PM, Michał Górny wrote: > > > -2. Root key and signing subkey of EITHER: > > > +2. Root key and a dedicated signing subkey, both of EITHER: > > > > "dedicated" here might be misread to be gentoo-specific, which doesn't > > really make much sense. > > What alternative do you suggest? We really want to make clear that we > require a separate subkey, and that subkey is not marked for encryption. > I'd suggest something along the lines of 'subkey with signing only capabilitiyies' or 'signing only subkey'. I state this because you are able to have a combined SE subkey which would match the language of dedicated or simply only saying 'signing subkey'. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-dev] Re: What means bup?
On 18-07-18 09:16:07, Johannes Huber wrote: > Hi all, > > english is not my mother language, so please clarify what bup means, just > seen here: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > > Just checked if it was a typo, but can't be: > git log --oneline --grep bup | count -l > Expected 0 lines, got 1248. > It's similiar to a sound you make when you touch something's nose. *boop* I just prefer bup instead. I generally only use it when doing simple bumps of packages (copy ebuilds with only keyword edits). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On 18-07-18 11:28:16, Mike Gilbert wrote: > On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode > wrote: > > On 18-07-18 09:16:07, Johannes Huber wrote: > >> Hi all, > >> > >> english is not my mother language, so please clarify what bup means, just > >> seen here: > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > >> > >> Just checked if it was a typo, but can't be: > >> git log --oneline --grep bup | count -l > >> Expected 0 lines, got 1248. > >> > > > > It's similiar to a sound you make when you touch something's nose. > > *boop* > > > > I just prefer bup instead. I generally only use it when doing simple > > bumps of packages (copy ebuilds with only keyword edits). > > My preference is to mention the version being added when committing a > version bump. eg. "cat/pkg: bump to x.y.z". > > Yes, it does take a few more seconds, but I think it is worth the effort. > I think more recently I've been following this format. cat/pkg: x.y.z bup -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On 18-09-22 16:16:28, Jonas Stein wrote: > >> english is not my mother language, so please clarify what bup means, just > >> seen here: > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 > >> Just checked if it was a typo, but can't be: > >> git log --oneline --grep bup | count -l > >> Expected 0 lines, got 1248. > > > It's similiar to a sound you make when you touch something's nose. > > *boop* > > There are again new commits with "bup". > Please do not misuse the commit message for jokes and word games. > My hand slipped. What ever happened to assuming the best :( Are you going to ping the list every time my hand slips up and I mistype something? Not sure you'll have time for it :P -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On 18-09-24 09:27:57, Kent Fredric wrote: > On Sat, 22 Sep 2018 15:36:23 -0500 > Matthew Thode wrote: > > My hand slipped. What ever happened to assuming the best :( Are you > > going to ping the list every time my hand slips up and I mistype > > something? Not sure you'll have time for it :P > > Personally, I would love it if more people tried harder to provide > meaningful commit messages. > > "bup" vs "bump" isn't really achieving much, just one of the two are > substantially more egregious. > > Perhaps, if the commit messages were crafted with clarity as their > intent, the consequence of accidental typos would be much more > inconsequential. > > ( I seriously think we could do with a *little* more chiding here than > we generally see, but like, I'm typically just biting my tongue every > time somebody doesn't invest any more effort than to write the word > "bump" in their text editor when committing with repoman, cos I really > don't want to be a dick about it. There's room for more than 4 > characters and a space in the subject, and infinitely more space in the > body, why do we have to choose the least clear of all options? ) > > Occasional accidents are still gonna happen, but it would be nice if we > didn't define accidents and siblings of accidents as the status quo. > What would you rather see for when a package is bumped (that is, simply copying the ebuild and editing the keywords)? -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On 18-09-23 21:39:01, Alec Warner wrote: > On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt wrote: > > > On 23/09/18 22:27, Kent Fredric wrote: > > > On Sat, 22 Sep 2018 15:36:23 -0500 > > > Matthew Thode wrote: > > >> My hand slipped. What ever happened to assuming the best :( Are you > > >> going to ping the list every time my hand slips up and I mistype > > >> something? Not sure you'll have time for it :P > > > Personally, I would love it if more people tried harder to provide > > > meaningful commit messages. > > > > > > "bup" vs "bump" isn't really achieving much, just one of the two are > > > substantially more egregious. > > > > > > Perhaps, if the commit messages were crafted with clarity as their > > > intent, the consequence of accidental typos would be much more > > > inconsequential. > > > > > > ( I seriously think we could do with a *little* more chiding here than > > > we generally see, but like, I'm typically just biting my tongue every > > > time somebody doesn't invest any more effort than to write the word > > > "bump" in their text editor when committing with repoman, cos I really > > > don't want to be a dick about it. There's room for more than 4 > > > characters and a space in the subject, and infinitely more space in the > > > body, why do we have to choose the least clear of all options? ) > > > > > > Occasional accidents are still gonna happen, but it would be nice if we > > > didn't define accidents and siblings of accidents as the status quo. > > > > > I think Kent has pretty much the point here .. we try to stipulate that > > the commit message describes what the update is, and is clear for *all* > > users of the repository, and not just the relevant maintainer. There is > > also a cronic double-standard for existing or long-standing devs, and > > newer devs, recruits and proxy-maintainers (who get a double-scrutiny > > typically) - and I could easily see how this breeds resentment... > > > > Perhaps it would be simple enough to add a check to repoman for commit > > messages less than 10 characters, and with at least one *additional* > > space, mandating two words in the commit message. It seems draconian, > > but if developers continue to be lazy, what choice does one have?! > > > > > I don't see a problem with 'version bump' as a description. Sometimes you > bump an ebuild because upstream released a new version and you want to > track. I'm fairly against changes describing what was changed (typically > the reader can git show and observe the changes.) The useful information is > *why* the change was made. Sometimes its because "upstream released a new > version." > > Like Matt I'm curious what others expect to see in the description. > That's exactly why I release much of the stuff I do, I get a task in todoist via ifttt monitoring a github atom feed that a new release is out and I package it. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
[gentoo-dev] wayland category
wayland, weston, sway{,lock,idle}, wl-clipboard, etc would be the start,
I'm sure there are a ton I'm missing but I don't know where to put
things like wl-clipboard, dev-libs doesn't seem right.
--
Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
