Mac builds have been uploaded, just the same as all the other 5.1
releases. Have a good weekend, everyone!
On Wed, May 13, 2020 at 3:48 PM Kevin Cozens wrote:
>
> On 2020-05-13 4:11 p.m., Rene Pöschl wrote:
> > You must pull the tagged commit otherwise you get whatever got merged last.
>
> Ok,
Thanks Nick - I didn't know that. I thought Adam was looking for the source
tar rather than pre-built docs.
Steve
On 5/14/20 3:44 PM, Nick Østergaard wrote:
@Steven A. Falco it is because we just prebuilt docs in the macos builds.
On Thu, 14 May 2020 at 21:34, Steven A. Falco
@Steven A. Falco it is because we just prebuilt docs in the macos builds.
On Thu, 14 May 2020 at 21:34, Steven A. Falco wrote:
>
> You can directly download tars from gitlab. Here is the url for the docs:
>
> https://gitlab.com/kicad/services/kicad-doc/-/archive/5.1.6/kicad-doc-5.1.6.tar.bz2
>
You can directly download tars from gitlab. Here is the url for the docs:
https://gitlab.com/kicad/services/kicad-doc/-/archive/5.1.6/kicad-doc-5.1.6.tar.bz2
You can specify a different file extension if you prefer something other than
bzip2.
Since gitlab is where kicad-doc is
On 14/05/2020 18:43, Wayne Stambaugh wrote:
Rene,
I wonder if we should implement a library commit message policy similar
to the one we use for the source repo[1] and tailor the changelog tags
for how library commits (or any other kicad repo) are made? It's pretty
painless from a committers
Carsten,
What information do you need from KiCad. Does Debian (or any other
disto) have recommendations for upstream projects to help packagers?
Packaging is import to the project so if we can package devs lives a bit
easier, I'm willing to consider ways to do so.
Rene,
I wonder if we should
The kicad library team does not have the resources to properly handle
even our main tasks (see the number of open pull requests awaiting
review, hint it is >300 with >600 open over all) let alone handling
additional docu. Plus we are not working with sourcecode. The skills of
the librarieans
Odd. It definitely is there. Thanks! Everyone else, please disregard.
Adam
On Thu, May 14, 2020 at 9:25 AM Christoph Moench-Tegeder
wrote:
>
> ## Adam Wolf (adamw...@feelslikeburning.com):
>
> > The Mac release packaging uses a tarball that has been located at
> >
## Adam Wolf (adamw...@feelslikeburning.com):
> The Mac release packaging uses a tarball that has been located at
> https://kicad-downloads.s3.cern.ch/docs/kicad-doc-5.1.x.tar.gz. It
> does not seem like the 5.1.6 tarball is up yet.
It's there:
===> License GPLv3+ CC-BY-3.0 accepted by the
Hi folks!
The Mac release packaging uses a tarball that has been located at
https://kicad-downloads.s3.cern.ch/docs/kicad-doc-5.1.x.tar.gz. It
does not seem like the 5.1.6 tarball is up yet. Is that something
that will happen today? I built test builds using the 5.1.6 tags for
everything using
On 5/14/20 1:28 AM, victor tejada wrote:
Hello, guys, I tried to compile kicad source code on fedora 32 but the error is
"ImportError: No module named wx
CMake Error at CMakeModules/FindwxPython.cmake:52 (message):
wxPython/Phoenix does not appear to be installed on the system
Call Stack (most
Hello Evan,
thanks for taking some time and writing up some sentences and opinions.
I don't wanted to blame anybody by my email, I just wanted to raise some
concerns I did have.
KiCad is not the only upstream project I package for Debian. From about
5 years experience of Debian packaging I can
12 matches
Mail list logo
