On Thu, Apr 06, 2017 at 09:46:55AM +0200, Cyril Brulebois wrote:
> Alexander Sosedkin (2017-04-06):
> > That's one way to think about it. Got it, keeping old modules is hard.
> > But I wasn't asking about keeping old modules, I see no point in this.
> > I was asking about generating and publishing
Alexander Sosedkin (2017-04-06):
> That's one way to think about it. Got it, keeping old modules is hard.
> But I wasn't asking about keeping old modules, I see no point in this.
> I was asking about generating and publishing a matching
> dists/testing/main/installer-/current on kernel upload.
> W
On Thu, Apr 06, 2017 at 10:01:41AM +0700, Alexander Sosedkin wrote:
> On Thu, 6 Apr 2017 00:05:17 +0200
> Cyril Brulebois wrote:
>
> > That's unfortunate, yes, but there's no easy way to keep old packages
> > around in a given repository.
>
> That's one way to think about it. Got it, keeping old
On Thu, 6 Apr 2017 00:05:17 +0200
Cyril Brulebois wrote:
> That's unfortunate, yes, but there's no easy way to keep old packages
> around in a given repository.
That's one way to think about it. Got it, keeping old modules is hard.
But I wasn't asking about keeping old modules, I see no point in
Alexander Sosedkin (2017-04-05):
> > Added tag(s) stretch-ignore.
>
> Whatever it means, it sounds very wrong.
>
> I see you guys like discussing workarounds, but how about, you know,
> actually publishing the correct kernel for netboot in the repo?
> Somebody used to do that, why isn't it the c
> Added tag(s) stretch-ignore.
Whatever it means, it sounds very wrong.
I see you guys like discussing workarounds, but how about, you know,
actually publishing the correct kernel for netboot in the repo?
Somebody used to do that, why isn't it the case now?
http://debian.backend.mirrors.debian.o
On Mon, Mar 27, 2017 at 12:54:18PM +0100, Ian Campbell wrote:
> > > One can always use http://snapshot.debian.org/ as one's mirror and
> > specify a dated URL that matches the ISO's creation date.
> I think (based on the last few paragraphs in the "Usage" section of
> that URL) that one would also
On Mon, 2017-03-27 at 13:32 +0200, Philip Hands wrote:
> > Alexander Sosedkin writes:
>
> > On Mon, 27 Mar 2017 12:43:40 +0200
> > > > Philipp Kern wrote:
> >
> > > Even if we'd leave the old kernel udebs in testing for a while, you'd
> > > still hit a point where we'd need to drop them and ol
On Mon, 27 Mar 2017 13:32:46 +0200
Philip Hands wrote:
> Alexander Sosedkin writes:
>
> > On Mon, 27 Mar 2017 12:43:40 +0200
> > Philipp Kern wrote:
> >
> >> Even if we'd leave the old kernel udebs in testing for a while,
> >> you'd still hit a point where we'd need to drop them and old
> >>
Alexander Sosedkin writes:
> On Mon, 27 Mar 2017 12:43:40 +0200
> Philipp Kern wrote:
>
>> Even if we'd leave the old kernel udebs in testing for a while, you'd
>> still hit a point where we'd need to drop them and old installers
>> would break.
>
> I can see that it's impossible to support dow
On Mon, 27 Mar 2017 12:43:40 +0200
Philipp Kern wrote:
> Even if we'd leave the old kernel udebs in testing for a while, you'd
> still hit a point where we'd need to drop them and old installers
> would break.
I can see that it's impossible to support downloading modules for all
old ISOs.
But
On 2017-03-27 11:56, Nye Liu wrote:
The reason I ask is because I have custom grub menu configs that I
don't want to constantly hand edit or patch on a cron job along with a
cron to download the dailies... and then have no idea if the cron will
do the right thing, or if the daily even works. I'd
Thanks for your response.
On Sun, 26 Mar 2017 18:31:45 +0200 Philipp Kern wrote:
> IOW: Is there a way to guarantee that
> (dist)/main/installer-amd64/current/images/netboot/netboot.tar.gz does not
> contain a kernel that has no modules package IN THAT SAME mirror?
>
> Or maybe even an automate
On 03/14/2017 10:34 PM, Nye Liu wrote:
> On Tue, Mar 14, 2017 at 08:39:31PM +, Ben Hutchings wrote:
>> On Tue, 2017-03-14 at 11:36 -0700, Nye Liu wrote:
>>> The only apparent solution is to have the kernel maintainers coordinate
>>> with the d-i maintainers so that whatever kernel is used in d
On Tue, Mar 14, 2017 at 08:39:31PM +, Ben Hutchings wrote:
> On Tue, 2017-03-14 at 11:36 -0700, Nye Liu wrote:
> > The only apparent solution is to have the kernel maintainers coordinate
> > with the d-i maintainers so that whatever kernel is used in d-i is NOT
> > removed from the package re
On Tue, 2017-03-14 at 11:36 -0700, Nye Liu wrote:
> The only apparent solution is to have the kernel maintainers coordinate
> with the d-i maintainers so that whatever kernel is used in d-i is NOT
> removed from the package repository and its mirrors.
The kernel maintainers already coordinate wi
The only apparent solution is to have the kernel maintainers coordinate
with the d-i maintainers so that whatever kernel is used in d-i is NOT
removed from the package repository and its mirrors.
This really should be marked grave or serious because it means net
install is completely broken.
18 matches
Mail list logo
