Hi all,
Up to now the only options for pulling patches from distributions
derived from Debian have been Ubuntu's Debian patches repository[1] and
manual downloads of source packages from derivatives. In my estimation a
more general way to do this would be desirable.
1. http://patches.ubuntu.
On Tue, Oct 25, 2011 at 11:22:05AM +0800, Paul Wise wrote:
> On Tue, Oct 25, 2011 at 11:06 AM, Russ Allbery wrote:
> > The results of that build seem unlikely to ever be seriously tested
> > currently, which makes me a little dubious that it's worth making a rule
> > about it.
>
> I would wager th
hiya,
On Tue, Oct 25, 2011 at 03:50:07PM +0800, Paul Wise wrote:
> For the presentation side of things I am thinking one approach might be
> to move UbuntuDiff[8] to the QA infrastructure, generalise it and
> enhance it for this purpose. This will necessarily include mechanisms to
> mark patches a
Package: wnpp
Owner: tak...@debian.org
Severity: wishlist
* Package name: python-pywebsocket
Version : 0.6b6
Upstream Author : Google Inc.
* URL or Web page : http://code.google.com/p/pywebsocket/
* License : BSD-3
Description : python Websocket server library
The py
On Tue, Oct 25, 2011 at 4:58 PM, sean finney wrote:
> I think it's also worth some consideration about if/how it could be
> integrated with the Debian patch-tracker service (or perhaps supercede said
> service if it made more sense).
>
> Without thinking super hard on it it seems like it could hav
On Tue, 2011-10-25 at 12:10 +0800, Paul Wise wrote:
[...]
> One example from the archive: firmware-free. Source code for the
> embedded software blobs is present but at least one of them no longer
> builds or never did.
[...]
I've been working on that specific case...
Ben.
--
Ben Hutchings
DNRC
On Tue, Oct 25, 2011 at 5:57 PM, Ben Hutchings wrote:
> On Tue, 2011-10-25 at 12:10 +0800, Paul Wise wrote:
> [...]
>> One example from the archive: firmware-free. Source code for the
>> embedded software blobs is present but at least one of them no longer
>> builds or never did.
> [...]
>
> I've b
> Adam Borowski writes:
[…]
> GNU's and the inventor of AM_MAINTAINER_MODE's stance:
> http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html
BTW, this URI seems to me like a thing to be reported to GNU
webmasters (Cc:'ed.) The Automake manual should be (and
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
I plan to package in order to update libfuse-perl the following package.
Package name: libunix-mknod-perl
Version: 0.04
Upstream Author: Jim Pirzyk,
URL: http://search.cpan.org/~pirzyk/Unix-Mknod-0.04/lib/Unix/Mknod.pm
Hello,
Quick question. I see you maintain zfs-fuse.
0.7.0 is out since March, but it's not even in Sid. Is there some deep
reason to this, or just lack of time?
Since zfs-fuse upstream is under extremely heavy development, I have the
feeling that any risks created by adopting the latest stable r
On 25/10/2011 09:50, Paul Wise wrote:
>
> For the presentation side of things I am thinking one approach might be
> to move UbuntuDiff[8] to the QA infrastructure, generalise it and
> enhance it for this purpose. This will necessarily include mechanisms
> to mark patches as having been dealt wit
On Tue, 25 Oct 2011, Adam Borowski wrote:
> If they use AM_MAINTAINER_MODE and it's "disabled" [1], there's no way to
> check if they aren't in DFSG and/or GPL violation by shipping sourceless
> code. Forbidding it would at least deal with patching autotools output
> rather than source.
As a rule
Hi Dániel,
2011/10/25 József Dániel :
> Hello,
> Quick question. I see you maintain zfs-fuse.
> 0.7.0 is out since March, but it's not even in Sid. Is there some deep
> reason to this, or just lack of time?
> Since zfs-fuse upstream is under extremely heavy development, I have the
> feeling that a
On Tue, Oct 25, 2011 at 12:38:11PM +0200, József Dániel wrote:
> Hello,
>
> Quick question. I see you maintain zfs-fuse.
>
> 0.7.0 is out since March, but it's not even in Sid. Is there some deep
> reason to this, or just lack of time?
The latter. It's on mentors, I need to go through the packag
2011/10/25 Aron Xu :
> Hi Dániel,
>
> 2011/10/25 József Dániel :
>> Hello,
>> Quick question. I see you maintain zfs-fuse.
>> 0.7.0 is out since March, but it's not even in Sid. Is there some deep
>> reason to this, or just lack of time?
>> Since zfs-fuse upstream is under extremely heavy developme
On Tue, Oct 25, 2011 at 8:25 PM, Mike Hommey wrote:
> On Tue, Oct 25, 2011 at 12:38:11PM +0200, József Dániel wrote:
>> Hello,
>>
>> Quick question. I see you maintain zfs-fuse.
>>
>> 0.7.0 is out since March, but it's not even in Sid. Is there some deep
>> reason to this, or just lack of time?
>
* Henrique de Moraes Holschuh [111025 14:28]:
> On Tue, 25 Oct 2011, Adam Borowski wrote:
> > If they use AM_MAINTAINER_MODE and it's "disabled" [1], there's no way to
> > check if they aren't in DFSG and/or GPL violation by shipping sourceless
> > code. Forbidding it would at least deal with pat
Package: wnpp
Severity: wishlist
Owner: "Antoine Beaupré"
* Package name: atheme-services
Version : 6.0.0
Upstream Author : William Pitcock and others
* URL : http://www.atheme.net/
* License : GPL
Programming Lang: C
Description : modular IRC services
Package: general
Followup-For: Bug #620133
Dear Maintainer,
sometimes the connection to the Internet is very slowed or turned off, but this
happened only since I use wheezy (no problem with debian stable or others os).
-- System Information:
Debian Release: wheezy/sid
APT prefers testing-pro
Processing commands for cont...@bugs.debian.org:
> reassign 646622 general
Bug #646622 [debian-maintainers] debian-maintainers: Changelog for new upstream
release should include summary of upstream changelog
Bug reassigned from package 'debian-maintainers' to 'general'.
> thanks
Stopping processi
Package: wnpp
Owner: Salvatore Bonaccorso
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libtap-formatter-html-perl
Version : 0.09
Upstream Author : Steve Purkis
* URL : http://search.cpan.org/dist/TAP-Forma
On Tue, Oct 25, 2011 at 15:50:07 +0800, Paul Wise wrote:
> Hi all,
>
> Up to now the only options for pulling patches from distributions
> derived from Debian have been Ubuntu's Debian patches repository[1] and
> manual downloads of source packages from derivatives. In my estimation a
> more gene
Pomoçao de fim de ano da CMBalões
BALÕES LOGOTIPADOS R$ 200,00 O MILHEIRO
Confira
Kit com 100 balões + gás hélio + fitilhos + monitor no local deixando tudo
pronto.
De segunda a sexta: R$ 250,00
Sábado e domingo: R$ 280,00
Kit com 200 balões na mesma proporção
De segunda a sexta: R$ 3
On Tue, 25 Oct 2011 13:57:20 +0200
Mehdi Dogguy wrote:
> On 25/10/2011 09:50, Paul Wise wrote:
> >
> > For the presentation side of things I am thinking one approach
> > might be to move UbuntuDiff[8] to the QA infrastructure, generalise
> > it and enhance it for this purpose. This will necessar
Am Mittwoch, den 26.10.2011, 08:49 +1100 schrieb Karl Goetz:
> On Tue, 25 Oct 2011 13:57:20 +0200
> Mehdi Dogguy wrote:
>
> > On 25/10/2011 09:50, Paul Wise wrote:
> > >
> > > For the presentation side of things I am thinking one approach
> > > might be to move UbuntuDiff[8] to the QA infrastruc
Adam Borowski writes:
> If they use AM_MAINTAINER_MODE and it's "disabled" [1], there's no way
> to check if they aren't in DFSG and/or GPL violation by shipping
> sourceless code. Forbidding it would at least deal with patching
> autotools output rather than source.
While I like the idea of re
On Wed, Oct 26, 2011 at 4:01 AM, Julien Cristau wrote:
> Is there a reason to restrict this to derivatives? I find patches from
> fedora rather more interesting than ubuntu's.
Fedora don't use Debian source packages so we don't have anything to
debdiff against.
But I guess you mean patches agai
On Tue, Oct 25, 2011 at 7:57 PM, Mehdi Dogguy wrote:
> I'm glad you liked it. ubuntudiff¹ was made exactly to show this kind of
> data. Currently, all ubuntudiff needs to produce html pages in some file
> listing source package names and associated patches. So, nothing is really
> bound to patches
On Tue, Oct 25, 2011 at 7:57 PM, Mehdi Dogguy wrote:
> I'm glad you liked it. ubuntudiff¹ was made exactly to show this kind of
> data. Currently, all ubuntudiff needs to produce html pages in some file
> listing source package names and associated patches. So, nothing is really
> bound to patches
On Wed, Oct 26, 2011 at 6:28 AM, Russ Allbery wrote:
> While I like the idea of rebuilding everything from scratch, adding
> Makefile rules to do so is horrible. Automake bungles this miserably and
> it produces all sorts of random unnecessary bugs. With my upstream hat
> on, I will *always* use
Paul Wise writes:
> On Wed, Oct 26, 2011 at 6:28 AM, Russ Allbery wrote:
>> While I like the idea of rebuilding everything from scratch, adding
>> Makefile rules to do so is horrible. Automake bungles this miserably
>> and it produces all sorts of random unnecessary bugs. With my upstream
>> ha
31 matches
Mail list logo
