Bug#1061344: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)

[Charles Plessy]

Hi Andreas,

I agree that we can remove EMBOSS in all 32-bit platforms.  I think that
a large fraction of the scientific field has no appetite to do any extra
volunteer work to such as accepting our patches to support scientific
computations on 32-bit systems in 15 years...

Have a nice day,

Charles

Bug#1049459: reverse dependencies

[Charles Plessy]

> Le Sat, Dec 02, 2023 at 01:34:39PM +, Thorsten Alteholz a écrit :
> > 
> > # Broken Build-Depends:
> > courier: mime-support
> > jool: mime-support
> > node-mime-types: mime-support

Hi Thorsten,

happy new year!

each packages above has been fixed by you, me, or their maintainer.

I am looking forward seeing the end of the mime-support transition !

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1057703: Please stop build-depending on mime-support

[Charles Plessy]

Le Thu, Dec 07, 2023 at 08:14:30PM +0900, Charles Plessy a écrit :
> 
> Please either drop the build-depend on mime-support or replace it by
> media-types.
> 
> If you are busy I can offer to NMU your package.  I would like to remove
> mime-support from the archive.

Dear Alberto,

unless you object, I intend to upload the fix to DELAYED/8 soon.

Have a nice day,

Charles

Bug#1057702: Please build-depend on media-types instead of mime.support

[Charles Plessy]

Le Thu, Dec 07, 2023 at 08:10:49PM +0900, Charles Plessy a écrit :
> 
> the file /etc/mime.types is now provided by the package media-types.
> Please build-depend on it instead of media.types.
> 
> If you are busy I can offer to NMU your package.  I would like to remove
> mime-support from the archive.

Dear Markus,

unless you object, I will soon upload to DELAYED/8.

Have a nice day,

Charles

Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)

[Charles Plessy]

Hi Graham and Andreas,

Le Thu, Dec 07, 2023 at 01:37:02PM -0100, Graham Inggs a écrit :
> 
> Also, why do r-bioc-netsam and r-bioc-org.hs.eg.db not even appear on
> the tracker?

I do not know for r-bioc-netsam, but for r-bioc-org.hs.eg.db and similar
packages, it is because it is an "annotation package" made of data and
therefore not managed the same way as the other Bioconductor packages.

This is why it DESCRIPTION file does not mention its Bioconductor Git
branch.  This is also why its version number matches the Bioconductor
release number.  Also, its homepage resolves to
https://bioconductor.org/packages/release/data/annotation/html/org.Hs.eg.db.html
while for regular packages there is no data/annotation/html in the URL.

I think that it does not have to depend on the bioc api pseudo-package.

I hope it helps,

Charles

Bug#1049459: reverse dependencies

[Charles Plessy]

Le Sat, Dec 02, 2023 at 01:34:39PM +, Thorsten Alteholz a écrit :
> 
> # Broken Build-Depends:
> courier: mime-support
> jool: mime-support
> node-mime-types: mime-support

Thanks Thorsten for the heads-up,

I had forgotten about reverse build-depends…

I just submitted bugs against courier and jool.  Can I ask you to fix
node-mime-types?  You are Uploader of it…

Looking at the source code, it seems that node-mime-types does not need
mime-support at all.  But if it does please build depend on media-types
instead.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1057703: Please stop build-depending on mime-support

[Charles Plessy]

Source: jool
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Alberto,

mime-support is a transitional package replaced by media-types.  It
provides the file /etc/mime.types.  But looking at the source code of
jool, it seems that you do not need it at all.

Please either drop the build-depend on mime-support or replace it by
media-types.

If you are busy I can offer to NMU your package.  I would like to remove
mime-support from the archive.

Have a nice day,

Charles

Bug#1057702: Please build-depend on media-types instead of mime.support

[Charles Plessy]

Source: courier
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Markus,

the file /etc/mime.types is now provided by the package media-types.
Please build-depend on it instead of media.types.

If you are busy I can offer to NMU your package.  I would like to remove
mime-support from the archive.

Have a nice day,

Charles

Bug#1054657: transition: r-bioc-biocgenerics

[Charles Plessy]

Le Wed, Nov 22, 2023 at 08:46:17PM +0100, Andreas Tille a écrit :
> Control: tags -1 - moreinfo
> 
> r-bioc-sparsearray is accepted in unstable.

Hello everybody,

would it be possible to have an estimation about when we can expect to
start the Bioconductor transition ?  I am contributing to Debian mostly
on my work time and it would be super useful for me to have this
information in order to better integrate it in my planning.

Regarding my unavailable dates: it is Dec 2nd to 11th, and 23rd to Jan
8th.

The next Bioconductor release has not been announced but will probably
take place in April or May 2024.  As time passes I am starting to wonder
if we should just skip the current one...

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1049459: RM: mime-support -- ROM; Transition over

[Charles Plessy]

Control: tag -1 - moreinfo

Dear Scott,

the transition is over; to the best of my knowledge, no package depends
exclusively on mime-support, and in all alternatives it comes second
after media-types.

Please remove mime-support.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1054657: transition: r-bioc-biocgenerics

[Charles Plessy]

Le Fri, Nov 10, 2023 at 11:30:13PM +0100, Sebastian Ramacher a écrit :
> 
> Can you please clarify whether you are talking about new dependencies or
> reverse dependencies above? Thanks.

Hi Sebastian,

I am talking about the reverse-dependencies of the packages that we need
to upload to NEW.  These are new dependencies of packages that need to
go through the Bioconductor transition.

Here is an example:

In Bioconductor 3.17, the new package S4Arrays was depended on by
DelayedArray.  This reverse dependency of a new package in Bioconductor
is a new dependency on a new package in Debian (r-bioc-delayed array
started to depend on r-bioc-s4arrays).  The upload of r-bioc-s4arrays
during the 3.17 transition is one of the causes of the delays.

Last week I thought that looking at the reverse-dependencies of packages
that are new in Bioconductor 3.18 would be a good heuristic to find if
we will need to introduce new packages in Debian.  This is the main
reason I expresesd my thoughts in terms of reverse-dependency of new
packages, instead of new dependencies on new packages.  However
yesterday me and Andreas figured out that this was not a good heuristic.

Here is an example:

In Bioconductor 3.18, DelayedArray starts to depend on SparseArray.
However, SparseArray is not new in Bioconductor 3.18.  It was
introudced in Bioconductor 3.17 but we did not notice and package it
because nothing was depending on it.

In conclusion, taking the point of view of reverse-dependencies of new
packages in Bioconductor was not as fruitful as I thought and I will try
to stick to the point of view of new dependencies on new packages in
Debian to avoid further confusions.

I hope it clarifies.

-- 
Charles

Bug#1054657: transition: r-bioc-biocgenerics

[Charles Plessy]

Hi Paul and everybody,

we are finding a way to compare the R dependencies of the Bioconductor
packages in Debian and in Bioc 3.18.  It uncovers some core packages
introduced in Bioc 3.17, but which only start to have
reverse-dependencies in 3.18, meaning that they are not in Debian yet
since we did not have a reason to package them at that time.

It seems that I was too confident that no new core dependencies would be
introduced, and I feel guilty for that.  Still I need to add that
despite the stress on both sides, I really would like no not be told "We
do not care about [the information you sent]" again, while "I am sorry
but I do not see the relevance" or "I am sorry but this is not enough"
is so much more informative and less conflictual.  I did appreciate a lot
the care you took in expressing your criticisms in your email yesterday.

We will complete the checks and package the new dependencies and submit
the to NEW next week.  I suppose that we just have to go through he
whole process and notify you when it is done?

Have a good week-end,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1054657: transition: r-bioc-biocgenerics

[Charles Plessy]

Le Thu, Nov 09, 2023 at 02:01:57PM +0100, Paul Gevers a écrit :
> 
> The first and foremost reason why we're not enthusiastic about defaulting to
> removal of packages from testing is that that's a disservice to our users of
> testing.

Hi Paul,

I understand that you feel responsible for the state of testing, but
please consider that the r-bioc-* package users are our users too.  Some
of them are our colleagues, or our friends.  Those who we do not know,
we see their blogs, their toots, their Dockerfiles.  We meet them at
conferences.  We also feel responsible and we have the intuition that
having the packages absent from testing for a couple of weeks is not
going to cause too much trouble.

> I have the *feeling* (which might be unjust, but then consider past
> interactions) that we often need to tell you about issues and how to solve
> them.

A lot of the issues are due to continuous integrations tests, where we
uncover bugs on architectures unsupported upstream (who only builds on
amd64 and Apple arm64).  One of the reasons we sometimes take time to
make a visible action in response to CI failures is that we, like you,
are limited in our time.  But if this is important for you we can surely
write ack messages faster.

> If the r-bioc team were to actively monitor the situation

I read the R and Bioc devel mailing list.  I am upstream developer of a
Bioconductor package.  Yes, I have been caught by surprise in the last
transition by the addition of new packages at the core of the dependency
tree.  Yes, reputation is easy to lose and hard to gain.  If I tell you
that I have been more careful because I wanted to avoid it to happen
again, you are free to think that the previous mistake proves my
incompetence, and that it means that my care and monitoring are useless.
This is what I feel when I see the new request from your team coming at
the last minute and not as a debriefing of the previous transition.

> Several other ecosystems, e.g. perl, python and ruby, do preparation outside
> of the Debian archive and often have some idea (or know quite well) of what
> to expect during the transition. It's that pro-activeness that makes a
> difference to us; it *sounds* much better than "let's start and find out how
> much work it is". Maybe it's just the tone, but we're all humans.

Please trust us this time, and if you think that next time you need to
monitor our monitoring, I can for instance toot regularly under a
pre-decided hashtag about our preparation and you can review it at the
time of the transition, (in about 5 months; the clock is ticking).

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1054657: transition: r-bioc-biocgenerics

