Re: Help offered with xwax package

[James Cowgill]

On 31/08/16 15:40, Daniel James wrote:
> Hi James,
> 
>> Please mention that you added yourself to
>> the list of uploaders in the changelog, then run dch -r, and then I'll
>> upload it for you.
> 
> Thanks! That's done:
> https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/commit/?id=19a0c911580a23b3aeefd446408cac3695f00516

Uploaded!

James



signature.asc
Description: OpenPGP 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: Help offered with xwax package

[Daniel James]

Hi James,

> Please mention that you added yourself to
> the list of uploaders in the changelog, then run dch -r, and then I'll
> upload it for you.

Thanks! That's done:
https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/commit/?id=19a0c911580a23b3aeefd446408cac3695f00516

Cheers!

Daniel

___
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: Help offered with xwax package

[James Cowgill]

Hi,

On 16/08/16 11:05, Daniel James wrote:
> Hi Jaromír,
> 
>> 1. Bump of standards version
>> 3. Use cgit for  Vcs-Browser would be probably better.
>> 4. Is d/dir file needed ?
> 
> Thanks for the review! I have pushed the above changes in
> https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/commit/?id=b26871620a6f5187d73907a684774477324f0045
> 
>> 2. Fix of hardening
> 
> As this is a real-time audio application, should hardening be applied if
> it has a performance penalty? Does it offer any genuine security
> advantage for a desktop application?
> 
> https://lintian.debian.org/tags/hardening-no-pie.html says "PIE has been
> associated with noticeable performance overhead on i386. However, GCC-5
> has implemented an optimization that can reduce the overhead
> significantly."

bindnow has no runtime performance impact (a slight increase in startup
time).

pie has minimal performance impact on arches which support pc-relative
addressing (eg x86_64), but yes it does impact performance on old gcc
versions with i386.

IMO you should enable them unless the performance reduction is
noticeable. Being a desktop application doesn't mean there are no
security concerns. A security bug can still compromise files owned by
the user running the application.

> As jessie provides gcc 4.9.2 and my aim is to provide a backport, it
> seems like there could be a performance hit.
> 
>> 5. Is parallel build now default or should be enabled?
> 
> The debian/rules file is very customised, I don't see any parallel build
> options used there at the moment.

Parallel is only the default in debhelper 10 which is experimental. You
should enable it manually for the moment.

>> 6. I would add d/source/local-options file
> 
> Is this file still needed even when the upstream source is no longer
> patched? The previous patch supporting avconv was now merged upstream.

local-options used to be useful when working with gbp, but now that the
defaults for dpkg-source have been changed (abort-on-upstream-changes is
now on by default, patches are unapplied automatically) it's now fairly
useless.

James



signature.asc
Description: OpenPGP 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: Help offered with xwax package

[Daniel James]

Hi Jaromír,

> 1. Bump of standards version
> 3. Use cgit for  Vcs-Browser would be probably better.
> 4. Is d/dir file needed ?

Thanks for the review! I have pushed the above changes in
https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/commit/?id=b26871620a6f5187d73907a684774477324f0045

> 2. Fix of hardening

As this is a real-time audio application, should hardening be applied if
it has a performance penalty? Does it offer any genuine security
advantage for a desktop application?

https://lintian.debian.org/tags/hardening-no-pie.html says "PIE has been
associated with noticeable performance overhead on i386. However, GCC-5
has implemented an optimization that can reduce the overhead
significantly."

As jessie provides gcc 4.9.2 and my aim is to provide a backport, it
seems like there could be a performance hit.

> 5. Is parallel build now default or should be enabled?

The debian/rules file is very customised, I don't see any parallel build
options used there at the moment.

> 6. I would add d/source/local-options file

Is this file still needed even when the upstream source is no longer
patched? The previous patch supporting avconv was now merged upstream.

Cheers!

Daniel

___
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: Help offered with xwax package

[Jaromír Mikeš]

2016-08-15 13:58 GMT+02:00 Daniel James :

Hi Daniel,

>> Or maybe the best ... asking upstream if he could name his releases
>> with ~ as - breaking our automatic system for watching new releases.
>
> I talked to the upstream author, he had not intended beta releases to be
> packaged by downstream distros.
>
> Anyway, the patch from Debian has been merged upstream and a 1.6 final
> release was made. I have imported these sources and removed the patch.
>
> Please could someone from the pkg-multimedia team review the package for
> release?
>
> https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/
>
> I have built it locally on jessie amd64 in a pbuilder-dist chroot and it
> seems fine.

$ lintian -IE --pedantic /home/mira/PACKAGING/xwax_1.6-1_amd64.changes
W: xwax source: out-of-date-standards-version 3.9.6 (current is 3.9.8)
P: xwax source: debian-watch-may-check-gpg-signature
I: xwax: hardening-no-pie usr/bin/xwax
I: xwax: hardening-no-bindnow usr/bin/xwax

1. Bump of standards version
2. Fix of hardening
3. Use cgit for  Vcs-Browser would be probably better.

best

mira

___
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: Help offered with xwax package

[Daniel James]

Hi Jaromír, hi all,

> Or maybe the best ... asking upstream if he could name his releases
> with ~ as - breaking our automatic system for watching new releases.

I talked to the upstream author, he had not intended beta releases to be
packaged by downstream distros.

Anyway, the patch from Debian has been merged upstream and a 1.6 final
release was made. I have imported these sources and removed the patch.

Please could someone from the pkg-multimedia team review the package for
release?

https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/

I have built it locally on jessie amd64 in a pbuilder-dist chroot and it
seems fine.

Thanks!

Daniel

___
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: .gitignore (was Re: Help offered with xwax package)

[Ross Gammon]

On 08/11/2016 10:43 AM, IOhannes m zmölnig (Debian/GNU) wrote:
> - suggest (in [3] to use a postclone hook that ignores Debian-toolchain
> artefacts via .git/info/exclude
> even better would be to nag the developers of gbp to automatically
> ignore /.pc/ if the source-format is "3.0 quilt"  (i've already done
> that [4], but it seems that with the advent of postclone hooks they
> think this is none-of-their-business).

This is my favourite. Since my first few gitignore merge hiccups, I have
always used "gbp-configure-unpatched-source" manually the first time I
patch a package. A postclone hook is a good idea.



signature.asc
Description: OpenPGP 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: .gitignore (was Re: Help offered with xwax package)

[Jonas Smedegaard]

Quoting Jaromír Mikeš (2016-08-12 16:29:03)
> "Files-Excluded stanza in d/copyright *without* warranting a "~repack" 
> suffix" seam to be easiest and totally acceptable for me.

Purpose of Files-Excluded in debian/copyright is to indicate files that 
has been removed in our redistribution by repacking upstream source.

Therefore I do not follow what you mean by emphasizing not repacking.  
What would be the point of telling something has been removed without 
then actually removing?


> Of course if git-import-orig would ignore upstream .gitignore file it
> would be even better.

This content in debian/gbp.conf ignores all .git files anywhere:

[DEFAULT]
filter = */.git*


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: 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: .gitignore (was Re: Help offered with xwax package)

[Jaromír Mikeš]

2016-08-11 10:43 GMT+02:00 IOhannes m zmölnig (Debian/GNU)
:

Hi IOhannes and others,

> - add ".gitignore" to the Files-Excluded stanza in d/copyright *without*
> warranting a "~repack" suffix in the version (i guess this is justified,
> since dpkg-source ignores the file anyhow).
> even better would be to nag the developers of gbp to just not include
> this file on import-orig (i'm not sure about the prospects of this
> suggestion though).
> - suggest (in [3] to use a postclone hook that ignores Debian-toolchain
> artefacts via .git/info/exclude
> even better would be to nag the developers of gbp to automatically
> ignore /.pc/ if the source-format is "3.0 quilt"  (i've already done
> that [4], but it seems that with the advent of postclone hooks they
> think this is none-of-their-business).
>
> what do others think*?

to simplify work with upstream .gitignore file would by very welcome.
In many cases is only reason for repacking.
I'm not sure which approach is technically best,
but "Files-Excluded stanza in d/copyright *without* warranting a
"~repack" suffix"
seam to be easiest and totally acceptable for me.
Of course if git-import-orig would ignore upstream .gitignore file it
would be even better.

best regards

mira

___
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: .gitignore (was Re: Help offered with xwax package)

[Jonas Smedegaard]

Quoting IOhannes m zmölnig (Debian/GNU) (2016-08-11 10:43:55)
> On 2016-08-10 11:52, James Cowgill wrote:
> >> Actually we should repack ( to get rid of upstream .gitignore file and
> >> > use our .gitignore file ) and rename.
> > You don't actually need to do that (and arguably you should not repack
> > orig tarballs unless you need to). For source format "3.0 (quilt)",
> > dpkg-source contains a set of regexes for files which are automatically
> > ignored when generating the final source package. .gitignore (and .git/)
> > are on the list so any changes you make to upstream's .gitignore are
> > completely ignored by dpkg-source.
> 
> i was wanting to ask about best practices regarding .gitignore for some
> time.
> 
> when packaging, i have two "problems" with .gitignore
> 
> #1 upstream includes a .gitignore
> having an upstream .gitignore field usually just creates trouble as it
> (mostly) hides stray artefacts lying around until dpkg-source comes and
> complains. i really think that gitignore's main purpose is exactly this
> hiding of build artefacts, but it mainly causes trouble when it comes to
> Debian's build chain.
> with my Debian hat on, i would like to get rid of all upstream
> .gitignore files, ideally *automatically* (to catch all those gitignores
> in subdirectories...)
> with my upstream hat on, i desparately need .gitignore though...
> 
> a "solution" which i often find applied (by myself, and others like
> mira) is to just strip away the .gitignore file, when repacking the
> sources (though afaik this is only done when the sources are repackaged
> anyhow)

Here's my understanding:

.git* files are not really project data but packaging data. When 
repackaging we should always throw away old packaging (meta)data, and 
may add new packaging (meta)data.

 * If upstream includes debian/* files, throw it away.
 * If upstream includes .git* or .svn* or .cvs* files, throw it away.

 * For a git containment, add .git* files as needed.
 * For a .deb package, add debian/* files as needed.

If lazy then you can skip cleanup of old containment files when not in 
the way of your own new containment, but lintian will rightfully warn if 
you ship a package with VCS files, because ideally you should care not 
only about your own needs but also downstream needs.


> #2 ignoring Debian toolchain artefacts
> most packages use "3.0 quilt", which I (unlike many others) have no
> problems with.
> unfortunately, using quilt results in a .pc/ directory in the project
> root, something that gbp will loudly complain about.
> 
> the most common "solution" is to add .pc/ to .gitignore

That's no different from any other containment, I believe.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: 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: .gitignore (was Re: Help offered with xwax package)

[Felipe Sateler]

On 11 August 2016 at 04:43, IOhannes m zmölnig (Debian/GNU)
 wrote:
> On 2016-08-10 11:52, James Cowgill wrote:
>>> Actually we should repack ( to get rid of upstream .gitignore file and
>>> > use our .gitignore file ) and rename.
>> You don't actually need to do that (and arguably you should not repack
>> orig tarballs unless you need to). For source format "3.0 (quilt)",
>> dpkg-source contains a set of regexes for files which are automatically
>> ignored when generating the final source package. .gitignore (and .git/)
>> are on the list so any changes you make to upstream's .gitignore are
>> completely ignored by dpkg-source.
>
> i was wanting to ask about best practices regarding .gitignore for some
> time.
>
> when packaging, i have two "problems" with .gitignore
>
> #1 upstream includes a .gitignore
> having an upstream .gitignore field usually just creates trouble as it
> (mostly) hides stray artefacts lying around until dpkg-source comes and
> complains. i really think that gitignore's main purpose is exactly this
> hiding of build artefacts, but it mainly causes trouble when it comes to
> Debian's build chain.
> with my Debian hat on, i would like to get rid of all upstream
> .gitignore files, ideally *automatically* (to catch all those gitignores
> in subdirectories...)
> with my upstream hat on, i desparately need .gitignore though...

I am less annoyed by this because I have set export-dir set in my
~/.gbp.conf. Thus gbp builds never happen in the git tree, and thus
never contain the build artifacts.

>
> a "solution" which i often find applied (by myself, and others like
> mira) is to just strip away the .gitignore file, when repacking the
> sources (though afaik this is only done when the sources are repackaged
> anyhow)
>
> #2 ignoring Debian toolchain artefacts
> most packages use "3.0 quilt", which I (unlike many others) have no
> problems with.
> unfortunately, using quilt results in a .pc/ directory in the project
> root, something that gbp will loudly complain about.
>
> the most common "solution" is to add .pc/ to .gitignore

I have lately been migrating to gbp pq instead of quilt to manage the
patches. In addition to allowing easier workflows for eg, rebasing on
new upstream versions, this nicely sidesteps the issue of the .pc dir.
Paired with the use of export-dir, this results in the .pc dir never
existing in my local worktree.



-- 

Saludos,
Felipe Sateler

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

.gitignore (was Re: Help offered with xwax package)

[Debian/GNU]

On 2016-08-10 11:52, James Cowgill wrote:
>> Actually we should repack ( to get rid of upstream .gitignore file and
>> > use our .gitignore file ) and rename.
> You don't actually need to do that (and arguably you should not repack
> orig tarballs unless you need to). For source format "3.0 (quilt)",
> dpkg-source contains a set of regexes for files which are automatically
> ignored when generating the final source package. .gitignore (and .git/)
> are on the list so any changes you make to upstream's .gitignore are
> completely ignored by dpkg-source.

i was wanting to ask about best practices regarding .gitignore for some
time.

when packaging, i have two "problems" with .gitignore

#1 upstream includes a .gitignore
having an upstream .gitignore field usually just creates trouble as it
(mostly) hides stray artefacts lying around until dpkg-source comes and
complains. i really think that gitignore's main purpose is exactly this
hiding of build artefacts, but it mainly causes trouble when it comes to
Debian's build chain.
with my Debian hat on, i would like to get rid of all upstream
.gitignore files, ideally *automatically* (to catch all those gitignores
in subdirectories...)
with my upstream hat on, i desparately need .gitignore though...

a "solution" which i often find applied (by myself, and others like
mira) is to just strip away the .gitignore file, when repacking the
sources (though afaik this is only done when the sources are repackaged
anyhow)

#2 ignoring Debian toolchain artefacts
most packages use "3.0 quilt", which I (unlike many others) have no
problems with.
unfortunately, using quilt results in a .pc/ directory in the project
root, something that gbp will loudly complain about.

the most common "solution" is to add .pc/ to .gitignore



now my problem is, that i heartily dislike both of these solutions.
the two reasons if found for my dislike are:
- they modify files outside of debian/, which i think is a no-go (where
does it end?), or at least ugly as hell.
- they add cruft to each and every package to solve a common problem.

i have (very unsystematically) tried to solve this problem in a more
central manner over the last few years, the idea being that this can
either be solved in the toolchain involved (gbp) and/or via some local
configuration on my computer that applies to "all Debian repositories".

for #1, i came up with something along the lines of [1], which basically
just ignores .gitignore on a per-repo basis (configured via `git config`)
in a way it works, but has some unwanted side-effects (like a no-longer
working tab-completion for git)

for #2 i was happy to see that recent versions of gbp (currently in
experimental) sport a postclone hook [2], which can be used to run
various repository tasks right after cloning.
i now use this to gitignore "/.pc/" via .git/info/exclude (not touching
the .gitignore file).

unfortunately the two proposals clash (ignoring .gitignore really means
ignoring all gitignore(5) files, including .git/info/exclude).


so i'm not sure about a proper "best practice" to deal with this.
i could imagine something like:

- add ".gitignore" to the Files-Excluded stanza in d/copyright *without*
warranting a "~repack" suffix in the version (i guess this is justified,
since dpkg-source ignores the file anyhow).
even better would be to nag the developers of gbp to just not include
this file on import-orig (i'm not sure about the prospects of this
suggestion though).
- suggest (in [3] to use a postclone hook that ignores Debian-toolchain
artefacts via .git/info/exclude
even better would be to nag the developers of gbp to automatically
ignore /.pc/ if the source-format is "3.0 quilt"  (i've already done
that [4], but it seems that with the advent of postclone hooks they
think this is none-of-their-business).

what do others think*?

fgmasdr
IOhannes



[1] http://stackoverflow.com/questions/25909293
[2] https://bugs.debian.org/812816
[3] https://wiki.debian.org/DebianMultimedia/DevelopPackaging
[4] https://bugs.debian.org/812815

* apart from "don't you have other problems?"

___
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: Help offered with xwax package

[Debian/GNU]

On 2016-08-10 12:00, Jaromír Mikeš wrote:
>>> >> $ uscan --report-status
>>> >> Processing watchfile line for package xwax...
>>> >> Newest version on remote site is 1.6-beta2, local version is 1.6~beta2
>>> >> xwax: Newer version (1.6-beta2) available on remote site:
>>> >>   https://github.com/xwax/xwax/archive/1.6-beta2.zip
>>> >>   (local version is 1.6~beta2)
>> >
>> > Yes that's the reason we have to rename 1.6- to 1.6~ because 1.6-beta2
>> > would later considered higher version then 1.6 but 1.6~beta2 lower.
[...]
>> > But not sure how to nicely - to ~ ... :(
>> >
>> > Maybe someone else?
> Or maybe the best ... asking upstream if he could name his releases
> with ~ as - breaking our automatic system for watching new releases.
> 

io think this should be handled with proper versionmangling in d/watch

fgmasdr
IOhannes

___
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: Help offered with xwax package

[Daniel James]

Hi Jaromír, hi James,

> Or maybe the best ... asking upstream if he could name his releases
> with ~ as - breaking our automatic system for watching new releases.

I don't think that's very likely in this case, as the 1.6-beta2 tag was
made a while ago. It might be better to handle this discrepancy at the
Debian end.

I'd appreciate any help with getting this package uploaded correctly.

Cheers!

Daniel

___
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: Help offered with xwax package

[Jaromír Mikeš]

2016-08-10 11:40 GMT+02:00 Jaromír Mikeš :
> 2016-08-10 10:55 GMT+02:00 Daniel James :
>> Hi Jaromír,
>>
 looks like named orig source as 1.6-beta2-1 instead of 1.6~beta2-1
 > (-/~) which cause problem when building with --pristine-tar
>>
>> Yes, that was probably my fault, the upstream release name is 1.6-beta2.
>>
>>> How did you get orig tarball? ... I guess that you download it
>>> manually because watch file showing 1.5 release as latest release.
>>
>> I archived it from a local clone of https://github.com/xwax/xwax/ but on
>> http://xwax.org/download.html version 1.5 is shown as the latest.
>>
>> The beta cycle is very long for xwax, so it makes sense that Debian
>> packaged the beta1 release already.
>>
>>> Let's fix watch file first to new location of releases.
>>
>> I've done that in:
>>
>> https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/commit/?id=ee27698b3abfed1810e0a245d687d7f9e021bfa1
>>
>>> Than $ uscan --debug --force-download should give you latest release
>>> automatically.
>>
>> uscan works, but there is a slight discrepancy because of the tilde in
>> the Debian version:
>>
>> $ uscan --report-status
>> Processing watchfile line for package xwax...
>> Newest version on remote site is 1.6-beta2, local version is 1.6~beta2
>> xwax: Newer version (1.6-beta2) available on remote site:
>>   https://github.com/xwax/xwax/archive/1.6-beta2.zip
>>   (local version is 1.6~beta2)
>
> Yes that's the reason we have to rename 1.6- to 1.6~ because 1.6-beta2
> would later considered higher version then 1.6 but 1.6~beta2 lower.
> Actually we should repack ( to get rid of upstream .gitignore file and
> use our .gitignore file ) and rename.
>
> For repacking I would use get-orig-source
> As example you can use rules file from eq10q package
> https://anonscm.debian.org/cgit/pkg-multimedia/eq10q.git/tree/debian/rules
> But not sure how to nicely - to ~ ... :(
>
> Maybe someone else?

Or maybe the best ... asking upstream if he could name his releases
with ~ as - breaking our automatic system for watching new releases.

mira

___
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: Help offered with xwax package

[James Cowgill]

Hi,

On 10/08/16 10:40, Jaromír Mikeš wrote:
> 2016-08-10 10:55 GMT+02:00 Daniel James :
>> uscan works, but there is a slight discrepancy because of the tilde in
>> the Debian version:
>>
>> $ uscan --report-status
>> Processing watchfile line for package xwax...
>> Newest version on remote site is 1.6-beta2, local version is 1.6~beta2
>> xwax: Newer version (1.6-beta2) available on remote site:
>>   https://github.com/xwax/xwax/archive/1.6-beta2.zip
>>   (local version is 1.6~beta2)
> 
> Yes that's the reason we have to rename 1.6- to 1.6~ because 1.6-beta2
> would later considered higher version then 1.6 but 1.6~beta2 lower.
> Actually we should repack ( to get rid of upstream .gitignore file and
> use our .gitignore file ) and rename.

You don't actually need to do that (and arguably you should not repack
orig tarballs unless you need to). For source format "3.0 (quilt)",
dpkg-source contains a set of regexes for files which are automatically
ignored when generating the final source package. .gitignore (and .git/)
are on the list so any changes you make to upstream's .gitignore are
completely ignored by dpkg-source.

The exact list can be found near the top of this file:
/usr/share/perl5/Dpkg/Source/Package.pm

James



signature.asc
Description: OpenPGP 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: Help offered with xwax package

[Jaromír Mikeš]

2016-08-10 10:55 GMT+02:00 Daniel James :
> Hi Jaromír,
>
>>> looks like named orig source as 1.6-beta2-1 instead of 1.6~beta2-1
>>> > (-/~) which cause problem when building with --pristine-tar
>
> Yes, that was probably my fault, the upstream release name is 1.6-beta2.
>
>> How did you get orig tarball? ... I guess that you download it
>> manually because watch file showing 1.5 release as latest release.
>
> I archived it from a local clone of https://github.com/xwax/xwax/ but on
> http://xwax.org/download.html version 1.5 is shown as the latest.
>
> The beta cycle is very long for xwax, so it makes sense that Debian
> packaged the beta1 release already.
>
>> Let's fix watch file first to new location of releases.
>
> I've done that in:
>
> https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/commit/?id=ee27698b3abfed1810e0a245d687d7f9e021bfa1
>
>> Than $ uscan --debug --force-download should give you latest release
>> automatically.
>
> uscan works, but there is a slight discrepancy because of the tilde in
> the Debian version:
>
> $ uscan --report-status
> Processing watchfile line for package xwax...
> Newest version on remote site is 1.6-beta2, local version is 1.6~beta2
> xwax: Newer version (1.6-beta2) available on remote site:
>   https://github.com/xwax/xwax/archive/1.6-beta2.zip
>   (local version is 1.6~beta2)

Yes that's the reason we have to rename 1.6- to 1.6~ because 1.6-beta2
would later considered higher version then 1.6 but 1.6~beta2 lower.
Actually we should repack ( to get rid of upstream .gitignore file and
use our .gitignore file ) and rename.

For repacking I would use get-orig-source
As example you can use rules file from eq10q package
https://anonscm.debian.org/cgit/pkg-multimedia/eq10q.git/tree/debian/rules
But not sure how to nicely - to ~ ... :(

Maybe someone else?

mira

___
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: Help offered with xwax package

[Daniel James]

Hi Jaromír,

>> looks like named orig source as 1.6-beta2-1 instead of 1.6~beta2-1
>> > (-/~) which cause problem when building with --pristine-tar

Yes, that was probably my fault, the upstream release name is 1.6-beta2.

> How did you get orig tarball? ... I guess that you download it
> manually because watch file showing 1.5 release as latest release.

I archived it from a local clone of https://github.com/xwax/xwax/ but on
http://xwax.org/download.html version 1.5 is shown as the latest.

The beta cycle is very long for xwax, so it makes sense that Debian
packaged the beta1 release already.

> Let's fix watch file first to new location of releases.

I've done that in:

https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/commit/?id=ee27698b3abfed1810e0a245d687d7f9e021bfa1

> Than $ uscan --debug --force-download should give you latest release
> automatically.

uscan works, but there is a slight discrepancy because of the tilde in
the Debian version:

$ uscan --report-status
Processing watchfile line for package xwax...
Newest version on remote site is 1.6-beta2, local version is 1.6~beta2
xwax: Newer version (1.6-beta2) available on remote site:
  https://github.com/xwax/xwax/archive/1.6-beta2.zip
  (local version is 1.6~beta2)

Cheers!

Daniel

___
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: Help offered with xwax package

[Jaromír Mikeš]

2016-08-09 21:36 GMT+02:00 Jaromír Mikeš :
> 2016-08-09 21:22 GMT+02:00 Jaromír Mikeš :
>> 2016-08-09 11:27 GMT+02:00 Daniel James :
>>
>> Hi Daniel,
>>
 Welcome on board ;)
>>>
>>> Thanks! I have pushed some updates to
>>> https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/ which are ready
>>> for review. I did not push a debian/1.6_beta2* tag yet.
>>
>> That's right debian tag should be pushed after uploading.
>>
>>> I have built the updated package in a clean jessie amd64 chroot using
>>> pubuilder-dist, and it installed and worked fine on my jessie system.
>>> Test .deb packages for amd64 and armhf are available here:
>>> https://github.com/danielhjames/xwax-debs/tree/master/jessie
>>>
>>> The upstream git repo still includes a file called .version in the root
>>> directory but it is listed in .gitignore there, so when I created the
>>> archive of the new upstream version I think this file was left out:
>>>
>>> git archive 1.6-beta2|gzip > ../xwax-1.6~beta2-orig.tar.gz>
>>> Cheers!
>>
>> I am usually get rig of upstream files like .gitignore .version by
>> repacking source
>>
>>> I don't think this .version file is used by Debian in any way, so I'm
>>> just mentioning it for the sake of completeness.
>>
>> I didn't over viewed your packaging yet ... just going to do it.
>
> I looks like named orig source as 1.6-beta2-1 instead of 1.6~beta2-1
> (-/~) which cause problem when building with --pristine-tar

How did you get orig tarball? ... I guess that you download it
manually because watch file showing 1.5 release as latest release.
Let's fix watch file first to new location of releases.
Than $ uscan --debug --force-download should give you latest release
automatically.

mira

___
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: Help offered with xwax package

[Jaromír Mikeš]

2016-08-09 21:22 GMT+02:00 Jaromír Mikeš :
> 2016-08-09 11:27 GMT+02:00 Daniel James :
>
> Hi Daniel,
>
>>> Welcome on board ;)
>>
>> Thanks! I have pushed some updates to
>> https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/ which are ready
>> for review. I did not push a debian/1.6_beta2* tag yet.
>
> That's right debian tag should be pushed after uploading.
>
>> I have built the updated package in a clean jessie amd64 chroot using
>> pubuilder-dist, and it installed and worked fine on my jessie system.
>> Test .deb packages for amd64 and armhf are available here:
>> https://github.com/danielhjames/xwax-debs/tree/master/jessie
>>
>> The upstream git repo still includes a file called .version in the root
>> directory but it is listed in .gitignore there, so when I created the
>> archive of the new upstream version I think this file was left out:
>>
>> git archive 1.6-beta2|gzip > ../xwax-1.6~beta2-orig.tar.gz>
>> Cheers!
>
> I am usually get rig of upstream files like .gitignore .version by
> repacking source
>
>> I don't think this .version file is used by Debian in any way, so I'm
>> just mentioning it for the sake of completeness.
>
> I didn't over viewed your packaging yet ... just going to do it.

I looks like named orig source as 1.6-beta2-1 instead of 1.6~beta2-1
(-/~) which cause problem when building with --pristine-tar

mira

___
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: Help offered with xwax package

[Jaromír Mikeš]

2016-08-09 11:27 GMT+02:00 Daniel James :

Hi Daniel,

>> Welcome on board ;)
>
> Thanks! I have pushed some updates to
> https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/ which are ready
> for review. I did not push a debian/1.6_beta2* tag yet.

That's right debian tag should be pushed after uploading.

> I have built the updated package in a clean jessie amd64 chroot using
> pubuilder-dist, and it installed and worked fine on my jessie system.
> Test .deb packages for amd64 and armhf are available here:
> https://github.com/danielhjames/xwax-debs/tree/master/jessie
>
> The upstream git repo still includes a file called .version in the root
> directory but it is listed in .gitignore there, so when I created the
> archive of the new upstream version I think this file was left out:
>
> git archive 1.6-beta2|gzip > ../xwax-1.6~beta2-orig.tar.gz>
> Cheers!
>
> Daniel
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

I am usually get rig of upstream files like .gitignore .version by
repacking source

> I don't think this .version file is used by Debian in any way, so I'm
> just mentioning it for the sake of completeness.

I didn't over viewed your packaging yet ... just going to do it.

best regards

mira

___
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: Help offered with xwax package

[Daniel James]

Hi Felipe, hi Jaromír,

> Welcome on board ;)

Thanks! I have pushed some updates to
https://anonscm.debian.org/cgit/pkg-multimedia/xwax.git/ which are ready
for review. I did not push a debian/1.6_beta2* tag yet.

I have built the updated package in a clean jessie amd64 chroot using
pubuilder-dist, and it installed and worked fine on my jessie system.
Test .deb packages for amd64 and armhf are available here:
https://github.com/danielhjames/xwax-debs/tree/master/jessie

The upstream git repo still includes a file called .version in the root
directory but it is listed in .gitignore there, so when I created the
archive of the new upstream version I think this file was left out:

git archive 1.6-beta2|gzip > ../xwax-1.6~beta2-orig.tar.gz

I don't think this .version file is used by Debian in any way, so I'm
just mentioning it for the sake of completeness.

Cheers!

Daniel

___
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: Help offered with xwax package

[Jaromír Mikeš]

2016-08-08 20:54 GMT+02:00 Felipe Sateler :
> Hi Daniel,
>
> On 8 August 2016 at 11:47, Daniel James  wrote:
>> Hi all,
>>
>> I'd like to help update the xwax package in Debian to the latest
>> upstream 1.6-beta2, which Ubuntu already has. Then I would like to
>> backport this new version to jessie-backports, as jessie currently has
>> xwax version 1.5.
>>
>> There appears to be a typo in the current patch for Debian
>> 0001-use_either_ffmpeg_or_avconv.patch as follows:
>>
>> which avconf -> which avconv
>>
>> I attach an updated copy of the patch.
>>
>> I am not a Debian Developer but I have done some packaging work in
>> collab-maint. If it would be possible to have commit access to
>> pkg-multimedia/xwax on alioth I would gladly push some other fixes
>> there, for lintian issues etc.
>>
>> My alioth user name is dhj-guest.
>
> I've added you to the team in alioth, welcome! Please be sure to read
> the wiki[1] for some details on how most packages are managed in the
> team.
>
>
> [1] https://wiki.debian.org/DebianMultimedia/DevelopPackaging

Welcome on board ;)

mira

___
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: Help offered with xwax package

[Felipe Sateler]

Hi Daniel,

On 8 August 2016 at 11:47, Daniel James  wrote:
> Hi all,
>
> I'd like to help update the xwax package in Debian to the latest
> upstream 1.6-beta2, which Ubuntu already has. Then I would like to
> backport this new version to jessie-backports, as jessie currently has
> xwax version 1.5.
>
> There appears to be a typo in the current patch for Debian
> 0001-use_either_ffmpeg_or_avconv.patch as follows:
>
> which avconf -> which avconv
>
> I attach an updated copy of the patch.
>
> I am not a Debian Developer but I have done some packaging work in
> collab-maint. If it would be possible to have commit access to
> pkg-multimedia/xwax on alioth I would gladly push some other fixes
> there, for lintian issues etc.
>
> My alioth user name is dhj-guest.

I've added you to the team in alioth, welcome! Please be sure to read
the wiki[1] for some details on how most packages are managed in the
team.


[1] https://wiki.debian.org/DebianMultimedia/DevelopPackaging


-- 

Saludos,
Felipe Sateler

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

Help offered with xwax package

[Daniel James]

Hi all,

I'd like to help update the xwax package in Debian to the latest
upstream 1.6-beta2, which Ubuntu already has. Then I would like to
backport this new version to jessie-backports, as jessie currently has
xwax version 1.5.

There appears to be a typo in the current patch for Debian
0001-use_either_ffmpeg_or_avconv.patch as follows:

which avconf -> which avconv

I attach an updated copy of the patch.

I am not a Debian Developer but I have done some packaging work in
collab-maint. If it would be possible to have commit access to
pkg-multimedia/xwax on alioth I would gladly push some other fixes
there, for lintian issues etc.

My alioth user name is dhj-guest.

Cheers!

Daniel
Description: Pick either avconv or ffmpeg.
Author: Alessio Treglia 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722487
Forwarded: no
---
 import |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- xwax.orig/import
+++ xwax/import
@@ -13,6 +13,8 @@
 FILE="$1"
 RATE="$2"
 
+g_fallback_tool="$(which avconv || which ffmpeg)"
+
 case "$FILE" in
 
 *.cdaudio)
@@ -27,7 +29,7 @@ case "$FILE" in
 
 *)
 echo "Calling fallback decoder..." >&2
-exec ffmpeg -v 0 -i "$FILE" -f s16le -ar "$RATE" -
+exec "$g_fallback_tool" -v 0 -i "$FILE" -f s16le -ar "$RATE" -
 ;;
 
 esac
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers