Bug#857552: i965-va-driver: failing to play videos (stops half-way through)

[Nicholas D Steeves]

On Wed, Mar 15, 2017 at 10:50:54AM +0100, Sebastian Ramacher wrote:
> Hi
> 
> On 2017-03-13 07:13:09, Luke Kenneth Casson Leighton wrote:
> > On Sun, Mar 12, 2017 at 7:01 PM, Sebastian Ramacher
> >  wrote:
> > > Control: tags -1 + moreinfo
> > >
> > > On 2017-03-12 13:31:24, lkcl wrote:
> > >> Package: i965-va-driver
> > >> Severity: important
> > >> Tags: upstream
> > >>
> > >> i'm getting a video stopping half-way through with the following errors
> > >> (reported under vlc):
> > > ...
> > >> [7f16c0d62ff8] avcodec decoder: Using Intel i965 driver for Intel(R) 
> > >> Skylake - 1.7.3 for hardware decoding.
> > >> [7f16c0c01978] mkv demux error: Dummy Element at unexpected 
> > >> position... corrupted file?
> > >> [7f16c0c01978] mkv demux error: Dummy element too large or misplaced 
> > >> at 770798513... skipping to next upper element
> > >> [7f16c0c01978] mkv demux error: Dummy Element at unexpected 
> > >> position... corrupted file?
> > >> [7f16c0c01978] mkv demux error: Dummy element too large or misplaced 
> > >> at 772666289... skipping to next upper element
> > >> [7f16c0c01978] mkv demux error: Dummy Element at unexpected 
> > >> position... corrupted file?
> > >> [7f16c0c01978] mkv demux error: Dummy element too large or misplaced 
> > >> at 774009777... skipping to next upper element
> > >> [7f16c0c01978] mkv demux error: This element is outside its known 
> > >> parent... upping level
> > >> [h264 @ 0x7f16c0c3f460] co located POCs unavailable
> > >> [h264 @ 0x7f16c0c30420] co located POCs unavailable
> > >> [h264 @ 0x7f16c0c3f460] co located POCs unavailable
> > >> [h264 @ 0x7f16c0c30420] co located POCs unavailable
> > >> [h264 @ 0x7f16c0c30420] co located POCs unavailable
> > >
> > > Or is that a problem with the file?
>
> > > Does the issue happen with every file or only that one?
> > 
> >  on occasion, several files (not all), but it's repeatable and at the
> > exact same place if it occurs.  so for example let's say that vlc
> > stops with the above error at 1m30s into the file, it's going to
> > happen *exactly* at that point *every* time *specifically* for that
> > file and that file only.
> > 
> > > Does it happen with any
> > > other video player (or when disabling hardware acceleration)?
> > 
> >  hmmm good points, i'll find out.  of course i'll have to set up hw
> > accel for other players... resource-hogging might make playback
> > difficult without hwaccel these are 720p files, quite
> > resource-intensive: just have to see how it goes.

Hi,

MPV can be very quickly set up to test this.  If you've installed MPV from 
testing:

mpv --hwdec=vaapi --vo=opengl

If performance isn't good enough, try

mpv --hwdec=vaapi --vo=vaapi

If you like MPV, you can configure it permanently here: ~/.config/mpv/mpv.conf

Add the lines:

hwdec=vaapi
vo=opengl or vo=vaapi, depending on which worked for you

I noticed something strange in the original bug report:

> > > On 2017-03-12 13:31:24, lkcl wrote:
> > >> Package: i965-va-driver
> > >> Severity: important
> > >> Tags: upstream
> > >> 
> > >> -- System Information:
> > >> Debian Release: 7.4
> > >>   APT prefers testing
> > >>   APT policy: (500, 'testing'), (500, 'stable')
> > >> Architecture: amd64 (x86_64)
> > >> Foreign Architectures: i386

Debian Release: 7.4 with i965-va-driver and kernel from Debian 9?

Luke, I think your base-files needs to be upgraded ;-) Out of
curiousity, does (as root) "echo n | apt-get dist-upgrade" want to
upgrade anything?

Cheers,
Nicholas

signature.asc
Description: PGP signature
___
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] audacious/master: Merge tag 'upstream/3.8.2'

[Nicholas D Steeves]

On Sat, Jun 17, 2017 at 03:33:47PM +, mati75-gu...@users.alioth.debian.org 
wrote:
> New upstream version 3.8.2
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> X-Git-Refname: refs/heads/master
> X-Git-Reftype: branch
> X-Git-Oldrev: 260cd9136b228abe35071ecc9fc0406f5d277cea
> X-Git-Newrev: b777f39ab38dc3695ad62b47d7ae48c2a2957590
> 
> The following commit has been merged in the master branch:
> commit de9fb632deeb72921c3c252b444be1f940822cb5
> Merge: 260cd9136b228abe35071ecc9fc0406f5d277cea 
> e71d3c04c4dafb4c9c0cb4f8e46180e4f679ed0b
> Author: Mateusz ??ukasik 
> Date:   Sat Jun 17 17:33:37 2017 +0200
> 
> Merge tag 'upstream/3.8.2'
> 
> Upstream version 3.8.2

Could we please add Qt-enabled variant build to the source package
similarly to how other packages build both a GUI and a -nox version?
Or maybe how src:transmission has both a Qt and GTK frontend?
I exclusively use the Qt front-end...

Other than that, if there's a way to disable the GTK GUI for the QT
variant I think users of LXQt might appreciate it.  Unfortunately I
won't have time to work on this for at least two months, but if anyone
knows of a example package that I could study, then I'd be happy to do
what I can when I have more free time.

Finally, upstream says that they're going to use the QT variant as the
basis for the OS X port, so I expect it to mature in the next two
years :-)

Sincerely,
Nicholas


signature.asc
Description: Digital signature
___
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#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

Hi John,

On Wed, Dec 06, 2017 at 05:08:56PM -0500, John Lindgren wrote:
> 
> Per Debian policy 2.3:
> 
> "Every package must be accompanied by a verbatim copy of its copyright
> information and distribution license in the file 
> /usr/share/doc/package/copyright
> (see Copyright information for further details)."
> 
> The file /usr/share/doc/audacious/copyright shipped in the Debian package
> is out of date and does not match the current Audacious license (GPL3 vs.
> BSD 2-clause).
> 
> Worse, the Debian package patches out[1] the upstream license file which
> is normally installed under /usr/share/audacious/COPYING and visible in
> the "About" window when running Audacious.
> 
> You are currently distributing Audacious in violation both of our license
> and of Debian's own policy.  Please include the original upstream license,
> verbatim, in the Debian package, or stop distributing Audacious.
> 
> Thank you,
> 
> John Lindgren
> Audacious maintainer

I'm not the maintainer of Audacious' Debian package, but I am part of
the Multimedia team, so I took a look at the Debian and upstream
source, because I agree that license problems must be fixed asap.

On this topic, would you please update contrib/audacious.appdata.xml
to reflect the current Audacious license (GPL3)?  It claims the
project_license is BSD-2-Clause.

http://redmine.audacious-media-player.org/projects/audacious/repository/revisions/master/changes/contrib/audacious.appdata.xml

And when I looked up upstream audacious/COPYING here:
http://redmine.audacious-media-player.org/projects/audacious/repository/revisions/master/changes/COPYING

I found this, which also looks like BSD-2-Clause:

LICENSE

Copyright © 2001-2017 Audacious developers and others

(A list of the copyright holders is provided in the AUTHORS file.)

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice,
   this list of conditions, and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions, and the following disclaimer in the
   documentation provided with the distribution.

This software is provided “as is” and without any warranty, express or
implied.  In no event shall the authors be liable for any damages arising
from the use of this software.
--
However, shouldn't it say the following if Audacious' project license
is GPL-3+ (drop the "any later version" clause for GPL-3 only) ?:

Audacious, an Advanced Audio Player
Copyright (C) 2001-2017 Audacious developers and others

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see .
--

Also, I found BSD-2-clause here: src/libaudcore/hook.cc,
src/libaudcore/hook.h, src/libaudcore/output.cc, et al.

Conversely, what I found in debian/copyright was a project license of
GPL-3, with notable exceptions. eg: are really translations GPL-1+?
Because the project license seems to be BSD-2-Clause, and the
translations have "This file is distributed under the same license as
the Audacious package" I wonder if they're actually BSD-2-Clause.
Would you please provide a citation for the upstream project's
relicensing to GPL-3?

