Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)
60 views
Skip to first unread message
Andreas Tille
Jan 31, 2012, 4:20:02 PM1/31/12
to
Hi,
this problem concerns missing *.mime file which breaks other programs
like for instance see
$ see test.pdf
Error: no "view" mailcap rules found for type "application/pdf"
On Tue, Jan 31, 2012 at 07:57:39PM +0100, Michael Biebl wrote:
> severity 658139 wishlist
> tags 658139 + wontfix
:-(
This is definitely not "wishlist" - but I do not like to play
severity-changing pingpong.
> On 31.01.2012 17:18, Andreas Tille wrote:
> > Package: evince
> > Severity: important
> > Tags: patch
> >
> > Hi,
> >
> > several programs (for instance see, mc) are regarding mime entries
> > in mailcap file and can not find a PDF viewer in case only evince is
> > installed. This ends up in something like:
>
> Since Joss has removed this file on purpose, it's very unlikely that it
> is coming back.
>
> This topic has been discussed several times already. Instead of
> maintaining these files by hand (remember, we do have quite a few in the
> GNOME repo), those mailcap entries should be generated automatically
> from the *.desktop files that are provided upstream and already contain
> all the necessary information.
> We don't want to maintain a second mime database by hand in parallel.
So the existence of a potential but not implemented solution rectifies
to break other packages? That's ... uhmm, my vocabulary is broken. :-(
> From our pov, someone interested in this topic should write a small
> tool, which does this automatically and is dpkg triggered.
I agree that an automatic solution would be prefered. However, as long
as such someone does not stand up and write such a program removing
existing solutions is <feel free to insert any word which fits>. I
rarely have read this kind of argument on a Debian mailing list.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012013120...@an3as.eu
this problem concerns missing *.mime file which breaks other programs
like for instance see
$ see test.pdf
Error: no "view" mailcap rules found for type "application/pdf"
On Tue, Jan 31, 2012 at 07:57:39PM +0100, Michael Biebl wrote:
> severity 658139 wishlist
> tags 658139 + wontfix
:-(
This is definitely not "wishlist" - but I do not like to play
severity-changing pingpong.
> On 31.01.2012 17:18, Andreas Tille wrote:
> > Package: evince
> > Severity: important
> > Tags: patch
> >
> > Hi,
> >
> > several programs (for instance see, mc) are regarding mime entries
> > in mailcap file and can not find a PDF viewer in case only evince is
> > installed. This ends up in something like:
>
> Since Joss has removed this file on purpose, it's very unlikely that it
> is coming back.
>
> This topic has been discussed several times already. Instead of
> maintaining these files by hand (remember, we do have quite a few in the
> GNOME repo), those mailcap entries should be generated automatically
> from the *.desktop files that are provided upstream and already contain
> all the necessary information.
> We don't want to maintain a second mime database by hand in parallel.
So the existence of a potential but not implemented solution rectifies
to break other packages? That's ... uhmm, my vocabulary is broken. :-(
> From our pov, someone interested in this topic should write a small
> tool, which does this automatically and is dpkg triggered.
I agree that an automatic solution would be prefered. However, as long
as such someone does not stand up and write such a program removing
existing solutions is <feel free to insert any word which fits>. I
rarely have read this kind of argument on a Debian mailing list.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012013120...@an3as.eu
Cyril Brulebois
Jan 31, 2012, 4:30:02 PM1/31/12
to
Andreas Tille <ti...@debian.org> (31/01/2012):
individual bugs; thanks already.
Mraw,
KiBi.
> This is definitely not "wishlist" - but I do not like to play
> severity-changing pingpong.
Please avoid “To: debian-devel@” when you disagree with maintainers on
> severity-changing pingpong.
individual bugs; thanks already.
Mraw,
KiBi.
Russ Allbery
Jan 31, 2012, 4:40:03 PM1/31/12
to
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Feb 1, 2012, 3:40:01 AM2/1/12
to
Le mardi 31 janvier 2012 à 21:51 +0100, Andreas Tille a écrit :
> I agree that an automatic solution would be prefered. However, as long
> as such someone does not stand up and write such a program removing
> existing solutions is <feel free to insert any word which fits>.
The point is, no one will write such a program until we remove support
> I agree that an automatic solution would be prefered. However, as long
> as such someone does not stand up and write such a program removing
> existing solutions is <feel free to insert any word which fits>.
for the old system entirely. To break such a chicken/egg circle, we
needed either to write the program ourselves, or to simply drop support
for the obsolete mime system. Guess what: I’m not writing a tool, lest
maintain it, for a technology that I don’t use.
And since, after seven months, nothing happened, it means no one is
interested enough, although some one-liners doing half of the job have
been circulating.
kthxbye,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Tille
Feb 1, 2012, 4:00:01 AM2/1/12
to
Hi Josselin,
On Wed, Feb 01, 2012 at 09:29:46AM +0100, Josselin Mouette wrote:
> Le mardi 31 janvier 2012 à 21:51 +0100, Andreas Tille a écrit :
> > I agree that an automatic solution would be prefered. However, as long
> > as such someone does not stand up and write such a program removing
> > existing solutions is <feel free to insert any word which fits>.
>
> The point is, no one will write such a program until we remove support
> for the old system entirely.
I confirm that I got your point even if I do not agree.
> To break such a chicken/egg circle, we
> needed either to write the program ourselves, or to simply drop support
> for the obsolete mime system.
Somehow I missed an announcement that mime is obsolete and not supported
in Debian any more. Did I missed something (URLs)? I insist in my
opinion that it is not correct to break an old but used (=established)
system intentionally to force others writing workarounds. (Cyril, it is
not about this specific bug - it is about the general principle.)
> Guess what: I’m not writing a tool, lest
> maintain it, for a technology that I don’t use.
OK, that's fair.
> And since, after seven months, nothing happened, it means no one is
> interested enough, although some one-liners doing half of the job have
> been circulating.
Well, from my perspective I was bored the first time when xpdf came up
when I was expecting evince. After purging xpdf I learned that see does
not find any pdf viewer. Sorry if I did not realised any discussion
seven monthes ago noch any one-line helpers.
So were can I read about which one-liner should be added to what package
to fix the problem you decided to force upon others.
On Wed, Feb 01, 2012 at 09:29:46AM +0100, Josselin Mouette wrote:
> Le mardi 31 janvier 2012 à 21:51 +0100, Andreas Tille a écrit :
> > I agree that an automatic solution would be prefered. However, as long
> > as such someone does not stand up and write such a program removing
> > existing solutions is <feel free to insert any word which fits>.
>
> The point is, no one will write such a program until we remove support
> for the old system entirely.
> To break such a chicken/egg circle, we
> needed either to write the program ourselves, or to simply drop support
> for the obsolete mime system.
in Debian any more. Did I missed something (URLs)? I insist in my
opinion that it is not correct to break an old but used (=established)
system intentionally to force others writing workarounds. (Cyril, it is
not about this specific bug - it is about the general principle.)
> Guess what: I’m not writing a tool, lest
> maintain it, for a technology that I don’t use.
> And since, after seven months, nothing happened, it means no one is
> interested enough, although some one-liners doing half of the job have
> been circulating.
when I was expecting evince. After purging xpdf I learned that see does
not find any pdf viewer. Sorry if I did not realised any discussion
seven monthes ago noch any one-line helpers.
So were can I read about which one-liner should be added to what package
to fix the problem you decided to force upon others.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120201085...@an3as.eu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Feb 1, 2012, 4:20:01 AM2/1/12
to
Andreas Tille <and...@an3as.eu> writes:
> Well, from my perspective I was bored the first time when xpdf came up
> when I was expecting evince. After purging xpdf I learned that see does
> not find any pdf viewer. Sorry if I did not realised any discussion
> seven monthes ago noch any one-line helpers.
> So were can I read about which one-liner should be added to what package
> to fix the problem you decided to force upon others.
So, I don't have a one-line script, but I generally agree with Josselin
> Well, from my perspective I was bored the first time when xpdf came up
> when I was expecting evince. After purging xpdf I learned that see does
> not find any pdf viewer. Sorry if I did not realised any discussion
> seven monthes ago noch any one-line helpers.
> So were can I read about which one-liner should be added to what package
> to fix the problem you decided to force upon others.
that maintaining the same information in two places is a bad idea. The
basic idea of what needs to be done is to convert the information in the
desktop files into the equivalent of a /usr/lib/mime/packages file.
For example, /usr/share/applications/xpdf.desktop has:
[Desktop Entry]
Name=xpdf
GenericName=PDF viewer
Comment=View PDF files
Exec=xpdf
Icon=xpdf
Terminal=false
Type=Application
MimeType=application/pdf;
Categories=Viewer;Graphics;
/usr/lib/mime/packages/xpdf has:
application/pdf; /usr/bin/xpdf %s; test=test "$DISPLAY" != ""; description=Portable Document Format; nametemplate=%s.pdf; priority=6
application/x-pdf; /usr/bin/xpdf %s; test=test "$DISPLAY" != ""; description=Portable Document Format; nametemplate=%s.pdf; priority=6
Obviously, the first field comes straight from MimeType (and, in general,
from the list of values in MimeType). I think one has to make the
assumption that one can add %s after Exec in order to load a file, since
the desktop entry doesn't have an equivalent of the command. The test is
the same for any application that says Terminal=false.
The description and nametemplate don't come from the same place. Those
come from /usr/share/mime/application/pdf.xml, and are the same for all
application/pdf entries.
The priority is a more interesting problem. I'm not sure how the desktop
specification assigns priorities when multiple applications can handle the
same MIME type.
This doesn't look like a trivial tool, but it looks possible to write.
What I'd do is teach update-mime how to handle desktop files as well and
then add a trigger for changes in /usr/share/applications.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87k446o...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Feb 1, 2012, 4:40:02 AM2/1/12
to
Le mercredi 01 février 2012 à 01:14 -0800, Russ Allbery a écrit :
> The description and nametemplate don't come from the same place. Those
> come from /usr/share/mime/application/pdf.xml, and are the same for all
> application/pdf entries.
That, and also you have to take into account aliases (different MIME
> The description and nametemplate don't come from the same place. Those
> come from /usr/share/mime/application/pdf.xml, and are the same for all
> application/pdf entries.
types characterizing the same file type) and subclasses (for example ODT
is a subclass of ZIP, yet you want to prioritize OOo if it is installed
to open it).
> The priority is a more interesting problem. I'm not sure how the desktop
> specification assigns priorities when multiple applications can handle the
> same MIME type.
specification handles defaults, instead of priorities. In Debian, we
take advantage of this to provide per-environment defaults. This way,
you can prioritize GNOME applications over KDE ones when running GNOME,
and vice versa. I don’t know if it’s possible to match that with the
mailcap system.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1328088922.9702.289.camel@pi0307572
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Feb 1, 2012, 5:00:02 AM2/1/12
to
Josselin Mouette <jo...@debian.org> writes:
> Le mercredi 01 février 2012 à 01:14 -0800, Russ Allbery a écrit :
>> The description and nametemplate don't come from the same place. Those
>> come from /usr/share/mime/application/pdf.xml, and are the same for all
>> application/pdf entries.
> That, and also you have to take into account aliases (different MIME
> types characterizing the same file type) and subclasses (for example ODT
> is a subclass of ZIP, yet you want to prioritize OOo if it is installed
> to open it).
Actually, I don't think you have to take any of that into account when
> Le mercredi 01 février 2012 à 01:14 -0800, Russ Allbery a écrit :
>> The description and nametemplate don't come from the same place. Those
>> come from /usr/share/mime/application/pdf.xml, and are the same for all
>> application/pdf entries.
> That, and also you have to take into account aliases (different MIME
> types characterizing the same file type) and subclasses (for example ODT
> is a subclass of ZIP, yet you want to prioritize OOo if it is installed
> to open it).
translating to mailcap, since it doesn't have this concept. It has a
mapping of MIME types to applications, and that's it. If you don't have a
mapping for that particular MIME type, the only other option you have is a
wildcard, and only text/* is really meaningful. So I think you can just
ignore this property; mailcap just doesn't have any way of opening ODT
files with a ZIP viewer when OOo isn't installed.
It's been a long time since I've done mailcap, though.
> Yes, that’s where things become interesting. The freedesktop
> specification handles defaults, instead of priorities. In Debian, we
> take advantage of this to provide per-environment defaults. This way,
> you can prioritize GNOME applications over KDE ones when running GNOME,
> and vice versa. I don’t know if it’s possible to match that with the
> mailcap system.
So there's no way to switch based on other system properties.
Well, you can use test to eliminate an application from consideration
entirely, but I don't think that fits for this.
That probably means that there's just no way to translate priority, and
you're going to have to guess or just take applications at random if
multiple applications with a desktop file manage the same MIME type. I
suppose you could apply a heuristic like using the application that has
the fewest MIME types it handles; I'm not sure if that's the right
approach.
The main place that mailcap is richer than the desktop file that I can see
is that mailcap allows you to express the exact command line (including
putting %s at different places if needed) and lets you specify different
commands for viewing, editing, and printing. For example:
message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal
I don't know if there's any way to do that with desktop files.
Also, I don't think there's a desktop equivalent of copiousoutput.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87fweuo...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Tille
Feb 1, 2012, 10:10:02 AM2/1/12
to
Hi,
On Wed, Feb 01, 2012 at 01:51:17AM -0800, Russ Allbery wrote:
> Josselin Mouette <jo...@debian.org> writes:
> ...
I confirm that I agree that we should prevent duplication of data which
was stated in previous mails.
> The main place that mailcap is richer than the desktop file that I can see
> is that mailcap allows you to express the exact command line (including
> putting %s at different places if needed) and lets you specify different
> commands for viewing, editing, and printing. For example:
>
> message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal
>
> I don't know if there's any way to do that with desktop files.
>
> Also, I don't think there's a desktop equivalent of copiousoutput.
Assuming that Russ did not overlooked something this means that mailcap
entries can not generatet from desktop files. So the one-liners
mentioned by Josselin which might solve 50% of the task could not easily
enhanced to two-liners doing 100% which do all the work. In other words
we dropped support for a technique that is used by several programs and
it seems a replacement is either hard to do or not possible at all.
I personally would cope with this by installing a local package carrying
the mailcap entries I need. However that can hardly be a solution for
our users. As a general solution I would see two ways:
1. Stop droping *.mime files from packages and reinjecting them.
2. Create a general mailcap entry collection package which works
around maintainers unwilling to support mailcap.
I'd prefer 1. because I see no point in just droping what worked in the
past and has no visible chance to break something heavily. Please
correct me if I'm wrong.
On Wed, Feb 01, 2012 at 01:51:17AM -0800, Russ Allbery wrote:
> Josselin Mouette <jo...@debian.org> writes:
> ...
I confirm that I agree that we should prevent duplication of data which
was stated in previous mails.
> The main place that mailcap is richer than the desktop file that I can see
> is that mailcap allows you to express the exact command line (including
> putting %s at different places if needed) and lets you specify different
> commands for viewing, editing, and printing. For example:
>
> message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal
>
> I don't know if there's any way to do that with desktop files.
>
> Also, I don't think there's a desktop equivalent of copiousoutput.
entries can not generatet from desktop files. So the one-liners
mentioned by Josselin which might solve 50% of the task could not easily
enhanced to two-liners doing 100% which do all the work. In other words
we dropped support for a technique that is used by several programs and
it seems a replacement is either hard to do or not possible at all.
I personally would cope with this by installing a local package carrying
the mailcap entries I need. However that can hardly be a solution for
our users. As a general solution I would see two ways:
1. Stop droping *.mime files from packages and reinjecting them.
2. Create a general mailcap entry collection package which works
around maintainers unwilling to support mailcap.
I'd prefer 1. because I see no point in just droping what worked in the
past and has no visible chance to break something heavily. Please
correct me if I'm wrong.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120201150...@an3as.eu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Biebl
Feb 1, 2012, 11:10:02 AM2/1/12
to
On 01.02.2012 16:03, Andreas Tille wrote:
> Hi,
>
> On Wed, Feb 01, 2012 at 01:51:17AM -0800, Russ Allbery wrote:
>> The main place that mailcap is richer than the desktop file that I can see
>> is that mailcap allows you to express the exact command line (including
>> putting %s at different places if needed) and lets you specify different
>> commands for viewing, editing, and printing. For example:
>>
>> message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal
>>
>> I don't know if there's any way to do that with desktop files.
>>
>> Also, I don't think there's a desktop equivalent of copiousoutput.
>
> Assuming that Russ did not overlooked something this means that mailcap
> entries can not generatet from desktop files. So the one-liners
> mentioned by Josselin which might solve 50% of the task could not easily
> enhanced to two-liners doing 100% which do all the work. In other words
> we dropped support for a technique that is used by several programs and
> it seems a replacement is either hard to do or not possible at all.
Tools like mutt, which need the extended mailcap syntax, can certainly
> Hi,
>
> On Wed, Feb 01, 2012 at 01:51:17AM -0800, Russ Allbery wrote:
>> The main place that mailcap is richer than the desktop file that I can see
>> is that mailcap allows you to express the exact command line (including
>> putting %s at different places if needed) and lets you specify different
>> commands for viewing, editing, and printing. For example:
>>
>> message/rfc822; mutt -Rf '%s'; edit=mutt -f '%s'; needsterminal
>>
>> I don't know if there's any way to do that with desktop files.
>>
>> Also, I don't think there's a desktop equivalent of copiousoutput.
>
> Assuming that Russ did not overlooked something this means that mailcap
> entries can not generatet from desktop files. So the one-liners
> mentioned by Josselin which might solve 50% of the task could not easily
> enhanced to two-liners doing 100% which do all the work. In other words
> we dropped support for a technique that is used by several programs and
> it seems a replacement is either hard to do or not possible at all.
continue to ship a mime file.
If a package ships both a desktop and a mime file, the conversion-tool
could simply skip the automatic generation of the mailcap entries under
the assumption that the manually written ones take precedence.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Russ Allbery
Feb 1, 2012, 5:20:02 PM2/1/12
to
The programs on my system that use the extended mailcap syntax are all
ones that aren't very invested in using *.desktop files right now anyway.
Things like copiousoutput are useful for commands that don't really fall
into the core area intended to be addressed by *.desktop.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87aa522...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Tille
Feb 1, 2012, 5:50:04 PM2/1/12
to
On Wed, Feb 01, 2012 at 05:03:17PM +0100, Michael Biebl wrote:
>
> Tools like mutt, which need the extended mailcap syntax, can certainly
> continue to ship a mime file.
>
> If a package ships both a desktop and a mime file, the conversion-tool
> could simply skip the automatic generation of the mailcap entries under
> the assumption that the manually written ones take precedence.
Could somebody please answer my implicite question why the mime files
>
> Tools like mutt, which need the extended mailcap syntax, can certainly
> continue to ship a mime file.
>
> If a package ships both a desktop and a mime file, the conversion-tool
> could simply skip the automatic generation of the mailcap entries under
> the assumption that the manually written ones take precedence.
are removed before such a conversion tool exists and thus shamelessly
are breaking applications that depend from it.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Russ Allbery
Feb 1, 2012, 6:00:01 PM2/1/12
to
Andreas Tille <and...@an3as.eu> writes:
> Could somebody please answer my implicite question why the mime files
> are removed before such a conversion tool exists and thus shamelessly
> are breaking applications that depend from it.
Josselin did answer your question. To paraphrase my understanding of the
> Could somebody please answer my implicite question why the mime files
> are removed before such a conversion tool exists and thus shamelessly
> are breaking applications that depend from it.
answer: because he (they, probably, but he only spoke for himself) doesn't
want to maintain those files because they duplicate information stored in
another system that he considers superior for the purposes of what he's
doing, their lack doesn't what he views as his primary target audience,
and by removing them he forces people who care about the mailcap support
to do the work of deriving that information from desktop files if they
care enough to keep the system working.
I can understand not liking this answer, but you did get an answer.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87liom1...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Wookey
Feb 1, 2012, 9:30:02 PM2/1/12
to
+++ Andreas Tille [2012-02-01 09:56 +0100]:
> Hi Josselin,
> > And since, after seven months, nothing happened, it means no one is
> > interested enough, although some one-liners doing half of the job have
> > been circulating.
>
> Well, from my perspective I was bored the first time when xpdf came up
> when I was expecting evince.
Same here. I recently noticed that I got epdfview instead of evince -
but they are much of a muchness, so I put this down to testing
randomness, or probably this new pdf reader 'stealing' the
application/pdf config. I've always been rather confused about the
interactions between the different application/filetype config systems
(and mc has it's own too) and irritating breakage is not exactly
unheard-of.
It wasn't at all obvious that the actual reason was a conspiracy to
remove mime file support from evince. Now that I know about it, I'm
not very impressed. Andreas has already expressed this annoyance so I
won't say it again.
As a packager I've been adding mime info recently to my packages so
that they work properly everywhere. I thought that's what packaging
(in Debian at least) was about.
I'm happy if someone can write an automagic tool for maintainers that
aren't going to support mime files any longer. But us mutt+mc types
really do still use this functionality every day. It doesn't look
obsolete to me, even if it has been superceded on the desktop. (And it
would be nice as a packager not to have to write this info down twice
in different approximately-equivalent formats).
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012020202...@dream.aleph1.co.uk
> Hi Josselin,
>
> > To break such a chicken/egg circle, we
> > needed either to write the program ourselves, or to simply drop support
> > for the obsolete mime system.
>
> Somehow I missed an announcement that mime is obsolete and not supported
> in Debian any more.
Me too - this is the first I've heard of it
> > To break such a chicken/egg circle, we
> > needed either to write the program ourselves, or to simply drop support
> > for the obsolete mime system.
>
> Somehow I missed an announcement that mime is obsolete and not supported
> in Debian any more.
> > And since, after seven months, nothing happened, it means no one is
> > interested enough, although some one-liners doing half of the job have
> > been circulating.
>
> Well, from my perspective I was bored the first time when xpdf came up
> when I was expecting evince.
but they are much of a muchness, so I put this down to testing
randomness, or probably this new pdf reader 'stealing' the
application/pdf config. I've always been rather confused about the
interactions between the different application/filetype config systems
(and mc has it's own too) and irritating breakage is not exactly
unheard-of.
It wasn't at all obvious that the actual reason was a conspiracy to
remove mime file support from evince. Now that I know about it, I'm
not very impressed. Andreas has already expressed this annoyance so I
won't say it again.
As a packager I've been adding mime info recently to my packages so
that they work properly everywhere. I thought that's what packaging
(in Debian at least) was about.
I'm happy if someone can write an automagic tool for maintainers that
aren't going to support mime files any longer. But us mutt+mc types
really do still use this functionality every day. It doesn't look
obsolete to me, even if it has been superceded on the desktop. (And it
would be nice as a packager not to have to write this info down twice
in different approximately-equivalent formats).
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Tille
Feb 2, 2012, 2:30:01 AM2/2/12
to
On Wed, Feb 01, 2012 at 02:52:22PM -0800, Russ Allbery wrote:
> Josselin did answer your question. To paraphrase my understanding of the
> answer: because he (they, probably, but he only spoke for himself) doesn't
> want to maintain those files because they duplicate information stored in
> another system that he considers superior for the purposes of what he's
> doing, their lack doesn't what he views as his primary target audience,
> and by removing them he forces people who care about the mailcap support
> to do the work of deriving that information from desktop files if they
> care enough to keep the system working.
OK, but in this case I think #658139 (and probably friends?) is
> Josselin did answer your question. To paraphrase my understanding of the
> answer: because he (they, probably, but he only spoke for himself) doesn't
> want to maintain those files because they duplicate information stored in
> another system that he considers superior for the purposes of what he's
> doing, their lack doesn't what he views as his primary target audience,
> and by removing them he forces people who care about the mailcap support
> to do the work of deriving that information from desktop files if they
> care enough to keep the system working.
incorrectly handled. It should not be wishlist + wontfix because
packages are actually broken. If Josselin and others are regarding this
as sombody else's problem the bug should be rather reassigned to
somebody else's package - in this case perhaps general comes to mind
because it affects several packages. Josselin was expecting the
"general void" to solve the problem and thus the bug should rather go
there (by keeping important severity).
Alternatively it also could be reassigned to mime-support because other
broken packages are basically relying on this one. However simply
hiding a problem by decreasing severity is a strange way to handle
something and assuming it would force somebody else to work.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120202072...@an3as.eu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Feb 2, 2012, 9:40:02 AM2/2/12
to
Le jeudi 02 février 2012 à 02:14 +0000, Wookey a écrit :
> It wasn't at all obvious that the actual reason was a conspiracy to
> remove mime file support from evince. Now that I know about it, I'm
> not very impressed. Andreas has already expressed this annoyance so I
> won't say it again.
Being annoyed and angry is nice and all, but if you want people to be
> It wasn't at all obvious that the actual reason was a conspiracy to
> remove mime file support from evince. Now that I know about it, I'm
> not very impressed. Andreas has already expressed this annoyance so I
> won't say it again.
impressed, actually working on the issue might achieve better results.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1328193172.9702.523.camel@pi0307572
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonas Smedegaard
Feb 2, 2012, 10:00:03 AM2/2/12
to
On 12-02-02 at 03:32pm, Josselin Mouette wrote:
> Le jeudi 02 février 2012 à 02:14 +0000, Wookey a écrit :
> > It wasn't at all obvious that the actual reason was a conspiracy to
> > remove mime file support from evince. Now that I know about it, I'm
> > not very impressed. Andreas has already expressed this annoyance so
> > I won't say it again.
>
> Being annoyed and angry is nice and all, but if you want people to be
> impressed, actually working on the issue might achieve better results.
The "issue" here (or at least at the dawn of this thread) is that some
> Le jeudi 02 février 2012 à 02:14 +0000, Wookey a écrit :
> > It wasn't at all obvious that the actual reason was a conspiracy to
> > remove mime file support from evince. Now that I know about it, I'm
> > not very impressed. Andreas has already expressed this annoyance so
> > I won't say it again.
>
> Being annoyed and angry is nice and all, but if you want people to be
> impressed, actually working on the issue might achieve better results.
package maintainers have chosen to break something that used to work.
It seems to me that Wookie indeed is "working on the issue": Attempting
to help clarify what is the issue, so that hopefully change the minds of
those upstreams and/or package maintainers currently tidying to only
provide XDG hints before being supported generally in Debian either
directly or through some clever Debian infrastructure.
...or at least help minimize the amount of fellow usptreams and/or
package maintainers following in the footsteps of those - hopefully few
- misguided ones currently tidying their packaging too aggressively.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
Josselin Mouette
Feb 2, 2012, 10:30:01 AM2/2/12
to
Le jeudi 02 février 2012 à 15:51 +0100, Jonas Smedegaard a écrit :
> The "issue" here (or at least at the dawn of this thread) is that some
> package maintainers have chosen to break something that used to work.
Claiming that the mime-support system actually works is stretching
> The "issue" here (or at least at the dawn of this thread) is that some
> package maintainers have chosen to break something that used to work.
reality as much as a bone who just met Chuck Norris’ fist. The policy
might claim it is the recommended way, but only a handful of programs,
such as mutt and lynx, actually make use of this information.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bernhard R. Link
Feb 2, 2012, 10:50:02 AM2/2/12
to
* Josselin Mouette <jo...@debian.org> [120202 16:23]:
> [the usual insults removed] The policy
a program for a given mime type. (xdgopen has still not got an option
to specify the mime-type, has it?)
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120202152...@server.brlink.eu
> [the usual insults removed] The policy
> might claim it is the recommended way, but only a handful of programs,
> such as mutt and lynx, actually make use of this information.
Or programs like "see" or everything using it that wants to savely run
> such as mutt and lynx, actually make use of this information.
a program for a given mime type. (xdgopen has still not got an option
to specify the mime-type, has it?)
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Tille
Feb 2, 2012, 10:50:02 AM2/2/12
to
On Thu, Feb 02, 2012 at 04:23:01PM +0100, Josselin Mouette wrote:
>
> Claiming that the mime-support system actually works is stretching
> reality as much as a bone who just met Chuck Norris’ fist.
I fail to see a reason to fall back to polemics.
>
> Claiming that the mime-support system actually works is stretching
> reality as much as a bone who just met Chuck Norris’ fist.
> The policy
> might claim it is the recommended way, but only a handful of programs,
> such as mutt and lynx, actually make use of this information.
explicitely given in the bug report. Adding w3m makes your hand really
full and a five minutes research would uncover another hand full.
However, to prove your point you need to mention counter examples which
are actually failing to use mime-support or are actually broken because
of using mime-support.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012020215...@an3as.eu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Feb 2, 2012, 11:00:01 AM2/2/12
to
Le jeudi 02 février 2012 à 16:43 +0100, Andreas Tille a écrit :
> > The policy
> > might claim it is the recommended way, but only a handful of programs,
> > such as mutt and lynx, actually make use of this information.
>
> Any reason you are leaving out those two programs (see, mc) which were
> explicitely given in the bug report. Adding w3m makes your hand really
> full and a five minutes research would uncover another hand full.
Oh, great. That changes everything, of course.
> > The policy
> > might claim it is the recommended way, but only a handful of programs,
> > such as mutt and lynx, actually make use of this information.
>
> Any reason you are leaving out those two programs (see, mc) which were
> explicitely given in the bug report. Adding w3m makes your hand really
> full and a five minutes research would uncover another hand full.
> However, to prove your point you need to mention counter examples which
> are actually failing to use mime-support or are actually broken because
> of using mime-support.
topic you are talking about?
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1328197942.9702.549.camel@pi0307572
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ian Jackson
Feb 2, 2012, 11:30:02 AM2/2/12
to
Josselin Mouette writes ("Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)"):
think policy is mandating an obsolete mechanism, is to get consensus
to change the approach for Debian as a whole.
The correct approach it is not to unilaterally decide to do switch to
some other half-implemented system, remove support for the previously
working machinery, and demand that bug submitters write the
compatibility code.
Ian.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20266.46581....@chiark.greenend.org.uk
> Le jeudi 02 février 2012 à 15:51 +0100, Jonas Smedegaard a écrit :
> > The "issue" here (or at least at the dawn of this thread) is that some
> > package maintainers have chosen to break something that used to work.
>
> Claiming that the mime-support system actually works is stretching
> reality as much as a bone who just met Chuck Norris’ fist. The policy
> might claim it is the recommended way, but only a handful of programs,
> such as mutt and lynx, actually make use of this information.
The correct approach if you don't like the existing machinery, and
> > The "issue" here (or at least at the dawn of this thread) is that some
> > package maintainers have chosen to break something that used to work.
>
> Claiming that the mime-support system actually works is stretching
> reality as much as a bone who just met Chuck Norris’ fist. The policy
> might claim it is the recommended way, but only a handful of programs,
> such as mutt and lynx, actually make use of this information.
think policy is mandating an obsolete mechanism, is to get consensus
to change the approach for Debian as a whole.
The correct approach it is not to unilaterally decide to do switch to
some other half-implemented system, remove support for the previously
working machinery, and demand that bug submitters write the
compatibility code.
Ian.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Feb 2, 2012, 12:10:03 PM2/2/12
to
Le jeudi 02 février 2012 à 16:12 +0000, Ian Jackson a écrit :
> The correct approach it is not to unilaterally decide to do switch to
> some other half-implemented system, remove support for the previously
> working machinery, and demand that bug submitters write the
> compatibility code.
The correct approach is to notice you have a perfectly working,
> The correct approach it is not to unilaterally decide to do switch to
> some other half-implemented system, remove support for the previously
> working machinery, and demand that bug submitters write the
> compatibility code.
fully-implemented system, that works fine across the whole distribution
except for a handful of packages, and to remove the compatibility code
for the legacy system.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1328202513.9702.593.camel@pi0307572
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Tille
Feb 2, 2012, 1:10:01 PM2/2/12
to
On Thu, Feb 02, 2012 at 04:52:22PM +0100, Josselin Mouette wrote:
> > However, to prove your point you need to mention counter examples which
> > are actually failing to use mime-support or are actually broken because
> > of using mime-support.
>
> Are you trying to troll, or do you actually not know anything of the
> topic you are talking about?
I'm probably a troll to consider answering messages like this, but in
> > However, to prove your point you need to mention counter examples which
> > are actually failing to use mime-support or are actually broken because
> > of using mime-support.
>
> Are you trying to troll, or do you actually not know anything of the
> topic you are talking about?
the paragraph above I was talking about logic and how to prove some
statement. At least when I was young I was winning some mathematics
contests where those knowledge was a precondition. So I'd like to
answer at lest the second part with "I know a bit about this".
Could you please now come back to the topic
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ian Jackson
Feb 2, 2012, 1:30:02 PM2/2/12
to
Josselin Mouette writes ("Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)"):
> Le jeudi 02 février 2012 à 16:12 +0000, Ian Jackson a écrit :
> > The correct approach it is not to unilaterally decide to do switch to
> > some other half-implemented system, remove support for the previously
> > working machinery, and demand that bug submitters write the
> > compatibility code.
>
> The correct approach is to notice you have a perfectly working,
> fully-implemented system, that works fine across the whole distribution
> except for a handful of packages, and to remove the compatibility code
> for the legacy system.
Whether something is a "legacy" system is a matter of opinion which
> > The correct approach it is not to unilaterally decide to do switch to
> > some other half-implemented system, remove support for the previously
> > working machinery, and demand that bug submitters write the
> > compatibility code.
>
> The correct approach is to notice you have a perfectly working,
> fully-implemented system, that works fine across the whole distribution
> except for a handful of packages, and to remove the compatibility code
> for the legacy system.
reasonable people can disagree on.
That's why you should get consensus before charging full steam ahead
with a change like this.
Ian.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Philip Hands
Feb 2, 2012, 1:50:02 PM2/2/12
to
On Thu, 02 Feb 2012 18:08:33 +0100, Josselin Mouette <jo...@debian.org> wrote:
> Le jeudi 02 février 2012 à 16:12 +0000, Ian Jackson a écrit :
> > The correct approach it is not to unilaterally decide to do switch to
> > some other half-implemented system, remove support for the previously
> > working machinery, and demand that bug submitters write the
> > compatibility code.
>
> The correct approach is to notice you have a perfectly working,
> fully-implemented system, that works fine across the whole distribution
> except for a handful of packages, and to remove the compatibility code
> for the legacy system.
I presume the subject of this thread explains why my emacs+notmuch setup
> Le jeudi 02 février 2012 à 16:12 +0000, Ian Jackson a écrit :
> > The correct approach it is not to unilaterally decide to do switch to
> > some other half-implemented system, remove support for the previously
> > working machinery, and demand that bug submitters write the
> > compatibility code.
>
> The correct approach is to notice you have a perfectly working,
> fully-implemented system, that works fine across the whole distribution
> except for a handful of packages, and to remove the compatibility code
> for the legacy system.
has lost the ability to show me pdfs.
I only very rarely get attachments, so the irritation of saving the file
and then pointing evince at it by hand was minor enough that I'd not got
round to finding out what the problem was.
Are you really saying that intentionally inflicting such low-grade
breakage and annoyance on your users is what you think it takes to
encourage them to write software for you?
This hardly seems compatible with our social contract.
Also, I note that there seems to be no warning that you've done this in
the NEWS or README files -- did you document this vandalism anywhere?
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/
|-| HANDS.COM Ltd. http://www.uk.debian.org/
|(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
brian m. carlson
Feb 2, 2012, 2:20:02 PM2/2/12
to
On Thu, Feb 02, 2012 at 06:08:33PM +0100, Josselin Mouette wrote:
> Le jeudi 02 février 2012 à 16:12 +0000, Ian Jackson a écrit :
> > The correct approach it is not to unilaterally decide to do switch to
> > some other half-implemented system, remove support for the previously
> > working machinery, and demand that bug submitters write the
> > compatibility code.
>
> The correct approach is to notice you have a perfectly working,
> fully-implemented system, that works fine across the whole distribution
> except for a handful of packages, and to remove the compatibility code
> for the legacy system.
The mime-support solution is part of Policy. It is a perfectly working,
> Le jeudi 02 février 2012 à 16:12 +0000, Ian Jackson a écrit :
> > The correct approach it is not to unilaterally decide to do switch to
> > some other half-implemented system, remove support for the previously
> > working machinery, and demand that bug submitters write the
> > compatibility code.
>
> The correct approach is to notice you have a perfectly working,
> fully-implemented system, that works fine across the whole distribution
> except for a handful of packages, and to remove the compatibility code
> for the legacy system.
fully-implemented solution. If you feel that it is obsolescent or
obsolete and should be replaced by a different solution, then it's your
job to convince other people of that, do the work to make that happen,
and request that Policy be amended accordingly. I have yet to see a bug
filed on the debian-policy package requesting that.
As it is, evince does not display PDFs from mutt. Thus your solution is
inadequate, because mutt does not use your solution (and there is no bug
filed against mutt to do so). You have thus broken an otherwise
perfectly working solution because you don't like it.
As a package maintainer, you're going to have to support some things you
don't like. If you hate natural alignment and think sparc is awful, you
still have to support it or find a co-maintainer who will. However
awful you think mime-support is, it's still part of Policy, and agreeing
on one system improves the experience for users, which is one of the
main purposes of a Linux distribution.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Michael Biebl
Feb 2, 2012, 2:30:03 PM2/2/12
to
On 02.02.2012 20:11, brian m. carlson wrote:
> The mime-support solution is part of Policy. It is a perfectly working,
...
> The mime-support solution is part of Policy. It is a perfectly working,
> As a package maintainer, you're going to have to support some things you
> don't like. If you hate natural alignment and think sparc is awful, you
talk again.
Seriously, all this whining is tiresome and doesn't get us one step
closer to a (technical) solution.
Russ Allbery
Feb 2, 2012, 4:00:03 PM2/2/12
to
Michael Biebl <bi...@debian.org> writes:
> Show us where mime-support is a required part in policy and then we can
> talk again.
Policy 9.7 currently says that it's a bug to not support mime-support:
> Show us where mime-support is a required part in policy and then we can
> talk again.
Packages which provide the ability to view/show/play, compose, edit or
print MIME types should register themselves as such following the
current MIME support policy.
and:
In the normative part of this manual, the words must, should and may,
and the adjectives required, recommended and optional, are used to
distinguish the significance of the various guidelines in this policy
document. Packages that do not conform to the guidelines denoted by
must (or required) will generally not be considered acceptable for the
Debian distribution. Non-conformance with guidelines denoted by
should (or recommended) will generally be considered a bug, but will
not necessarily render a package unsuitable for distribution.
So it depends on your definition of "required," I suppose.
Anyway, I think this discussion is painful and not likely to change
anyone's mind, whereas the necessary glue between desktop files and
mime-support looks like a couple of days of work. I'm currently playing
with the idea of writing a spec and posting it to Planet Debian asking
someone with the skill and some free time to implement it.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/877h05q...@windlord.stanford.edu
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Biebl
Feb 2, 2012, 4:30:01 PM2/2/12
to
On 02.02.2012 21:58, Russ Allbery wrote:
> Anyway, I think this discussion is painful and not likely to change
> anyone's mind, whereas the necessary glue between desktop files and
> mime-support looks like a couple of days of work. I'm currently playing
> with the idea of writing a spec and posting it to Planet Debian asking
> someone with the skill and some free time to implement it.
That would be very much appreciated.
> Anyway, I think this discussion is painful and not likely to change
> anyone's mind, whereas the necessary glue between desktop files and
> mime-support looks like a couple of days of work. I'm currently playing
> with the idea of writing a spec and posting it to Planet Debian asking
> someone with the skill and some free time to implement it.
And btw, thanks a lot for staying technical in this whole discussion!
I've reassigned #658139 to general.
I guess it would make sense to discuss further technical details there
or at least keep it updated with the outcome of your blog posting?
Cheers,
Andreas Tille
Feb 2, 2012, 4:40:04 PM2/2/12
to
Hi Russ,
On Thu, Feb 02, 2012 at 12:58:03PM -0800, Russ Allbery wrote:
> Michael Biebl <bi...@debian.org> writes:
>
> > Show us where mime-support is a required part in policy and then we can
> > talk again.
>
> Policy 9.7 currently says that it's a bug to not support mime-support:
Many thanks for always bringing discussions to some reasonable state by
sticking to pure facts.
> Anyway, I think this discussion is painful and not likely to change
> anyone's mind, whereas the necessary glue between desktop files and
> mime-support looks like a couple of days of work. I'm currently playing
> with the idea of writing a spec and posting it to Planet Debian asking
> someone with the skill and some free time to implement it.
It might make sense to mention #658139 in this spec which is now
assigned to general. When becoming suspicious about mime types
I noticed the following:
$ see test.ogg
Error: no "view" mailcap rules found for type "audio/ogg"
$ see test.mp3
-> brings up alsaplayer
So even some ogg capable players and probably other programs might
profit here. I just detected this by chance and thus would like to
mention that it might be needed to do some more general research. I
admit that I could perfectly live without a `see *.ogg` which is way
below my interest in getting proper settings for *.pdf - just mentioning
that in fact the problem is more general.
Kind regards
Andreas (who regrets to waste time of his fellow developers
by not resisting a provocation sometimes)
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012020221...@an3as.eu
On Thu, Feb 02, 2012 at 12:58:03PM -0800, Russ Allbery wrote:
> Michael Biebl <bi...@debian.org> writes:
>
> > Show us where mime-support is a required part in policy and then we can
> > talk again.
>
> Policy 9.7 currently says that it's a bug to not support mime-support:
sticking to pure facts.
> Anyway, I think this discussion is painful and not likely to change
> anyone's mind, whereas the necessary glue between desktop files and
> mime-support looks like a couple of days of work. I'm currently playing
> with the idea of writing a spec and posting it to Planet Debian asking
> someone with the skill and some free time to implement it.
assigned to general. When becoming suspicious about mime types
I noticed the following:
$ see test.ogg
Error: no "view" mailcap rules found for type "audio/ogg"
$ see test.mp3
-> brings up alsaplayer
So even some ogg capable players and probably other programs might
profit here. I just detected this by chance and thus would like to
mention that it might be needed to do some more general research. I
admit that I could perfectly live without a `see *.ogg` which is way
below my interest in getting proper settings for *.pdf - just mentioning
that in fact the problem is more general.
Kind regards
Andreas (who regrets to waste time of his fellow developers
by not resisting a provocation sometimes)
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
Feb 2, 2012, 6:30:01 PM2/2/12
to
Le jeudi 02 février 2012 à 19:11 +0000, brian m. carlson a écrit :
> The mime-support solution is part of Policy. It is a perfectly working,
> fully-implemented solution.
This is a blatant lack of knowledge of the current state of the
> The mime-support solution is part of Policy. It is a perfectly working,
> fully-implemented solution.
distribution.
> If you feel that it is obsolescent or
> obsolete and should be replaced by a different solution, then it's your
> job to convince other people of that, do the work to make that happen,
> and request that Policy be amended accordingly. I have yet to see a bug
> filed on the debian-policy package requesting that.
horse was already dead several years ago. Get a grip. Fix the policy if
you want to spend time on the problem.
> As it is, evince does not display PDFs from mutt. Thus your solution is
> inadequate, because mutt does not use your solution (and there is no bug
> filed against mutt to do so). You have thus broken an otherwise
> perfectly working solution because you don't like it.
evolution, epiphany, nautilus, rox-filer and konqueror. Thus your
solution is inadequate, because these programs do not use your solution
(there is no bug filed against them to do so, and if there was, we would
have a good laugh and close it).
> As a package maintainer, you're going to have to support some things you
> don't like.
respective maintainers, and replace a modern MIME system with decent
support for aliases, subtypes, defaults by a system that requires you to
write overly long files in an obscure language - but that works with
mutt.
Josselin Mouette
Feb 2, 2012, 6:30:01 PM2/2/12
to
Le jeudi 02 février 2012 à 18:59 +0100, Andreas Tille a écrit :
> On Thu, Feb 02, 2012 at 04:52:22PM +0100, Josselin Mouette wrote:
> > > However, to prove your point you need to mention counter examples which
> > > are actually failing to use mime-support or are actually broken because
> > > of using mime-support.
> >
> > Are you trying to troll, or do you actually not know anything of the
> > topic you are talking about?
>
> I'm probably a troll to consider answering messages like this, but in
> the paragraph above I was talking about logic and how to prove some
> statement. At least when I was young I was winning some mathematics
> contests where those knowledge was a precondition. So I'd like to
> answer at lest the second part with "I know a bit about this".
I’m very happy to read about that, but this is not a mathematics
> On Thu, Feb 02, 2012 at 04:52:22PM +0100, Josselin Mouette wrote:
> > > However, to prove your point you need to mention counter examples which
> > > are actually failing to use mime-support or are actually broken because
> > > of using mime-support.
> >
> > Are you trying to troll, or do you actually not know anything of the
> > topic you are talking about?
>
> I'm probably a troll to consider answering messages like this, but in
> the paragraph above I was talking about logic and how to prove some
> statement. At least when I was young I was winning some mathematics
> contests where those knowledge was a precondition. So I'd like to
> answer at lest the second part with "I know a bit about this".
contest.
> Could you please now come back to the topic
This is the MIME system most programs in Debian, including anything
related to GNOME, KDE, Xfce and certainly more (Firefox and rox come to
mind), are using nowadays:
http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html
And the standard for application associations:
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1328224807.21840.4.camel@tomoyo
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mike Hommey
Feb 3, 2012, 2:00:02 AM2/3/12
to
On Fri, Feb 03, 2012 at 12:27:40AM +0100, Josselin Mouette wrote:
> Le jeudi 02 février 2012 à 19:11 +0000, brian m. carlson a écrit :
> > The mime-support solution is part of Policy. It is a perfectly working,
> > fully-implemented solution.
>
> This is a blatant lack of knowledge of the current state of the
> distribution.
>
> > If you feel that it is obsolescent or
> > obsolete and should be replaced by a different solution, then it's your
> > job to convince other people of that, do the work to make that happen,
> > and request that Policy be amended accordingly. I have yet to see a bug
> > filed on the debian-policy package requesting that.
>
> This system has *already* been replaced by a different solution. That
> horse was already dead several years ago. Get a grip. Fix the policy if
> you want to spend time on the problem.
>
> > As it is, evince does not display PDFs from mutt. Thus your solution is
> > inadequate, because mutt does not use your solution (and there is no bug
> > filed against mutt to do so). You have thus broken an otherwise
> > perfectly working solution because you don't like it.
>
> As it is, programs registered in mime-support are not used from firefox,
> evolution, epiphany, nautilus, rox-filer and konqueror. Thus your
> solution is inadequate, because these programs do not use your solution
> (there is no bug filed against them to do so, and if there was, we would
> have a good laugh and close it).
Firefox does, and if it doesn't, it's a bug to be filed. It lacks
> Le jeudi 02 février 2012 à 19:11 +0000, brian m. carlson a écrit :
> > The mime-support solution is part of Policy. It is a perfectly working,
> > fully-implemented solution.
>
> This is a blatant lack of knowledge of the current state of the
> distribution.
>
> > If you feel that it is obsolescent or
> > obsolete and should be replaced by a different solution, then it's your
> > job to convince other people of that, do the work to make that happen,
> > and request that Policy be amended accordingly. I have yet to see a bug
> > filed on the debian-policy package requesting that.
>
> This system has *already* been replaced by a different solution. That
> horse was already dead several years ago. Get a grip. Fix the policy if
> you want to spend time on the problem.
>
> > As it is, evince does not display PDFs from mutt. Thus your solution is
> > inadequate, because mutt does not use your solution (and there is no bug
> > filed against mutt to do so). You have thus broken an otherwise
> > perfectly working solution because you don't like it.
>
> As it is, programs registered in mime-support are not used from firefox,
> evolution, epiphany, nautilus, rox-filer and konqueror. Thus your
> solution is inadequate, because these programs do not use your solution
> (there is no bug filed against them to do so, and if there was, we would
> have a good laugh and close it).
support for some keywords, though.
Mike
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ian Jackson
Feb 3, 2012, 7:20:02 AM2/3/12
to
Josselin Mouette writes ("Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)"):
> This is a blatant lack of knowledge of the current state of the
> distribution.
I'm afraid you are demonstrating your own blatant lack of knowledge.
> distribution.
> This system has *already* been replaced by a different solution. That
> horse was already dead several years ago. Get a grip. Fix the policy if
> you want to spend time on the problem.
programs have started implementing a different approach.
> Maybe you want to maintain all these programs instead of their
> respective maintainers, and replace a modern MIME system with decent
> support for aliases, subtypes, defaults by a system that requires you to
> write overly long files in an obscure language - but that works with
> mutt.
You are basically saying that you refuse to acknowledge that there is
any room for discussion; you refuse to make even the smallest
accomodation to the views of many of your co-developers and users; and
you are being very rude.
Ian.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Raphael Hertzog
Feb 18, 2012, 10:50:03 AM2/18/12
to
Hello,
On Wed, 01 Feb 2012, Josselin Mouette wrote:
> Le mardi 31 janvier 2012 à 21:51 +0100, Andreas Tille a écrit :
> > I agree that an automatic solution would be prefered. However, as long
> > as such someone does not stand up and write such a program removing
> > existing solutions is <feel free to insert any word which fits>.
>
> The point is, no one will write such a program until we remove support
> for the old system entirely.
FWIW, it looks like Josselin suggested this in #497779 more than 3 years
ago already.
So he certainly tried something else before simply removing the mailcap
file. I pinged the mime support maintainer, pointing to Russ' mail
explaining how to generate mailcap entries out of the desktop files.
Hopefully this will help since he seemed interested into supporting this.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120218154...@rivendell.home.ouaza.com
On Wed, 01 Feb 2012, Josselin Mouette wrote:
> Le mardi 31 janvier 2012 à 21:51 +0100, Andreas Tille a écrit :
> > I agree that an automatic solution would be prefered. However, as long
> > as such someone does not stand up and write such a program removing
> > existing solutions is <feel free to insert any word which fits>.
>
> The point is, no one will write such a program until we remove support
> for the old system entirely.
FWIW, it looks like Josselin suggested this in #497779 more than 3 years
ago already.
So he certainly tried something else before simply removing the mailcap
file. I pinged the mime support maintainer, pointing to Russ' mail
explaining how to generate mailcap entries out of the desktop files.
Hopefully this will help since he seemed interested into supporting this.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Tille
May 2, 2012, 9:40:03 AM5/2/12
to
Hi,
I just would like to warm up this thread a bit because I wonder if a
solution would be found in time for Wheezy release. It seems nobody
really seems to care about those suggested scripts and we are breaking a
certain amount of programs if mailcap entries are dropped without any
replacement. I wonder whether the severity of "important" is to weak to
reflect this. Several people in this thread expressed their annoyance
about this but nothing has happened so far. If nobody works on
automatic scripts (which are hard to write as Russ expressed here
because mailcap has features not implemented in freedesktop.org) should
we try something else to not spoil the wheezy user experience of terminal
addicted users?
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120502133...@an3as.eu
I just would like to warm up this thread a bit because I wonder if a
solution would be found in time for Wheezy release. It seems nobody
really seems to care about those suggested scripts and we are breaking a
certain amount of programs if mailcap entries are dropped without any
replacement. I wonder whether the severity of "important" is to weak to
reflect this. Several people in this thread expressed their annoyance
about this but nothing has happened so far. If nobody works on
automatic scripts (which are hard to write as Russ expressed here
because mailcap has features not implemented in freedesktop.org) should
we try something else to not spoil the wheezy user experience of terminal
addicted users?
Kind regards
Andreas.
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
May 2, 2012, 10:20:01 AM5/2/12
to
On Wed, 2012-05-02 at 15:30 +0200, Andreas Tille wrote:
> Hi,
>
> I just would like to warm up this thread a bit because I wonder if a
> solution would be found in time for Wheezy release. It seems nobody
> really seems to care about those suggested scripts and we are breaking a
> certain amount of programs if mailcap entries are dropped without any
> replacement. I wonder whether the severity of "important" is to weak to
> reflect this. Several people in this thread expressed their annoyance
> about this but nothing has happened so far. If nobody works on
> automatic scripts (which are hard to write as Russ expressed here
> because mailcap has features not implemented in freedesktop.org) should
> we try something else to not spoil the wheezy user experience of terminal
> addicted users?
I'm also not seeing GNOME applications as file type handlers in
> Hi,
>
> I just would like to warm up this thread a bit because I wonder if a
> solution would be found in time for Wheezy release. It seems nobody
> really seems to care about those suggested scripts and we are breaking a
> certain amount of programs if mailcap entries are dropped without any
> replacement. I wonder whether the severity of "important" is to weak to
> reflect this. Several people in this thread expressed their annoyance
> about this but nothing has happened so far. If nobody works on
> automatic scripts (which are hard to write as Russ expressed here
> because mailcap has features not implemented in freedesktop.org) should
> we try something else to not spoil the wheezy user experience of terminal
> addicted users?
Akregator (KDE application). So I'm not sure this is even 'just' a
problem for text-mode applications.
Ben.
--
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.
Sune Vuorela
May 2, 2012, 10:40:02 AM5/2/12
to
On 2012-05-02, Ben Hutchings <b...@decadent.org.uk> wrote:
> I'm also not seeing GNOME applications as file type handlers in
> Akregator (KDE application). So I'm not sure this is even 'just' a
> problem for text-mode applications.
I just tried to install 'gedit' to test it, and I can nicely now set
> I'm also not seeing GNOME applications as file type handlers in
> Akregator (KDE application). So I'm not sure this is even 'just' a
> problem for text-mode applications.
gedit as a handler for text/plain mimetype in my KDE Plasma Desktop.
So it seems to integrate quite nicely ?
/Sune
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Tille
May 31, 2012, 3:40:03 PM5/31/12
to
Hi,
On Wed, May 02, 2012 at 03:16:08PM +0100, Ben Hutchings wrote:
> I'm also not seeing GNOME applications as file type handlers in
> Akregator (KDE application). So I'm not sure this is even 'just' a
> problem for text-mode applications.
I have no idea whether the solution proposed below could help here: I
just injected
svn://svn.debian.org/collab-maint/deb-maint/mime-support-extra
which would bring back mime support for evince for all applications I'm
using. (I was too bored to always update a local evince package which
works.) It is *very* simple and does not implement all those nifty
suggestions given here but not yet implemented.
I see two options to go from here:
1. I just keep this package as a private solution.
2. I upload the package to unstable by
a) issuing a new ITP
b) turning #658139 into ITP: mime-support-extra
I have no idea what makes the best sense and whether ftpmaster would
accept such a package (I'm not even sure whether I in the position of
ftpmaster would accept this). I'd regard it as a too simple but helpful
workaround for a problem which should be solved differently.
In any case the idea is to collect issues of broken mime support where
maintainers are unable / not willing to respect Debian policy 9.7.
Adding more entries is simple: Just add the according mime file as
<pkg>.mime and add <pkg> to "Enhances" in debian/control.
What do you think?
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120531193...@an3as.eu
On Wed, May 02, 2012 at 03:16:08PM +0100, Ben Hutchings wrote:
> I'm also not seeing GNOME applications as file type handlers in
> Akregator (KDE application). So I'm not sure this is even 'just' a
> problem for text-mode applications.
just injected
svn://svn.debian.org/collab-maint/deb-maint/mime-support-extra
which would bring back mime support for evince for all applications I'm
using. (I was too bored to always update a local evince package which
works.) It is *very* simple and does not implement all those nifty
suggestions given here but not yet implemented.
I see two options to go from here:
1. I just keep this package as a private solution.
2. I upload the package to unstable by
a) issuing a new ITP
b) turning #658139 into ITP: mime-support-extra
I have no idea what makes the best sense and whether ftpmaster would
accept such a package (I'm not even sure whether I in the position of
ftpmaster would accept this). I'd regard it as a too simple but helpful
workaround for a problem which should be solved differently.
In any case the idea is to collect issues of broken mime support where
maintainers are unable / not willing to respect Debian policy 9.7.
Adding more entries is simple: Just add the according mime file as
<pkg>.mime and add <pkg> to "Enhances" in debian/control.
What do you think?
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Biebl
May 31, 2012, 5:00:02 PM5/31/12
to
On 31.05.2012 21:35, Andreas Tille wrote:
> In any case the idea is to collect issues of broken mime support where
> maintainers are unable / not willing to respect Debian policy 9.7.
> Adding more entries is simple: Just add the according mime file as
> <pkg>.mime and add <pkg> to "Enhances" in debian/control.
I don't think adding such a package is a good idea. It's just an ugly
> In any case the idea is to collect issues of broken mime support where
> maintainers are unable / not willing to respect Debian policy 9.7.
> Adding more entries is simple: Just add the according mime file as
> <pkg>.mime and add <pkg> to "Enhances" in debian/control.
work-around.
In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779 there is
already a patch by brian m. carlson. Any effort regarding this issue
should be spent getting this patch ready and applied to mime-support.
Andreas Tille
Jun 1, 2012, 7:40:02 AM6/1/12
to
Hi,
On Thu, May 31, 2012 at 10:56:50PM +0200, Michael Biebl wrote:
> On 31.05.2012 21:35, Andreas Tille wrote:
>
> > In any case the idea is to collect issues of broken mime support where
> > maintainers are unable / not willing to respect Debian policy 9.7.
> > Adding more entries is simple: Just add the according mime file as
> > <pkg>.mime and add <pkg> to "Enhances" in debian/control.
>
> I don't think adding such a package is a good idea. It's just an ugly
> work-around.
Fully ACK. That's why the first of the option what could be done was to
leave it as local package and do not upload it officially.
> In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779 there is
> already a patch by brian m. carlson. Any effort regarding this issue
> should be spent getting this patch ready and applied to mime-support.
I would consider the severity of this bug to low considering that
several applications are broken if we will not fix this problem before
the next stable release. Is there anything which prevents an upload of
this fix? If there would be no soonish upload I'd consider increasing
the severity to make sure it will not be forgotten somehow.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120601113...@an3as.eu
On Thu, May 31, 2012 at 10:56:50PM +0200, Michael Biebl wrote:
> On 31.05.2012 21:35, Andreas Tille wrote:
>
> > In any case the idea is to collect issues of broken mime support where
> > maintainers are unable / not willing to respect Debian policy 9.7.
> > Adding more entries is simple: Just add the according mime file as
> > <pkg>.mime and add <pkg> to "Enhances" in debian/control.
>
> I don't think adding such a package is a good idea. It's just an ugly
> work-around.
leave it as local package and do not upload it officially.
> In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779 there is
> already a patch by brian m. carlson. Any effort regarding this issue
> should be spent getting this patch ready and applied to mime-support.
several applications are broken if we will not fix this problem before
the next stable release. Is there anything which prevents an upload of
this fix? If there would be no soonish upload I'd consider increasing
the severity to make sure it will not be forgotten somehow.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages