reassign 642005 live-config
severity 642005 wishlist
thanks
On Sun, 18 Sep 2011, Yami Shi wrote:
Package: general
Severity: grave
Justification: renders package unusable
We use that severity+justification when a bug in a package makes the package
ITSELF unusable.
Configuration errors are
On Sun, 18 Sep 2011, Evgeni Golov wrote:
On 09/18/2011 04:46 PM, Henrique de Moraes Holschuh wrote:
Reassigning to Debian live-config, please reassign elsewhere if
innapropriate. Note that non-live Debian installs have fairly large SHM
limits (kernel default, which is half your RAM
On Fri, 02 Sep 2011, Bastian Blank wrote:
On Thu, Sep 01, 2011 at 06:05:01PM -0300, Henrique de Moraes Holschuh wrote:
Our kernels are not a problem. The Debian mirror in mirrors.kernel.org,
on the other hand... While the apt signature will protect users
downloading packages through
On Fri, 02 Sep 2011, Philipp Kern wrote:
On 2011-09-02, Henrique de Moraes Holschuh h...@debian.org wrote:
On Fri, 02 Sep 2011, Bastian Blank wrote:
On Thu, Sep 01, 2011 at 06:05:01PM -0300, Henrique de Moraes Holschuh
wrote:
Our kernels are not a problem. The Debian mirror
(debian-kernel dropped from CC, since our kernels have already been reported
to be safe elsewhere in the thread).
On Thu, 01 Sep 2011, Christoph Anton Mitterer wrote:
Any knowledge how far Debian's kernels and sources are concerned by this?
Do you guys take them from git, or from the kernel.org
On Mon, 29 Aug 2011, Brian May wrote:
On 27 August 2011 06:38, Henrique de Moraes Holschuh h...@debian.org wrote:
And I do think it is at least a serious bug for libgpg-error-dev to drop its
static lib when there are rdepends that require it (dar). But I am not sure
about this one
On Fri, 26 Aug 2011, Brian May wrote:
The dar package is accumulating a number of easy to fix bugs, however
due to a change in another package, it will no longer build anymore.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632889
The only thing I can find in the changelog is from a
On Sat, 20 Aug 2011, Russell Coker wrote:
On Sat, 20 Aug 2011, Adam Borowski kilob...@angband.pl wrote:
It seems to me that the only problem is if you run multiple instances of
a daemon on different ports and don't use /etc/bindresvport.blacklist,
SE Linux, or some other method of
On Sat, 20 Aug 2011, Andreas Barth wrote:
* Henrique de Moraes Holschuh (h...@debian.org) [110820 14:39]:
Yes. And we can easily maintain a current one for Debian-packaged software,
although the initial build of such a blacklist will take some work.
Actually, the existing interface
On Sat, 13 Aug 2011, Andreas Barth wrote:
Resulting packages
All binary packages built need to be functionally working, and follow
the standard for packages on ftp-master. This means they could e.g.
miss documentation (as long as they are not RC-buggy, i.e. they need
to have changelog and
On Sat, 16 Jul 2011, Joost Yervante Damad wrote:
I just orphaned openMSX and related packages:
openmsx, openmsx-catapult, openmsx-debugger, pasmo, cbios.
Anyone interested in taking over might want to look at them as a
cluster.
Hmmm, it has been a long time since I paid attention to my
On Thu, 07 Jul 2011, Paul Wise wrote:
On Wed, 2011-07-06 at 20:12 -0300, Henrique de Moraes Holschuh wrote:
On Thu, 07 Jul 2011, Paul Wise wrote:
Does Debian have any space related software?
Yes.
Do you know of any specific packages?
apt-cache shows a lot of them, keywords orbital
On Thu, 07 Jul 2011, Paul Wise wrote:
On Wed, Jul 6, 2011 at 12:21 PM, Maxime Chatelle m...@gmx.com wrote:
This annonce may be interresting. :)
It's a gsoc-like, but by european space agency.
http://sophia.estec.esa.int/socis2011/
Does Debian have any space related software?
Yes.
If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 18 Jun 2011 00:12:54 -0300
Source: rng-tools
Binary: rng-tools
Architecture: amd64 source
Version: 2-unofficial-mt.14-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
de Moraes Holschuh h...@debian.org
Description:
intel-microcode - Processor microcode data file for Intel CPUs
Changes:
intel-microcode (0.20110428-1) unstable; urgency=low
.
* New upstream data file: microcode-20110428
+ New Microcodes:
sig 0x000206a7, pf mask 0x12, 2011-04-07
On Sun, 19 Jun 2011, Milan P. Stanic wrote:
On Sun, 2011-06-19 at 20:28, Paul Wise wrote:
On Sun, Jun 19, 2011 at 8:02 PM, Steffen Moeller wrote:
* Package name : raccoon
That is one letter away from racoon, the IPsec IKE keying daemon. I
wonder if that would be too confusing of
Package: wnpp
Severity: normal
I request assistance with maintaining the rng-tools package. I am
upstream for the package, but it needs downstream-care which I have
not been providing it with due to limited time.
The package description is:
The rngd daemon acts as a bridge between a Hardware
On Mon, 13 Jun 2011, Andrei POPESCU wrote:
On Du, 12 iun 11, 21:44:37, Henrique de Moraes Holschuh wrote:
#602694 needs to stay open and blocking zookeeper from Squeeze until it
has a maintainer team that is confident they will be able to handle the
stable support and also confident
retitle 626020 zookeeper: incorrect dependency information
thanks
On Sun, 12 Jun 2011, Ted Dunning wrote:
I just looked at this bug and it looks like a configuration error in
the environment rather than a bug in Zookeeper per se.
In particular, Java = 1.6 is an explicit requirement of the
On Sun, 12 Jun 2011, Ansgar Burchardt wrote:
The interested party might also not know how packages are maintained
in Debian. And I don't think it is helpful to threaten upstream with
removal of his software from Debian, certainly not in the first answer.
Please be a bit less aggressive.
Eh,
On Sun, 12 Jun 2011, Ted Dunning wrote:
Ted Dunning ted.dunn...@gmail.com writes:
There has been a bit of talk about Apache Zookeeper recently by Thomas
Koch. He has a bad opinion of Zookeeper and things it is not good
enough for Debian.
Could you please provide a reference?
How
On Sun, 05 Jun 2011, Jonas Smedegaard wrote:
On 11-06-05 at 05:39am, Vincent Bernat wrote:
On Sat, 4 Jun 2011 21:54:11 +0200, Jonas Smedegaard wrote:
What I do is use upstream provided tarballs, then put aside
autotools-generated files, then autogenerate myself, and in the clean
rule
On Sun, 05 Jun 2011, Jonas Smedegaard wrote:
On 11-06-05 at 09:48am, Henrique de Moraes Holschuh wrote:
On Sun, 05 Jun 2011, Jonas Smedegaard wrote:
On 11-06-05 at 05:39am, Vincent Bernat wrote:
On Sat, 4 Jun 2011 21:54:11 +0200, Jonas Smedegaard wrote:
What I do is use upstream
On Mon, 30 May 2011, Marco d'Itri wrote:
On May 30, Ben Hutchings b...@decadent.org.uk wrote:
There are likely to be many programs and build scripts that test for a
kernel version prefix of '2.6' vs '2.4' and will behave incorrectly when
they find '3.0'. Others require that there are at
On Mon, 23 May 2011, Paul Wise wrote:
On Mon, May 23, 2011 at 7:47 AM, Goswin von Brederlow goswin-...@web.de
wrote:
The only advantage of this would be for systems that firewall outgoing
mail conections but allow http or have a http proxy but no smarthost.
There are a *lot* of ISPs that
On Tue, 17 May 2011, Matthias Klose wrote:
Assuming we can't just do away with i486 support for now, did anyone track
down exactly what was causing breakages that forced the change from
march=486 to march=586?
libgomp assumes 586; there were some GFortran/OMP issues on i386.
assumes 586 is
On Tue, 17 May 2011, Christoph Anton Mitterer wrote:
For that reason, the situation that initscripts are
still around but the daemon/application they start/stop/whatever isn't,
is quite common. And it would be absurd if initscripts would exit wit $?
!= 0 in that case.
Here the problem is
On Tue, 17 May 2011, Jonas Meurer wrote:
I tire of this thread. There are apparently bugs in the initscripts, well,
if that's correct, just get them fixed. Then, the package will not allow
itself to be removed with crypt disks still active in the first place.
It'd have to switch to
On Sun, 15 May 2011, Jonas Meurer wrote:
- But if the package is installed and removed (but not purged) some
additional caution should be taken. I'd suggest using e.g. debconf (with a
should? We hardly hand-hold our users that much. You have removed the
package, all functionality it
On Sun, 15 May 2011, Mike Hommey wrote:
I just found out that gcc is compiled with --with-arch-32=i586, which
effectively means it builds with -march=i586 by default (and that it
still claims an i486-linux-gnu target).
I'm wondering. Is the project at large aware that we're not building for
On Sun, 15 May 2011, Ben Hutchings wrote:
On Sun, 2011-05-15 at 09:28 -0300, Henrique de Moraes Holschuh wrote:
On Sun, 15 May 2011, Mike Hommey wrote:
I just found out that gcc is compiled with --with-arch-32=i586, which
effectively means it builds with -march=i586 by default
On Sun, 15 May 2011, Christoph Anton Mitterer wrote:
And honestly, I don't see much of a difference with the warnings
when removing the running kernel or are there any bigger
problems that modules that should be newly loaded would not be
found?!
An immediate panic makes it impossible for
On Mon, 16 May 2011, Christoph Anton Mitterer wrote:
With the most recent upload (and this is the very reason why I've reopened
the bug), you can have the situation (package removed but not pruged) where
you say:
/etc/init.d/cryptdisks stop
and it gives you just $? = 0, as
On Mon, 16 May 2011, Ben Hutchings wrote:
I think any claim that Debian supports 486-class processors is more of
an aspiration. What maintainer has the time to test on such antiques
regularly?
Well, nobody is running regular kernel regression testing on 486-class
hardware AFAIK, and that
On Sat, 14 May 2011, Tollef Fog Heen wrote:
]] Kurt Roeckx
| On Sat, May 14, 2011 at 04:55:01PM +0100, Roger Leigh wrote:
| Packages using /etc
|/etc/adjtime
|
| That file should probably not be in /etc in the first place,
| but be somewhere under /var/lib. Since FHS 2.2 it even
On Wed, 11 May 2011, Dominic Hargreaves wrote:
Sorry but if you alternate physical possession of a laptop with someone whom
you suspect of being hostile, no files are secure as long as they're stored
on that laptop.
This is not necessarily the case if a per-user encrypted filestore,
such
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 11 May 2011 04:41:20 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20110511.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Mon, 09 May 2011, Vincent Danjean wrote:
On 08/05/2011 17:33, Martin Zobel-Helas wrote:
i currently wonder if Debian should implement RFC 4941 as default for
wheezy.
[...]
I would like to hear other developers meanings to this issue, before
proposing this as release goal for wheezy.
On Mon, 09 May 2011, Bjørn Mork wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
We've been trying to avoid that kind of bad practice here in Brazil,
through an effort to get ISPs to undertand you do NOT issue /64 to
clients in the various NANOG-like (locally called GTER
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 08 May 2011 19:44:58 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20110508.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Sat, 07 May 2011, Enrico Weigelt wrote:
* Henrique de Moraes Holschuh h...@debian.org schrieb:
Yes. I think it was Cyrus IMAP that required -I in places where
autoreconf doesn't reach, so I called each tool separately. Which is
obviously a problem in autoreconf.
Is it really
On Sat, 07 May 2011, Tollef Fog Heen wrote:
| The problem is that autoreconf offers NO command line options for you to
| pass the required -I parameters for aclocal, nor is there a way to encode
| that information in the one place where it could conveniently live
| (configure.ac) AFAIK.
On Fri, 06 May 2011, Stanisław Findeisen wrote:
Because we do not enable pam_wheel by default, so it is not needed by
default.
Heh, that's what this question is about. :-)
Then ask it directly :-p
Restricting certain privileges (like su root) to certain users only
looks more secure than
On Fri, 06 May 2011, Chris Warburton wrote:
Hi Scott. ocPortal isn't massively widespread compared to other systems,
so there's obviously less experimental proof of security. We had a
security hole a few years ago; this was before I got involved, but
there's details here
On Fri, 06 May 2011, Stanisław Findeisen wrote:
Why is there no wheel group by default in Debian GNU/Linux?
Because we do not enable pam_wheel by default, so it is not needed by
default.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness
On Tue, 26 Apr 2011, James Vega wrote:
Why assume the first version will be = 1.x? It's not uncommon to use
0.x. Using 0~YYMMDD seems a safer option to reduce the chance of
needing an epoch if/when upstream starts using actual version numbers.
The 0.DATE thing is from before we had support
On Tue, 26 Apr 2011, Uoti Urpala wrote:
This branch of the thread was NOT about packages that use date ONLY. Maybe
that's what you were confused about above? The version would still need the
last release name too, as in 15.3.2~rc3+svn2005010112.
The two possibilities showed up in the
On Tue, 26 Apr 2011, Ondřej Surý wrote:
4. Build-Depends - Depends (aka invalid listing in Build-Depends)
http://wiki.debian.org/BerkeleyDB/InvalidBuild-Depends
Packages in list 4 should be fixed because it means either one of:
1. The Build-Depends listing is erroneous (f.e. upstream
On Wed, 27 Apr 2011, Julian Andres Klode wrote:
I hereby request comments on changing APT to pre-depend on
${shlibs:Depends}. The reason is simple:
When we upload a new version of APT, depending on a newer
library version (due to new symbols, whatever), and APT gets
On Tue, 26 Apr 2011, Uoti Urpala wrote:
Henrique de Moraes Holschuh hmh at debian.org writes:
On Tue, 26 Apr 2011, Adam Borowski wrote:
Telling someone the bug is in a version I pulled from the VCS but didn't
bother noting down which version it was is not very useful.
Now you're
On Tue, 26 Apr 2011, Chow Loong Jin wrote:
On 26/04/2011 01:50, Gunnar Wolf wrote:
Anyway - Summing up what I'm saying here, tags have a clear meaning: A
point where upstream wants us to base our efforts at, mid-devel-cycle
breakage should be at a minimum. So, instead of basing our packages
On Tue, 26 Apr 2011, Adam Borowski wrote:
Telling someone the bug is in a version I pulled from the VCS but didn't
bother noting down which version it was is not very useful.
Now you're being silly.
All you need is the proper date and time to use as a version (for
ordering), and a proper
On Sun, 24 Apr 2011, Moritz Mühlenhoff wrote:
[Followup-To: nach gmane.linux.debian.devel.general gesetzt.]
Philipp Kern tr...@philkern.de schrieb:
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-23, Dominic Hargreaves d...@earth.li wrote:
On Sat, Apr 23, 2011 at
On Sat, 23 Apr 2011, Cyril Brulebois wrote:
Ben Hutchings b...@decadent.org.uk (23/04/2011):
I would like to see policy forbid the use of commit hashes in
versions. They aren't ordered, and the information about exactly
which commit the snapshot was can be included in the changelog.
On Sat, 16 Apr 2011, Lars Wirzenius wrote:
On pe, 2011-04-15 at 21:58 -0300, Henrique de Moraes Holschuh wrote:
Symlinks in system path components REALLY are best avoided.
Out of curiosity: why?
Because not everything is blind to what it is transversing to get to the
inode a path refers
On Fri, 15 Apr 2011, Roger Leigh wrote:
{ find var/run/ ! -type d -print0; \
find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
I'm afraid this will need fixing in util-vserver(?) though. We can't
work around this in initscripts postinst, I'm afraid, since it worked
On Sat, 16 Apr 2011, Roger Leigh wrote:
On Fri, Apr 15, 2011 at 08:59:01PM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 15 Apr 2011, Roger Leigh wrote:
{ find var/run/ ! -type d -print0; \
find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
I'm afraid
On Sun, 03 Apr 2011, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
On Thu, 31 Mar 2011, Goswin von Brederlow wrote:
/etc/adjtime
This needs to survive reboots, and it is also needed early in the boot.
It is used to correct the RTC syndrome.
I am
On Thu, 31 Mar 2011, Steve McIntyre wrote:
On Wed, Mar 30, 2011 at 09:54:49AM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 30 Mar 2011, Steve McIntyre wrote:
I think so. The package with long names tend to follow a naming policy
that sort of imposes the long name... so if we put a too
On Thu, 31 Mar 2011, Roger Leigh wrote:
/etc/adjtime
This needs to survive reboots, and it is also needed early in the boot.
It is used to correct the RTC syndrome.
I am at a loss about how it could be made compatible with RO /.
/etc/hosts.deny (written by denyhosts, hence
On Thu, 31 Mar 2011, Henrique de Moraes Holschuh wrote:
On Thu, 31 Mar 2011, Roger Leigh wrote:
/etc/adjtime
This needs to survive reboots, and it is also needed early in the boot.
It is used to correct the RTC syndrome.
I am at a loss about how it could be made compatible
On Wed, 30 Mar 2011, Steve McIntyre wrote:
I think so. The package with long names tend to follow a naming policy
that sort of imposes the long name... so if we put a too-short limit
then we're asking them to make an exception in the naming policy.
So what's a reasonable name length limit
On Thu, 31 Mar 2011, Goswin von Brederlow wrote:
/etc/adjtime
This needs to survive reboots, and it is also needed early in the boot.
It is used to correct the RTC syndrome.
I am at a loss about how it could be made compatible with RO /.
/etc/hosts.deny (written by denyhosts, hence that one
On Tue, 29 Mar 2011, Dominique Dumont wrote:
On Monday 28 March 2011 19:43:52 Henrique de Moraes Holschuh wrote:
So, we have to either accept source-only uploads with the knowledge that
some people will upload even more crap, or don't accept source-only
uploads at all
On Mon, 28 Mar 2011, Bernd Zeimetz wrote:
On 03/28/2011 04:37 PM, Mark Hymers wrote:
The main decision which needs to be made is whether, as a project, we
want source only uploads or to throw away DD built non-all debs.
There's not entire agreement amongst the ftpmasters about this (I err
On Sun, 27 Mar 2011, Joerg Jaspert wrote:
- As there have been intermittent problems with the current tool which
generates the pdiff files (on occasion causing us to have to restart
the whole diff series), we looked into improving the situation. We
finally came up with the idea to store
On Sun, 27 Mar 2011, Joerg Jaspert wrote:
Right now the source contents of unstable has, unpacked, 220MB. (Packed
gzip its 28MB, while the binary contents per have each have 18MB
packed).
That should not be a problem in any non-joke box. Unless you'll run it
in a memory-constrained vm or
On Thu, 17 Mar 2011, Paul Wise wrote:
Does your autogen.sh script ever become anything more than calling
autoreconf with some specific options?
Yes. I think it was Cyrus IMAP that required -I in places where
autoreconf doesn't reach, so I called each tool separately. Which is
obviously a
On Thu, 17 Mar 2011, Andreas Tille wrote:
On Thu, Mar 17, 2011 at 04:09:25PM +0800, Paul Wise wrote:
Agreed. That would usually not be something that would cause enough
problems for a new tar.gz to be warranted though.
I just accept your opinion that repackaging is not warranted and I did
On Thu, 17 Mar 2011, Andreas Tille wrote:
Assume please the following:
1. Unpack upstream source, copy debian/ dir into it
2. make -f debian/rules clean
You should have looked for a get-orig-sources target, first. You just
skipped any orig source conditioning the maintainer had to do.
On Thu, 17 Mar 2011, Sean Finney wrote:
autofoo stuff examines timestamps on various files, so it's possible
that if configure gets patched before configure.ac, and
AM_MAINTAINER_MODE is set to a specific value, that ./configure ends up
wanting to regenerate ./configure at build time. double
On Fri, 18 Mar 2011, Russell Coker wrote:
On Fri, 18 Mar 2011, Goswin von Brederlow goswin-...@web.de wrote:
On a machine with lots of RAM (== disk cache...) and high I/O load, you
don't want to do a (global!) sync(). This can totally kill the machine
for 20min or more and is a big no
On Tue, 15 Mar 2011, Julien Cristau wrote:
On Tue, Mar 15, 2011 at 17:52:31 +0100, Bernd Zeimetz wrote:
And for packages you either have to do stable updates all the time, or
add an additional repository, or use unstable on a server. Whatever you
prefer.
Not to mention debian mirrors
On Tue, 15 Mar 2011, Josue Abarca wrote:
What about?:
From: /usr/share/doc/autotools-dev/README.Debian.gz
Example autogen.sh and debian/rules files can be found in
/usr/share/doc/autotools-dev/examples. Do not use them as-is. Rather,
properly customize your own.
And look at the dates of
On Wed, 16 Mar 2011, Neil Williams wrote:
On Tue, 15 Mar 2011 23:35:59 +
Ben Hutchings b...@decadent.org.uk wrote:
On Tue, Mar 15, 2011 at 10:55:54PM +, Neil Williams wrote:
Other tools, like svn-buildpackage, don't have this problem, via the
mergeWithUpstream support and/or a
On Fri, 11 Mar 2011, Martin Zobel-Helas wrote:
On Fri Mar 11, 2011 at 13:11:52 -0600, Gunnar Wolf wrote:
I was prodded by my Chilean friend, Germán Póo-Caamaño, to help find a
way to push the tzdata corrections needed for Chile's change of
timezone plans. Trying to do so, I found he already
On Fri, 11 Mar 2011, Adam D. Barratt wrote:
On Fri, 2011-03-11 at 16:54 -0300, Henrique de Moraes Holschuh wrote:
On Fri, 11 Mar 2011, Martin Zobel-Helas wrote:
On Fri Mar 11, 2011 at 13:11:52 -0600, Gunnar Wolf wrote:
Chile was supposed to leave the Summer daylight savings period
On Wed, 02 Mar 2011, Tollef Fog Heen wrote:
]] Henrique de Moraes Holschuh
| Actually, we usually use it to *remove* bogus rpath, but hey, it would
| be a poor tool if it couldn't be used to add a proper rpath :)
It doesn't know how to add an rpath, just change or remove one. Patches
On Sun, 27 Feb 2011, Steve Langasek wrote:
On Sun, Feb 27, 2011 at 03:29:05PM -0600, Raphael Geissert wrote:
On Sun, Feb 27, 2011 at 02:41:32PM -0600, Raphael Geissert wrote:
If you ask me, I would say that providing a magic for file(1) as I said
on debian-arm[1] would be more useful
On Mon, 28 Feb 2011, Olaf van der Spek wrote:
places. So if you want /usr/local/bin binaries to see /usr/local/lib
by default (that's what Debian and other Linux systems do, on purpose),
then all your system binaries will see them too. Anyway, it's not a
bug or even really a design flaw
On Mon, 28 Feb 2011, Olaf van der Spek wrote:
Sure. But Sergey has a good point: why are there no bin and lib inside
/home so normal users can safely install software without risking
AFAIK, there are strong security concerns. You cannot have unprotected
directories in the default linker paths.
On Tue, 22 Feb 2011, Joey Hess wrote:
Russ Allbery wrote:
Joerg Jaspert jo...@debian.org writes:
Right. For now I undo this (with next dinstall run), until either one of
the following happens:
- lenny is gone and the tools are fixed in squeeze with a point
update (provided
On Mon, 14 Feb 2011, Josselin Mouette wrote:
You must specify the encoding of your data in your bitstreams. I agree
this is inconvenient (and one of the things I dislike in Python), but it
is:
1. completely independent of the locale (UTF8 or not)
2. easy to work with once you
On Mon, 14 Feb 2011, Tollef Fog Heen wrote:
That would mean limiting each init system to the limitations of the most
limited init system, which would be a sad state of affairs. Also, I
Yes. So, we also have to set where we want the low bar.
don't believe there's a 1:1 correspondence between
On Sun, 13 Feb 2011, brian m. carlson wrote:
On Sun, Feb 13, 2011 at 06:00:11PM +, Lars Wirzenius wrote:
That's something I don't understand. If I upload a broken package, why
should it be the buildd admin's job to deal with it? Should not I get
notified of the error, and told to fix
On Fri, 11 Feb 2011, Lars Wirzenius wrote:
However, I'm curious: is there a lot of software that is broken with
Unicode, particularly with the UTF-8 encoding? I can't remember anything
much in recent times.
1. Stuff that cannot do one of UTF-8, UTF-16 or UCS-4.
2. Anything that cannot deal
On Sat, 12 Feb 2011, Adam Borowski wrote:
On Fri, Feb 11, 2011 at 08:16:54PM -0200, Henrique de Moraes Holschuh wrote:
2. Anything that cannot deal with Supplementary planes.
This includes the use of UCS-2 instead of UTF-16, as it cannot represent
the Supplementary planes. python
On Wed, 09 Feb 2011, John Goerzen wrote:
On 02/08/2011 05:04 PM, Hamish Moffatt wrote:
Similar AX.25 tools call and listen were renamed in 2007 to ax*
(package ax25-apps), because those names were too generic (according to
the changelog).
... resulting in considerable confusion from many
On Mon, 07 Feb 2011, Jonathan Nieder wrote:
As you may know[0], there are currently two packages in Debian
experimental providing a node binary.
[0] http://lists.debian.org/debian-devel/2010/08/msg00568.html
...
One is from the node.js project. It was renamed from server to
node on March
On Tue, 01 Feb 2011, Thijs Kinkhorst wrote:
On Mon, January 31, 2011 18:09, Christian PERRIER wrote:
However, upstream's policy in their stable branches is alway to only
fix important bugs (they don't call them this way...but the
definition is fairly close to Debian's). So, *in the case of
Package: wnpp
Severity: wishlist
Owner: Henrique de Moraes Holschuh h...@debian.org
* Package name: iucode-tool
Version : 0.5
Upstream Author : Henrique de Moraes Holschuh h...@debian.org
* URL : none yet
* License : GPL v2 or later
Programming Lang: C
On Mon, 24 Jan 2011, Yaroslav Halchenko wrote:
Alternatively, version of dpkg could be lowered and functionality
conditioned on the version of dpkg (thus implementing necessary logic to
support older versions), it would imho be better and more flexible to
please those backport-lovers, saving
de Moraes Holschuh h...@debian.org
Description:
intel-microcode - Processor microcode data file for Intel CPUs
Changes:
intel-microcode (0.20101123-1) unstable; urgency=low
.
* New upstream data file: microcode-20101123
+ New Microcodes:
sig 0x06fb, pf mask 0x20, 2010-10-03
Ted,
Thanks for the reply and detailed analysis.
Which gets me back to the question of use cases. When are we going to
be using this monster? For many use cases, where the original reason
Where implicit rollbacks are desireable, I suppose. It is incompatible
with edit-in-place, anyway.
On Sun, 02 Jan 2011, Ted Ts'o wrote:
And of course, Olaf isn't actually offerring to implement this
hypothetical O_ATOMIC. Oh, no! He's just petulently demanding it,
even though he can't give us any concrete use cases where this would
actually be a huge win over a userspace safe-write
On Sun, 02 Jan 2011, Olaf van der Spek wrote:
On Sun, Jan 2, 2011 at 1:52 PM, Henrique de Moraes Holschuh
h...@debian.org wrote:
Olaf, O_ATOMIC is difficult in the kernel sense and in the long run. It
is an API that is too hard to implement in a sane way, with too many
boundary conditions
On Fri, 31 Dec 2010, Olaf van der Spek wrote:
Ah, hehe. BTW, care to respond to the mail I send to you?
There is nothing more I can add to this thread. You want O_ATOMIC. It
cannot be implemented for all use cases of the POSIX API, so it will not
be implemented by the kernel. That's all there
On Wed, 29 Dec 2010, Olaf van der Spek wrote:
Writing a temp file, fsync, rename is often proposed. However, the
It is:
write temp file (in same directory as file to be replaced), fsync temp
file[1], rename (atomic), fsync directory[2].
[1] Makes sure file data has been commited to backend
On Thu, 30 Dec 2010, Olaf van der Spek wrote:
On Thu, Dec 30, 2010 at 12:46 PM, Henrique de Moraes Holschuh
h...@debian.org wrote:
write temp file (in same directory as file to be replaced), fsync temp
What if the target name is actually a symlink? To a different volume?
Indeed. You have
On Thu, 30 Dec 2010, Olaf van der Spek wrote:
The reason I asked for a kernelland solution is because it's hard if
not impossible to do properly in userland. But some kernel devs (Ted
and others) don't agree. They reason that the desire to preserve all
meta-data isn't reasonable by itself.
It
501 - 600 of 1562 matches
Mail list logo
