Package: wnpp
Severity: wishlist
Owner: Guo Yixuan
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: gcc-4.8-doc
Version : 4.8.0-1
Upstream Author : FSF
* URL : http://gcc.gnu.org/
* License : GFDL-1.3+, with invariant sections
Programming Lang: Tex
Control: reopen -1
Control: reassign -1 release-notes
On Vi, 10 mai 13, 02:43:28, ant wrote:
> Package: general
> Severity: wishlist
>
> Dear Debian,
>
> At the end of a slow line it would still be nice to be able to download only
> the actual binary differences between versions of a package d
Processing control commands:
> reopen -1
Bug #707672 {Done: Paul Wise } [general] general: binary diffs
of large packages
Bug reopened
Ignoring request to alter fixed versions of bug #707672 to the same values
previously set
> reassign -1 release-notes
Bug #707672 [general] general: binary diffs
On Thu, 9 May 2013 15:50:45 +0200, Philipp Kern
wrote:
>On Thu, May 09, 2013 at 10:32:09AM +0200, Marc Haber wrote:
>> That's how I do it for new installs. However, this is vastly more
>> complex than the traditional setup, and it doesn't help for systems in
>> maintenance mode that, for example,
On Thu, 9 May 2013 18:17:29 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 09, "Bernhard R. Link" wrote:
>> Or in other words: to make essential functionality not available if
>> /usr is broken.
>Again: this is not we are discussing. Essential functionality is moving
>to /usr anyway
Which is
Hi,
On Wed, May 08, 2013 at 05:28:58PM +0100, Neil Williams wrote:
> Other steps to take as preventative measures:
> * Make it a *MUST* that all transitions, no matter how small, are
> checked with the release team starting from as soon as the freeze is
> announced (not just after it starts) suc
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung
* Package name: nemo-fileroller
Version : 1.8.0
Upstream Author : Linux Mint Project
* URL : https://github.com/linuxmint/nemo-extensions/
* License : GPL-3 vs LGPL-2+ (COPYING vs source headers)
Program
Package: wnpp
Severity: wishlist
Owner: Oleg Gashev
* Package name: libmodule-faker-perl
Version : 0.014
Upstream Author : Ricardo Signes
* URL : https://metacpan.org/release/Module-Faker/
* License : Artistic or GPL-1+
Programming Lang: Perl
Description
On May 10, Marc Haber wrote:
> Having the rescue image _this_ independent is not really desireable
> since one would probably have to deal with outdated or non-existing
> rescue tools in the independent image while the correct software in
> the correct version is on the system's own / file system
Package: wnpp
Severity: wishlist
Owner: Steven Hamilton
* Package name: mr.rescue
Version : 1.01
Upstream Author : Tangram Games
* URL : http://tangramgames.dk
* License : Zlib, BY-NC-SA 3.0 Unported License, Custom Public Domain
Programming Lang: Lua, Love2
On Fri, May 10, 2013 at 11:48:37AM +0200, Marco d'Itri wrote:
[ reiterating the same arguments seen numerous times before ]
I suggest that we leave practical implications of the /usr merge aside
for a moment. The pros and cons have been discussed at lengths. If there
is value in further arguments,
NEWSLETTER
Boutique
Bienvenue à la newsletter de la maison de disques So Much
Distribution, Distribution Numérique, Téléchargement MusiqueDécouvrez notre
espace boutique pour acheter les CDs de nos Artistes.Bonne visite...
NOUVEAUTE A TELECHARGER
Ricardo BarryBaby-
On Fri, 10 May 2013 11:24:30 +0200
Ivo De Decker wrote:
> Hi,
>
> On Wed, May 08, 2013 at 05:28:58PM +0100, Neil Williams wrote:
> > Other steps to take as preventative measures:
>
> > * Make it a *MUST* that all transitions, no matter how small, are
> > checked with the release team starting
On Fri, 10 May 2013 11:24:30 +0200
Ivo De Decker wrote:
> Hi,
>
> On Wed, May 08, 2013 at 05:28:58PM +0100, Neil Williams wrote:
> > Other steps to take as preventative measures:
>
> > * Make it a *MUST* that all transitions, no matter how small, are
> > checked with the release team starting
Le mercredi 08 mai 2013 à 16:51 +0100, Ian Jackson a écrit :
> * Try to identify the main ways in which bugs can be "hard" (which
>might be technical, political, or a mixture)
One of the general problems I have been running into include several
(sometimes all) of the following patterns.
On Thu, 2013-05-09 at 08:43 +0200, Niels Thykier wrote:
> On 2013-05-09 07:56, Paul Wise wrote:
> > On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote:
> >
> >> I just noticed that we have the first amd64 package in the archive that
> >> has dependencies on :i386 qualified libraries:
> >>
> >>
[Charles Plessy, 2013-05-09]
> For a large number of packages if not all, we should allow the
> package maintainers to manually migrate their packages to Testing during the
> Freeze, within boundaries set on debian-devel-announce by the release team.
+1
or a soft freeze (as described ab
On Thu, May 09, 2013 at 02:08:05PM +0200, Marc Haber wrote:
> You have a point here. The problem is that people need to change their
> operations, which is hard for many people, let alone the case when
> emergency manuals need to be changed just for the sake of satisfying
> Lennart.
There are vari
On Tue, May 07, 2013 at 10:23:52PM +, Thorsten Glaser wrote:
> Gah! Just because the other FLOS idiots are doing it doesn’t mean
> Debian should follow.
Do you also have technical objections or some kind of reasoning behind
this?
--
Regards,
Olav
--
To UNSUBSCRIBE, email to debian-devel-r
On 2013-05-10 14:48, Ben Hutchings wrote:
> On Thu, 2013-05-09 at 08:43 +0200, Niels Thykier wrote:
>> On 2013-05-09 07:56, Paul Wise wrote:
>>> On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote:
>>>
I just noticed that we have the first amd64 package in the archive that
has dependen
On Fri, May 10, 2013 at 03:04:34PM +0200, Olav Vitters wrote:
> On Thu, May 09, 2013 at 02:08:05PM +0200, Marc Haber wrote:
> > You have a point here. The problem is that people need to change their
> > operations, which is hard for many people, let alone the case when
> > emergency manuals need to
On Wednesday, May 08, 2013 04:51:14 PM Ian Jackson wrote:
> So I would like to suggest that we should have a thread where we:
>
> * Try to identify the main ways in which bugs can be "hard" (which
>might be technical, political, or a mixture)
>
> * Try to think of workflows which might over
On Fri, 2013-05-10 at 14:46 +0100, Roger Leigh wrote:
> On Fri, May 10, 2013 at 03:04:34PM +0200, Olav Vitters wrote:
> > On Thu, May 09, 2013 at 02:08:05PM +0200, Marc Haber wrote:
> > > You have a point here. The problem is that people need to change their
> > > operations, which is hard for many
On Fri, 10 May 2013 10:03:46 -0400
Scott Kitterman wrote:
> On Wednesday, May 08, 2013 04:51:14 PM Ian Jackson wrote:
> > So I would like to suggest that we should have a thread where we:
> >
> > * Try to identify the main ways in which bugs can be "hard" (which
> >might be technical, polit
Raphaël wrote:
> I don't think that you're speaking of the same thing. I see no
> information about "X.509 client certificates" in Monkeysphere. It
> offers ways to validate the server certificate (if it's not signed by
> known CA) but it doesn't seem to offer any solution to manage client
> certi
Paul Wise writes:
> On Fri, May 10, 2013 at 3:49 AM, Lars Wirzenius wrote:
>> * Keep testing free of RC bugs.
> I keep packages I (co-)maintain free of RC bugs.
The point isn't what individual developers do, particularly developers who
are extremely well-engaged with the project. The point is
Package: wnpp
Severity: wishlist
Owner: Victor Seva
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* Package name: lua-lemock
Version : 0.6
Upstream Author : Tommy Petterson
* URL : https://github.com/LuaDist/lemock/
* License : MIT
Programming Lang: Lua
D
On Fri, 10 May 2013 11:48:37 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 10, Marc Haber wrote:
>> Having the rescue image _this_ independent is not really desireable
>> since one would probably have to deal with outdated or non-existing
>> rescue tools in the independent image while the cor
On May 10, Marc Haber wrote:
> Additional work necessary to satisfy upstream's bizarre ideas. Why not
> keeping things the way they are now? They work. No need to waste
> developer time.
Why make new releases? bo worked fine, there is no need for new features.
> >People use live CDs for rescue a
I started a thread[1] on maven-user yesterday to try and understand
whether Maven's convenience with binary artifacts extrapolates to
convenience working with source
One of the first answers even suggested I should go and see the Debian
folks (the FTP master's reputation for keeping binary stuff
On Fri, 10 May 2013 19:38:22 +0200, m...@linux.it (Marco d'Itri) wrote:
>So this confirms that a live system like GRML is a good replacement for
>a rescue system, looks like we solved another use case.
You are trying to turn my word around. Bad style of discussion. EOD on
my part, it's another wa
Dear developers,
I am considering activating encryption of popularity-contest submissions
using public key cryptography to protect popcon submission while in transit.
This means
- The popularity-contest package will include a public key that will be used to
encrypt
report.
- The popcon.debian.
On May 03, 2013, at 04:38 PM, Josselin Mouette wrote:
>- source-only uploads
>They are pushed to the buildds, and the produced binaries
>(including arch:all) are put in a staging area (much like
>incoming.d.o). These binaries can be downloaded, but
>the .changes can
Bill Allombert writes ("encrypted popcon submissions"):
> The drawback is the computing cost on the server. Currently we are
> processing about 25000 report each days, which would require about 2
> hours of 'real' CPU time to decrypt, which is too much for
> popov.debian.org. On the other hand this
On Fri, 10 May 2013, Bill Allombert wrote:
> I am considering activating encryption of popularity-contest submissions
> using public key cryptography to protect popcon submission while in transit.
Do you think the benefits outweight the drawback that the admin no
longer can be certain we don't se
Package: general
Severity: normal
-- System Information:
Debian Release: 6.0.7
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_MX.utf8, LC_CTYPE=es_MX.utf8 (charmap=UTF-8)
Shell: /bin/sh linked
Peter Palfrader writes ("Re: encrypted popcon submissions"):
> Do you think the benefits outweight the drawback that the admin no
> longer can be certain we don't send anything we shouldn't?
This is a very good point but it can be easily dealt with: the
encrypted message should have two recipients
On May 05, 2013, at 01:12 AM, Roger Leigh wrote:
>There's definitely an open bug for adding this, and I'll be happy
>for it to be added. It shouldn't be too hard to implement, though
>we would probably want to make it configurable whether the repeat
>build failing should fail the build as a whole
* Peter Palfrader , 2013-05-10, 22:44:
On Fri, 10 May 2013, Bill Allombert wrote:
I am considering activating encryption of popularity-contest
submissions using public key cryptography to protect popcon submission
while in transit.
I think encrypting popcon submissions in an excellent idea.
Le Fri, May 10, 2013 at 10:02:06PM +0200, Bill Allombert a écrit :
>
> I am considering activating encryption of popularity-contest submissions
> using public key cryptography to protect popcon submission while in transit.
Hello Bill,
sorry if it is a naive question: by "public key cryptography"
On Fri, May 10, 2013 at 11:24 PM, Russ Allbery wrote:
> The point isn't what individual developers do, particularly developers who
> are extremely well-engaged with the project. The point is to find ways to
> do this at another level up. Obviously, given the number of RC bugs that
> we had to fi
I think you want to discuss this on the debian-java list instead.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
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/CAKT
Paul Wise writes:
> On Fri, May 10, 2013 at 11:24 PM, Russ Allbery wrote:
>> The point isn't what individual developers do, particularly developers
>> who are extremely well-engaged with the project. The point is to find
>> ways to do this at another level up. Obviously, given the number of RC
On Sat, May 11, 2013 at 8:40 AM, Charles Plessy wrote:
> sorry if it is a naive question: by "public key cryptography", do you mean GPG
> or TLS ?
He is talking about OpenPGP and gpg, TLS wouldn't be helpful since
popcon uses either SMTP or HTTP.
--
bye,
pabs
http://wiki.debian.org/PaulWise
On Sat, May 11, 2013 at 10:42 AM, Russ Allbery wrote:
> I would need to do some research, since I'm not personally familiar with
> everything that's in a blend or a task at the moment. Just off the top of
> my head, though, to pick an area of personal expertise, I don't think
> there's an existin
On Thu, May 09, 2013 at 08:49:51PM +0100, Lars Wirzenius wrote:
> * Remove RC buggy packages sooner rather than later. An RC buggy
> package should be removed at soon as possible: when the bug
> is identified, allow a bit of time for the bug to be verified
> (was it actually an RC bug?), but
Hi
On Fri, May 10, 2013 at 07:42:21PM -0700, Russ Allbery wrote:
> Paul Wise writes:
> > Agreed. Do you have any example use-cases that should block releases but
> > aren't in blends or tasks? Perhaps we need to start some new blends or
> > add new tasks.
>
> I would need to do some research, si
Hello all,
i aks this list because i will now more about the "lost Interrupt 0x50)
error.
A faulty hard disk, makes other Logentries and this disk are replace by
the vendor this disk is a new/refurbished disk.
I have test with other Serverhardware what is happen if i put out the
power cabel
48 matches
Mail list logo
