[NEW PORT] textproc/cast2gif: Tool to render Asciinema cast files to GIFs

[Nuno Teixeira]

Hello to all,

A tool to render textproc/py-asciinema cast files to GIF.
This is a pre-release.
Please test it and use https://github.com/katharostech/cast2gif/issues if
necessary.
Bug 251064 

Thanks,

Nuno Teixeira
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Port build failure in stage-qa,Port build failure in stage-qa

[Stefan Esser]

Am 11.11.20 um 23:48 schrieb Yasuhiro KIMURA:

From: Stefan Esser 
Subject: Port build failure in stage-qa,Port build failure in stage-qa
Date: Wed, 11 Nov 2020 21:56:49 +0100


Since DEVELOPER=yes cannot be overridden on the command line, I'll
have to remove it from make.conf to get a kernel with matching
modules installed.


I add following lines in make.conf.

--
.ifndef NO_DEVELOPER
DEVELOPER=yes
.endif
--

And developer mode can be disabled from command line with

% make NO_DEVELOPER=yes

Just FYI.


Thank you! I should have got to this solution myself ;-)

Such an override should probably exist in the port system's
Makefiles, but your work-around resolves the issue I had.

Best regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Sudden trouble with net/rdesktop

[Andrea Venturoli]

Hello.

After many year of happy usage, since yesterday rdesktop dumps core 
(12.2/amd64).



% rdesktop xx
Assertion failed: ((len * 2) < size), function _utils_data_to_hex, file 
utils.c, line 499.
Abort (core dumped)


This is systematic with 4 servers out of 5; the 5th still works 
perfectly, but I have no idea in which way it might differ from the others.


I don't think this has anything to do with the upgrade to 1.9.0, since I 
was able to use 1.9.0 for a while.


Anyone else seeing this?
Where do I go and look?

 bye & Thanks
av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

emacssurvey.org

[Joseph Mingrone]

Hello all,

Emacs ports maintainers here. Over the past few years we have made some
changes to the Emacs ports, which hopefully improve the user
experience. For example, we now update editors/emacs-devel to the latest
upstream commit about every two weeks and we eat our own dog
food. Thanks to users, we were able to catch and report bugs before they
could reach a stable release. Upstream has been receptive to our
reports, though few if any core Emacs developers run FreeBSD. If you
care about Emacs on FreeBSD, please let the Emacs community know by
filling out the Emacs Survey at

emacssurvey.org.

It's open until November 30.

Regards,

Ashish and Joe


signature.asc
Description: PGP signature

Re: Sudden trouble with net/rdesktop

[Yuri Pankov]

Yuri Pankov wrote:

Andrea Venturoli wrote:

Hello.

After many year of happy usage, since yesterday rdesktop dumps core 
(12.2/amd64).



% rdesktop xx
Assertion failed: ((len * 2) < size), function _utils_data_to_hex, 
file utils.c, line 499.

Abort (core dumped)


This is systematic with 4 servers out of 5; the 5th still works 
perfectly, but I have no idea in which way it might differ from the 
others.


I don't think this has anything to do with the upgrade to 1.9.0, since 
I was able to use 1.9.0 for a while.


Anyone else seeing this?
Where do I go and look?


I see a similar report on github:

https://github.com/rdesktop/rdesktop/issues/380

Could it be something that changed on remote side, e.g. any recent updates?

As a workaround, try increasing the buf size to e.g. 512 in 
utils.c:_utils_cert_get_info().


Sorry, looks like I'm reading that backwards, and increasing the buf 
size will actually make it worse.


BTW, did you previously have rdesktop compiled without DEBUG option, so 
that assert() simply didn't fire, and now it's ON?

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Sudden trouble with net/rdesktop

[Yuri Pankov]

Andrea Venturoli wrote:

Hello.

After many year of happy usage, since yesterday rdesktop dumps core 
(12.2/amd64).



% rdesktop xx
Assertion failed: ((len * 2) < size), function _utils_data_to_hex, 
file utils.c, line 499.

Abort (core dumped)


This is systematic with 4 servers out of 5; the 5th still works 
perfectly, but I have no idea in which way it might differ from the others.


I don't think this has anything to do with the upgrade to 1.9.0, since I 
was able to use 1.9.0 for a while.


Anyone else seeing this?
Where do I go and look?


I see a similar report on github:

https://github.com/rdesktop/rdesktop/issues/380

Could it be something that changed on remote side, e.g. any recent updates?

