Bug#824078: libdvd-pkg: fails to report "apt-get check" errors (and others) correctly
On Friday, 20 May 2016 12:50:48 AM AEST Austin English wrote: > I understand that there's a *potential* problem. Potential problem of breaking APT operations is much more dangerous than "actual" problem of ignoring return values. > But > here we have an *actual* problem, where the script is silently ignoring > errors which is causing problems in downstream, and as far as I can > tell, the current solution is to ignore actual errors in favor of > preventing *potential* solutions? That's right. Script was not intended to be used directly to begin with. It was designed to be run automatically at the end of APT operations and (re-)build passenger package when required. > What exactly needs to be tested in the current packaging scheme so that > behavior could be changed? I volunteer to help with that, if it's made > clear what needs to be done. Perhaps to temporary break script to always return error value and try various apt operations (e.g. install, remove and reconfigure of other packages) when post-invoke hook is activated to perform build or update. We need to be absolutely sure that build/install errors do not propagate where they does not belong and that nothing got broken if we take responsibility for propagation of those errors. -- Best wishes, Dmitry Smirnov. --- Without doubt you are not sane. -- Tage Danielsson signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#824078: libdvd-pkg: fails to report "apt-get check" errors (and others) correctly
On Sunday, 15 May 2016 3:15:50 PM AEST Cyril Brulebois wrote: > instead of being told again and again how much of a snow flake > your package is, and how OK it is for it to behave like it currently does. You seems to imply that everything is terribly wrong with the package that sounds like exadderation. Design may not be perfect but I'm not aware of better one... I'm all for improvements. But on this instance it is hard to safely improve on problems that you highlighted. It is more difficult than just propagate error codes or I would have already fixed it... I hope you understand... -- All the best, Dmitry Smirnov. --- It is impossible to imagine Goethe or Beethoven being good at billiards or golf. -- H. L. Mencken signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#824078: libdvd-pkg: fails to report "apt-get check" errors (and others) correctly
On Sunday, 15 May 2016 2:03:28 PM AEST Cyril Brulebois wrote: > Failing to return success or failure properly really is Bad Programming > 101. This means your uers have no programmatic way of knowing whether > what they called worked, and how to behave accordingly. I know, I know. :) I agree. However here safety concerns are more important: we can afford to fail to build a package but not to compromise package management by propagating errors where they naturally do not occur. I hope it make sense. > Silently pretending everything went fine when it didn't seems like a > reasonable behaviour? I strongly disagree. Breaking package management would be more dangerous than "silently" failing. (It does not really fail that silently). You do not understand design of this package. Examples you quoted in the original bug report are meant to work like this. "apt-get check" is a way to check whether it is safe to attempt installing .deb (we could just go ahead with attempt and let it fail further down the road). Failure of "apt-get check" is expected (to certain extent, as it is merely a safety precaution) and its exit code should not normally propagate even if it safe to do so. "dpkg -i /dev/zero" is already reworked into "dpkg -P non-existent-package" (as per #824093): it is to check whether DPKG database is locked hence failure is an expected behaviour (e.g. when APT is working) and exit code should not propagate either. What you are suggesting to change are not improvements in the context of this package. Although I agree with you that returning original exit value without overriding it is a best practice for most situations. > I didn't realize it got hooked up into apt (the build script is called > directly in Tails). Actually, this makes this issue looks even worth > than I thought… "Even worse" maybe? I'm not sure I understand your concerns... -- All the best, Dmitry Smirnov. --- In individuals, insanity is rare; but in groups, parties, nations and epochs, it is the rule. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#824093: dpkg-reconfigure libdvd-pkg fails to build libdvdcss2 with dpkg 1.18.7
On Thursday, 12 May 2016 5:54:40 PM AEST Carlos Maddela wrote: > I have attached a patch with this fix. Thank you very much for your help, Carlos. :) -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- "For every complex problem there is an answer that is clear, simple, and wrong. -- H. L. Mencken signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#824078: libdvd-pkg: fails to report "apt-get check" errors (and others) correctly
Hi Cyril, Thank you for your concerns and bug report. On Thursday, 12 May 2016 12:44:30 AM AEST Cyril Brulebois wrote: > Severity: important I don't understand how not returning exit code qualifies for "important" severity... IMHO it is "minor" unless I'm missing what kind of breakage it may cause... > But our wrapper specifically exited with '1' in that case, and it seemed > strange that debian/b-i_libdvdcss.sh didn't catch that. > [...] > I would suggest storing the return value > e.g. with "ret=$?", and using "exit $ret" so that this return value is > propagated. If propagating this return value isn't deemed interesting, > please at least "exit 1". This is not just ugly code of mine but deliberate/intentional decision to override exit code. Trouble is that libdvd-pkg hooks into APT post-invoke handler and run commands that normally never run on that stage. Therefore there is a risk and potential to break APT operations and cause system-wide effect... I feel uncomfortable about propagating exit status without good understanding of consequences and without serious testing (for which I have not time right now)... -- Regards, Dmitry Smirnov. --- The greatest personal limitation is to be found not in the things you want to do and can't, but in the things you've never considered doing. -- Richard Bandler signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#798929: Progress?
On Thursday 24 December 2015 01:05:11 Anton Gladky wrote: > is there any progress on this bug? No progress yet, still on my TODO list. I might be able to upload new translations during holidays in order to prepare for uploading to backports. -- Regards, Dmitry Smirnov. P.S. Please maintain meaningful subject. --- Ignorance is the mother of devotion. -- Dean Henry Cole signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#793937: libdvd-pkg: General update after the debconf review process
On Tuesday 15 December 2015 22:50:30 Félix Sipma wrote: > Has there been any progress on this issue since this last message? I suppose it is my turn to apply all contributed translations. I should be able to do so on holidays. Sorry for delay. -- Best wishes, Dmitry Smirnov. --- Scientific education and religious education are incompatible. The clergy have ceased to interfere with education at the advanced state, with which I am directly concerned, but they have still got control of that of children. This means that the children have to learn about Adam and Noah instead of about Evolution; about David who killed Goliath, instead of Koch who killed cholera; about Christ's ascent into heaven instead of Montgolfier's and Wright's. Worse than that, they are taught that it is a virtue to accept statements without adequate evidence, which leaves them a prey to quacks of every kind in later life, and makes it very difficult for them to accept the methods of thought which are successful in science. -- J. B. S. Haldane signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#802021: audacity: non-free files
Source: audacity Version: 2.0.6-2 Severity: important Files in "lib-src/libnyquist/nyquist/xlisp" have the following in the header: Copyright (c) 1985, by David Michael Betz All Rights Reserved Permission is granted for unrestricted non-commercial use Also I'm concerned about the following files in "lib-src/lv2/lv2/lv2specgen/DTD": xhtml-symbol.ent xhtml-special.ent xhtml-lat1.ent as they contain the following: Portions (C) International Organization for Standardization 1986: Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. Please investigate. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#800878: inkscape: non-free file "gallardo.svgz"
Source: inkscape Version: 0.91-5 Severity: important Dear maintainer, According to its metadata, image "/usr/share/inkscape/examples/gallardo.svgz" appears to be non-free: WorkLicense: http://creativecommons.org/licenses/by-nc-sa/2.5/ LicenseProhibits: http://web.resource.org/cc/CommercialUse WorkDescription: A traced Lamborghini Gallardo. The source image can be found at: http://en.wikipedia.org/wiki/Image:Lamborghini_Gallardo_silver.jpg -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#800878: inkscape: non-free file "gallardo.svgz"
On Sunday 04 October 2015 15:56:11 Mattia Rizzolo wrote: > On Mon, Oct 05, 2015 at 12:52:49AM +1100, Dmitry Smirnov wrote: > > According to its metadata, image > > "/usr/share/inkscape/examples/gallardo.svgz"> > > appears to be non-free: > > WorkLicense: http://creativecommons.org/licenses/by-nc-sa/2.5/ > > LicenseProhibits: http://web.resource.org/cc/CommercialUse > > WorkDescription: A traced Lamborghini Gallardo. > > The source image can be found at: > > http://en.wikipedia.org/wiki/Image:Lamborghini_Gallardo_silver.jpg > > It's funny because according to that wikipedia page the image under a > double license GFDL-1.2 / CC-BY-SA-3.0. Not really that funny because there are two different images - the original photo (CC-BY-SA-3.0) and its traced image (derivative) included to Inkscape under CC-BY-NC-SA-2.5... I reckon there is some irony... Anyway I found another non-free image: /usr/share/inkscape/examples/animated-clock.svg LicenseProhibits: http://web.resource.org/cc/CommercialUse WorkLicense: http://creativecommons.org/licenses/by-nc-nd/2.5/ Thanks. -- Best wishes, Dmitry Smirnov. --- Democracy is a pathetic belief in the collective wisdom of individual ignorance. -- H. L. Mencken signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#798929: libdvd-pkg: could you backport it for jessie
On Monday 14 September 2015 10:40:31 Picca Frédéric-Emmanuel wrote: > It would be great if we could install your package on Debian jessie. > > So would you considere backporting it. Good idea, thanks. "libdvd-pkg" is currently undergoing review by debian- i10n-english team. Once finished debconf dialogs and package description will be significantly imporoved. Then I'll upload "libdvd-pkg" to "jessie- backports". Thank you. -- Cheers, Dmitry Smirnov. --- In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual. -- Galileo Galilei signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797113: libdvd-pkg doesn't respect APT's proxy settings when downloading libdvdcss
On Monday 31 August 2015 00:58:50 Austin English wrote: > Would you consider switching to using curl? I've attached a patch > which does so (which fixes my issue when building tails with > libdvd-pkg). > > Alternatively, we could try wget, then curl, then uscan. If you prefer > that, let me know and I'll attach a new patch. Thanks but why do we need curl? Wget respects proxy settings from the "http(s)_proxy" environment variables so this issue appears to be merely incorrect proxy configuration on your system. Also you should be able to set wget proxy settings in "/etc/wgetrc" or in "~/.wgetrc" and no patching would be necessary... -- Regards, Dmitry Smirnov. --- The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought. -- John F Kennedy signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797113: libdvd-pkg doesn't respect APT's proxy settings when downloading libdvdcss
On Monday 31 August 2015 14:20:16 Austin English wrote: > I'll follow up with tails on how to handle this. If you would consider > adding the curl fallback or switching to curl, I'd appreciate it, but > understand if you don't want to fix what's not broken (in Debian). Thank you, I'll consider adding curl as alternative after I deal with other priorities... -- Cheers, Dmitry Smirnov. --- Each generation imagines itself to be more intelligent than the one that went before it, and wiser than the one that comes after it. -- George Orwell, Review of "A Coat of Many Colours: Occasional Essays" by Herbert Read, Poetry Quarterly (Winter 1945) signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797113: libdvd-pkg doesn't respect APT's proxy settings when downloading libdvdcss
Hi Austin, On Thursday 27 August 2015 15:48:13 Austin English wrote: I expect the download to use apt's proxy, and libdvdcss to build built. libdvd-pkg uses `wget` by but (in case of failure) there is a fallback to `uscan` if the latter is available. I suppose `uscan` might respect APT proxy settings so you might try installing devscripts package to see if it helps. -- Cheers, Dmitry Smirnov. --- It is impossible to imagine Goethe or Beethoven being good at billiards or golf. -- H. L. Mencken signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#797113: libdvd-pkg doesn't respect APT's proxy settings when downloading libdvdcss
Hi Austin, On Thursday 27 August 2015 18:58:51 Austin English wrote: Thanks for the suggestion, but uscan also fails: I'm sorry that `uscan` did not work for you. I had a thought about this problem and I think using APT proxy would be wrong and useless because libdvd-pkg downloads upstream sources directly from upstream and not from any of APT mirrors. Software like apt-cacher-ng automatically blocks such destinations so APT proxy will not be helpful for such case. Therefore I'm tagging this bug as wontfix. IMHO the only option is to configure proxy that `wget` understands. -- Best wishes, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#793937: [LCFC2] templates://libdvd-pkg/{templates}
On Sunday 23 August 2015 11:26:17 Christian PERRIER wrote:
This is the last call for comments for the review of debconf
templates for libdvd-pkg.
The reviewed templates will be sent on Tuesday, August 25, 2015 to this bug
report and a mail will be sent to this list with [BTS] as a subject tag.
The only thing which makes me feel uncomfortable about this version is
doing downloads in
This package automates the process of doing downloads of the source
files for ${PKGG} from videolan.org, compiling them, and installing the
binary packages (${PKGG_ALL}).
I suggest re-writing as
This package automates the process of downloading of the source files for
${PKGG} from videolan.org, compiling them and installing the
binary deb packages (${PKGG_ALL}).
--
All the best,
Dmitry Smirnov.
signature.asc
Description: This is a digitally signed message part.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#793937: [LCFC2] templates://libdvd-pkg/{templates}
Hi Justin,
On Sunday 23 August 2015 22:51:53 Justin B Rye wrote:
Dmitry Smirnov wrote:
The only thing which makes me feel uncomfortable about this version is
doing downloads in
This package automates the process of doing downloads of the source
Hmm, do can often be a bit weak, if that's what you mean...
I mean process of (doing|launching|performing) downloads feels heavy and
unnecessary... Why not just process of downloading?
That has an excess of (the), and it loses the plural instances of
downloads (plural runs automatically produce plural output packages,
so you can recycle this text for other downloaders regardless of how
many packages they produce per run). Oh, and you've lost a Harvard
comma again and put the deb back in after I thought we'd agreed to
take it out!
Sorry about those unintentional changes. I simply missed all that on manual
merge...
Would you be any happier with a version that just replaces doing
with something less weak, like performing or launching?
I reckon performing might be the best for this context but still I'm not
convinced if it is necessary...
What do you think of
This package automates the process of downloading source
files for ${PKGG} from videolan.org, compiling them, and installing the
binary packages (${PKGG_ALL}).
--
Best wishes,
Dmitry Smirnov
---
However beautiful the strategy, you should occasionally look at the
results.
-- Winston Churchill
signature.asc
Description: This is a digitally signed message part.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#793937: [RFR] templates://libdvd-pkg/{templates}
when it happens -- something like at the end of APT transaction...
Or is the probability of a dpkg lock problem high enough that there
needs to be a hint in that direction, like, say:
When updates are available, the hook will launch the
process of downloading the source, recompiling it, and (if it can acquire
a lock on the package database) using dpkg -i to install the new
versions.
This version seems to express hook status by if it can acquire a lock on the
package database which is not quite the same...
For now I'll count your requirement for minimal changes as a vote for
that version!
:)
And when the whole point of a package is to summon the software that
must not be named - a forbidden algorithm so unspeakable that merely
contemplating it causes the FTPmasters 2d10 san loss - well, I'd have
thought there'd be some hint at that in the description.
:) I love your sense of humour. :) I couldn't have said it better myself. :)
You may be overestimating my ability to navigate git trees, but I
think I've found them. There's one commit where you take out a
reference to the package being illegal in some jurisdictions - I can
see why that might make FTPmasters unhappy - but I don't see anything
even vaguely similar to my description of CSS. It looks as if you
leapt straight from this ridiculous thing is prohibited to all
relevant information is prohibited.
Then I reckon we may not have the full history of changes... I hope I won't
have to dig my email for proof...
It's legal to provide this software, but it *isn't* legal to explain
what CSS is?
Yes.
If this was the case, Wikipedia would be one vast scrum of lawyers,
but libdvdcss would have been available in Debian main all along.
I'm afraid it might be difficult for me to express how the legal side of it
works but please remember that Debian is different from Wikipedia in terms of
re-distributability. I think this level of indirection is necessary in some
jurisdictions where CSS-circumventing software is illegal.
Could you get the FTPmasters to produce a nice clear policy statement
about exactly what information can't be revealed? Then you could get
videolan.org to host that as a web page and link to it from the package
description.
Only as much as package description already reveals can be revealed but not
more. We should be able to re-phrase a little.
My latest version is a strictly language-fixes-only revision, bringing
the description generally into line with DevRef recommendations but
brazenly flouting a Debian Policy 3.4 should.
Thank you. I've applied most of your changes to control file (I've dropped
only of your choice part) and I've merged most of your improvements to
templates (I've changed doing downloads with downloading):
https://anonscm.debian.org/cgit/pkg-multimedia/libdvd-pkg.git/commit/?id¾e536ee
Would it be OK to replace
process of downloading of the source files for ${PKGG} from videolan.org
with
process of downloading ${PKGG} sources files from videolan.org
?
I really like most of your improvements to templates. Thanks to you now it is
much easier to understand what package really does. I much appreciate your
attention to details and thorough approach to translation. Thank you for
taking so much time to understand how this package works.
I'm attaching new control and templates files for review.
--
All the best,
Dmitry Smirnov.
---
Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
-- H. L. Mencken
signature.asc
Description: This is a digitally signed message part.
Source: libdvd-pkg
Section: contrib/utils
Priority: optional
Maintainer: Debian Multimedia Maintainers
pkg-multimedia-maintainers@lists.alioth.debian.org
Uploaders: Dmitry Smirnov only...@debian.org
Standards-Version: 3.9.6
Build-Depends: debhelper (= 9)
Vcs-Browser: http://anonscm.debian.org/cgit/pkg-multimedia/libdvd-pkg.git
Vcs-Git: git://anonscm.debian.org/pkg-multimedia/libdvd-pkg.git
Package: libdvd-pkg
Architecture: all
Provides: ${guest:Provides}
Depends: ${misc:Depends} ,build-essential
,wget | devscripts
,${guest:Build-Depends}
Recommends: ${guest:Recommends} ,libcap2-bin
Suggests: ${guest:Suggests}
Description: DVD-Video playing library - installer
This package fetches, compiles from source code, and installs library
packages necessary for playing video DVDs with media player
(such as VLC, SMplayer, Totem, etc.).
Template: libdvd-pkg/first-install
Type: note
_Description:
This package automates the process of downloading of the source files for
${PKGG} from videolan.org, compiling them and installing the
binary deb packages (${PKGG_ALL}).
.
Please run sudo dpkg-reconfigure ${PKGI} to launch this process for
the first time.
Template: libdvd-pkg/title_b-i
Type: title
_Description: Download, build and install ${PKGG}${VER}
Template: libdvd-pkg/build
Type: boolean
Default: true
_Description: Download
Bug#793937: [RFR] templates://libdvd-pkg/{templates}
. Certainly there is no need to explain that in full details anywhere but in README.source. Also I believe unnecessary technical details regarding particular implementation of check for DPKG database lock do not belong to debconf dialog. Please let's keep dialogs simple and introduce minimum changes, especially if you don't understand well enough how it works. I took this text from Template: fheroes2-pkg/post-invoke_hook-install, but we could certainly drop details like that. Agreed. Besides if I recall correctly I've never merged such technical details into fheroes2-pkg/post-invoke_hook-install... If you weren't prepared to allow us to review the templates and package description, it would have helped if you had said so when we asked. I have no objections against review and I'm not against it. Though I had no idea that I would have to defend technical design of the package. ;) It did not occur to me that I had to tell about how sensitive package description is but I'm quite all right with improving it even if there are limits to acceptable changes. Maybe we can focus on improving debconf dialogs first? (And sorry, but I'm not a developer. I won't see commits unless you can give me URLs I can browse to.) Sorry I thought package metadata or link from PTS page makes it easy enough to find repository: https://anonscm.debian.org/cgit/pkg-multimedia/libdvd-pkg.git The one thing users *don't* really need to be told here is that video DVDs can be played with a variety of media players. Listing them just means you'll have to update this text every couple of years as desktops change their minds about which one to use. I'm with you here but I don't know a better way to articulate the previous argument without mentioning players. I'm happy to mention generic player or players without mentioning any particular ones. I'm not sure you even need to do that. Your package is aimed at users who are *starting* by thinking right, I've got a media player and a DVD, is there some other thing I need? - you don't have to include adverts for the concept of watching DVDs on media players, you just need to tell them what problem it solves. Except that apparently telling them this is illegal?! Yeah, unfortunately package description can't reproduce any parts of libdvdcss description... On second thought it could be useful to know which players can take advantage of installed libdvdcss library. For that matter it makes perfect sense to mention particular players. It's legal to provide this software, but it *isn't* legal to explain what CSS is? Yes. However even if we can't elaborate what it does at least we say what software is going to be installed so users can read about it elsewhere... I can understand that we don't want to say this package is a tool for pirating DVDs by illegally bypassing CSS encryption, but I really think we could get a whole lot closer to mentioning the point of the exercise. For a start, with a minor tweak: Some features of the DVD-Video format use the Content Scramble System (CSS). Software to bypass this encryption cannot be distributed via the Debian repositories. I've been through this countless times. No, CSS can't be mentioned nor what Debian can (or can not) distribute. That's just a fact about a well-known publicly specified data format followed by a fact about how completely law-abiding Debian is. Could we not put these undisputed innocent facts in the description? It makes me feel quite uncomfortable but it seems that we can't/shouldn't do it... I ought to be providing an updated attempt at a patch, but instead I'm going to go for a walk. I need a walk too as we got ourselves into rather tiresome discussion... :) -- Best wishes, Dmitry Smirnov. --- You have enemies? Good. That means you've stood up for something, sometime in your life. -- Victor Hugo, Villemain, 1845 (often misattributed to Winston Churchill) signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#793990: libdvd-pkg: Debconf abuse
On Friday 07 August 2015 08:27:28 Christian PERRIER wrote: It won't make me like debconf notes better (if Joey Hess was still around, you might want to ask him about them, he would say that inventing debconf nontes wsa the worst idea he probably ever had...)but I already had cases in the debconf abuse bug reports, where maintainers disagreed with me and we finally agreed to.just disagreee..and bugs were either close or marked wontfix:-) I understand that situation with debconf notes is not ideal... Unfortunately I see no solution to this problem for this particular package. FYI my original implementation did not have that note and it was introduced on ftp-masters demand because (as everyone agreed) package should not do unexpected things and this one is already unusual enough... -- Best wishes, Dmitry Smirnov. --- The Santa myth is one of the most effective means ever devised for intimidating children, eroding their self-esteem, twisting their behavior, warping their values, and slowing their development of critical thinking skills. -- Tom Flynn, The Trouble with Christmas signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#793990: libdvd-pkg: Debconf abuse
On Wednesday 29 July 2015 14:53:41 Christian Perrier wrote: This package seems to use a debconf note to notify users without any special action. If it is about a particular note then which one? FYI debconf prompt was introduced by request of Ansgar (on behalf of ftp- master) as a condition for entering archive. libdvd-pkg uses debconf dialogs to configure or schedule important actions that may not be possible to do when dialog is displayed. At the moment I can't quite recognise the abuse without further hints... -- Regards, Dmitry Smirnov --- If any remedy is tested under controlled scientific conditions and proved to be effective, it will cease to be alternative and will simply become medicine. So-called alternative medicine either hasn't been tested or it has failed its tests. -- Richard Dawkins, 2007 signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Thanks for insight into upstream security situation, Balint. So what would be the next step? Mass bug filings? Shall we draft a template here? -- All the best, Dmitry Smirnov --- It is a fine thing to be honest, but it is also very important to be right. -- Winston Churchill signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Fwd: RM: flumotion -- ROM; unmaintained upstream; depends on obsolete gstreamer0.10
On Wed, 20 May 2015 16:36:03 IOhannes m zmölnig wrote: just to let you know that i requested a package removal for 'flumotion'. Thanks for the note. So icecast2 is the only remaining alternative to flumotion, right? -- All the best, Dmitry Smirnov signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Mon, 18 May 2015 12:16:32 Reinhard Tartler wrote: Interestingly Gentoo recently switched to FFmpeg by default [3] after conducting a survey [4]. About 300 people participated in that survey and the outcome was rather clear: It saddens me to see people organizing votes where people participate that have no idea what they are voting about. How many of the 300 people that participated have tried to cherry pick a fix to libavcodec, or can even tell what the difference between libavcodec and libswscale is? Voting among people who perfectly understands the problem would be unnecessary. But even votes from people who is not deeply into ffmpeg/libav differences are valuable because people have different perspectives. In this particular case the outcome was quite convincing unlike cases where ~51% is for something and ~49% is against (and everybody have a feeling that outcome is a mistake or mere twist of luck). It may be appealing to discredit voters (and invalidate outcome) but in general Gentoo users are not that illiterate... It took very much work and a long time to get were we are today. It would be very sad to see this work undone. We have opportunity to avoid even more work that is likely will be of little value in the future. Sensible for Debian? I'm not sure. You bring a number of good points, but there is a significant long-term risk with relying on a single genius developer. I'd rather love to see people working together than against each other, but that might be wishful thinking. This is another way to explain why I'm so undecided what to recommend: On the one hand, I of course can follow the argument that technically, it appears easy to abandon libav and migrate Debian over to the FFmpeg variant and benefit from all the additional functionality that have accumulated over time. This adds additional significant risks. I can also see the argument that compared to other risks that we take (see mysql/mariadb, openoffice/libreoffice, etc.) this may or may not be acceptable. Over time project with more gravity to attract contributors will evolve faster leaving another project behind with ever increasing gap. It affects long-term maintainability. We need to stay with more active project not only for features but due to pragmatic expectation that more active project will be better maintained. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual. -- Galileo Galilei signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Mon, 18 May 2015 16:05:11 Jonas Smedegaard wrote: How would they not be relevant? They recommend users to use ffmpeg and list examples of problems they may encounter if they decide to use mpv with libav (problems that are regularly reported as mpv bugs). Because a) it is not a comparison (as Dmitry introduced it) but a non-exhaustive list now shrunk to a single concrete item (subtitle coverage) that you find wrong to focus on and instead bring a different example of your own, and because b) it is not an assesment of *our* problem but a different problem that can be solved by running a script that recompiles against uptodate FFmpeg statically linked against mpv. Apologies for poor choice of words. Not much of a comparison (call it as you like) this ffmpeg vs. libav page contained some insights into pros and cons. Of course information there was incomplete and that's probably why it was taken down -- it is not mpv developers' job to maintain ffmpeg vs. libav wiki which opens them for criticism about inaccurate/incomplete/biased comparison. I imagine they've made up their minds and that page was not needed any more. Yet it had some useful information (that's why I mentioned it). -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- It is no use saying, 'We are doing our best.' You have got to succeed in doing what is necessary. -- Winston Churchill signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
Hi Andreas, Thank you for a very good overview. On Fri, 15 May 2015 16:55:30 Andreas Cadhalpun wrote: FFmpeg is clearly better at fixing security issues. To take a random example, an out of bounds read in the bink decoder was fixed in FFmpeg three years ago [1], while Libav git master is still vulnerable today. [...] Interestingly Gentoo recently switched to FFmpeg by default [3] after conducting a survey [4]. About 300 people participated in that survey and the outcome was rather clear: 62%[ 189 ]I prefer ffmpeg, and it should be the default. 4% [ 15 ]I prefer libav, and it should be the default. [...] Maybe Moritz can elaborate on this. It seems he already did [11]: I think ffmpeg is doing better in terms of handling security issues; when I contacted Michael Niedermeyer in private we has always quick to reply, while libav-security@ seems understaffed: Several queries in the past needed additional poking, some were left unaddressed until today. Also, the Google fuzzer guys stated that more samples are unfixed in libav compared to ffmpeg. [...] 3: http://thread.gmane.org/gmane.linux.gentoo.devel/95339/focus=95585 4: https://forums.gentoo.org/viewtopic-t-1010096.html 11: https://lists.debian.org/debian-devel/2014/08/msg00060.html After the above I don't need any more evidence to support transition to ffmpeg. There are benefits of reducing differences from other distros who already uses ffmpeg. After all with ffmpeg we will benefit from better upstream support. IMHO if Moritz thinks that ffmpeg is better from security prospective it means that we don't have a case for libav any more. I am now convinced that it will be better for Debian to use ffmpeg. I also found an interesting comparison where mpv upstream shares their assessment of the problem: https://web.archive.org/web/20150115005029/https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- It is a mistake to try to look too far ahead. The chain of destiny can only be grasped one link at a time. -- Winston Churchill signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Select provider of libav* libraries
On Sat, 9 May 2015 16:00:49 Andreas Cadhalpun wrote: What would you count as very compelling reasons if more features, less bugs and better security support are not sufficient? More features is not necessary means less maintenance burden; Less bugs is not always means better software (it is a matter of how upstream manages bugs); Quality of security support is something that remains to be seen. Those are all technical concerns but to me there are other concerns that I believe are more important. I think we are all can agree that it would be beneficial if both projects join forces and abandon competition in favour of cooperation. Therefore if one project disappear then another one would naturally unite remaining contributors. Then we will have all technical benefits of better upstream support, less bugs, more features, stronger security as well as less duplication of effort, less fragmentation and less maintenance burden. When we were choosing init system I was against upstart because I did not want Debian to become its life support. Remember how quickly upstart faded into obsolescence when it became clear that Debian is not going to use it? I have a feeling that Debian already became life support for libav. Ever since Debian chosen libav, ffmpeg remained alive and apparently doing well without our help. I'm not too sure if libav would be able to stay alive without Debian. From maintenance prospective libav seems to be a liability. We have to carry patches for packages where upstreams are not too concerned about supporting libav. I maintain 4 packages with patches to replace `ffmpeg` with `avconv` (blktrace, seekwatcher, synfig, zoneminder). I maintain at least four packages depending on libav libraries: * xpra: upstream cares for other distros so he supports ffmpeg and (reluctantly) libav because we are using it. He prefers ffmpeg. Packaging contains three libav-specific patches. * tupi: was using ffmpeg but switched to libav following our trend. Still builds with ffmpeg (as far as I'm aware). * synfig: upstream could not care less about libav; supports only ffmpeg and fails to build with libav. Also contains patch to replace `ffmpeg` with `avconv`. We build synfig without ffmpeg/libav libraries at all. * zoneminder: supports both but upstream once commented that Staying on top of the libav/ffmpeg mess seems to be a full time job in and of itself. Also in the light of past libav transitions and deprecations that required multiple changes in Debian and upstream I know no upstream who is happy to support libav. All my experience tells me that with ffmpeg we shall be just as good as with libav, or better. I am not qualified for technical comparison between ffmpeg and libav. My assessment is purely from maintenance prospective, both in Debian and upstream. Although I have no first hand experience with ffmpeg I tend to support switching to ffmpeg because upstreams that I'm in touch with seems to prefer ffmpeg over libav. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#783258: flac: FTBFS due to missing symbols
On Sun, 26 Apr 2015 09:55:40 Fabian Greffrath wrote: Am Sonntag, den 26.04.2015, 01:10 +1000 schrieb Dmitry Smirnov: .symbols seems not to be very useful for C++ and they come with high maintenance cost. I'd probably just remove libflac++6.symbols... Yes, that would probably be the easiest solution. And I am inclined to do just this, as I am not really fluent in C++. But, I'd prefer if someone with more experience in C++ libraries could chime in as a second (ne, third) Uploader and take care of that file at least. ;) No worries, I'll do that. :) -- Cheers, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#772748: [synfigstudio] Interface doesn't accept changes in all parameters.
Hi, On Wed, 10 Dec 2014 20:19:27 Fenix wrote: Severity: grave Please let's not panic and use correct severity level: https://www.debian.org/Bugs/Developer#severities Here is more info: -- http://www.synfig.org/forums/viewtopic.php?f=15t=6044p=24734#p24734 -- Fantastic, there are links right to the patch, thank you. I don't know it the patch is in unstable version 0.42.2-2, but if that version doesn't go to testing, it'll made the frozen package mostly non usable. I see.. Please confirm if just uploaded package fixes this problem for you and I'll submit unblock request to release team if it does. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- If any remedy is tested under controlled scientific conditions and proved to be effective, it will cease to be alternative and will simply become medicine. So-called alternative medicine either hasn't been tested or it has failed its tests. -- Richard Dawkins, 2007 signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#763915: libva-dev: package lacks static libraries
On Fri, 3 Oct 2014 20:12:35 Peter Keel wrote: libva-dev lacks libva.a and libva.la, and I think it's policy that it should have that. Static libraries are optional. In some of my packages I tend to leave static libs behind quite deliberately to discourage static linking. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738811: handbrake: crashes after source DVD is selected
Are you using dvdnav or libdvdread (check in File/Preferences/Advanced)? libdvdread used to be problematic in the past and once it was causing similar crash, see #688574. Unfortunately it looks like it hasn't been properly fixed which makes me wonder if it hit us again... -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] synfig-synfig/master: commented unused libav and ffmpeg (Build-)Depends.
On Fri, 13 Sep 2013 22:24:49 Sebastian Ramacher wrote: Please also remove libmod_ffmpeg.so from the binary package. It's useless without a ffmpeg binary. OK, thanks for suggestion. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] synfig-synfig/master: .symbols update
On Fri, 13 Sep 2013 22:27:27 Sebastian Ramacher wrote: On 2013-09-13 11:25:14, only...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit 3614efd8d34e7d187527a8f7a631e17a8b5f6d2e Author: Dmitry Smirnov only...@member.fsf.org Date: Fri Sep 13 21:16:37 2013 +1000 .symbols update This is still broken and failed to build on the buildds. See https://buildd.debian.org/status/fetch.php?pkg=synfigarch=i386ver=0.64.0-2stamp=1379072718 for an example. Thanks, it looks like introducing .symbols wasn't a good idea... I'm not sure how to handle situation like this... Sebastian, could you please comment/advise on the following bug as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709779 Thank you. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#709779: this needs a versioned depends...
On Tue, 4 Jun 2013 03:02:26 Holger Levsen wrote: this bug is not fixed just because all versions are accidently in sync again, instead, this needs to be ensured by a dependency. I'm not convinced that synfigstudio needs vesrsioned dependency on exact version of libsynfig0. Perhaps the real problem is how library mini-transition was handled. Upstream broke it and I uploaded synfig (library) and synfigstudio (GUI) in a way that synfig propagated to testing a bit earlier than synfigstudio. The older version of synfigstudio in testing was effectively broken for few days until newer synfigstudio migrated. I agree that perhaps packages could benefit from tighter dependency. I committed .symbols file and dh_makeshlibs -V override [1] so when both packages will be rebuilt new dependency (calculated by `dh_shlibdeps`) will look like this: libsynfig0 (= 0.64.0). However it won't save from potential breakage if future libsynfig0 versions will be backwards incompatible with synfigstudio. I think hard-coded dependency on exact version of libsynfig0 is a bad idea. I'm not sure how to handle this bug. Perhaps I need advise on how to upload future updates to synfig package without breaking synfigstudio... Would it be a good idea to follow the usual transition procedure when the only one dependency package is involved to library update? [1]: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/synfig-synfig.git;a=commitdiff;h=4bbd2508f8ace12687e904015d15628ce63d79c1 Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- Good luck happens when preparedness meets opportunity. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#692974: Bug:#692974: synfigstudio: some crashes during layer edition
Dear Luc, Recently synfig was updated to version 0.64.0 -- could you please kindly check if it is affected by this problem? Thank you. All the best, Dmitry Smirnov GPG key : 4096R/53968D1B --- Good luck happens when preparedness meets opportunity. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#699722: src:libav: x264 decoding crashes
Xpra upstream commented on issue [1]: Confirmed as a libav bug, I was seeing memory allocation these errors on mac osx: Non-aligned pointer being freed as per http://stackoverflow.com/questions/4055277/non-aligned-pointer-being-freed-on-mac Downgrading to libav 0.8.5 fixes the issue, Not an xpra bug, closing. [1]: https://www.xpra.org/trac/ticket/244#comment:5 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#699722: src:libav: x264 decoding crashes
Package: src:libav Version: 6:9.1-3 Severity: normal I still don't have a whole picture but starting with one of the latest libav experimental releases xpra package started to crash on x264 decoding: === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x76d76)[0x7f22c283bd76] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7f22c2840aac] /usr/lib/x86_64-linux-gnu/libavutil.so.52(av_freep+0xc)[0x7f22bf0989ac] /usr/lib/x86_64-linux-gnu/libavcodec.so.54(avcodec_get_frame_defaults+0x13)[0x7f22be09ed93] /usr/lib/python2.7/dist-packages/xpra/x264/codec.so(decompress_image+0x61)[0x7f22bee83731] /usr/lib/python2.7/dist-packages/xpra/x264/codec.so(+0x5faa)[0x7f22bee7ffaa] /usr/bin/python(PyEval_EvalFrameEx+0x2de)[0x4ac5ce] /usr/bin/python(PyEval_EvalFrameEx+0xaf0)[0x4acde0] I wonder where this regression comes from... -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] glmark2/master: RFP/ITP bug #695849 assigned
Hi Reinhard, On Fri, 4 Jan 2013 00:32:19 Reinhard Tartler wrote: c) is already processed by PET: http://pet.debian.net/pkg-multimedia/pet.cgi I removed glmark2 repository from pkg-multimedia but it is still appears in PET. Please advise. -- Cheers, Dmitry Smirnov GPG : 53968D1B --- Faith: Belief without evidence in what is told by one who speaks without knowledge, of things without parallel. (Ambrose Bierce) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] glmark2/master: RFP/ITP bug #695849 assigned
On Thu, 3 Jan 2013 23:10:15 Reinhard Tartler wrote: On Thu, Dec 13, 2012 at 1:59 PM, onlyjob-gu...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit d191a4eb0740b54661c4cc0fc288b79063e822a4 Author: Dmitry Smirnov only...@member.fsf.org Date: Thu Dec 13 23:59:01 2012 +1100 RFP/ITP bug #695849 assigned diff --git a/debian/changelog b/debian/changelog index 9c36013..19d9f30 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,5 +1,5 @@ glmark2 (2012.11-1) UNRELEASED; urgency=low - * Initial release (Closes: #). + * Initial release (Closes: #695849). -- Dmitry Smirnov only...@member.fsf.org Thu, 13 Dec 2012 23:31:56 +1100 Sorry Reinhard, I'm a bit confused which package you're talking about -- glmark2 or libdvdcss-pkg? You quoted one bug but posted to another... TBH, I think this package is (currently) not fit for the pkg-multimedia team for two reasons: a) It does not contain the upstream sources, only the packaging directory debian/ is in the tree If it is glmark2 it is easy enough to fix if you're concerned about team's best practice. Is this so important because of team preference? In SVN we usually track only packaging. I think choosing git shouldn't always imply git-buildpackage repository layout... b) It is not backed up by some other pkg-multimedia team member. Please help me to understand -- because I'm not sure what package you're talking about. Do we need at least one team member to back it up? Or would you insist on minimum two members? Dimitry, unless both issues can be fixed, I think collab-maint would serve a much better umbrella than pkg-multimedia. Although glmark2 is finished I'm a bit reluctant to take responsibility for it at this time but I might do it later. Package glmark2 is much related to multimedia and appears to be a good fit for a team. Does it make sense to move it to collab-maint for some time? Even if not maintained now, it's a new package so perhaps it's not too important where it is waiting for maintainer while it is not uploaded yet. It feels a bit like finish it or leave... Speaking about finishing, did you have a chance to try it? Do you think it is useful despite failure of some opengl (but not opengl-es) tests? If so I'm happy to own ITP even though it might not be a right time for me. Thank you. -- Regards, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] glmark2/master: RFP/ITP bug #695849 assigned
On Fri, 4 Jan 2013 00:02:12 Reinhard Tartler wrote: Well, I think consistency in the workflow is important for working efficiently in a team. Therefore, this point is for me an absolute requirement for working on the package. Yes you're right. I can only agree. IOW: I do not the svn-buildpackage package layout, and I absolutely hate it. I'm sure you have your reasons. I'm OK to convert, sorry for troubles. b) It is not backed up by some other pkg-multimedia team member. Please help me to understand -- because I'm not sure what package you're talking about. Do we need at least one team member to back it up? Or would you insist on minimum two members? Yes, I do really think that *every* package in pkg-multimedia should have *at least* two *active* team members in the Uploaders field. Everything else indicates that not enough developers in the team care for the package, which in the end is harmful for pkg-multimedia. We already a pretty bad maintainer per package ratio, and adding more poorly-maintained packages does not help at all. OK, thanks for explaining. I have two concerns though. This package is not uploaded so it does not affect maintainer per package ratio. Not yet. It doesn't make any sense to move package repository to collab-maint whenever there is less than two active maintainers. Wouldn't we push less active packages away from pkg-multimedia like this? You're talking about desirable (ideal) situation. Dimitry, unless both issues can be fixed, I think collab-maint would serve a much better umbrella than pkg-multimedia. Although glmark2 is finished I'm a bit reluctant to take responsibility for it at this time but I might do it later. Package glmark2 is much related to multimedia and appears to be a good fit for a team. Does it make sense to move it to collab-maint for some time? Even if not maintained now, it's a new package so perhaps it's not too important where it is waiting for maintainer while it is not uploaded yet. It feels a bit like finish it or leave... Speaking about finishing, did you have a chance to try it? Do you think it is useful despite failure of some opengl (but not opengl-es) tests? If so I'm happy to own ITP even though it might not be a right time for me. Sorry, I neither have time nor interest to investigate glmark2, nor do I find glmark2 particularly in scope of pkg-multimedia. Moreover, the svn-buildpackage style packaging already deterred me enough to refrain me to take a closer look. Sorry Reinhard, I didn't know you feel so strong about it. Of course I'll move the package to collab-maint if you insist. Otherwise I'll convert its repository to git-buildpackage layout so we can decide whenever we want it in pkg-multimedia. Thanks. -- Regards, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] glmark2/master: RFP/ITP bug #695849 assigned
On Fri, 4 Jan 2013 00:32:19 Reinhard Tartler wrote: It doesn't make any sense to move package repository to collab-maint whenever there is less than two active maintainers. Wouldn't we push less active packages away from pkg-multimedia like this? Yes, and I think this is desireable if we do not want pkg-multimedia to deter to some other multimedia-related Debian QA-group. Let's please leave that for the proper Debian QA group. OK. You're talking about desirable (ideal) situation. I'm not sure if I understand this comment. I meant to say that 2 maintainers per package is ideal and desirable situation which is not necessarily true for every single package in team. :) It feels a bit like finish it or leave... Speaking about finishing, did you have a chance to try it? Do you think it is useful despite failure of some opengl (but not opengl-es) tests? If so I'm happy to own ITP even though it might not be a right time for me. Sorry, I neither have time nor interest to investigate glmark2, nor do I find glmark2 particularly in scope of pkg-multimedia. Moreover, the svn-buildpackage style packaging already deterred me enough to refrain me to take a closer look. Sorry Reinhard, I didn't know you feel so strong about it. Of course I'll move the package to collab-maint if you insist. Otherwise I'll convert its repository to git-buildpackage layout so we can decide whenever we want it in pkg-multimedia. Thanks. It's not that I really insist on something. I'm wondering what is the best way to go with the package. While not uploaded yet, it already does consume considerable team ressources, and since it seems that nobody else in the team is interested in the package, I feel that you would have less effort with leaving the packaging style as it is and just move the repository to collab-maint. Perhaps not enthusiastically enough I expressed my interest and I'm willing to prioritise if you feel that I should. But I'm only one person so I'll move glmark2 to collab-maint within few days. I only regret about my little contribution to the team's existing packages. Perhaps if I were more active you would be less concerned about maintainability... Sorry if my previous mails on the package were too harsh. Not at all, I think they were straightforward and sincere. :) I respect that. I strongly suspect that we have a number of other packages within the team with the same issues as glmark2. Nevertheless, I do not intend to play the team police game proactively, but only when I stumble upon (obvious) problems in problematic package. I would appreciate if other active team members would join this effort. No worries. Happy new year! :-) Happy New Year indeed. :) -- Regards, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#695849: RFP: glmark2 -- OpenGL (ES) 2.0 benchmark suite
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: pkg-multimedia-maintainers@lists.alioth.debian.org Package name: glmark2 Version: 2012-11 Upstream Author: Linaro Limited URL: https://launchpad.net/glmark2 License: GPL-3,Expat,BSD-3-clause Description: OpenGL (ES) 2.0 benchmark suite glmark2 is a benchmark for OpenGL ES 2.0. It uses only the subset of the OpenGL 2.0 API that is compatible with OpenGL ES 2.0. glmark2 offers a suite of scenes that can be used to measure many aspects of OpenGL (ES) 2.0 performance. The way in which each scene is rendered is configurable through a set of options. There is a repository with almost completed packaging: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/glmark2.git signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#695523: same in smplayer
I've seen similar symptoms in smplayer on some movies so it may be an issue in mplayer... By the way how do you justify severity important? IMHO it should be minor or normal... Regards, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#692974: synfigstudio: some crashes during layer edition
Hi Luc, Thank you for report but could you please kindly report upstream as well? http://sourceforge.net/tracker/?group_id=144022atid=757416 I'm not familiar with graphics editing terms so I couldn't understand how to reproduce the issue. :( Can you reproduce with any file from synfig-examples? If so I would much appreciate step-by-step instructions. Thanks. Regards, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#691067: handbrake-gtk: Handbrake SIGABRTs while scanning DVD titles
So far I can't reproduce the issue. John, could you please advise on status of Preferences -- Advanced -- Use dvdnav Does it make any difference if you change it? Thanks. Cheers, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#691067: handbrake-gtk: Handbrake SIGABRTs while scanning DVD titles
On Sun, 21 Oct 2012 19:13:50 Reinhard Tartler wrote: Unfortunately, we do not provide an handbrake-dbg package, which would be tremendously helpful for identifying where exactly the beast crashes. I think we should do that for the next upload. Everything is ready for that -- I already committed -dbg package some weeks ago when I was troubleshooting a different issue. Regards, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#691067: handbrake-gtk: Handbrake SIGABRTs while scanning DVD titles
Hi John, I had the same problem -- it is because of bug in libdvdread4_4.2.0+20120521-2, see #688574. We declared Breaks with broken libdvdread4 in repository. As for now the problem will go away if you upgrade to libdvdread4-4.2.0+20120521-3 from unstable. Cheers, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#691067: handbrake-gtk: Handbrake SIGABRTs while scanning DVD titles
On Sun, 21 Oct 2012 13:17:47 John Livingston wrote: Thanks, I appreciate the quick reply. Unfortunately updating libdvdread4 to 4.2.0+20120521-3 didn't seem to have any effect; I'm still seeing an abort coming from the same place: OK, then we may have a different issue... Could you please provide a detailed instructions how to reproduce? Also please include list of installed libraries as produced by reportbug or reportbug-ng, see http://www.debian.org/Bugs/Reporting Thank you. Regards, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#691067: handbrake-gtk: Handbrake SIGABRTs while scanning DVD titles
Hi John, You're right, I've missed list of installed libraries in your original report. Please forgive me for my miserably poor attention to details today. Thank you for clear instructions how to reproduce -- I'll see if I can crash handbrake this way. Regards, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Hnadbrake: thank you.
Dear Reinhard, Fabian, Andres and Rogério, Thank you sincerely for bringing handbrake to Debian. Great work, I know how challenging it was. I hope you'll excuse me for committing few improvements without discussing it with you first. It should be OK but please feel free to revert if necessary. Cheers, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Handbrake: thank you.
Hi Fabian, On Fri, 5 Oct 2012 00:00:09 Fabian Greffrath wrote: The versioned Recommends is moot, I have changed it into a versioned Breaks. The rest is fine, thank you very much! Fantastic, thank you for correcting to Breaks. I wasn't sure about it as I thought it could be too strong under some circumstances like when we're not transcoding DVD etc... I'll remember your advise -- thanks for sharing your knowledge. :) Cheers, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: feedback for libdvdcss-pkg
Hi Fabian, On Fri, 21 Sep 2012 17:33:02 Fabian Greffrath wrote: Am 20.09.2012 13:41, schrieb Dmitry Smirnov: due to fears of running afoul of DMCA-style laws etc. That sounds better at least. I re-phrased to libdvdcss is a free software but Debian is not shipping it due to fears of running afoul of DMCA-style laws. Thank you for your suggestion. I would not call it misuse, actually it's quite common practice. Look at both files, you will see that their content is the same. NEWS is just ChangeLog without the VCS noise. You're certainly right -- somehow I misunderstood on first reading, sorry. Indeed upstream NEWS file should be installed as changelog. I updated the package. Thank you. Also I updated your symbol-visibility.patch from upstream trunk as you advised. Thank you for for sharing your ideas. However, this is not our main problem at the moment. ;) True. Moving on. :) All the best, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
feedback for libdvdcss-pkg
Hi Team, I'm looking for feedback for my libdvdcss-pkg package. Do you think the implementation is feasible? Any ideas how it can be improved or it is technically ready for upload? Source package is available from: http://mentors.debian.net/debian/pool/contrib/libd/libdvdcss-pkg/libdvdcss-pkg_1.2.12-1.dsc Package information is there: https://mentors.debian.net/package/libdvdcss-pkg Thank you. Regards, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: feedback for libdvdcss-pkg
Hi Fabian, Thank you for taking time and sharing your thoughts. On Thu, 20 Sep 2012 18:10:26 Fabian Greffrath wrote: I just had a short look, but to me this looks overly complicated. Why do we have to download the sources and build them into a separate package and then install this one - all that mixed with debconf interaction? I tried to explain some of the reasons in README.Debian. First of all I believe everything we install should be under package management control. There are number of libdvdcss2 packages around, notably from deb-multimedia and the idea is not to conflict with them by to take over. Secondly I want package to be upgradable and allow to remove it using normal package management tools. This is the main idea. Debconf is very important to notify user about the implications and to allow to disable package re-building. Why not download the sources, check integrity, compile them and install them - just like flashplugin-nonfree or ttf-mscorefonts-installer do? Because I don't like how they're doing it. :( If I have package I can archive it, bring to another computer with no internet, see what's installed and there, check integrity (debsums) etc. There are many advantages that package management system provides. Apart from this: - Each mention of the word illegal *must* disappear! Could you suggest a better wording please? How to express better why we're not shipping from main repository and why we're asking for user's discression to build the package? - Please no leading commas in debian/control (cosmetic). There are so many opinions on this. I found this notation most useful for revision control. Otherwise you'll need trailing commas that tend to annoy more people for reasons I couldn't understand. I prefer practical over cosmetic. IMHO this not just looks good but also easy to work with. - You have both dh_makeshlibs -V in rules and a symbols file, that's redundant. Of course, thank you. :) Committed. - Why did you modify the changelog? We already worked on libdvdcss packaging and have properly documented that in this file. Sorry, I don't quite follow you... I modify changelog to inject '~local' to version of generated package. This is in order to mark local package as such. If you meant changelog of libdvdcss as a whole (not the version part) I can explain. Historically I forked libdvdcss from deb-multimedia and incorporated it before I've noticed that libdvdcss2 was also packaged here. I wrote to Andres Mejia asking for permission to merge our work but he didn't reply yet. Anyway at the moment it suits to have guest package source embedded as proof of concept. I'm sure eventually we'll de-duplicate. - We should maybe install NEWS as changelog. Could you be more specific please? Do you mean to embed guest package changelog to host package NEWS or to use NEWS to articulate the fact that we're building package on client side? Wouldn't it be unnecessary complicated? - Symbol visibility support is now included upstream, we should include this patch instead. But the patch is there, properly annotated. I'm afraid I don't quite follow you again. Thank you. Cheers, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: feedback for libdvdcss-pkg
On Thu, 20 Sep 2012 20:33:43 Fabian Greffrath wrote: We shouldn't even attempt to touch legal ground. Just tell the users where they can find more information, e.g. http://www.videolan.org/developers/libdvdcss.html, and that they are using it at their own risk. I believe our users deserve to know why they can't have normal libdvdcss. We could quote wikipedia: due to fears of running afoul of DMCA-style laws etc. I'm open to the suggestions of better warnings. You're right, link to upstream page is worth mentioning. Could you be more specific please? Do you mean to embed guest package changelog to host package NEWS or to use NEWS to articulate the fact that we're building package on client side? No, the actual libdvdcss package (is that what you refer to as guest package?) should have dh_installchangelogs install NEWS instead of Changelog. I think that won't be right to do. The idea is build a normal package which complies with our policy. I see no reason to misuse NEWS for changelog. But the patch is there, properly annotated. I'm afraid I don't quite follow you again. I am talking about this one: http://svn.videolan.org/comp.php?repname=libdvdcsscompare[]=%2F@254compa re[]=%2F@255 Thank you for this one, I'll incorporate. That patch of yours was great, thank you. Regards, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#687624: ITP: libdvdcss-pkg -- automated installer for libdvdcss
On Mon, 17 Sep 2012 04:39:49 Stefano Zacchiroli wrote: Indeed. I've in the past sought legal advice on the appropriateness of having an automated installer for libdvdcss in the Debian archive and shared the results with interested members of pkg-multimedia team. The bottom line of that work was that it could be done, but we need to pay attention at the package description. Please check back with me before finalizing that part. My package libdvdcss-pkg has the following in its description: [snip] . libdvdcss is a library for accessing and unscrambling DVDs encrypted with the Content Scramble System (CSS). It is a free software but it may be illegal in some jurisdictions. As well as debconf notice: are you sure you want to build and install libdvdcss? Please be aware that libdvdcss may be illegal in some jurisdictions. . Source files will be downloaded from videolan.org. Please advise if the above warnings are strong enough. ... and of course, as a more general advice, please avoid duplicating efforts and converge on a single implementation, whatever, but please only one :-) Indeed. In this case there wasn't much of duplication because implementations are substantially different. I believe having two proof-of-concept implementations can allow peer review to have a good starting point for decision whichever is better and make possible to actually try the package rather than having long theoretical discussions about how it could be done. I'm sure eventually we will be merging our efforts when Andres Mejia (the author of the other implementation) will find time to reply. Thank you. All the best, Dmitry. signature.asc Description: This is a digitally signed message part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#687624: ITP: libdvdcss-pkg -- automated installer for libdvdcss
On Fri, 14 Sep 2012 22:14:57 Reinhard Tartler wrote: This has been discussed before within the pkg-multimedia team. There is even preliminary work available at http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libdvdcss-installer.git; a=summary. Thank you, I'm aware of that. Some time ago I wrote to Andres Mejia (who made libdvdcss-installer) to discuss but got no reply yet. Our implementations are very different. I'm member of pkg-multimedia but I hesitated to alter libdvdcss-installer without Andres' consent. Team pkg-multimedia, does anyone remember or know why that branch has not been uploaded to debian yet? If I recall correctly, it can't install the package from postinst due to DPKG lock. Probably that's the main reason. Also it is manual, got no debconf prompt to warn user about consequences, can't handle upgrades (and removes) gracefully etc. Cheers, Dmitry. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#665041: New upstream release of etl, synfig and synfigstudio
Thanks Aron, I updated all three packages for new upstream release: http://members.iinet.net.au/~onlyjob/etl_0.04.15-1.dsc http://members.iinet.net.au/~onlyjob/synfig_0.63.05-1.dsc http://members.iinet.net.au/~onlyjob/synfigstudio_0.63.05-1.dsc They should be ready for upload now. Cheers, Dmitry. On Sat, 12 May 2012 13:00:08 Aron Xu wrote: Hi, Thanks for your work on etl, synfig and synfigstudio! I had a quick look at etl and it appears to be almost okay (almost because I didn't look throughout, but its a fair simple package). Upstream of the software has released a minor update of the package, so please package it and send an RFS to me ASAP in time of Wheezy's freeze, which is said to happen in June. -- Regards, Aron Xu ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
