On Fri, 2023-07-28 at 12:14 +, Christian Buhtz wrote:
> I realized that most of the tests in my test suite are integration or
> system tests which are impossible to handle by Debians build server and
> testing system (how do you name it?).
These sorts of tests are suitable for autopkgtests
Carsten Schoenert writes:
> There is a private list there such information *can* be given, again,
> there is no rule that I need to do this.
> There are options if some other DD believes a package is needing an
> update, that process is called NMU (non maintainer upload). Or if you
> think
On Fri, Jul 28, 2023 at 11:08:38AM +, c.bu...@posteo.jp wrote:
> So it is possible to have packages in the debian repo that don't run any
> tests? I wasn't expecting this.
Many packages don't have tests at all. For many of them tests are not
possible or don't make much sense.
On Fri, Jul 28, 2023 at 12:14:33PM +, c.bu...@posteo.jp wrote:
> Hello,
>
> I'm upstream maintainer (but not founder) of "backintime".
>
> I realized that most of the tests in my test suite are integration or system
> tests which are impossible to handle by Debians build server and testing
>
Hello Timo,
thanks for reply.
Am 28.07.2023 14:56 schrieb Timo Röhling:
I had a look at the backintime sources, and I noticed that you
First of all: I haven't nothing. :D I'm not the founder of backintime
(BIT) just the 3rd generation maintainer trying to modernize an over 15
year old
Dear Simon,
thanks for your thougths.
Am 28.07.2023 14:44 schrieb Simon McVittie:
The other angle this could be approached from is as an upstream
developer:
IMHO this is the only angle it should be approached from because it is
upstreams responsibility and Debian shouldn't waste resources
Hi Christian,
* c.bu...@posteo.jp [2023-07-28 12:14]:
Or any other idea on your site?
I had a look at the backintime sources, and I noticed that you have
implemented a very unusual (for Python, at least) build system.
There are well-known tools and standard practices in the Python
ecosystem
On Fri, 28 Jul 2023 at 11:53:29 +0200, Carsten Schoenert wrote:
> To quote from the BTS:
> ---%<---
> > In 1.2 upstream added a test suite. We should run it during build
> > (cd common && $(MAKE) test) but it needs to be able to write to the home
> > directory, which is disabled on Debian
On Fri, 28 Jul 2023 at 11:08:38 +, c.bu...@posteo.jp wrote:
> Am 28.07.2023 11:53 schrieb Carsten Schoenert:
> > I don't see any workaround and there is non needed. The bug issue is
> > about the not usable upstream test suite that would need to be called
> > through d/rules.
>
> Maybe this
Hello,
I'm upstream maintainer (but not founder) of "backintime".
I realized that most of the tests in my test suite are integration or
system tests which are impossible to handle by Debians build server and
testing system (how do you name it?).
My package do use something like "./configure
Dear Carsten,
thanks for taking time and replying.
Am 28.07.2023 11:53 schrieb Carsten Schoenert:
you really should read the Social Contract/DFSG, the Debian policy and
the Developers reference a few times.
I'll do.
There is no rule that any DD or DM *must* do something in Debian, so
you
Hello Christian,
Am 27.07.23 um 21:56 schrieb c.bu...@posteo.jp:
Dear Carsten,
thanks for your feedback, your kind words and your patience with my
frustration. :)
I was thinking about what it is what bothers me here. It is not that
"the work" isn't done or bugs not fixed. It is that there is
Hi Gregor,
* Gregor Riepl [2023-07-28 09:21]:
I'm looking for help with a regression in cmake 3.27, that is
currently producing incorrect module installation paths for the Python
package Uranium:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042157
I posted an explanation to
Hello Christian,
if you want to improve my understanding of Debian's build environment
and learn more about it you should start to build yourself a package
locally in a Debian's build environment.
I went this way myself some years ago. We here at the list we can help
you to do it yourself.
Hi,
I'm looking for help with a regression in cmake 3.27, that is currently
producing incorrect module installation paths for the Python package
Uranium: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042157
Uranium's cmake script uses the cmake variable Python_SITELIB to
determine the
Dear Mechtilde,
thanks for taking time to reply.
Am 28.07.2023 07:31 schrieb Mechtilde:
Did you try to build the last released version?
What are your problems to build backintime?
At upstream I have no problems to build and test it because I'm
upstream. ;)
But in my understanding the
Hello Christian,
a short comment to your log mail,
Am 27.07.23 um 21:56 schrieb c.bu...@posteo.jp:
Dear Carsten,
You might haven't read all ticket comments or I wasn't able to make my
question clear. The intention of my last comments to that ticket are to
understand how Jonathan worked
17 matches
Mail list logo
