Re: Removing more packages from unstable

[Andreas Metzler]

On 2024-08-20 Helmut Grohne  wrote:
> Hi fellow developers,

> (modified resend, as first attempt didn't arrive)

> please allow me to open a can of worms. Package removal from unstable.
> Deciding when it is time to remove a package from unstable is difficult.
> There may be users still and it is unclear whether keeping the package
> imposes a cost. In this mail I want to argue for more aggressive package
> removal and seek consensus on a way forward.

+1

> What does a package cost?

> There are various QA-related teams looking at packages from other
[ a lot]

I always notice this whenever I make a pretty minor transition, about
half the packages I have to deal with are of dubious usefulness and
quite unmaintainted.

[...]
> mixer.app
[...]

On one hand I am proud that I managed to remove it early from testing
OTOH I should have had it removed from sid years ago. Bug filed now.

cu Andreas

Re: Vendoring an unmaintained library?

[Andreas Metzler]

On 2024-07-03 Alexandre Rossi  wrote:
[...]
> #1073005 asks for the vendoring back of an unvendored library, arguing
> that this particular library is unmaintained upstream, implying that the
> vendored fork is better maintained.

> My view on this is that if the vendored fork is better maintained, the
> vendored fork should become the upstream of the Debian package.
[...]

FWIW both FreeBSD and Gentoo have switched to the suggested fork (last
commit 2020), while the original source on sf is quite dead (last change
2013).

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: autoconf 2.72 to unstable?

[Andreas Metzler]

On 2024-06-14 Gürkan Myczko  wrote:
[...]
> Have never done mass bug filings, any easy way, preferably something copy
> pastable,
> non-interactive.

Hej,

How about mass-bug(1) in devscripts?

cu Andreas

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andreas Metzler]

On 2024-05-29 Marco d'Itri  wrote:
> On May 28, Andreas Metzler  wrote:

>> I think it is bad choice to deliberately have different behavior for
>> freshly installed and upgraded systems. Offering upgrades has always
>> been one of the major selling points of Debian, and imho this
>> implicitely includes that you do not get a worse or second class Debian
>> installation when you upgrade it than if you installed from scratch.

> I strongly disagree: it is a bad choice to change on upgrades a default 
> which may cause data loss.

Hello,

That is false dichotomy. data-loss will occur when people use /tmp or
/var/tmp for persistent data-storage because "This has (for a couple of
years) worked on Debian systems" not because "This has (for a couple of
years) worked on *this* *specific* Debian system.".

cu Andreas

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andreas Metzler]

On 2024-05-28 Luca Boccassi  
wrote:
[...]
> - existing installations pre-trixie will get an orphaned tmpfiles.d in
> /etc/ that keeps the existing behaviour unchanged (no cleanup of
> /var/tmp)
[...]

Hello,

I think it is bad choice to deliberately have different behavior for
freshly installed and upgraded systems. Offering upgrades has always
been one of the major selling points of Debian, and imho this
implicitely includes that you do not get a worse or second class Debian
installation when you upgrade it than if you installed from scratch.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Status of the t64 transition

[Andreas Metzler]

On 2024-04-18 Sebastian Ramacher  wrote:
[...]
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
>  * are BD-Uninstallabe,
>  * FTBFS but with out ftbfs-tagged RC bug,
>  * have hard-coded dependencies on pre-t64 libraries,
>  * have $oldlib | $newlib dependencies (those are at least wrong on
>armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are
>decrufted),
>  * have been rebuilt before all dependencies were built,
>  * have broken symbols/shlibs files producing incorrect dependencies,
>  * or might just be missing the binNMU (but those should be few).

> hugin
[...]

Good morning,

thanks for the update.

Looking at hugin, I think it is fine on all release-architectures, none
of the problems noted above apply here. Am I missing something?

TIA, cu Andreas

PS: fakeroot seems to be an important blocker not in the list.

Re: Some t64 libraries already in testing; I'm confused

[Andreas Metzler]

On 2024-03-31 Andreas Metzler  wrote:
[...]
> Afaict these are broken, though:
[...]
> tnat64 0.06-1

false positive, grep error.

Re: Some t64 libraries already in testing; I'm confused

[Andreas Metzler]

On 2024-03-31 Andreas Metzler  wrote:
> On 2024-03-31 Sven Joachim  wrote:
[...]
>> Unfortunately the other four are not similar, but rather lacked a build
>> dependency on dpkg-dev (>= 1.22.5) which would have prevented their
>> migration to testing.  Testing users on armel and armhf should avoid
>> installing them and downgrade to the pre-t64 version if necessary.

> All of those noted above except udns have already been fixed in sid.

Afaict these are broken, though:

cpdb-libs 2.0~b5-1.2
dante 1.4.3+dfsg-1
fuse 2.9.9-8.1
gambc 4.9.3-1.3
hdf5 1.10.10+repack-3.3
libdmapsharing 3.9.13-2
libgom 0.4-3
libgweather4 4.4.2-1
libgxps 0.3.2-4
libhinawa 4.0.1-2.2
llvm-toolchain-15 1:15.0.7-14
llvm-toolchain-16 1:16.0.6-24
llvm-toolchain-17 1:17.0.6-9
lomiri-ui-toolkit 1.3.5100+dfsg-1
ogre-1.12 1.12.10+dfsg2-6
pacman-package-manager 6.0.2-6
pangomm2.48 2.52.0-1
tnat64 0.06-1
udns 0.5-1
vte 1:0.28.2-6.1

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Some t64 libraries already in testing; I'm confused

[Andreas Metzler]

On 2024-03-31 Sven Joachim  wrote:
> On 2024-03-31 06:54 +0200, Andreas Metzler wrote:
> > On 2024-03-30 Julian Gilbey  wrote:
[...]
> >> Looking through testing, I see the following t64 libraries present:

> >> libaio1t64
> >> libfyba0t64
> >> libglibmm-2.68-1t64
> >> libnetcdf19t64
> >> libudns0t64
> >> libczmq4t64 (virtual package; libczmq4 provides this)

> > I have not checked all the others (libczmq4: "Undo 4.2.1-1.1. There are
> > only 3 symbols with time_t, and they are not used in the distribution.
> > Avoid to carry the package rename forever."), but suspect they are
> > similar.

> Unfortunately the other four are not similar, but rather lacked a build
> dependency on dpkg-dev (>= 1.22.5) which would have prevented their
> migration to testing.  Testing users on armel and armhf should avoid
> installing them and downgrade to the pre-t64 version if necessary.

All of those noted above except udns have already been fixed in sid.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Some t64 libraries already in testing; I'm confused

[Andreas Metzler]

On 2024-03-30 Julian Gilbey  wrote:
> My very limited understanding of this major transition was that the
> t64 libraries are being held in unstable until (almost) everything is
> ready, at which point there will be a coordinated migration into
> testing.  But I've now been asked to upgrade something on my testing
> machine which pulls in a t64 library.  Has something slipped through
> the net, or is this intentional?

> Looking through testing, I see the following t64 libraries present:

> libaio1t64
> libfyba0t64
> libglibmm-2.68-1t64
> libnetcdf19t64
> libudns0t64
> libczmq4t64 (virtual package; libczmq4 provides this)

Good morning,

I also stumbled over libaio1t64 and looked at the changelog. It is not
part of the transition in that it was simply rebuilt with different
compiler flags and therefore broke the ABI. Instead source code changes
were made to extend the ABI to support usage both from code built with
t64 flags and without.

I have not checked all the others (libczmq4: "Undo 4.2.1-1.1. There are
only 3 symbols with time_t, and they are not used in the distribution.
Avoid to carry the package rename forever."), but suspect they are
similar.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: xz backdoor

[Andreas Metzler]

On 2024-03-31 Wookey  wrote:
[...]
> e.g. I remember it took me years to realise that I used _my_ public
> key for signing,
[...]

Good morning,

s/public/private/ - $recipient can then use your public key to verify
the sig.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Debian testing/unstable users: beware of Firefox critical CVEs

[Andreas Metzler]

On 2024-03-24 Samuel Henrique  wrote:
> Hello everyone,

> Given our current time_t transition happening, which means packages
> are blocked from migrating to testing for weeks, and that unstable
> updates have become harder to apply, two critical CVE fixes for
> Firefox became impossible to get it through the official repositories:
[...]
> I hope this is useful to those who are not aware of the issue yet.

Good morning,

Thanks for the heads-up. For my personal use I have simply rebuilt the
sid package on trixie. However trying fix these kind of issues by
rebuilding locally obviously does not scale, I will probably upgrade to
unstable in due course.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: dpkg --verify not helpful?

[Andreas Metzler]

On 2024-03-02 Sven Joachim  wrote:
> On 2024-03-02 08:47 +0100, Sven Joachim wrote:
>> On 2024-03-02 08:01 +0100, Andreas Metzler wrote:

>>> iirc it was recently proposed to add a suggestion to run dpkg --verify
>>> to the trixie upgrade notes to find missing files due to the usr-merge
>>> transition. (Cannot find the reference right now).

>>> However I just had file loss (due to libuuid changing its name to t64
>>> and back again) and dpkg --verify (and --audit) is happy:
[...]
>> The libuuid1t64 package has an unversioned Replaces: on libuuid1, so the
>> missing files belong to it.  If you remove libuuid1t64, the files are
>> gone and libuuid1 needs to be reinstalled.

>> The libuuid1 package should do something to prevent that file loss,
>> e.g. declaring its own Replaces+Conflicts on libuuid1t64.

> Filed bug #1065242 for that problem.  Thanks for noticing and bringing
> up the issue.

Hello,

thank you for the diagnosis and following up on fixing this.

FWIW

cd / && find  /var/lib/dpkg/info -name '*.md5sums' -exec md5sum --check --quiet 
{} +

can be used to doublecheck for files that are missing even if dpkg
--verify does not consider this to be a problem due to replaces.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

dpkg --verify not helpful?

[Andreas Metzler]

Hello,

iirc it was recently proposed to add a suggestion to run dpkg --verify
to the trixie upgrade notes to find missing files due to the usr-merge
transition. (Cannot find the reference right now).

However I just had file loss (due to libuuid changing its name to t64
and back again) and dpkg --verify (and --audit) is happy:
(sid)ametzler@argenau:/tmp$ ldd -r /usr/lib/x86_64-linux-gnu/libSM.so.6 | grep 
not
libuuid.so.1 => not found
(sid)ametzler@argenau:/tmp$ dpkg -s libuuid1
Package: libuuid1
Status: install ok installed
[...]
Version: 2.39.3-7
(sid)ametzler@argenau:/tmp$ dpkg --verify libuuid1 && echo success
success
(sid)ametzler@argenau:/tmp$ dpkg -L libuuid1 | grep /lib/
/usr/lib/x86_64-linux-gnu
(sid)ametzler@argenau:/tmp$ grep /lib/ /var/lib/dpkg/info/libuui
d1\:amd64.list
/usr/lib/x86_64-linux-gnu
(sid)ametzler@argenau:/tmp$ dpkg --contents 
/var/cache/apt/archives/libuuid1_2.39.3-7_amd64.deb |  grep '\.so'
-rw-r--r-- root/root 34872 2024-03-01 10:20 
./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0
lrwxrwxrwx root/root 0 2024-03-01 10:20 
./usr/lib/x86_64-linux-gnu/libuuid.so.1 -> libuuid.so.1.3.0

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: time_t and backports

[Andreas Metzler]

On 2024-02-26 John Goerzen  wrote:
> Hi folks,

> As a person that frequently uploads to bookworm-backports, I am
> wondering how we are handling the time_t transition there?

> The picture of synchronization with testing is a little complicated over
> there.  If you change the default build flags, you produce unexpected
> surprises over bookworm.  If you don't, the t64 packages aren't really
> t64.

Hello,

Imho you would need to undo the t64 rename for bpo instead of fiddling
with buildflags. We needed a transition because the whole distribution
needs to be built consistently with (or without) t64.  bookworm is built
without.

If you backported a libfoo3 which had replaced libfoo2t64 things will
get complicated, it would be necessary to upload as libfoo3t32 but the
tooling (${t32:Provides} does not exist.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Confusion over t64 migration

[Andreas Metzler]

On 2024-02-09 John Goerzen  wrote:
[...]
> So at the moment, I am unclear why there are bugs filed with severity
> serious that apparently cannot be fixed.  Shouldn't they be normal with
> a tag wontfix until the relevant dpkg changes are in unstable?

> To put it another way, I'm not seeing why we are reporting RC bugs
> against a bunch of packages before it is possible to fix them.
[...]

Hello John,

Afaiui the transition has been delayed unexpectly. (#1063329). I *think*
the priority was also chosen as signal to avoid unstable uploads for the
already staged packages. Stuff should have happened quickly, before we
entered the autoremoval timer.

Looking at "your" bug #1062097 it looks like you were unlucky, mine all
had a fat warning "NOTICE: these changes must not be uploaded to
unstable yet!".

There was a little bit of discussion about the delay on
https://lists.debian.org/debian-release/2024/02/msg00272.html but it
has not yielded a plan yet.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

[Andreas Metzler]

On 2024-02-06 Helmut Grohne  wrote:
> Package: libselinux1t64

[...]> This looks fairly innocuous. We create a minimal sid chroot and install
> libselinux1t64 using apt. What could possibly go wrong? Well, apt thinks
> that it would be a good idea to avoid coinstalling breaking packages and
> first removes libselinux1 before proceeding to install libselinux1t64.
> Unfortunately, libselinux1 is transitively essential and dpkg links it,
[...]
> both dpkg and tar are now broken. This is pretty bad. To make matters
> worse, the situation arises from the combination of Breaks + Provides
[...]

Hello,

color me stupid but isn't this fishy?

Package: libselinux1t64
Replaces: libselinux1
Provides: libselinux1 (= 3.5-2.1~exp1)
Breaks: libselinux1 (<< 3.5-2.1~exp1)

Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
"libselinux1 (>= 3.1~)". dpkg needs to be rebuilt and the rebuilt
version gets a dep on "libselinux1t64 (>= 3.5)".

Will ${t64:Provides} stop expanding to "libselinux1 = ${binary:Version
for real t64-builds? (The ones in experimental are not.) If that is case
this bug and this way of testing does not make sense.

Otherwise the plan looks flawed.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: 64-bit time_t transition in progress

[Andreas Metzler]

On 2024-02-06 Alberto Garcia  wrote:
> On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> > In fact, none of the t64 binaries currently being uploaded
> > to experimental have the final ABI either, we're just using
> > experimental to clear binary NEW.

> I was having a look at two of the packages that I maintain that have
> t64 binaries in experimental and I noticed that while the binary
> package does have a different name the .so files themselves are the
> same. Is this expected when we're talking about an ABI break?

Hello Alberto,

It is expected for this ABI break yes. Essentially we are just doing a
rebuild-everything-involved while making sure the package
interdependencies avoid a (breaking) mixture. This is similar what we
did when the C++ ABI changed.[1]

cu Andreas
https://lists.debian.org/debian-release/2005/04/msg00153.html
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Bug#698988: O: nvi - 4.4BSD re-implementation of vi

[Andreas Metzler]

On 2024-02-05 Tobias Heider  wrote:
[...]
> As an active nvi user I would love to step up and help, but the biggest
> problem I see is that the choice of upstream project. Since the original
> is gone there isn't a clear successor.

> The BSDs all have their own forks which diverged over time (and those don't
> build on Linux).
> The other two options there are today are https://repo.or.cz/nvi.git which
> d/control currently points to and more recently 
> https://github.com/lichray/nvi2.

> The first has a very low commit frequency (last commit was 2020, before
> that 2016) and sticks very closely to the original source. nvi2 has added
> new features such as multibyte support and is starting to receive bug fixes
> and features from the different *BSD forks.

> I have been thinking of proposing a new package for nvi2 but maybe it
> would make more sense to move this one to the more active upstream.
> It looks like some of the issues we are carrying patches for in Debian
> might be fixed there already and if not they seem active enough to
> merge our fixes.

> What would be the best way forward here? ITA and eventually switch the
> upstream or start a new package and let this one continue its slow
> death?

Hello Thomas,

On one hand it depends on whether there is significant value in keeping the
other nvi around, i.e. a significant part of the userbase would be
reluctant to switch. (I have no opinion on that I use vim ;-)

On the other hand reducing the number of QA-maintained packages is a
strong argument for switching.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: 64-bit time_t transition in progress

[Andreas Metzler]

On 2024-02-03 Sebastian Andrzej Siewior  wrote:
> On 2024-02-02 08:43:52 [-0800], Steve Langasek wrote:

>> debian-devel-announce wouldn't let me attach the file, but for those on
>> debian-devel at least, you can find the dd-list of to-be-NMUed source
>> packages attached.

> OpenSSL is on the list. I did not see a NMU bug report. Was the bug
> missed or can it be removed the list of packages that require a NMU?

"These (0-day) NMUs started on Monday, and about 500 libraries have been
uploaded to experimental so far.  The goal is to get all source packages
that can be SRUed to experimental uploaded by this weekend."

The fact that no "We are done" message followed suggests that Steve and
his colleagues are still working on it and will get to OpenSSL in due
time.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Policy: versioning between releases

[Andreas Metzler]

On 2024-01-21 Matthias Urlichs  wrote:
> On 21.01.24 15:34, Andreas Metzler wrote:
> > However according to our release notes we only support upgrading from
> > release x to x+1, skipping releases is not allowed.

> I'm not talking about skipping releases but about partial upgrades.

eah, but it still answers your question. ...

> Thus …

> > foo/testing requires bar >=1.1 to work but just states "Depends: bar >=1",
> and bar/stable is 1.0.42

> assume that Stable has bar/stable==1.0.42 and foo/stable==2.1, while Testing
> has foo/stable==2.2. $USER adds Testing (or possibly stable/backports) to
> their apt.sources, updates foo, observes breakage, and now needs to dig
> through dependencies to figure out what went wrong.

... If testing's foo 2.2 required bar >> 1.0.42 it would need to have a
respective *versioned* dependency.


> Yes I know that this cannot happen when people simply dist-upgrade,
[...]

I strongly disagree. A dist-upgrade is not atomic. foo and bar will/can be
upgraded at separated dpkg runs by apt. If the dependencies are not
strong enough we would see breakage.

cu Andreas

Re: Policy: versioning between releases

[Andreas Metzler]

On 2024-01-21 Matthias Urlichs  wrote:
> question: policy 3.5 states, rather unequivocally,

>Every package must specify the dependency information about other
>packages that are required for the first to work correctly.

> Now … does that apply to crossing release boundaries? Specifically, if
> foo/testing requires bar >=1.1 to work but just states "Depends: bar >=1",
> and bar/stable is 1.0.42 … is that a bug? If so which severity?

> If not, shouldn't that be mentioned somewhere in Policy? Offhand I didn't
> find anything that even mentions Debian suites / releases, but admittedly I
> only skimmed the table of content and didn't re-read the whole thing.

Hello,

I also do not think policy has anything to say about our release system.
However according to our release notes we only support upgrading from
release x to x+1, skipping releases is not allowed.

This implies that one may/should change "Depends: bar (>= 1.12)" to
"Depends: bar" (in an upload to sid) once we have made a stable release
that includes at least bar 1.12.

IIRC https://janitor.debian.net/scrub-obsolete/ implements this
algoritm.

cu Andreas

Re: Bug#1058807: ITP: acme.sh -- Pure unix shell script implementing ACME client protocol

[Andreas Metzler]

On 2023-12-16 Jérémy Lal  wrote:
[...]
> * Package name: acme.sh
>   Version : 3.0.7
>   Upstream Contact: w...@neilpang.com
> * URL : https://acme.sh
> * License : GPL-3
>   Programming Lang: Shell
>   Description : Pure unix shell script implementing ACME client protocol
[...]
> This acme.sh tool is a must-have for everyone who stumbled upon
> certbot shotcomings. It is odd that it isn't already in debian.

Good, morning,

letsencrypt.org lists 6 bash-implementations of the acme protocol, I do
not think it is surprising that not all of them are packaged
(letsencrypt.sh/dehydrated has been available in Debian forever).

Not trying to discourage you from packaging, at a first glance acme.sh
seems to be very much alive project.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Signature strength of .dsc

[Andreas Metzler]

On 2023-12-06 Dimitri John Ledkov  wrote:
[...]
> May I also do a mass bug file against the above set of packages, at
> wishlist priority to nudge maintainers (or QA or Janitor) to make an
> upload?
> ideally bundled with any other reasonable modernisations. As such an
> algorithm indicates that the package is likely to be either very
> stable or in potential need of a bit of TLC ?
[...]

Hello,

Imho submitting another (minor/wishlist cosmetic) bug-report against
already neglected packages does not make sense. It is not like Debian QA
is bored and has no idea where to spend effort.

It should be easily possible to order/filter source packages by upload
date using udd, if one were interested in investing love in packages
like these.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Linking coreutils against OpenSSL

[Andreas Metzler]

On 2023-11-11 Michael Stone  wrote:
> On Sat, Nov 11, 2023 at 11:50:31AM +0100, Andreas Metzler wrote:
> > you seem to have missed/deleted the paragraph where Ansgar suggested how
> > to do this *without* tradeoff. ("explicitly disable/enable build options
> > per arch")

> No, I didn't. That was in my original email and is one of the possibilities
> for future versions depending on the feedback from people testing to guide
> whether it makes sense to make this per-arch rather than global.

Hm. Would you mind explaining why you chose to not implement this but
instead only used a per-arch build-dep? (With the downside of wrong
builds on dirty chroots and slent breakage when a respective feature
is not found)?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Linking coreutils against OpenSSL

[Andreas Metzler]

On 2023-11-10 Michael Stone  wrote:
> On Fri, Nov 10, 2023 at 03:10:42PM +0100, Ansgar wrote:
>> Please avoid producing different results depending on the build
>> environment. That just results in non-reproducible issues in unclean
>> environments (suddenly different dependencies, different features,
>> ...).

> I think that is an acceptable tradeoff at this time; the only difference
> will be the dependencies, but that is the intent. Automated buildd packages
> should be stable. Based on further experience and feedback, one of the other
> options could be chosen instead. (I'm particularly interested in hearing
> from people who compare the different builds on arm, as that is where
> there's been an assertion of a performance regression.)

Hello,

you seem to have missed/deleted the paragraph where Ansgar suggested how
to do this *without* tradeoff. ("explicitly disable/enable build options
per arch")

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru coreutils-9.4/debian/rules coreutils-9.4/debian/rules
--- coreutils-9.4/debian/rules	2023-11-10 14:31:21.0 +0100
+++ coreutils-9.4/debian/rules	2023-11-11 11:37:05.0 +0100
@@ -13,13 +13,20 @@
   DEB_CFLAGS_MAINT_APPEND += -mieee
 endif
 
+ifeq ($(DEB_TARGET_MULTIARCH),x86_64-linux-gnu)
+opensslconf = --with-openssl=auto-gpl-compat
+else
+opensslconf = --with-openssl=no
+endif
+
 BIN_PROGS = cat chgrp chmod chown cp date dd df dir echo false ln ls mkdir \
 	mknod mv pwd readlink rm rmdir vdir sleep stty sync touch true uname \
 	mktemp
 d=debian/coreutils
 
 override_dh_auto_configure:
-	dh_auto_configure -- --enable-install-program=arch --with-openssl=auto-gpl-compat
+	dh_auto_configure -- --enable-install-program=arch \
+		$(opensslconf)
 
 %:
 	dh $@ --with autoreconf

Re: mutt removed from testing while the bug was closed (fixed)

[Andreas Metzler]

On 2023-10-26 Vincent Lefevre  wrote:
> On 2023-10-26 02:03:49 +0200, Vincent Lefevre wrote:
[...]
> Hmm... This seems to be due to a bug in the BTS when the bug was
> reopened for stable. At

>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563#25

> "Bug reopened Request was from Antonio Radici  to 
> cont...@bugs.debian.org. (Sun, 10 Sep 2023 11:36:03 GMT) (full text, mbox, 
> link).
[...]

Hello,

It was user error, plain and simple. The bug was closed and marked as fixed
in Version 2.2.12-0.1 at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563#20
and Antonio told the BTS "No, that is true" ("reopen 1051563") and the
BTS implemented this command. The reopen should not have happened and
should have been reverted.

The documentation given in the original announcement when version
tracking was introduced [1] still applies. The nice nice graphs on the
webpages for each bug that show which versions a bug (still) applies to
are not men tioned there yet.

cu Andreas

[1] https://lists.debian.org/debian-devel-announce/2005/07/msg00010.html

Re: Hyphens in man pages

[Andreas Metzler]

On 2023-10-15 Wookey  wrote:
[...]
> OK. So I read all that, and learned a whole load of stuff I was quite
> happy not knowing about.

> However despite reading it all, and especially this bit:
> "Whenever I've maintained man pages in roff I tend to be precise in
> > the usage of - and \-, but TBH this has seemed like a lost battle,"

> I was left not actually know what - and \- represent, nor which one I
> _should_ be using in my man pages. And that seems to be the one thing
> we should be telling the 'average maintainer'.
[...]

Hello,

a pretty good guidance[1] is to

use "\-" whenever it refers to option ("-h", --help"), argument ("find
-mmin -2") or something else that is not natural language but something
that might be pasted, like a command-name ("ssh-add" or "dpkg-source")

and "-" everywhere else.

cu Andreas

[1] Well it is "guidance": pasting will work, but there might still be
places in the prose where a dash would be typographically correct. Some
of these typographical conventions are langauage specific. All this
familiar to LaTeX users.
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Proposed MBF: Removal of libfreetype6-dev (causing FTBFS)

[Andreas Metzler]

On 2023-08-19 Diederik de Haas  wrote:
> [please CC me as I'm not subscribed to debian-devel]

> On Mon, 17 Jul 2023 at 21:45:13 +1000, Hugh McMaster wrote:
> > On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote:
> > > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote:
> > > > Currently, there are 219 build-dependencies and 29 (direct)
> > > > dependencies on libfreetype6-dev, which has been released with
> > > > bullseye and bookworm.
[...]
> > > Lintian diagnoses this as "[build-]depends-on-obsolete-package" since
[...]
> > Thanks for pointing this out. I wasn't aware Lintian had started
> > flagging dependencies on obsolete packages some 10 months ago.

> > Having Lintian issue a warning or error instead of bug filing is preferable.

> While it's true that lintian did issue an error, now that src:freetype has 
> been updated and libfreetype6-dev has been dropped, there are a number of 
> packages which hadn't been updated and now FTBFS.
[...]
> As the FTBFS wrt libfreetype6-dev was predicted and announced [1], wouldn't 
> it 
> have been better if the MBF had taken place?

> What is the recommended/appropriate way to deal with such issues?

The agreed reached was not "let's ignore it, lintian has been warning
about it". Instead a way forward that /should/ have avoided any breakage
(versioned provides) was proposed and chosen.

https://lists.debian.org/debian-devel/2023/07/msg00193.html

cu Andreas

Re: Potential MBF: packages failing to build twice in a row

[Andreas Metzler]

On 2023-08-15 Boyuan Yang  wrote:
[...]
> where .po file that contains translation is updated every time, causing dpkg-
> source to complain the diff and quit when building twoce in a row.

> Take https://tracker.debian.org/pkg/ibus-array as an example. The upstream
> project does not include .pot template file in the source code. The logic of
> Makefile.in.in is to call msgmerge to update po translation file with
> generated .pot file when .pot file is not present. This causes at least the
> following diff after build:

> --- ibus-array-0.2.2.orig/po/zh_TW.po
> +++ ibus-array-0.2.2/po/zh_TW.po
> @@ -6,7 +6,7 @@ msgid ""
>  msgstr ""
>  "Project-Id-Version: ibus-array 0.2.2\n"
>  "Report-Msgid-Bugs-To: https://github.com/lexical/ibus-array/issues\n";
> -"POT-Creation-Date: 2019-12-10 22:09+0800\n"
> +"POT-Creation-Date: 2023-08-15 09:07-0400\n"
[...]
> I am looking for the advice to implement an elegant solution. What I
> can think of now is to persuade upstream to embed a copy of generated
> .pot template file in source code, which does not sound reasonable.
> Meanwhile since Makefile.in.in is somehow widely used, this issue
> likely already had impact on packages using gettext to handle
> translation.

You could simply set

extend-diff-ignore="\.po$"

in debian/source/options (untested).

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

guile-gnutls not picked up by sid autobuilders

[Andreas Metzler]

Good morning,

guile-gnutls was uploaded almost a week ago to sid, but the unstable
autobuilders seem to ignore it.
https://buildd.debian.org/status/package.php?p=guile-gnutls

Is there anything I can do? The experimental uploads were picked up
seamlessly.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: /usr-merge: continuous archive analysis

[Andreas Metzler]

On 2023-08-01 Helmut Grohne  wrote:
[...]
> In moving crontab_setgid from lib to libexec, you effectively evade the
> moratorium and are entitled to also move from / to /usr. This is an
> action you can do right now. The move from /lib to /usr/libexec prevents
> the file loss scenario that spurred the moratorium.
[...]

Hello,

Somehow related: If I introduce a new systemd unit should I work
around dh_installsystemd and ship it in /usr/lib/systemd/system/?

At first glance it seemed like a good idea (not adding to the problem)
but doubt there is real benefit. - Another binary package in the same
source already ships a unit that will need to be moved so we will need
to use $magic anyway. FWIW I would have used something like this:

override_dh_installsystemd:
dh_installsystemd
mv debian/foo/lib/systemd/system \
debian/foo/usr/lib/systemd/

(I am assuming dh_installsystemd would not start installing stuff into
/usr/lib without a dh_compat bump.)
cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Empty Contents files for bookworm-updates

[Andreas Metzler]

On 2023-07-15 Markus Falb  wrote:
> Hi, it’s Markus,

> …snip
> Index of /debian/dists/bookworm-updates/main

[...]
> The size of the gz files is 20, i.e. the unzipped files are empty.
> Is this by purpose?

Afaict (from looking at the Packages files) there are no Packagages yet
in bookworm-updates/main. So yes.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Second take at DEP17 - consensus call on /usr-merge matters

[Andreas Metzler]

On 2023-06-28 Helmut Grohne  wrote:
> The category of generic changes includes
> imposing an ordering on initial unpacks (e.g. base-files first).

Hello,

I have not dug deeply into this but in the back of my mind a voice is
vaguely remebering that we already had multiple times wished we had this
in our toolset for handling other upgrade issues.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

[Andreas Metzler]

On 2023-06-19 Sven Joachim  wrote:
[...]
> If my above statements about debootstrap are correct, this will result
> in no dhcp-client being installed at all by debootstrap unless the
> override bug also requests bumping dhcpcd-base's priority from optional
> to important.

Not complety true. debootstrap would still install systemd which includes
systemd-networkd.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Andreas Metzler]

On 2023-06-07 Paul Wise  wrote:
[...]
> There was another option mentioned earlier in the thread that could
> help resolve some aspects of these conflicts; make 32-bit arches
> (or just i386) support both time_t ABIs, like glibc and Linux do.

> The 64-bit time_t ABI would be the default but the 32-bit time_t ABI
> would be present for running old binaries that still kind of work with
> the 32-bit ABIs after 2038, or under faketime when they do not.

> This would be more work for Debian and a lot more work for upstreams
> but would be a better outcome for the diversity of uses for 32-bit.

Hello,

I doubt it is a realistic option, though. This is a non-trivial change
and imho way over Debian's resources.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Andreas Metzler]

On 2023-05-20 Wookey  wrote:
> On 2023-05-17 20:14 -0500, Richard Laager wrote:
>> They mention, "We likely have to complete Modern C porting first to remove
>> any instances of -Wimplicit-function-declaration otherwise the redirects in
>> glibc for e.g. time->time64 won't actually work."

>> Has that issue been considered here? (I can't speak intelligently on it at
>> this time. I just want to make sure it's on your radar.)

> I was aware of it (the gentoo info is linked on the 64bit-time wiki
> page), but had not yet looked into how significant an issue this actually
> was, so had not documented it. (frankly, I was hoping we could avoid
> tying yet another transition into this one). Thanks for the reminder.
[...]

Hello,

There is an ongoing Fedora project by Florian Weimer which includes this
issue.

https://fedoraproject.org/wiki/Changes/PortingToModernC

Not sure whether there is a similar effort for Debian but it should help
a lot, everything with active upstream that is packaged by Fedora will
be fixed.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Andreas Metzler]

On 2023-05-12 Ansgar  wrote:
[...]
> The core issue as I see it is as follows:
[...]
> Do you think this summary of the issue is right?

I think Simon's reading of the situation as posted in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035904#30
makes a lot of sense.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: DEP 17: Improve support for directory aliasing in dpkg

[Andreas Metzler]

On 2023-05-05 Simon Richter  wrote:
[...]
> My proposal would be to put the onus on the client registering the
> diversion:
[...]
>  - packages are encouraged to register both diversions

Hello,

That seems to be a rather ugly user interface, ("There is dpkg-divert on
Debian, but because the usrmerge you need to invoke it twce to be
sure"). Will we need to have a meta-transition years from now trying to
get get rid of the double diversions?

cu Andreas

Re: Many packages will install apache2

[Andreas Metzler]

On 2023-01-18 Jérémy Lal  wrote:
> I just keep on removing apache2 on my system, and find it bad that some
> updates will reinstall it.
> It seems to be coming from dependencies on "apache2 | httpd-cgi" which
> favors the former (I have some httpd-cgi installed, just not apache2).
> Is it okay to open bugs asking to use instead "httpd-cgi | apache2"?
> Which severity would be correct? Unless there is a general reason not
> to do this?

Hello,

If apt finds that a dependency requires (apache2 OR httpd-cgi) and
something providing httpd-cgi is already installed it will not (should
not) remove the providing package and install httpd-cgi. So you will
need to look in detail why apache2 is being installed on your system.

Using "apache2 | httpd-cgi" as dependency allows us (Debian) to declare
apache2 to be the default choice.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: depends-on-obsolete-package lsb-base

[Andreas Metzler]

On 2023-01-18 Otto Kekäläinen  wrote:
> Lintian just started erroring on 'depends-on-obsolete-package
> lsb-base' on many of my packages yesterday. There are no new uploads
[...]
> Does somebody know what is going on?

> Example:
> E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>= 3.0-10)

That is this change
  * Remove init.d-script-needs-depends-on-lsb-base and add lsb-base to
obsolete-packages. (Closes: #1019851)

from this commit:

commit 97f742b00553a4dd7ba681aefa4cc164ea263f71
Remove init.d-script-needs-depends-on-lsb-base and add lsb-base to 
obsolete-packages

The functionality of lsb-base is in the Essential:yes set since
Bullseye. The package itself is now an empty transitional package
(because debootstrap doesn't understand the Provides relationship) which
depends on the new provider of the functionality, sysvinit-utils, which
is also in the Essential:yes set.

Closes: #1019851

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: SONAME bumps (transitions) always via experimental

[Andreas Metzler]

On 2023-01-10 Sam Hartman  wrote:
> > "Graham" == Graham Inggs  writes:
> Graham> Hi All
> Graham> On Fri, 6 Jan 2023 at 00:33, Bastian Blank  
> wrote:
> Graham> Would it be a bad thing to require all uploads that need to
> Graham> go through NEW (source and binary) to target experimental?

> Graham> I have been doing this for my own, and sponsored, uploads
> Graham> for some years already.

[...]
> Also, I'm less convinced there's a good reason for source new uploads to
> target experimental.
> If it's a new package with entirely new binary packages, it shouldn't be
> involved in any transitions.
[...]

Afaiui Graham's *question* was in response to Bastian's "However, please
describe an actionable plan." Obviously it would be a lot easier if we
could require to have all NEW uploads go to experimental instead of
trying to filter for soname bumps.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Boost 1.81 in Debian Testing

[Andreas Metzler]

On 2023-01-04 Markus Blatt  wrote:
> Dear Anton,

> Am Wed, Jan 04, 2023 at 06:24:38AM +0100 schrieb Anton Gladky:
> > I am pleased to announce that the latest version of Boost, version
> > 1.81, is now available in Debian Testing [1].

> Thanks a lot.

>> We encourage all contributors whose packages depend on Boost libraries to

> Just double checking, still a newbie. By that you mean changing to an
> explicit dependency on the version in debian/control (e.g.
> libboost-system-dev -> libboost-system1.81-dev) and reuploading the
> source?  After the transition finished I would undo that change again.

Helo Markus,

Eh, no. You should simply do a *local* test-build (without any upload) after
sudo apt install libboost-dev -t experimental

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Please, minimize your build chroots

[Andreas Metzler]

On 2022-12-16 Santiago Vila  wrote:
> Greetings.

> I'm doing archive-wide rebuilds again.

> I've just filed 21 bugs with subject "Missing build-depends on tzdata"
> in bookworm (as tzdata is not build-essential).

> This is of course not fun for the maintainers, but it's also not fun
> for people doing QA, because those bugs could be caught earlier in the
> chain, but they are not. This is extra work for everybody.

> (Similar bugs are even sliding into stable releases, I plan to report
> a few of them against bullseye after 11.6 this Saturday, as bullseye
> is the currently supported stable release).

> Because people accept the default by debootrap "as is", chroots used
> to build packages include packages which are neither essential nor
> build-essential, like tzdata, mount or e2fsprogs.
[...]

or apt.

I am wondering if there is point to this or whether policy should be
changed? Is there some value in investing work in having packages
buildable without Prioriry required packages?

Such installations can only be found as artifacts since there does not
seem to be a supported way to upgrade them or (un)install packages
(quoting policy: "Removing a "required" package may cause your system to
become totally broken and you may not even be able to use "dpkg" to put
things back, so only do so if you know what you are doing.") Essentialy
policy is telling us it might work to install b-d, and uninstall
Prioriry required, however dpkg might break halfway through and it would
not be a bug.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: propose: provide "docker" package as docker, not wmdocker

[Andreas Metzler]

Gioele Barabucci  wrote:
> On 05/12/22 18:19, Andreas Metzler wrote:
>> how do you avoid that people who still have got the transitional docker
>> (--> wmdocker) package installed end up being upgraded to real docker
>> (from docker.io)?

> How was the transition from git-the-file-viewer to git-the-VCS handled 
> in lenny/squeeze?

Afaict (Thanks, Gerrit for linking the discussion in git's
debian/changelog) it was also discussed on debian-devel before making
the switch.  However no real solution came up and it was deemed to be
acceptable to have some unwanted git (VCS) installations.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Andreas Metzler]

On 2022-12-09 Andreas Tille  wrote:
[...]
> Thanks to Alexander Sulfrian who pointed out the Git repository
> featuring old tags that were obviously taken over from SVN I was proven
> wrong with the statement that there is no configure.ac any more.

> Unfortunately this is no simple drop-in with modern autoconf tools
> and my weak attempt in Git to use this failed.[1]
[...]

Hello,

I have given this a a little bit of time. This seems to work:

1. Copy configure.ac from upstream's 2.3.2h2 branch.
2. Add 'export AUTOHEADER = true' to debian/rules.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: propose: provide "docker" package as docker, not wmdocker

[Andreas Metzler]

On 2022-12-04 Hideki Yamane  wrote:
> Hi,

>  I'd like to propose wmdocker package would rename its source package
>  from docker to wmdocker, and then docker.io package provides docker
>  binary package and transitional docker.io package.

>  Most of users who is not Debian expert still confusing with docker
>  package, so I want to fix it in Debian12 "bookworm".

>  wmdocker and transitional dummy docker package is already in Debian10
>  "buster", so it does not confuse users and also other packages as
>  well.

>  Any thoughts?

>  If there's no objections against it, I'll file a bug and upload
>  renamed source package for wmdocker (maybe with some more updates to
>  comply with current Standards-version) first.

Hello,

how do you avoid that people who still have got the transitional docker
(--> wmdocker) package installed end up being upgraded to real docker
(from docker.io)?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Pre-Depends usage

[Andreas Metzler]

On 2022-11-14 Guerkan Myczko  wrote:
> I would like to use Pre-Depends in the cadabra2 packge so it'll not break
> the jupyterhub notebook. It gets broken due to the package python3-notebook
> creating a symlink for the codemirror at
> /usr/lib/python3/dist-packages/notebook/static/components
> Now if cadabra2 which puts a part into that directory, while it's not yet
> symlinked the codeeditor part of notebook gets broken.
[...]

I think you must not install files into the symlink but into the real
directory where the symlink
/usr/lib/python3/dist-packages/notebook/static/components/codemirror
points to, afaict /usr/share/javascript/codemirror.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Transition: pkg-config to pkgconf: next steps

[Andreas Metzler]

On 2022-10-20 Johannes Schauer Marin Rodrigues  wrote:
> Quoting Andrej Shadura (2022-10-20 12:25:13)
> > I’ve been rebuilding packages with pkgconf for the past couple of weeks, and
> > it looks very good so far:
> > 
> > http://pkgconf-migration.debian.net/

> Thank you! Attached is a dd-list of those packages listed in the "Failures
> only" page in case somebody wants to have a quick glance whether their package
> is affected.

> Thanks!

> cheers, josch

[...]
> Andreas Metzler 
>enblend-enfuse (U)

Works for me. - It is now also marked with SUCCESS on your webpage, I
guess you retried?

cu Andreas

Re: Proposed MBF: wxwidgets3.2 transition

[Andreas Metzler]

On 2022-09-15 Scott Talbert  wrote:
> On Thu, 15 Sep 2022, Andreas Metzler wrote:
[...]
> > A successful build is no guarantee for a working packaging though. e.g.
> > hugin errs out immediately when built with the newer wxWidgets.

> That is certainly true - and probably another good reason we don't use the
> single-dev-package approach.

> Do you want help with those errors?

Hello Scott,

thanks for the offer, upstream has been uite helpful. However something
else came up:
| After starting up, klicking on [Preview
| Panorama (OpenGL)] yields an error (and nothing else:
| 
| --
| Error initializing GLEW
| Fast preview window cannot be opened.
| --
| with this message on the console:
| ERROR: 14:13:49.978869 (./src/hugin1/hugin/GLViewer.cpp:133) SetUpContext(): 
Error initialising GLEW: Unknown error.
| 
| Klicking on [Preview Panorama (OpenGL)] again succeeds.

Upstream pointed me to hugin documentation which says:
Note: On Linux wxWidgets 3.1.5 and later is by default compiled with EGL
support for the wxGLCanvas class. In this case you need to activate EGL
support explicitly also in GLEW, otherwise there are crashes when
intializing the wxGLCanvas.

Afaict from looking at Debian's glew 2.2.0 it is indeed built without
EGL support (debian/rules does not use SYSTEM=...-egl).

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Proposed MBF: wxwidgets3.2 transition

[Andreas Metzler]

On 2022-09-13 Scott Talbert  wrote:
> Hi,

> wxWidgets 3.2 (a new API/ABI stable release) has been released a few months
> ago and is now packaged in unstable as wxwidgets3.2.  Upstream has stopped
> supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx
> package users to wxwidgets3.2 for bullseye, with the plan to remove
> wxwidgets3.0 before release.

> For most packages, the transition should be as simple as changing
> Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev.  Some packages
> may require small patches; I'm happy to help with those (and I have some
> already from working on this transition in Fedora already).
[...]

A successful build is no guarantee for a working packaging though. e.g.
hugin errs out immediately when built with the newer wxWidgets.

cu Andreas

Re: Bug#1019721: libopenmpi-dev: Cannot uninstall rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran': No such file or directory

[Andreas Metzler]

On 2022-09-14 Paul Wise  wrote:
> On Wed, 2022-09-14 at 07:41 +0200, Andreas Metzler wrote:

>> Is there a way to find all packages built against broken dh-fortran-
>> mod so all affected packages can be rebuilt?

> I am not sure of the correct regex, but the binary package control
> search should work, if it doesn't then you need a local mirror:

> https://binarycontrol.debian.net/?q=%2Fusr%2Flib%2F%5C%24multiarch%2Ffortran%2Fgfortran&path=

Thank you, I have justed filed a binNMU request #1019876 for the
remaining 4 source packages.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1019721: libopenmpi-dev: Cannot uninstall rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran': No such file or directory

[Andreas Metzler]

Package: libopenmpi-dev
Version: 4.1.4-2
Severity: serious

Hello,

it seems to be impossible to uninstall libopenmpi-dev:
(sid)root@argenau:/# dpkg --purge libopenmpi-dev
(Reading database ... 25167 files and directories currently installed.)
Removing libopenmpi-dev:amd64 (4.1.4-2) ...
rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran': No such 
file or directory
dpkg: error processing package libopenmpi-dev:amd64 (--purge):
[...]

Looking at the postrm script we find:
(sid)root@argenau:/# grep ^rmdir 
/var/lib/dpkg/info/libopenmpi-dev\:amd64.postrm 
rmdir --ignore-fail-on-non-empty /usr/lib/$multiarch/fortran/gfortran
rmdir --ignore-fail-on-non-empty /usr/lib/$multiarch/fortran/gfortran
rmdir --ignore-fail-on-non-empty /usr/lib/$multiarch/fortran/gfortran
rmdir --ignore-fail-on-non-empty /usr/lib/$multiarch/fortran/gfortran
rmdir --ignore-fail-on-non-empty /usr/lib/$multiarch/fortran/gfortran

i.e. rmdir is run unconditiionally multiple times on the same directory,
the first instance succeeds, the second one fails.

This is #1019050 in dh-fortran-mod which is now fixed. However
libopenmpi-dev 4.1.4-2 contains the broken code generated by
dh-fortran-mod and needs a rebuild against dh-fortran-mod (0.27) and
should not propagate to testing.

Is there a way to find all packages built against broken dh-fortran-mod
so all affected packages can be rebuilt?

cu Andreas

Re: Q: systemd-timer vs cron

[Andreas Metzler]

On 2022-03-12 Hideki Yamane  wrote:
>  Is there any suggestion or guideline for pacakges that contain
>  both systemd-timer unit setting and cronjob? Don't they conflict
>  or not

Hello,

You want to skip running the cronjob on systems with systemd as init
systems. e.g. exim's daily cronjob works like this:
1. the systemd unit runs /etc/cron.daily/exim4-base with argument
   systemd-timer.
2. /etc/cron.daily/exim4-base checks for a systemd setup by testing 
   existence of /run/systemd/system. On a systemd setup the script
   exits immediately when executed from cron (i.e. $1!=systemd-timer).

If the cron script itself was trivial I would avoid the ugliness of invoking
/etc/cron.d* from systemd. ;-)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: MBF: valgrind-if-available

[Andreas Metzler]

On 2022-02-27 Adam Borowski  wrote:
> On Sun, Feb 27, 2022 at 01:40:48AM +0100, Ben Hutchings wrote:
[...]
>> This should use "command -v", not which, I think?

> No, and the recent debacle revealed enough reasons that I'm pondering a MBF
> to change that _back_ in packages which followed the bad advice.

> Among others, "command -v"
> * gets confused by aliases
> * it fails to check +x perm both in dash and bash.  While this is something
>   required by POSIX, neither shell in unstable checks that, reporting the
>   command as executable if it's not.
> * built-ins get reported as available.  And busybox has even "dpkg"
>   built-in, with a pretty bad implementation.
[...]

Hello,

Is any of this relevant in the context Debian package building
(especially by autobuilders)? The only thing I can see is if $developer
had a nonexec ~/bin/somecommand and wondered why the local behavior
differed from the autobuilders. Aliases are a non-issue. Built-ins
(like command -v) actually are available, and when the respective
command is called the builtin will be used.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Why? "Marked for autoremoval on 24 March due to xdelta3: #965883"

[Andreas Metzler]

On 2022-02-24 Osamu Aoki  wrote:
> I favor moving away from pre-dh7 packages and I support people pushing for 
> it.  But I
> am in intriguing situation with this effort.  Can someone help me.

> At: https://udd.debian.org/cgi-bin/autoremovals.cgi

> I see:

> Osamu Aoki 
>debian-history: buggy deps xdelta3, flagged for removal in 28.4 days
>debian-reference: buggy deps xdelta3, flagged for removal in 28.4 days
>maint-guide: buggy deps xdelta3, flagged for removal in 28.4 days

> These are all COMPAT=13 packages with d/control having:

> > Build-Depends: debhelper-compat (= 13)

> Thus, it doesn't make sense to be connected to 
> > xdelta3: Removal of obsolete debhelper compat 5 and 6 in bookworm
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965883

> Also, these packages are not even listed in the original hit list:
> https://lists.debian.org/debian-devel/2020/07/msg00065.html


> I have been using at least compat=8 since 2013 for 2 of these packages
> and compat=7 since 2010 for another.  So I can't figure out why these
> packages are suddenly flagged.
[...]

Hello,

Afaiui xdelta3 was (see below) rc-buggy, because it used dh 5 or 6 and
was therefore marked for autoremoval. Afaik autoremovals are recursive,
i.e. we do not make packages uninstallable by removing their
dependencies but instead also remove these depending packages. I think
this also extends to build-dependencies, we do not want unbuildable
packages in testing so these would be removed, too. The respective set of
xdelta3 is probly huge, it includes e.g. pristine-tar. I suspect
debian-history et al are part of this set.

This is probably very academic now since Andreas Tille has uploaded a fixed 
xdelta3 package today. - Just doublecheck after the next britney run
whether debian-history ist still marked for removal.

cu Andreas


-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: using epoch to repair versioning of byacc package

[Andreas Metzler]

On 2022-01-23 Thomas Dickey  wrote:
> From: Richard Laager 
>> On 1/23/22 10:04, Thomas Dickey wrote:
[...]
>> I see no other way to correct this but to add an epoch.

> agreed.  Is there some way to further improve the transition?

>> As we see in this case, switching from version numbers to date-based
>> versions is dangerous because it's impossible to go back without an
>> epoch. A better version would have been something like
>> 1.9.1+20050505.

> I suspect that providing an interim 1.9.1+20140715 with/without an epoch
> would have problems going backward.  But there might be some way to do that.
[...]

Hello,

afaiui Richard was pondering the time machine solution - Whether the
2005 upload should have have used 1.9.1+20050505 instead of 20050505. It
is not a viable solution anymore.

>> Lintian flags on this, but (according to the name and description) only for
>> new packages:
>> https://lintian.debian.org/tags/new-package-uses-date-based-version-number

>> Personally, I'd like to see that lintian check fire if the date-based
>> versioning is new. That is, it should fire if the previous changelog entry
>> did not have a date-based version.

> yes... but it's a little late for that (I've only learned about these
> issues in the process of setting up the upgrade).

>> Even better would be a dak (or whatever ftp-master tool is relevant) hard
>> fail if going from non-date-based to date-based at the front of the version
>> string.

It might help a little bit but I suspect that very often at the time the
upload with the date-based version hits the Debian archive the version
number is already entrenched. - There might have been lengthy
discussions before or packages with the new numbering have been shipped
at other places like other major distros.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#996232: ITP: android-file-transfer-linux -- Android File Transfer for Linux

[Andreas Metzler]

On 2021-10-12 YaNing Lu  wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: debian-devel@lists.debian.org

> * Package name: android-file-transfer-linux
>   Version : 4.2.0
>   Upstream Author : Vladimir  
> * URL : https://github.com/whoozle/android-file-transfer-linux

This is already packaged.
https://packages.qa.debian.org/android-file-transfer

cu Andreas

Re: dh_install -X not excluding any files

[Andreas Metzler]

On 2021-09-14 John Paul Adrian Glaubitz  wrote:
> I'm currently working on packaging KIWI [1] for Debian where I need to
> exclude on of the binaries from being installed into /usr/bin.

> I tried using "dh_install -Xkiwicompat" [2] but that doesn't work no
> matter what variation I'm trying, the binary kiwicompat still gets
> installed into /usr/bin.

> Does anyone have a clue why excluding "kiwicompat" doesn't work?

Hello,

It is not installed by dh_install:
| dh_auto_install
| [...]
| running install_scripts
| Installing kiwi-ng script to /dev/shm/KIW/kiwi-debian/debian/kiwi/usr/bin
| Installing kiwicompat script to /dev/shm/KIW/kiwi-debian/debian/kiwi/usr/bin
| make[1]: Leaving directory '/dev/shm/KIW/kiwi-debian'
|debian/rules override_dh_install
| make[1]: Entering directory '/dev/shm/KIW/kiwi-debian'
| dh_install -Xkiwicompat

Since there is only a single binary package dh_auto_install installs
directly to debian/kiwi/
(sid)ametzler@argenau:/dev/shm/KIW/kiwi-debian$ dh_auto_install --no-act --verbo
se
make -j1 install DESTDIR=/dev/shm/KIW/kiwi-debian/debian/kiwi 
AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true"

Since you are already overriding dh_auto_install you could simply rm the
offending file there.

cu Andreas

Re: Debhelper and /lib/systemd vs /usr/lib/systemd

[Andreas Metzler]

On 2021-08-25 Niels Thykier  wrote:
[...]
> As I understand it, the "have usrmerge package patch the dpkg database"
> approach will only work if we ensure that each and every package stop
> using / in bookworm+1.

Hello,

you missed the second part of the "plan". Editing dpkg database syncs
the db with reality. In addition to that we need:
| if dpkg sees the top-level symlink, canonicalizes
| any files referenced in the packages to /usr/{bin,lib,sbin}/$1, with a
| fallback searching for /{bin,lib,sbin}/$1 in the file system, this
| would solve the problem.

A one-time rewrite does not solve the issue.  We cannot guarantee that
dpkg never sees a file with /bin/foo because of local or third party
packages.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: merged /usr vs. symlink farms

[Andreas Metzler]

On 2021-08-26 Timo Röhling  wrote:
[...]
> However, Guillem also seems to think that dpkg can manage file
> symlinks in a real directory better than an directory symlinks in /,
> which is why he proposed symlink farms in the first place.

Hello,

Afaiui, the symlink farm would just work from dpkg's point of view, even
with dpkg from oldoldoldoldstable. It can handle symlinks to files just
fine.

usrmerge is conceptually a lot harder because dpkg needs to get to handle
the fact that /bin/foo and /usr/bin/foo conflict.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: merged /usr vs. symlink farms

[Andreas Metzler]

On 2021-08-22 Guillem Jover  wrote:
[...]
> The huge majority of files under /lib* (which is the actual bulk of them)
> should require no symlink farms. Many of the ones under /bin and /sbin
> (we are talking about around 240 packages here) might be switchable w/o
> compat symlinks after careful consideration (or not…), many of the ones
> that require symlinks would need these just for a period of time, and
> only a handful would remain (the ones that are part of standard
> interfaces, which I'd expect would be mostly shells?). I think the amount
> of symlinks currently provided by f.ex. lvm2 and e2fsprogs combined would
> amount to more symlinks than what we would eventually end up with TBH.
[...]
> I've also tried to stop replying to all misconceptions, inaccuracies
> and plain wrong stuff on this thread (f.ex. people vocal in this thread
> apparently do not exactly seem to know how upgrades or our package
> manager works in Debian?), first to avoid dominating it with replies
> (like some kind of deranged person, where I think I've probably already
> surpassed my quota), and because it just all seems like a monumental
> waste of time, energy and motivation. Which I'd rather spend elsewhere.

Hello Guillem,

Afaict we have still no idea on how to move on.

1 I think you agree that there is a significant number of usrmerged Debian
  installations out there. It does not really matter whether there are 7% or
  40%. They exist and should (keep) working.

2 As you have stated there are known issues with dpkg and usrmerged
  systems. Some of them are are triggered by moving files from / to /usr.

Starting from here it is hard to see a way forward. Is it a
realistic option to require something like
-
dpkg --purge usrmerge
dpkg-fsys-usrunmess
-
pre dist-upgrade to bookworm to get back all systems to a sane (from
dpkg POV) state and start fresh? Is this robust (except for crash as
stated in the manpage), or would you consider it beta-quality?

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Planning for libidn shared library version transition

[Andreas Metzler]

On 2021-07-27 Simon Josefsson  wrote:
> Hi!  I'm now resuming work on the libidn shared library transition, and
> I'm ready for the upload to experimental.  I wanted to ping back here to
[...]

Hello Simon,

thank you, looks good to me.

cu Andreas

Re: merged /usr

[Andreas Metzler]

On 2021-07-27 Wouter Verhelst  wrote:
> On Tue, Jul 27, 2021 at 02:13:33PM +0200, Andreas Metzler wrote:
[...]
>> Afaiu you are suggesting to do somethink like this instead and
>> immediately post bulleye release.
>> 
>> preinst upgrade|install
>> if aliasing-symlinks /bin --> /usr/bin
>># do nothing
>> else
>>mv /bin/mv /usr/bin/mv

> That should be a copy (mv is too dangerous)

>>ln -s /usr/bin/mv /bin/mv

> This can be "ln -sf" to make it atomic.

>> fi
>> Plus corresponding error handling code in postrm abort install.
>> 

> Yes, but for packages in the Essential set only. For other packages, we
> can make it much simpler.

>> I just do not get the benefit. It seems rather complicated with
>> potential for breakage in corner cases and unnecessary since we (CTTE)
>> have essentially decided that there is going to be a cutoff date
>> pre-bookworm-release whereupon package maintainers can rely on the
>> existence of aliasing-symlinks and can simply move the file without any
>> maintainerscripts. It seems to be a waste of work to write
>> complicated maintainerscripts that are only needed as long as we need to
>> handle both usrmerge-d and non-usrmerge-d systems.

> I'm not worried about the support for both usrmerge'd and not usrmerge'd
> systems.

> I'm worried about systems being written to completely bypass the dpkg
> database.

Hello Wouter,

I think we complicated things enormously and caused real breakage by
trying to support both setups. This has already caused considerable work
without longterm gain and is preventing us to reach an unbroken state
(dpkg knowning the correct paths on all systems) again. That is what I
see as goal.

The maintainerscript setup for symlinking looks like a lot of work and
muddles the whole situation even more, there are more files/symlinks
dpkg does not know about and our systems diverge even more. I really do
not get how that is a step forward.

> It's being pushed forward "because we broke things in the past
> and now the only way to fix it is to break even more things". That's BS.
[...]

When you say "break more things" you are thinking of the social effect
(alienating Guillem)? I am not aware of any plans for new technical
breakage.

cu Andreas

PS: As you can probably tell English is not my native language so please
take the whole mail with a grain of salt if I did not manage to hit the
correct level of politeness.
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: merged /usr

[Andreas Metzler]

On 2021-07-27 Wouter Verhelst  wrote:
> On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
>> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
>>> I've suggested previously that we can easily make it RC for bookworm to
>>> have a file outside a limited set of directories (/etc and /usr would be
>>> OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
>>> This is easy to detect with a lintian check and reasonably easy to
>>> implement

>> I don't think that works in general without breaking some of Debian's
>> axioms around Essential packages, as previously described here:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118

> Yes. Those arguments didn't convince me then, and they don't convince me
> now.

> A package in the essential set could work around the issue by moving a
> file around and creating a necessary symlink in preinst rather than
> shipping things. The set of Essential packages is small however, and
> most packages can ship a compat symlink.

> I didn't say we *should* ship compat symlinks; I said we should make
> antyhing that is *not* a compat symlink in a particular set of
> directories be RC.
[...]

Hello Wouter,

I will bite.

just for context: Simon said in #978636 that e.g. coreutils
a) cannot ship both /usr/bin/mv and /bin/mv (the latter a symlink) in
the tarfile since /bin _might_ be a symlink to /usr/bin but 
b) it needs to provide /bin/mv in unpacked, unconfigured state.

Simon then said we needed a flag day where the aliasing-symlinks /bin -->
/usr/bin are either guaranteed to exist or forbidden. Once that is know
essential packages either ship both /usr/bin/mv and /bin/mv (the latter
a symlink) or only ship /usr/bin/mv (with no symlink required.)

Afaiu you are suggesting to do somethink like this instead and
immediately post bulleye release.

preinst upgrade|install
if aliasing-symlinks /bin --> /usr/bin
   # do nothing
else
   mv /bin/mv /usr/bin/mv
   ln -s /usr/bin/mv /bin/mv
fi
Plus corresponding error handling code in postrm abort install.


I just do not get the benefit. It seems rather complicated with
potential for breakage in corner cases and unnecessary since we (CTTE)
have essentially decided that there is going to be a cutoff date
pre-bookworm-release whereupon package maintainers can rely on the
existence of aliasing-symlinks and can simply move the file without any
maintainerscripts. It seems to be a waste of work to write
complicated maintainerscripts that are only needed as long as we need to
handle both usrmerge-d and non-usrmerge-d systems.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Andreas Metzler]

On 2021-07-20 Guillem Jover  wrote:
> On Mon, 2021-07-19 at 16:41:42 +0200, Johannes Schauer Marin Rodrigues wrote:
>> So what what is actually the roadmap after the bullseye release?
>> What is the way forward? Should I rather file bugs with patches
>> against individual packages to move their files from
>> /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/ or do we already have a
>> debhelper patch to do that move for us?

> Unfortunately, when the supporters of the merged-/usr-via-aliased-dirs
> pushed their approach into the distribution, that meant that package
> stopped being able to ship compatibility symlinks under «/», and those
> needed to be "handled" in maintscripts (by reimplementing poorly and
> unsafely what dpkg is supposed to do). This means dpkg is not in the
> loop and cannot perform a safe upgrade moving these pathnames safely,
> as long as merged-/usr-via-aliased-dirs is supported.
[...]

Hello,
Isn't this kind of crying over spilt milk? I also wish we never had ended
up with the buster/bullseye state where both unmerged and
merged-/usr-via-aliased-dirs are fully supported. However there is now a
huge number of merged-/usr-via-aliased-dirs installations out there and
we cannot make them magically disappear. Undoing
merged-/usr-via-aliased-dirs would be very error-prone while afaiui we
have a relatively simple plan to get a clean merged /usr in bookworm or
bookworm +1:

1. Make merged-/usr-via-aliased-dirs the only supported layout and make
this information available to apt. (Like we did for multi-arch-support.)
2. After that individual packages can safely move files from / to /usr,
pre-depending on merged-usr-support.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Reconsider sending ITP bugs to debian-devel: a new list?

[Andreas Metzler]

On 2021-06-12 Jonathan Carter  wrote:
> On 2021/06/11 12:33, Raphael Hertzog wrote:
> > Jonathan explained that it wasn't easy for him due to reading over NNTP
> > and I also think that it's a bad default to have lists where custom
> > filtering is desirable for many.

> Ah, I haven't used NNTP in 22 years so the details to its limitations
> have faded a bit :)

Hello,

These problems seem to be not NNTP specific but reader specific. e.g.
with tin I could easily hide ITP bugs by filtering on subject. That is
more coarse than autofiltering to a separate mailbox where you
could look at when you have time spare. But I do not think it is
asignificant difference, ITP feedback often needs to happen *quickly* ad
not two weeks later.

I am sure other readers offer similar capabilities, Emacs/Gnus probably
could even display the ITP bugs as a separate group. ;-)

FWIW I am with Steve on this issue, reviews would decrease a lot if one
needed to subscribe to a separate list.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Planning for libidn shared library version transition

[Andreas Metzler]

On 2021-05-26 Guillem Jover  wrote:
> On Tue, 2021-05-25 at 19:43:21 +0200, Andreas Metzler wrote:
[...]
> I'd probably instead make this a versioned Provides, so that the
> transitional package can be removed right away from systems, it does
> not interfere with the transition, and people can switch to the new
> package in parallel w/o disruption.

Hello,

Why not use a versioned Provides *instead* of the dummy package? We have
had these a long time our packagment management system should have 100%
support now.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Planning for libidn shared library version transition

[Andreas Metzler]

On 2021-05-24 Simon Josefsson  wrote:
> Hi!  This is for post-bullseye, but I appreciate guidance if anyone has
> time.  Shared library version transitions trigger uncertainty in me.

> I want to upload a new upstream libidn release into Debian, but upstream
> has done a shared library transition.

Hello Simon,

I will assume that "shared library transition" means that that libidn
1.34 will have a soname bump (libidn12.so) but that the new release is
API compatible. The following assumes this is true ...

> Bullseye will ship with
> libidn11-dev instead of libidn-dev too.  Is the first step on the
> transition to provide a libidn-dev package experimental (and after the
> release, unstable) and make all reverse build-dependencies use it?

That would delay the whole thing unnecessarily, you would not want to
artificially make changing all rdeps a pre-dependency of your work

First off if the new version of libidn is API compatible with 1.33 there
will be no hard /requirement/ for renaming libidn11-dev to libidn12-dev.
You could have libidn11-dev as a dev-package for libidn12. It is not
aesthetically pleasing and confusing but would continue to work and has
the least potential for error. OTOH a soname bump is good time for
renaming the development package since you will have a new binary
package (libidn12) and will need to go through NEW processing anyway.
However you should do soname bump and  dev-package rename in one upload
(to experimental) instead of beforehand. This ways ftp-master will only
need to check it once. So you would use this timelime:

1. Prepare packages of the new upstream targeted for experimental
(libidn12, libidn-dev, libidn11-dev transition package). Test.
2. Upload to experimental.
3. Wait for NEW processing
4. Do some more tests, once you thinks all rdeps could be built against
libidn12 you request a transition slot. Please note that at this point
no source changes to rdeps related to packaging changes needed to happen,
they can (and should) continue to b-d on libidn11-dev which pulls in the
libidn-dev.
5. debian-release gives you the GO for uploading the package to testing.
6. You do this and debian-release triggers rebuilds of all rdeps.
7. All rebuilt rdeps and libidn12/libidn-dev/libidn11-dev propagate to
testing together 10 days later.
8. Now you can start submitting bug-reports against rdeps asking for a
change of the b-d.

[...]
> A 'git diff' between the version in bullseye and what I want to upload
> to experimental is shown below, together with debdiff-output between the
> built packages.

> Generally, does things looks okay?  Specifically, what about the
> Breaks/Replaces/Conflicts?  The d/changelog entry?  Will the confusing
> 'Replaces: libidn11-dev' for the libidn11 (!) package in bullseye cause
> any problem?  Am I right to drop it here?

>  Package: libidn11-dev
> +Section: oldlibs
> +Architecture: any
> +Depends: libidn-dev, ${misc:Depends}

I would use (= ${binary:Version}) for the depends to make sure that
libidn11-dev 1.38 together with libidn-dev 1.34 do not fullfill a
dependency on libidn11-dev (>= 1.35)

> +Package: libidn-dev
>  Section: libdevel
>  Architecture: any
>  Depends: libidn11 (= ${binary:Version}), pkg-config, ${misc:Depends}
> -Conflicts: libidn9-dev
> +Breaks: libidn11-dev (<< 1.33-4)
> +Replaces: libidn11-dev (<< 1.33-4)
> +Provides: libidn11-dev
>  Multi-Arch: same
>  Description: Development files for GNU Libidn, an IDN library

You should drop the Provides - It is superfluous since you have got a
libidn11-dev transition package.

hth, cu Andreas


-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: please document why a package has been dropped from Testing/Bullseye

[Andreas Metzler]

On 2021-05-09 Harald Dunkel  wrote:
> https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so
> I wonder what is the recommended way to find out why rsnapshot (or any
> other package) has been dropped from Testing?

> rsnapshot is still in Sid. I found #986709, of course, but this
> information should be much easier to access.

Hello,

Look at https://tracker.debian.org/pkg/rsnapshot or
https://packages.qa.debian.org/rsnapshot

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: File moved from one package to another - use Conflicts/Replaces or Breaks/Replaces?

[Andreas Metzler]

On 2021-04-03 Otto Kekäläinen  wrote:
> Hello!

> In MariaDB we have over the years moved files around. A file that was first
> in e.g. mariadb-server-10.3 might have been moved to
> mariadb-server-core-10.3 and some years later to mariadb-client-core-10.5.
> The result is a massive debian/control file with a lot of
> Conflicts/Breaks/Replaces [1]

> While trying to clean up and simplify I started wondering, when should one
> use Conflicts/Replaces and when Breaks/Replaces?
[...]

The rough guideline is to use Breaks together with an earlier than (<<,
<=) condition. Which seems to be what mariadb does.

I do not think there is a lot to improve here. Did you you see David's
recent message, <20210331164012.gevwmagm63q2yc54@crossbow>?

| For me, this whole situation seems wrong though. Why do you have
| versioned package names (mariadb-server-*) when they are all mutually
| exclusive with one another due to all shipping the same binary?
| 
| Either embrace versioned names like e.g. gcc/clang do or drop the
| pretense and ship an unversioned mariadb-server. Most packages aren't
| packaged versioned after all and that is (mostly) fine (same for client
| and co which only makes this more complicated and worse).
| 
| Mixing the two causes your users to experience the worst of both worlds:
| The packages can not be co-installed forcing them through the change in
| one sitting and they are an upgrade nightmare as there will always be
| one more situation in which apt (or another resolver, or even a human)
| decides that (part of) an upgrade is not worth the perceived cost.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Questioning debian/upstream/signing-key.asc

[Andreas Metzler]

On 2021-03-26 Christoph Biedl  wrote:
> a few days ago, I ran uscan on a package where I knew there was a new
> upstream version - just to encounter an validation error since the
> keys in debian/upstream/signing-key.asc had expired.
[...]
> Another about 40 distinct keys will expire within the next three months.

> So for more than 20 percent of the packages with d/u/s-k, it's
> impossible to verify a new upstream tarball without extra work. Ouch.

> Of course I understand there are various reasons why this happens, and
> several are not the maintainer's fault. But at least in some cases it's
> obvious the maintainers didn't care: When there has been an upload with
> a new upstream version released after the expiration. This has
> happened, hopefully they've verified the tarball by other means.

> So, how to go from here?
[...]

Hello Christoph,

I think there are two different issues at hand.

Uploading a new upstream version of a package where
debian/upstream/signing-key.asc is expired or does not 
match the uploaded upstream signature is a (minor) bug.

Otoh having a debian/upstream/signing-key.asc which expired *since*
the first upload of the upstream version is kind of the natural way of
things. When a new version appears we download it and check the
signature. If it does not verify we will investigate, perhaps the
key expired and was extended or a new key was used. Trying to do this
before we look at (and actually have a new upstream) is error-prone
could be make-work. (No new upstream released before this key experies,
too.)

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#929165: How to use rm_conffile to remove files that contain empty " ", comma "," and wildcard "*"?

[Andreas Metzler]

On 2021-03-07 Hideki Yamane  wrote:
> X-debbugs-CC: debian-devel@lists.debian.org
>  I've tried to remove files that was accidentally containts empty " ",
>  comma "," and wildcard "*" via rm_conffile from dpkg-maintscript-helper.

>  However, it returns an error like below.

> > dh_installdeb: error: The current conffile path for rm_conffile must be 
> > present and absolute, got 
> > '/etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg,

>  I've specified it like below.

> > # cat debian/ubuntu-dbgsym-keyring.maintscript
> > rm_conffile '/etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg, *'
[...]
>  How to use rm_conffile to remove such files that contains empty, comma
>  and * in its filenames?

Hello,

I think that might be a dh_installdeb error, it seems to check whether
the first character is a '/', and does not account for possible quoting
characters.

This might work around this
rm_conffile /etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg,\ \*

BTW you should really specify [prior-version and [package].

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: move to merged-usr-only?

[Andreas Metzler]

On 2020-11-20 Ansgar  wrote:
> I would like to propose to plan to move to support merged-usr-only over
> the following releases.  The motivation is bugs like [1] where upstream
> developers just use `/usr/bin/rm` (or other binaries, or user scripts
> using /usr/bin/bash, or ...) unconditionally; this was already a
> motivation to adopt merged-/usr as a default for me.

> As far as I know nothing broke catastrophically over the last releases
> with merged-/usr.

> Alternatively, a team could form that preemptively looks at such issues
> and fixes them, ideally upstream.

> So a possible idea would be to:

>  - For Debian 12 (bookworm): make it mandatory to migrate old systems to
>merged-/usr on upgrade. Possibly by allowing the existing usrmerge
>program to run from the initramfs.

>  - For Debian 13 (trixie): packages should no longer install to /bin,
>/sbin, /lib, but to the respective locations under /usr.

Hello Ansgar,

I am all for declaring a cutoff date (and release) which makes usrmerge
mandatory and the only supported setup. (Or alternatively make usrmerge
an unsupported setup.) The current state where we are trying to support
both and end up dealing with fallout and cannot make real progress to
the clean state (bash being shipped as /usr/bin/bash and therefore dpkg
knowing about it) is a waste of developer time.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.

[Andreas Metzler]

On 2020-10-09 calumlikesapple...@gmail.com wrote:
> On Thu, 2020-10-08 at 18:45 +0200, Andreas Metzler wrote:
>> I do not get the reason for this change. Surely we do not expect
>> people to manually type 

>> open penguin.jpeg
[...]
> I disagree.  If you are developing an application, and are already
> working within a terminal, you probably won't want to have to open up a
> file browser and navigate to the right direction just to check if your
> penguin logo is wearing a hat.  In that case, typing 

> open penguin.jpeg

> is probably very handy.
[...]

There is already
see penguin.jpeg

cu Andreas

Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.

[Andreas Metzler]

On 2020-10-07 Charles Plessy  wrote:
> Hello everybody, hello Debian freedesktop.org maintainers,

> /bin/open has been kindly freed a couple years ago (#732796) and I would
> like to propose to repurpose it as a standard command for opening files,
> like on Mac OS and NextStep before it.
[...]

Hello,

I do not get the reason for this change. Surely we do not expect people to
manually type 

open penguin.jpeg

in an xterm window, because they do not know how to handle the file.
They will usually *klick* on it and some infernal magic will invoke the
correct program, be it named xdg-open or geeqie.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Andreas Metzler]

On 2020-08-29 Raphael Hertzog  wrote:
> +URL: https://dep-team.pages.debian.net/deps/dep14/
[...]

| When a package targets any release that is not one of the usual
| development releases (i.e. stable releases or a frozen development
| release), it should be prepared in a branch named with the codename of
| the target distribution. In the case of Debian, that means for example
| debian/jessie, debian/wheezy, debian/wheezy-backports, etc. We
| specifically avoid "suite" names because those tend to evolve over
| time ("stable" becomes "oldstable" and so on).

Hello

I had been doing this (well, without the debian/ prefix).  Naturally I
rarely touched theses stable or oldstable branches and whenever I did
I ended up googling the release number [1] for the release name since I
needed it for the Debian version number of the upload.  This was not a
welcome distraction when handling security issues. I have now switched
to using 09_stretch, 10_buster, etc. which was a huge improvement.

cu Andreas


[1] I know that the info is available in file /some/where/release in a
package called something lsb-release-info, but resolving this link
takes even longer than google/wikipedia.
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: [Summary]: RFC: Standardizing source package artifacts build paths

[Andreas Metzler]

In gmane.linux.debian.devel.general Niels Thykier  wrote:
[...]
>  3) We followed up with an [update to the proposal] were debhelper would
> optionally expose some of the relevant directories (some by default,
> others on request) with symlinks while still supporting the new
> layout. It did not attempt to change the debian/.build directory.


>  4) There is not been any visible feedback on our updated proposal from
> people, who raised concerns about the path, on whether this
> alleviated their concern.  Nor any visible feedback on the choice of
> paths being exposed by default.
[...]

FWIW I did not followup there because symlimking a hidden directory
just complicates things without addressing arguments against using a
hidden directory at all. I have not received a real answer to
20200331172540.ga1...@argenau.bebt.de. - But please bear with me ...

I do think it is a splendid idea to separate generated stuff from
everything else, I think there is no real good reason for using a
hidden toplevel directory. There is not a *strong* reason for not
doing so either. This subquestion is mainly a bikeshed-type question,
a matter of personal preference, so there is no consensus to be found.
Please if you use a hidden toplevel dir just do it, do not complicate
thing by symlinking outside the directory, which would sabotage the
original aim of clearly separating generated stuff without increasing
consensus. TIA.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: RFC: Standardizing source package artifacts build paths

[Andreas Metzler]

On 2020-03-09 Sam Hartman  wrote:
> I'm concerned about a leading . at least for:

> * the debian/tmp replacement
> * the replacement for the package install directories under debian.

> I think that maintaining those directories such that ls shows them will
> be more friendly for new maintainers.
> So I'd prefer something like debian/build rather than debian/.build for
> at least those directories.

I would like to add a strong AOL. Please do not use a hidden toplevel
directory. debian/.build does not avoid clutter - it just makes it harder
to recognize a cluttered directory. Not "stomping over any existing
directories" is also a weak argument for ".build" vs any other name,
neither has a guarantee that there are no conflicts currently.

cu Andreas

Re: Is comma operator defined by POSIX and supported by dash?

[Andreas Metzler]

On 2020-03-22 Bagas Sanjaya  wrote:
> Hello,

> According to [Bashism Wiki](https://mywiki.wooledge.org/Bashism):

>> The comma operator is widely supported by almost everything except dash
>> and yash -- even posh and Busybox. In ksh93 however, it conflicts with
>> the decimal radix in locales where it's used in floating points instead
>> of period

> Does it implied that arithmetic comma operator (`,`) isn't defined by POSIX
> shell specification? 

Hello Bagas,

I do not get why you are sending this mail. The web page above has
direct links to the posix specification. You can look there yourself.

> Does dash support it?

* Ditto. You are quoting "comma operator [...] supported [...] except dash"
  and still asking whether it is supported in dash. Aren't you a Debian
  user? Why don't you just try it out?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide

[Andreas Metzler]

On 2020-03-08 Wookey  wrote:
[...]
> So you need to package boringSSL before uploading this
> package.
[...]

https://packages.qa.debian.org/android-platform-external-boringssl

cu Andreas

Is there still a point in installing libgcrypt to /lib instead of /usr/lib

[Andreas Metzler]

Hello,

afaict we are moving to a usrmerge setup, i.e. with /lib just a
symlink to /usr/lib. So shouldn't packages start installing stuff to
/usr/lib instead of /lib? I would like to do that for libgcrypt, since
I would be able to shorten debian/rules by stopping to split stuff
between /lib (.so) and /usr/lib (.a).

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature

Re: How to give back a build

[Andreas Metzler]

On 2019-09-12 Jeff  wrote:
> The package I uploaded yesterday failed to build[1]. In the buildd, 2 of
> 1000+ tests failed. Of course, I built in a clean sbuild for sid before
> I uploaded it, and the same package built fine on the newer Ubuntu
> distros on launchpad. So I'm hoping it was just a glitch, and I'd like
> to retry the build, but my search engine foo is failing me.

> How can I give back the build?

https://lists.debian.org/debian-devel-announce/2019/08/msg3.html

Re: Why keep upstream sources in Git at salsa.d.o?

[Andreas Metzler]

Alexis Murzeau  wrote:
> Le 13/08/2019 à 01:17, Daniel Leidert a écrit :
>> Am Montag, den 12.08.2019, 19:53 +0200 schrieb Marc Haber:
[...]
>>> I haven't heard that a debian/ only repository layout is possible with
>>> git-buildpackage before today.

>> Works nicely. I keep a file debian/gbp.conf usually with the content
[...]
> I'm curious about keeping only debian/ in git.
> How to build such git repository ?

> I've tried one of yours but failed like this:
[...]
> I guess I'm missing either a part of git history or just the orig
> tarball, but what's the normal way to get it ?

> (maybe there is a doc or wiki somewhere about this ?)

Looking at the manpage I think you'll need to give gbp a pointer to
where the upstream tarball is available.

--git-tarball-dir=DIRECTORY

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: The noudeb build profile and dh-only rules files

[Andreas Metzler]

Theodore Ts'o  wrote:
[...]
> Thanks, that's really helpful.  One of the really frustrating things
> I've found about trying to use dh is that there is a real lack of
> examples which are more complicated than:

> #!/usr/bin/make -f
> #
> # See?   dh is easy-peasy!

> %:
> dh $@

> Sure, there are few a examples using one or two override declarations,
> but trying to use dh on a non-trivial package is non-obvious,
> given the current documentation. 
[...]

Hello,

FWIW my personal experience with converting was that I had to stop
treating debian/rules as a makefile with a dependency tree of
targets. It is just list of dh_auto_*. If you want to change the
buildprocess, override dh_auto_build, etc.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: git vs dfsg tarballs

[Andreas Metzler]

Enrico Weigelt, metux IT consult  wrote:
> I'm often seeing packagers directly putting dfsg'ed trees into their git
> repos, w/o any indication how the tree was actually created from the
> original releases.
[...]
> My preferred way (except for rare cases where upstream history is
> extremely huge - like mozilla stuff) would be just branching at the
> upstream's release tag and adding commits for removing the non-dfsg
> files ontop of that.
[...]

Hello,

the main reason for having +dfsg versions is that non-distributable
stuff is removed. Distributing these files in a Debian hosted GIT
repository would not be workable, would it?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: salsa.debian.org: merge requests and such

[Andreas Metzler]

Jonathan Dowland  wrote:
> On Tue, Nov 06, 2018 at 08:06:38PM +0100, Andreas Metzler wrote:
>> Could we document this a little bit better in the wiki? This is
>> completely different than on alioth, where collab-maint was suggested
>> for basically everything that did not need a mailinglist.
>> <https://wiki.debian.org/Alioth/PackagingProject>.

> The rules were basically the same for collab-maint as they are for
> Salsa's Debian group, it even says so on that very page you linked:
> "Thanks to ACL, all Debian developers have write access on those
> repositories."

Hello,

alioth's collab-maint was a zero-admin way to have a Debian hosted GIT
repository, without implying a specific commit-policy. e.g.:
| If a maintainer wants to maintain his/her package within a VCS, (s)he
| can use the collab-maint repository even if the package is not (yet)
| collaboratively maintained. This is always useful since contributors
| are more likely to propose patch if they can be sure that the work has
| not yet been done.

i.e. e.g. for this use case patch-submitting instead of direct
committing was expected.

And this was the way it was used, although DD had commit-rights, they
would not do uncoordinated commits to master. There was no technical
barrier but a social one. Similar to package uploading. Technically
every DD has upload rights for everything, but we have a common ground
what is accepted there. The technical barriers are the same on salsa
as they were on alioth, the implicit barriers obviously have changed,
probably because forking and merge request for private projects is
easy now.

[...]
> But of course, the wiki docs can be improved, including by you :-)

I have updated the wiki, I am little bit more awake than yesterday.
;-)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: salsa.debian.org: merge requests and such

[Andreas Metzler]

Guillem Jover  wrote:
> On Tue, 2018-11-06 at 15:00:03 +, Matthew Vernon wrote:
[...]
>> that at least a MR is something I should have expected as a package
>> maintainer, not just commits to master?

> Assuming that packages is under the Salsa Debian namespace, then I
> think that's what you (perhaps unknowingly :) signed up for when
> adding a repo there. See the Collab-maint sections in:

>   

> and

>   
> 
[...]

Hello,

Could we document this a little bit better in the wiki? This is
completely different than on alioth, where collab-maint was suggested
for basically everything that did not need a mailinglist.
.

The dda-mail made this difference pretty clear:
| If you create a project within the Debian group, you are implicitly
| welcoming all DDs to contribute directly to the project.
But the wording cannot be copied over directly to the wiki, the
style's off. And I am too stupid right now to convert it. ;-)

cu And- plan for the weekend: move everything except qa away from
Debian/group - reas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: changing git tags on the remote repo

[Andreas Metzler]

Holger Wansing  wrote:
> I am curious about how to change an already existing git tag afterwards
> (means: change the commit it points to).

> Locally, I can change an existing tag, and then create it newly.
> But I cannot push it to the remote repo (get
> "! [rejected]139 -> 139 (already exists) "

> There is -f (--force) option to replace an existing tag and locally it seems
> to work, since it says 
> "Tag '139' updated (was 02108ec)"
> but the push to remote repo fails nevertheless.


> Any help?

Iirc you need to delete the remote tag first.
https://stackoverflow.com/questions/5480258/how-to-delete-a-git-remote-tag

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: improved alioth-salsa test script (calls for testing/improvements)s

[Andreas Metzler]

Holger Levsen  wrote:
> hi,

> maybe i'm stupid but i'm also failing now with my 3rd "quick" attempt of
> migration to salsa using the script...

> holger@moszumanska:~/alioth-migration$ ./migrate-repo -v -d 
> /srv/git.debian.org/git/collab-maint/anarchism.git /debian/anarchism

[...]
> (oh and the point of this mail is basically none. "it doesnt work for
> me", mostly just curious if i'm the only one who cant get it to work.
> But given i have limited time i guess i will just migrate my 20 or so
> repos manually, and save braincells for later. sorry to not being able
> to give better feedback.)

Hello Holger,

for "my" projects I have used import.sh from 
https://salsa.debian.org/mehdi/salsa-scripts.git
and never had any problems.

Afaict you have already deleted the repo, so
https://salsa.debian.org/debian/anarchism
Overview -> Details -> [Import repository] 
with https://anonscm.debian.org/git/collab-maint/anarchism.git
should just work now.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Andreas Metzler]

Tobias Frost  wrote:
> On Mon, Apr 16, 2018 at 08:28:08AM +0800, Rolf Leggewie wrote:
>> https://anonscm.debian.org/gitweb/?p=collab-maint/gjots2.git

> You know that collab-maint stands for "Collaborative Maintaince"?

> IMHO by placing it into collab-maint, everyone is allowed / suggested
> to work on those packages. If you don't want that, don't go there.

That is not my understanding. alioth/collab-maint and its successor
salsa/debian simply provide a public GIT repository without the need
to set up a separate salsa project.

See https://wiki.debian.org/Alioth/PackagingProject

The fact that *technically* every DM has write permission on the repo
does not make committing permitted. There is just no technical barrier,
only the social one.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Debian Policy 4.1.4.0 released

[Andreas Metzler]

Ole Streicher  wrote:
> Sean Whitton  writes:
>> On Sat, Apr 07 2018, Ole Streicher wrote:
[...]
>>> Sure, but why do we give up a common rule? I think the cases where
>>> d/watch does not work are not so rare (at least I have quite a number
>>> of them), and keeping them unified is not the worst thing we can do.

>> See discussion in #515856.

> Maybe I didn't read it too carefully, but I didn't find the argument why
> get-orig-source is not kept for the cases where uscan doesn't do the
> job.

> And when I extrapolate from my packages, this is not an exceptionally
> rare case.

Imho Sean's last mail sums it up pretty well
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515856#94

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: "apt-get source snappy" pulls Extra-Source-Only 1.1.4-1 in Debian-Stretch?

[Andreas Metzler]

In gmane.linux.debian.devel.general Philipp Hahn  wrote:
> Hello APT developers,

> today I encountered the strange situation, that Debian-Stretch
> officially has 1.1.3-3, but if I do a "apt-get source snappy" I get 1.1.4-1:
[...]

> So how can I tell "apt-get source" to pull the "right" version, e.g. the
> version "libsnappy1v5" was built from?

>> $ LANG=C apt-cache policy libsnappy1v5
>> libsnappy1v5:
>>   Installed: 1.1.3-3
>>   Candidate: 1.1.3-3
>>   Version table:
>>  *** 1.1.3-3 500
>> 500 http://deb.debian.org/debian stretch/main amd64 Packages
>> 100 /var/lib/dpkg/status

> This looks like a bug in APT and did I miss something?

apt-get source does not care which version is installed.
from apt-get(8)
| APT will examine
| the available packages to decide which source package to fetch. It
| will then find and download into the current directory the newest
| available version of that source package ...

-t stretch or libsnappy1v5=1.1.3-3 will probably work.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Repackaging upstream source with file modifications?

[Andreas Metzler]

Dimitri John Ledkov  wrote:
> On 12 February 2018 at 10:28, Colin Watson  wrote:
[...]
>> My recent attempt to upload grub2 2.02-3 was rejected due to
>> https://bugs.debian.org/745409, which I admit I've been putting off
>> dealing with for a while; but the relevant tag
>> (license-problem-non-free-RFC) was added to the ftpmaster auto-reject

> I believe this tag to be a false positive in this case.

> Whilst RFC text themselves are not-free, the code components of an RFC
> are free under a 3-clause BSD like license.

> I only see code components in the grub2 package and no RFC text.

> http://trustee.ietf.org/license-info/IETF-TLP-5.htm Section 4 License
> to Code Components

Hello,

I do not think so. The respective code is from rfc1952 (May 1996). The
code component exception applies from Nov 2008 onwards. 
See https://trustee.ietf.org/copyright-faq.html 5.1:
Afaiui parts from older rfc are unusable.

cu Andreas
PS: I would love to be wrong on this.
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Andreas Metzler]

Dr. Bas Wijnen  wrote:
> On Fri, Dec 29, 2017 at 10:43:58PM +0100, Alexander Wirt wrote:
>> On Fri, 29 Dec 2017, Philipp Kern wrote:
>> > Put a mapping into a git repository that DDs can push to? Make sure that
>> > it is fast-forwarded always? Then let people deal with it?
>> I am currently working on such a mapping. 

> I appreciate your work, but this doesn't seem all that useful to me.  If DDs
> can push the mapping, can't they just as well upload a new package with the
> fields in the control file updated?

Compare:

a) uploading and building 400 packages.
b) checkout git repository
   copy list of old git repositories from tracker, search/replace
   commit and push

Thanmks Alexander!

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: ftp master uploads disappearing?

[Andreas Metzler]

Andreas Tille  wrote:
[...]
> To answer Mattias question why not using source uploads all the time:
> Once I have build the package to see whether all those lintian issues
> are fixed I want to fix I have a sensible package to upload and somehow
> this workflow to upload what is just there remains.
[...]

Hello,

I am also doing regular local builds, because I like being able to
a) use debdiff to the previous upload and b) compare buildlogs.

This is not a blocker for source-only uploads, though, you can generate
a source-only changes file from the full_build_changes file like this:

mergechanges --source -f exim4_4.89-7_amd64.changes exim4_4.89-7_amd64.changes

hth, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Alioth: the future of mailing lists

[Andreas Metzler]

On 2017-09-17 Alexander Wirt  wrote:
[...]
>   - Distribution lists for use in the Maintainer: field.  We suggest
> that, with maybe some extra code, this use-case could be well served
> by the tracker.debian.org service for almost all purposes.  For
> larger teams, such as the Debian Perl Group, a list on lists.debian.org
> might be another option.
[...]
> Proposed Timeline:
>  * 2018-02-01: mailing lists on Alioth are disabled; incoming mail is
>no longer accepted.

Hello,

thanks for the heads-up.

The maintainer e-mail address is listed not only on packages.debian.org
but also on "dpkg -s ..." et. al. Users send support e-mail there. Imho
either the mailing lists need to run a lot longer (possibly until
stretch EOL) or (prefered) the old list-address should redirect to the
new one.

>  * May 2018 (with the wheezy EOL): alioth is shut down; mailing list
>archives are unavailable.  (A static export/dump will be provided
>in some convenient location.)

Would it be possible to keep the list-archives online, indexed by
search-engines? These are static pages, aren't they? There is some
interesting information there and removal from the web makes it hard
to find.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Please add lzip support in the repository

[Andreas Metzler]

Adrian Bunk  wrote:
> On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
[...]
>> So, it would make more sense to have a par2 (or create a modern version
>> of it, actually) ECC layer on top of the compression layer, at which
>> point we can use one of the already supported compression formats.
>>...

> A digital signature is an ECC layer.

Hello,
I do not think so. A digital signature will only help with error
/detection/ but not *correction*.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Fwd: Mail delivery failed: returning message to sender

[Andreas Metzler]

Niels Thykier  wrote:
> Andreas Metzler:
[...]
>> No, the encoding was not correct. Compare how you (your MUA) just did it in
>> this message with the rejected one.

>>   From: =?UTF-8?Q?TOMAS_MARTI=c5=a0IUS?= 

>>   From: =?utf-8?b?VG9tYXMgTWFydGnFoWl1cyA8dG9tYXNAcHVnYS52ZHUubHQ+?=
[...]

> Hi,

> The latter is "simply" a base64 encoding:

> $ echo 'VG9tYXMgTWFydGnFoWl1cyA8dG9tYXNAcHVnYS52ZHUubHQ+' | base64 -d
> Tomas Martišius 
[...]
> I am not an expert on permitted ways of quoting UTF-8 in mail
> headers, but the base64 method does not seem entirely inconceivable
> for some RFC to support that (especially not considering you can
> encode the body with base64).

Whether VG9tYXMgTWFydGnFoWl1cyA8dG9tYXNAcHVnYS52ZHUubHQ+ can be
/decoded/ to something that contains a mail-address is not relevant. The
header 

  From: =?utf-8?b?VG9tYXMgTWFydGnFoWl1cyA8dG9tYXNAcHVnYS52ZHUubHQ+?=

does not fullfill the syntax required by RFC 2822. These syntax
requiremts apply to the (possibly rfc2047-) *encoded* field contents,
not to the decoded values.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Fwd: Mail delivery failed: returning message to sender

[Andreas Metzler]

On 2016-12-28 TOMAS MARTIŠIUS  wrote:
> 2016.12.28 09:09, Andreas Metzler rašė:
>> On 2016-12-27 TOMAS MARTIŠIUS  wrote:
>>> Why I can't report bug using reportbug command? After reporting I get back
>>> e-mail with this message:
[...]
>> The From header does not look too good:

>>> From: =?utf-8?b?VG9tYXMgTWFydGnFoWl1cyA8dG9tYXNAcHVnYS52ZHUubHQ+?=

> But I am not only english speaking man, so there are UTF-8 chars in my
> last name. Thats why subject is encoded. And it is encoded in standard
> way, using reportbug command.

> It seams that if someone using UTF-8 in his name and wants report bug - it
> has a problems.

> I think this is totally bad for debian community - we are losing important
> bug reports.
[...]

Hello,

No, the encoding was not correct. Compare how you (your MUA) just did it in
this message with the rejected one.

  From: =?UTF-8?Q?TOMAS_MARTI=c5=a0IUS?= 

This matches

from=   "From:" mailbox-list CRLF
mailbox-list=   (mailbox *("," mailbox)) / obs-mbox-list
mailbox =   name-addr / addr-spec
name-addr   =   [display-name] angle-addr
angle-addr  =   [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
display-name=   phrase
obs-angle-addr  =   [CFWS] "<" [obs-route] addr-spec ">" [CFWS]
addr-spec   =   local-part "@" domain

in RFC 2822. There is an addr-spec (to...@puga.vdu.lt) and a
display-name ("=?UTF-8?Q?TOMAS_MARTI=c5=a0IUS?=). The rejected message
OTOH has no valid e-mail adress.
 From: =?utf-8?b?VG9tYXMgTWFydGnFoWl1cyA8dG9tYXNAcHVnYS52ZHUubHQ+?=

FWIW I just used reportbug to generate a test-bugreport (with 8-bit
characters in the submitter name), and reportbug generated a correctly
encoded.

Please submit a bug-report against reportbug if there is an easy way to
reproduce the issue.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'