Johannes Schauer Marin Rodrigues writes:
> I would be *very* interested in more in-depth write-ups of the workflows
> other DDs prefer to use, how they use them and what they think makes
> them better than the alternatives.
> Personally, I start packaging something without git, once I'm satisfie
My standard workflow
I use gbp and dgit
gbp import-orig --pristine-tar --uscan
gbp dch
lintian-brush
dgit --gbp sbuild (build and autopkgtest)
...work until it is ok on my computer
gbp dch
... hand edit the changelog
gbp push
git push (to push the UNRELEASE master branch)
... wait for salsa resu
On Wed, May 22, 2024 at 12:32:32AM +0200, Salvo Tomaselli wrote:
> And what's the advantage? When an nmu happens the person doing it normally
> doesn't bother to push to salsa anyway.
Yes, because it's unfortunately too expensive to:
- make sure the repo exists and is uptodate
- somehow find out
Hi Stefano,
Am Tue, May 21, 2024 at 02:36:47PM + schrieb Stefano Rivera:
> Hi Philip (2024.05.21_10:05:59_+)
> > Attempts at top-down imposition of new methods on Debian strike me as
> > being unlikely to induce joy in anyone involved.
>
> Yeah, that doesn't fly in community projects like
Am Wed, May 22, 2024 at 12:32:32AM +0200 schrieb Salvo Tomaselli:
>
> And what's the advantage? When an nmu happens the person doing it normally
> doesn't bother to push to salsa anyway. At most I get a patch in the
> bugreport, or I have to diff the packages and import the diff.
IMHO this is a
Quoting Luca Boccassi (2024-05-22 01:45:54)
> On Wed, 22 May 2024 at 00:40, Russ Allbery wrote:
> > For what it's worth, what I do for the packages for which I'm also
> > upstream is that I just add Salsa as another remote and, after I upload
> > a new version of the Debian package, I push to Sals
Quoting Bernd Zeimetz (2024-05-21 00:54:07)
> On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues
> wrote:
> > Quoting Andreas Tille (2024-04-10 22:44:25)
> > > > I do understand the argument that lots of different workflows
> > > > adds
> > > > friction. But I'm just still using wh
On Wed, 22 May 2024 at 00:40, Russ Allbery wrote:
>
> Salvo Tomaselli writes:
>
> > If the debian/ directory is on salsa, but the rest of the project is
> > somewhere else, then this no longer works, I have to tag in 2 different
> > places, I have 2 different repositories to push to and so on.
>
Salvo Tomaselli writes:
> If the debian/ directory is on salsa, but the rest of the project is
> somewhere else, then this no longer works, I have to tag in 2 different
> places, I have 2 different repositories to push to and so on.
For what it's worth, what I do for the packages for which I'm a
On Tue, 2024-05-21 at 09:11 -0600, Sam Hartman wrote:
> > > > > > "Otto" == Otto Kekäläinen writes:
> Otto> Would you be kind and try to understand the opposing
> viewpoint
> Otto> by trying it for one day?
>
> Otto> You could go to
> Otto>
> https://salsa.debian.org/debbugs-team/
On Tue, 2024-05-21 at 12:05 +0200, Philip Hands wrote:
>
> For anyone with an opinion, I'd suggest that you should try to make
> sure
> that DEP-14 reflects your opinion, and then work on getting people to
> adopt the use of DEP-14 and/or get DEP-14 accepted.
>
To be honest: in my opinion the wh
On Tue, 2024-05-21 at 15:50 +0200, Salvo Tomaselli wrote:
> > Do you think that mandating Salsa is a sensible step in this
> > direction?
>
> No. It would increase my workload for all the stuff where I am also
> upstream.
Could you explain that? I do similar things (just that not everything
of it
Hi!
On Sun, 19 May 2024 at 20:48, Don Armstrong wrote:
>
> On Sun, 19 May 2024, Bill Allombert wrote:
> > Also debbugs is a special case:
> > The debbugs Debian package (as opposed to the debbugs software) have never
> > been
> > really maintained. I am actually one of the very few users of this
On Tue, May 21, 2024 at 06:13:21PM +0200, Andrej Shadura wrote:
> In fact, having checked the source code, it’s one way only, and after
> all it’s also someone else’s quick hack. Maybe someone should write
> a robust tool to support all formats and directions and package *that*
> for Debian? :)
I
Stefano Rivera writes:
> On the other hand, dgit is only useful if you have a certain view of the
> world, that hasn't aligned with how I've done Debian packaging. I mean,
> an entirely git-centric view where you let go of trying to maintain your
> patch stack.
dgit has no problems with you main
Hi again,
On Tue, 21 May 2024, at 17:59, Andrej Shadura wrote:
> On Tue, 21 May 2024, at 17:17, Facundo Gaich wrote:
>> Well I ended packaging this, it's waiting in debcargo-conf at
>> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653
>
> If the Rust impl of toml2json works be
Hello,
Tomas Pospisek, le mar. 21 mai 2024 17:22:47 +0200, a ecrit:
> > > Quoting Victor Gamper (2024-05-17 21:58:58)
> > > For i386 there is a severe lack of person-power. Do you want to start
> > > contributing your free-time for several years to come to d-i and
> > > other areas
> > > which are
Hi,
On Tue, 21 May 2024, at 17:17, Facundo Gaich wrote:
> On Thu, Feb 22, 2024 at 1:39 PM Jonas Smedegaard wrote:
>> Quoting Facundo Gaich (2024-02-22 17:12:22)
>> > I can work on packaging this if you're still interested, I'd need a
>> > sponsor.
>> >
>> > I've already done some preliminary wo
Hi Maite, hi Rhys,
don't top-post. That breaks the flow of the arguments being argued about.
*From:* Johannes Schauer Marin Rodrigues
*Sent:* Friday, May 17, 2024 15:48
*To:* Victor Gamper; debian-devel@lists.debian.org
*Subject:* Re: About i386 support
Quoting Victor Gamper (2024-05-17 21:5
Package: wnpp
Severity: wishlist
Owner: Edward Betts
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: bluetooth-sensor-state-data
Version : 1.6.2
Upstream Author : J. Nick Koston
* URL :
https://github.com/bluetooth-devices/
Control: retitle -1 ITP: rust-toml2json -- A very small CLI for converting
TOML to JSON
Control: owner -1 !
Well I ended packaging this, it's waiting in debcargo-conf at
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/653
Best,
Facundo
On Thu, Feb 22, 2024 at 1:39 PM Jonas Smed
> "Otto" == Otto Kekäläinen writes:
Otto> Would you be kind and try to understand the opposing viewpoint
Otto> by trying it for one day?
Otto> You could go to
Otto> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
Otto> and conduct a code review?
I have n
Hi Philip (2024.05.21_10:05:59_+)
> Attempts at top-down imposition of new methods on Debian strike me as
> being unlikely to induce joy in anyone involved.
Yeah, that doesn't fly in community projects like Debian at all.
However, there is a gap between getting a DEP approved and getting the
PICCA Frederic-Emmanuel:
I tried it on one of my package silx
warning: File: ./debian/tests/control:22:14:22:19: It is possible that the value is a
typo of "i386". [Correctable via --auto-fix]
22: Architecture: !i386
It seems wrong to me, the test control file allow !i386
Cheers
Frederi
On Tue, 21 May 2024 at 14:13, Andrey Rakhmatullin wrote:
>
> On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> > Hi,
> >
> > On 5/21/24 15:54, Andrey Rakhmatullin wrote:
> >
> > > > The Debian archive itself is a VCS, so git-maintained packaging is also
> > > > a
> > > > duplicatio
Andreas Tille:
Hi Niels,
at first sorry for my late answer.
At Thu, May 09, 2024 Niels Thykier wrote:
[...] >> For me, lintian fails in all roles it has. It is not a good tool for
newbies
to get help, since it can only test build artifacts. As an example, your
feedback look is a full packag
On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> The Debian archive itself is a VCS, so git-maintained packaging is also a
> duplication, and keeping the official VCS and git synchronized is causing
> additional work for developers, which is why people are opposed to having it
> man
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: nemo-qml-plugin-contacts
Version : 0.3.28
Upstream Contact: https://sailfishos.org/contact/
* URL : https://github.com/sailfishos/nemo-qml-plugin-contacts.g
I tried it on one of my package silx
warning: File: ./debian/tests/control:22:14:22:19: It is possible that the
value is a typo of "i386". [Correctable via --auto-fix]
22: Architecture: !i386
It seems wrong to me, the test control file allow !i386
Cheers
Frederic
On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> Hi,
>
> On 5/21/24 15:54, Andrey Rakhmatullin wrote:
>
> > > The Debian archive itself is a VCS, so git-maintained packaging is also a
> > > duplication, and keeping the official VCS and git synchronized is causing
> > > additional
Hi,
On 5/21/24 15:54, Andrey Rakhmatullin wrote:
The Debian archive itself is a VCS, so git-maintained packaging is also a
duplication, and keeping the official VCS and git synchronized is causing
additional work for developers, which is why people are opposed to having it
mandated.
The Debi
On Mon, May 20, 2024 at 01:00:00PM -0700, Otto Kekäläinen wrote:
> Regarding this discussion in general, I get the sense that
> participants haven't actually tried Debputy and are not aware of its
> capabilities. If you have Podman/Docker you can effortlessly run this
> little check to get some exp
Hello,
On Sun 19 May 2024 at 10:05am +02, Paul Gevers wrote:
>
> PS: I've always wondered if the dgit server shouldn't track history, even if
> uploads don't happen via it. A dgit clone could (should?) already provide
> available history, even if no upload happened via it yet.
Well, 'dgit clone'
Hello,
On Sun 19 May 2024 at 12:32pm -07, Otto Kekäläinen wrote:
> You could go to
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
> conduct a code review?
>
> You might discover that GitLab is useful and is not duplicating
> Debbugs or anything else in Debian - it is curr
On Tue, May 21, 2024 at 12:05:59PM +0200, Philip Hands wrote:
> >> > All these things should make it much more easy for other people or
> >> > automated tools to send merge requests or keep maintaining a
> >> > package in
> >> > case the original maintainer becomes MIA.
> >>
> >>
> >> Mandating a
On Mon, 20 May 2024 at 19:10:00 -0700, Otto Kekäläinen wrote:
> Exact quote: "These commits have intentionally no debian/changelog
> updates as it causes every single rebase or cherry-pick of a commit to
> always have a merge conflict. It is much better to have all commits
> as-is, and then right b
On Tue, 21 May 2024 at 03:16, Simon Richter wrote:
>
> Hi,
>
> On 5/21/24 10:43, Luca Boccassi wrote:
>
> >> The ecosystem, however, does not support our workflows, and adapting it
> >> to do that is even more effort than maintaining our own tools. [...]
>
> > That's a problem of our workflows, wh
Bernd Zeimetz writes:
> On Mon, 2024-05-20 at 20:47 +, Scott Kitterman wrote:
>> >
>> > All these things should make it much more easy for other people or
>> > automated tools to send merge requests or keep maintaining a
>> > package in
>> > case the original maintainer becomes MIA.
>>
>>
Andrey,
On Tue, May 21, 2024 at 3:31 AM Andrey Rakhmatullin wrote:
>
> On Mon, May 20, 2024 at 07:16:54PM -0300, Leandro Cunha wrote:
> > > > > which is good news. The end of support for 32 bits will not
> > > > > affect the lives of almost anyone who has machines purchased after
> > > > > 2011 a
39 matches
Mail list logo
