On Wed, Jul 19, 2017 at 3:59 PM, Holger Levsen wrote:
> I dont even see how there would
> be much delay, if we had the policy of say requiring a debian-cd upload
> (to sid) with the changes made to create the stable upload.
Sid likely won't work here because both sid and testing may get ahead
of
Holger Levsen writes ("Re: Debian built from non-Debian sources"):
> On Tue, Jul 18, 2017 at 09:50:48PM +0200, Bernd Zeimetz wrote:
> > So do I understand it right that you are actively going to test the CD
> > build process in a long enough time before the release and se
On Tue, Jul 18, 2017 at 09:50:48PM +0200, Bernd Zeimetz wrote:
> So do I understand it right that you are actively going to test the CD
> build process in a long enough time before the release and send patches
> in time to make sure the changes will be part of the release?
>
> If not - please stop
Steve McIntyre writes ("Re: Debian built from non-Debian sources"):
> There are several repos involved. They're described at the DebianCD
> team wiki page
> https://wiki.debian.org/Teams/DebianCd
> which is itself linked from the top-level of our download area at
On Tue, Jul 18, 2017 at 07:15:47PM +0100, Ian Jackson wrote:
>Steve McIntyre writes ("Re: Debian built from non-Debian sources"):
>> For the record, all the changes I'm talking about go into public git
>> with all of the configuration and scripting that we use on
On Tue, Jul 18, 2017 at 9:15 PM, Ian Jackson
wrote:
> Steve McIntyre writes ("Re: Debian built from non-Debian sources"):
>> For the record, all the changes I'm talking about go into public git
>> with all of the configuration and scripting that we use on our image
&
On 07/18/2017 03:12 AM, Jonas Smedegaard wrote:
> I do not say you are doing it wrong.
>
> I say we(!) can do better. I can do better if I can repreat your work
> using Debian components. I can more confidently verify that I did not
> mess things up if I can mimic with a higher degree your wor
Steve McIntyre writes ("Re: Debian built from non-Debian sources"):
> For the record, all the changes I'm talking about go into public git
> with all of the configuration and scripting that we use on our image
> building machine.
For me, this is the important part. (Ther
On Tue, 18 Jul 2017, Alexey Salmin wrote:
> No one can volunteer to fix it until it's acknowledged this is worth
> fixing.
If you think it's worth fixing, you can volunteer yourself to fix it.
That would look something like:
"I'm interested in helping make sure that THINGY happens. Would
patches
alexey.sal...@gmail.com wrote:
>On Tue, Jul 18, 2017 at 2:09 AM, Steve McIntyre wrote:
>> Making images often requires tweaks to the build script at/near
>> release time. The archive continues to be a moving target until very
>> close to that time. More than once we've fixed things or added
>> wor
On Tue, Jul 18, 2017 at 4:51 PM, Scott Kitterman wrote:
>
>
> On July 18, 2017 8:41:43 AM EDT, Alexey Salmin
> wrote:
>>On Tue, Jul 18, 2017 at 2:09 AM, Steve McIntyre
>>wrote:
>>> Making images often requires tweaks to the build script at/near
>>> release time. The archive continues to be a mo
On July 18, 2017 8:41:43 AM EDT, Alexey Salmin wrote:
>On Tue, Jul 18, 2017 at 2:09 AM, Steve McIntyre
>wrote:
>> Making images often requires tweaks to the build script at/near
>> release time. The archive continues to be a moving target until very
>> close to that time. More than once we've f
On Tue, Jul 18, 2017 at 2:09 AM, Steve McIntyre wrote:
> Making images often requires tweaks to the build script at/near
> release time. The archive continues to be a moving target until very
> close to that time. More than once we've fixed things or added
> workarounds in the image generation scr
Steve McIntyre writes ("Re: Debian built from non-Debian sources"):
> Making images often requires tweaks to the build script at/near
> release time. The archive continues to be a moving target until very
> close to that time. More than once we've fixed things or added
&g
On Tue, Jul 18, 2017 at 9:09 AM, Steve McIntyre wrote:
> Making images often requires tweaks to the build script at/near
> release time. The archive continues to be a moving target until very
> close to that time. More than once we've fixed things or added
> workarounds in the image generation scr
Quoting Steve McIntyre (2017-07-18 02:32:11)
> On Tue, Jul 18, 2017 at 02:04:04AM +0200, Jonas Smedegaard wrote:
> >Quoting Steve McIntyre (2017-07-18 01:09:43)
> >> I've corrected several of your incorrect assertions already. I'm bored
> >> of this.
> >
> >Your arrogant attitude hurts!
>
> I'm *
On Tue, Jul 18, 2017 at 02:04:04AM +0200, Jonas Smedegaard wrote:
>Quoting Steve McIntyre (2017-07-18 01:09:43)
>> I've corrected several of your incorrect assertions already. I'm bored
>> of this.
>
>Your arrogant attitude hurts!
I'm *sorry* if you're hurt. Look at it from my point of view. You'
Quoting Steve McIntyre (2017-07-18 01:09:43)
> I've corrected several of your incorrect assertions already. I'm bored
> of this.
Your arrogant attitude hurts!
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me free
Jonas wrote:
>Quoting Steve McIntyre (2017-07-17 02:00:25)
>
>> But a *lot* of the infrastructure we use to run Debian is not exactly
>> what's been packaged, as already mentioned. Look at dak. debian-cd,
>> live-wrapper et al *are* packaged, but we're not *necessarily* using
>> the exact code t
]] Ian Jackson
> Russ Allbery writes ("Re: Debian built from non-Debian sources"):
> > I think it would be interesting to strive for making available all Debian
> > infrastructure in our archives (although I think you may find that you'll
> > need a separat
Jonas Smedegaard writes:
> I still believe that libisofs are closer tied to our product than to our
> surrounding services: We (or derivatives) may upgrade/replace/skip
> Apache or dak or Alioth and still deliver an identical product, but
> upgrading libisofs may directly cause an image to fail o
Quoting Steve McIntyre (2017-07-17 02:00:25)
> Jonas wrote:
> >Quoting Steve McIntyre (2017-07-16 22:14:29)
> >> Jonas wrote:
> >> >Quoting Andrey Rahmatullin (2017-07-16 19:28:06)
> >> >> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard
> >> >> wrote:
> >> >> > Is our install images exc
On Mon, Jul 17, 2017 at 12:09:30AM +0200, Christian Seiler wrote:
> [...] downstreams should be able to reproduce Debian images.
> In the short term only in functionality and not bit-by-bit, but I
> would consider reproducible image builds a worthwhile long-term goal
> after fully reproducible pack
Russ Allbery writes ("Re: Debian built from non-Debian sources"):
> I think it would be interesting to strive for making available all Debian
> infrastructure in our archives (although I think you may find that you'll
> need a separate archive that doesn't correspond t
Steve McIntyre writes:
> Jonas wrote:
>> It was just an example, however, and my real question was generally
>> what governs code we distribute outside packages - i.e. our install
>> images, if Debian Policy covers only packages.
> Go argue with the Policy folks, I guess.
Speaking as one of the
Jonas wrote:
>Quoting Steve McIntyre (2017-07-16 22:14:29)
>> Jonas wrote:
>> >Quoting Andrey Rahmatullin (2017-07-16 19:28:06)
>> >> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard wrote:
>> >> > Is our install images excepmt from our Policy that all dependencies
>> >> > must
>> >> >
On 07/16/2017 11:12 PM, Jonas Smedegaard wrote:
> It was just an example, however, and my real question was generally what
> governs code we distribute outside packages - i.e. our install images,
> if Debian Policy covers only packages.
I don't know if this is actually in Policy or not, but in m
Quoting Steve McIntyre (2017-07-16 22:14:29)
> Jonas wrote:
> >Quoting Andrey Rahmatullin (2017-07-16 19:28:06)
> >> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard wrote:
> >> > Is our install images excepmt from our Policy that all dependencies must
> >> > be in Debian, or am I mistak
Jonas wrote:
>Quoting Andrey Rahmatullin (2017-07-16 19:28:06)
>> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard wrote:
>> > Is our install images excepmt from our Policy that all dependencies must
>> > be in Debian, or am I mistaken that we have such Policy?
>> Do we? The Debian Poli
On Sun, Jul 16, 2017 at 08:12:55PM +0200, Jonas Smedegaard wrote:
> > > Is our install images excepmt from our Policy that all dependencies must
> > > be in Debian, or am I mistaken that we have such Policy?
> > Do we? The Debian Policy covers only debs.
> > Also, dak isn't in the archive either.
Quoting Andrey Rahmatullin (2017-07-16 19:28:06)
> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard wrote:
> > Is our install images excepmt from our Policy that all dependencies must
> > be in Debian, or am I mistaken that we have such Policy?
> Do we? The Debian Policy covers only deb
On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard wrote:
> Is our install images excepmt from our Policy that all dependencies must
> be in Debian, or am I mistaken that we have such Policy?
Do we? The Debian Policy covers only debs.
Also, dak isn't in the archive either.
--
WBR, wRAR
Hi,
I wonder it can be that our netinst image uses a version of libisofs
which seemingly was never packaged for Debian:
$ isoinfo -d -i firmware-9.0.0-amd64-netinst.iso
CD-ROM is in ISO 9660 format
System id:
Volume id: Debian 9.0.0 amd64 n
Volume set id:
Publisher id:
Data preparer id: XORR
33 matches
Mail list logo
