On Mon, 2008-03-17 at 02:38 -0300, Martín Ferrari wrote:
> Dear -devel:
>
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to
> upstream bug t
On Mon, Mar 17, 2008 at 2:38 PM, Martín Ferrari
<[EMAIL PROTECTED]> wrote:
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to
> upstream
"Martín Ferrari" <[EMAIL PROTECTED]> writes:
> Following the trend to add metadata to the debian/control file that
> allows for the creation of new and powerful tools, I thought about the
> usefulness of a header that'd allow to automatically relate to upstream
> bug trackers.
>
> It could be used
Dear -devel:
Following the trend to add metadata to the debian/control file that
allows for the creation of new and powerful tools, I thought about the
usefulness of a header that'd allow to automatically relate to
upstream bug trackers.
It could be used to automatically forward bugs, track which
On Sun, Mar 16, 2008 at 11:59:52PM +, Steve McIntyre wrote:
> 2 small CDs per arch (business card, netinst)
> ~30 CDs per arch for a full CD set
> ~4 DVDs per arch for a full DVD set
> (total 353 CDs, 51 DVDs, 426 GB)
Bluray image? Apparently there's been a winner in the format wars,
and w
Tim Cutts wrote:
Hm, can you help with creating a good set of colors?
There are a number of programs around which can help with this. I use
Color Oracle: http://colororacle.cartography.ch/
It sits in a Gnome panel, and will temporarily change your entire
display's colours to simulate thr
Steve McIntyre wrote:
[ Please note Reply-To: to debian-cd... ]
Hi folks,
It's time for me to ask the question again - what CDs and DVDs will we
find useful enough that we should make them for lenny?
[...]
1. Is it worth making full sets of CDs at all? Can we rely on people
having a net
[ Please note Reply-To: to debian-cd... ]
Hi folks,
It's time for me to ask the question again - what CDs and DVDs will we
find useful enough that we should make them for lenny? The reason I'm
asking is that we're looking at a *huge* number of discs, and it's not
clear that they'll all be useful.
Bas Wijnen wrote:
> This does break versions which go from 1 to 1.1 to 1.2 to 2 to 2.1, etc,
> but we're talking about native packages, which means we can expect
> upstream not to be so crazy.
People do this all the time, for completly sane reasons.
--
see shy jo
signature.asc
Description: Di
On Sun, Mar 16, 2008 at 09:07:48AM -0400, Kevin Coyner wrote:
> > I think you want the one that uploaded the .orig.tar.gz, so:
> > lynx -dump
> > http://packages.qa.debian.org/r/rhinote/news/20060625T184700Z.html | gpg
> > --verify
> > gpg: Signature made Sun 11 Jun 2006 03:11:54 PM CEST using DS
On Sat, 2008-03-15 at 16:05 +0100, Vincent Bernat wrote:
> OoO Pendant le journal télévisé du jeudi 13 mars 2008, vers 20:00, Russ
> Allbery <[EMAIL PROTECTED]> disait:
>
> > (I *have* heard of architectures in common use where a pointer to data
> > is a different size than a pointer to a
[Russ Allbery]
>> Is the only way to make sure that conffiles do not clutter filesystem to
>> remove them in maintainer's script on upgrade from previous version?
>
> I believe that's the case, although I'd like to get some confirmation
> before adding something to Policy 10.7.3 about this. See Bu
"Artur R. Czechowski" <[EMAIL PROTECTED]> writes:
> So, why it still exists? I read Debian Policy, section 10.7.3[1] but it
> does not say what shall happen if after upgrade of the package it does
> not provide conffile anymore.
>
> Is the only way to make sure that conffiles do not clutter filesy
Artur R. Czechowski wrote:
>
> Is the only way to make sure that conffiles do not clutter filesystem to
> remove them in maintainer's script on upgrade from previous version?
That's correct. The only way currently to remove obsolete conffiles is
to do it manually in the maintainer scripts [1]
I
[Patrick Matthäi]
> is there any reason to encrypt your traffic on downloading packages?
> I think this will only cause more traffic and cpu overhead on the
> mirrors instead of help anything.
I took is request to ask for SOCKS support, not encrypted connections.
I know that I've used the SOCKS f
[Florian Weimer]
> This reminds me of an old problem: Does the network dependency
> result in initialization of the IPv6 stack?
That is up to the network enabling script to decide. :)
At the moment, the $network virtual facility is defined to mean the
scripts networking and ifupdown. If these s
Hello developers,
Trying to run insserv and dependency based boot sequence on my workstation
I run into a phenomenon I cannot understand.
Let's see an example: xserver-xorg package.
I have latest version from unstable:
ii xserver-xorg 1:7.3+10 the X.Org X server
Let's see the content of
xHemi schrieb:
> This might not be the correct place but here goes..
>
> apt-get provides http_proxy and ftp_proxy support but why not SOCKS?
> I have no experience with SOCKS other than that I use it daily in conjunction
> with firefox and ssh. I think it is a feature which could be of use
> to o
* Petter Reinholdtsen:
> Here is a small update on the release goal of converting the Debian boot
> sequening to use dynamic and dependency based ordering instead of hardcoded
> sequence numbers.
>
> The latest status information is available from
> http://wiki.debian.org/LSBInitScripts/Dependency
Package: wnpp
Severity: wishlist
Owner: "Jan Lübbe" <[EMAIL PROTECTED]>
* Package name: python-pysnmp4-apps
Version : 0.2.6a
Upstream Author : Ilya Etingof
* URL : http://pysnmp.sourceforge.net/
* License : BSD-style
Programming Lang: Python
Description
On Sun, Mar 16, 2008 at 12:19:45PM +0100, Bernhard R. Link wrote:
> * Steve Langasek <[EMAIL PROTECTED]> [080315 21:12]:
> > $ cat /srv/ftp.debian.org/queue/reject/rhinote_0.7.0-2_i386.reason
> > Rejected: md5sum and/or size mismatch on existing copy of
> > rhinote_0.7.0.orig.tar.gz.
> > Rejected
On Sun, 03 Feb 2008, Raphael Hertzog wrote:
> On Sat, 02 Feb 2008, Charles Plessy wrote:
> > Is there sombody working on Wig&Pen? Is the format consensual enough
> > that it would be accepted in Debian?
>
> I plan to work on it (but have not done anything yet except thinking about
> it and followi
On Sun, Mar 16, 2008 at 02:13:32PM +, The Fungi wrote:
> On Sun, Mar 16, 2008 at 09:07:48AM -0400, Kevin Coyner wrote:
> > I'm going to contact upstream and ask if they would consider
> > releasing a new version so that this can get cleaned up.
> Wouldn't prepending an epoch be less drastic? D
On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
> "Adam D. Barratt" <[EMAIL PROTECTED]> writes:
> > On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
[...]
> >> Good idea. Even better, IMO, would be to use a system which is in
> >> line with non-native packages. How about this rule:
> >
"Adam D. Barratt" <[EMAIL PROTECTED]> writes:
> On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
>> [Adding bug #437392 to Cc, which deals with this issue for normal
>> NMUs, because I'm making a suggestion about them.]
>>
>> On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
>>
On Sun, Mar 16, 2008 at 02:13:32PM +, The Fungi wrote:
> On Sun, Mar 16, 2008 at 09:07:48AM -0400, Kevin Coyner wrote:
> > I'm going to contact upstream and ask if they would consider
> > releasing a new version so that this can get cleaned up.
>
> Wouldn't prepending an epoch be less drastic?
The Fungi wrote:
> On Sun, Mar 16, 2008 at 09:07:48AM -0400, Kevin Coyner wrote:
> > I'm going to contact upstream and ask if they would consider
> > releasing a new version so that this can get cleaned up.
>
> Wouldn't prepending an epoch be less drastic? Doesn't sound like the
> mistake was upst
On Sun, Mar 16, 2008 at 09:07:48AM -0400, Kevin Coyner wrote:
> I'm going to contact upstream and ask if they would consider
> releasing a new version so that this can get cleaned up.
Wouldn't prepending an epoch be less drastic? Doesn't sound like the
mistake was upstream's...
--
{ IRL(Jeremy_St
On Sun, Mar 16, 2008 at 01:52:32PM +0100, Kurt Roeckx wrote..
> > > But is there a way to know who the sponsor of rhinote_0.7.0-1 was?
> >
> > [EMAIL PROTECTED]:~$ lynx -dump
> > http://packages.qa.debian.org/r/rhinote/news/20080316T114705Z.html | gpg
> > --verify
> > gpg: Signature made
On 16/03/2008, Bernhard R. Link wrote:
> But is there a way to know who the sponsor of rhinote_0.7.0-1 was?
Besides the “lynx -dump”-based solutions mentioned in this thread,
there's far easier:
| $ who-uploads rhinote # from devscripts
| Uploads for rhinote:
| 0.7.0-2 to unstable: Kevin Coyner <[
On Sun, Mar 16, 2008 at 01:37:29PM +0100, Marc 'HE' Brockschmidt wrote:
> "Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> > * Steve Langasek <[EMAIL PROTECTED]> [080315 21:12]:
> >> $ cat /srv/ftp.debian.org/queue/reject/rhinote_0.7.0-2_i386.reason
> >> Rejected: md5sum and/or size mismatch on ex
"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> * Steve Langasek <[EMAIL PROTECTED]> [080315 21:12]:
>> $ cat /srv/ftp.debian.org/queue/reject/rhinote_0.7.0-2_i386.reason
>> Rejected: md5sum and/or size mismatch on existing copy of
>> rhinote_0.7.0.orig.tar.gz.
>> Rejected: can not overwrite exi
On Sun, Mar 16, 2008 at 08:23:43PM +0900, Charles Plessy wrote:
> Le Sun, Mar 16, 2008 at 12:10:13PM +0100, Bas Wijnen a écrit :
> >
> > This could also lead to a problem in very rare cases: If a program has
> > the same version in stable and testing, and gets a security update, then
> > they both
* Steve Langasek <[EMAIL PROTECTED]> [080315 21:12]:
> $ cat /srv/ftp.debian.org/queue/reject/rhinote_0.7.0-2_i386.reason
> Rejected: md5sum and/or size mismatch on existing copy of
> rhinote_0.7.0.orig.tar.gz.
> Rejected: can not overwrite existing copy of 'rhinote_0.7.0.orig.tar.gz'
> already
On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
> [Adding bug #437392 to Cc, which deals with this issue for normal
> NMUs, because I'm making a suggestion about them.]
>
> On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
> > devscripts 2.10.19 (soon to be uploaded) will modif
Le Sun, Mar 16, 2008 at 12:10:13PM +0100, Bas Wijnen a écrit :
>
> This could also lead to a problem in very rare cases: If a program has
> the same version in stable and testing, and gets a security update, then
> they both get a similar version. For the example, say 1.2-5.1+sarge1 in
> stable a
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: gnview
Version: 0.8
Upstream Author: Mitsutoshi Kiuchi <[EMAIL PROTECTED]>
URL: http://gnview.sourceforge.jp/
License: GPL version2
Programming Lang: Perl
Description
On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote:
> The current binNMU numbering scheme was selected explicitly to allow
> security uploads to sort later by numbering as
> +; e.g., 1.2-5.1+etch1.
That makes sense, although doesn't seem to match current practice. Was
any consideration given
On Sun, 16 Mar 2008, Thijs Kinkhorst wrote:
> On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
> > We're aware that the Developers Reference specifies that the latter
> > format should be used, but it is problematic as -0.1 sorts before +b1
> > and, as such, the NMU will not supersede any prev
On Sun, Mar 16, 2008 at 03:47:56AM -0700, Steve Langasek wrote:
> The current binNMU numbering scheme was selected explicitly to allow
> security uploads to sort later by numbering as
> +; e.g., 1.2-5.1+etch1.
This could also lead to a problem in very rare cases: If a program has
the same version
On Sunday 16 March 2008 11:47, Steve Langasek wrote:
> The current binNMU numbering scheme was selected explicitly to allow
> security uploads to sort later by numbering as
> +; e.g., 1.2-5.1+etch1.
Ah, I wasn't aware of that (and no-one seems to be using it currently). The
release managers know
On Sun, Mar 16, 2008 at 11:36:20AM +0100, Thijs Kinkhorst wrote:
> On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
> > We're aware that the Developers Reference specifies that the latter
> > format should be used, but it is problematic as -0.1 sorts before +b1
> > and, as such, the NMU will n
On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
> We're aware that the Developers Reference specifies that the latter
> format should be used, but it is problematic as -0.1 sorts before +b1
> and, as such, the NMU will not supersede any previous binNMUs of the
> same package version.
>
> Whil
* Adam D. Barratt:
> Currently, debchange will produce a version number of X-0.1 in such
> cases which suffers from the problem described above. It has been
> suggested that either one of +s1 / +sec1 / +security1 or 1
> should be used to avoid the issue.
For stable and oldstable, we need 1. But
[Adding bug #437392 to Cc, which deals with this issue for normal NMUs,
because I'm making a suggestion about them.]
On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
> devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of
> "debchange --nmu" to version an NMU of a n
45 matches
Mail list logo
