Re: [gentoo-dev] zoom concerns

2020-04-02 Thread Michal Prívozník
On 2. 4. 2020 7:51, Michał Górny wrote:
> On Thu, 2020-04-02 at 10:13 +0800, William Kenworthy wrote:
>> And I would like to add that sometimes you don't have a choice - if 
>> someone who is paying you says to use zoom, there is no choice
> 
> You always have a choice.  You can live poor and happy!  ;-)
> 
>>  - but I 
>> would rather use gentoo than fire up the MS laptop..
> 
> ...and here's where we disagree.  It's better to run risky apps
> on a throwaway system than let them damage or crack your primary system.
> 

Alternatively, you can set up a VM that contains nothing but the bare
minimum required to run app X and assign webcam to it, for instance.
Having said that, I'd still love the packaging system to install the app
as it resolves all the dependencies, etc.

Michal




[gentoo-dev] Re: autotools

2020-03-26 Thread Michal Prívozník
On 26. 3. 2020 18:47, Samuel Bernardo wrote:
> Dear all,
> 
> I send this email to ask you for your help for the better approach to
> translate the following autoreconf command to an ebuild:
> 
>> |autoreconf -i -f ./configure \ --prefix=/usr \
>> --libexecdir=/usr/lib/snapd \
>> --with-snap-mount-dir=/var/lib/snapd/snap \ --enable-apparmor \
>> --enable-nvidia-biarch \ --enable-merged-usr|
> I realise that eautoreconf from autotools.eclass doesn't accept any
> parameters, so how would you advise me to reproduce it inside an ebuild
> using the available functions and eclasses?
> 
> My goal is to create an ebuild from latest snapd pkgbuild:
> 
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=snapd
> 
> Thank you,
> 
> Samuel
> 

I guess you are not really after autoreconf arguments rather than
./configure ones. You want to focus on src_configure() in the ebuild. I
suggest starting here:


https://devmanual.gentoo.org/ebuild-writing/functions/src_configure/configuring/index.html

and there are plenty of examples existing in the portage. You will need
to define USE flags for your ebuild though so that users can
enable/disable parts of functionality.

Happy hacking!

Michal




Re: [gentoo-dev] [PATCH] app-emulation/libvirt-snmp: version bump to 0.0.4

2018-10-27 Thread Michal Prívozník
On 10/26/2018 05:42 PM, Michael Orlitzky wrote:
> On 10/26/2018 04:40 AM, Michal Prívozník wrote:
>>
>> So the desired way is to use github pull requests? That is rather
>> unfortunate. 
> 
> In this case there's no "project" associated with libvirt-snmp; but if
> there were, it would have a @gentoo.org alias that you
> could send patches to. 

Well, why don't we create something like virtualizat...@gentoo.org? That
would be a mailing list to discuss virtualization related topics.

Bugzilla is still the official (and in this case,
> best) place to put these in my opinion.

I don't think so. I've been attaching patches to BZ in the past and the
response time was very poor. I know everybody is working on gentoo in
their spare time and I appreciate it, but why not use something that
works for both sides? I think that if we want to attract more volunteers
we have to have a process that goes the least into their way.

> 
> Personally I don't mind them on the -dev list, but they do get sent to a
> thousand people who have no interest in or ability to commit them.
> 

That is the case on every mailing list. Every -dev list has number of
subscribes far bigger than number of people with commit access.

But I respect your decision guys. I am going to stop posting patches
until there's an agreement on how to do that.

Michal



Re: [gentoo-dev] [PATCH] app-emulation/libvirt-snmp: version bump to 0.0.4

2018-10-26 Thread Michal Prívozník
On 10/26/2018 06:52 AM, Mikle Kolyada wrote:
> 
> 
> On 26.10.2018 04:04, Matthias Maier wrote:
>>> could you please stop sending project related stuff to the -dev mailing
>>> list? It is irrelevant place to provide bump patches
>> Why? What's the purpose of a developer mailing list then?
> Because we have github/project alias for that purpose
> 

So the desired way is to use github pull requests? That is rather
unfortunate.

Michal