On Tue, Sep 22, 2020 at 09:42:57PM -0700, Felix Lechner wrote:
> This is a courtesy reminder that your Debian key is expiring on 2020-10-05.
> Please also keep in mind that the Debian folks in charge of the
> keyring update it only once a month. That usually happens on the 24th
> of each month. It
Nicolas Dandrimont wrote:
> * Martin Michlmayr [2018-03-30 17:14:49 +0200]:
> > beancount 2.0 was released a few days ago so it's time to get this
> > into Debian.
> > Anyone interested in packaging it? It's Python code.
> I've been meaning to look into this for a while, as I've been using
> bean
Hey Luke, Jonas,
On Fri, Nov 03, 2017 at 08:31:33PM +, Luke Dashjr wrote:
> > >> I believe Bitcoin is now stable enough for stable release.
> > > Things have only gotten less stable upstream since 2013...
> > Please provide references supporting that.
0.15 is certainly "stable" in the sense t
On Wed, Oct 26, 2016 at 07:04:35PM +1100, Erik de Castro Lopo wrote:
> Anthony Towns wrote:
> > Maybe
> > /usr/lib/x86_64-linux-gnu/qt5/examples/widgets/desktop/systray/systray
> > might reproduce the crash?
> Indeed it does! Gdb backtrace follows.
Okay, that makes it
On Tue, Oct 25, 2016 at 07:16:45PM +1100, Erik de Castro Lopo wrote:
> Thread 1 "bitcoin-qt" received signal SIGSEGV, Segmentation fault.
> qglx_findConfig (display=display@entry=0x56151080, screen=screen@entry=0,
> format=...,
> drawableBit=drawableBit@entry=1) at glxconvenience/qglxconv
> Just got a new machine, installed bitcoin-qt, ran it and got an
> immediate segfault. Re-running get the same result.
>
> Backtrace from GDB:
>
> (gdb) r
> Starting program: /home/erikd/Local/bin/bitcoin-qt
That's an odd location for the packaged binary?
> [Thread debugging using libthread_db e
> The description of the bitcoin* packages mentions the following line:
> This requires 20+ GB of space, slowly growing.
>
> That info seems to be severely outdated and actually uses 87+ GB on
> my system, which is more then 4 times as much. I've put the severity
> at normal instead of minor/wishli
Hey doko,
> Package: bitcoin
> Version: 0.12.1-0.1
>
> This package builds with a non standard compiler version; please check
> if this package can be built with the default version of gcc/g++, or
> with gcc-6/g++-6.
> The severity of this report is likely to be raised before the release,
> so tha
On Mon, Aug 01, 2016 at 02:25:25PM +1000, Anthony Towns wrote:
> I've had a go at packaging 0.12.1, and it seems to have worked. Changes
> versus the collab-maint repo are at:
I've taken the liberty of uploading NMUs of 0.12.1 and 0.13.0rc3 to
unstable and experimental via DE
On Sat, Aug 06, 2016 at 02:11:02PM +1000, Anthony Towns wrote:
> Building 0.12.1 fails due to the new gcc-6 default in unstable (see bug
> 812275), but 0.13.0rc2 builds okay and the tests pass.
My mistake, the build I tried was still against ssl from unstable. With
the correct libs
Source: bitcoin
Followup-For: Bug #828248
> OpenSSL 1.1.0 is about to released. During a rebuild of all packages
> using OpenSSL this package fail to build. A log of that build can be found
> at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/bitcoin_0.11.2-1_amd64-20160529-140
Source: bitcoin
Followup-For: Bug #812275
> This package fails to build with GCC 6.
FWIW, this bug seems to be fixed upstream somewhere between 0.12.1 and
0.13.0rc2. I ran a git bisect, and the commit that fixes the issue seems
to be:
https://github.com/bitcoin/bitcoin/commit/89f71c68c0fecf63059
On Wed, Aug 03, 2016 at 11:21:38AM +1000, Anthony Towns wrote:
> On Mon, Aug 01, 2016 at 09:35:42AM +0200, Jonas Smedegaard wrote:
> > Quoting Anthony Towns (2016-08-01 06:25:25)
> > > I've had a go at packaging 0.12.1, and it seems to have worked.
> > > Changes
On Mon, Aug 01, 2016 at 09:35:42AM +0200, Jonas Smedegaard wrote:
> Quoting Anthony Towns (2016-08-01 06:25:25)
> > I've had a go at packaging 0.12.1, and it seems to have worked.
> > Changes versus the collab-maint repo are at:
> > https://github.com/ajtowns/
Package: bitcoin-qt
Followup-For: Bug #822203
Hi,
I've had a go at packaging 0.12.1, and it seems to have worked. Changes
versus the collab-maint repo are at:
https://github.com/ajtowns/bitcoin-deb/commits/master
I had to disable cdbs to get it to build; I hit the same problem Petter
saw in B
Package: python-sympy
Version: 1.0-1
Severity: normal
Hi,
In sympy 0.7.5-2 a Conflicts: python-gmpy2 was added to the python-sympy
package to avoid an error in isympy reported in Bug#730975.
This error no longer seems to occur -- presumably due to mpmath having
better special casing:
] $ head -
Source: protobuf-c
Version: 1.0.2-1
Severity: wishlist
Hi,
Any chance the Debian package could be updated to latest upstream? oneof
support would be helpful...
protobuf-c (1.1.0)
* Implement oneof support (Issue #174). Protobuf 2.6.0 or newer is now
required to build protobuf-c.
Cheers,
that add some output as to
what binaries doop_source is actually looking at which seemed helpful)
Cheers,
aj
--
Anthony Towns
diff --git a/britney.py b/britney.py
index 55dd7c3..b254ea7 100755
--- a/britney.py
+++ b/britney.py
@@ -1859,11 +1859,6 @@ class Britney(object):
InstallabilityT
Package: wnpp
Severity: wishlist
Owner: Anthony Towns
* Package name: python-beanbag
Version : 1.9.1
Upstream Author : Anthony Towns
* URL : https://pypi.python.org/pypi/beanbag/
* License : MIT
Programming Lang: Python
Description : Helper module for
Packard:
3. We propose to the DPL that Keith Packard should be appointed
to the TC. (Constitution 6.2(2))
Option Kern:
4. We propose to the DPL that Philipp Kern should be appointed
to the TC. (Constitution 6.2(2))
That seems like a sensible structure to continue to me?
Cheers,
aj
--
Anthony Towns
On Sun, Nov 23, 2014 at 01:25:50PM +0100, Bill Allombert wrote:
> On Sun, Nov 23, 2014 at 01:58:41AM +0000, Anthony Towns wrote:
> > On Sat, Nov 22, 2014 at 12:39:44PM +0500, Andrey Rahmatullin wrote:
> > > On Thu, Nov 12, 2009 at 04:31:52PM -0800, Russ Allbery wrote:
> &g
On 3 November 2014 20:30, Anthony Towns wrote:
> On 3 November 2014 20:22, Julian Andres Klode wrote:
>> A simple way to achieve what you want is to create a local dummy
>> package that depends on the packages you want and is
>> "Essential: yes" or "Import
On 3 November 2014 20:22, Julian Andres Klode wrote:
> A simple way to achieve what you want is to create a local dummy
> package that depends on the packages you want and is
> "Essential: yes" or "Important: yes". Important being preferred, since
> it has less restrictions on installation orderin
Package: apt
Version: 1.0.9.3
Severity: wishlist
Tags: patch
Hi,
It would be useful to be able to locally mark certain packages as
"Essential:yes" so that they are never uninstalled. Trivial example: mark
sysvinit-core as essential on systems you don't want to have upgraded
to systemd as init.
I
On 26 September 2014 00:36, Anthony Towns wrote:
> This bug is reportedly fixed in the new upstream version 0.10.5 about a
> month ago:
Turns out the 0.10.5.1 tarball doesn't actually include the sources
for the minified jquery -- it's just included in git.
gitit 0.10.5.1
tag 736189 + fixed-upstream
thanks
This bug is reportedly fixed in the new upstream version 0.10.5 about a
month ago:
> I've released gitit 0.10.5.
>
> CHANGES:
>
...
> * Add full versions of minified JavaScript (#400) (Peter Gallagher).
-- https://groups.google.com/forum/#!topic/gitit-disc
as seeing the same thing in the previous version of colobot (no
text, but the links were still clickable). It seems fixed for me now,
as of 0.1.3-1.
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe&quo
suckah"
To make that provision work, I think you'd have to have a minimum
voting period, in which case I don't think there's any value beyond
just having a minimum discussion period.
But ultimately, if a majority of the ctte want to vote on a particular
question that's within
ms like
having that be separate from the ctte's duties in general would be a
better plan than allowing discussions to go secret whenever someone
thinks it would be "counterproductive".
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debia
I
don't know how you could do that more effectively; must/should/may
still seems reasonable to me, but it doesn't seem that effective.
Splitting them as three separate documents (distro/release
requirements, policy, suggested practices) might be an option. Maybe
it would be more effect
On Sat, Feb 08, 2014 at 12:56:56PM -0700, Bdale Garbee wrote:
> Bdale Garbee writes:
> > - - - start ballot - - -
> > We exercise our power to decide in cases of overlapping jurisdiction
> > (6.1.2) by asserting that the default init system for Linux
> > architectures in jessie should be
> > D
On 10 February 2014 06:41, Serge Kosyrev wrote:
> False. Three messages on this list brought this conflict of interest
> into light:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810 by Anthony Towns
> [...]
> There was no answer.
So, fwiw, I thought the above was
n that case, wouldn't it make sense to have a quick chat with the
other policy editors about officially delegating the task of deciding
on policy for depending on init systems to the tech ctte?
Could even open a new bug for it!
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-
y allowing
proposals to be blocked by 1/N voters voting for FD where N > 2)
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
er ctte members will also vote FD above
T or DT (given UT is irrelevant); which based on the already expressed
preferences and votes, isn't actually going to happen.
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On 6 February 2014 16:27, Anthony Towns wrote:
> Rankings between remaning actual outcomes is:
> 4x UL > DL > UT > DT (steve, colin, ian, andi)
> 2x DT > DL > UT > UL (russ, don)
Ah! I thought there was something to add here
The above votes divide neatly i
:2
UL > UT > DT 4:2
DL > UT 6:0
It seems to me that if this ballot fails to FD, any future ballots
should skip options:
OT, VT (insufficient support over FD)
OL, VL (at least 6 of 8 committee members prefer UL and DL over
these options)
It seems unlikely that there's
Hey Colin,
On 29 January 2014 21:13, Colin Watson wrote:
> On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
>> > Q2: Is it OK for packages to depend on a specific init system as
>> > pid 1 ?
>> Q2a: Is it OK for packages providing init systems to p
On 2 February 2014 04:05, Uoti Urpala wrote:
> On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote:
>> Sébastien Villemot writes ("Bug#727708: TC resolution revised draft"):
>> > P1: DT > UT > DL > UL
> So his example was one where the D/U and L/T choices were independent
> for every voter,
For
ust be able to apt-get install it and be just as
cool as aj is". I don't think that's a win.
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On 20 January 2014 14:29, Russ Allbery wrote:
> Steve Langasek writes:
>> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
>> For my part I think this is generally a good idea, but I have the
>> impression that at least Russ would be strongly opposed to thi
On 20 January 2014 14:29, Russ Allbery wrote:
> Steve Langasek writes:
>> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
>>> I think (a) and (b) are pretty non-controversial. (c) and (d) are
>>> required if we want to deal with new GNOME stuff and anyt
On 17 January 2014 03:52, Ian Jackson wrote:
> What is Debian ? In one respect, Debian is an operating system. And
> of course in another respect Debian is a community.
> * Debian is a forum for cooperation and technical development.
> * Debian, as a piece of software, tries to be all things to
g myself that in an ideal world I'd
prefer the event model. upstart doesn't seem to implement that
sufficiently though at this point. Sigh, now I'm imagining an event
based init system written in haskell...)
Cheers,
aj
[0] http://upstart.ubuntu.com/cookbook/#restarting-jobs-wi
On 31 December 2013 12:55, Colin Watson wrote:
> The criticisms of Upstart's event model in the systemd position
> statement simply do not make sense to me. Events model how things
> actually happen in reality; dependencies are artificial constructions on
> top of them, and making them work requi
On 15 January 2014 20:36, Martin Pitt wrote:
> It's not realistic for a maintainer to continuously test three init
> systems;
It's not realistic for a maintainer to continuously test against 13
architectures (including three different kernel trees) either. So we
don't do that and instead let main
On Jan 5, 2014 10:40 AM, "Russ Allbery" wrote:
> Anthony Towns writes:
> > How hard would it be to write an external wrapper that converts the
> > systemd style socket activation to the SIGSTOP protocol (for upstart
> > invoking a systemd compatible daemon)?
On s
On Jan 5, 2014 2:39 AM, "Russ Allbery" wrote:
> I'm doubtful that either of us are going to convince the other on this
> point. I don't consider it comparable to the other examples you're
> citing, and I think it's inobvious that raise(SIGSTOP) is a good technical
> choice. Simple, yes, but that
uld/should/would manage.
Forced to make a choice, should Debian go for smoother/tighter
integration between apps, or more choice for users/sysadmins? I'd
expect Debian to choose the latter; though Ubuntu, Red Hat and
possibly Fedora might choose the former.
Cheers,
a "por que no los dos?" j
--
Anthony Towns
Not speaking for my employer...
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Okay, let's see how replying to a mail on my phone while in flight mode
goes. Apologies in advance for formatting, quoting and vocabulary issues.
On Dec 31, 2013 4:48 AM, "Russ Allbery" wrote:
> 2. Impact of Multiple Init Systems
> Obviously, the ideal situation for project-wide integration and
013
> - the latest of these uploads breaks the installer, [...]
Isn't this a rationale for d-i to use the stable builds of syslinux
present in testing (or potentially testing-proposed-updates) rather
than unstable?
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-bugs-dist
pecify the default option to be
+ used, the quorum required, and any supermajority requirements.
B. Use of language and typography
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: openrocket
Version: 1.1.3-1
Severity: wishlist
Tags: patch
Running "openrocket blah.ork" doesn't work, but it does if you change
the wrapper script:
--- /usr/bin/openrocket.old 2010-12-07 14:43:16.0 +1000
+++ /usr/bin/openrocket 2010-12-07 14:43:27.0 +1000
@@ -1,2 +1,2 @
6/07/msg00041.html
Just my 2c, FWIW, HTH, etc.
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
t support for sha1/sha256/crc/... checksums
by just changing one package
- admin has hashes of exactly what was unpacked, no matter the source
- no concerns about bugs in dh_md5sums or similar resulting in bad checksums
Advantages of doing it when uploading:
- provides some sort of double check o
On Sun, Mar 7, 2010 at 10:28, Goswin von Brederlow wrote:
> Anthony Towns writes:
>> Advantages of doing it when uploading:
>> - provides some sort of double check of what's being uploaded
>> - saves CPU time on users' machines
> - avoids having bad ch
Package: sputnik
Version: 9.03.13+1-1
Severity: serious
Justification: Policy 3.5
>From /usr/share/lua/5.1/sputnik/actions/wiki.lua:
require("coxpcall")
But liblua5.1-coxpcall0 isn't listed amongst:
Depends: liblua5.1-wsapi1, liblua5.1-markdown0, liblua5.1-cosmo0,
liblua5.1-fil
Package: liblua5.1-wsapi1
Version: 1.1.0-4
Severity: important
wsapi.cgi has carriage return (^M, \r) characters at end-of-line, which makes
it non-executable because there's no "lua5.1\r" in $PATH:
$ /usr/bin/wsapi.cgi
: No such file or directory
$ /usr/bin/wsapi.cgi 2>&1 |hexdump -C
Package: bugs.debian.org
Severity: wishlist
For browsers that support javascript, it's possible to make pasting
#123456 bug numbers from emails and changelogs slightly easier. Adding
something like the following snippet to the bugs.d.o/ frontpage (ie,
the page on www.d.o that's the target of the r
On Fri, Jan 30, 2009 at 09:14:54PM +0100, Michael Vogt wrote:
> On Sun, Dec 21, 2008 at 10:45:13PM +1000, Anthony Towns wrote:
> > Attached is a patch against apt 0.7.19 (current in lenny/sid)
> > including just the Redirect support from Jeff Licquia's patch in
> > Bug#2
Package: apt
Version: 0.7.19, 0.7.20~exp3
Severity: normal
>From /usr/share/doc/apt/copyright:
] In addition, prior to November 15th, 2000, apt may be distributed under
] terms identical to the above with the following addition:
]
] Works using apt may link against the GUI library "libqt", copyr
Attached is a patch against apt 0.7.19 (current in lenny/sid)
including just the Redirect support from Jeff Licquia's patch in
Bug#212732.
As far as the issues described in Bug#66434 with bad redirection and
mod_speling, that seems mostly unlikely to be a problem these days thanks
to the md5 vali
On Fri, Oct 31, 2008 at 03:52:31PM +0100, Andreas Barth wrote:
> 1. Currently, the submitter claims that the bug is serious, the
> maintainer don't think so, and there is no decision by the release team
> yet. So the current state of the bug isn't serious, but important.
ie, the views (on serious
On Mon, Apr 28, 2008 at 10:26:32AM +0200, Christian Perrier wrote:
> I announced the intent to build and possibly upload a non-maintainer upload
> for this package in order to fix this long-time pending localization
> bug as well as all other pending translations.
Ack, do it. AFAICS your patch lea
reopen 474651
thanks
On Fri, Apr 18, 2008 at 02:06:48PM +0200, Peter Walser wrote:
> It is reproducable and it's just whith:
> $ fakeroot -s fakechroot.save \
> fakechroot /usr/sbin/debootstrap --variant=fakechroot \
> sid /sid http://ftp.ch.debian.org/debian/
Turns out it's reproducible with
]
On Tue, Apr 08, 2008 at 01:45:30PM +1000, Anthony Towns wrote:
> add-bar:
> Previous-Changeset: add-foo
>
> Inserting at the end is trivial (add a new signed changeset, and update
> LAST-CHANGESET), removing from the middle is easy-ish (replace the old
> changeset wit
On Tue, Apr 08, 2008 at 01:45:30PM +1000, Anthony Towns wrote:
> FWIW, attached is something that'll take a directory of changesets
> (".") and either die with an error if there's a problem, or print out
> the order they should be applied in.
*sigh*
Cheers,
aj
#
On Mon, Apr 07, 2008 at 05:19:15PM -0400, Joey Hess wrote:
> > and introduces a Key-Info: section to make it easier to find a changeset
> > just by grepping.
> Some overlap with d-m keycheck info, though I don't think I've ever
> grepped that.
Opaque files just bother me.
> If you have a use case
$ head -n4 /usr/bin/jetring-diff
] #!/usr/bin/perl -w
]
] # Copyright (c) 2007 Anthony Towns
] # GNU GPL; v2 or later
Cheers,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: jetring
Version: 0.12
Severity: wishlist
Tags: patch
The following changes "Action: import" to "Action: import
--import-options=merge-only" for patches that just modify a key, and
introduces a Key-Info: section to make it easier to find a changeset
just by grepping.
For checking keyserve
Package: scribble
Version: 1.10-2
scribble specifies:
] Replaces: scrabble (< 1.10)
] Conflicts: scrabble (< 1.10)
These should be "<=", as per policy 7.1:
] The relations allowed are `<<', `<=', `=', `>=' and `>>' for strictly
] earlier, earlier or equal, exactly equal, later or equal and stri
On Thu, Mar 06, 2008 at 02:56:39PM -0800, Don Armstrong wrote:
> > It's good to have a *command* for "I'm the maintainer of this
> > package (or the submitter of this bug), and this bug is DONE.", but
> > using the done field for that just doesn't work right anymore.
> I think that it can, and shou
On Tue, Mar 04, 2008 at 12:28:51AM -0800, Don Armstrong wrote:
> On Tue, 04 Mar 2008, Anthony Towns wrote:
> > Well, ultimately, the problem's that "done" doesn't really mean all that
> > much anymore -- we've got:
> -done basically means "I'm t
On Mon, Mar 03, 2008 at 01:55:29PM -0800, Don Armstrong wrote:
> On Mon, 03 Mar 2008, Colin Watson wrote:
> > On Mon, Mar 03, 2008 at 10:01:00PM +0100, Steinar H. Gunderson wrote:
> > > On Mon, Mar 03, 2008 at 08:57:25PM +, Colin Watson wrote:
> > > > Blink. Is that a typo? notfixed should be,
On Mon, Mar 03, 2008 at 02:51:10PM -0800, Don Armstrong wrote:
> On Mon, 03 Mar 2008, Colin Watson wrote:
> > Yes, I know - I meant conceptually rather than in detail. notfixed
> > should not leave the bug in a fixed/done-type state.
> The problem is that giving it side effects (reopening the bug)
On Wed, Jan 09, 2008 at 05:58:34PM +1000, Anthony Towns wrote:
> Disallow: /*/ # exclude everything but the shortcuts
> Allow: /cgi-bin/bugreport.cgi?bug=
> Allow: /cgi-bin/pkgreport.cgi?pkg=*;dist=unstable$
> I've set that up on rietz for Googlebot, we&#
On Wed, Jan 09, 2008 at 12:54:32PM -0800, Don Armstrong wrote:
> On Wed, 09 Jan 2008, Anthony Towns wrote:
> > Uh, you're kidding right? The BTS's own search engine won't turn up hits
> > outside the BTS, as a trivial example...
> It's far superior to google
On Wed, Jan 09, 2008 at 05:58:34PM +1000, Anthony Towns wrote:
> Getting smarturl.cgi properly done is still probably the real solution.
Okay, so I've made smaturl.cgi work again; it was broken by:
- Debbugs::CGI not accepting params from ARGV (smarturl.cgi changed
to set QUER
On Thu, Jan 03, 2008 at 01:07:15PM -0800, Don Armstrong wrote:
> There are already mirrors which allow indexing, and you can use the
> BTS's own search engine which is far superior to gooogle [...]
Uh, you're kidding right? The BTS's own search engine won't turn up hits
outside the BTS, as a trivi
On Wed, Dec 19, 2007 at 08:51:08PM +0100, Andreas Henriksson wrote:
> Here's an additional patch on top of the previous in the series. It
> restores backwards compatability for the "hwaddress" option (and drops
> the new lladdress option that was invented for the new syntax).
Ah, I don't think I c
On Tue, Dec 18, 2007 at 02:53:25PM +0100, Andreas Henriksson wrote:
> Here's a bunch of patches to improve ifupdown 0.7~alpha2 (the current version
> in experimental).
> +Depends: net-tools, iproute (>= 20071016-1), [...]
iproute (20071016-1) unstable; urgency=low
...
[ Alexander Wirt ]
*
On Tue, Dec 18, 2007 at 12:24:21PM -0500, Noah Meyerhans wrote:
> This is done. Steffani now has interface eth0.64 with address 18.24.0.11
Hrm, if you had security.debian.org pointing at:
18.24.0.11
212.211.132.032
212.211.132.250
The rule9-prediction scripts says you get:
000.0
On Sat, Dec 15, 2007 at 10:23:50AM -0200, Felipe Augusto van de Wiel wrote:
> I finished working on the scripts that will generate the
> files, we add some tests during the "package" build to reduce the
> checks on the "archive side". The package, .dsc and byhand-ddtp
> are here: http://peopl
On Mon, Dec 17, 2007 at 12:07:04AM +0100, Josip Rodin wrote:
> FWIW, the last reading is:
> * villa 5.33 MB/s
> * lobos 4.92 MB/s
> * steffani 14.58 MB/s
The original was:
> * villa 4.29 MB/s
> * lobos 3.91 MB/s
> * steffani 14.86 MB/s
Interesting that it got somewhat more balanced.
For referenc
On Sun, Dec 16, 2007 at 06:28:39PM +1000, Anthony Towns wrote:
> Going back to steffani, that gives B = 14.86 MB/s - 3.53 MB/s = 11.33 MB/s,
> and we thus have:
> A = 10.59 MB/s
> B = 11.33 MB/s
> C + F = 1.14 MB/s
> D = 0MB/s (by assumption
On Sun, Dec 16, 2007 at 03:45:37AM +0100, Josip Rodin wrote:
> After around 11 hours, we've had:
> * villa 4.29 MB/s
> * lobos 3.91 MB/s
> * steffani 14.86 MB/s
The rule9 prediction was:
A: 000.000.000.000-127.255.255.255: steffani, villa, lobos
B: 128.000.000.000-191.255.255.255: steffani
C: 192
On Sat, Dec 15, 2007 at 10:23:50AM -0200, Felipe Augusto van de Wiel (faw)
wrote:
> The package, .dsc and byhand-ddtp
> are here: http://people.debian.org/~faw/ddtp/
(I haven't looked at this yet)
> Some doubts appear in the process, while writing the byhand
> I realize that you (or other
On Tue, Dec 11, 2007 at 05:50:52PM -0200, Felipe Augusto van de Wiel wrote:
> > I'm still not entirely comfortable with having something outside of
> > ftpmaster determine which translations should be in which suites,
> > but that's something that'll probably need changes in apt-ftparchive
> > to i
On Mon, Dec 10, 2007 at 12:39:34AM -0200, Felipe Augusto van de Wiel (faw)
wrote:
> If I'm not wrong, Anthony did the first upload of the
> Translation files, I'm cc:ing him, he probably can add more
> info on that.
> I think we could use the BYHAND to upload Translation
> files having
On Thu, Dec 06, 2007 at 06:31:50PM +0100, Lo?c Minier wrote:
> On Thu, Dec 06, 2007, Anthony Towns wrote:
> > > Regardless, even requiring debian/rules to be a makefile doesn't
> > > actually do much, because someone could do something like:
> > > .DEFAULT:
On Tue, Jul 10, 2007 at 01:42:03PM -0700, Don Armstrong wrote:
> On Tue, 10 Jul 2007, Russ Allbery wrote:
> > I also could have sworn that we recently tightened this requirement,
> > but I can find no mention of that in changelog with some quick
> > searches. Am I just imagining things?
> It was ti
severity 454461 wishlist
thanks
On Wed, Dec 05, 2007 at 05:27:37PM -0500, Joey Hess wrote:
> Martin Wuertele wrote:
> > Please change the name to debian-maintainers-keyring to match the
> > keyring namespace as used by the following packages:
> > debian-keyring
> > debian-archive-keyring
> > debia
On Tue, Nov 27, 2007 at 09:25:02PM +, Ian Jackson wrote:
> [Option D:]
> (1) The existing libconfig in Debian may retain its name.
The maintainer of that package writes:
] Here's my argument(s). I'll try to keep it short:
]
] a) First come, first serve. I'm both the upstream author an
On Fri, Nov 23, 2007 at 06:56:03PM +0100, Benj. Mako Hill wrote:
> I advocate Asheesh Laroia as a DM. I've been reviewing and uploading
> Asheesh's packages for sometime now and he already done a great job for
> Debian already and will continue to do so a sa DM.
Could people advocating DMs (or pot
; fields. Includes support for in place
+specification of postinst and other maintainer scripts.
+
+ -- Anthony Towns <[EMAIL PROTECTED]> Wed, 07 Nov 2007 14:32:33 +1000
+
equivs (2.0.7-0.0aj1) unstable; urgency=low
* An unuploaded NMU.
diff -Nurb equivs-2.0.7-0.0aj1/usr/bin/equivs-bu
es to include actual files by
+specifying a "Files:" section that contains " src /path/to/dest"
+lines.
+ * Update Standards-Version.
+ * Change debhelper to Build-Depends: for availability in clean target.
+
+ -- Anthony Towns <[EMAIL PROTECTED]> Tue, 06 Nov 2007
On Wed, Oct 17, 2007 at 06:28:23AM -0500, Steve Robbins wrote:
> I guess you're reopening of this bug is related to the UNACCEPT messages
> that I got.
> I am still in the dark about that.
> Could you please let me know what is wrong and what I might need to do to
> fix it?
There was some intern
tag 360066 unreproducible
thanks
I think this is actually due to a typo on the submitter's behalf:
> [EMAIL PROTECTED]:~$ sudo ps
> sudo: unable to lookup az-svr-01 via gethostbyname()
> PID TTY TIME CMD
> 12302 pts/000:00:00 ps
>
> If I change the hostname to azsrv01 sudo is silen
So here's my understanding of where we're at.
First, fact finding. Everything here should be able to be agreed by
everyone.
getaddrinfo() is a new interface that replaces gethostbyname(). It
hasn't different semantics that are intended to make it superior
to gethostbyname() and other functions, b
On Sun, Sep 23, 2007 at 04:21:58AM -0700, Steve Langasek wrote:
> On Fri, Sep 21, 2007 at 01:07:49PM +1000, Anthony Towns wrote:
> > On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
> > > So do you have a use case where you think the behavior described in rule 9
&g
1 - 100 of 172 matches
Mail list logo