As a workaround, try increasing the buf size to e.g. 512 in 
utils.c:_utils_cert_get_info().

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Sudden trouble with net/rdesktop

[Andrea Venturoli]

On 11/12/20 5:18 PM, Yuri Pankov wrote:

Could it be something that changed on remote side, e.g. any recent 
updates?


Sure.
Most targets are Windows 10 machines, so they possibly updated to a 
newer version, but I don't know.

One is Windows 2012, though, so I don't think that changed that much.



As a workaround, try increasing the buf size to e.g. 512 in 
utils.c:_utils_cert_get_info().


Sorry, looks like I'm reading that backwards, and increasing the buf 
size will actually make it worse.


BTW, did you previously have rdesktop compiled without DEBUG option, so 
that assert() simply didn't fire, and now it's ON?


Actually I built it in poudriere *without* DEBUG option.

I might as well enable it and investigate, then.



 bye & Thanks
av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

www/chromium seemingly restricted to -j1

[bob prohaska]

Running -current on a Raspberry Pi 3B, at 367528.
It seems that the latest www/chromium wants to compile
exclusively with -j1, regardless of settings for -j2 
in /etc/make.conf or on the make command line.

Have I missed something new?

Thanks for reading,

bob prohaska

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FireFox keeps loosing data

[Dave Horsfall]

On Thu, 12 Nov 2020, Andrea Venturoli wrote:

Firefox uses sqlite databases to store cookies, history and other 
items. You should never store these on NFS.


Really? It has worked properly for years; it's only been broken for some 
months. Besides history works perfectly. Wouldn't any corruption produce 
some sort of log somewhere?


Never use file locking on NFS.  Period.  One day it *will* bite you, due 
to some yet-to-be-discovered bug.  In the meantime, feel free to ignore 
the advice of those who have been there before...


-- Dave
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Understanding different port counts

[Moritz Schmitt]

Hi,

I noticed a big difference between the number of ports on
freebsd.org/ports/ and on freshports.org. Currently, it's 33348 vs.
41346.

The freebsd.org's number equals roughly the number of lines of a current
INDEX, but how does FreshPorts count?

Best,
Moritz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: STOP rust!

[Dewayne Geraghty]

On 11/11/2020 12:24 am, Rozhuk Ivan wrote:
> Hi all!
> 
> With latest ports tree librsvg2-rust-2.50.0 is required to some ports.
> It want replace librsvg2-2.40.21.
> 
> I do not want build ugly rust during hours to build small lib in less than 
> minute.
> 
> 
> Same with polkit & spidermonkey.
> https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35
> 
> I remove polkit where it is possible.
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 

Good question Rozhuk, I've had a similar "problem" elsewhere.  The
workaround is to force your applications to break from the normal
maintenance/updating process.  There are two methods:

1. Lets say the upstream port that now wants to use librsvg2-rust-2.50.0 is
/usr/ports/risky/business

You'll need to modify
/usr/ports/risky/business/Makefile
to depend on librsvg2 and not librsvg2-rust

OR
2. You'll need to revert the port risky/business, everytime you perform
a /usr/ports update.

(Lookup svnlite help, or use something like
svnlite update /usr/ports
svnlite update -r '{2020-11-01}' /usr/ports/risky/business
the order is important)

Keep a record of which option you've chosen because you'll eventually
want to return to the normal way of doing things, because port
maintainers track the status of their ports - for security, feature and
bug updates and generously do the work for you.  (svnlite diff
/usr/ports may be helpful, unless you accidentally accept differences ;) )

The more promising approach is, as Yuri suggests, take up the issue with
the librsvg2 team.  However I've observed that when a downstream project
team invest in migrating to new tools, they're unlikely to rescind that
decision.

You'll also need to track the interaction of up/downstream tools because
eventually something will require a new feature in librsvg2 2.50+

Tough call, but the flexibility of the ports system helps.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: STOP rust!

[Adam Weinberger]

On Thu, Nov 12, 2020 at 2:58 PM Dewayne Geraghty
 wrote:
>
> On 11/11/2020 12:24 am, Rozhuk Ivan wrote:
> > Hi all!
> >
> > With latest ports tree librsvg2-rust-2.50.0 is required to some ports.
> > It want replace librsvg2-2.40.21.
> >
> > I do not want build ugly rust during hours to build small lib in less than 
> > minute.

Rust is an absolute beast, there's no doubt about it. Rust itself
builds painfully slowly, and then it builds other things painfully
slowly as well. I go through contortions to avoid needing Rust;
building node is frustrating enough. I'm 100% with you that building
Rust is like beating your CPU with a hammer.

Unfortunately for those of us with limited build resources, Rust is
the New Hotness for a reason. Upstreams are switching to it every day,
and more and more libraries and binaries will rely on it. We are going
to have to rip off that band-aid sometime, and the right time to do it
is when upstreams switch to it. When something I need requires Rust,
I'll have to make my peace with it. I strongly urge against the
kludges offered in this thread; much as it sucks to build, I urge you
to make your peace with Rust as a dependency. It will not be the last.
There are many great programs that I eschew because they're written in
Rust; once I make my peace with it, I'll get to use a lot of things
I've been avoiding.

librsvg has switched to Rust, and so the port has no choice but to
switch to it. It's not that we prioritize FreeBSD-provided pkgs over
end-user poudriere, it's simply our obligation to build the current
stable release with the tools they require. Linux-oriented upstreams
(like GNOME) generally expect end-users to install from
distro-provided packages, so they approach the choice of
C/C++/Haskell/Go/Rust as a transparent change. BSDs still celebrate
end-user builds, and the tools to do so are increasingly massive,
disparate, and complex.

It would be really nice if poudriere could keep a list of pkgs that
should be fetched rather than built locally, but that alone is a
nightmare for the solver, I suspect.

The tl;dr here is that I 100% agree that Rust absolutely sucks to
build, and I avoid needing to build Rust, but the ports tree will
always use whatever tools the current stable version requires. librsvg
is now built with Rust, and so we now build librsvg with Rust.

# Adam


-- 
Adam Weinberger
ad...@adamw.org  //  ad...@freebsd.org
https://www.adamw.org
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: STOP rust!

[Chris]

On 2020-11-12 15:47, Adam Weinberger wrote:

On Thu, Nov 12, 2020 at 2:58 PM Dewayne Geraghty
 wrote:


On 11/11/2020 12:24 am, Rozhuk Ivan wrote:
> Hi all!
>
> With latest ports tree librsvg2-rust-2.50.0 is required to some ports.
> It want replace librsvg2-2.40.21.
>
> I do not want build ugly rust during hours to build small lib in less than 
minute.


Rust is an absolute beast, there's no doubt about it. Rust itself
builds painfully slowly, and then it builds other things painfully
slowly as well. I go through contortions to avoid needing Rust;
building node is frustrating enough. I'm 100% with you that building
Rust is like beating your CPU with a hammer.

Unfortunately for those of us with limited build resources, Rust is
the New Hotness for a reason. Upstreams are switching to it every day,
and more and more libraries and binaries will rely on it. We are going
to have to rip off that band-aid sometime, and the right time to do it
is when upstreams switch to it. When something I need requires Rust,
I'll have to make my peace with it. I strongly urge against the
kludges offered in this thread; much as it sucks to build, I urge you
to make your peace with Rust as a dependency. It will not be the last.
There are many great programs that I eschew because they're written in
Rust; once I make my peace with it, I'll get to use a lot of things
I've been avoiding.

librsvg has switched to Rust, and so the port has no choice but to
switch to it. It's not that we prioritize FreeBSD-provided pkgs over
end-user poudriere, it's simply our obligation to build the current
stable release with the tools they require. Linux-oriented upstreams
(like GNOME) generally expect end-users to install from
distro-provided packages, so they approach the choice of
C/C++/Haskell/Go/Rust as a transparent change. BSDs still celebrate
end-user builds, and the tools to do so are increasingly massive,
disparate, and complex.

It would be really nice if poudriere could keep a list of pkgs that
should be fetched rather than built locally, but that alone is a
nightmare for the solver, I suspect.

The tl;dr here is that I 100% agree that Rust absolutely sucks to
build, and I avoid needing to build Rust, but the ports tree will
always use whatever tools the current stable version requires. librsvg
is now built with Rust, and so we now build librsvg with Rust.

# Adam

Ahem,
Using a 500 ton brake press to bend paper clips is just stupid. While Adam
makes some good points. I'd like to add that Rust is popular for a reason, 
and

can be considered UNpopular for good reason. IOW please inform your vendor
that using a 500 ton brake press to bend paper clips is stupid, and 
unreasonable.
It's a hard point to argue when confronted with the fact that using a 
multi-gig
builder to build a several-k library/program is just impractical, and 
unreasonable.


Thanks for listening. :-)

--Chris
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: botan2-2.17.1 error build

[Alex V. Petrov]

c++ -L/usr/local/lib -fstack-protector -pthread build/obj/cli/argon2.o
build/obj/cli/asn1.o build/obj/cli/bcrypt.o build/obj/cli/cc_enc.o
build/obj/cli/cli.o build/obj/cli/cli_rng.o build/obj/cli/codec[10/1463]
obj/cli/compress.o build/obj/cli/encryption.o build/obj/cli/entropy.o
build/obj/cli/hash.o build/obj/cli/hmac.o build/obj/cli/main.o
build/obj/cli/math.o build/obj/cli/pbkdf.o build/obj/cli/pk_crypt.o
build/obj
/cli/psk.o build/obj/cli/pubkey.o build/obj/cli/roughtime.o
build/obj/cli/sandbox.o build/obj/cli/speed.o
build/obj/cli/timing_tests.o build/obj/cli/tls_client.o
build/obj/cli/tls_http_server.o build/obj/cli/tl
s_proxy.o build/obj/cli/tls_server.o build/obj/cli/tls_utils.o
build/obj/cli/tss.o build/obj/cli/utils.o build/obj/cli/x509.o -pthread
-Wl,-rpath,/usr/local/lib -fstack-protector-strong  -L. -lbotan-2 -lboost_s
ystem -lbz2 -lcrypto -llzma -lz -o botan


ld: error: undefined symbol: Botan::Stateful_RNG::add_entropy(unsigned
char const*, unsigned long)

>>> referenced by cli_rng.cpp


>>>
build/obj/cli/cli_rng.o:(Botan_CLI::cli_make_rng(std::__1::basic_string, std::__1::allocator > const&,
std::__1::basic_string, std::__1::allocator > const&))





ld: error: undefined symbol:
Botan::HMAC_DRBG::HMAC_DRBG(std::__1::basic_string, std::__1::allocator > const&)

>>> referenced by speed.cpp
>>>   build/obj/cli/speed.o:(Botan_CLI::Speed::go())


ld: error: undefined symbol: Botan::vartime_divide(Botan::BigInt const&,
Botan::BigInt const&, Botan::BigInt&, Botan::BigInt&)

>>> referenced by speed.cpp
>>>
build/obj/cli/speed.o:(Botan_CLI::Speed::bench_mp_div(std::__1::chrono::duration >))

>>> referenced by speed.cpp
>>>
build/obj/cli/speed.o:(Botan_CLI::Speed::bench_mp_div10(std::__1::chrono::duration >))

ld: error: undefined symbol: Botan::operator/(Botan::BigInt const&,
unsigned long)

>>> referenced by speed.cpp
>>>
build/obj/cli/speed.o:(Botan_CLI::Speed::bench_random_prime(std::__1::chrono::duration >))
>>> referenced by speed.cpp
>>>
build/obj/cli/speed.o:(Botan_CLI::Speed::bench_random_prime(std::__1::chrono::duration >)::'lambda3'()::operator()() const)

ld: error: undefined symbol:
Botan::ASN1_Time::ASN1_Time(std::__1::chrono::time_point > >
const&)
>>> referenced by x509.cpp
>>>   build/obj/cli/x509.o:(Botan_CLI::Sign_Cert::go())

>>> referenced by x509.cpp
>>>   build/obj/cli/x509.o:(Botan_CLI::Sign_Cert::go())


ld: error: undefined symbol:
Botan::X509_CA::sign_request(Botan::PKCS10_Request const&,
Botan::RandomNumberGenerator&, Botan::ASN1_Time const&, Botan::ASN1_Time
const&) const
>>> referenced by x509.cpp
>>>   build/obj/cli/x509.o:(Botan_CLI::Sign_Cert::go())

c++: error: linker command failed with exit code 1 (use -v to see
invocation)

gmake[2]: *** [Makefile:73: botan] Error 1

gmake[2]: Leaving directory
'/usr/ports/security/botan2/work/Botan-2.17.1'


*** Error code 1

Stop.
make[1]: stopped in /usr/ports/security/botan2

*** Error code 1
-- 
-
Alex.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: botan2-2.17.1 error build

[Michael Butler via freebsd-ports]

Uninstall the previous version and rebuild. It will complete and install 
successfully,


imb

On 11/12/20 8:29 PM, Alex V. Petrov wrote:

c++ -L/usr/local/lib -fstack-protector -pthread build/obj/cli/argon2.o
build/obj/cli/asn1.o build/obj/cli/bcrypt.o build/obj/cli/cc_enc.o
build/obj/cli/cli.o build/obj/cli/cli_rng.o build/obj/cli/codec[10/1463]
obj/cli/compress.o build/obj/cli/encryption.o build/obj/cli/entropy.o
build/obj/cli/hash.o build/obj/cli/hmac.o build/obj/cli/main.o
build/obj/cli/math.o build/obj/cli/pbkdf.o build/obj/cli/pk_crypt.o
build/obj
/cli/psk.o build/obj/cli/pubkey.o build/obj/cli/roughtime.o
build/obj/cli/sandbox.o build/obj/cli/speed.o
build/obj/cli/timing_tests.o build/obj/cli/tls_client.o
build/obj/cli/tls_http_server.o build/obj/cli/tl
s_proxy.o build/obj/cli/tls_server.o build/obj/cli/tls_utils.o
build/obj/cli/tss.o build/obj/cli/utils.o build/obj/cli/x509.o -pthread
-Wl,-rpath,/usr/local/lib -fstack-protector-strong  -L. -lbotan-2 -lboost_s
ystem -lbz2 -lcrypto -llzma -lz -o botan


ld: error: undefined symbol: Botan::Stateful_RNG::add_entropy(unsigned
char const*, unsigned long)


referenced by cli_rng.cpp






build/obj/cli/cli_rng.o:(Botan_CLI::cli_make_rng(std::__1::basic_string, std::__1::allocator > const&,
std::__1::basic_string, std::__1::allocator > const&))





ld: error: undefined symbol:
Botan::HMAC_DRBG::HMAC_DRBG(std::__1::basic_string, std::__1::allocator > const&)


referenced by speed.cpp
   build/obj/cli/speed.o:(Botan_CLI::Speed::go())



ld: error: undefined symbol: Botan::vartime_divide(Botan::BigInt const&,
Botan::BigInt const&, Botan::BigInt&, Botan::BigInt&)


referenced by speed.cpp


build/obj/cli/speed.o:(Botan_CLI::Speed::bench_mp_div(std::__1::chrono::duration >))


referenced by speed.cpp


build/obj/cli/speed.o:(Botan_CLI::Speed::bench_mp_div10(std::__1::chrono::duration >))

ld: error: undefined symbol: Botan::operator/(Botan::BigInt const&,
unsigned long)


referenced by speed.cpp


build/obj/cli/speed.o:(Botan_CLI::Speed::bench_random_prime(std::__1::chrono::duration >))

referenced by speed.cpp


build/obj/cli/speed.o:(Botan_CLI::Speed::bench_random_prime(std::__1::chrono::duration >)::'lambda3'()::operator()() const)

ld: error: undefined symbol:
Botan::ASN1_Time::ASN1_Time(std::__1::chrono::time_point > >
const&)

referenced by x509.cpp
   build/obj/cli/x509.o:(Botan_CLI::Sign_Cert::go())



referenced by x509.cpp
   build/obj/cli/x509.o:(Botan_CLI::Sign_Cert::go())



ld: error: undefined symbol:
Botan::X509_CA::sign_request(Botan::PKCS10_Request const&,
Botan::RandomNumberGenerator&, Botan::ASN1_Time const&, Botan::ASN1_Time
const&) const

referenced by x509.cpp
   build/obj/cli/x509.o:(Botan_CLI::Sign_Cert::go())


c++: error: linker command failed with exit code 1 (use -v to see
invocation)

gmake[2]: *** [Makefile:73: botan] Error 1

gmake[2]: Leaving directory
'/usr/ports/security/botan2/work/Botan-2.17.1'


*** Error code 1

Stop.
make[1]: stopped in /usr/ports/security/botan2

*** Error code 1



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FireFox keeps loosing data

[Andrea Venturoli]

On 11/12/20 9:52 PM, Dave Horsfall wrote:

Never use file locking on NFS.  Period.  One day it *will* bite you, due 
to some yet-to-be-discovered bug.  In the meantime, feel free to ignore 
the advice of those who have been there before...


Thanks for the advice.
What protocol do you suggest, instead, for sharing data to a diskless 
client?
The only other I used is SMB and it proved far more problematic than 
NFS, in my experience.


 bye & Thanks
av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: STOP rust!

[Thierry Thomas]

Le ven. 13 nov. 20 à  0:47:49 +0100, Adam Weinberger 
 écrivait :

> It would be really nice if poudriere could keep a list of pkgs that
> should be fetched rather than built locally, but that alone is a
> nightmare for the solver, I suspect.

Good news: it´s coming!

-- 
Th. Thomas.


signature.asc
Description: PGP signature