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

2016-05-20 Thread 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
> git status
> git add  # same as above
> git push # push the current branch
> git push --tags   # push the tag

The tag happens before git add, thus necessarily before the commit.
>From my experiments, it seems like

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

2016-05-10 Thread Mattia Rizzolo 
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.

> Had I made my mistake at this
> point, it seems like it would have been a huge mess!

I see it's easy to do something wrong by accident here ;)

> > 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.

> 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.

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

Sorry for making this actually simple backport look like a huge
complicated deal :)

-- 
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  `-


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

2016-05-10 Thread 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

2016-05-10 Thread 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: 
>>

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

2016-05-10 Thread Mattia Rizzolo 
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 ;)

-- 
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  `-


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

2016-05-10 Thread Mattia Rizzolo 
Sorry for the delay, these days are crazy for me

On Fri, May 06, 2016 at 02:05:17PM -0400, Nicholas D Steeves wrote:
> 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.

Nevermind, happens :)
FTR, I tend to clean up my local repository as soon as I'm done with
that build, as way too often happens to leave something there to me.

> 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.


> Message-ID: 
>

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

2016-05-06 Thread 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

2016-05-06 Thread 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:

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

2016-05-06 Thread Mattia Rizzolo 
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.
> 
> https://mentors.debian.net/package/audacious-plugins
> https://mentors.debian.net/package/audacious

I tried now the very packages you uploaded there, and failed the same.
Some things:

root@chase:/build/audacious-plugins-3.7.2# ls
/usr/include/libroar/libroar.h
/usr/include/libroar/libroar.h
root@chase:/build/audacious-plugins-3.7.2# dpkg -S
/usr/include/libroar/libroar.h libroar-dev: /usr/include/libroar/libroar.h
root@chase:/build/audacious-plugins-3.7.2# aptitude why libroar-dev
i   pbuilder-satisfydepends-dummy Depends  libsndio-dev
i A libroar-dev   Provides libsndio-dev


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.

-- 
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  `-


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

2016-05-04 Thread 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

2016-05-04 Thread 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 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

2016-05-04 Thread 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

2016-05-03 Thread Mattia Rizzolo 
On Mon, May 02, 2016 at 08:50:55AM +, Mattia Rizzolo wrote:
> I'll go ahead and built 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.

-- 
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  `-


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

2016-05-02 Thread Mattia Rizzolo 
On Mon, May 02, 2016 at 09:34:05AM +0200, Mateusz Łukasik wrote:
> The best way is creating jessie branch and prepare backport there.

jessie-backports, no 'jessie', please (I renamed the branches already).
The 'jessie' branch should be used for eventual stable updates.

I saw you also renamed the tags.  Well, thanks.


I'll go ahead and built later.

-- 
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  `-


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

2016-05-02 Thread Mateusz Łukasik 

On 02.05.2016 02:06 +0200, Nicholas D Steeves wrote:

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".




I will fix that.

The best way is creating jessie branch and prepare backport there.

--
 .''`.  Mateusz Łukasik
: :' :  http://mati75.eu
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

___
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

2016-05-01 Thread 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

2016-04-29 Thread Mattia Rizzolo 
On Fri, Apr 29, 2016 at 07:55:29PM -0400, Nicholas D Steeves wrote:
> > 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!

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?)

> 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

That would be mostly about undoing a particular change in a file in a
subsequent commit.

My question before was mostly aimed to the others members of the team,
to know whether they like destroying history or not.
In the first case a `git reset --hard 7c8a90` and `git push --force`
(note that this might require more work, as non-fast-forward pushes are
not usually allowed by the remote repos on alioth) should be enough.
In the second, a `git revert a6274ea` will create another commit
reverting the changes done after that commit specified, and pushed so.

Just saying (as I'd like to hear from somebody else), if the first was
done without deleting the tag, such tag would be the way I prefer them
to be when dealing with backports :)

> 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.

-- 
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  `-


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

2016-04-29 Thread 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

2016-04-29 Thread Mattia Rizzolo 
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 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.

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.

-- 
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  `-


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

2016-04-29 Thread 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

2016-04-28 Thread Mattia Rizzolo 
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.

It's appropriated here, yep :)
Though, even if I routinely processes RFSes from the
request-sponsorships pseudopackage, I usually just ignore RFS emails to
random mailing lists unless i can do them right now.  So, for what
relates to me, I just skipped this.  Though, there are several other
people who can do it.
Sebastians pinged me earlier to have a look at this :)

> 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 :)

-- 
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  `-


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

2016-04-07 Thread 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

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

2016-04-07 Thread 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