Re: what to do is maintainer is lacking? (was: wine-unstable in Debian)
* Charles Plessy , 2012-04-22, 11:49: The point of NMUs is *helping* a maintainer which, for different reasons, is temporarily unable to fix specific issues in their packages. If the NMU-er keeps that principle in mind, everything else descends more or less naturally. Hi Stefano, much of you wrote here make a lot of sense, and I think it would be a good stem for an update the Developers Reference (and therefore mark DEP1 obsolete after four years of good service to Debian). Why is DEP-1 even marked as accepted? It's been rejected after all... -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120422073458.ga3...@jwilk.net
Re: what to do is maintainer is lacking? (was: wine-unstable in Debian)
On Sun, Apr 22, 2012 at 11:49:08AM +0900, Charles Plessy wrote:
> If we would converge on a good rule of thumb to replace the nth NMU in
> a row to a QA orphaning, then I believe that the updated NMU section
> in the Developers Reference would then stay unchanged for a long time.
I do see value in what you're proposing and I suspect it already happens
even in the lack of a good rule of thumb. All in all, it seems to me
that the two are rather separate concerns: NMUs are for temporarily get
unstuck a package wrt some specific bug, whereas orphaning is a more
generic activity to ensure people do now believe a package is maintained
while in fact it is not. But having a rule of thumb won't hurt, I guess,
as long as it remains so rather than a rule carved in stone to complain
against when it is not followed to the letter (something we're rather
prone to).
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Towards multi-arch: "Multi-Arch: same" file conflicts
On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote: > If a package is marked as "Multi-Arch: same", files with the same > name have to be (byte-to-byte) identical across all architectures. > Unfortunately, not all packages obey this requirement. I set up a > page to track violators: > > http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt > http://people.debian.org/~jwilk/multi-arch/same-md5sums.ddlist > I've just filed a number of bugs (~60) based on this list, excluding binNMUed packages and packages affected by #647522. Cheers, Julien signature.asc Description: Digital signature
Bug#670041: ITP: libbiblio-thesaurus-perl -- Biblio::Thesaurus - Perl extension for managing ISO thesaurus
Package: wnpp Severity: wishlist Owner: Nuno Carvalho * Package name: libbiblio-thesaurus-perl Version : 0.42 Upstream Author : Alberto Simões * URL : http://search.cpan.org/dist/Biblio-Thesaurus/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Biblio::Thesaurus - Perl extension for managing ISO thesaurus A Thesaurus is a classification structure. We can see it as a graph where nodes are terms and the vertices are relations between terms. This module provides transparent methods to maintain Thesaurus files. The module uses a subset from ISO 2788 which defines some standard features to be found on thesaurus files. This ISO includes a set of relations that can be seen as standard but, this program can use user defined ones. So, it can be used on ISO or not ISO thesaurus files. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120422133505.15895.4155.report...@smallgodz.com
Bug#670052: ITP: libpostproc -- FFmpeg derived postprocessing library
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
* Package name: libpostproc
Version : ?
Upstream Author : Michael Niedermayer (michae...@gmx.at)
* URL : http://git.videolan.org/?p=libpostproc.git;a=summary
* License : GPLv2+
Programming Lang: C
Description : FFmpeg derived postprocessing library
Proposed package metadata:
Package: libpostproc-dev
Section: libdevel
Architecture: any
Depends: libpostproc52 (= ${binary:Version})
Description: FFmpeg derived postprocessing library - development headers
This package contains the postprocessing library for legacy
applications.
Package: libpostproc52
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: FFmpeg derived postprocessing library
This package contains the postprocessing library for legacy
applications.
Suggestions for better package descriptions welcome.
For inclusion in team pkg-multimedia, I solicit for supporters inside
team pkg-multimedia. I expect this library to take very little efford
maintenance way and to go away in the long term. It has only been
created because libav dropped it from its sources. We need to carry it
in Debian until all packages that depend on it have migrated away from
it.
Preliminary packaging can be inspected here:
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libpostproc.git
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120422155630.765.4375.reportbug@localhost6.localdomain6
Bug#670065: ITP: pear-symfony-project-channel -- PEAR Symfony Project channel definition file
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: pear-symfony-project-channel Version : 1.0-1 Upstream Author : Thomas Goirand * URL : http://pear.symfony-project.com/ * License : BSD Programming Lang: XML Description : PEAR Symfony Project channel definition file Long description: This is the PEAR channel registry entry for the Symfony Project. PEAR is a framework and distribution system for reusable PHP components. A PEAR channel is a website that provides package for download and a few extra meta-information for files. The Symfony Project is a PHP Web Framework. A bit of background: The Debian PKG-PEAR team is currently making an effort to package PHPUnit, which is a unit testing framework. One of the dependency of PHPUnit is php-symfony-yaml (see #613425), which is why we need the Symfony Project channel definition file to be packaged in Debian (to make it possible to continue to use "pear install" for PEAR packages not in Debian, and have consistancy in the system). We believe that using PHPUnit is moving toward the correct direction of improving the quality of PEAR packages, by finally activating unit testing in the build process of PEAR packages (this is a long term goal, which I don't think will be reachable before the freeze of Wheezy, unfortunately). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120422174050.7729.96746.report...@buzig.gplhost.com
Re: state of security hardening build flag efforts
Russ Allbery wrote:
> Uoti Urpala writes:
> > Russ Allbery wrote:
>
> >> +pie causes a fairly ordinary regular binary (gnubg) to die with a bus
> >> error immediately upon execution. If someone could figure out why and
> >> whether it's a general class of problems or something peculiar to that
> >> code, I'd be feeling more optimistic about enabling PIE more broadly.
>
> > I tried building it with +pie on AMD64. It ran without crashing.
>
> Try on i386. That's where I had the problem. (Sorry, I should have said
> that.)
I tried it on i386 now. The binary didn't start; however, I did not see
any bus error. Rather, the kernel immediately kills the new process with
SIGKILL before any code starts executing. The issue is triggered by the
huge static amMoves array declared in eval.c function GenerateMoves, and
only occurs with address space randomization enabled (it runs fine under
gdb by default, unless you do "set disable-randomization off"). The
following program demonstrates the same issue if compiled with -pie:
char a[19500];
int main(void) { return a; }
I think the reason for this behavior is that with address space
randomization and PIE the array is placed in or above the mmap segment
of process memory, and that has a predetermined size which may be too
small for big objects. The same program actually works if I use "ulimit
-s 50", which reserves more space at the top of the address space.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1335128169.1791.20.camel@glyph.nonexistent.invalid
