Hi,
On Thu, 29 Aug 2013, Ansgar Burchardt wrote:
> Lucas Nussbaum writes:
> > Is there a reason why we couldn't have incoming.d.o apt-able without
> > lowering the dinstall frequency?
>
> That is also possible, however fewer dinstall runs mean less data to
> push to mirrors and to archive on sna
Bernd Zeimetz writes:
> On 08/29/2013 12:13 AM, Ansgar Burchardt wrote:
>> Lucas Nussbaum writes:
>>> Is there a reason why we couldn't have incoming.d.o apt-able without
>>> lowering the dinstall frequency?
>>
>> That is also possible, however fewer dinstall runs mean less data to
>> push to mi
Am 29.08.2013 09:38, schrieb Raphael Hertzog:
Can we separate dinstall and pushing to the mirrors ?
Yes we can, but I don't see the need for dinstall without pushing the
mirrors.
The reason why we want to keep dinstall running often are notably:
- closing bug earlier
Not needed. Happens
On Thu, Aug 29, 2013 at 09:38:55 +0200, Raphael Hertzog wrote:
> The reason why we want to keep dinstall running often are notably:
> - closing bug earlier
bugs are closed in cron.unchecked, which runs every 15 minutes.
> - informing users/developers earlier that updates are available (even
>
2013/8/29 Dmitrijs Ledkovs :
> Can dinstall be run every hour please? For me, if anything dinstall is
> not frequent enough.
No, dinstall takes more than an hour to finish...
> If it takes longer than hour to execute, can it be optimised and sped up?
... and even if it can be reduced, there are
Hi,
On Tue Aug 27, 2013 at 02:11:56 +0200, Thomas Goirand wrote:
> On 08/26/2013 12:33 PM, Neil McGovern wrote:
> > I'm hoping that these raising of hands are also offers to help do the
> > work to make it happen.
> >
> Guys, if you want it to happen, raise your hands *now* like Gustavo did.
> O
On 29 August 2013 10:55, Luca Falavigna wrote:
> 2013/8/29 Dmitrijs Ledkovs :
>> Can dinstall be run every hour please? For me, if anything dinstall is
>> not frequent enough.
>
> No, dinstall takes more than an hour to finish...
>
Ok.
>> If it takes longer than hour to execute, can it be optimi
Hi
Is incoming.debian.org mirrored? From my end (UK) it looks like it's
hosted in the USA, well 17 hops away with a ~10% packet loss along
the
way (could be blocked mtr/pings)
Its not, what should it be mirrored for currently. Thats part of this
thread,
if we make it apt-able, THEN it will
]] Dmitrijs Ledkovs
> Is incoming.debian.org mirrored?
No.
> Can incoming be mirrored on e.g. eu & jp UploadQueue boxes?
We'd probably not set up mirroring of it, no. We'd make it more easily
available through other means, as outlined in the initial mail.
--
Tollef Fog Heen
UNIX is user fri
On Thu, Aug 29, 2013 at 11:59 AM, Martin Zobel-Helas wrote:
> I am raising my hand here. I am willing to support the debian security
> team. I will be able to do that during my paid work time, as my
> employer, credativ, is backing this.
>
> Mid-term goal should be a Debian LTS version, but we can
Hi,
please start with helping supporting the current stable release better:
http://udd.debian.org/bugs.cgi?release=wheezy&rc=1 shows 255 RC bugs in
wheezy, just four months after this counter was basically at zero.
Output from my (sadly currently still "internal") tool:
$ udd-tracker.sh
udd-
On Wednesday 28 August 2013 22:58:03 Joerg Jaspert wrote:
> * Have incoming.debian.org be an apt-able location (actually the buildd
>locations, so it is suite/archive specific, not one global queue)[1]
Are the package signatures verified at this point ?
All the best
--
https://github.com/
2013/8/29 Dominique Dumont :
> Are the package signatures verified at this point ?
Yes. Packages are listed in incoming.d.o after they have been accepted by dak.
Cheers,
Luca
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact lis
Steve Langasek writes ("Update policies for security bugs [Was, Re: Dreamhost
dumps Debian]"):
> I don't think this is incompatible with my contention that updates for
> security bugs should be driven by the security team. If we think a security
> fix should not be pushed *immediately* to users,
Raphael Hertzog writes ("Re: Less dinstall FTW?"):
> It's probably a good idea to run dinstall more often but to push to
> mirrors only once or twice a day. That would probably imply keeping
> already processed packages for an entire day on incoming.d.o as well
> so that they don't disappear there
Adam Borowski writes ("Re: UTF-8 in jessie"):
> Let's take a look at some sheets.
Last time I looked at this I found a copy of the actual ASCII
standards document from 1968 or so and it did mention this usage.
> > I don't think that better UTF-8 support should involve needlessly
> > converting 7-
On Wed, Aug 28, 2013 at 04:33:38PM +0200, Ondřej Surý wrote:
> On Wed, Aug 28, 2013 at 4:29 PM, Michael Meskes wrote:
> > Anyhow, I doubt we can reasonably expect to maintain *all* packages for a
> > longer
> > period. How about starting with a defined list of packages that we do care
> > about in
Hi,
as I have seen some confusion what this change means in practice and
most answers ignored the second part of the proposal, here are some more
explanations:
dinstall and unchecked runs
---
The archive processes uploads every 15 minutes ("cron.unchecked"). At
this time
Quoting Ian Jackson (2013-08-29 13:56:09)
> Adam Borowski writes ("Re: UTF-8 in jessie"):
> > Let's take a look at some sheets.
>
> Last time I looked at this I found a copy of the actual ASCII
> standards document from 1968 or so and it did mention this usage.
>
> > > I don't think that better
On Thu, Aug 29, 2013 at 12:30 PM, Dmitrijs Ledkovs wrote:
> I don't want to build packages using local apt repository of uploads,
> since e.g. I don't want to upload something that was build against
> earlier uploaded $foo, which got rejected by ftp-masters for example.
> Currently, it's sometim
On Thu, Aug 29, 2013 at 2:39 PM, Ansgar Burchardt wrote:
> The open question is if having earlier (easy) access to uploads is
> worthwhile or
That would only make sense if buildds would be given access to i.d.o, and I
consider this to be very dangerous (so I am not proposing this, juste
mention
Ansgar Burchardt wrote:
> In comparison the changing part of unstable:
>
> $ du -shc dists/unstable/*/{binary-*,source,Contents*.gz} | tail -1
> 665Mtotal
>
> So having two dinstall runs per day compared to four would reduce the
> amount of changes by roughly 1.3 GB per day. Mirrors also
On Thu, Aug 29, 2013 at 2:08 PM, Michael Meskes wrote:
> On Wed, Aug 28, 2013 at 04:33:38PM +0200, Ondřej Surý wrote:
> > On Wed, Aug 28, 2013 at 4:29 PM, Michael Meskes
> wrote:
> > > Anyhow, I doubt we can reasonably expect to maintain *all* packages
> for a
> > > longer
> > > period. How abou
Ian Jackson wrote:
> Please let's not do this. Doing this would mean that after an upload
> there would be an even longer period where the archive database says
> that sid has version X but in fact it's difficult to find a copy of
> version X anywhere because the main archive and mirrors still hav
Ansgar Burchardt writes ("Re: Less dinstall FTW?"):
> as I have seen some confusion what this change means in practice and
> most answers ignored the second part of the proposal, here are some more
> explanations:
Thank you for the clear explanation. I'm much less confused.
> The latter is proba
Jonas Smedegaard writes ("Re: UTF-8 in jessie"):
> I believe the underlying issue is the one summarized here:
> https://en.wikipedia.org/wiki/Typewriter_apostrophe#ASCII_encoding
Yes.
> How about we simply mention explicitly that `arcane quoting' - even if
> arguably related to UTF-8 encoding,
On Aug 29, 2013 10:30 AM, "Ondřej Surý" wrote:
>
> On Thu, Aug 29, 2013 at 2:39 PM, Ansgar Burchardt
wrote:
>>
>> The open question is if having earlier (easy) access to uploads is
>> worthwhile or
>
>
> That would only make sense if buildds would be given access to i.d.o, and
I consider this to
Joerg Jaspert wrote:
> Now there are those of us who think that this is against "the spirit" of
> having multiple dinstalls and that having apt-able incoming repositories
> will only lead to people with "versionitis" repeatedly abuse apt-get
> update, and not actually help development significantly
On Thu, Aug 29, 2013 at 12:08:09PM -0400, Joey Hess wrote:
> I am disturbed by the repeated use of this disparaging "versionitis" term
> in this thread.
>
> Wanting to be able to rapidly iterate as we develop a very complicated
Key word: we
The issue is, users will think "Oh sure, this'll be a g
Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru
* Package name: iwsy
Version : 3.3
Upstream Author : Dean Sturtevant
* URL : http://code.google.com/p/include-what-you-use/
* License : University of Illinois/NCSA Open Source License
Programming Lang: C
Joey Hess, le Thu 29 Aug 2013 12:08:09 -0400, a écrit :
> I am disturbed by the repeated use of this disparaging "versionitis" term
> in this thread.
>
> Wanting to be able to rapidly iterate as we develop a very complicated
> distribution is not "verionitis".
The word is not about that usage, bu
Ansgar Burchardt wrote:
> The more interesting part of the proposal has so far been ignored by
> most replies: we would make the incoming.d.o archive public. This would
> mean all new uploads are available after ~15 minutes via APT, a lot
> faster than the current interval between dinstall runs.
>
Paul Tagliamonte wrote:
> Key word: we
>
> The issue is, users will think "Oh sure, this'll be a great way to get
> packages! Faster is better, right?"
Users are part of the development and testing infrastructure of Debian.
(Disparaging our users is another problem some of us seem to have..)
--
Quoting Ian Jackson (2013-08-29 18:03:22)
> Jonas Smedegaard writes ("Re: UTF-8 in jessie"):
>> I believe the underlying issue is the one summarized here:
>> https://en.wikipedia.org/wiki/Typewriter_apostrophe#ASCII_encoding
>
> Yes.
>
>> How about we simply mention explicitly that `arcane quoti
On Thu, Aug 29, 2013 at 12:33:26PM -0400, Joey Hess wrote:
> Users are part of the development and testing infrastructure of Debian.
>
> (Disparaging our users is another problem some of us seem to have..)
While I agree in general, this is *not* a slight against our users. I
would never dare. Seri
Jonas Smedegaard writes ("Re: UTF-8 in jessie"):
> Quoting Ian Jackson (2013-08-29 18:03:22)
> > Jonas Smedegaard writes ("Re: UTF-8 in jessie"):
> >> I believe the underlying issue is the one summarized here:
> >> https://en.wikipedia.org/wiki/Typewriter_apostrophe#ASCII_encoding
...
> My aim was
Ian Jackson writes:
> Jonas Smedegaard writes ("Re: UTF-8 in jessie"):
>> How about we simply mention explicitly that `arcane quoting' - even if
>> arguably related to UTF-8 encoding, should be classified not as
>> release-critical bugs but as spelling errors.
> I don't think it is a bug. What
Holger Levsen schrieb:
> please start with helping supporting the current stable release better:
Indeed, actions speak louder than words. Here's four specific packages,
where the security team could need some help for an oldstable-security
update:
- mysql-5.1 needs to be updated to 5.1.71
- Seve
Thanks for pointing this out, I have missed it on first read.
In that case I still don't see a strong reason why to have a public apt-getable
i.d.o.
Ondřej Surý
> On 29. 8. 2013, at 18:06, James McCoy wrote:
>
>
> On Aug 29, 2013 10:30 AM, "Ondřej Surý" wrote:
> >
> > On Thu, Aug 29, 2013 a
On Thu, Aug 29, 2013 at 04:21:43PM +0200, Ondřej Surý wrote:
> On Thu, Aug 29, 2013 at 12:30 PM, Dmitrijs Ledkovs wrote:
> > I don't want to build packages using local apt repository of uploads,
> > since e.g. I don't want to upload something that was build against
> > earlier uploaded $foo, whi
On 08/27/2013 06:53 AM, Pau Garcia i Quiles wrote:
>
> stable. Having a team of people like Mike, Michael, Gustavo, me, etc
> to take care of EVERY package is plain impossible, especially if we
> want 5 years
i didn't say EVERY package i say the packages we care about
we simply don't have the manp
On 13318 March 1977, Uoti Urpala wrote:
>> So maybe 3293-3926 MB per day, i.e. about half of the actual package
>> changes.
> Could dinstall frequency vary by architecture? Most of the benefit in
> frequent dinstall runs comes from AMD64, but most of the cost comes from
> unimportant architectures
On 13318 March 1977, Ondřej Surý wrote:
>> The open question is if having earlier (easy) access to uploads is
>> worthwhile or
> That would only make sense if buildds would be given access to i.d.o, and I
> consider this to be very dangerous (so I am not proposing this, juste
> mentioning it).
Yo
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 532 (new: 8)
Total number of packages offered up for adoption: 149 (new: 0)
Total number of packages request
Package: wnpp
Owner: gregor herrmann
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libapp-fatpacker-perl
Version : 0.009018
Upstream Author : Karen Etheridge
* URL : https://metacpan.org/release/App-FatPack
Package: wnpp
Owner: gregor herrmann
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libmodule-reader-perl
Version : 0.002000
Upstream Author : Graham Knop
* URL : https://metacpan.org/release/Module-Reader
*
Excerpts from Vincent Bernat's message of 2013-06-01 03:24:02 -0700:
> ❦ 1 juin 2013 00:44 CEST, Steve Langasek :
>
> >> start on (local-filesystems and net-device-up IFACE!=lo)
> >> stop on runlevel [016]
> >
> > FYI, it's strongly recommended to use 'start on runlevel [2345]' here as the
> >
Excerpts from Russ Allbery's message of 2013-08-27 13:47:01 -0700:
> Clint Byrum writes:
>
> > Perhaps you missed the blog post [1] details?
>
> > "About ten months ago, we realized that the next installation of Debian
> > was upcoming, and after upgrading about 20,000 machines since Debian 6
>
Excerpts from John Paul Adrian Glaubitz's message of 2013-06-01 03:52:51 -0700:
> On 06/01/2013 12:24 PM, Vincent Bernat wrote:
> > I don't know how systemd behaves in this way (so this is not something
> > to hold against upstart), but there are so many daemons that need to be
> > started after th
Clint Byrum writes:
> Dreamhost is a hosting company. It actually is quite possible that all
> 20,000 machines mentioned are unique snowflakes in this case. Though it
> is probably more likely that there at most 10,000 unique machines, with
> some customers having only one, but others having 3 or
50 matches
Mail list logo
