Re: Bug#1053165: ITS: nunit

[Andreas Ronnquist]

On Thu, 28 Sep 2023 17:22:20 +0200,
Bastian Germann wrote:

>Okay. What do you suggest for "team maintained" packages where there is no 
>active team member?
>File MIA processes for each of the uploaders? And then? The MIA team's bugs 
>are not RC bugs,
>so you cannot even NMU them based on the MIA bug.
>
>I think, just letting such packages rot for one or two decades does not help 
>anybody, certainly not our users.
>

I interpret it as you can NMU even if it doesn't fix RC bugs, see
devref 5.11.1:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus

Different delays for "only release-critical" in combination with
important bugs - and then "Other NMUs: 10 days" - which to my
interpretation also means fixing non-RC bugs.

Of course you should always give the maintainer a chance to react though.

-- Andreas Rönnquist
mailingli...@gusnan.se
andr...@ronnquist.net

Re: Embedded buildpath via rpath using cmake

[Andreas Ronnquist]

On Thu, 03 Feb 2022 16:41:21 -0800,
Vagrant Cascadian wrote:
>
>I've attached a list of the maintainers of affected packages produced
>with dd-list, getting the list of packages from the above-mentioned
>reproducible builds issue and diff.dcsr.txt from archive rebuild.
>
>If you're on the list, would love if you could check if your package
>still builds correctly when passing only
>-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON.  For a few of the packages, there
>are already patches in the Debian bug tracking system waiting for you!
>

allegro5 builds fine here when adding -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON.

-- Andreas Rönnquist
mailingli...@gusnan.se
gus...@debian.org


pgpNZ3VqoXFHr.pgp
Description: OpenPGP digital signatur

Re: Switch to DEP-14-ish with an existing "debian" branch

[Andreas Ronnquist]

On Mon, 4 Feb 2019 15:07:22 +0200,
Peter Pentchev wrote:

>Hi,
>
>So these days I decided that DEP-14[1] actually seems to be a Good
>Thing(tm) and I started thinking about switching my packages' Git
>repositories to this layout.  However, I immediately hit a snag:
>in some of my repositories the upstream branch is named "master" and
>the Debian packaging branch is named "debian".  Due to a (somewhat
>understandable, even though a leaky abstraction) limitation of Git,
>I cannot create a "debian/master" branch if there already is a "debian"
>branch in the repository.
>
>Have others come across this when migrating Debian packaging repos to
>a DEP-14 layout?  How do you deal with this?
>
>I'm thinking of prefixing the new branches with, say, "pkg/", so that
>there would be a DEP-14-ish layout with the upstream branch being
>named "master", the main Debian branch being "pkg/debian/master",
>backports in "pkg/debian/buster", "pkg/debian/stretch", etc, and
>similarly Ubuntu packaging in "pkg/ubuntu/master", "pkg/ubuntu/bionic",
>etc.  Does this sound reasonable, or have other people already done
>something similar and adopted a prefix other than "pkg/"?
>
>Thanks to the people who came up with the idea of a harmonized layout
>of Debian packaging repositories and then did the work of writing up
>the DEP itself!  And, yeah, well, does what I'm trying to do feel like
>de-harmonizing the layout by introducing Yet Another Branch Naming
>Scheme? :)  If so, sorry! :)
>
>G'luck,
>Peter
>
>[1] https://dep-team.pages.debian.net/deps/dep14/
>

Try

git branch -m debian debian/master

which will rename the branch locally - then you should be able to
remove the remote branch, and then simply push the branch with the
new name to the remote.

Remember that you'll need proper permissions on salsa to remove
branches. (See Settings/Repository) - and you should also change Default
Branch there.

-- Andreas Rönnquist
mailingli...@gusnan.se
gus...@debian.org


pgpT5903FfToW.pgp
Description: OpenPGP digital signatur

Re: Removing packages perhaps too aggressively?

[Andreas Ronnquist]

On Wed, 31 Jan 2018 20:14:31 +0100,
Andrej Shadura wrote:

>Hi everyone,
>
>It has happened to me in the recent years quite a few times that a
>package which I was using has a RoQA bug filed against it, and the
>package's got removed at a very short notice.
>
>For example, in #616376, gbdfed was removed because "low popcon,
>orphaned". It took just one day to remove it, with no discussion at
>all. Orphaned is *not* a bug. Orphaned doesn't mean the package has no
>users. Maybe the package works for them just fine, and they're happy.
>Should I've known someone's going to remove it, I would have adopted
>it earlier.
>
>Today, hyde. I worked on a new release of the package in July, leaving
>a couple of things to be polished when I find more time. Today, I
>needed to use the package, so I thought, oh, let me adopt and upload
>the package. Here you go, there's #871004 for you. Missed jessie,
>stretch, not in testing, no uploads since the beginning of 2017. Filed
>on 06 Aug 2017, removed 10 Sep 2017. Fair enough, the notice was on
>display for a whole month. In a place resembling a locked filing
>cabinet stuck in a disused lavatory with a sign on the door saying
>‘Beware of the Leopard’.
>

Isn't this rather publicly announced by the how-can-i-help program? I
am running apt, and after each apt run I get a little report for
how-can-i-help if some of my installed packages are orphaned or in risk
of being removed.

I don't know if this isn't the case if you are using apt-get or
aptitude though.

-- Andreas Rönnquist
mailingli...@gusnan.se
andr...@ronnquist.net
gus...@debian.org