[Charles Plessy]

Le Tue, Nov 07, 2023 at 10:53:00AM +0100, Sebastian Ramacher a écrit :
> 
> We do not care about new reverse dependencies.

Hi Sebastian,

I am sorry that the information that I sent appears to have wasted your
time.  I still think that it does have some relevance, but I probably
did not explain my thougts well, and I worry that you have no appetite
for reading a longer version.

By the way, I work in a multicultural environment where most people are
not native speakers of English and we take great care of not hurting
each other in our oral and written communications.  Nobody would ever
start an answer like you did, and I feel like saying that I am not used
any more to that kind of communication.  Hence the unease that you can
probably feel from my reply.

> We care about new dependencies of packages currently in the archive.
> So what's the status of new the dependencies?

The tools available to us to answer your question are quite inexistant.
Until now we would just wait for the release team's green light to
ensure that we do not disturb other transitions.  The previous one was
more painful than usual, but in our experience it is quite rare.  I wish
you would trust our word instead of requiring quantitative evidence.

One possible direction would be to leverage the work done by Dirk and
others in r2u, where the Bioc transition is over, and for each package
in Debian, look if the r2u equivalent has a dependency not in Debian.

https://fediscience.org/@eddelbuettel@mastodon.social/111359074099802189

Still, that is quite an extensive amount of work, only to ensure that
the risk of asking the FTP team to fast-track a package is lowered to a
minimum.  We have done such requests in the past, and the response was
usually cheerful so unless you received complains form the FTP team, may
I suggest that you might be worrying too much?  And again, we are not
under the impression that this transition will be as demanding as the
past one.

Please let me I ask again for your kind understanding and allow us to do
the transition despite not being able to tell you if and how much the
transition will require the processing of packages through the NEW
queue.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1005644: Intent to NMU pillow (Re: Bug#1005644: python3-pil: should depend on "media-types | mime-support")

[Charles Plessy]

Le Wed, Oct 25, 2023 at 10:23:44PM +0900, Charles Plessy a écrit :
> 
> I intend to NMU pillow to DELAYED/15 soon, unless you plan to remove the
> dependency on mime-support by yourself in a reasonable delay.

Hello Matthias,

I uploaded to DELAYED/15 on the 29th.  Here is the debdiff.

$ debdiff pillow_10.0.0-1.dsc pillow_10.0.0-1.1.dsc
diff -Nru pillow-10.0.0/debian/changelog pillow-10.0.0/debian/changelog
--- pillow-10.0.0/debian/changelog  2023-07-06 01:58:54.0 +0900
+++ pillow-10.0.0/debian/changelog  2023-10-29 08:05:25.0 +0900
@@ -1,3 +1,11 @@
+pillow (10.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Depend on media-types instead of mime-support.
+Closes:#987500, #1003934, #1005644
+
+ -- Charles Plessy   Sun, 29 Oct 2023 08:05:25 +0900
+
 pillow (10.0.0-1) unstable; urgency=medium

   * New upstream version.
diff -Nru pillow-10.0.0/debian/control pillow-10.0.0/debian/control
--- pillow-10.0.0/debian/control2023-06-12 16:30:52.0 +0900
+++ pillow-10.0.0/debian/control2023-10-29 08:04:20.0 +0900
@@ -23,7 +23,7 @@
 Package: python3-pil
 Architecture: any
 Multi-Arch: same
-Depends: ${python3:Depends}, mime-support | python3-pil.imagetk,
+Depends: ${python3:Depends}, media-types | python3-pil.imagetk,
   ${shlibs:Depends}, ${misc:Depends}
 Recommends: python3-olefile
 Suggests: python-pil-doc

Best regard,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1054657: transition: r-bioc-biocgenerics

[Charles Plessy]

> Am Wed, Nov 01, 2023 at 09:02:10AM -0100 schrieb Graham Inggs:
> > Again, we are not asking for the entire transition to happen in
> > experimental.  We are only asking for the NEW packages, so that NEW
> > processing happens before the transition, and not during.

Le Wed, Nov 01, 2023 at 11:28:38AM +0100, Andreas Tille a écrit :
> Understood this item now - but I'm lacking any clue how to find out
> what new packages are needed.

Hi Graham and Andreas,

I just finished inspecting by eye the homepage of each of the 69 new
Bioconductor packages.  None of them declare a reverse-dependency to
an existing Bioc package that we ship in Debian.  Therefore, I do not
expect that this transition will require NEW processing.

https://bioconductor.org/news/bioc_3_18_release/

Graham, please let us know when we can start uploading.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1054657: transition: r-bioc-biocgenerics

[Charles Plessy]

Le Sun, Oct 29, 2023 at 02:57:01PM -0100, Graham Inggs a écrit :
> 
> No, after the NEW packages have cleared NEW and the moreinfo tag is
> removed, we'll consider a slot for the transition.  We would like to
> avoid stalling the transition with multiple packages going through
> NEW, and putting pressure on FTP Masters by telling them a package is
> needed for a transition is not nice either.

Hi Graham,

although the previous transition introduced a lot of NEW packages
transitively depending on each other, this was quite exceptional.  We do
not expect that core parts of the dependency chain will change again
this time.

With this in mind, can I ask why is it necessary to upload to
experimental first?  We never had to do it before, and it is a lot of
extra work.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1005644: Intent to NMU pillow (Re: Bug#1005644: python3-pil: should depend on "media-types | mime-support")

[Charles Plessy]

Le Sun, Feb 13, 2022 at 11:38:24AM +0100, Jörg-Volker Peetz a écrit :
> 
> since package mime-support is a transitional package, please change the
> dependency on "mime-support | python3-pil.imagetk" to "media-types |
> mime-support | python3-pil.imagetk".

Dear Matthias,

I intend to NMU pillow to DELAYED/15 soon, unless you plan to remove the
dependency on mime-support by yourself in a reasonable delay.

Cheers,

Charles, maintainer of the media-types, mailcap and mime-support
packages.

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1049459: RM: mime-support -- ROM; Transition over

[Charles Plessy]

Le Tue, Oct 10, 2023 at 06:56:43AM +0900, Charles Plessy a écrit :
> 
> python3-pil depends on mime-support | python3-pil.imagetk, and
> python3-pil.imagetk does not depend on mime-support, thus python3-pil is
> installable without mime-support, isn't it?
> 
> Could you please remove mime-support?

Shall I understand your silence as a "no?"

> I would like to finish this
> transition, to not have to think about it anymore, and focus on the
> future.
> 
> If you prefer I NMU pillow instead, please let me know.
> 
> Have a nice day,
> 
> Charles
> 
> -- 
> Charles Plessy Nagahama, Yomitan, Okinawa, Japan
> Tooting from work,   https://fediscience.org/@charles_plessy
> Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1049459: RM: mime-support -- ROM; Transition over

[Charles Plessy]

Dear Scott and Pino,

python3-pil depends on mime-support | python3-pil.imagetk, and
python3-pil.imagetk does not depend on mime-support, thus python3-pil is
installable without mime-support, isn't it?

Could you please remove mime-support?  I would like to finish this
transition, to not have to think about it anymore, and focus on the
future.

If you prefer I NMU pillow instead, please let me know.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1052137: run-mailcap.1: some remarks and editorial changes for this man page

[Charles Plessy]

Dear Bjarni,

thank you for your report about this manpage and the other ones of this
package.

I am considering refactoring the whole package as a Perl module that might
be called App::Mailcap, and as part of this the manual pages would be
converted to Perldoc format.  Therefore, I do not intend to take action
direclty on the currently nroff-formated manpages.

This said, if you send a proper patch or a merge request, I will surely
take your changes.

Have a nice day,

-- 
Charles

Bug#1009768: s3fs-fuse: Please replace mime-support with media-types in Depends

[Charles Plessy]

Hello,

s3fs-fuse is one of the last packages holding the mime-support
transition; I intend to NMU it soon with to close this bug.

Have a nice day,

Charles

Le Sun, Apr 17, 2022 at 02:32:04PM +0900, Charles Plessy a écrit :
> Source: s3fs-fuse
> Severity: normal
> X-Debbugs-Cc: ple...@debian.org
> 
> Dear s3fs maintainers,
> 
> In the previous release cycle, I have split the `mime-support` package
> into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
> the mailcap system.  `mime-support` is now a transitional package that
> I would like to remove from Debian.
> 
> May I ask you to replace mime-support with media-types in s3fs's Depends ?
> 
> Have a nice day,
> 
> Charles
> 
> --
> Charles Plessy Nagahama, Yomitan, Okinawa, Japan
> Tooting from work,   https://mastodon.technology/@charles_plessy
> Tooting from home,     https://framapiaf.org/@charles_plessy

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1009768: s3fs-fuse: Please replace mime-support with media-types in Depends

[Charles Plessy]

Le Sun, Apr 17, 2022 at 02:32:04PM +0900, Charles Plessy a écrit :
> 
> In the previous release cycle, I have split the `mime-support` package
> into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
> the mailcap system.  `mime-support` is now a transitional package that
> I would like to remove from Debian.
> 
> May I ask you to replace mime-support with media-types in s3fs's Depends ?

Dear Andrii,

I see that you have patched your package in your VCS; thank you for
this.

I would like to complete the transition, may I ask you to upload soon?
Or may I offer my help with a NMU ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#980347: Please Recommend mailcap instead of mime-support

[Charles Plessy]

Le Mon, Jan 18, 2021 at 07:54:19AM +0900, Charles Plessy a écrit :
> 
> I have recently split the `mime-support` package into two: `mailcap` for
> the mailcap system, and `media-types` for providing `/etc/mime.types`
> to allow minimal systems without `mailcap`.
> 
> The `mailcap` package depends on `media-types` replaces `mime-support`,
> which now a transitional package, and it would be great if users could
> be able to remove it after the _Bookworm_ release.
> 
> Please Recommend `mailcap` instead of `mime-support`.

Dear William,

to complete the transition I intend to NMU unless you object with a
timeline.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1009771: netsurf: Please replace mime-support with media-types or mailcap in Recommends

[Charles Plessy]

Le Sun, Apr 17, 2022 at 02:48:31PM +0900, Charles Plessy a écrit :
> 
> In the previous release cycle, I have split the `mime-support` package
> into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
> the mailcap system.  `mime-support` is now a transitional package that I
> would like to remove from Debian.
> 
> According to your needs, can you replace mime-support with media-types
> or mailcap in netsurf's Recommends ?

Hello,

To complete the transition, I intend to NMU netsurf soon unless you
object with a timeline.

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1049459: RM: mime-support -- ROM; Transition over

[Charles Plessy]

Dear Scott,

I just saw your "moreinfo" tag.

I forgot to mention in the bug that I have a wiki page tracking final
stage of the transition:

https://wiki.debian.org/mime-support

Please let me know if you need more information or if you would prefer
me to NMU the unresponsive packages before you remove mime-support.

Have a nice day,

-- 
Charles

Bug#1050481: Please depend on media-types or mailcap instead of mime-support

[Charles Plessy]

Package: pygopherd
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear John,

the mime-support package on which pygopherd depends is a transition
package that was superseded by media-types, providing /etc/mime.types,
and mailcap, providing the mailcap system.

I need you to update the dependency in order to complete the transition.

Have a nice day,

-- 
Charles

Bug#1041556: [R-pkg-team] Bug#1041556: What is the architecture name in R what we call armel/armhf

[Charles Plessy]

Le Thu, Aug 17, 2023 at 07:52:35AM +0200, Andreas Tille a écrit :
> 
>   arch <- R.version$arch
>   identical(arch, "i386") || identical(arch, "i686") || identical(arch, 
> "armel") || identical(arch, "armhf")

Hi Andreas, how about:

system("dpkg-architecture -qDEB_BUILD_ARCH", intern=TRUE) %in% c("i386", 
"i686", "armel", "armhf")

Have a nice day,

-- 
Charles

Bug#1049459: RM: mime-support -- ROM; Transition over

[Charles Plessy]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: mime-supp...@packages.debian.org
Control: affects -1 + src:mime-support

Dear FTP team,

please remove mime-support (binary and source) from trixie.

The transition from mime-support to media-types and mailcap was started
in 2020.  There are only a handful of packages (to the best of my
knowledge: s3fs, ytree, netsurf, pygopherd) that still depend or
recommend it, and for each of them except pygopherd (sorry) a bug was
open more than a year ago.

Removing media-types will close the transition.  It will also break the
packages above, but the fix is trivial and I can NMU if needed.

Have a nice day,

Charles

Bug#1042776: [R-pkg-team] Bug#1042776: Bug#1042776: r-bioc-deseq: still depends on obsolete r-api-bioc-3.16

[Charles Plessy]

Le Tue, Aug 01, 2023 at 09:29:59AM +0900, Charles Plessy a écrit :
> 
> the DESeq Bioconductor package was removed from the 3.17 release
> upstream.  I think that we can remove it from unstable and testing too.
> 
> I will fill a removal later today.

Actually it was removed from BioC 3.10 and the fix is easy, so I just
uploaded a fixed version.

I will still fill a removal unless somebody objects.  The replacement
package, r-bioc-deseq2, is well established and I am not aware of
people or pipelines using the old version.

I note that the med-bio-dev metapackage will need to be updated
accordingly.  I can to so after my joini request is accepted.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home, https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1042776: [R-pkg-team] Bug#1042776: r-bioc-deseq: still depends on obsolete r-api-bioc-3.16

[Charles Plessy]

Le Mon, Jul 31, 2023 at 09:46:48PM +0200, Andreas Beckmann a écrit :
> 
>   The following packages have unmet dependencies:
>r-bioc-deseq : Depends: r-api-bioc-3.16 but it is not installable

Dear Andreas,

thanks for the catch,

the DESeq Bioconductor package was removed from the 3.17 release
upstream.  I think that we can remove it from unstable and testing too.

I will fill a removal later today.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1039926: Will file bug report for complete R transition (Was: Bug#1039926: svglite requires rebuild under R 4.3.*)

[Charles Plessy]

Hi all,

pardon me the offence and the noise, but I asked ChatGPT...

--

Me:

In Debian, updates of the r-base package sometimes break backwards
compatibility with a small number of binary packages shipping CRAN
packages, which have in common to use R’s graphic API. We hesitate
between just bumping the version number of the r-base packages’ API, or
to create a new API version scheme just for the subset of packages that
are regularly broken. Which way would you recommend?

ChatGPT:

Creating a new API version scheme just for the subset of packages that
are regularly broken might be a more efficient solution. This way, you
can manage the updates for these specific packages separately without
affecting the entire r-base package. However, this approach might
require more maintenance work. Bumping the version number of the r-base
packages' API is a simpler solution, but it might cause unnecessary
updates for packages that are not affected by the compatibility issue.
It's a trade-off between complexity and efficiency, and the best choice
depends on the specific circumstances and resources available.

--

Sorry that it was not conclusive !

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1028631: media-types: rss is associated with application/x-rss+xml instead of application/rss+xml

[Charles Plessy]

Le Thu, May 18, 2023 at 02:54:10PM +0200, Patrice Duroux a écrit :
> 
> Maybe it should be redirected to the members of the RSS Advisory Board, right?
> I think that I'm not a relevant contact to apply for such a media type. I will
> not be able to exchange and provide additional information.

Hi Patrice,

you can also submit a media type on behalf of others. I did it for
text/gff3.  If you can not contact the members of the RSS Advisory
Board (which seems inactive), I think that you have good grounds to fill
the registration form by yourself.

> Also, if the content of etc/mime.types is based on the IANA one[1], then why 
> it
> provides this 'application/x-rss+XML' entry? What for?

It looks like somebody convinced the previous maintainer to remove
application/rss+XML in favour of the unregistered one!

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605250

10 years later, that surely does not look like it was the best choice…

But please give a try to the IANA registration.  It is way easier than
10 years ago.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1028631: media-types: rss is associated with application/x-rss+xml instead of application/rss+xml

[Charles Plessy]

Hi Patrice,

maybe you or someone else can register the media type to the IANA based
on the expired IETF draft and see if it goes?

In any case, we have time as Debian is currently frozen...

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1028631: media-types: rss is associated with application/x-rss+xml instead of application/rss+xml

[Charles Plessy]

Dear Giuseppe,

thank you for your report,

registration to IANA is not difficult, can you find somebody who is
willing to do it ?

https://www.iana.org/form/media-types

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#978984: media-types: /etc/mime.types reported as oldconfig

[Charles Plessy]

Le Sun, Dec 25, 2022 at 10:58:12AM +0200, Martin-Éric Racine a écrit :
> 
> Where? What was the explanation?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886389#45

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1009118: [Debian-med-packaging] Bug#1009118: python3-biopython: incompatible with muscle >= 5

[Charles Plessy]

Hello everybody,

I have read the Muscle5 paper and it is a totally different program than
Muscle3.

https://pubmed.ncbi.nlm.nih.gov/36379955/

Reintroducing muscle3 as a separate package might be useful not only to
Biopython, but also to the people who need it in pipelines, etc.

Have a nice day,

Charles

Bug#1024700: radosgw: Replace transition package mime-support with media-types.

[Charles Plessy]

Package: radosgw
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Hello,

can you replace the transition package `mime-support` with `media-types`
in the control file of radosgw ?

The `media-types` package was split out of `mime-support` during the
previous release cycle and distributes the `/etc/mime.types` file.

In case it helps I prepared a Merge Request on Salsa:

https://salsa.debian.org/ceph-team/ceph/-/merge_requests/8

Have a nice day,

-- 
Charles

Bug#1022307: [Debian-med-packaging] Bug#1022307: status on t_coffee causing biopython ftbfs

[Charles Plessy]

Le Tue, Nov 22, 2022 at 11:54:48PM +0100, Étienne Mollier a écrit :
> 
> Hi, mostly retitling the open entry against biopython for the
> sake of clarity, and also pinging both bugs to reset auto-
> removal counters.  We don't have much news from t_coffee
> upstream to day unfortunately.  Maybe it will be necessary to
> revert the t-coffee version bump for the upcoming Debian release
> or do people see other options?

Hi Étienne,

I think that we do not have enough evidence that t_coffee was properly
tested on other architectures than amd64.  Even though a particular
version may build fine, and let biophython pass its tests, we do not
know if t_coffee produces sound results on these architectures.  Unless
we know or hear from an ARM user, I would recommend to play safe and
only distribute it on amd64 for this release.

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1023230: [Debian-med-packaging] Bug#1023230: t-coffee breaks libbio-tools-run-alignment-tcoffee-perl autopkgtest: test times out after 2:47 hours

[Charles Plessy]

Le Mon, Oct 31, 2022 at 09:27:47PM +0100, Paul Gevers a écrit :
> 
> https://ci.debian.net/data/autopkgtest/testing/arm64/libb/libbio-tools-run-alignment-tcoffee-perl/27686780/log.gz
> 
> autopkgtest [11:59:24]: ERROR: timed out on command "su -s /bin/bash debci

Hi all,

I think that t-coffee never worked on ARM.  It built, but never worked.
The simplest would be to distribute it only on amd64.

See https://bugs.debian.org/631249

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1021971: python3-pychopper: New upstream release available, but routine-update fails.

[Charles Plessy]

Package: python3-pychopper
Version: 2.5.0-1
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Hi all, I just tried to routine-update python3-pychopper but it failed.
I do not have time to troubleshoot further.  I am pasting the error so
that you can prepare before picking the ball.

Cheers,

-- Charles

dh_auto_test -- --system=custom --test-args="PYTHONPATH={build_dir} 
{interpreter} -m pytest -v"
pybuild --test --test-pytest -i python{version} -p 3.10 --system=custom 
"--test-args=PYTHONPATH={build_dir} {interpreter} -m pytest -v"
I: pybuild base:240: 
PYTHONPATH=/home/charles-plessy/Debian/python3-pychopper/.pybuild/cpython3_3.10_pychopper/build
 python3.10 -m pytest -v
= test session starts ==
platform linux -- Python 3.10.7, pytest-7.1.2, pluggy-1.0.0+repack -- 
/usr/bin/python3.10
cachedir: .pytest_cache
hypothesis profile 'default' -> 
database=DirectoryBasedExampleDatabase('/home/charles-plessy/Debian/python3-pychopper/.hypothesis/examples')
rootdir: /home/charles-plessy/Debian/python3-pychopper, configfile: pytest.ini, 
testpaths: pychopper
plugins: openfiles-0.5.0, remotedata-0.3.3, arraydiff-0.5.0, cov-4.0.0, 
xonsh-0.13.3, hypothesis-6.36.0, timeout-2.1.0, xdist-2.5.0, mock-3.8.2, 
forked-1.4.0, doctestplus-0.12.1
collecting ... collected 4 items

pychopper/tests/test_detector.py::TestDetector::testPairAlign PASSED [ 25%]
pychopper/tests/test_detector.py::TestDetector::testScoreCutoff PASSED   [ 50%]
pychopper/tests/test_regression_simple.py::TestIntegration::testIntegration 
FAILED [ 75%]
pychopper/tests/test_regression_simple.py::TestIntegration::testIntegration_umi 
FAILED [100%]

=== FAILURES ===
___ TestIntegration.testIntegration 

self = 

def testIntegration(self):
""" Integration test. """
base = path.dirname(__file__)
test_base = path.join(base, 'data')

barcodes = path.join(test_base, 'barcodes.fas')
input_fasta = path.join(test_base, 'ref.fq.gz')
output_fasta = path.join(test_base, 'test_output.fq.gz')
expected_output = path.join(test_base, 'expected_output.fas')

subprocess.call("{} {} {} {} {}".format('pychopper', "-Y 0 -B 3 -q 0.5 
-m edlib -b", barcodes, input_fasta, output_fasta), shell=True)
retval = subprocess.call(['cmp', output_fasta, expected_output])
>   self.assertEqual(retval, 0)
E   AssertionError: 2 != 0

pychopper/tests/test_regression_simple.py:21: AssertionError
- Captured stderr call -----
/bin/sh: 1: pychopper: not found
cmp: 
/home/charles-plessy/Debian/python3-pychopper/pychopper/tests/data/test_output.fq.gz:
 No such file or directory
_ TestIntegration.testIntegration_umi __

self = 

def testIntegration_umi(self):
""" Integration test. """
base = path.dirname(__file__)
test_base = path.join(base, 'data')

input_fasta = path.join(test_base, 'PCS111_umi_test_reads.fastq.gz')
output_fasta = path.join(test_base, 'test_output_umi.fq.gz')
expected_output = path.join(test_base, 
'PCS111_umi_test_reads_expected.fastq')

subprocess.call("{} {} {} {}".format('pychopper', "-U -m edlib -k 
PCS111", input_fasta, output_fasta), shell=True)
retval = subprocess.call(['cmp', output_fasta, expected_output])
>   self.assertEqual(retval, 0)
E   AssertionError: 2 != 0

pychopper/tests/test_regression_simple.py:35: AssertionError
----- Captured stderr call -
/bin/sh: 1: pychopper: not found
cmp: 
/home/charles-plessy/Debian/python3-pychopper/pychopper/tests/data/test_output_umi.fq.gz:
 No such file or directory
=== short test summary info 
FAILED 
pychopper/tests/test_regression_simple.py::TestIntegration::testIntegration
FAILED 
pychopper/tests/test_regression_simple.py::TestIntegration::testIntegration_umi
= 2 failed, 2 passed in 0.10s ==
E: pybuild pybuild:379: test: plugin custom failed with: exit code=1: 
PYTHONPATH=/home/charles-plessy/Debian/python3-pychopper/.pybuild/cpython3_3.10_pychopper/build
 python3.10 -m pytest -v
rm -fr -- /tmp/dh-xdg-rundir-MUPdeGOd
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 
--system=custom "--test-args=PYTHONPATH={build_dir} {interpreter} -m pytest -v" 
returned exit code 13
make[1]: *** [debian/rules:29: override_dh_auto_test] Error 25
make[1]: Leaving directory '/home/charles-plessy/Debian/python3-pychopper'
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: de

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Charles Plessy]

Hi Russ and Gregor,

thanks for your feedback,

I think that I made most of the points I was thinking about and hope
that some of them related to Simple English and jargon can be useful in
the future.  I also understand your point of view.  One final comment I
would like to make is that the format is used in other contexts, such as
Apt (using "paragraph" in https://wiki.debian.org/DebianRepository/Format),
DEP-11 (using "block" in https://wiki.debian.org/DEP-11), and probably
other files generated for the Debian archive.  I recommend to keep
producers and consumers of these files in the loop before changing
Chapter 5.  As for on which word to standardise on, I trust the Policy
Editors to make a good choice, even if it is not my favourite.

Have a nice week-end,

-- 
Charles

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Charles Plessy]

Hi Russ,

Le Tue, Sep 20, 2022 at 06:08:16PM -0700, Russ Allbery a écrit :
> 
> I do find the use of paragraph the way we were previously using it to
> be confusing, particularly given that the paragraphs contain fields
> which in turn contain actual paragraphs in the normal sense of the
> term.

> I don't want to keep using paragraph, but I'd be open to some other term
> that Guillem was also open to (I think matching the terminology in dpkg is
> very important).  Section or block are commonly used for things like this,
> but aren't very precise, so I'm not that enthused by them.

In the spec, the word "paragraph" is only used in the specified context,
so I always felt that there is no ambiguity.  But of course, it can
create opportunities for misunderstanding when discussing about the
spec.  So point taken about "paragraph", although interestingly, the
Simple English definition of "paragraph" is quite spot on if one would
replace "sentence" with "field": ”one or more sentences that are written
together with no line breaks separating them.  Usually they are
connected by a single idea.” ()

The use of "paragraph" in the current spec is also consistent with
Chapter 5 of the Policy, which also uses the word "paragraph".  By the
way, in section 5.6.26 of the Policy, the word "stanza" is also used to
mean something else than a "paragraph".

I do not mind the word "section".  It is the term used in the manual
page "systemd.syntax" that describes systemd's unit files, which means
that readers may be already familiar with the concept.  One could argue
that its definition in Simple English
(, “A section of a thing or
place is a part of it”) would allow a reader to think that a Field is
also a section, but I feel it is unlikely to happen.  This said, one big
disadvantage of "section" is that when searching for this word in a
document, there may be a lot of noisy hits such as "refer to section xyz
for details".

I understand about avoiding ambiguity, but in my opinion it is the price
to pay to be able to translate information into simple words from
English to non-European languages.  Although the Policy itself is not
going to be translated, I think that it can be advantageous if its
contents can be discussed in simple words in people's native languages.

Cheers,

-- Charles

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Charles Plessy]

Hi all,

while I do not want to pull the handbrake I would like to add my
minority opinion to that change:

Le Tue, Sep 20, 2022 at 04:11:43PM +, Russ Allbery (@rra) a écrit :
> 
> The «stanza» name is a commonly used and understood term when referring
> to deb822 blocks. Although «paragraph» is commonly used it has the
> problem of being confusing as it then makes it hard to distinguish
> actual text paragraphs in prose, while «stanza» is a very specific
> term that is not applied anywhere else in the deb822 context, so its
> always more clear and specific.

I disagree with this point of view.  In my own case I had to take a
dictionary to learn what a stanza is, while the word paragraph is surely
know at least to anybody who studied English in a classroom.

In my own field, (molecular biology) we (or at least some of us) are
putting some effort to eliminate jargon and use simple words that makes
written documents more accessible to the public.  This is why I prefered
paragraph to stanza when working on the specification.

If I were to redo such a specification from scratch, I would ask
non-European language speakers their opinion too.

Have a nice day,

-- 
Charles

Bug#897980: chromium-bsu: on play mode, after the first left click, game loose focus of mouse

[Charles Plessy]

Le Wed, Mar 24, 2021 at 10:58:24AM +0800, Paul Wise a écrit :
> 
> Are you using a Wayland desktop? If so, please log out and try it with
> an X11 desktop, or tell SDL to switch to using Wayland instead of X11:
> 
> env SDL_VIDEODRIVER=wayland chromium-bsu

Hi Paul,

same problem here, and setting the environment variable as you showed
allowed to move the fighter while firing.

Unfortunately, the mouse movements are buggy, as sometimes they are
transiently limited in the horizontal or vertical range of the screen
that they can cover.

I can not tell if it is a separate bug or a side effect of the
workaround you proposed above.

If the environment variable setting is the correct solution for this
bug, how about changing `/usr/games/chromium-bsu/` to a script that
checks for something like `$XDG_SESSION_TYPE == 'wayland'` and
sets `SDL_VIDEODRIVER=wayland` accordingly if true ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#953046: Wrongly picks AZERTY layout when alternative Canadian layout is present.

[Charles Plessy]

Hi Gunnar !

Summary: I report which layout I get with various combinations of locale and
user and system configurations.  Perhaps importantly, I also found that when I
switch layout using the keyboard shortcut that I configured (pressing the two
shift keys), I do not get the same result as if I select the same layout using
the mouse in the menu bar!

I tried multiple combinations of configurations.  To describe them easily, I
will call "user layout" the value of "layout" in
~/.config/mozc/ibus_config.textproto, which for instance is "jp"
in the example below:

cat ~/.config/mozc/ibus_config.textproto

engines {
  name : "mozc-jp"
  longname : "Mozc"
  layout : "jp"
   }

  layout : "jp"

And I will call "system layout" the value of "" in the
file /usr/share/ibus/component/mozc.xml, which for instance is "jp"
in the example below.

cat  /usr/share/ibus/component/mozc.xml 

  com.google.IBus.Mozc
  Mozc Component
  /usr/lib/ibus-mozc/ibus-engine-mozc --ibus
  2.26.4220.100+dfsg-4
  Google Inc.
  New BSD
  https://github.com/google/mozc
  ibus-mozc
  
  jp


As I write this, I have "jp" in both my user and system layout, and
LANG=fr_FR.UTF-8, LANGUAGE= and LC_ALL= in my environment.  My three layouts
are Japanese (Mozc), Japanese and Canadian multilingual. `gsettings get
org.gnome.desktop.input-sources sources` indicates: [('ibus', 'mozc-jp'),
('xkb', 'jp'), ('xkb', 'ca+multix')].  However, when I select the xkb jp
layout, the keyboard types in canadian layout.  The two other layouts
give the expected result.

As I reported earlier, when the user and system "layout" values are "default",
and my locale is fr_FR.UTF-8, then when I select the Mozc layout my keyboard
sometimes in types in azerty layout, which I have configured nowhere.  Today
I found that this only happens if I switch to the layout via the keyboard
shortcut (here: shiftL + shiftR).  If I switch layout using the mouse and the
GNOME menu bar, the Mozc layout is the same as the previously selected keyboard
(either Japanese or Canadian multilingual).

Here is a summary of various combinations of configurations that I tested.  Too
be frank, using the fr_CA.UTF-8 is fine with me as a workaround.  My main
motivation with this report is that in the default configuraiton, having the
French azeerty layout picked despite it is nowhere in the configuraiton is
clearly a bug.

usersystem  locale  problem
--  --  ---
default default fr_FR.UTF-8 ibus mozc-jp layout is sometimes French azerty 
and sometimes Canadian
default default fr_CA.UTF-8 fr_CA.UTF-8 is in principle the wrong locale.   
jp  jp  fr_FR.UTF-8 xkb jp layout is Canadian
jp  jp  fr_CA.UTF-8 xkb jp layout is Canadian
jp  default fr_CA.UTF-8 xkb jp layout is Canadian
jp  default fr_FR.UTF-8 xkb jp layout is Canadian
default jp  fr_FR.UTF-8 xkb jp layout is Canadian
default jp  fr_CA.UTF-8 xkb jp layout is Canadian

Have a nice week-end !

-- 
Charles

Bug#953046: Wrongly picks AZERTY layout when alternative Canadian layout is present.

[Charles Plessy]

Dear Gunnar and Nobuhiro,

it took me some time to debug the issue further, but here are some
new information that I hope you will find useful:

In finally found that the AZERTY layout is imposed by the Japanese
input system when the language I chose in Gnome is French from France,
and switching it to French from Canada or of course English restores
the QWERTY layout.

So it looks like the problem did not have to do with the presence of
the alternative canadian keyboard layout.

I inspected my locales when using the different variants of French
and the most prominent change is LANG, with either fr_FR or fr_CA.

So maybe ibus or Mozc hardcode the input layout to AZERTY through
a guess based on the fr_FR locale, assuming that all French speakers
from France type on AZERTY keyboards ?

Le Sun, Mar 21, 2021 at 03:05:38PM +0100, Gunnar Hjalmarsson a écrit :
> 
> Can you please run these terminal commands:
> 
> gsettings get org.gnome.desktop.input-sources sources

[('ibus', 'mozc-jp'), ('xkb', 'jp'), ('xkb', 'ca+multix')]
 
> gsettings get org.freedesktop.ibus.general use-system-keyboard-layout

false

> cat /etc/default/keyboard

XKBLAYOUT=jp,ca
XKBVARIANT=,multix
BACKSPACE=guess

And also:

cat /etc/default/locale 

LANG=fr_CA.UTF-8

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010328: mldonkey-server: Please replace mime-support with media-types in Depends

[Charles Plessy]

Package: mldonkey-server
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear OCaml team,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in
mldonkey-server's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010327: Please replace or remove mime-support in the Recommends section of xmaxima and maxima-emacs

[Charles Plessy]

Source: maxima
Version: Please replace or remove mime-support in the Recommends section of 
xmaxima and maxima-emacs
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Camm,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

xmaxima and maxima-emacs recommend the mime-support package.  Can you
replace it with either media-types or mailcap according to your needs?
Alternatively, if it appears that you do not directly need the presence
of the /etc/mime.types file or the availability of the mailcap system,
you can just drop the recommends entirely.  I searched for keywords such
as mime.types and mailcap via codesearch.debian.net and could not find
evidence of use.

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010326: live-task-standard: Please replace mime-support with media-types in Depends

[Charles Plessy]

Package: live-task-standard
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Live Systems Maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in
live-task-standard's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010324: golang-github-google-martian-dev: Please replace mime-support with media-types in Depends

[Charles Plessy]

Package: golang-github-google-martian-dev
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Debian Go maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in
golang-github-google-martian-dev's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010325: golang-github-google-go-github: Please replace mime-support with media-types in Depends

[Charles Plessy]

Source: golang-github-google-go-github
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Debian Go maintainers,

hello again :)

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in
golang-github-google-go-github's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010323: exmh: Please replace mime-support with media-types in Depends

[Charles Plessy]

Package: exmh
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Alexander,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in exmh's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010155: php8.1: Please replace mime-support with media-types in Depends

[Charles Plessy]

Package: php8.1
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear PHP maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in the Depends
line of the php8.1 packages that use it?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010153: nmh: Please replace mime-support with media-types in Depends

[Charles Plessy]

Package: nmh
Severity: normal
X-Debbugs-Cc: ple...@debian.org

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in nmh's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010102: debian-edu-config: Please replace mime-support with media-types or mailcap in Depends

[Charles Plessy]

Package: debian-edu-config
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Debian Edu maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types of mailcap in
debian-edu-config's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010101: mit-scheme: Please replace mime-support with media-types in Recommends

[Charles Plessy]

Package: mit-scheme
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Barak,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in mit-scheme's
Recommmends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1009771: netsurf: Please replace mime-support with media-types or mailcap in Recommends

[Charles Plessy]

Source: netsurf
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear netsurf maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that I
would like to remove from Debian.

According to your needs, can you replace mime-support with media-types
or mailcap in netsurf's Recommends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1009770: gitit: Please replace mime-support with media-types in Recommends

[Charles Plessy]

Package: gitit
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear gitit maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that I
would like to remove from Debian.

May I ask you to replace mime-support with media-types in gitit's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1009768: s3fs-fuse: Please replace mime-support with media-types in Depends

[Charles Plessy]

Source: s3fs-fuse
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear s3fs maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in s3fs's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1009767: topal: Please replace mime-support with media-types or mailcap in Recommends

[Charles Plessy]

Package: topal
Version: 80-1+b3
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Phil,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

According to your needs, can you replace mime-support with media-types or
mailcap in topal's Recommends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1009766: w3m: Please replace mime-support with media-types or mailcap in Suggests

[Charles Plessy]

Package: w3m
Version: 0.5.3+git20210102-6
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear w3m maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

According to your needs, can you replace mime-support with media-types or
mailcap in w3m's Suggests ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1001407: lynx: still recommends on transitional package mime-suport

[Charles Plessy]

Dear Elimar,

I am the maintainer of mime-support, mailcap and media-types.

I would like to remove mime-support from Debian this release cycle.

Sorry that I did not contact you earlier, but may I ask you to recommend
mailcap instead of mime-support ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1009224: Using different R versions in parallel with Debian

[Charles Plessy]

Le Sat, Apr 09, 2022 at 10:19:17AM +0200, Paul Menzel a écrit :
> 
> Thank you very much for packaging and maintaining R and related software in
> Debian. Some of our scientists use Debian and its R packages. Sometimes
> they’d like to use different R versions, for example, they’d like to stay
> with an R version from a different Debian suite, or use different versions
> in parallel. Is that somehow supported? I only read README [1]. If it’s
> documented somewhere, I am sorry for the noise and a pointer would be nice.

Dear Paul,

I am not the mainainer of r-base, but I would like to mention the
lightweight containerisation system `schroot` available in Debian, that
makes it easy to run other versions of R while keeping the same home
directory.  I have blogged an example where I installed R 4.1 to run it
on Buster.

http://charles.plessy.org/Debian/debi%C3%A2neries/r-4.1/index.en

Dirk (the r-base maintainer), has probably other good (and more modern)
solutions.  In any case, please feel free to post more questions
directly on the debian-r mailing list.

Have a nice week-end,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1005180: update-mime: conffile can't update settings

[Charles Plessy]

Le Wed, Mar 30, 2022 at 06:04:06PM +0300, Yair Yarom a écrit :
> 
> This is a somewhat obscure feature (and not really documented), so I doubt
> it breaks many systems, and so I'm not sure how urgent this is to be
> backported.

Thanks Yair for the fast answer,

indeed, it is undocumented and I did not receive more reports about the
breakage, so I will not backport or update stable unless there is more
demand for it.

Have a nice day,

-- 
Charles

Bug#1005180: update-mime: conffile can't update settings

[Charles Plessy]

Control: tag -1 pending

Le Tue, Feb 08, 2022 at 04:30:09PM +0200, Yair Yarom a écrit :
> 
> In update-mime, setting all variable with 'my' prevents them from
> being updated by the conf file (/etc/update-mime.conf). Setting them
> to 'our' solves this issue.

Dear Yair,

thank you for your report and the patch, and sorry for the regression.

I have pushed a commit that changes `my` to `our` in all variables of
that block, except for `$conffile` where `our` would not make sense.

I am tagging this patch "pending" but it may take a bit of time before
I upload an update, as I would like to go through of a couple of other
open issues first.

Do you think a backport or a stable update would be needed ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy


signature.asc
Description: PGP signature

Bug#1008480: debian-policy: The mime-support package was split into media-types and mailcap

[Charles Plessy]

Package: debian-policy
Version: 4.6.0.1
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Hi Russ and Sean,

it is a long time I have not posted here!

In the previous release cycle, I have split the mime-support into the
media-types and the mailcap packages.

The patch below updates the Policy to reflect that.

Have a nice Sunday,

-- Charles

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 83b71b1..72923f9 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -796,16 +796,16 @@ install a file in :manpage:`mailcap(5)` format (RFC 1524) 
in the directory
 ``/usr/lib/mime/packages/``. The file name should be the binary package's
 name.

-The mime-support package provides the ``update-mime`` program, which
+The mailcap package provides the ``update-mime`` program, which
 integrates these registrations in the ``/etc/mailcap`` file, using dpkg
 triggers.  [#]_

 Packages installing desktop entries should not install mailcap entries
-for the same program, because the mime-support package already reads
+for the same program, because the mailcap package already reads
 desktop entries.

 Packages using these facilities *should not* depend on, recommend, or
-suggest ``mime-support``.
+suggest ``mailcap``.

 .. _s-file-media-type:

@@ -821,7 +821,7 @@ characteristic file extensions and magic patterns should be 
registered
 to the IANA (Internet Assigned Numbers Authority). See
 https://www.iana.org/assignments/media-types and RFC 6838 for details.
 This information will then propagate to the systems discovering file
-media types in Debian, provided by the shared-mime-info, mime-support
+media types in Debian, provided by the shared-mime-info, media-types
 and file packages. If registration and propagation can not be waited
 for, support can be asked to the maintainers of the packages mentioned
 above.

Bug#978015: Add "image/webp webp" to /etc/mime.types ?

[Charles Plessy]

Le Mon, Dec 28, 2020 at 08:16:24AM +0900, Charles Plessy a écrit :
> 
> I see on the upstream mailing list that it is being discussed.
> 
> https://groups.google.com/a/webmproject.org/g/webp-discuss/c/gklBC0vn7NI/m/_bmsFb05AwAJ
> 
> In my opinion, it is unfair to call IANA's registration "paperwork",
> "administrative work" or "time investment" (as in the thread linked
> above).
> 
> Registration is done through a simple web form, without the need to
> create an account.
> 
> https://www.iana.org/form/media-types

Hi Trent and VA,

would one of you be intereted to ping Google to register the media type
to the IANA ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1004985: media-types: Should use audio/mp4 for .m4a, not audio/mpeg

[Charles Plessy]

Control: tag -1 pending

Le Fri, Feb 04, 2022 at 09:20:40PM +, Anders Kaseorg a écrit :
> 
> This association for the .m4a extension is incorrect. Please update this to
> 
> audio/mpegmpga mpega mp1 mp2 mp3
> audio/mp4 m4a

Dear Anders,

thanks for your detailed report!  I commited the change to the source
package and it will take effect after the next upload.

Have a nice week-end,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#987395: media-types: Add image/jxl as a mime type

[Charles Plessy]

Le Fri, Jan 14, 2022 at 09:43:39AM +0100, Mathieu Malaterre a écrit :
> Odd, there is still nothing today:
> 
> https://www.iana.org/assignments/media-types/image/jxl

Hi Mathieu,

I checked on the ISO website and 3 parts out of 4 of the standard are
still reported to be in development, maybe that is the reason.

I see that many image/jx* have been registered to the IANA by
sc29-sec maybe you can ask that person if they have
a plan to do so for JPEG XL ?

Have a nice week-end,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1000588: evince,mailcap: "evince --new-window $file" opens the file chooser dialog instead of the requested file

[Charles Plessy]

Le Thu, Nov 25, 2021 at 03:15:27PM +, Simon McVittie a écrit :
> Control: reassign -1 mailcap 3.70
> 
> On Thu, 25 Nov 2021 at 15:13:01 +0100, Julien Cristau wrote:
> 
> Yes, update-mime should only be parsing the fields from the
> [Desktop Entry] group, something like this (untested):

Thanks Julien and Simon,

I agree that the problem and the solution are in mailcap.

I am about to go for a business trip, so the fix may take a couple of
weeks.  If you consider an NMU please go straight for a team upload
and push the change in Salsa; as DDs you should have commit rights.

https://salsa.debian.org/debian/mailcap

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#995616: dh-make: create debian/upstream/medatada template

[Charles Plessy]

> Am Wed, Oct 13, 2021 at 07:37:33AM +1100 schrieb Craig Small:
> >   It was more that the main system [1] that used this data seemed to be
> > offline as well as the debian med one [2] too.
> >
> > 2: http://debian-med.alioth.debian.org/tasks

Le Wed, Oct 13, 2021 at 06:49:30AM +0200, Andreas Tille a écrit :
> 
> Even when alioth as online the page you should refer to is
> 
>https://blends.debian.org/med/tasks/
>  
> Where did you found those outdated link to alioth (this should have
> been fixed a long time ago - sorry if anybody missed this).

Hi Andreas, sorry for not providing enough context, it was here:

https://wiki.debian.org/UpstreamMetadata?action=diff=145=144

Cheers

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#995616: dh-make: create debian/upstream/medatada template

[Charles Plessy]

Hi Craig,

the "upstream-metadata.debian.net" system was replaced a long time ago
and I removed mention of it in the wiki page to reflect that.

I also updated the URL to the web sentinel, which is now:
https://blends.debian.org/med/tasks

Sorry for the confusion and thanks for your support !

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#915541: [Debian-med-packaging] Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Charles Plessy]

Le Thu, Sep 16, 2021 at 08:37:38PM +0200, Lucas Nussbaum a écrit :
> https://salsa.debian.org/med-team/parallel/-/blob/master/debian/patches/remove-overreaching-citation-request.patch).

Hi all,

sorry but how likely is it that we will break user scripts with this patch ?

https://github.com/search?q=%22parallel+--citation%22=code

I think that it would be better to disable citation checks without
changing availability of the command-line options.  (Sorry that I
can not do it myself).

Ole, in Debian we put a lot of effort providing citation information in
a central space, so that one can collect detailed references for
complete pipelines made using our packages.

https://salsa.debian.org/med-team/parallel/-/blob/master/debian/upstream/metadata

But better than a bibliographic DOI, have you consideded registering a
RRID ? (https://www.rrids.org/) (https://scicrunch.org/resources) This
will give scientists an easier way to declare their use of your work in
their publications without going to troubles about space in the
bibliography section, which is limited by many journals.

To the others: do you know a way to list or count the publications that
refer to a given RRID ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#993235: php8.0: Please depend on media-types instead of mime-support

[Charles Plessy]

Source: php8.0
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear PHP Maintainers,

since Bullseye, mime-support is a transition package.  The new package
providing /etc/mime.types is called media-types.  Can you
depend/recommend it directly so that I remove mime-support from
Bullseye?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#979020: Please replace mime-support with media-types and mailcap in Recommends.

[Charles Plessy]

Le Sat, Jan 02, 2021 at 10:13:09AM +0900, Charles Plessy a écrit :
> 
> Recently I have split the `mime-support` package into two: `media-types`
> supplies /etc/mime.types and `mailcap` supplies the mailcap system.
> `mime-support` remains as a transitional package for the moment.
> 
> I believe that `mutt` and `neomutt` recommend `mime-support` for both
> functionalities.
> 
> At your convenience, can you replace mime-support with media-types and
> mailcap in mutt and neomutt's Recommends ?

Hello,

now that Bullseye is released, it would be great if mutt and neomutt
could recommend media-types and mailcap directly, so that I can remove
mime-support.

Have a nice Sunday,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#980269: Please depend on media-types instead of mime-support

[Charles Plessy]

Le Sun, Jan 17, 2021 at 08:12:10AM +0900, Charles Plessy a écrit :
> 
> `mime-support` is now a transitional package, and it would be great if
> users could be able to remove it after the _Bookworm_ release.
> 
> Please Depend on `media-types` instead of `mime-support` if you only
> need the `/etc/mime.types` file.

Hello,

now that Bullseye is released, it would be great if you could depend on
media-types instead of mime-support!

Have a nice Sunday,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#980275: Please depend on media-types instead of mime-support

[Charles Plessy]

Le Sun, Jan 17, 2021 at 11:28:03AM +0900, Charles Plessy a écrit :
> 
> `mime-support` is now a transitional package, and it would be great if
> users could be able to remove it after the _Bookworm_ release.
> 
> Please Depend on `media-types` instead of `mime-support` if you only
> need the `/etc/mime.types` file.

Hello,

now that Bullseye is released, it would be great if you could depend on
media-types instead of mime-support.

Have a nice Sunday !

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#992485: override: mime-support:oldlibs/optional

[Charles Plessy]

Le Thu, Aug 19, 2021 at 01:48:01AM -0500, Daniel Lewart a écrit :
> 
> Please change mime-support from:
> net/standard
> to:
> oldlibs/optional

Thanks Daniel,

Indeed I intended to ask for it during this release cycle.  Actually,
the source package already reflects this.


https://salsa.debian.org/debian/mime-support/-/blob/master/debian/control#L4-5

I have started to open bugs on some of the packages that still depend on
mime-support directly.  Your help is welcome.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#991158: media-types: use image/x-xcf rather than application/x-xcf to match gimp.desktop

[Charles Plessy]

Control: tag -1 pending

Le Sat, Jul 17, 2021 at 07:29:22AM +1000, Joel Hockey a écrit :
> 
> The GIMP team have confirmed that image/x-xcf is the correct mime.
> 
> https://www.mail-archive.com/gimp-developer-list%40gnome.org/msg09755.html

Thanks Joel,

the change will be applied after the release.

It seems that a couple of other packages have borrowed mime-support's
media type.

http://codesearch.debian.net/search?q=application%2Fx-xcf=1

I will notify their maintainers.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#991158: media-types: use image/x-xcf rather than application/x-xcf to match gimp.desktop

[Charles Plessy]

Le Fri, Jul 16, 2021 at 01:20:40PM +1000, Joel Hockey a écrit :
> 
> GIMP uses the xcf file extension by default, and registers to handle
> mime type image/x-xcf in its gimp.desktop file.

Thanks Joel for the report,

Debian is in deep freeze but I can make changes later based on the
recommendation of the GIMP developers.

May I ask you to also suggest them to register their media type to the
IANA ?  I can provide assistance if needed.

https://www.iana.org/form/media-types

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#987395: media-types: Add image/jxl as a mime type.

[Charles Plessy]

Control: tag -1 pending

Hi Luc,

thanks for your bug report and your direct emmail sent a couple of days
ago.  After receiving it I had already answered you that I added the
media type, but that it will take effect after the release.  I hope
that my message did not get filtered (my mail server is on the Amazon
cloud...).

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#986043: emboss: uses media types that are not registered

[Charles Plessy]

Package: emboss
Severity: wishlist

Hello everybody,

In 2008, for the visualisation of DNA sequence chromatograms generated
by Applied Biosystems machines and their successors, I created files
declaring media types for the mailcap and FreeDesktop systems.  Due to
my incomplete undertanding at that time, I used standard tree media
types, such as `application/vnd.appliedbiosystems.abif` without making
sure they are declared.

In principle, it would be better to either have the maker company to
declare chromatogram files' media types and their magic numbers, or
empower one of us (any volunteer?) to do so.  Then we could propagate
them in the "file" and "shared-mime-info" databases, which would
increase the chance that the media types are used when the files
are served on the Web or sent by email.

Thus, I open this bug as a reminder.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#985596: [Debian-med-packaging] Bug#985596: Bug#985596: emboss has mailcap entries with quoted %-escapes

[Charles Plessy]

Le Sun, Mar 21, 2021 at 03:33:21PM +0100, Marriott NZ a écrit :
> 
> I agree that such file is not useful out of the box, and personally I have no 
> objection to removing it (can't wait for mailcap to disappear :D).
> But once fixed the file is probably not harmful either, and it can be useful 
> to a user who is willing to add the corresponding entries to /etc/mime.types 
> or ~/.mime.types manually (for example if you have a mailcap-based file 
> manager, and you want to make it open .ab1 files).
> I'm not familiar with the registration of media types to IANA, so I'll leave 
> the decision to you.

Hi Mariott,

I have pushed your patch to Unstable, closing this bug as you have seen.

I will follow up about .ab1 files in a new wishlist bug.

Have a nice Sunday, and thanks for your care about security!

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#985596: [Debian-med-packaging] Bug#985596: emboss has mailcap entries with quoted %-escapes

[Charles Plessy]

Le Sat, Mar 20, 2021 at 03:52:21PM +0100, Marriott NZ a écrit :
> Package: emboss
> Version: 6.6.0+dfsg-8
> Tags: patch, security
> 
> Dear Maintainer,
> the emboss package has mailcap entries with quoted %-escapes. That is 
> considered unsafe. Proper escaping should be left to the programs using the 
> entry.

Hi Mariott,

thanks for your report,

and hello everybody.

In the case of this package I wonder if the mailcap file should better be
deleted instead of corrected.

I just downloaded an example ab1 file
(https://github.com/labsquare/CutePeaks/blob/master/examples/A_forward.ab1)
and saw that it is not recognised as any of the media types listed
below.  Therefore for the mailcap file to be useful, the file should be
served via the web or attached to an email, with the media type
information properly set.  But this is unlikely to happen as email
composers or web servers are likely to use similar information soures as
in Debian systems (file(1), /etc/mime.types, shared-mime-info…) and so
will also detect the format of this file.

A quick search in the web shows traces of myself trying to make that
happen more than 10 years ago, but it did not bear fruit.  I think that
if we were to try again (for instance adding the magic number of these
files to the file(1) database), it would be with a different media type
anyway, unless one registers application/vnd.appliedbiosystems.abif
to the IANA ?

Have a nice week-end,

Charles

> diff --git a/debian/emboss.mime b/debian/emboss.mime
> index 38db622..1a7017f 100644
> --- a/debian/emboss.mime
> +++ b/debian/emboss.mime
> @@ -1,6 +1,6 @@
> -application/vnd.appliedbiosystems.abif; abiview -auto '%s' ; 
> description=ABIF Applied Biosystems Inc. chromatogram; nametemplate=%s.ab1
> -application/x-dna; abiview -auto '%s' ; description=ABIF Applied Biosystems 
> Inc. chromatogram; nametemplate=%s.ab1
> -application/abi1; abiview -auto '%s' ; description=ABIF Applied Biosystems 
> Inc. chromatogram; nametemplate=%s.ab1
> -application/vnd.appliedbiosystems.abif; seqret -filter '%s' ; 
> description=ABIF Applied Biosystems Inc. chromatogram; nametemplate=%s.ab1 ; 
> copiousoutput
> -application/x-dna; seqret -filter '%s' ; description=ABIF Applied Biosystems 
> Inc. chromatogram; nametemplate=%s.ab1 ; copiousoutput
> -application/abi1; seqret -filter '%s' ; description=ABIF Applied Biosystems 
> Inc. chromatogram; nametemplate=%s.ab1 ; copiousoutput
> +application/vnd.appliedbiosystems.abif; abiview -auto %s ; description=ABIF 
> Applied Biosystems Inc. chromatogram; nametemplate=%s.ab1
> +application/x-dna; abiview -auto %s ; description=ABIF Applied Biosystems 
> Inc. chromatogram; nametemplate=%s.ab1
> +application/abi1; abiview -auto %s ; description=ABIF Applied Biosystems 
> Inc. chromatogram; nametemplate=%s.ab1
> +application/vnd.appliedbiosystems.abif; seqret -filter %s ; description=ABIF 
> Applied Biosystems Inc. chromatogram; nametemplate=%s.ab1 ; copiousoutput
> +application/x-dna; seqret -filter %s ; description=ABIF Applied Biosystems 
> Inc. chromatogram; nametemplate=%s.ab1 ; copiousoutput
> +application/abi1; seqret -filter %s ; description=ABIF Applied Biosystems 
> Inc. chromatogram; nametemplate=%s.ab1 ; copiousoutput

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#985602: Document the new /usr/bin/open command

[Charles Plessy]

Package: release-notes
Tag: bullseye

Hello,

I would like to document the new `/usr/bin/open` command in the "what's
new" section of the release notes.  Here is a description.

A new `open` commmand is available as a convenience alias to `xdg-open`
(by default) or `run-mailcap`, managed by the update-alternatives(1)
system.  It is intended for interactive use at the command line, to open
files with their default application, which can be a graphical program
when available.

Have a nice week-end,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#985039: media-types: please bring back application/x-shockwave-flash

[Charles Plessy]

Hi Pierre,

thank you for the detailed explanations.

So the problem is the Flash plugin, which is not supported upstream nor
distributed by Debian anymore.  While it was not my intention to make
its use more difficult, I wonder if the change is not a bad thing.
After all, users who really want to use it can simply add back the
x-shockwave-flash media type in `/etc/mime.types` and solve the problem
locally.

In any case, I think that it would be too late to revert the change in
the package before the release.  I may consider to request a Stable
update if other users support your point of view, but at the moment I
think that I will simply leave the situation as it is.

Please do not hesitate to ping me a couple of weeks after the release
if you would like.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#985039: media-types: please bring back application/x-shockwave-flash

[Charles Plessy]

Le Fri, Mar 12, 2021 at 07:46:35AM +0100, Pierre Ynard a écrit :
> 
> I've noticed (the hard way) that the application/x-shockwave-flash
> media type for SWF files had been removed at the beginning of the year.

Hello and thanks for your report !

I replaced it with application/vnd.adobe.flash.movie, which was
registered in 2013.

https://www.iana.org/assignments/media-types/application/vnd.adobe.flash.movie

Sorry that it was not prominently explained in the changelog.

Can you give me details on what is broken by this change ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#982060: run-mailcap: special characters in file names break "open"

[Charles Plessy]

Le Sat, Feb 06, 2021 at 07:35:16AM +0100, Marriott NZ a écrit :
> 
> run-mailcap fails if run as "open" on file names containing special 
> characters.
> It also allows shell command injection from file names (again: 
> https://www.debian.org/security/2014/dsa-3114).

Thanks Mariott for the head-up.  I totally forgot about this.

> The problem originates from this commit:
> https://salsa.debian.org/debian/mailcap/-/commit/66f82f13d86d565ebe249a8b56da8dd0cb63e2ef
> > Prevent run-mailcap from creating a temporary copy when run as "open".

I will revert it.

> The man page is giving false information, please fix this too:

Thanks for spotting this as well.

> An alternative to making a temporary symlink would be to properly
> quote special characters in the file name (as described here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980345).

I will have a lood at this but first will upload the fix for /usr/bin/open.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#978984: media-types: /etc/mime.types reported as oldconfig

[Charles Plessy]

Dear Martin,

It turns out that it is a bug in dpkg (<https://bugs.debian.org/886389>)…

I tried dpkg-maintscript-helper with `rm_conffile /etc/mime.types` but
as a result the upgrade from Buster to Bullseye would ignore local
modifications.

I will keep this bug open in case there is a chance to do the cleanup
in the Bullseye to Bookworm upgrade.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#980349: Please drop recommend on mime-support

[Charles Plessy]

Package: xcftools

Dear Jan,

I have recently split the `mime-support` package into two: `mailcap` for
the mailcap system, and `media-types` for providing `/etc/mime.types`.
The goal is to allow minimal systems without `mailcap`.

In the case of `xcftools`, I searched in its source for `mime.types`
and `mailcap` and found that thanks to your patch you do not need
to recommend on `mime-support` anymore.  If I am wrong, please replace
it with `mailcap`.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#980347: Please Recommend mailcap instead of mime-support

[Charles Plessy]

Package:ytree

Dear William,

I have recently split the `mime-support` package into two: `mailcap` for
the mailcap system, and `media-types` for providing `/etc/mime.types`
to allow minimal systems without `mailcap`.

The `mailcap` package depends on `media-types` replaces `mime-support`,
which now a transitional package, and it would be great if users could
be able to remove it after the _Bookworm_ release.

Please Recommend `mailcap` instead of `mime-support`.

Have a nice week-end,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#980275: Please depend on media-types instead of mime-support

[Charles Plessy]

Package: apache2

Dear apache2 maintainers,

I have recently split the `mime-support` package into two: `mailcap` for
the mailcap system, and `media-types` for providing `/etc/mime.types`.
The goal is to allow minimal systems without `mailcap`.

`mime-support` is now a transitional package, and it would be great if
users could be able to remove it after the _Bookworm_ release.

Please Depend on `media-types` instead of `mime-support` if you only
need the `/etc/mime.types` file.

Have a nice week-end,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#980269: Please depend on media-types instead of mime-support

[Charles Plessy]

Package: lighttpd

Dear lighttpd maintainers,

I have recently split the `mime-support` package into two: `mailcap` for
the mailcap system, and `media-types` for providing `/etc/mime.types`.
The goal is to allow minimal systems without `mailcap`.

`mime-support` is now a transitional package, and it would be great if
users could be able to remove it after the _Bookworm_ release.

Please Depend on `media-types` instead of `mime-support` if you only
need the `/etc/mime.types` file.

Have a nice week-end,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#979554: please clarify case sensitiveness of mime.types

[Charles Plessy]

Le Fri, Jan 08, 2021 at 09:38:50AM +0100, Alexandre Duret-Lutz a écrit :
> 
> Recent versions of media-types (1.1.0 and 2.0.0) have introduced some
> lines with extension appearing in both lowercase and uppercase form:

Hi Alexandre, thank you for your report,

I was also wondering about case sensitivity when I worked on the 2.0.0
update.  One of my current problems is that there does not seem to be
a written specification for such details in /etc/mime.types.

> audio/AMR   amr AMR
> audio/AMR-WBawb AWB
> audio/EVRC-QCP  qcp QCP

The IANA assignment pages for these three types list both the lower- and
the uppercase suffixes, so I decided to stick to that.

> image/t38   t38 T38

When I merged the mime.types from Fedora in Debian's, Fedora had the
lowercase one and Debian the uppercase one.  The IANA assignment
declares no extension.  I decided to keep both.  Perhaps it is not
the best decision.

> image/vnd.globalgraphics.pgbPGB pgb

This type also declares both cases in IANA's assignment.

> Some tools will complain if some entries in mime.types have duplicate
> extensions (in some case-insensitive sense).  For instance the above
> lines are causing Bug#979232 for lighttpd.

I am glad that you could solve the bug easily on lighttpd's side.  By
the way I am preparing an update that reverts all case-sensitive
duplicates for this release cycle, and will surely do the same for
case-insensitive ones if it causes serious bugs elsewhere. 

> So the question is what is the intended semantics for the above lines?
> Is "audio/AMR amr AMR" really meant to achieve more than "audio/AMR amr"?

The problem here is that I have no comprehensive information on how
softwares use the mime.types files.  I can not rule out that some use
case sensitivity for their own good reasons, so if no other bug arise, I
would like to continue to stick to the information provided by the IANA.

> Also note that mime.types lists some extensions with only uppercase
> versions, or a mix of lower and upper case letters:
> 
> application/vnd.sar SAR
> application/vnd.ves.encrypted   VES

These two I imported from Fedora and I checked that they are consistent
with IANA.

> application/x-font-pcf  pcf pcf.Z

This one has been for a long time in Debian.

> Those entries will behave differently for "see" and Python's
> "mimetypes.guess_type()".   For instance "see" will consider "foo.sar"
> as application/vnd.sar, but "mimetypes.guess_type()" will not.

I can not tell which approach is wiser...  The mime.types file is not
comprehensive and is usually lagging.  What if there is another file
format around that uses the lowercase `sar` extension?

> It would be nice to clarify the semantics in the comments at the top of
> mime.types.

Definitely! I hope to do so or write a proper man page after I dig the
history of that file.

Bonne journée,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#974729: #974729, mailcap 3.67: obsolete conffiles

[Charles Plessy]

Hello again,

Le Sun, Nov 22, 2020 at 06:23:55AM +0100, Xk2c a écrit :
> 
> % command dpkg-query -W -f='${Conffiles}\n' mime-support
>  /etc/mime.types f4631d08bcc92bf2dde274696d7b4b35 obsolete
>  /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
> 
> % command dpkg-query -W -f='${Conffiles}\n' media-types
>  /etc/mime.types f4631d08bcc92bf2dde274696d7b4b35
> 
> % command dpkg-query -W -f='${Conffiles}\n' mailcap
>  /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e

I asked for advice on debian-mentors and the current outcome is that it
might be https://bugs.debian.org/886389 in dpkg.  I will wait some time
for an answer and if nothing comes, I will try if
dpkg-maintscript-helper can be used to force mime-support forget its
conffiles without losing the local changes.

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#886389: dpkg: conffile marked as obsolete after being taken over by different package

[Charles Plessy]

Hello Guillem,

I think that I have hit the same bug when splitting the `mime-support`
package into `media-types` and `mailcap`:

mime-support had the conffiles `/etc/mime.types` and
`/etc/mailcap.order` until version 3.64.  Version 3.65 is a transitional
package containing only a changelog and a copyright file, and depends on
media-types and mailcap.  And these two packages declare a Breaks and
Replaces relationship against mime-support << 3.65.

As a result of the upgrade, the conffiles are now owned by the new
packages.  But dpkg still keeps a record that the mime-support has
the "obsolete" version of them:

# dpkg-query -W -f='${Conffiles}\n' media-types
 /etc/mime.types 43fa90aa9a5e009997f451be169ac530

# md5sum /etc/mime.types
43fa90aa9a5e009997f451be169ac530  /etc/mime.types

# dpkg-query -W -f='${Conffiles}\n'  mailcap
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e

# dpkg-query -W -f='${Conffiles}\n'  mime-support
 /etc/mime.types 0d516753aee0a2c670c79667aad0c836 obsolete
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete

Is there something we can do about that ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#978984: media-types: /etc/mime.types reported as oldconfig

[Charles Plessy]

Control: reassign -1 mime-support

Le Sat, Jan 02, 2021 at 12:17:58PM +0200, Martin-Éric Racine a écrit :
> 
> $ dpkg-query -W -f='${Conffiles}\n'  mime-support
>  /etc/mime.types f4631d08bcc92bf2dde274696d7b4b35 obsolete
>  /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
> $ dpkg-query -W -f='${Conffiles}\n' media-types
>  /etc/mime.types 43fa90aa9a5e009997f451be169ac530
> $ dpkg-query -W -f='${Conffiles}\n'  mailcap
>  /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e

Hi Martin,

thanks for the checks,

the above commands show that the obsolete conffiles belong to
mime-support, not to media-types as you reported initially.

I am checking on debian-mentors if the fact that mime-support still
declares obsolete conffiles is a bug or not, and will update the package
or close the bug accordingly.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#978984: media-types: /etc/mime.types reported as oldconfig

[Charles Plessy]

Le Sat, Jan 02, 2021 at 10:00:51AM +0200, Martin-Éric Racine a écrit :
> 
> The issue can be reproduced both on my Testing host and in an Unstable
> chroot that regularly gets updated.

Thanks for the quick answer; can you give details on the commands you ran ?

On my side:

$ sudo debootstrap stable testMimeSupportUPdate http://deb.debian.org/debian
$ sudo chroot testMimeSupportUPdate
# apt install mime-support
# dpkg-query -W -f='${Conffiles}\n'  mime-support
 /etc/mime.types 0d516753aee0a2c670c79667aad0c836
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e
# nano /etc/apt/sources.list # change stable to unstable
# apt update
# apt dist-upgrade
# dpkg-query -W -f='${Conffiles}\n' | command grep 'obsolete$'
 /etc/calendar/default f499e79b0d2d685aa5ae7e1013940b96 obsolete
 /etc/mime.types 0d516753aee0a2c670c79667aad0c836 obsolete
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
# dpkg-query -W -f='${Conffiles}\n' media-types 
 /etc/mime.types 43fa90aa9a5e009997f451be169ac530
# md5sum /etc/mime.types
43fa90aa9a5e009997f451be169ac530  /etc/mime.types
# dpkg-query -W -f='${Conffiles}\n'  mailcap
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e
# dpkg-query -W -f='${Conffiles}\n'  mime-support
 /etc/mime.types 0d516753aee0a2c670c79667aad0c836 obsolete
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete

With this chain of events, the obsolete conffiles belong to
mime-support.

Cheers,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#978984: media-types: /etc/mime.types reported as oldconfig

[Charles Plessy]

Le Fri, Jan 01, 2021 at 07:24:28PM +0200, Martin-Éric Racine a écrit :
> 
> /etc/mime.types is reported as oldconfig belonging to package media-types.

Dear Martin,

I can not reproduce that in a clean chroot.  Can you give extra details
on your system and the tools you used to upgrade and query dpkg's
database ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy