date:20140823

Re: Standardizing the layout of git packaging repositories

2014-08-23 Thread 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

2014-08-23 Thread 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

2014-08-23 Thread Russ Allbery

Matthias Urlichs matth...@urlichs.de 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)   http://www.eyrie.org/~eagle/


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

2014-08-23 Thread Jonas Smedegaard

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard d...@jones.dk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: compass-blueprint-plugin
  Version : 0.0.1
  Upstream Author : Scott Davis jetvipe...@gmail.com
* 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

2014-08-23 Thread Michael Niedermayer

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 prein...@logic.at 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!

1 2 >

1 - 100 of 115 matches

Mail list logo