Vincent Lefevre wrote:
> Isn't the "ftp:" URL scheme obsolete?
No, it isn't.
> At least it is no longer
> recognized by Firefox, which does a search on Google instead.
Yes, FTP support has been removed from Firefox since version 90 in 2021,
but Firefox is - first and foremost - a browser, not a
Hi,
I've noticed lots of "ftp:" URLs in debian/copyright files.
Isn't the "ftp:" URL scheme obsolete? At least it is no longer
recognized by Firefox, which does a search on Google instead.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessi
On Apr 25, Vincent Lefevre wrote:
I've noticed lots of "ftp:" URLs in debian/copyright files.
Isn't the "ftp:" URL scheme obsolete? At least it is no longer
The protocol, maybe. The URL scheme not at all.
recognized by Firefox, which does a search on G
Le Fri, Apr 25, 2025 at 11:24:53PM +0200, Vincent Lefevre a écrit :
>
> I've noticed lots of "ftp:" URLs in debian/copyright files.
> Isn't the "ftp:" URL scheme obsolete? At least it is no longer
> recognized by Firefox, which does a search on Googl
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 18 Apr 2025 14:37:34 +0200
Debian Project Secretary - Kurt Roeckx wrote:
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 7066677e-e899-4143-af5e-710364fc2673
> [ ] Choice 1: Gianfranco Costamagn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 18 Apr 2025 14:37:34 +0200
Debian Project Secretary - Kurt Roeckx wrote:
>
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines
> =-=-=-=-=-=-=-=- 7066677e-e899-4143-af5e-710364fc2673
> [ ] Choice 1: Gian
On Fri, 18 Apr 2025 14:37:34 +0200
Debian Project Secretary - Kurt Roeckx wrote:
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines
> =-=-=-=-=-=-=-=- 7066677e-e899-4143-af5e-710364fc2673
> [ ] Choice 1: Gianfranco Costamagna
> [ ] Choice 2: Julian Andres Klode
> [
On 2025-04-17 Osamu Aoki wrote:
> Following up on my previous post.
>> How about adding simpler versioned depends (no pre-depends) with pre-rm
>> script?
> I am talking about tricks using the "dpkg-maintscript-helper
> symlink_to_dir ..." command. Any thought?
[deleting drafted response]
This
Aoki wrote:
> Hi,
>
>
> I now see this as a bug. I think this was caused by my post-bookworm change
> in
> debian-reference (2.109) on Mon, 18 Dec 2023.
>
> If I remember correctly, the intent of this change was to move all
> HTML/PDF/Plain_Text document to a p
Hi,
I now see this as a bug. I think this was caused by my post-bookworm change in
debian-reference (2.109) on Mon, 18 Dec 2023.
If I remember correctly, the intent of this change was to move all
HTML/PDF/Plain_Text document to a path under /usr/share/doc/ for better policy
compliance.
This
On Sat, Apr 12, 2025 at 09:09:25AM +0200, Debian Project Secretary - Kurt
Roeckx wrote:
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 7066677e-e899-4143-af5e-710364fc2673
> [2] Choice 1: Gianfranco Costamagna
> [2] Choice 2: Julian Andres Klo
I belive debian wants to provide its documentation as packages in stable
releases.
But currently debian-reference is scheduled for auto removal on 2025-04-15
(which this mail bumps a bit into the future).
Maybe "nobody" is aware of this?
Anyone up to taking a look at this?
On Mon, 1
[Forwarded copy of original email: signed for authentication]
On Sat, Apr 05, 2025 at 04:06:17PM +, Andrew M.A. Cater wrote:
> Dear Branden,
>
> The Debian Code of Conduct[1] (and the mailing list Code of Conduct[2]) can
> be boiled down to two sentences in simple English:
>
Hi,
On 4/6/25 4:04 PM, Simon Josefsson wrote:
Some questions were asked in
https://lists.debian.org/debian-devel/2024/02/msg9.html quoted here
again for easy reference:
2) For each private key, information about its management and lifecycle.
Relevant questions include:
a) How was
On 06/04/2025 22:04, Simon Josefsson wrote:
Ansgar writes:
Hi,
as usual we have prepared new archive signing keys.
Can you share some more information about these keys?
Some questions were asked in
https://lists.debian.org/debian-devel/2024/02/msg9.html quoted here
again for easy
Ansgar writes:
> Hi,
>
> as usual we have prepared new archive signing keys.
Can you share some more information about these keys?
Some questions were asked in
https://lists.debian.org/debian-devel/2024/02/msg9.html quoted here
again for easy reference:
2) For each pr
I'd surely feel more confident about this if there was a signature.
signature.asc
Description: This is a digitally signed message part.
Dear Branden,
The Debian Code of Conduct[1] (and the mailing list Code of Conduct[2]) can
be boiled down to two sentences in simple English:
Assume good faith.
Treat others with respect, both within and outside Debian.
You seem to be complaining about the conduct of the Community Team
On Mon Mar 31, 2025 at 10:56 PM BST, CrypticVerse wrote:
I am sorry if this was said earlier and I did not catch it,
but I cannot find the reasoning behind the closure of this ITP.
Can someone tell me just a bit more about that?
Again, I am sorry if this was already mentioned
I've re-opened it
Hello,
I am sorry if this was said earlier and I did not catch it,
but I cannot find the reasoning behind the closure of this ITP.
Can someone tell me just a bit more about that?
Again, I am sorry if this was already mentioned
Thanks!
---
Luka
On Thu Mar 27, 2025 at 12:50 PM GMT, Simon Josefsson wrote:
To me this looks like it can be a useful package, if it isn't already,
and it looks fine for inclusion into Debian.
Apologies to Luka, I should not describe it as "clearly not suitable".
--
Please do not CC me for
Hi,
Yes, I have looked into the 'dh-make' tool. From what I've seen, it
generated too many files that were not needed to compile the program.
'dh-make', for me, also left a lot of fields that needed to be manually
edited later on. My tool takes in user input a bit more than 'dh-make', so
it can wri
On 27/03/2025 13:50, Simon Josefsson wrote:
I've found the 'dh-make-golang make' tool incredibly useful to quickly
get a suitable debian/* template for a project. I would find a similar
tool that isn't Go-specific which would could an upstream tarball and/or
a URL to a hom
Nicolas Peugnet writes:
> On 27/03/2025 13:50, Simon Josefsson wrote:
>> I've found the 'dh-make-golang make' tool incredibly useful to quickly
>> get a suitable debian/* template for a project. I would find a similar
>> tool that isn't Go-specific whi
"Jonathan Dowland" writes:
> On Wed Mar 26, 2025 at 7:12 PM GMT, Alexandre Detiste wrote:
>> Please stop this series of troll packages.
>
> I think characterising this as trolling is unfair.
+1
> Clearly this is not suitable for inclusion in Debian, but, what isn&#x
On Wed Mar 26, 2025 at 7:12 PM GMT, Alexandre Detiste wrote:
Please stop this series of troll packages.
I think characterising this as trolling is unfair. Clearly this is not
suitable for inclusion in Debian, but, what isn't clear is Luka's
intent. It looks to me that they ar
Please stop this series of troll packages.
---
package_name = subprocess.run("cat debian/control | grep Source | awk
'{{print $2}}'", shell=True, check=True, stdout=subprocess.PIPE, text=True)
Le mer. 26 mars 2025, 20:03, Luka Kubat a écrit :
> Package: wnpp
>
Package: wnpp
Severity: wishlist
Owner: Luka Kubat
X-Debbugs-Cc: debian-devel@lists.debian.org, crypticvers...@gmail.com
* Package name: package-assembler
Version : 1.0.0
Upstream Contact: Luka Kubat
* URL : https://github.com/Crypticverse/package-assembler
* License
faced an old
> known problem with OpenPGP certificates with SHA-1 issues in the
> Debian keyrings.
Being one of those on the list, I'm even more confused than I'd be about
this anyway.
So those people you listed:
* Did they something wrong (although certainly with best intentions
ed in, but it should refuse them now that it has
switched to use sqv since 2.9.19 (2024-12), and the Debian archive
too for the .dsc and .changes signatures themselves since
<https://lists.debian.org/debian-devel-announce/2017/02/msg7.html>,
and while I had the notion that we had SHA-1 usag
Hi!
On Sun, 2025-03-23 at 18:46:37 -0400, Robert Edmonds wrote:
> Guillem Jover wrote:
> > Not all of these issues are equally "bad" from a Debian point of view,
> > but all are probably bad for the certificate owners, as it might imply
> > that people cannot ve
res, resurfaced an old
> known problem with OpenPGP certificates with SHA-1 issues in the
> Debian keyrings.
>
> Not all of these issues are equally "bad" from a Debian point of view,
> but all are probably bad for the certificate owners, as it might imply
> that p
Guillem Jover wrote...
> I'm happy to try to address anything that seems unclear, or get
> someone else who might be able to answer! And as Holger suggested
> elsewhere, we can probably also create a FAQ on the wiki with some of
> this to point to people.
Thanks for your explanations, things are
[I don't have enough time at present to fully drive this from a
keyring-maint PoV, but without any hats on I thought I'd add a couple of
extra bits of information.]
On Fri, Mar 21, 2025 at 01:11:20AM +0100, Guillem Jover wrote:
On Thu, 2025-03-20 at 22:00:04 +0100, Christoph Biedl wrote:
Bein
key»). Which should better match the terminology used for
> example with TLS/SSL certificates and keys.
> See <https://www.rfc-editor.org/rfc/rfc9580.html#name-terminology-changes>.
https://book.sequoia-pgp.org/bckgrnd_keys_certificates.html agrees.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
Hi!
On Thu, 2025-03-20 at 10:55:16 +0900, Charles Plessy wrote:
> sorry but I am confused... can you explain at a beginner level what is the
> difference between a certificate and a "key" in the sense it is used in the
> Developers Reference?
Ah, sorry, the OpenPGP working group and as part of th
> sorry but I am confused... can you explain at a beginner level what
> is the difference between a certificate and a "key" in the sense it
> is used in the Developers Reference?
A certificate is a key with a name attached to it. So in the case of
Debian developer's PGP
Hi Guillem,
sorry but I am confused... can you explain at a beginner level what is the
difference between a certificate and a "key" in the sense it is used in the
Developers Reference?
Have a nice day,
Charles
--
Charles Plessy Nagahama, Yomitan, Okinawa, Ja
Hi Sean,
Am Tue, Mar 11, 2025 at 10:01:06AM +0800 schrieb Sean Whitton:
> > As defined by our constitution (§6.2.2), the Debian Technical Committee
> > has recommended the appointment to the committee of:
> >
> > * Paul Tagliamonte
> >
> > I agree with thei
On 09.03.25 17:45, Marco d'Itri wrote:
On Mar 09, Matthias Urlichs wrote:
My "build me a Debian image" script has been doing that for two years now,
simply by moving /var/lib/dpkg to /usr/state/dpkg and bind-mounting it back
onto /var/lib/dpkg (symlinking won't work).
How
Hello,
On Mon 10 Mar 2025 at 06:54pm +01, Andreas Tille wrote:
> Dear fellow developers,
>
> As defined by our constitution (§6.2.2), the Debian Technical Committee
> has recommended the appointment to the committee of:
>
> * Paul Tagliamonte
>
> I agree with their re
On Mar 09, Matthias Urlichs wrote:
> My "build me a Debian image" script has been doing that for two years now,
> simply by moving /var/lib/dpkg to /usr/state/dpkg and bind-mounting it back
> onto /var/lib/dpkg (symlinking won't work).
How so? My /var/lib/dpkg has been a
On 06.03.25 11:25, Helmut Grohne wrote:
onger term, it shall become possible to install Debian in such a way that the
entire installation
lives below /usr (though it will not be possible to upgrade such an
installation due to the lack of /var/lib/dpkg in the initial
implementation).
My "
thout any of their users complaining about it,
> and I do not understand why it becomes a priority to change them now.
I didn't know about this. Please share some examples on
debian-policy@lists.d.o.
--
Sean Whitton
signature.asc
Description: PGP signature
* Charles Plessy [250227 10:12]:
> Le Thu, Feb 27, 2025 at 03:02:08PM +0800, Sean Whitton a écrit :
> >
> > Packages that already install programs to /usr/games, where another
> > package installs a program of the same with different functionality
> > to a different directory on the d
ng other improvements, since our time is limited).
>
> I also wonder if the cost of this policy will increase with time given
> that a) the number of existing software is increasing, b) the number of
> Debian packages is increasing, c) upstreams care less and less about
> co-instability beca
ing software is increasing, b) the number of
Debian packages is increasing, c) upstreams care less and less about
co-instability because of containers, conda namespaces etc.
Importantly, each time we rename a binary, we become incompatible with
third-party scripts, upstream documentation, *overflow
Am 20.02.25 um 11:13 schrieb Vincent Lefevre:
Hi,
On 2025-02-20 17:51:40 +0800, Sean Whitton wrote:
I just pushed version 4.7.1.0 of the Debian Policy Manual and related
documents to the binary-NEW queue for sid.
Below you will find the significant normative changes from the
previously
Hi,
On 2025-02-20 17:51:40 +0800, Sean Whitton wrote:
> I just pushed version 4.7.1.0 of the Debian Policy Manual and related
> documents to the binary-NEW queue for sid.
> Below you will find the significant normative changes from the
> previously-announced release of Pol
On Wednesday, February 12, 2025 10:51:13 AM MST Raphael Hertzog wrote:
> That sounds like what the "debian_pipeline" workflow can do in
> https://debusine.debian.net, except that it is able to do it on multiple
> architectures and also run reverse dependencies autopkgtest (however it
> doesn't supp
Hi,
On Tue, 11 Feb 2025, Kirill Rekhov wrote:
> I wrote a script called chroot-debianizer that automates routine tasks related
> to Debian package management. This tool is designed to facilitate a clean and
> isolated package building process in chroot environments specifically for th
Hi, Dear Debian Engineers.
I hope this message finds you well. Sorry for advertising my small project.
I use this script often when working with Debian packages.
I wrote a script called chroot-debianizer that automates routine tasks related
to Debian package management. This tool is designed to
Just as a PSA...
Abhijith PA dijo [Mon, Feb 10, 2025 at 07:56:39PM +0530]:
> Hi,
>
> This is a *reminder* call to submit Debian projects for GSoC25. The
> deadline for the same is Feb 11 1800 UTC. (roughly ~27 hours)
>
> == Proposing a Project ==
>
> Add your project id
> current
>> situation.
>
> There is also <https://bugs.debian.org/1031381>, and I started a
> discussion on this list with the stuff I think was collected as being
> unclear and worth improving or clarifying at [M], but AFAIR the driver
> of the DEP stated not having t
On Sun, 02 Feb 2025 at 14:18:53 -0300, Leo Historias wrote:
> As we know, I386 is dropped from Debian Ports starting with Trixie
i386 is not being dropped from Debian in trixie.
What *is* being dropped (has already been dropped) is the ability to
run i386 as a completely independent, boota
On Sun, Feb 02, 2025 at 11:23:33PM -0300, Leo Historias wrote:
> Oh god,I should clarify when i say that...
>
>
> They will drop support for it starting with Trixienot that it is no
> longer supported.
I'm not sure how is it different but this is also not what was planned.
--
WBR, wRAR
s
And yes,i mean the normal repo
Oh god,I should clarify when i say that...
They will drop support for it starting with Trixienot that it is no
longer supported.
On Sun, Feb 02, 2025 at 02:18:53PM -0300, Leo Historias wrote:
> As we know, I386 is dropped from Debian Ports starting with Trixie,
As we know it is not, even if by "Debian Ports" here you mean the normal
Debian archive.
--
WBR, wRAR
signature.asc
Description: PGP signature
As we know, I386 is dropped from Debian Ports starting with Trixie,
however due to the architecture's popularity, it should at least be moved
to Debian Ports, where it'll be maintained by the community
Will i386 be moved to Debian Ports if support ends for it?
scussion on this list with the stuff I think was collected as being
unclear and worth improving or clarifying at [M], but AFAIR the driver
of the DEP stated not having time to handle that work.
[M] https://lists.debian.org/debian-devel/2023/08/msg00067.html
> So I'm reporting this here again t
Hi,
On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote:
> But also, in this particular case, it's not the issue of the spec but of a
> particular tool trying to enforce the rule.
>
> I'll file a bug to fix it.
I finally found many reports already dealing with this issue in the bug tracker.
d DEP-3 syntax for this is:
> > > >
> > > > Bug: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378
> > > >
> > > > so using that instead of Bug-Upstream might help?
> > > >
> > > > My understanding is that the Bug- conven
>
> > > so using that instead of Bug-Upstream might help?
> > >
> > > My understanding is that the Bug- convention is intended
> > > for other downstreams, which might be Debian, a Debian derivative like
> > > Ubuntu, or sometimes an unrelated downst
On Sat, Feb 1, 2025 at 10:14 AM Abou Al Montacir wrote:
> With regards to other possible values (No, NotNeeded), I find it a bit hacky
> to use this field to provide an upstream bug URL.
> I would completely remove this practice and keep this field human readable
> and understandable to be a sim
s/41378
> >
> > I believe the intended DEP-3 syntax for this is:
> >
> > Bug: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378
> >
> > so using that instead of Bug-Upstream might help?
> >
> > My understanding is that the Bug- con
Bug-Upstream might help?
My understanding is that the Bug- convention is intended
for other downstreams, which might be Debian, a Debian derivative like
Ubuntu, or sometimes an unrelated downstream like Fedora that has provided
useful/relevant information in their record of the equivalent bug.
smcv
//gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378
>
> so using that instead of Bug-Upstream might help?
>
> My understanding is that the Bug- convention is intended
> for other downstreams, which might be Debian, a Debian derivative like
> Ubuntu, or sometimes an unrel
Hi Abou,
Quoting Abou Al Montacir (2025-02-01 13:13:32)
> According
> to https://udd.debian.org/patches.cgi?src=lazarus&version=3.8%2Bdfsg1-4 my
> package have a patch with invalid metadata. There seem to be that the tool
> considers the following as an error:
> Forwarded: Yes
> Bug-Upstream: http
Hi All,
According
to https://udd.debian.org/patches.cgi?src=lazarus&version=3.8%2Bdfsg1-4 my
package have a patch with invalid metadata. There seem to be that the tool
considers the following as an error:
Forwarded: Yes
Bug-Upstream: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41378
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello dear engineers.
I have prepared some new packages for Debian, would you be interested?
These packages have been verified and have the confirmed tags.
1. vifm
RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093235
https
On Thu Jan 23, 2025 at 2:28 PM GMT, Matthew Vernon wrote:
I'd much much rather MRs were associated with bug reports; that way I
only have to remember to check one place for outstanding issues in my
packages, and years down the line when I wonder "why did this change get
made" I can look up the bu
On Fri Jan 24, 2025 at 11:22 AM GMT, Johannes Schauer Marin Rodrigues wrote:
I'm likely in lack of understanding here but I have not yet understood
the utility of merge commits. You say that they could be useful to
attach git notes to it. But can these notes not also attached to
regular commits
Quoting Andreas Tille (2025-01-29 15:06:15)
> Am Sun, Jan 26, 2025 at 01:06:00AM +0100 schrieb gregor herrmann:
> > The alternative -- and that's what we did in pkg-perl -- is to have
> > the Janitor just commit to our repos instead of filing merge
> > requests:
> > https://salsa.debian.org/janitor
Am Sun, Jan 26, 2025 at 01:06:00AM +0100 schrieb gregor herrmann:
> The alternative -- and that's what we did in pkg-perl -- is to have
> the Janitor just commit to our repos instead of filing merge
> requests:
> https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf
On Thu, 2025-01-23 at 17:06:04 -0800, Otto Kekäläinen wrote:
> Current https://dep-team.pages.debian.net/deps/dep14/ states that the
> default Debian branch name is 'debian/latest':
>
> > In Debian this means that uploads to unstable and experimental should be
>
s, and others not familiar with the project should be making
> > changes.
>
> From https://dep-team.pages.debian.net/deps/dep14/:
>
> > [Packaging branches and tags] NOTE: If the Git repository listed in
> > debian/control's Vcs-Git field does not indicate an explici
you to use debian/unstable and
debian/experimental if you want.
As has already been mentioned earlier in this thread, the Debian GNOME
renamed all our branches from debian/master to debian/latest a year
and a half ago.
And for our specific workflow, using debian/latest (or debian/master
befo
The "For development releases" section should say that
> the branch for uploads to the current development release of the
> furthest-upstream distribution handled in a given repository (typically
> Debian) should be the default branch, as pointed to by the HEAD
> reference.
T
//dep-team.pages.debian.net/deps/dep14/:
[Packaging branches and tags] NOTE: If the Git repository listed in
debian/control's Vcs-Git field does not indicate an explicit branch
(with the -b suffix) then it should have its HEAD point to
the branch where new upstream versions are being packaged (that is
one of th
* Otto Kekäläinen [250128 00:04]:
> I wrote and rewrote this script a couple of times in past two months:
> https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/dep-14-convert-git-branch-names.sh
>
> It's not exactly ideal yet, but it does the job. The name is a bit
Hi!
On Mon, 2025-01-27 at 06:28:59 -0600, G. Branden Robinson wrote:
> At 2025-01-27T12:27:12+0100, IOhannes m zmölnig (Debian GNU|Linux) wrote:
> > as for the original subject of this thread: what's actually wrong with
> > 'debian/main' instead of 'debian/l
On Tue, Jan 28, 2025 at 12:50:43PM +0100, Guillem Jover wrote:
> > I'd point out that "debian/main" also refers to the part of the Debian
> > package archive that is not "contrib" or "non-free".
> > I therefore perceive "debian/main" a
* Charles Plessy [250128 01:44]:
> Hello everybody,
>
> How about debian/default or debian/devel?
Yes please do a few more changes to the names, so everybody can pick
whatever they like ("it was fine back then"), and everone who went
under a painful migration to the curren
On 1/28/25 05:11, Johannes Schauer Marin Rodrigues wrote:
https://salsa.debian.org/debian/devscripts/-/merge_requests/427
yes!
(i guess)
fmasdr
IOhannes
OpenPGP_0xB65019C47F7A36F8.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Migrating thousands (in the case of pkg-perl) repos both remote/on
> salsa and locally (for dozens of team members) is not trivial, and
> AFAIK noone so far has come up with working tooling.
I wrote and rewrote this script a couple of times in past two months:
https://salsa.debian.org/debi
Quoting IOhannes m zmölnig (Debian GNU|Linux) (2025-01-27 12:27:12)
> On 1/26/25 01:10, gregor herrmann wrote:
> > Yes, and more importantly:
> >> - because it is not easy and fast to migrate and if you do it you have to
> >> redo the local repository, if you are alone w
Hello everybody,
How about debian/default or debian/devel?
The good thing with these names is that they are friendly to
tab-completion, as the finger on the letter d does not have to move.
Have a nice day,
--
Charles
On 1/27/25 13:28, G. Branden Robinson wrote:
At 2025-01-27T12:27:12+0100, IOhannes m zmölnig (Debian GNU|Linux) wrote:
as for the original subject of this thread: what's actually wrong with
'debian/main' instead of 'debian/latest'? i personally do not really
care, and
At 2025-01-27T12:27:12+0100, IOhannes m zmölnig (Debian GNU|Linux) wrote:
> as for the original subject of this thread: what's actually wrong with
> 'debian/main' instead of 'debian/latest'? i personally do not really
> care, and can live with whatever is decided
On 1/26/25 01:10, gregor herrmann wrote:
On Fri, 24 Jan 2025 12:22:20 +0100, Fabio Fantoni wrote:
Il 24/01/2025 02:06, Otto Kekäläinen ha scritto:
Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?
I thi
ompared to the released version. I tried to
>> manually incorporate those changes, and only later found out that the
>> actual latest branch is "debian/sid" and it did have everything
>> up-to-date. (Note that this has since been fixed[1]). I think for new
>&g
On Fri, Jan 24, 2025 at 04:31:57PM -0800, Xiyue Deng wrote:
> tho...@goirand.fr writes:
> > What you experience shows one thing: having the default branch being
> > set correctly should be what we mandate.
>
> Indeed. Though IIRC the default branch was not a native git concept
> until 2.28, so us
; manually incorporate those changes, and only later found out that the
> actual latest branch is "debian/sid" and it did have everything
> up-to-date. (Note that this has since been fixed[1]). I think for new
> repository, standardizing on a name (either "debian/latest" or
uot; upstream final release, and 24.8.x is not :)
DEP-14 has naming schemes for two reasonable workflows, and I think a
lot of criticisms of it are assuming that one of them is the only one
and disregarding the other.
In the GNOME team we use debian/latest (the default branch in the git
repo)
a debian/experimental and merge it back late..)
Stuff which is in development upstream or in experimental exists, even if it is
not in master.
Sometimes it's the version where stuff happens - like in freeze time where all
stuff happens there since sid is (basically) frozen for anythin
5785 (and counting) branches of https://github.com/JetBrains/kotlin/
> to its packaging repository? For the record, it's a 4 GiB download, and
> it makes some tools crash. There are probably even worse examples in the
> wild.
I think Phil meant by 'all branches' here both the Debia
Hi Rene,
> What should debian/latest be? The latest upstream (pre-)release? Aka what is
> in experimental? Or not even there,
> just preparing stuff for experimental?
This is a good question, as it goes to the core of why DEP-14
recommends debian/latest first, respectively in t
On Fri, 24 Jan 2025 12:22:20 +0100, Fabio Fantoni wrote:
> Il 24/01/2025 02:06, Otto Kekäläinen ha scritto:
> > Why does the majority of Debian packages still use 'master' or
> > 'debian/master' branch as the main development branch?
> I think:
> - beca
1 - 100 of 1416 matches
Mail list logo