Finally, from what I understand about combining licenses I think the
BSD-2-clause project license (please provide evidence that this isn't
the case), the src/libguess/* BSD-3-clause and the GPL bits can all be
used to produce a GPL-3 binary, so long as the BSD copyright notices
are preserved.

To my eyes it looks like the upstream project license needs to be
clarified and disambiguated, debian/copyright needs work, and finally
that deduplication patch can be dropped.

I'd be happy to take care of the Debian side of things over the
weekend.

Thank you,
Nicholas


signature.asc
Description: PGP signature
___
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#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

Dear Debian Legal Team,

I've CCed you for my reply to this bug, because I don't have the
experience to be able to tell if Debian implicitly relicensed
Audacious as GPL-3 from 2012-2016, how potentially falling out of
BSD-2-clause license compliance might have affected this, and also how
this should be resolved.  The Debian packaging is GPL-2+, so it's
possible to move to copyright-format/1.0 if that would simplify
things.  Also, please reply to point 2. OTTO "ancient plugins...under
different licenses.  I assume audacious-plugins will also need a
copyright review.  Please CC John and I, Bug #883731, and
debian-legal as appropriate.


Hi John,

On Thu, Dec 07, 2017 at 05:15:53PM -0500, John Lindgren wrote:
> Hi Nicholas,
> 
> > On this topic, would you please update contrib/audacious.appdata.xml
> > to reflect the current Audacious license (GPL3)? It claims the
> > project_license is BSD-2-Clause.
> 
> Sorry if my initial email was unclear.  The current Audacious license *is*
> BSD 2-clause, with some exceptions:

Oh, now I see.  Sorry I wasn't familiar with Audacious' upstream
relicensing, and thank you very much for confirming for the files I
asked about.

> 1. The embedded copy of libguess (which is an external project) is under
>a BSD 3-clause license, with a separate copyright.  I believe this is
>not a problem so long as the libguess license is also included with
>any distribution.
> 2. Some of the more ancient plugins are under different licenses, including
>GPLv2+ and GPLv3.  When we relicensed the main parts of Audacious to BSD
>around 2012, we thought it impractical to contact all of the original
>plugin authors since some of them go back to XMMS days (20 years ago now).
>The plugins are compiled as separate binaries, and Debian has them in a
>separate package (audacious-plugins).
> 
> Our upstream COPYING file makes note of these exceptions, which is one
> reason why it's important for it to be included verbatim, and not replaced
> with generic BSD 2-clause text as it is in the current Debian package.

Both BSD 3-clause and BSD 2-clause allow relicensing as GPL, thus so
long as the licensing terms are complied with correctly BSD code can
perpetually and unidirectionally flow to GPL projects.  So from what I
can tell it's 100% ok for the Debian package (both src and bin) to be
GPL-3 from 2012-to-2016, and both the Debian source packages and
binaries from this time period might actually be implicitly relicensed
as GPL-3.  If so, that's history that can't be changed.  Also, I'm not
sure what debian-legal and ftpmaster's view of #2 will be in light of
the relicensing (and possible implied relicensing back to GPL-3).

On 2016-04-06 06:55:52
(commit@124bf3bdccdac9d0eb78ce65b53c9a4ba128e052)
use-system-licenses.patch might have made Debian's implicit
relicensing invalid, not because of the deduplication patch per-se,
but because /usr/share/common-licenses/BSD is a 3-clause and not a
2-clause one like Audacious uses.  It's the same style, but is a
different license altogether...and yeah, I think one can go
BSD-2-clause to BSD-3-clause to GPL-3, but only if the original
BSD-2-clause bits aren't stripped.  I'm also unsure whether the patch
that changes the user-visible bits and the out-of-date
debian/copyright outweigh the 2-clause license that wasn't stripped
from the headers of various files.  eg: not implicitly relicensed, and
just out of date copyright plus non-compliance with 2-clause BSD.

> Regarding the plugins, I don't know the state of debian/copyright in the
> audacious-plugins package, but my main concern here is that the one in
> audacious is correct.
>
> > Conversely, what I found in debian/copyright was a project license of
> > GPL-3, with notable exceptions. eg: are really translations GPL-1+?
> 
> As I said, debian/copyright is out-of-date.  We relicensed the project
> from GPLv3 to BSD 2-clause back in 2012.  Possibly we didn't make an
> obvious enough announcement back then for Debian to take notice.

I haven't looked at audacious-plugins yet either.  Re: "is correct", I
agree, and I'm hoping the fix will be to simply synchronise with
upstream Audacious' BSD 2-clause.

> Translations are under the same license as the rest of Audacious.

Thank you for the confirmation.

> > To my eyes it looks like the upstream project license needs to be
> > clarified and disambiguated, debian/copyright needs work, and finally
> > that deduplication patch can be dropped.
> 
> Let me know if you think there are still clarifications needed upstream
> given the information I've provided here.  I'd be happy to adjust things
> as necessary.

Well, since the main Audacious project is in fact 2-clause-BSD this
is much clearer now!  Thanks again for the help.  I hope to work on
this Sunday, or after we hear back from debian-legal.

Sincerely,
Nicholas


signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list

Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

Hi Francesco, John, and everybody else reading this,

On Fri, Dec 08, 2017 at 11:10:40AM +0100, Francesco Poli wrote:
> On Thu, 7 Dec 2017 22:39:41 -0500 Nicholas D Steeves wrote:
[...]
> Failing to retain the license text in the package distribution is in
> fact lack of compliance with the 2-clause BSD license, I would say...
> 
> > and also how
> > this should be resolved.  The Debian packaging is GPL-2+, so it's
> > possible to move to copyright-format/1.0 if that would simplify
> > things.
> 
> I personally think that the first thing to do is an accurate copyright
> and licensing status review of the audacious package, so that the
> debian/copyright file may be fixed to reflect the actual current state
> of affairs.
> The Audacious upstream developers may be willing to help, by clarifying
> any doubts upon request.
> This may be a perfect opportunity to switch to the [machine readable]
> format.
> 
> [machine readable]: 
> <https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/>

Thanks for the clarification.  I guess I've dropped the offending
patch in git and am currently working on a copyright-format/1.0
debian/copyright.

Will I also need to provide formal copies in debian/COPYING.emails or
would a README.copyright or similar pointing to the bug report
suffice?  In particular I'm concerned about lines like this from
d/copyright:

"po/uk.po" is © 2005 Mykola Lynnyk and is distributed under the terms of the
 GPL.

Where the new po/uk.po is GPL-incompatible 2-clause BSD:

# Ukrainian translation for Audacious
# Copyright (C) Audacious translators
# This file is distributed under the same license as the Audacious package.
#
# Translators:
# Dennis , 2014
# Eugene Paskevich , 2015-2016
# Kostyantyn Fedenko , 2011
# Oleg , 2012
# NaiLi (aka jamesjames) Rootaerc , 2012
# NaiLi (aka jamesjames) Rootaerc , 2012
# Oleg , 2012
# Rax Garfield , 2012
# Rax Garfield (http://biokillaz.com/), 2012
# Rax Garfield , 2012-2013
# Rustam Tsurik , 2013
# Rustam Tsurik , 2013
# Oleg , 2012
# Taras Shevchenko, 2017
# Yaroslav Yenkala , 2016
msgid ""
msgstr ""
"Project-Id-Version: Audacious\n"
"Report-Msgid-Bugs-To: http://redmine.audacious-media-player.org/\n";
"POT-Creation-Date: 2017-08-19 19:12+0200\n"
"PO-Revision-Date: 2017-08-06 05:54+\n"
"Last-Translator: Taras Shevchenko\n"

John, what happened here with Mykola Lynnyk's 2005 GPL copyright?

> > Also, please reply to point 2. OTTO "ancient plugins...under
> > different licenses.  I assume audacious-plugins will also need a
> > copyright review.
> 
> Probably.

I took a cursory glance and it seems to be in better shape than the
main audacious package but I'll take a look later.

> > Please CC John and I, Bug #883731, and
> > debian-legal as appropriate.
> 
> Done.
> 
> I hope my comments may help.
> 
> Bye and thanks to the Debian Multimedia Maintainers for the time they
> spend in maintaining a number of great Debian packages, and to the
> Audacious upstream developers for the time they spend in
> developing/maintaining that very nice audio player (that I personally
> use everyday!). Thank you!

Thank you Francesco, your comments do help.  I'm also a big fan of
Audacious and use it all the time. (thank you John!)  Oh, and if
everything goes according to plan we'll have a qt variant again
sometime in 2018 (one src:package will build the gtk variant, cleanup,
build the qt variant, and then package the two variants separately).

Cheers,
Nicholas


signature.asc
Description: PGP signature
___
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#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

On Fri, Dec 08, 2017 at 10:36:49AM -0500, John Lindgren wrote:
> Nicholas D Steeves wrote:
> 
> > Both BSD 3-clause and BSD 2-clause allow relicensing as GPL, thus so
> > long as the licensing terms are complied with correctly BSD code can
> > perpetually and unidirectionally flow to GPL projects.
> 
> Yes, I agree.  It's perfectly okay for the Debian package(s) to be
> distributed as GPL, *as long as* the original BSD license text is still
> retained.
> 
> > I'm also unsure whether the patch
> > that changes the user-visible bits and the out-of-date
> > debian/copyright outweigh the 2-clause license that wasn't stripped
> > from the headers of various files.
> 
> Speaking for myself as upstream project lead, I'm not worried about
> the legal status of already-built packages, but I would prefer that the
> upstream (BSD 2-clause) license remain user-visible in future Debian
> builds.  The simplest way to achieve this would be to remove
> use-system-licenses.patch and let the GUI again display
> /usr/share/audacious/COPYING as the upstream version does.

This will be easier to do.

> Alternatively, debian/copyright could be updated to include the full
> text of the upstream license, plus any Debian-specific bits (packaging
> copyrights, etc.), and the patch could be updated so that the GUI
> displays the installed version of that file instead (I think that would
> be /usr/share/doc/audacious/copyright?)

Thank you for your blessing on doing it this way.  If Debian was/is
relicensing as GPL in a non-reversible way then this the way it
would/might have to be done.

> Francesco Poli wrote:
> 
> > The Audacious upstream developers may be willing to help, by clarifying
> > any doubts upon request.
> 
> Yes, for sure.

Please see my question about a missing copyright holder; I paused my
review at this point, so there might be other examples.

> > If that is deemed to be needed or useful, it could be feasible to also
> > fix the debian/copyright file for audacious version 3.7.2 in a Debian
> > stable update (and possibly also address the same issue for
> > oldstable)... On the other hand, this extra effort could perhaps be
> > considered not worth doing.
> 
> For my part, I'm not worried about the stable+oldstable packages being
> fixed, only that the problem is resolved in a new unstable upload going
> forward.  I think that the other upstream developers would agree.

Whew, thank you, that makes things easier for everyone :-)

> Thank you both for the prompt reply and good discussion!

You're welcome!  Thank you for reaching out.

Sincerely,
Nicholas


signature.asc
Description: PGP signature
___
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#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

On Mon, Dec 11, 2017 at 12:23:47AM +0100, Francesco Poli wrote:
> On Sun, 10 Dec 2017 18:12:39 -0500 Nicholas D Steeves wrote:
> 
> [...]
> > GPL-incompatible 2-clause BSD
> [...]
> 
> A nitpick: the 2-clause BSD license is not GPL-incompatible (it's
> indeed compatible with the GNU GPL).
> It's just a distinct license with different (and much simpler)
> wording...

Good point.  I ought to have phrased that differently ;-) What I mean
is that a GPL piece cannot become a BSD piece without explicit
relicensing by all copyright holders.


signature.asc
Description: PGP signature
___
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#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

Hi Ian, Francesco, John, and everyone else reading this,

On Mon, Dec 11, 2017 at 12:28:43AM -0500, John Lindgren wrote:
> On 12/10/2017 06:12 PM, Nicholas D Steeves wrote:
> > In particular I'm concerned about lines like this from
> > d/copyright:
> > 
> > "po/uk.po" is © 2005 Mykola Lynnyk and is distributed under the terms of the
> >  GPL.
> > 
> > Where the new po/uk.po is GPL-incompatible 2-clause BSD:
> 
> The line "Copyright (C) 2005 Mykola Lynnyk <...>" appears to have been
> lost accidentally in commit 1a013156d209b, when we switched over to
> Transifex.  I'll see about restoring it.
> 
> As far as our Git history goes back (to October 2005), uk.po had no
> license declaration and was assumed to be under the same license as the
> source files it translated (which at the time was GPLv2+). At the time
> of the BSD relicense, we took the liberty of assuming that such
> translations would automatically switch to the new license along with
> the source files they translated.  No one (to my knowledge) has
> contacted us in the five years since to clarify that their translations
> were intended to be forever GPL-only, but I suppose that to take a more
> cautious approach, Debian could still distribute the package as GPL in
> total.

For Debian Legal Team: With respect to the translations, I now suspect
they can probably be transitioned to BSD without issue, because
copyright is also assigned to the Audacious Translators.  eg, in the
last GPL-2+ release 3.2.4:
Copyright (C) Audacious translators

Would you please confirm?  It would be nice to be able to simplify the
issue of relicensing for the translations :-)  Also, would you please
confirm or deny the necessity of the work outlined in the second half
of this email?


John, I removed the offending patch in git for the user-visible
license provided by the Audacious GUI.  Then I went ahead and did a
historical relicensing review, in spite of the potential for other
missing copyright holders due to the Transifex switch.  I am a bit
concerned about what looks to be a politic of "silence is consent" wrt
relicensing, and hope that I am wrong, or that I was sloppy in my
review.  Was the discussing conducted informally off the record?

By the way, I definitely support every author's right to choose a
preferred license, so I'm not troubled with a transition to BSD
licensing ;-) This is one of the reasons the FSF demands copyright
assignment for their projects...they want to be able to relicense at
any point in the future without having to contact and document consent
from all contributors.

Would you please take a look at the following (Ian's reply) for an
example of how to provide a record of all copyright holder's consent?
tldr; documented confirmation (eg: via copies of emails or a download
of a bug report/issue/forum thread) for all contributors who did not
assign copyright to the Audacious Team in the headers of the files
they contributed to.  I would be happy to generate such a file[s] if
you can point me in the right direction[s].

On Mon, Dec 11, 2017 at 03:03:09PM +, Ian Jackson wrote:
> Nicholas D Steeves writes ("Re: Bug#883731: audacious: Debian packaging has 
> incorrect license"):
> > Will I also need to provide formal copies in debian/COPYING.emails or
> > would a README.copyright or similar pointing to the bug report
> > suffice?  In particular I'm concerned about lines like this from
> > d/copyright:
> 
> Please put all the necessary information in the source package.
> 
> COPYING.emails is only one filename you might choose to use.  If you
> want to download multiple pages, or something, you can put them in
> separate files.  It's probably a good idea to download them with w3m
> -dump or something.  That produces a human-readable file which doesn't
> depend on any external HTML assets.
> 
> This is much better than simply urls, because (sadly), urls often rot.
> The lifetime of the contents in debian/ is controlled by Debian and
> often exceeds, by large factors, the lifetime of upstream source
> repositories, bug trackers, etc.
> 
> It would be a best praqctice to record the contents _and also_ the url
> you got it from, and the date you downloaded it.  That way the
> information you give is verifiable while the url is still active; and
> if the url rots, the information (attribution, etc.) is not lost.
> 
> So in summary, I would 
>   w3m -dump https://bugtracker/whatever > debian/COPYING.issue4391.txt
> and make an overview file (COPYING.emails maybe) referring to
> these other files.

Specific commits I couldn't find documented consent for, and which
didn't have have copyright assigned to the Audacious Team i

joining the team

[Nicholas D Steeves]

Dear Debian Multimedia team,

In the last year I've spent time practising formal backports and
updating packages, and since sometime this last fall I've been doing
uploads to debian-mentors.  Currently I think the only packages in the
Debian archive with my name on them are the exfat-fuse and and
exfat-utils backports to Jessie.

I'd like to join the Debian Multimedia team as my next step in
becoming more involved with Debian development.  My alioth account
name is sten-guest, my irc nick on oftc and freenode is nick[0].  My
first choice of usernames is sten, because it's what I've been using
since my undergrad.  Also, that's what I used when I was doing
packaging work for CRUX Linux from 2004 to 2006.  My second choice
would be either nick0 or nsteeves.  I am subscribed to backports,
debian-mentors, pkg-multimedia-maintainers, and
pkg-multimedia-commits.

My bug-managing experience is mostly with btrfs-tools.  Here is a
updated package I uploaded to debian mentors today:

http://mentors.debian.net/package/audacious

Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/a/audacious/audacious_3.7.2-1.1.dsc

I'm also working on closing bug #780081 (btrfs-tools), but I'm not
sure how the bug tracker and package rename interact.  I'm providing
it for review here, because I imagine that being able to properly
rename a package is a necessary prerequisite for joining a team:

http://mentors.debian.net/package/btrfs-progs

Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.4.1-1.1.dsc

Kind regards,
Nicholas

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

Hi,

I'm a member of the team, and I'd like to maintain backports of these
packages for Jessie.  In particular I'm looking forward to 3.7.2 which
updates the last.fm submission API to one that actually works ;-)  I
thought it was more appropriate to post here first, but please let me
know if you prefer an official RFS bug.

Would ctaylor, bilalakhtar, Cyril Lavier, or someone else please
sponsor this upload?

Kind regards,
Nicholas

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

ack, forgot the links:

http://mentors.debian.net/package/audacious

  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/a/audacious/audacious_3.6.2-2~bpo8+1.dsc


http://mentors.debian.net/package/audacious-plugins

  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/a/audacious-plugins/audacious-plugins_3.6.2-2~bpo8+1.dsc

On 7 April 2016 at 20:26, Nicholas D Steeves  wrote:
> Hi,
>
> I'm a member of the team, and I'd like to maintain backports of these
> packages for Jessie.  In particular I'm looking forward to 3.7.2 which
> updates the last.fm submission API to one that actually works ;-)  I
> thought it was more appropriate to post here first, but please let me
> know if you prefer an official RFS bug.
>
> Would ctaylor, bilalakhtar, Cyril Lavier, or someone else please
> sponsor this upload?
>
> Kind regards,
> Nicholas

___
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: joining the team

[Nicholas D Steeves]

Thank you for the help and advice!

Nicholas

___
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: Request for jessie backport of mpv

[Nicholas D Steeves]

Hi Chris,

On 18 April 2016 at 17:10, Chris Metzner  wrote:
> Hello,
>
> Thank you for taking time to read this, I know you are very busy with other
> matters. The version of mpv on jessie is 0.6.2-2 and this is ancient. Many
> new features are out in a newer versions and I believe this would be of
> benefit to provide the most stable and newest version of this great player.

I've been personally using such a backport.  I've run into
vaapi-related regressions, and was disappointed b2sb (binaural filter
for headphones) support broke.  The vaapi problems might be related to
running new code on an ancient graphics subsystem ;-)  Also, if I
remember correctly the config file format also changed in various
ways, and the audio filter syntax changed.

I'd be happy to do it, and would need an sponsor for the upload, but
it's definitely not something I want to maintain.  If you need
packages for x86 or amd64 I'd be happy to upload time some place so
you can give them a try.  If debian-mentors can compile for arm, ppc,
etc, I guess that might be an option too...

Kind regards,
Nicholas

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

team member RFS upload of audacious-3.7.2-2~bpo8+1

[Nicholas D Steeves]

Hi,

I am a member of the team, but not a full DD, and I'd like to maintain
a backport of audacious to jessie.  No one has submitted a bug for
obsolete and broken Last.FM (and possibly Libre.FM) submission in
version 3.5-2 or 3.6.2-2, but I have confirmed that audacious has
updated the submission API for 3.7.2, and that it works flawlessly.  I
have not filed an RFS bug.

To access further information about these packages, please visit the
following URLs:

  http://mentors.debian.net/package/audacious
  http://mentors.debian.net/package/audacious-plugins

Alternatively, one can download the packages with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/a/audacious/audacious_3.7.2-1~bpo8+1.dsc
  dget -x 
http://mentors.debian.net/debian/pool/main/a/audacious-plugins/audacious-plugins_3.7.2-2~bpo8+1.dsc

Cheers,
Nicholas

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

Hi Mattia,

On 28 April 2016 at 06:19, Mattia Rizzolo  wrote:
> On Thu, Apr 07, 2016 at 08:26:28PM -0400, Nicholas D Steeves wrote:
>> I'm a member of the team, and I'd like to maintain backports of these
>> packages for Jessie.
>
> ok.
>
>> I
>> thought it was more appropriate to post here first, but please let me
>> know if you prefer an official RFS bug.
>
>> Would ctaylor, bilalakhtar, Cyril Lavier, or someone else please
>> sponsor this upload?
>
> I'll happilly do so, but I'd really prefer to do so over git, so please
> do your backporting on the git repositories of those 2 things, either in
> a jessie-backports branch, or just with a tag (I mean, I don't really
> see the point in such jessie-backports branches, I prefer to do my
> backports just with tags without them being on any branch, but this can
> be a bit hard to grasp if you are not used to use git, so do it as you
> prefer).
>
> Please poke me (as in: put my email in the To/Cc, so it gets in folder
> where i actually pay real attention to mails) once you are done, and
> I'll look at what you did and build/sign/upload :)

I've just pushed the trivial changelog changes for audacious and
audacious-plugins.  I've tested that they work, and uploaded the
packages to mentors as proof.

I made my changes, git add, git commit, git tag.  I wasn't sure which
convention to use for backports, so I based my tag on the debian
version.  It's at the top of the list for git tag -l.  I also wasn't
sure if I should if I should reset the tag back to the debian/3.7.2-1
and debian/3.7.2-2.  Please indicate how I can do a better job next
time.

Thank you,
Nicholas

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

On 29 April 2016 at 18:02, Mattia Rizzolo  wrote:
> On Fri, Apr 29, 2016 at 01:07:20PM -0400, Nicholas D Steeves wrote:
>> I made my changes, git add, git commit, git tag.  I wasn't sure which
>> convention to use for backports, so I based my tag on the debian
>> version.  It's at the top of the list for git tag -l.  I also wasn't
>> sure if I should if I should reset the tag back to the debian/3.7.2-1
>> and debian/3.7.2-2.  Please indicate how I can do a better job next
>> time.
>
>
> let's do it right this time too :), as you want to *maintain* the
> backport, you ought to learn it.

I agree! :-)

> I see you pushed to the master branch.  This is wrong straigh away.
> The master branch is used to do the main development of the package, and
> targets either unstable or experimental.  If you want to keep the
> backports stuff in a branch (as I think you could very well do), do it
> in a jessie-backports branch, not master.

But you said you preferred it to be pushed with just a tag!

On 28 April 2016 at 06:19, Mattia Rizzolo  wrote:
> I'll happilly do so, but I'd really prefer to do so over git, so please
> do your backporting on the git repositories of those 2 things, either in
> a jessie-backports branch, or just with a tag (I mean, I don't really
> see the point in such jessie-backports branches, I prefer to do my
> backports just with tags without them being on any branch, but this can
> be a bit hard to grasp if you are not used to use git, so do it as you
> prefer).

So you wanted me to detach from the master branch with: git checkout
master^ before making changes?
And when the next version of the package hits stable I'd git checkout
master && git checkout master^ ?

>
> Now, the question about what to do with that commit arises.  If this was
> a repository of mine I'd have just force-pushed it, but I won't do it
> here unless somebody says me to do it.
>

I'd be happy to take responsibility for my mistake, especially since
I'd like to learn to to fix it.  According to the following guide I
should be able to do with with:
https://www.atlassian.com/git/tutorials/undoing-changes/git-checkout

First, I'd delete the tags I introduced, then:

for audacious:
git checkout 79c8a90
git status
git add debian/changelog (probably necessary)
git commit  -> with this as the message, if necessary: upload to
unstable (or would I say revert to 79c8a90?)
git push

for audacious-plugins:
git checkout 985c3d8
git status
git add debian/changelog (probably necessary)
git commit -> with this as the message, if necessary: Finalize
changelog (or would I say revert to 985c3d8?)
git push

What tag would you like me to use for the backport?

Thank you for your patience,
and sorry for the potential hassle!

Nicholas

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

On 29 April 2016 at 22:42, Mattia Rizzolo  wrote:
> On Fri, Apr 29, 2016 at 07:55:29PM -0400, Nicholas D Steeves wrote:
>> But you said you preferred it to be pushed with just a tag!
>
> yes, but not in master!
> A tag is always wanted in any case, with "just a tag" I was meaning a
> tag that is not in any branch, try having a look at some package of mine
> with a backport (like pbuilder, diffoscope, s3fs-fuse,...), you'll see
> that there is a bpo tag, but the commit referenced by that tag is not in
> any branch.
> But I can easily see how this can be confusing/hard, so a
> jessie-backports tag is just a very good way to deal with it! :)
>
>> So you wanted me to detach from the master branch with: git checkout
>> master^ before making changes?
>
> git checkout master^ would bring you to whatever is right before master
> (what's so special about the second-last commit on master?)
> You should make sure that you are on the commit describing the uploaded
> package, which not always is what is pointed by master.
> So probably here I'd say that you should do `git checkout debian/3.7.2-1`
> (or whatever version you are backporting) before doing anything
>
>> And when the next version of the package hits stable I'd git checkout
>> master && git checkout master^ ?
>
> erm?  Can't understand what you mean here (1/ "hits stable" is very much
> something not real 2/ `git checkout master && git checkout master^`
> looks very fishy, what would do that?)

This is question I've been trying to answer:  How do you detach from
HEAD?  I read a possibly obsolete article that said to add the caret
symbol at the end of the branch do do this.  Is this not the case?  Is
it rather "git checkout master^0"?  And in this case, isn't it more
appropriate to to do "git checkout --detach debian/3.7.2-1".

As for "hits stable" I'm sorry, that was a thoughtless and automatic
typo.  I meant "hits testing", as in, when a package without RC bugs
automatically migrates.  So in this case, to prepare for a
not-in-a-branch commit would I "git checkout --detach
debian/version-in-testing"?

>> What tag would you like me to use for the backport?
>
> the tag should be 'debian/$version', so like 'debian/3.7.2-1_bpo8+1'.
> `gbp buildpackage` would create it right.

Oh, thank you, I love helper scripts.  For extra safety, is the
following appropriate?: gbp buildpackage --git-debian-branch=''

I'm going to write a "contributing backports with git" article for the
wiki once I get this figured out, in the hopes that it will prevent
future situations like this one from emerging.

Best regards,
Nicholas

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

Hi Mateusz,

On 2 May 2016 at 03:34, Mateusz Łukasik  wrote:
> On 02.05.2016 02:06 +0200, Nicholas D Steeves wrote:
>>
>> This is question I've been trying to answer:  How do you detach from
>> HEAD?  I read a possibly obsolete article that said to add the caret
>> symbol at the end of the branch do do this.  Is this not the case?  Is
>> it rather "git checkout master^0"?  And in this case, isn't it more
>> appropriate to to do "git checkout --detach debian/3.7.2-1".
>>
>
>
> I will fix that.
>
> The best way is creating jessie branch and prepare backport there.

Thank you very much for fixing the mess I made.  To maintain this
backport, is the following sequence of commands appropriate?:

git checkout --detach --rebase debian/version-revision
(make changes)
git-buildpackage --git-tag
git status
git add (changed files, usually just debian/changelog)
git push remotes/origin/jessie-backports
--

Sincerely,
Nicholas

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

Hi Mattia,

On 3 May 2016 at 09:56, Mattia Rizzolo  wrote:
> On Mon, May 02, 2016 at 08:50:55AM +, Mattia Rizzolo wrote:
>> I'll go ahead and built&upload later.
>
> So, I've now actually tried to build them.
> src:audacious built just fine, but audacious-plugins failed:
>
> Entering directory sndio-ng.
> make[5]: Entering directory '/build/audacious-plugins-3.7.2/src/sndio-ng'
> make[6]: Entering directory '/build/audacious-plugins-3.7.2/src/sndio-ng'
> make[7]: Entering directory '/build/audacious-plugins-3.7.2/src/sndio-ng'
> make[7]: Leaving directory '/build/audacious-plugins-3.7.2/src/sndio-ng'
> Successfully generated dependencies.
> make[6]: Leaving directory '/build/audacious-plugins-3.7.2/src/sndio-ng'
> make[6]: Entering directory '/build/audacious-plugins-3.7.2/src/sndio-ng'
> In file included from /usr/include/libroar/libroar.h:153:0,
>  from /usr/include/roaraudio.h:133,
>  from /usr/include/libroarsndio/libroarsndio.h:52,
>  from /usr/include/sndio.h:9,
>  from sndio.cc:34:
> /usr/include/libroar/services.h:128:8: error: expected unqualified-id before 
> 'new'
>   int (*new)(const struct roar_audio_info * info, int dir, int parent, int 
> mixer);
> ^
> /usr/include/libroar/services.h:128:8: error: expected ')' before 'new'
> sndio.cc: In member function 'virtual bool SndioPlugin::open_audio(int, int, 
> int)':
> sndio.cc:187:64: error: 'SIO_DEVANY' was not declared in this scope
>  const char * device2 = device[0] ? (const char *) device : SIO_DEVANY;
> ^
> Failed to compile sndio.cc (plugin)!
> ../../buildsys.mk:413: recipe for target 'sndio.plugin.o' failed
> make[6]: *** [sndio.plugin.o] Error 1
> make[6]: Leaving directory '/build/audacious-plugins-3.7.2/src/sndio-ng'
> ../../buildsys.mk:116: recipe for target 'all' failed
> make[5]: *** [all] Error 2
> make[5]: Leaving directory '/build/audacious-plugins-3.7.2/src/sndio-ng'
> ../buildsys.mk:123: recipe for target 'sndio-ng' failed
> make[4]: *** [sndio-ng] Error 2
> make[4]: Leaving directory '/build/audacious-plugins-3.7.2/src'
> ../buildsys.mk:116: recipe for target 'all' failed
> make[3]: *** [all] Error 2
> make[3]: Leaving directory '/build/audacious-plugins-3.7.2/src'
> buildsys.mk:123: recipe for target 'src' failed
> make[2]: *** [src] Error 2
> make[2]: Leaving directory '/build/audacious-plugins-3.7.2'
> buildsys.mk:116: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory '/build/audacious-plugins-3.7.2'
> dh_auto_build: make -j1 returned exit code 2
> debian/rules:20: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
>
> So, I uploaded nothing.
>
> Nicholas: you still haven't confirmed that you are subscribed to the
> debian-backports@ ML, where eventual backport-related bugs should end
> up.
> Also, please check that build failure I got.

Sorry for the delay.  Oh my, it seems I wasn't subscribed to
debian-backports@!  I am now :-)

As for the build failure:

/usr/include/roaraudio.h is found in libroar-dev.  Libroar-dev is not
a build dependency of either a audacious or audacious-plugins;
likewise, libroar2 is not a runtime dependency.  Have you added extra
packages to your clean chroot?

A formal backport in a clean chroot+local repository so
audacious-plugins can build against the backported audacious worked
for me.

https://mentors.debian.net/package/audacious-plugins
https://mentors.debian.net/package/audacious

Kind regards,
Nicholas

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

On 4 May 2016 at 23:32, Nicholas D Steeves  wrote:
> Sorry for the delay.  Oh my, it seems I wasn't subscribed to
> debian-backports@!  I am now :-)

Correction: I believe been subscribed for quite some time but haven't
received any mail since April 28th.  I've resubscribed, just in case.

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

On 6 May 2016 at 05:51, Mattia Rizzolo  wrote:
> On Wed, May 04, 2016 at 11:32:20PM -0400, Nicholas D Steeves wrote:
>> /usr/include/roaraudio.h is found in libroar-dev.  Libroar-dev is not
>> a build dependency of either a audacious or audacious-plugins;
>> likewise, libroar2 is not a runtime dependency.  Have you added extra
>> packages to your clean chroot?
>
> definitely not.
>
>> A formal backport in a clean chroot+local repository so
>> audacious-plugins can build against the backported audacious worked
>> for me.
>
> I tried now the very packages you uploaded there, and failed the same.
> Some things:
>
> in sid there is a *real* libsndio-dev, but that package is not in
> jessie.  Instead, in jessie the only thing providing that package is
> libroar-dev.
>
> Which rises the question: do *you* a clean chroot?
> My chroot is a simple jessie, + the jessie-bpo and the local repo added,
> and the only things installed from outside jessie are the binaries built
> by the locally backported audacious.

Oh my, this is embarrassing!  As I mentioned before my chroot uses the
following:
OTHERMIRROR='deb http://security.debian.org/ jessie/updates main | deb
http://debian.ec.as6453.net/debian/ jessie-backports main | deb
[trusted=yes] file:/usr/src/repo/amd64 ./'

It seems I backported libsndio in a fugue state Feb 9th!  I found a
libsndio-dev_1.0.1-2~bpo8+1_amd64.deb in my local repo.  I can't find
an email notification from debian-mentors saying I uploaded it, so my
conclusion is that this was leftover cruft from when I just starting
out.  You have my sincerest apologies.  I've just purged that repo and
uploaded a bpo of libsndio to mentors.

In the interest of preventing future mistakes, could someone please
reply to my git question from the following email:
Message-ID: 

Humble regards,
Nicholas

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

P.S. and I now see that I backported it for personal use, because an
mpv backport (also for personal use only) required it.

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

On 10 May 2016 at 11:17, Mattia Rizzolo  wrote:
> Sorry for the delay, these days are crazy for me

That's life, right?!  :-)

> On Fri, May 06, 2016 at 02:05:17PM -0400, Nicholas D Steeves wrote:
>> I've just purged that repo and uploaded a bpo of libsndio to mentors.
>
> mh, no.
>
> There is already one in bpo-NEW from 2 days ago :)
> https://ftp-master.debian.org/new/sndio_1.1.0-2~bpo8%2B1.html
>
> So, I'm going to use a local bpo of sndio instead (also because yours
> would not be nice to upload due to the +2.  why 2 identical changelog
> entries??), and try to build audacious again.  Tomorrow first thing in
> the morning most probably.

;-) That's mine.  I contacted Peter Piwowarski asking if he'd like me
to maintain a backport as soon as I realised that an audacious bpo
depended on having a sndio bpo in the archive.  I'm not sure where two
identical changelog entries for bpo+1 and bpo+2 came from...that's
very strange.  Thankfully my sponsor caught it during the application
process!

>> Message-ID: 
>> 
>
> On Thu, May 5, 2016 at 3:19 AM, Nicholas D Steeves  wrote:
>> Thank you very much for fixing the mess I made.  To maintain this
>> backport, is the following sequence of commands appropriate?:
>>
>> git checkout --detach --rebase debian/version-revision
>
> actually --detach shouldn't be needed at all, and I can't really see
> what --rebase would do here (also because it's not even in
> git-checkout(1))

It seems I somehow mixed up git-checkout and git-rebase.

> Now, umh, with `push debian/%(bpo_tag)s would be what I usually do
> without a branch.

Ohhh, I think I'm starting to understand now.  So what happens that
the local master branch gets ahead of the remote without --detach, but
that's ok.  It's ok because git pushes a snapshot of the local changed
state to a remote state is only referenced by the tag.  If for some
reason there was a bug in the debian/%(bpo_tag)s version, that's not
in the debian/version-revision...well, that's where it feels strange
to me.  So then one would make further changes to the local repo,
local master would get further out of sync from remote master, but
that wouldn't matter because the local state of master is only ever
reflected as a tag on the remote?  Had I made my mistake at this
point, it seems like it would have been a huge mess!

> given that now a branch is used instead the workflow is:
>
> git checkout jessie-backports   # enter the bpo branch
> git merge debian/version-revision  # merge changes since last bpo
>   # this might lead to
>  # conflicts in 
> changelog, but
>  # nothing impossible.
> dch --bpo   # update changelog
> gbp buildpackage --git-tag  # build+tag
> git status
> git add  # same as above
> git push # push the current branch
> git push --tags   # push the tag

This makes sense to me, but I'm still unclear why "git checkout
jessie-backports && git merge debian/version-revision" is preferred
over "git rebase debian/version-revision", when version-bumping the
bpo.  I guess the question is: For a version bump of a bpo, should the
changelog of a new-version bpo mention the previous bpo, or should it
only contain a single "Rebuild for $stable-backports" entry?  The
semantics of checkout+merge seem to favour a bpo changelog that
mentions prior versions (independent parallel branch with coherent
history and imported updates), while the semantics of git rebase seem
to favour a series of bpo forks (branch is a history of forks).  I've
consulted this doc: https://git-scm.com/docs/git-rebase

Mattia, thank you for taking the time to help me understand,
I appreciate it a lot,
Nicholas

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

On 10 May 2016 at 11:42, Mattia Rizzolo  wrote:
> On Tue, May 10, 2016 at 03:17:30PM +, Mattia Rizzolo wrote:
>> So, I'm going to use a local bpo of sndio instead (also because yours
>> would not be nice to upload due to the +2.  why 2 identical changelog
>> entries??), and try to build audacious again.  Tomorrow first thing in
>> the morning most probably.
>
> Actually, already did and uploading now.
>
> Enjoy ;)

Yay! :-)

___
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: RFS: audacious/3.6.2-2~bpo8+1 and audacious-plugins/3.6.2-2~bpo8+1

[Nicholas D Steeves]

Sorry for the delay.  Life... ;-)

On 10 May 2016 at 20:16, Mattia Rizzolo  wrote:
> On Tue, May 10, 2016 at 06:03:18PM -0400, Nicholas D Steeves wrote:
>> > Now, umh, with `push debian/%(bpo_tag)s would be what I usually do
>> > without a branch.
>>
>> Ohhh, I think I'm starting to understand now.  So what happens that
>> the local master branch gets ahead of the remote without --detach, but
>> that's ok.  It's ok because git pushes a snapshot of the local changed
>> state to a remote state is only referenced by the tag.  If for some
>> reason there was a bug in the debian/%(bpo_tag)s version, that's not
>> in the debian/version-revision...well, that's where it feels strange
>> to me.  So then one would make further changes to the local repo,
>> local master would get further out of sync from remote master, but
>> that wouldn't matter because the local state of master is only ever
>> reflected as a tag on the remote?
>
> Well, you are not supposed to have your local master out of sync with
> the remote one.  doing `git checkout debian/version-revision` detaches
> your head from a branch, and the stuff you do that are only referenced
> by the tag, yep.  But if you do a `git checkout master` you ought to go
> back to the very place the remote master is, and doing stuff that means
> pushing to the remote master, and stuff pushed there is going to be on
> the next unstable upload.

Ahh, so that's how you do it!  Git checkout tag detaches from a branch
and updates to that state; subsequent git checkouts will not checkout
anything, unless the tag is forcefully updated (bad!).  Git checkout
branch attaches to that branch and updates; subsequent git checkouts
bring the local repo up-to-date with that branch.

>> > given that now a branch is used instead the workflow is:
>>
>> This makes sense to me, but I'm still unclear why "git checkout
>> jessie-backports && git merge debian/version-revision" is preferred
>> over "git rebase debian/version-revision", when version-bumping the
>> bpo.  I guess the question is: For a version bump of a bpo, should the
>> changelog of a new-version bpo mention the previous bpo, or should it
>> only contain a single "Rebuild for $stable-backports" entry?
>
> The "jessie-backports branch workflow" I keep as a reference is the one
> used by devscripts, that actually keeps the old backports entry in the
> changelog during the merge.

Is the "jessie-backports branch workflow" what you provided in a
previous email?  Used by which devscript?  Dch?  If the workflow is
different than what was shared, could you please tell me where I can
read it?  I'm guessing that this will be what happens over time, to
debian/changelog:

Tagged bpo changelogs will only have one "Rebuild for jessie-backports" entry.
All these entries will somehow be prepended to the changelog in the
jessie-backports branch?
Or will the debian/changelog on the jessie-backports branch be
identical to the latest tagged bpo?

>> The
>> semantics of checkout+merge seem to favour a bpo changelog that
>> mentions prior versions (independent parallel branch with coherent
>> history and imported updates), while the semantics of git rebase seem
>> to favour a series of bpo forks (branch is a history of forks).
>
> my idea of bpo is a series of separated forks, and here detached tags
> work better than a branch.  But I think this is really a matter of how
> you see it and how you work better, the actual thing doesn't really
> change much.

I've been (locally) experimenting with both approaches.  I still think
I'm doing something wrong with detached tags!  For example, suppose I
fix spelling errors in some package of v4.5.3, and want to backport
those changes to v4.5.2:

git checkout v4.5.3
(make changes. eg: update changelog with an obvious marker)
git add -u
git commit

git checkout v4.5.2
(warning)
git stash
git checkout v4.5.2
git stash pop
(resolve conflicts)
git tag -a v4.5.2.1 -m "Backport trivial spelling fixes from v4.5.3"
git add -u
git commit
--

At this point, what I found was that if I do a checkout master, and
then do a checkout v4.5.2.1, then my changes are lost.  The only way I
can get back to them is by doing a checkout cce2f0d.  Git tag -l
--contains commit cce2f0d prints nothing.

git tag -f v4.5.2.1 cce2f0d
prints
Updated tag 'v4.5.2.1' (was 09846dc)

Now I can get back to the intended detached state using the tag.  My
concern is that with the following instructions:

On 10 May 2016 at 11:17, Mattia Rizzolo  wrote:
> dch --bpo   # update changelog
> gbp buildpackage --git-tag  # build+tag
&g

bluray burning

[Nicholas D Steeves]

Hi team!

First off, I hope I'm not breaking an unspoken taboo by raising this
issue...  Given that cdrkit still cannot reliably burn BDRs, and a
precedent for allowing CDDL software in the archive, with minor
acrobatics, I believe it is possible package a cdrecord-building
package similar to ttf-mscorefonts-installer, one of the ZFS packages,
or maybe libdvd-pkg.  I would like to do the work myself and to
maintain the package, as I've been updating my private copy since 2011
or so.  If you've already done the work, why not share it, after doing
a bit more work on fixups, right?

The primary business/professional rational for the package is for a
poor-man's alternative to WORM tapes, using 25, 50, or 100GB discs.
Many drives also support M-DISC ( https://en.wikipedia.org/wiki/M-DISC
), which sounds like a seriously cool, if expensive, physical archival
format that outlasts even tape!

Is libdvd-pkg the most appropriate package to model mine on?  From
what I've read the problem is with distributing the mixed GPL+CDDL
source, so it seems like the best thing to do is to put it in Section:
contrib/utils, and provide sha256sums of the source.  When the package
is installed, it downloads the source from the original site, builds
it, and installs.  I'm guessing the package should be called
cdrecord-pkg, and cdrecord-pkg should download, build, and install
cdrecord.

My second set of questions involves the built system "smake".  With
the exception of smake/autoconf, which is GPL, it is CDDL copyright
source.  I'm not yet sure if it can be transitioned autoreconf, and
I'm not sure if that would be a strong enough solution to the GPL +
CDDL source = undistributable problem.  If it can be transitioned
without issue, then could smake be a normal part of the archive in
Section: devel?  If it can't be transitioned, then should I make a
smake-pkg in section contrib/devel that downloads, builds, and
installs smake?

Sincerely,
Nicholas

___
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#824211: marked as pending

[Nicholas D Steeves]

On 31 May 2016 at 16:27, Jaromír Mikeš  wrote:
> Will be fixed soon.
>
> mira
>
> 2016-05-31 20:42 GMT+02:00 Javier Serrano Polo :
>> El dt 31 de 05 de 2016 a les 14:09 +, Jaromír Mikeš va escriure:
>>> +  * Fix multi-arch path.
>>
>> Will the plug-ins be installed under /usr/lib/*/ladspa? I would be in
>> favor, but AFAIK this would be the first Debian package to ship LADSPA
>> plug-ins under a multiarch folder instead of /usr/lib/ladspa.

