* Holger Levsen [241121 12:26]:
> and you seem to think adding another Debian specific complex tool will
> attrack new people? Most people^wcontributors out there know git already,
> for them a simple git only workflow is *much* more inviting than having
> to learn gbp *only* to contribute to Debi
On Wed, Nov 20, 2024 at 08:10:30PM -0800, Otto Kekäläinen wrote:
> > fwiw, I'm also not using git-buildpackage and I don't want to. (Step
> > learning
> > curve, too much magic, hard to debug and I dont see benefits for the
> > packages
> > I maintain.) I'm also not a beginner. And I love gbp-dch
On Fri, Nov 22, 2024 at 3:58 AM Johannes Schauer Marin Rodrigues
wrote:
>
> Hi,
>
> Quoting phil995511 - (2024-11-22 02:29:31)
> > Only kernel 6.13 will support the new GPUs that will be released in early
> > 2025, the new Intel CPUs, the same for a whole bunch of new hardware...
> >
> > To be sat
Hi,
Quoting phil995511 - (2024-11-22 02:29:31)
> Only kernel 6.13 will support the new GPUs that will be released in early
> 2025, the new Intel CPUs, the same for a whole bunch of new hardware...
>
> To be satisfied with kernel 6.12 would in my opinion be a big strategic
> mistake jeopardizing c
> > collecting stats from Debian packages, using for example data points
> > that 13573 packages in Debian have explicitly a debian/gbp.conf file
> > already.
>
> I guess those data points include how many packages use salsa, with
> various Gitlab features enabled.
>
> Since various Gitlab features
Otto Kekäläinen writes:
> Hi all,
>
> I published a complete rewrite of the earlier draft as:
>
> https://salsa.debian.org/dep-team/deps/-/merge_requests/12
> DEP-18: Encourage Continuous Integration and Merge Request
> based Collaboration for Debian packages
I think this will be mor
Quoting Otto Kekäläinen (2024-11-21 09:30:12)
> > > collecting stats from Debian packages, using for example data points
> > > that 13573 packages in Debian have explicitly a debian/gbp.conf file
> > > already.
> >
> > I guess those data points include how many packages use salsa, with
> > various
Quoting Otto Kekäläinen (2024-11-21 05:40:37)
> > > I published a complete rewrite of the earlier draft as:
> > >
> > > https://salsa.debian.org/dep-team/deps/-/merge_requests/12
> > > DEP-18: Encourage Continuous Integration and Merge Request
> > > based Collaboration for Debian packag
Debian packages a number of Luanti mods with the prefix "minetest-mod-". A
lot of these are very old versions and may contain non-free copyrighted
assets that have been replaced with free replacements in the latest
version. I don't know if the packages are even being maintained but I'm
sending this
On Thu, Nov 07, 2024 at 03:04:13PM +, Colin Watson wrote:
> On Thu, Nov 07, 2024 at 11:41:28AM +0100, Guillem Jover wrote:
> > But I'm thinking that, perhaps the best option is to ask upstream
> > directly, whether they are going to release a 2.1.x release soon, or
> > if they could do that now
Hi Kari (2024.11.18_15:40:55_+)
> - Only store debian/ in the repository and use origtargz for the rest.
I used to feel strongly this way, too. However,
A big advantage of storing the upstream sources in git is that you can
use git to manage the quilt patch queue. I used to be pretty good at
On 11/21/24 9:51 AM, Simon Josefsson wrote:
> I support going even further: I think the Debian build infrastructure
> should over time be moved over to Salsa pipelines. GitLab pipelines
> offer a lot of transparency, security and reproducability benefits
> compared to the current Debian buildds wh
On Thu, Nov 21, 2024 at 04:27:48PM +0100, ROllerozxa wrote:
> Debian packages a number of Luanti mods with the prefix "minetest-mod-". A
> lot of these are very old versions and may contain non-free copyrighted
> assets that have been replaced with free replacements in the latest
> version. I don't
Hello,
For the next release of Debian 13, I hope you will use the 6.13 kernel
which brings many essential revisions especially in terms of hardware
support (Rpi5, news AMD GPU, news Intel CPU, BTRFS performance and
fonctions, etc, etc).
And above all, it would also be wonderful if you gave users
On Thu, Nov 21, 2024 at 11:26:15AM +, Holger Levsen wrote:
> > I am not enforcing git-buildpackage on everyone. I am accelerating the
> > convergence of workflows so that it is easier for maintainers to
> > collaborate, so we can have more code reviews, more new maintainers,
> > and in the long
Hello,
I discussed all this a few days ago by email with your leader Andreas Tille
who advised me to post this here.
My goal is therefore to let you think about the question and then discuss
it among yourselves...
Only kernel 6.13 will support the new GPUs that will be released in early
2025, t
On 18/11/2024 18:16, Kari Pahula wrote:
> I'm thinking that it's the merging of debian and upstream branches and
> maintaining it that really causes the warts in gbp and I'm not at all
> sure if there are any actual workflows that require having that.
> "upstreamless" as I described it may be a bit
On 2024-11-21 21:16:20, Julian Andres Klode wrote:
> I've just finished more or less, adjusting the APT test suite
> to test gpgv-sq. I plan to upload APT that tests gpgv-sq
> tomorrow. This ensures full compatibility between apt and
> gpgv-sq going forward.
Excuse my ignorance, but what is gpgv-s
Philipp Kern writes:
> On 11/21/24 9:51 AM, Simon Josefsson wrote:
>> I support going even further: I think the Debian build infrastructure
>> should over time be moved over to Salsa pipelines. GitLab pipelines
>> offer a lot of transparency, security and reproducability benefits
>> compared to
On 2024-11-21 18:45:06, Marc Haber wrote:
> [writing this with my adduser hat on. I am also in touch with the
> maintainers of src:shadow and base-passwd]
>
> Hi,
>
> recently, I have "taken over" the wiki page about UserAccounts and have
> put in some history and general thoughts about what Debi
On 11/21/24 15:19, Iustin Pop wrote:
I'm not happy with the heavyness that one gets via gpg just for
verifying signatures, so I'd be all for a lighter-weight solution.
gpgv is lighter weight than gpgv-sq. Surprisingly, it's not just
the rustc-static-links-everything problem, since gpgv-static
On Fri, Nov 22, 2024 at 06:46:10AM +0900, Simon Richter wrote:
> Because there is no coordination between gpgv and gpgv-sq packages,
that's not entirely true.
> and
> dependent packages should have no reason to care. gpgv-sq unilaterally
> claims compatibility, and if something breaks as a resul
Hi,
> > > fwiw, I'm also not using git-buildpackage and I don't want to. (Step
> > > learning
> > > curve, too much magic, hard to debug and I dont see benefits for the
> > > packages
> > > I maintain.) I'm also not a beginner. And I love gbp-dch.
> > I think git-buildpackage is great, and I am
Hi,
> > and you seem to think adding another Debian specific complex tool will
> > attrack new people? Most people^wcontributors out there know git already,
> > for them a simple git only workflow is *much* more inviting than having
> > to learn gbp *only* to contribute to Debian.
>
> This. Exactl
Em qui., 21 de nov. de 2024, 22:29, phil995511 -
escreveu:
> Hello,
>
> I discussed all this a few days ago by email with your leader Andreas
> Tille who advised me to post this here.
>
> My goal is therefore to let you think about the question and then discuss
> it among yourselves...
>
>
> Only
Hi,
Quoting Otto Kekäläinen (2024-11-19 07:34:45)
> I am contemplating if I should also make videos on Debian packaging best
> practices, or have start a new Matrix channel specifically to help
> maintainers setup their git repositories correctly and find the optimal
> git-buildpackage commands fo
Hi,
On 11/22/24 05:49, Gioele Barabucci wrote:
Unrelated to the apt proposal, how come dpkg-divert is being used here
by gpgv-from-sq instead of using the what-is-python/python-is-pythonX
approach of just shipping a symlink?
Because there is no coordination between gpgv and gpgv-sq packages,
[writing this with my adduser hat on. I am also in touch with the
maintainers of src:shadow and base-passwd]
Hi,
recently, I have "taken over" the wiki page about UserAccounts and have
put in some history and general thoughts about what Debian thinks about
user names and name restrictions.
https
On Nov 21, Julian Andres Klode wrote:
> I've just finished more or less, adjusting the APT test suite
> to test gpgv-sq. I plan to upload APT that tests gpgv-sq
> tomorrow. This ensures full compatibility between apt and
> gpgv-sq going forward.
OK, but why?
Did you make an analysis of how much
I've just finished more or less, adjusting the APT test suite
to test gpgv-sq. I plan to upload APT that tests gpgv-sq
tomorrow. This ensures full compatibility between apt and
gpgv-sq going forward.
After that migrates to testing next week, I want to make
the switch: APT by default should use gpg
Marc Haber writes:
> For adduser's next release, I would like to discuss the following
> things:
>
> (1)
> Should Debian allow UTF-8 user names in the first place or should we
> restrict names for regular users to some us-ascii near set as well? (I
> think yes, we should)
would allowing utf-8 e
On Thu, Nov 21, 2024 at 1:57 PM phil995511 - wrote:
>
> Hello,
>
> For the next release of Debian 13, I hope you will use the 6.13 kernel which
> brings many essential revisions especially in terms of hardware support
> (Rpi5, news AMD GPU, news Intel CPU, BTRFS performance and fonctions, etc,
On 21/11/24 21:16, Julian Andres Klode wrote:
1) The Depends will install gpgv-from-sq on new systems. The
gpgv-from-sq package diverts /usr/bin/gpgv to gpgv-g10code
and Provides gpgv, installing a symlink to gpgv-sq.
Unrelated to the apt proposal, how come dpkg-divert is being used her
On Wednesday, November 20, 2024 9:10:30 PM MST Otto Kekäläinen wrote:
> I am not enforcing git-buildpackage on everyone. I am accelerating the
> convergence of workflows so that it is easier for maintainers to
> collaborate, so we can have more code reviews, more new maintainers,
> and in the long
34 matches
Mail list logo
