On Sat, Feb 08, 2020 at 10:07:48PM +0200, Otto Kekäläinen wrote:
> Hello!
>
> I've ended up in being both the maintainer in Debian and an upstream
> developer for a couple of packages and I have been fantasizing about
> how to optimize my workflow so that I primarily fix all bugs and do QA
> direc
On Thu, 06 Feb 2020 10:32:42 +1100
Dmitry Smirnov wrote:
> IMHO it is disturbing that one of the most essential processes in Debian
> -- acceptance of new and modified packages -- operates almost in secrecy.
This is an understandable perspective, but secrecy probably isn't the best word.
> To m
Michael Lustfield:
> [...]
>
> I too would love to engage in a civil discussion about ways to improve the
> situation. Let's start with this-
>
> Why do reviews take so long?
> - The team is tiny
> - Much of the team seems very burned out
> - The ones that are active tend to stick to source or "u
Package: wnpp
Severity: wishlist
Owner: Leon Marz
* Package name: libcglm
Version : 0.6.2
Upstream Author : Recep Aslantas
* URL : https://github.com/recp/cglm
* License : MIT
Programming Lang: C
Description : Optimized OpenGL Mathematics library for C
Quoting Michael Lustfield (2020-02-09 11:04:25)
> On Thu, 06 Feb 2020 10:32:42 +1100
> Dmitry Smirnov wrote:
>
> > IMHO it is disturbing that one of the most essential processes in
> > Debian -- acceptance of new and modified packages -- operates almost
> > in secrecy.
>
> This is an understan
Hi Niels,
On Sun, Feb 09, 2020 at 11:22:46AM +0100, Niels Thykier wrote:
> For the parts involving tooling, are there bugs/salsa issues describing
> the issue so a "non-FTP-team"-member can take a stab at fixing them?
First of all the major problem we are talking about, that the reviewing
process
* Ben Hutchings:
> If I recall correctly, glibc *will* provide both entry points, so there
> is no ABI break. But the size of time_t (etc.) exposed through libc-
> dev is fixed at glibc build time.
Is this a Debian-specific decision?
There has been a proposal upstream not to support 32-bit time
* Otto Kekäläinen:
> Is somebody else already doing something similar like this?
We are doing this with glibc in Fedora, which is not Debian, but kind
of similar. We try to push all backportable fixes to the upstream
release branches (and master) and synthesize new pseudo-release
tarballs from t
Hi,
Thanks for your heads up.
On Sat, 1 Feb 2020 04:05:55 +0100
Michael Biebl wrote:
> with today's upload of systemd 244.1-2 I finally enabled persistent
> journal by default [1]. It has been a long requested feature.
I read this thread and other info, my thought is
Pros)
Well, as I read
Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere
* Package name: octave-matgeom
Version : 1.2.2
Upstream Author : David Legland and Juan Pablo
Carbajal
* URL : https://octave.sourceforge.io/matgeom/
* License : BSD-2-clause and GPL-3+
Programmin
On Sun, 09 Feb 2020 04:04:25 -0600, Michael Lustfield wrote:
> I would personally *LOVE* to see ITPs be a requirement for *ALL* new packages.
Fine with me.
> Making it a requirement and expecting ftp-masters to ignore any upload until
> the ITP has existed for at least X days would be absolutely
On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
> * Ben Hutchings:
>
> > If I recall correctly, glibc *will* provide both entry points, so there
> > is no ABI break. But the size of time_t (etc.) exposed through libc-
> > dev is fixed at glibc build time.
>
> Is this a Debian-specific d
Le 09/02/2020 à 18:12, gregor herrmann a écrit :
> On Sun, 09 Feb 2020 04:04:25 -0600, Michael Lustfield wrote:
>
>> I would personally *LOVE* to see ITPs be a requirement for *ALL* new
>> packages.
>
> Fine with me.
>
>> Making it a requirement and expecting ftp-masters to ignore any upload un
On Fri, Feb 7, 2020 at 7:58 PM Sudip Mukherjee
wrote:
>
> On Fri, Feb 7, 2020 at 10:17 AM Sudip Mukherjee
> wrote:
> >
> > On Thu, Feb 6, 2020 at 10:53 PM Christian Barcenas
> > wrote:
> > >
> > > I just noticed that your packaging repo is currently empty.
> > > Would you be able to push your cu
Hi Mo,
> "Packages involved" means the packages that you intend to upload to our
> archive. The freeness of plain text files (e.g. code) is easy to judge.
> When you have doubt whether to upload a binary blob (pretrained model)
> to main or contrib, feel free to ask me publically.
Thanks, I will
Package: wnpp
Severity: wishlist
Owner: Gabriel Filion
* Package name: ruby-tty-spinner
Version : 0.9.3
Upstream Author : Piotr Murach
* URL : https://ttytoolkit.org/
* License : expat
Programming Lang: Ruby
Description : Library for showing a spinner
Hello!
Thanks for all the examples (LXQt [where I looked at the sources of
lxqt-panel], git-remote-gcrypt, nbd, review, glibc).
Most interesting was perhaps Seans git-remote-gcrypt. You even have a
rpm spec file included which helps illustrate this is a true upstream
and not a fully native Debian
Hello!
Currently the project where I am closest to this goal is in
rdiff-backup. The upstream debian/ is almost 1:1 to the downstream
debian/. I've made a dh_gencontrol override to ensure the upstream CI
always builds binaries with the correct version number inherited from
a git tag in upstream:
h
On 2/8/20 7:57 PM, Simon Richter wrote:
> In my experience, it was often a good idea to separate my upstream and
> Debian hats.
+1
My current situation is that I'm a Debian packager who has then over
time become more involved in upstream and eventually ended up with a
commit bit.
On a different
Hello,
On Sun 09 Feb 2020 at 10:57PM +02, Otto Kekäläinen wrote:
> Most interesting was perhaps Seans git-remote-gcrypt. You even have a
> rpm spec file included which helps illustrate this is a true upstream
> and not a fully native Debian package.
>
> There does not seem to be any automation ar
Hello,
On Sun 09 Feb 2020 at 04:04AM -06, Michael Lustfield wrote:
>> To make matters worse ftp-masters rarely leave their comments in ITP
>> issues. As I've recently learned that have profound effect on processing of
>> new packages.
>
> I personally think this sounds like a fantastic (and not v
On Sun, Feb 09, 2020 at 07:01:05PM -0700, Sean Whitton wrote:
> One key problem with the current workflow is that it makes it very
> difficult to avoid reviewing identical files more than once. That would
> be a big improvement.
(I was just talking with Michael about this several minutes ago.)
J
On Sunday, 9 February 2020 9:04:25 PM AEDT Michael Lustfield wrote:
> This is an understandable perspective, but secrecy probably isn't the best
> word.
Probably. If I had a better linguistic faculties then I could have find a
better word. But I have had to use what I was available...
> I perso
On Monday, 10 February 2020 1:01:05 PM AEDT Sean Whitton wrote:
> AIUI, the reason REJECT comments aren't public is because it might
> sometimes make people feel embarassed.
Then many reviews of a packaging work that is done by mentors would be
embarrassing but that's OK because everybody have a
On Saturday, 8 February 2020 1:49:20 PM AEDT Paul Wise wrote:
> There is one attribute of how Debian does things that clashes with
> being able to do this; service maintainers need to be able to update
> code on a different schedule to Debian stable and even backports
> time-frames.
When service m
25 matches
Mail list logo