A few of my hopefully-baseless worries:

Would someone please confirm that this is a mechanism in place to
insure that any of /usr/lib/*/ladspa and /usr/lib/ladspa will be
correctly added to $LADSPA_PATH?  Also, will the multiarch approach
necessitate a LADSPA32_PATH LADSPA64_PATH in the case of a mixed i386
and amd64 system?  Or is this the beginning of a formal transition
from /usr/lib/ladspa to /usr/lib/$primary_arch/ladspa?

Sincerely,
Nicholas

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Whatever happened to this multiarch effort?

[Nicholas D Steeves]

Following up on:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824211#70

The LV2 multi-arch enabling thread stopped at the following:
https://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2014-January/036354.html

Did anyone ever follow-up with Robin Gareus or Alessio Treglia?  Does
LV2_PATH replace $LADSPA_PATH, and are there still any LADSPA V1
plugins in the archive?  Was it the potential of breaking the software
which didn't/doesn't use liblilv that caused this effort to stall?
Alternatively, I wonder if it was because it turned out to be such a
massive effort to patch a tonne of stuff...

Cheers,
Nicholas

___
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#824211: marked as pending

[Nicholas D Steeves]

Oh, I now see what happened with swh-plugins now with '+  * Fix
multi-arch path."' (I received email to deb-multimedia mailing list
and replied without checking bug context).  Sorry about that!  I'll
move my OT discussion to the mailing list.

Best regards,
Nicholas

___
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#827983: libva1: upgrade to va 1.7.1 breaks intel graphics

[Nicholas D Steeves]

Hi,

For another data point, I've attached the output to the following:
lsb_release -a > graphics-stack.txt && echo >> graphics-stack.txt &&
dpkg -l linux-image-4.4.14.20160627 *drm* xserver-xorg-video-intel
*mesa* libva* i965-va-driver | sed '//d' >> graphics-stack.txt

As Sebastian notes, I also think it's unlikely that the libva
subsystem is exclusively at fault.  Norbert, does your system exhibit
this behaviour if you install libva.*=1.7.1, but use an older version
of i965-va-driver?  To provide more useful debugging info, could you
please install the following: linux-image-4.6.0-1-amd64=4.6.2-2,
xserver-xorg-video-intel-dbg, and i965-va-driver-dbg?

Then boot linux-4.6.2 with drm.debug=0xe.  Please specify which
applications exhibit the corruption.  What compositing window manager
are you using, and what CPU and GPU ?  Also, please attach your "dmesg
> ~/dmesg.log" and "lspci -nn | grep -e "\[03..\]: > ~/gpu.info &&
echo && cat /proc/mtrr >> ~/gpu.info"

What Norbert describes as " * redrawing of applications full of
failures (no redrawing in many cases!)" reminds me of when Kwin is
configured to "Re-use screen content".  Also, a long time ago I had
similar symptoms on my Sandybridge (2000-series i5) Thinkpad.  I
believe it only affected Iceweasel/Firefox, but it was so long ago I'm
not sure...  It might have been caused by an interaction between
kernel version and i965-va-driver version I was using.

Cheers,
Nicholas
Distributor ID: Debian
Description:Debian GNU/Linux 8.5 (jessie)
Release:8.5
Codename:   jessie

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture 
Description
+++--===--==
ii  i965-va-driver:amd64 1.4.1-2 amd64
VAAPI driver for Intel G45 & HD Graphics family
ii  i965-va-driver:i386  1.4.1-2 i386 
VAAPI driver for Intel G45 & HD Graphics family
ii  libdrm-amdgpu1:amd64 2.4.68-1~bpo8+1 amd64
Userspace interface to amdgpu-specific kernel DRM services -- runtime
ii  libdrm-amdgpu1:i386  2.4.68-1~bpo8+1 i386 
Userspace interface to amdgpu-specific kernel DRM services -- runtime
ii  libdrm-dev:amd64 2.4.68-1~bpo8+1 amd64
Userspace interface to kernel DRM services -- development files
ii  libdrm-intel1:amd64  2.4.68-1~bpo8+1 amd64
Userspace interface to intel-specific kernel DRM services -- runtime
ii  libdrm-intel1:i386   2.4.68-1~bpo8+1 i386 
Userspace interface to intel-specific kernel DRM services -- runtime
ii  libdrm-nouveau2:amd642.4.68-1~bpo8+1 amd64
Userspace interface to nouveau-specific kernel DRM services -- runtime
ii  libdrm-nouveau2:i386 2.4.68-1~bpo8+1 i386 
Userspace interface to nouveau-specific kernel DRM services -- runtime
ii  libdrm-radeon1:amd64 2.4.68-1~bpo8+1 amd64
Userspace interface to radeon-specific kernel DRM services -- runtime
ii  libdrm-radeon1:i386  2.4.68-1~bpo8+1 i386 
Userspace interface to radeon-specific kernel DRM services -- runtime
ii  libdrm2:amd642.4.68-1~bpo8+1 amd64
Userspace interface to kernel DRM services -- runtime
ii  libdrm2:i386 2.4.68-1~bpo8+1 i386 
Userspace interface to kernel DRM services -- runtime
ii  libegl1-mesa:amd64   11.1.3-1~bpo8+1 amd64
free implementation of the EGL API -- runtime
ii  libegl1-mesa-dev:amd64   11.1.3-1~bpo8+1 amd64
free implementation of the EGL API -- development files
ii  libegl1-mesa-drivers:amd64   11.1.3-1~bpo8+1 amd64
transitional dummy package
ii  libgl1-mesa-dev:amd6411.1.3-1~bpo8+1 amd64
free implementation of the OpenGL API -- GLX development files
ii  libgl1-mesa-dri:amd6411.1.3-1~bpo8+1 amd64
free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-dri:i386 11.1.3-1~bpo8+1 i386 
free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx:amd6411.1.3-1~bpo8+1 amd64
free implementation of the OpenGL API -- GLX runtime
ii  libgl1-mesa-glx:i386 11.1.3-1~bpo8+1 i386 
free implementation of the OpenGL API -- GLX runtime
ii  libglapi-mesa:amd64  11.1.3-1~bpo8+1 amd64
free implementation of the GL API -- shared libra

modifying libva (master) .gitignore

[Nicholas D Steeves]

Hi,

I ran into an issue with backporting libva.  Is it ok if I add the
following to libva (master) .gitignore?:

debian.upstream/changelog
debian.upstream/control

Thanks,
Nicholas

___
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: modifying libva (master) .gitignore

[Nicholas D Steeves]

Hi Sebastian,

On 5 July 2016 at 05:30, Sebastian Ramacher  wrote:
>
> On 2016-07-04 14:54:17, Nicholas D Steeves wrote:
>> I ran into an issue with backporting libva.  Is it ok if I add the
>> following to libva (master) .gitignore?:
>>
>> debian.upstream/changelog
>> debian.upstream/control
>
> How will this change affect gbp import-orig since these files come from the
> upstream tarball?
>
> I usually use --git-ignore-new and cases where I really need gbp buildpackage.
>

I've read the following article:
https://wiki.debian.org/UpstreamGuide

>From what I understand of that page, and what I understand of the
build process, it should be safe and desirable to prevent the
debian.upstream/* from being imported into (master), because we use
the ones in the (master) libva/debian.  Debian.upstream should
probably still be imported into the (upstream) branch.

Today I a tested a variety of approaches in combination with gbp
import-orig, and it seems like this simple .gitignore solution might
not be viable.  For example, adding debian.upstream to .gitignore and
then deleting debian.upstream will produce conflicts whenever gbp
import-orig imports a new version.  Alternatively, if debian.upstream
is not deleted then the directory on Alioth will increasingly get
stale.  I think this is probably the correct solution:

https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Merge-Strategies
more documentation available here:
https://git-scm.com/docs/gitattributes

I have to take a break from this for a couple hours, but it looks like
setting a custom attribute of merge=ours (deleted) for the
debian.upstream directory will prevent both the merge conflict every
time gbp import-orig is run, and will prevent the stale directory on
Alioth by maintaining its deleted state.

Two questions:  What do you think of this approach?  If we go ahead
with this, on specifically what page should we document this "using
git attributes in Debian packaging to prevent import of upstream
debian directory" approach so that other Debian developers can refer
to it?  It would have saved me a tonne of time if I had been able to,
for example, find this information in:
https://wiki.debian.org/PackagingWithGit

Kind regards,
Nicholas

___
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: modifying libva (master) .gitignore

[Nicholas D Steeves]

Hi Sebastian,

On 8 July 2016 at 04:33, Sebastian Ramacher  wrote:
> On 2016-07-06 16:17:09, Nicholas D Steeves wrote:
>>
>> On 5 July 2016 at 05:30, Sebastian Ramacher  wrote:
>> >
>> > On 2016-07-04 14:54:17, Nicholas D Steeves wrote:
>> >> I ran into an issue with backporting libva.  Is it ok if I add the
>> >> following to libva (master) .gitignore?:
>> >>
>> >> debian.upstream/changelog
>> >> debian.upstream/control
>> >
>> > How will this change affect gbp import-orig since these files come from the
>> > upstream tarball?
>> >
>> > I usually use --git-ignore-new and cases where I really need gbp 
>> > buildpackage.
>> >
>
> I think it's overly complicated for something that can simply be solved by 
> using
> --git-ignore-new when using gbp buildpackage or patching the upstream build
> system to not include debian.upstream/Makefile.am. I'll probably add a patch 
> for
> the latter.

Thank you for the assistance!  I'm going to bookmark this method for
future reference, and yes, I see why it is undeniably better than my
proposal. ;-)  I imagine those three commits need to be represented in
debian/changelog before I do the backport, so I've attached an example
patch.  To release the bpo while I still have the free time, is it ok
to add these items to a 1.7.1-1 bpo changelog, push and release, and
only later package 1.7.1-2 whenever it hits testing?

Also for future reference: Did I update the changelog properly, to
represent work another team member did on the package?  And is it ok
to push changelog diffs like this one, or should I wait for author of
the work to update the changelog?

Cheers,
Nicholas
From a343f23ef398864df25a06863bc4fb4f8a9d71d7 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Mon, 11 Jul 2016 09:27:06 -0400
Subject: [PATCH] Update changelog from git log of Sebastian's work

Signed-off-by: Nicholas D Steeves 
---
 debian/changelog | 9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 9d18b4b..715a142 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libva (1.7.1-2) UNRELEASED; urgency=medium
+
+  [ Sebastian Ramacher ]
+  * Remove obsolete files
+  * No longer clean files in debian.upstream
+  * Do not touch debian.upstream during build
+
+ -- Nicholas D Steeves   Mon, 11 Jul 2016 09:23:44 -0400
+
 libva (1.7.1-1) unstable; urgency=medium
 
   * New upstream release.
-- 
2.8.1

___
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: modifying libva (master) .gitignore

[Nicholas D Steeves]

P.S. I think I've finally gotten the hang of pushing tags disconnected
from a branch.  eg:
1. create local bpo development branch
2. prepare backport
3. tag bpo
4. git push origin tag_name

And the reason I made those mistakes with the audacious bpo is because
I understood "not on a branch" to mean not on a local branch, rather
than not on a remote branch.  If you would confirm that I did it
correctly, then in the future I can push bpos without a (remote)
jessie-backports branch.
https://github.com/sten0/libva-test/blob/debian/1.7.1-1_bpo8%2B1/debian/changelog

Thanks!
Nicholas

___
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: modifying libva (master) .gitignore

[Nicholas D Steeves]

On 8 July 2016 at 04:33, Sebastian Ramacher  wrote:
> On 2016-07-06 16:17:09, Nicholas D Steeves wrote:
>> Hi Sebastian,
>>
>> On 5 July 2016 at 05:30, Sebastian Ramacher  wrote:
>> >
>> > On 2016-07-04 14:54:17, Nicholas D Steeves wrote:
>> >> I ran into an issue with backporting libva.  Is it ok if I add the
>> >> following to libva (master) .gitignore?:
>> >>
>> >> debian.upstream/changelog
>> >> debian.upstream/control
>> >
>> > How will this change affect gbp import-orig since these files come from the
>> > upstream tarball?
>> >
>> > I usually use --git-ignore-new and cases where I really need gbp 
>> > buildpackage.
>> >
>>
>> From what I understand of that page, and what I understand of the
>> build process, it should be safe and desirable to prevent the
>> debian.upstream/* from being imported into (master), because we use
>> the ones in the (master) libva/debian.  Debian.upstream should
>> probably still be imported into the (upstream) branch.
>>
>> Today I a tested a variety of approaches in combination with gbp
>> import-orig, and it seems like this simple .gitignore solution might
>> not be viable.  For example, adding debian.upstream to .gitignore and
...
> I think it's overly complicated for something that can simply be solved by 
> using
> --git-ignore-new when using gbp buildpackage or patching the upstream build
> system to not include debian.upstream/Makefile.am. I'll probably add a patch 
> for
> the latter.

It seems I spoke too soon wrt my last email.  Currently, libva still
wants to run make in debian.upstream.  What I find strange is that
outright removing the debian.upstream dir didn't cause the following
build failures:

checkout f57b4ed747be83f72a4c6b72a845011ef6c35ce6
  * I then removed the debian.upstream directory, and commited the changes
  * It built just fine for sid and for jessie-backports (gbp)

checkout dbb99e381206508d213797dbe1214a8f04368333
  * build fails (gbp) with

make[5]: Nothing to be done for 'all-am'.
make[5]: Leaving directory '/build/libva-1.7.1/test'
make[4]: Leaving directory '/build/libva-1.7.1/test'
Making all in debian.upstream
make[4]: Entering directory '/build/libva-1.7.1/debian.upstream'
make[4]: *** No rule to make target 'all'.  Stop.
make[4]: Leaving directory '/build/libva-1.7.1/debian.upstream'
Makefile:465: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/build/libva-1.7.1'
Makefile:397: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/build/libva-1.7.1'
dh_auto_build: make -j1 returned exit code 2
debian/rules:20: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/build/libva-1.7.1'
debian/rules:14: recipe for target 'build' failed
make: *** [build] Error 2

checkout 3836579b289964afe57ed3986693d1b882b74efb
  * build fails for the same reason

checkout 22796dd3c4cf90c44e27ca74692fdad127b545e5
  * build fails for the same reason

Cheers,
Nicholas

___
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] libva/master: Fix FTBS by updating ignore-debian.upstream.patch * Remove debian.upstream, and associated unused stanzas from Makefile.am and Makefile.in

[Nicholas D Steeves]

On 17 July 2016 at 04:52, Sebastian Ramacher  wrote:
> On 2016-07-17 01:46:30, sten-gu...@users.alioth.debian.org wrote:
>> The following commit has been merged in the master branch:
>> commit aa0330cf48fb0f6fd37840d46981efe0b0a3e2c0
>> Author: Nicholas D Steeves 
>> Date:   Sat Jul 16 21:21:08 2016 -0400
>>
>> Fix FTBS by updating ignore-debian.upstream.patch
>>   * Remove debian.upstream, and associated unused stanzas
>> from Makefile.am and Makefile.in
>>
...
>> + DEB_BUILDDIR = debian.build
>> +-
>> +-deb:
>> +-@[ -d debian ] || ln -s debian.upstream debian
>> +-dpkg-buildpackage -rfakeroot -uc -us
>> +-
>> +-deb.upstream: dist
>> +--mkdir -p $(DEB_BUILDDIR)
>> +-cd $(DEB_BUILDDIR)  && \
>> +-rm -rf $(PACKAGE)-$(VERSION)&& \
>> +-tar zxvf ../$(PACKAGE)-$(VERSION).tar.gz&& \
>> +-cd $(PACKAGE)-$(VERSION)&& \
>> +-$(MAKE) deb -f Makefile.am
>
> That's not used anyway. I'd leave it in.

I wasn't sure what the minimum necessary modifications were to prevent
these targets from being made by "make all"

>> +-SUBDIRS = va dummy_drv_video pkgconfig test debian.upstream doc
>> ++SUBDIRS = va dummy_drv_video pkgconfig test doc

Is removing the SUBDIR sufficient?

>> +Index: libva/Makefile.in
>> +===
>> +--- libva.orig/Makefile.in
>>  libva/Makefile.in
>
> No, please don't patch any Makefile.in if dh_autoreconf is used.

Done, Makefile.in restored in commit 833f1ff432601266f3480adf120e76756a6c3f8f

Thank you for the tips!
Nicholas

___
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] libva/master: Fix FTBS by updating ignore-debian.upstream.patch * Remove debian.upstream, and associated unused stanzas from Makefile.am and Makefile.in

[Nicholas D Steeves]

On 17 July 2016 at 18:02, Nicholas D Steeves  wrote:
> On 17 July 2016 at 04:52, Sebastian Ramacher  wrote:
>> On 2016-07-17 01:46:30, sten-gu...@users.alioth.debian.org wrote:
>>>
>>> + DEB_BUILDDIR = debian.build
>>> +-
>>> +-deb:
>>> +-@[ -d debian ] || ln -s debian.upstream debian
>>> +-dpkg-buildpackage -rfakeroot -uc -us
>>> +-
>>> +-deb.upstream: dist
>>> +--mkdir -p $(DEB_BUILDDIR)
>>> +-cd $(DEB_BUILDDIR)  && \
>>> +-rm -rf $(PACKAGE)-$(VERSION)&& \
>>> +-tar zxvf ../$(PACKAGE)-$(VERSION).tar.gz&& \
>>> +-cd $(PACKAGE)-$(VERSION)&& \
>>> +-$(MAKE) deb -f Makefile.am
>>
>> That's not used anyway. I'd leave it in.
>
> I wasn't sure what the minimum necessary modifications were to prevent
> these targets from being made by "make all"
>
>>> +-SUBDIRS = va dummy_drv_video pkgconfig test debian.upstream doc
>>> ++SUBDIRS = va dummy_drv_video pkgconfig test doc
>
> Is removing the SUBDIR sufficient?

Well, it builds...  I pushed the changes.  Simple patches are always
preferable, right?! ;-)

Cheers,
Nicholas

___
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] mpv/master: Rebuild against ffmpeg-3.1.1 (Closes: #831537)

[Nicholas D Steeves]

On 18 July 2016 at 06:21, James Cowgill  wrote:
> Hi,
>
> On Sun, 2016-07-17 at 22:16 +, sten-gu...@users.alioth.debian.org wrote:
>> The following commit has been merged in the master branch:
>> commit d3dc4b14057eab6f3bfa09c8388a7c20351ccf95
>> Author:
>> Date:   Sun Jul 17 17:40:59 2016 -0400
>>
>> Rebuild against ffmpeg-3.1.1 (Closes: #831537)
>>
>> diff --git a/debian/changelog b/debian/changelog
>> index 0e3ff7b..1123209 100644
>> --- a/debian/changelog
>> +++ b/debian/changelog
>> @@ -1,3 +1,9 @@
>> +mpv (0.18.0-2) UNRELEASED; urgency=medium
>> +
>> +  * Rebuild against ffmpeg-3.1.1 (Closes: #831537)
>> +
>> + -- Nicholas D Steeves   Sun, 17 Jul 2016 17:38:39 -0400
>
> This is the wrong way to go about doing this. If you just want to
> rebuild a package, then you should ask the release team to binNMU it.
>
> IMO this warning should be patched out of mpv (and any ABI issues
> sorted out). Upstream also seems to have made this warning into a fatal
> error in 0.18.1 which is obviously unacceptable for Debian.
>
> https://github.com/mpv-player/mpv/commit/d057e7a142a327c653f3f0379014567028448b5d

My mistake, I've reverted it.  When is "dch -R" appropriate?  When I
saw the bug report I thought "aha! I know how to fix this, this is
what dch -R is for!" because it is a "no-change rebuild" (dch
manpage).  Also, I thought that even no change rebuilds were supposed
to be represented in git...

Has someone else already emailed debian-release@lists?

Best regards,
Nicholas

___
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#831537: marked as pending

[Nicholas D Steeves]

On 25 July 2016 at 21:41, Roland Hieber  wrote:
> Hi,
>
> I'm curious and want to understand, so am I right that a binNMU [0]
> should be enough here? If not, why not?
>
> [0]: https://wiki.debian.org/binNMU
>
> Cheers,
>  - Roland

I thought so too...  You can follow the Debian side of the discussion here:
https://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2016-July/052802.html

Cheers,
Nicholas

___
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] intel-vaapi-driver/master: Update changelog.

[Nicholas D Steeves]

On 26 July 2016 at 15:28,   wrote:
> The following commit has been merged in the master branch:
> commit 83b3cee40dba3b40797b576a4d32429741224c15
> Author: Nicholas D Steeves 
> Date:   Tue Jul 26 15:26:05 2016 -0400
>
> Update changelog.
>
> diff --git a/debian/changelog b/debian/changelog
> index d843983..a4954e5 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,6 +1,7 @@
>  intel-vaapi-driver (1.7.1-2) UNRELEASED; urgency=medium
>
> -  * debian/patches/ignore-debian.upstream.patch: replicate patch from libva
> +  * debian/patches/ignore-debian.upstream.patch: replicate patch from libva.
> +  * debian/clean: replicate change from libva; remove empty file.

Please soon upload 1.7.1-2 to sid.  It is needed for my three-part
backport of the Intel vaapi stack (intel-gpu-tools, libva, and
intel-vaapi-driver).  Intel-gpu-tools is in jessie-backports and libva
1.7.1-2 is waiting to migrate to testing.  It would be better to
simultaneously upload libva and intel-vaapi-driver to
jessie-backports, no?

Kind regards,
Nicholas

___
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] intel-vaapi-driver packaging branch, jessie-backports, created. debian/1.7.1-1-1-gb40f4e3

[Nicholas D Steeves]

On 29 July 2016 at 06:28,   wrote:
> The branch, jessie-backports has been created
> at  b40f4e34eed7e6e9f3225aa28f8ac9963d509747 (commit)
>
> - Shortlog 
> commit b40f4e34eed7e6e9f3225aa28f8ac9963d509747
> Author: Nicholas D Steeves 
> Date:   Fri Jul 29 06:25:56 2016 -0400
>
> Backport 1.7.1-1 to Jessie.
>

I figured out a way to a hack to work around the gbp build failure
that is fixed in 1.7.1-2 UNRELEASED.  Briefly, in ~/.gbp.conf:  change
the cleaner line under [DEFAULT] to "cleaner = true" ;-)  Please
upload the libva bpo and this one simultaneously.

Cheers!
Nicholas

___
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: concerning llibva backport

[Nicholas D Steeves]

On 5 August 2016 at 09:43, Sebastian Ramacher  wrote:
> On 2016-07-29 06:40:07, Nicholas D Steeves wrote:
>> On 29 July 2016 at 06:28,   wrote:
>> > The branch, jessie-backports has been created
>> > at  b40f4e34eed7e6e9f3225aa28f8ac9963d509747 (commit)
>> >
>> > - Shortlog 
>> > commit b40f4e34eed7e6e9f3225aa28f8ac9963d509747
>> > Author: Nicholas D Steeves 
>> > Date:   Fri Jul 29 06:25:56 2016 -0400
>> >
>> > Backport 1.7.1-1 to Jessie.
>> >
>>
>> I figured out a way to a hack to work around the gbp build failure
>> that is fixed in 1.7.1-2 UNRELEASED.  Briefly, in ~/.gbp.conf:  change
>> the cleaner line under [DEFAULT] to "cleaner = true" ;-)  Please
>> upload the libva bpo and this one simultaneously.
>
> I'm not in the backports ACL. You'll need another DD to sponsor the upload.
>
> Cheers
> --
> Sebastian Ramacher

Hi Sebastian,

I did a fresh build of libva-1.7.1-1~bpo+1 today, and noticed that it
was building against mesa-10.3.2-1+deb8u1 from Jessie.  I've been
testing it on a Jessie+backported mesa-11.1.3-1~bpo8+1, and the
packages I've been testing have also been built against mesa-10.3.x.
Do you think it's ok to build against mesa 10.3.2, or should we bump
the build deps of libva to pull in mesa from jessie-backports.  I'm in
favour of bumping the deps asap.  Additionally, I think it would also
be wise to bump the intel-vaapi-driver build-depend on libdrm-dev to
prevent it from being built against libdrm-2.4.58-2.

Also, my upload sponsor requires no-change backports so packages
implementing these proposed changes will need to be uploaded to sid.

Kind regards,
Nicholas

___
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: concerning llibva backport

[Nicholas D Steeves]

On 5 August 2016 at 18:30, Felipe Sateler  wrote:
> On 5 August 2016 at 18:15, James Cowgill  wrote:
>> On 05/08/16 22:47, Felipe Sateler wrote:
>>> On 5 August 2016 at 17:24, James Cowgill  wrote:
>>>> On 05/08/16 21:03, Nicholas D Steeves wrote:
>>>>> Hi Sebastian,
>>>>>
>>>>> I did a fresh build of libva-1.7.1-1~bpo+1 today, and noticed that it
>>>>> was building against mesa-10.3.2-1+deb8u1 from Jessie.  I've been
>>>>> testing it on a Jessie+backported mesa-11.1.3-1~bpo8+1, and the
>>>>> packages I've been testing have also been built against mesa-10.3.x.
>>>>> Do you think it's ok to build against mesa 10.3.2, or should we bump
>>>>> the build deps of libva to pull in mesa from jessie-backports.  I'm in
>>>>> favour of bumping the deps asap.  Additionally, I think it would also
>>>>> be wise to bump the intel-vaapi-driver build-depend on libdrm-dev to
>>>>> prevent it from being built against libdrm-2.4.58-2.
>>>>
>>>> Why? You realize that building against a newer version of mesa/libdrm
>>>> won't affect the dependencies on the final package?
>>>
>>> In backports, it does. Dependencies are statisfied from stable if
>>> possible, thus the build-depends needs to be tightened to force use of
>>> the backported library.
>>
>> What I mean is that build-depending on a more recent package version
>> doesn't necessarily[1] mean that version will be required at runtime and
>> reflected in the Depends: lines. For example, mesa doesn't insert any
>> dependencies into the users of libgl1-mesa-glx, so bumping the
>> build-dependency will have no affect on the version of the package
>> actually used at runtime. So if the downstream package doesn't use any
>> new features in the more recent library, why bump the build-dependency?
>
> Ah. I was unaware of that weirdness. Indeed the mesa symbols file set
> all versions to 0, and does not provide a -dev package mapping. So the
> dep would be useless.
>
>
> --
>
> Saludos,
> Felipe Sateler

Yes, I just ran into that...  Bumping libegl1-mesa-dev and
libgl1-mesa-dev is insufficient, because mesa-common, libgl1,
libgl1-mesa-glx, libglapi-mesa still get pulled in from stable.

However, libwayland-egl1-mesa, libwayland-egl1-mesa-dev, libegl1-mesa,
and libegl1-mesa-dev are pulled in from jessie-backports.  I've
attached the build log.

So, what needs to be done?  Does debian/control a method to add
Build-Depends line like: (this AND this) || (that), ?  Specifically,
I'm wondering if the "libgl1-mesa-dev (>= 11.1.0) | libgl-dev," can be
change to something that includes the list of packages being pulled in
from stable.

Cheers,
Nicholas


libva_1.7.1-3~bpo8+1_amd64.build.xz
Description: application/xz
___
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: concerning llibva backport

[Nicholas D Steeves]

On Thu, Aug 25, 2016 at 11:26:58PM +0100, James Cowgill wrote:
> On 23/08/16 23:30, Nicholas D Steeves wrote:
> > On 7 August 2016 at 09:12, James Cowgill  wrote:
> >> Hi,
> >>
> >> On 06/08/16 22:58, Nicholas D Steeves wrote:
> >>> On 6 August 2016 at 05:12, Sebastian Ramacher  
> >>> wrote:
> >>>> On 2016-08-05 16:03:39, Nicholas D Steeves wrote:
> >>>>> Hi Sebastian,
> >>>>>
> >>>>> I did a fresh build of libva-1.7.1-1~bpo+1 today, and noticed that it
> >>>>> was building against mesa-10.3.2-1+deb8u1 from Jessie.  I've been
> >>>>> testing it on a Jessie+backported mesa-11.1.3-1~bpo8+1, and the
> >>>>> packages I've been testing have also been built against mesa-10.3.x.
> >>>>> Do you think it's ok to build against mesa 10.3.2, or should we bump
> >>>>> the build deps of libva to pull in mesa from jessie-backports.  I'm in
> >>>>> favour of bumping the deps asap.
> >>>>
> >>>> NACK. The mesa build dependency does not matter at all. The only 
> >>>> intersting
> >>>> thing is libdrm vor intel-vaapi-driver.
> >>>>
> >>>>> Additionally, I think it would also
> >>>>> be wise to bump the intel-vaapi-driver build-depend on libdrm-dev to
> >>>>> prevent it from being built against libdrm-2.4.58-2.
> >>>>
> >>>> This was recently bumped to match the upstream requirement. There is not 
> >>>> other
> >>>> bumping needed.
> >>>>
> >>>> Cheers
> >>>> --
> >>>> Sebastian Ramacher
> >>>
> >>> So, just to definitively confirm, the following is a non-issue?:
> >>>
> >>> I found was that in some cases symbols were added, in some cases they
> >>> were removed.  In particular I'm concerned with a number of symbols
> >>> from libgl1-mesa-glx that were removed in 11.x.  If building against
> >>> mesa-10.x makes vaapi use any of these texture, matrix, transform,
> >>> shader, or surface symbols then would libva or the intel vaapi driver
> >>> misbehave if those functions are not included in mesa 11.x?
> >>
> >> Mesa (and libGL in general) is a special library which is allowed to
> >> remove certain functions without breaking the ABI because all users of
> >> those functions are expected to look them up using dlsym and gracefully
> >> handle any errors. As far as I can tell, it was mostly obsolete
> >> extension functions that were removed in mesa-11.
> >>
> >>> In years past I've had libvaapi or intel-vaapi-driver compilation fail
> >>> because of incompatible texture and (especially!) surface functions.
> >>> The Ubuntu convention also seems to be that libvaapi bpo depends on
> >>> libmesa bpo ( 
> >>> https://askubuntu.com/questions/758398/ubuntu-14-04-4-lts-enablement-stack-has-unmet-mesa-dev-dependencies
> >>> ).
> >>
> >> I'm not sure the above question has anything to do with libva and I
> >> couldn't find any Ubuntu backports of libva when I tried searching.
> >>
> >>> Back then, I ran into what I believe was this issue when I
> >>> privately backported libva to Wheezy, and had to backport libmesa too,
> >>> and also had to use debuild instead of a clean chroot.  Symbol files
> >>> are attached.  I generated them with using dpkg-deb to unpack the
> >>> packages, then dpkg-gensymbols -v1 -plibgl1-mesa-glx
> >>> -Plibgl1-mesa-glx_$VERSION -Olibgl1-mesa-glx_$VERSION.symbols
> >>>
> >>> libglapi-mesa-11.x added _glapi_new_nop_table@Base,
> >>> _glapi_set_nop_handler@Base, and table_set_noop_handler@Base, but I
> >>> don't recognize those as being relevant to VAAPI.
> >>>
> >>> Please let me know, I'd prefer to be wrong :-)
> >>>
> >>> Thank you for taking the time to respond,
> >>> Nicholas
> >>
> >> James
> > 
> > Thank you for the clarification James!  And sorry for the delay...busy
> > period with work.  If there are no remaining issues blocking an
> > upload, would someone with the bpo acl please upload and tag backports
> > for libva and intel-vaapi-driver?  The backports both are on their
> > respective jessie-backports branches.
> 
> Uploaded!
> 
> James
> 

Thank you James!

Nicholas


signature.asc
Description: Digital signature
___
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#836078: audacious: please switch from dbus-x11 to default-dbus-session-bus | dbus-session-bus

[Nicholas D Steeves]

On Tue, Aug 30, 2016 at 02:21:11PM +0100, Simon McVittie wrote:
> As described in 
> I'm trying to reduce how much dbus-launch is used in Debian.
> This package currently Depends on dbus-x11 as a way to get a session bus.
> 
> This package falls into the "other software that relies on D-Bus"
> category: please replace
> 
> Depends: dbus-x11
> 
> with
> 
> Depends: default-dbus-session-bus | dbus-session-bus
> 
> so that either dbus-user-session or dbus-x11 can be used.
> 
> My short-term goal with this is that major desktop environments in Debian
> stretch should be able to run with either dbus-user-session or dbus-x11,
> with the other one uninstalled.

Hi Simon,

I maintain the Jessie backport for audacious.  As far as I can tell,
neither default-dbus-session-bus nor dbus-session-bus are provided for
Jessie, even as a virtual package.  What is your plan
is for continuing to support no-change backports for Jessie?  This
might be a good addendum for that debian-devel thread. :-)

Cheers!
Nicholas


signature.asc
Description: Digital signature
___
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: concerning libva-1.7.2-1 backport

[Nicholas D Steeves]

On 6 August 2016 at 05:12, Sebastian Ramacher  wrote:
> On 2016-08-05 16:03:39, Nicholas D Steeves wrote:
>>
>> Hi Sebastian,
>>
>> I did a fresh build of libva-1.7.1-1~bpo+1 today, and noticed that it
>> was building against mesa-10.3.2-1+deb8u1 from Jessie.  I've been
>> testing it on a Jessie+backported mesa-11.1.3-1~bpo8+1, and the
>> packages I've been testing have also been built against mesa-10.3.x.
>> Do you think it's ok to build against mesa 10.3.2, or should we bump
>> the build deps of libva to pull in mesa from jessie-backports.  I'm in
>> favour of bumping the deps asap.
>
> NACK. The mesa build dependency does not matter at all. The only intersting
> thing is libdrm vor intel-vaapi-driver.
>
>> Additionally, I think it would also
>> be wise to bump the intel-vaapi-driver build-depend on libdrm-dev to
>> prevent it from being built against libdrm-2.4.58-2.
>
> This was recently bumped to match the upstream requirement. There is not other
> bumping needed.
>
> Cheers
> --
> Sebastian Ramacher

Hi Sebastian,

When backporting libva-1.7.2-1 today, it builds against and depends on
libdrm-2.4.58-2 instead of 2.4.70-1~bpo8+1.  Intel-vaapi-driver
correctly builds and depends on libdrm-2.4.70-1~bpo8+1.  Is it really
ok?  Shouldn't the two build against and require the same libdrm
version? eg, intel-vaapi-driver/debian/control: libdrm-dev (>= 2.4.60)

Cheers,
Nicholas

___
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: concerning libva-1.7.2-1 backport

[Nicholas D Steeves]

On Mon, Sep 05, 2016 at 04:58:41PM +0100, James Cowgill wrote:
> Hi,
> 
> On 05/09/16 16:39, Nicholas Steeves wrote:
> > On 5 September 2016 at 11:03, James Cowgill  wrote:
> >> On 05/09/16 15:41, Nicholas D Steeves wrote:
> >>> Hi Sebastian,
> >>>
> >>> When backporting libva-1.7.2-1 today, it builds against and depends on
> >>> libdrm-2.4.58-2 instead of 2.4.70-1~bpo8+1.  Intel-vaapi-driver
> >>> correctly builds and depends on libdrm-2.4.70-1~bpo8+1.  Is it really
> >>> ok?  Shouldn't the two build against and require the same libdrm
> >>> version? eg, intel-vaapi-driver/debian/control: libdrm-dev (>= 2.4.60)
> >>
> >> libdrm 2.4.70 gets pulled in when intel-vaapi-driver is built because
> >> intel-vaapi-driver depends on intel-gpu-tools from backports, which in
> >> turn depends on a newer libdrm.
> >>
> >> I think I said this to you before: this is not a problem because the
> >> versions of libdrm at runtime will always be the same everywhere and
> >> intel-vaapi-driver does not seem to do anything different (as far as I'm
> >> aware) if built against a more recent version of libdrm.
> >>
> >> James
> >>
> > 
> > Hi James,
> > 
> > I understand how the intel-vaapi-driver dependencies work, and which 
> > packages end up installed at runtime.  My concern is specifically:
> > 
> > A.
> > 1. build libva (built with old_libdrm)
> > 2. build intel-vaapi-driver (built with new_libdrm and with (libva built 
> > with old_libdrm))
> > 3. install intel-vaapi-driver (install new_libdrm and (libva built with 
> > old_libdrm))
> > 
> > vs
> > 
> > B.
> > 1. build libva (built with with newdrm)
> > 2. build intel-vaapi-driver (built with new_libdrm and with (libva built 
> > with new_libdrm))
> > 3. install intel-vaapi-driver (install new_libdrm and (libva built with 
> > new_libdrm))
> > 
> > Are (A) and (B) really equivalent?  I understand that the installed package 
> > versions are the same, but
> A2 != B2 makes me think that they're not equivalent.  That's what I'm
> wondering :-)
> 
> From your breakdown, A and B are equivalent iff:
>  libva built with old_libdrm
>   and
>  libva built with new_libdrm
> are equivalent.
> 
> I believe this is true on the basis that libav doesn't do anything
> special if built against a newer libdrm. The final libav binaries should
> pretty much be identical.
> 
> James
> 

Hi James,

Sweet! :-)  Thank you for taking the time to clear up this point.  Can we 
depend on upstream updating libav/configure.ac if ever this changes?

Thank you,
Nicholas


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

[RFS] updated libva and intel-vaapi-driver bpos

[Nicholas D Steeves]

Hi!

I've updated the jessie-backports branches of libva and
intel-vaapi-driver, and have lightly tested the resulting packages.
Fast-forwarding seems a bit smoother, but that might be placebo effect
;-)

Please upload and tag these updated bpos.

Kind regards,
Nicholas


signature.asc
Description: Digital signature
___
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: [RFS] updated libva and intel-vaapi-driver bpos

[Nicholas D Steeves]

On Mon, Sep 12, 2016 at 06:43:07PM +, Mattia Rizzolo wrote:
> On Mon, Sep 12, 2016 at 06:41:25AM +, Mattia Rizzolo wrote:
> > Given that I gather intel-vaapi-driver needs the newer libva and today
> > I'm too lazy to copy .deb in the local repository I'll wait for libva to
> > reach the mirror before doing intel-vaapi-driver.
> 
> apparently amd64 is comparable to mipsel, as it's kinda lagging.
> https://buildd.debian.org/status/package.php?p=libva&suite=jessie-backports
> 
> I'm going to just trust you that it build and upload.
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Hi Mattia,

Thank you for the sponsored uploads!  Does "Needs-Build" status mean
that the package is still waiting for CPU time on an armel, armhf, and
mipsel system somewhere on the buildd network?

Cheers,
Nicholas


signature.asc
Description: Digital signature
___
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: [RFS] updated libva and intel-vaapi-driver bpos

[Nicholas D Steeves]

On Tue, Sep 13, 2016 at 09:08:38PM +, Mattia Rizzolo wrote:
> On Tue, Sep 13, 2016 at 05:03:23PM -0400, Nicholas D Steeves wrote:
> > Does "Needs-Build" status mean
> > that the package is still waiting for CPU time on an armel, armhf, and
> > mipsel system somewhere on the buildd network?
> 
> Yes, it's waiting for a spare buildd to pick up the builds.
> I don't know how the backports upload are considered in the build
> priority, but clearly not near the top¹..
> 
> 
> 
> ¹ e.g. I know that security builds are scheduled before anything else,
>   then stable, then unstable, then experimental; and that within a
>   single suite there are other things dictating priorities (like, new
>   packages are built after updated ones, even if the latter came after).
>   I just   don't know where backports is in that list.
> 
> -- 
> regards,
> Mattia Rizzolo

Thank you for the clarification!  Hm, I wonder if there aren't very
many mipsel build hosts, or if it's just that they're very slow?  If
the problem is that there aren't enough, I wonder if it would be
useful to write a wiki page linked to from "ways to contribute to
Debian" detailing the process of how to repurpose an old router as a
buildd host. ;-)

Cheers,
Nicholas


signature.asc
Description: Digital signature
___
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: Joining pkg-multimedia team

[Nicholas D Steeves]

On Fri, Sep 16, 2016 at 04:58:28PM +0200, Andreas Boll wrote:
> Hi,
> 
> my name is Andreas Boll, I'm a Debian Maintainer and I'd like to officially 
> become part of the Debian Multimedia Team.
> I'm also a member of the Debian X Strike Force where I co-maintain Mesa and 
> related packages.
> 
> I'm currently working on a backport of a newer version of Mesa and had to 
> backport some additional packages. One of these packages is vdpau-video. So 
> I'm maintaining the backport of vdpau-video for jessie-backports since 
> yesterday (Thanks mapreri for sponsoring!).

Hi Andreas,

It's good to hear from you!  Out of curiosity, are you participating
in the jessie+backports installer image effort? (IIRC, the "Jessie
half release" thread on -devel)

Cheers,
Nicholas


signature.asc
Description: Digital signature
___
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: Transitioning mplayer2 users to mpv

[Nicholas D Steeves]

On Wed, Oct 19, 2016 at 10:56:21PM +0100, James Cowgill wrote:
> Hi all,
> 
> Recently on IRC, uau suggested that instead of transitioning mplayer2
> users to mplayer, they should be transitioned to mpv instead. The
> reasons for this include: mpv being a fork of mplayer2 (thus retaining
> mplayer2 specific functionality), and mpv being much more actively
> developed than mplayer.
> 
> I happen to think this is a good idea. Does anyone have any opinions
> about it?
> 
> The plan would be:
> 
> Add an mplayer2 transitional package to mpv with an epoched version
> (probably 3:) and containing a symlink from mplayer to mpv.
> The package would need to conflict/replaces/provides mplayer, like
> mplayer2 did before it was removed. Then remove the old transitional
> package from mplayer and revert the old conflicts/replaces the package
> had. Once stretch is released, the mplayer2 package can be dropped.
> 
> James

I agree that this is a good idea!  Do you think this would need to be
documented in NEWS?  The reason I ask is that IIRC the command line
arguments use a different syntax and a silent transition could break
custom command aliases.  Also, it's nice to be made aware when the
location of configuration changes. (eg: ~/.mplayer | ~/.mplayer2 ->
~/.config/mpv)

The only regression I'm aware of is that at some point after I
transitioned to mpv, mpv broke and/or removed the bs2b (binaural
crossfeed audio filter for use with headphones).  Has anybody tested
compatibility with front-ends like gnome-mplayer or smplayer?

Cheers,
Nicholas


signature.asc
Description: Digital signature
___
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: mipsel buildd

[Nicholas D Steeves]

On Thu, Sep 15, 2016 at 09:22:37AM +0100, James Cowgill wrote:
> Hi,
> 
> On 15/09/16 01:15, Nicholas D Steeves wrote:
> > On Tue, Sep 13, 2016 at 09:08:38PM +, Mattia Rizzolo wrote:
> >> On Tue, Sep 13, 2016 at 05:03:23PM -0400, Nicholas D Steeves wrote:
> >>> Does "Needs-Build" status mean
> >>> that the package is still waiting for CPU time on an armel, armhf, and
> >>> mipsel system somewhere on the buildd network?
> >>
> >> Yes, it's waiting for a spare buildd to pick up the builds.
> >> I don't know how the backports upload are considered in the build
> >> priority, but clearly not near the top¹..
> >>
> >>
> >>
> >> ¹ e.g. I know that security builds are scheduled before anything else,
> >>   then stable, then unstable, then experimental; and that within a
> >>   single suite there are other things dictating priorities (like, new
> >>   packages are built after updated ones, even if the latter came after).
> >>   I just   don't know where backports is in that list.
> >>
> >> -- 
> >> regards,
> >> Mattia Rizzolo
> > 
> > Thank you for the clarification!  Hm, I wonder if there aren't very
> > many mipsel build hosts, or if it's just that they're very slow?  If
> > the problem is that there aren't enough, I wonder if it would be
> > useful to write a wiki page linked to from "ways to contribute to
> > Debian" detailing the process of how to repurpose an old router as a
> > buildd host. ;-)
> 
> At the moment there are more mipsel buildds than mips, but the mipsel
> buildds are also used for building mips64el so they can seem a bit slow
> at times as they have double the work to do. Extra hardware is always
> useful, but I'm not sure an old router would be anywhere near powerful
> enough to operate a buildd :)
> 
> Thanks,
> James
> 

Hi James,

Haha yeah, it would be more of a proof-of-concept than a practical
thing ;-) Out of curiousity, do you know if most mipsel buildd hosts
are running on old SGI gear, on those new "Warrior" boards, or on
something even more exotic and expensive?

Cheers,
Nicholas


signature.asc
Description: Digital signature
___
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: [RFS] updated libva and intel-vaapi-driver bpos

[Nicholas D Steeves]

On Tue, Sep 13, 2016 at 09:08:38PM +, Mattia Rizzolo wrote:
> On Tue, Sep 13, 2016 at 05:03:23PM -0400, Nicholas D Steeves wrote:
> > Does "Needs-Build" status mean
> > that the package is still waiting for CPU time on an armel, armhf, and
> > mipsel system somewhere on the buildd network?
> 
> Yes, it's waiting for a spare buildd to pick up the builds.
> I don't know how the backports upload are considered in the build
> priority, but clearly not near the top¹..
> 
> 
> 
> ¹ e.g. I know that security builds are scheduled before anything else,
>   then stable, then unstable, then experimental; and that within a
>   single suite there are other things dictating priorities (like, new
>   packages are built after updated ones, even if the latter came after).
>   I just   don't know where backports is in that list.
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Hi Mattia,

Thank you for sponsoring these uploads last time, and sorry this
thanks is arriving so late!

I have pushed updates.  Proof that they build is here:
https://mentors.debian.net/package/libva
https://mentors.debian.net/package/intel-vaapi-driver

I'm not sure what version of libva mentors builds intel-vaapi-driver
against, but it seems to have worked.  When I built them locally I
built libva first, and copied the debs to my local repo.  The clean
jessie pbuilder I use to build these intel-vaapi-driver then pulls in
whatever version it needs.

Do you think the mipsel delays from the last run can be used to
predict $DELAY for an upload of intel-vaapi-driver to deferred/$DELAY?
The libva version I've requested migrates to testing tomorrow,
assuming no bugs are reported in the next however many of hours :-)

Thank you again for your continued support.
Sincerely,
Nicholas


signature.asc
Description: Digital signature
___
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: [RFS] updated libva and intel-vaapi-driver bpos

[Nicholas D Steeves]

On Tue, Nov 22, 2016 at 03:23:27AM +0100, Mattia Rizzolo wrote:
> On Mon, Nov 21, 2016 at 07:31:10PM -0500, Nicholas D Steeves wrote:
> > Proof that they build is here:
> > https://mentors.debian.net/package/libva
> > https://mentors.debian.net/package/intel-vaapi-driver
> 
> bah, no need for mentors (for me at least); I'm very happy to just use
> the git repository.
> 
> > I'm not sure what version of libva mentors builds intel-vaapi-driver
> > against, but it seems to have worked.
> 
> ?
> mentors.d.n doesn't build anything.  What do you mean by that?

Oh!  I've been assuming that the delay between when a package is
uploaded to mentors.d.n and the time it appears under "My Packages"
was because mentors was building the package...  Either way, I won't
bother using mentors.d.n for future bpos of these packages.

> > When I built them locally I
> > built libva first, and copied the debs to my local repo.  The clean
> > jessie pbuilder I use to build these intel-vaapi-driver then pulls in
> > whatever version it needs.
> 
> Yeah, well, the build-dep is very clear on the need of 1.7.3 of libva :)
> In this case I usually test build locally by using the local repo, but
> then upload source only and the have the buildd figure what to do (they
> will not try the build until the needed libva is available).

Oh good, I wasn't sure about this :-)

> > Do you think the mipsel delays from the last run can be used to
> > predict $DELAY for an upload of intel-vaapi-driver to deferred/$DELAY?
> 
> umh, not sure what you mean here?
> Why would we need to do anything to wait for mipsel?

My bad, it skipped my mind that intel-vaapi-driver only builds for
amd64 and i386!

> > The libva version I've requested migrates to testing tomorrow,
> > assuming no bugs are reported in the next however many of hours :-)
> 
> yeah, I'll wait for that to happen before looking at these anyway :P
> I want everything but backports-master chasing after me, that wouldn't
> be nice (also because I saw how bad that could be...).

Sounds good!

Thanks again,
Nicholas


signature.asc
Description: Digital signature
___
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: mipsel buildd

[Nicholas D Steeves]

On Tue, Nov 22, 2016 at 09:51:33AM +, James Cowgill wrote:
> Hi,
> 
> On 22/11/16 00:17, Nicholas D Steeves wrote:
> > On Thu, Sep 15, 2016 at 09:22:37AM +0100, James Cowgill wrote:
> >> On 15/09/16 01:15, Nicholas D Steeves wrote:
> >>> Thank you for the clarification!  Hm, I wonder if there aren't very
> >>> many mipsel build hosts, or if it's just that they're very slow?  If
> >>> the problem is that there aren't enough, I wonder if it would be
> >>> useful to write a wiki page linked to from "ways to contribute to
> >>> Debian" detailing the process of how to repurpose an old router as a
> >>> buildd host. ;-)
> >>
> >> At the moment there are more mipsel buildds than mips, but the mipsel
> >> buildds are also used for building mips64el so they can seem a bit slow
> >> at times as they have double the work to do. Extra hardware is always
> >> useful, but I'm not sure an old router would be anywhere near powerful
> >> enough to operate a buildd :)
> >
> > Haha yeah, it would be more of a proof-of-concept than a practical
> > thing ;-) Out of curiousity, do you know if most mipsel buildd hosts
> > are running on old SGI gear, on those new "Warrior" boards, or on
> > something even more exotic and expensive?
> 
> There's a list here:
> https://wiki.debian.org/MIPSPort#Build_daemons_.26_porter_boxes
> 
> Most of them are Cavium Octeon based boards except for a few Loongson
> 3As. A lot of the really old SGI stuff won't actually run stretch.

Wow, I've never heard of Octeon before, though Loongson is familiar.

Thanks James!
Nick


signature.asc
Description: Digital signature
___
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: [RFS] updated libva and intel-vaapi-driver bpos

[Nicholas D Steeves]

On Tue, Nov 22, 2016 at 10:07:18PM +0100, Mattia Rizzolo wrote:
> On Mon, Nov 21, 2016 at 10:36:13PM -0500, Nicholas D Steeves wrote:
> > > > The libva version I've requested migrates to testing tomorrow,
> > > > assuming no bugs are reported in the next however many of hours :-)
> > > 
> > > yeah, I'll wait for that to happen before looking at these anyway :P
> > > I want everything but backports-master chasing after me, that wouldn't
> > > be nice (also because I saw how bad that could be...).
> > 
> > Sounds good!
> 
> And uploaded both :)
> I've actually first uploaded libva this morning, and now, after 2
> dinstalls, the built packages reached my mirror and I could build
> intel-vaapi-driver using them ;)

Wow Mattia!

Thank you for uploading these so quickly :-D

Cheers,
Nicholas

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers