On Mon, 2012-06-11 at 11:39:24 +0100, Ian Jackson wrote:
> Guillem Jover writes ("Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1
> binNMU broke multi-arch installability"):
> > As I mentioned in the long ref-counting thread, I strongly disagree this
> > is a correct solution, it just seem
> So because it turned out that the information indeed was public, you
> find it ok to ask in public if it is public.
he posted a link on the 1st email... how is a link "non public"?
--
Salvo Tomaselli
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubs
On Sun, 2012-06-10 at 14:40:28 +0200, Raphael Hertzog wrote:
> On Sun, 10 Jun 2012, Guillem Jover wrote:
> > As I mentioned in the long ref-counting thread, I strongly disagree this
> > is a correct solution, it just seems like a hack to me. Instead I
> > think we should consider changelog (and cop
Hi,
On Tue, 12 Jun 2012, Guillem Jover wrote:
> > This allows us to get rid of the special-casing of bin-nmu in dpkg where
> > we only support one extension (+bX).
> >
> > We have many other cases where it would be helpful to be able to do such
> > binary-only rebuild in different environments and
Aneurin Price writes:
> In anything resembling a 'normal' system (ie. the kind where one might
> be using the defaults) I would say that the tmpfs correlation is so
> strong as to be very nearly 1:1, and this seems like the crux of the
> matter; that is after all the reason that these application
On 06/12/2012 12:24 AM, Joey Hess wrote:
> Ian Jackson wrote:
>>> - It allows DMs to grant permissions to other DMs.
>>
>> It is far from clear that forbidding this is the right thing to do.
>
> As far as I know, we did this intentionally. When a DM is the maintainer
> of a package, they should b
On 12-06-12 at 12:33pm, Salvo Tomaselli wrote:
> > So because it turned out that the information indeed was public, you
> > find it ok to ask in public if it is public.
>
> he posted a link on the 1st email... how is a link "non public"?
The link was public. The discussion here about potential i
Hi Mike,
On Mon, 11 Jun 2012 15:40:59 -0400, Michael Gilbert
wrote:
> We've been getting a few bug reports from users attempting to install
> multiarch wine who have yet to manually enable multiarch itself.
> Obviously that is a failure on their part, and is easily correctable.
> However, I wonde
Hi,
On Sun, Jun 10, 2012 at 01:57:49PM +0200, Ansgar Burchardt wrote:
>
> The ftp team wants to change how allowing Debian Maintainers to upload
> packages works. The current approach with the DM-Upload-Allowed field
> has a few issues we would like to address:
I have read three responses to th
Bernd Zeimetz writes:
> Which bad things happened that we have to change the current process?
As far as I see, it's more about "what good things didn't happen" why we
have to change the process.
That is also addresses a few corner cases that could've gone bad, but
never did is a side-effect.
-
Package: wnpp
Severity: wishlist
Owner: "Adrian-Ken Rueegsegger"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: adhcp
Version : 0.3
Upstream Author : codelabs.ch
* URL : http://www.codelabs.ch/adhcp/
* License : GPL-2+
Programming Lang: Ada
k...@codelabs.ch wrote:
>Package: wnpp
>Severity: wishlist
>Owner: "Adrian-Ken Rueegsegger"
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>* Package name: adhcp
> Version : 0.3
> Upstream Author : codelabs.ch
>* URL : http://www.codelabs.ch/adhcp/
>* License
On Tue, Jun 12, 2012 at 01:15:51PM +0200, Bjørn Mork wrote:
Aneurin Price writes:
In anything resembling a 'normal' system (ie. the kind where one might
be using the defaults) I would say that the tmpfs correlation is so
strong as to be very nearly 1:1, and this seems like the crux of the
matte
Hi,
On 06/12/2012 03:45 PM, Steve McIntyre wrote:
> k...@codelabs.ch wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: "Adrian-Ken Rueegsegger"
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> * Package name: adhcp
>> Version : 0.3
>> Upstream Author : codelabs.c
On Tue, Jun 12, 2012 at 04:33:00PM +0200, Adrian-Ken Rueegsegger wrote:
>Hi,
>
>On 06/12/2012 03:45 PM, Steve McIntyre wrote:
>>
>> One question: why?
>
>Is the question about why ADHCP in general or why ADHCP in Debian?
>
>If it is the former: the initial motivation for the development of ADHCP
>
Don is right.
I'd like to step up a level and think about the situation.
The real issue here is that having /tmp be just another directory in a
writable partition filesystem, like / or /home or whatever, means that
/tmp gets all the associated properties. One such property (A) is
that files can
On Tue, 2012-06-12 at 15:59 +0100, Steve McIntyre wrote:
> On Tue, Jun 12, 2012 at 04:33:00PM +0200, Adrian-Ken Rueegsegger wrote:
> >Hi,
> >
> >On 06/12/2012 03:45 PM, Steve McIntyre wrote:
> >>
> >> One question: why?
> >
> >Is the question about why ADHCP in general or why ADHCP in Debian?
> >
also sprach Ben Hutchings [2012.06.12.1736 +0200]:
> dhclient could do with some good competition; it's slow to recover from
> a link drop (or suspend/resume) and its configuration format is not very
> user-friendly. But it does seem premature to include ADHCP.
udhcpc and dhcpcd also work.
--
* Paul Wise schrieb:
Hi,
> Please read through some of these pages:
>
> http://www.debian.org/doc/manuals/maint-guide/
> http://mentors.debian.net/intro-maintainers
Thanks. I'll dig into it.
Meanwhile I'm almost finished with git importing and patch sorting,
and created a .deb via git-buildpa
On Tue, Jun 12, 2012 at 11:45 AM, David Kalnischkies wrote:
> On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert wrote:
>> In particular, I filed a bug against dpkg requesting that it produce
>> more informative error messages in these cases [0], but I wonder if a
>> part of the solution shouldn't
Hi folks,
is there already a way for maintaining debian packages entirely
with git - without the orig tarball ?
As more and more projects are moving to git, this IMHO would make
things easier for those projects.
I'm currently (re)packaging wwwoffle, and optimially I'd just like
to push a sign
Hi folks,
just seen that the German translation of the maintainer guide is
quite incomplete.
Perhaps I could find some time for fixing it, if anybody explains
me how to do that ;-)
cu
--
--
Enrico Weigelt, metux IT service
Hi Enrico,
On 12.06.2012 19:15, Enrico Weigelt wrote:
> just seen that the German translation of the maintainer guide is
> quite incomplete.
>
> Perhaps I could find some time for fixing it, if anybody explains
> me how to do that ;-)
Thanks for volunteering. Please ask on the
debian-l10n-ger.
Package: wnpp
Severity: wishlist
Owner: Vincent Sanders
* Package name: jsapigen
Version : 0.5.1
Upstream Author : Thomas Zimmermann
* URL : http://jsapigen.sourceforge.net/
* License : GPL3+
Programming Lang: C
Description : Generate C interface bindi
Guillem Jover wrote:
> By definition a binNMU cannot produce a source package anyway, so I
> fail to see the point in this artifical need to distinguish “source”
> and “binary” changelogs through different files, AFAIR I already
Why "artificial"? Isn't it a completely natural and consistent view t
On Sun, Jun 10, 2012 at 10:01:29AM +0200, Guillem Jover wrote:
> As I mentioned in the long ref-counting thread, I strongly disagree this
> is a correct solution, it just seems like a hack to me. Instead I
> think we should consider changelog (and copyright as long as it's in
> machine parseable fo
Package: wnpp
Severity: wishlist
Owner: Thomas Bechtold
* Package name: dbus-test-runner
Version : 0.0.5
Upstream Author : Ted Gould
* URL : https://launchpad.net/dbus-test-runner/
* License : GPL-3
Programming Lang: C
Description : Runs tests under a
* Ian Jackson (ijack...@chiark.greenend.org.uk) [120611 13:21]:
> Guillem Jover writes ("Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1
> binNMU broke multi-arch installability"):
> > As I mentioned in the long ref-counting thread, I strongly disagree this
> > is a correct solution, it ju
* Guillem Jover (guil...@debian.org) [120612 09:00]:
> I disagree placing it in the dpkg database is not helpful, for a user
> or other programs wanting to access that structured package metadata
> it's obviously easier and better to do something like
> «dpkg --show-changelog foo» or «dpkg-query --
* Raphael Hertzog (hert...@debian.org) [120612 13:10]:
> 1/ we modify dpkg to ignore differences on /usr/share/doc/*/changelog.*gz
> for multi-arch: same packages
Doesn't sound too bad to me, at least for short-term (where I'd tend
to take the changelog-version of the main architecture on installa
Enrico Weigelt writes:
> Hi folks,
>
>
> is there already a way for maintaining debian packages entirely
> with git - without the orig tarball ?
Not what you mean -- although there is pristine-tar to enable one to
discard the actual tarball and recreate it from git later.
> As more and more pro
El 12/06/12 12:40, Enrico Weigelt escribió:
>
> Hi folks,
>
>
> is there already a way for maintaining debian packages entirely
> with git - without the orig tarball ?
>
> As more and more projects are moving to git, this IMHO would make
> things easier for those projects.
>
>
> I'm currently
Michael,
am Tue, Jun 12, 2012 at 12:57:12PM -0400 hast du folgendes geschrieben:
> A squeeze-proposed-update could help that along, right?
no, we don't generally require people to update to the latest stable to upgrade
to the next stable version.
Also depending on the solution it might also not
* David Kalnischkies (kalnischk...@gmail.com) [120612 18:03]:
> You need to upgrade to support MultiArch,
> but you need MultiArch to upgrade…
> (beside, how would the detection for such a message look like?)
We had discussed to export foreign-arch packages to the arches
packages files at debconf.
On Tue, Jun 12, 2012 at 2:48 PM, Luis Alejandro Martínez Faneyth
wrote:
> El 12/06/12 12:40, Enrico Weigelt escribió:
>>
>> Hi folks,
>>
>>
>> is there already a way for maintaining debian packages entirely
>> with git - without the orig tarball ?
I use something like this in the gbp.conf:
[DEFA
Hi,
On Mon, Jun 11, 2012 at 10:53:50PM +0200, Peter Pöschl wrote:
> Seems you overlooked this:
>
> > Debian Unstable 64-bit 5.5.23-2
I just tried on my 32bit machine, and didn't get in in some 50.000
attempts. Also, the squeeze versions are listed under "unaffected",
which is what reduces the s
Package: wnpp
Severity: wishlist
Owner: Charles Plessy
* Package name: libnetty3.1-java
Version : 3.1.0.CR1
Upstream Author : Red Hat Middleware LLC, and individual contributors
* URL : http://www.jboss.org/netty
* License : LGPL-2.1+
Programming Lang: Java
2012/6/10 Wouter Verhelst wrote:
>> A lot of people (including you) said that tmpfs makes things faster. But
>> there were no examples of popular use-cases becoming faster because
>> of /tmp on tmpfs, so I had nothing to quote.
>
> You're not even trying.
>
> if tmpfs is faster than (say) ext4, th
2012/6/12 Bjørn Mork wrote:
> I still think that the easy tmpfs resizing makes it superior for /tmp.
Why do people repeat that tmpfs is easy to resize? Yes, you need about 3
commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on
disk, because it's large by default and you don
2012/6/12 Barak A. Pearlmutter wrote:
> The real issue here is that having /tmp be just another directory in a
> writable partition filesystem, like / or /home or whatever, means that
> /tmp gets all the associated properties. One such property (A) is
> that files can be large and can bleed off t
Dear fellow developers,
I would hereby kindly ask you (once again) to consider more
coordination with the i18n teams when preparing uploads for packages
when these introduce changes to debconf templates: either new
templates, modified ones (even for trivial changes), etc.
The i18n teams are curre
On 13/06/2012 03:53, Serge wrote:
> 2012/6/12 Bjørn Mork wrote:
>
>> I still think that the easy tmpfs resizing makes it superior for /tmp.
>
> Why do people repeat that tmpfs is easy to resize? Yes, you need about 3
> commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on
>
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-bioc-biocgenerics
Version : 0.2.0
Upstream Author : The Bioconductor Dev Team
* URL :
http://www.bioconductor.org/packages/release/bioc/html/BiocGenerics.html
* License : Artistic-2.0
Pr
43 matches
Mail list logo
