Re: Standardizing the layout of git packaging repositories

[Matthias Urlichs]

Hi,

Russ Allbery:
> It's somewhat harder to maintain, but it's vastly better for
> communicating to upstream or to other distributions.
> 
Mmh. Whenever Upstream uses git, my favorite method of sending a patch 
is to put the fix in a separate branch, and then tell ^w ask them
to "git pull" it.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140823095854.ga24...@smurf.noris.de

Re: Reintroducing FFmpeg to Debian

[Andreas Cadhalpun]

Hi,

On 17.08.2014 00:49, Andreas Cadhalpun wrote:

I have now sent the pkg-config patches to the BTS [1].


I have found a simpler way to make it possible to link packages not 
using pkg-config against FFmpeg in Debian:
The lib*-ffmpeg-dev packages now install symbolic links from the 
standard lib*.so library names to the suffixed ones.
This makes it possible to use the normal linker flags, e.g. '-lavcodec', 
to link against the FFmpeg libraries with '-ffmpeg' suffix.


Therefore I have closed the bugs with the pkg-config patches [1].

Thus, once FFmpeg is through NEW, most packages can just switch the 
build-dependencies to be build against FFmpeg.


Best regards,
Andreas


1: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=reintroducing-ffmpeg;users=andreas.cadhal...@googlemail.com



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f87004.6000...@googlemail.com

Re: Standardizing the layout of git packaging repositories

[Russ Allbery]

Matthias Urlichs  writes:
> Russ Allbery:

>> It's somewhat harder to maintain, but it's vastly better for
>> communicating to upstream or to other distributions.

> Mmh. Whenever Upstream uses git, my favorite method of sending a patch
> is to put the fix in a separate branch, and then tell ^w ask them to
> "git pull" it.

Right, exactly.  That's super-annoying to do if you were keeping
everything mixed together in the master branch, much easier if you were
keeping separate branches for each fix but keeping those separate branches
is itself incredibly annoying, and utterly trivial if you're using gbp pq
or git-dpm.  The latter take a little bit of getting used to, and are then
almost as fast as just making changes directly in Git, but let you
actually send isolated fixes upstream.

This use case is *exactly* why I started using separated patches and the
3.0 (quilt) format.

I would never use quilt directly.  Been there, done that, have no interest
in doing it again.  I like Git.  But using it as an export format for
patch-queue branches works really well.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761hjhxmv@hope.eyrie.org

Bug#759009: ITP: compass-blueprint-plugin -- Compass extension for blueprint CSS framework

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: compass-blueprint-plugin
  Version : 0.0.1
  Upstream Author : Scott Davis 
* URL : http://compass-blueprint.org/
* License : Expat
  Programming Lang: SCSS
  Description : Compass extension for blueprint CSS framework

 Compass is a CSS authoring framework which uses the Sass stylesheet
 language to make writing stylesheets powerful and easy.
 .
 Compass-blueprint is a CSS Framework extension for Compass, included
 with early releases of Compass but now shipped as separate plugin.

Needed (as recommendation) for newer releases of ruby-compass to avoid
regression: Was previously shipped as part of Compass itself, but not
any longer.

This package will be maintained in the Sass team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJT+N+rXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWs1EIAJVOkGnPRpcwabNZ+f3tMFkW
VvF/VnpvcWmRgRcZzwKHIQ9/bIdjVNqaGYAV0ehfy+2JgmBjRl1uW/zgtzvUfUP/
YJBMh333mo5KxeJJHQWlcUINgWd+lYWIkwUwFZEk6KmOmj/Oqno/K4Zc+nWXqc2B
xmhqqJoOBATRuZ1K5aNvrjro4GTrV0faTYJ71FqsEusEapICnIiEwo31INemRKak
f7yipt+h9CpFVG3UwyJYqZ1Dh7cQ/QbnsoxKfjId6ufsFMNFNF/z0WiGvBv2Q1pc
YINIjGR855m/SqfM57nSpecLL6CkGo39aWSnym/gu8WRZxbgjHm5CExFASkBKio=
=uD5X
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140823183839.12655.74426.report...@bastian.jones.dk

Re: Reintroducing FFmpeg to Debian

[Michael Niedermayer]

Hi

On Thu, Aug 21, 2014 at 03:16:50AM +0200, Attila Kinali wrote:
> Servus,
> 
> On Wed, 20 Aug 2014 18:43:18 +0900
> Norbert Preining  wrote:
> 
> > By continuing old fights, inspite of the very clearly friendly and
> > open offers and suggestions byu Michael, you and others from AV continue
> > simply to insult and be nasty.
> 
> Sorry, but this is not true. Yes, Michael always offers to mend ways
> and to do this and that. But he never does. It's just lip service.
> He didn't do it before the split and he didn't happen after the split.

Theres something about your statements, the one above as well as the
ones in other mails in this thread that i dont fully understand

You said in this thread that "i'm not a developer
and have not written one line of code for libav. i dont even read
the mailinglists"
(https://lists.debian.org/debian-devel/2014/08/msg00782.html)

and IIRC you also didnt read the ffmpeg mailing lists in the time
before the fork, except some specific threads, nor are you on the
ffmpeg IRC channels and i belive you arent subscribed to the FFmpeg
mailing lists now either. I definitly found a unsubscribe statement
for your address from march 2011 in the logs.

Given that, how can you even know anything about FFmpeg or what its
developers do or say or not do or not say
?

FFmpeg development discussions are mainly on our mailing list. with
a tiny bit on our IRC channels

I know you did read some specific threads which where related to
the fork as you participated in them. But these where possibly the
most heated and aggressive discussions we ever had on
ffmpeg-devel. And certainly are not representative for FFmpeg either
before or after the fork.


> Yes, the people at libav are bitter. Yes, they are angry. But how
> would you feel if people would walk up to you at random OSS events
> and tell you that X just told them you are the bad guy, that you
> steal childrens ice cream? (Yes, this has happend)
> 
> 
> > I am really impressed by the ability of Michael to take this without
> > changing into a more inpolite tone. Which you and others from AV are
> > definitely doing.
> 
> If you mean me by "others", then i would like to ask where i have been
> impolite.
> 
> > * AV maintainers are averse o any cooperation, and just licking their
> >   wounds since several years
> 
> You know, that FFmpeg and libav have been cooperating ever since the
> split? FFmpeg merges all (or almost all?) patches commited to libav

> without further review.

normally (for example in the kernel) code is reviewed before it is
pushed and not when it is merged.
Yet i _try_ to review and test what i merge from libav.
To proof that, here are some examples of bugfixes and decissions
based on such reviews. These wouldnt exist if the code wouldnt be
reviewed.

4 days ago:
libav added some () to a condition:
https://github.com/libav/libav/commit/d456baafb68cd80c0f537f1d843076e4dd853558

on the ffmpeg side the code was instead changed the following way a
year ago
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1e2ab98460761c86268993e7a7ee690876df5efd
libav decided not to pick this change, and instead made their own
different change as shown above

and in the merge i tested both to double check that our solution is
correct and libavs isnt, and kept our solution.
More precissely libavs breaks decoding of
http://samples.ffmpeg.org/ffmpeg-bugs/roundup/issue414/black_screen_VC-1.mkv


or for example 16days ago
libav fixed a few memory leaks
https://github.com/libav/libav/commit/5b220e1e19c17b202d83d9be0868d152109ae8f0
but they used the wrong deallocation function, that is free() instead
of av_free*() which can lead to memory corruption,
Multiple people noticed that and it was fixed in the same git push
that pushed the merge
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=92deb28945a5f2b58908d383f183cfc1bc1d7fae
also there where multiple other related issues found when reviewing
the change from libav which where fixed in ffmpeg in the same push as
well:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=12b59e57f3d7a37ef7b29d8a1df5eb886b00b4ba
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=31eaecfee9d84381945f3d5201775b9b00161d7a
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=92a28e9f562124732fa27f0c62118f15a6fee239
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5f8300afc6537e2e06f8f90989d5f268884bb79c

but either way, id like to suggest again, we move forward and
rather discuss how we can improve the situation, do something about
the split and move toward un-doing it!

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: Digital signature

Bug#759014: RFP: bitcointrader -- Bitcoin trading application

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: 
debian-devel@lists.debian.org,pkg-bitcoin-de...@lists.alioth.debian.org

   Package name: bitcointrader
Version: 1.07.99
Upstream Author: July IGHOR 
URL: https://github.com/JulyIGHOR/QtBitcoinTrader
License: GPL-3+ with OpenSSL linking exception
Description: Bitcoin trading application
 QtBitcoinTrader is a front-end to cryptocurrency exchanges. It helps to
 open and cancel orders very fast and monitor data in real time.
 .
 Supported exchanges:
  * BTC China
  * GOC.io
  * BTC-e
  * Bitstamp
  * Bitfinex
 .
 BitCoins are a digital currency, exchanged freely against all other
 currencies.

Package is intended to be team-maintained so I would like to have one
co-maintainer before I convert this RFP to ITP.

Packaging is committed to 

http://anonscm.debian.org/gitweb/?p=pkg-bitcoin/bitcointrader.git



signature.asc
Description: This is a digitally signed message part.

Bug#759019: ITP: python-hurry.filesize -- human readable file sizes or anything sized in bytes

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-hurry.filesize
  Version : 0.9
  Upstream Author : Martijn Faassen, Startifact 
* URL : https://pypi.python.org/pypi/hurry.filesize
* License : ZPL-2.1
  Programming Lang: Python
  Description : human readable file sizes or anything sized in bytes

 hurry.filesize a simple Python library that can take a number of bytes and
 returns a human-readable string with the size in it, in kilobytes (K),
 megabytes (M), etc.
 .
 The default system it uses is "traditional", where multipliers of 1024
 increase the unit size.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140823205204.18479.67491.report...@buzig.gplhost.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Kieran Kunhya]

> but either way, id like to suggest again, we move forward and
> rather discuss how we can improve the situation, do something about
> the split and move toward un-doing it!

We look forward to seeing you in Dublin then.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK+ULv47B21JMGwyjA66JEL46Aa=xhzafvzbhybugbk83tr...@mail.gmail.com