Re: live-wrapper - RFE - Arch boot automatic detection

[Michael .]

I wasn't going to say anything else on this matter until you said this

>Now you're twisting my words.

and then said this

>Yes. At the beginning of this thread you said that live-wrapper
>discussions were unwelcome here and they should be taken elsewhere.

Let's clarify these things for the list reader who you are now leading to
believe something that is not true.
Firstly, I asked a simple question in response to various things stated in
various discussions, your comment brought them altogether. I merely asked
what things were wrong with Live Build. You come back and immediately
accuse me of twisting your words.

Secondly, please quote word for word where I said live-wrapper discussions
were unwelcome here and that they should be taken elsewhere. If you can't,
which I know you can't, I can only assume, quote
>you're twisting my words
end quote.



On 19 November 2015 at 22:13, Ben Armstrong 
wrote:

> On 18/11/15 11:04 PM, Michael . wrote:
> > It is highly unlikely Debian will move alpha software into Stretch
> > when it becomes stable. Jessie is 6 moths old so Testing freeze is
> > possibly 12 months away with Stretech's release approximately 6 months
> > after that. I can only hope Live Wrapper is mature by then.
>
> Don't confuse upstream stage of software development with
> release-readiness from Debian's perspective. There can be release
> critical bugs on 'stable release' software that threatens its removal as
> the next Debian release nears, and conversely, 'alpha stage' software
> can be released, so long as it has no release critical bugs.
>
> packages.debian.org tells me live-build 5.0~a11-1 is in Stretch. Unless
> matters worsen between now and Stretch's release (e.g. RC bugs are filed
> on it and nobody steps up to fix them), it *will* release with Stretch.
> You do not need to speculate on what Debian will or will not do in the
> matter.
>
> > May I ask then what was not sane, what was fragile, and what was
> > unofficial, with regards to Live Build?
>
> Now you're twisting my words. live-wrapper's goal to provide a positive
> contribution to the Debian project is not mutually exclusive with
> live-build continuing to make a positive contribution to the Debian
> project. My statement was in support of the value of their work, not a
> statement of the lack of value live-build. I think live-build has served
> a lot of people well for a long time. It has its quirks, and has not
> always been easy to keep up with, as the development process has
> introduced a constant stream of incompatibilities with prior versions.
> However, as a community, we've dealt with that, and we have nevertheless
> built a lot of awesome things with it.
>
> >
> > >So your answer to moving those discussions quicker is to push the
> > >live-wrapper developers away where they won't bother you?
> >
> > Push them away so they wont bother me?
>
> Yes. At the beginning of this thread you said that live-wrapper
> discussions were unwelcome here and they should be taken elsewhere.
>
> > I've tried to get answers to simple questions, you know answers like
> > "yes we did provide patches and they were ignored-rejected-whatever".
> > If this has, as you appear to be saying and the other team actually
> > did say, "coming for a long time" the logistics of this should have
> > been worked out already. Having these discussions after the fact
> > indicates a whole heap of poor planning.
>
> I understand you find communication about these matters difficult and
> frustrating. I share your frustration. However, the outcome (that Daniel
> quit) was not planned nor desired. From what I can see, it was intended
> that live-wrapper be developed in parallel with live-build until it
> reached maturity and could be used by Debian CD to ultimately replace
> live-build. It appears to have been inevitable in the Debian CD team's
> eyes that they would have to write something to accommodate what they
> saw as the flaws in live-build, but I don't see that it was inevitable
> that live-build development had to cease. That was a decision one person
> made unilaterally and we now have to deal with that.
>
> > >Sorry, I just don't see the need for this. I don't see Debian making
> > >"statements" in other cases where upstreams have given up and Debian has
> > >moved on. At least not unless it's a fairly big piece of infrastructure
> > >with broad impact on the project and a clarifying statement really is
> > >necessary (like libc6). I don't think that's the case in this situation.
> > >I rather think it will work out organically instead, from the people
> > >doing the work from here on to improve the toolset, and will not be
> > >something that comes down as a decree from the top.
> >
> > I must have misunderstood the importance to Debian of having a "Live"
> > system.
>
> I didn't say it wasn't important for Debian to have one. I only spoke to
> the relative importance of libc6 vs. live-build and therefore what sort
> of 

Re: live-wrapper - RFE - Arch boot automatic detection

[Ben Armstrong]

On Nov 19, 2015 3:18 PM, Ben Armstrong  wrote:
> Usually I spend more time trying to detect time problems, 
Argh. Tone* problems (speaking of things slipping by proofing, like tablet keyboard autopredict failures :)

Re: live-wrapper - RFE - Arch boot automatic detection

[Michael .]

Apology accepted and I do admire your efforts for trying to keep things
together.
I hope the community will be kept informed of developments.

On 20 November 2015 at 06:23, Ben Armstrong 
wrote:

>
> On Nov 19, 2015 3:18 PM, Ben Armstrong 
> wrote:
> > Usually I spend more time trying to detect time problems,
> Argh. Tone* problems (speaking of things slipping by proofing, like tablet
> keyboard autopredict failures :)
>

Re: live-wrapper - RFE - Arch boot automatic detection

[Ben Armstrong]

On 19/11/15 07:13 AM, Ben Armstrong wrote:
> On 18/11/15 11:04 PM, Michael . wrote:
>> I must have misunderstood the importance to Debian of having a "Live"
>> system.
> I didn't say it wasn't important for Debian to have one. I only spoke to
> the relative importance of libc6 vs. live-build and therefore what sort
> of official Debian response there needs to be in this situation. Debian
> contains lots of important software, including live-build. Debian does
> not issue official statements about upstream changes for many of them.
> In the specific case of eglibc, a statement was warranted and therefore
> issued because that had broad impact on the project as a whole. I don't
> believe live-build is in the same category because it is a broadly used
> piece of infrastructure that many other Debian packages depend upon. But
> I'll reiterate, this is just my personal opinion.

Sorry, I meant to say here "[live-build] *is not* a broadly used piece
of infrastructure that many other Debian packages depend upon."

That is to say, while live-build is important software, and while it is
important for Debian to have live images, we, the live-build
user/developer community are a tiny fraction of the greater community.

I think if there were a real threat that Debian would somehow not
release with any live images next release, or with poorer quality images
next release, that's an issue Debian as a whole should be concerned
about preventing. I haven't seen any evidence so far that this is a real
threat, for the reasons I have already argued.

Ben

Re: live-wrapper - RFE - Arch boot automatic detection

[Ben Armstrong]

On 18/11/15 11:04 PM, Michael . wrote:
> It is highly unlikely Debian will move alpha software into Stretch
> when it becomes stable. Jessie is 6 moths old so Testing freeze is
> possibly 12 months away with Stretech's release approximately 6 months
> after that. I can only hope Live Wrapper is mature by then.

Don't confuse upstream stage of software development with
release-readiness from Debian's perspective. There can be release
critical bugs on 'stable release' software that threatens its removal as
the next Debian release nears, and conversely, 'alpha stage' software
can be released, so long as it has no release critical bugs.

packages.debian.org tells me live-build 5.0~a11-1 is in Stretch. Unless
matters worsen between now and Stretch's release (e.g. RC bugs are filed
on it and nobody steps up to fix them), it *will* release with Stretch.
You do not need to speculate on what Debian will or will not do in the
matter.

> May I ask then what was not sane, what was fragile, and what was
> unofficial, with regards to Live Build?

Now you're twisting my words. live-wrapper's goal to provide a positive
contribution to the Debian project is not mutually exclusive with
live-build continuing to make a positive contribution to the Debian
project. My statement was in support of the value of their work, not a
statement of the lack of value live-build. I think live-build has served
a lot of people well for a long time. It has its quirks, and has not
always been easy to keep up with, as the development process has
introduced a constant stream of incompatibilities with prior versions.
However, as a community, we've dealt with that, and we have nevertheless
built a lot of awesome things with it.

>
> >So your answer to moving those discussions quicker is to push the
> >live-wrapper developers away where they won't bother you?
>
> Push them away so they wont bother me?

Yes. At the beginning of this thread you said that live-wrapper
discussions were unwelcome here and they should be taken elsewhere.

> I've tried to get answers to simple questions, you know answers like
> "yes we did provide patches and they were ignored-rejected-whatever".
> If this has, as you appear to be saying and the other team actually
> did say, "coming for a long time" the logistics of this should have
> been worked out already. Having these discussions after the fact
> indicates a whole heap of poor planning.

I understand you find communication about these matters difficult and
frustrating. I share your frustration. However, the outcome (that Daniel
quit) was not planned nor desired. From what I can see, it was intended
that live-wrapper be developed in parallel with live-build until it
reached maturity and could be used by Debian CD to ultimately replace
live-build. It appears to have been inevitable in the Debian CD team's
eyes that they would have to write something to accommodate what they
saw as the flaws in live-build, but I don't see that it was inevitable
that live-build development had to cease. That was a decision one person
made unilaterally and we now have to deal with that.

> >Sorry, I just don't see the need for this. I don't see Debian making
> >"statements" in other cases where upstreams have given up and Debian has
> >moved on. At least not unless it's a fairly big piece of infrastructure
> >with broad impact on the project and a clarifying statement really is
> >necessary (like libc6). I don't think that's the case in this situation.
> >I rather think it will work out organically instead, from the people
> >doing the work from here on to improve the toolset, and will not be
> >something that comes down as a decree from the top.
>
> I must have misunderstood the importance to Debian of having a "Live"
> system.

I didn't say it wasn't important for Debian to have one. I only spoke to
the relative importance of libc6 vs. live-build and therefore what sort
of official Debian response there needs to be in this situation. Debian
contains lots of important software, including live-build. Debian does
not issue official statements about upstream changes for many of them.
In the specific case of eglibc, a statement was warranted and therefore
issued because that had broad impact on the project as a whole. I don't
believe live-build is in the same category because it is a broadly used
piece of infrastructure that many other Debian packages depend upon. But
I'll reiterate, this is just my personal opinion.

>
> >What you officially do with your project is up to you. I think it's
> >pretty clear by your own statement that live-wrapper is not ready for
> >you to use, so you ought to continue using live-build for now. What real
> >blocker stands in your way of continuing to use it if it has been
> >working well for you?
>
> Ben, if Live-wrapper is really for me to use please tell me what dist
> it is currently available in so I can use it? I've just done a search
> of Debian Packages and it isn't listed so it isn't ready for me to 

Re: live-wrapper - RFE - Arch boot automatic detection

[Fernando Toledo]

El 18/11/15 a las 20:33, Ben Armstrong escribió:
> On 18/11/15 07:15 PM, Michael . wrote:
>> Correct me if I am wrong but I'm not sure this is the right list for
>> this. Live Wrapper and Live build are 2 separate projects run by, or
>> at least they were until Live Build has been discontinued, 2 differnt
>> groups.
>> If you want to message the Live Wrapper group I suggest you contact
>> Debian CD and ask them what list is appropriate for your ideas and
>> patches.
> 
> I don't see any justification for splitting our pool of expertise across
> two disjoint groups. In coming months we will likely need to have many
> conversations involving both the old and the new, and the resulting
> cross-posting between groups would just be confusing, and hamper
> development going forward.
> 
> Ben

+1

-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

live-wrapper - RFE - Arch boot automatic detection

[adrian15]

1) I make the assumption that live-wrapper currently supports to build 
an x86 system with both a 586 kernel and amd64 kernel in the same iso.


2)  I would like live-wrapper to have support for arch automatic 
detection at boot. That means that the bootloader chooses the right 
kernel depending on the available architecture.


I already did this work for live-build and the commits can be found here:

https://github.com/adrian15/live-build/commit/5852a69976da36abd7bcbbce95807a7a2451a7a6

https://github.com/adrian15/live-build/commit/36f781c4dc55e9a0d14cc74df5ff36f9eac2e33f

3) I don't mind implementing the bits to improve the grub cfg file and 
live cfg file but taking a look at:


https://anonscm.debian.org/cgit/debian-live/live-wrapper.git/tree/lbng/vm.py?id=4c908cd1682f5d15912810a33c71c35a54fc7115

where the detect_kernel function is defined and:

https://anonscm.debian.org/cgit/debian-live/live-wrapper.git/tree/lbng/grub.py?id=4c908cd1682f5d15912810a33c71c35a54fc7115

which it's one of the places where it is used... well...

I need not only what you currently save on version but also the arch... 
not sure how irl wants to implement it, with two variables,... Should I 
parse myself the detect_kernels output and play from there? Should the 
output be two variables ? A dict variable ?



Given these files found:

vmlinuz-3.16.0-4-amd64
vmlinuz-3.16.0-4-586
vmlinuz-3.14.0-1-amd64
vmlinuz-3.14.0-1-586

I need to be able to loop over 3.16.0-4 so that I found that it has two 
architectures. Then if one of them is amd64 I guess I can suppose the 
other one would be 586.


Once that happens I can add my auto entry which if it was a function 
would need to know the kernel filenames and the kernel associated arch.


Additional note: Pae can also be supported by autodetection if pae 
kernels are still available in Debian. I think pae it's supported on 
syslinux but not on grub2.


4) Hopefully this RFE can improve the current live-wrapper design.


adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Re: live-wrapper - RFE - Arch boot automatic detection

[Ben Armstrong]

These opinions are my own and do not represent an official statement by
Debian or any of its subprojects.

On 18/11/15 08:52 PM, Michael . wrote:
> With regards to a couple of points you have made in this, and your
> previous, post nothing about Live Build is clear anymore. Actually
> that is incorrect, the only thing that is clear is Daniel has given up
> with it as a Debian project and as the lead developer it seems Live
> Build as a Debian project is discontinued (remember we were told it
> was deprecated).

Upstream gave up on the project. This is not unique in the software in
Debian. Upstreams give up all the time, for various reasons. And there
doesn't need to be confusion about it. The abandoned software remains in
Debian, and if someone doesn't step up to take it over, it eventually
goes to Debian QA. If someone does take it over, as often happens with
software that is useful for which there is no alternative, then
hopefully it continues to live on in Debian indefinitely under new
leadership.

It's too early yet to know what's happening with it in the longer term.
I think that in a large part depends on the user/developer community's
response to it (i.e. which software they favour with their attention),
and not at all with what Debian does or does not endorse. If development
on live-wrapper is swift, and it gains a following and rapidly becomes
feature complete, it may quickly overtake live-build and come to be
preferred by the community. If it is slow, live-build may dominate for a
while longer. But I cannot possibly predict at this stage which way it
will go.

At the risk of sounding like a broken record ... people are still acting
as though live-build will be imminently removed from Debian or will
suddenly lose support, neither of which are true. There's no reason at
this time to remove it. It is in decent shape, and a significant pool of
developers and users remain who know enough about it that it will for
the time being continue to be supported.

> Your Previous post on the issue of Live build mentioned something
> about people taking Live Build on, has this happened? Are you,
> personally, keeping Live Build going?

I'm not taking a technical leadership role. However, I'm continuing in a
support role for as long as it looks like that is in Debian's best
interest. I have a fair bit of experience with it and try to assist
whenever I can.

> The splitting of the resource pool had happened well before anyone in
> Live Build (thats what the available evidence suggests) or its user
> community new anything about it. Debian CD split the pool of resources
> by making their own project (which they are entitled to do) and not
> assisting Live Build (which they are also entitled to do).

From what I could see, Debian CD made every effort to assist Debian Live
before striking off on their own. They reported problems and provided
patches (some of which, like the UEFI one, were rejected, and no
alternative solution provided for a very, very long time). So I don't
think it's fair to say they "split the resource pool". That could only
be true if they actively pulled the existing Debian Live developers off
the project. That's not what happened. They are now *adding to* what
we've built with live-wrapper, as I understand it using live-boot and
live-config at the core, bringing to the table their own resources, to
try to help Debian (you know, the *whole* project, not two autonomous
projects Debian Live and Debian CD with opposing goals and interests)
have sane, non-fragile official live CD builds. I think that's an
excellent goal, and therefore am in support of their efforts. It's a
more inclusive process than you have portrayed it, which is why I'm
counseling unity here and not divisiveness.

> The discussions in coming months are a rather mute point now aren't
> they? What has happened has happened, what has been said has been
> said, and the users of Live Build are caught in the middle and are
> going to have to either wait for someone to fill them in or move to
> using Live Wrapper (which isn't really usable at the moment). My point
> here is this process of discussions over the coming months really
> needs to be quicker.

So your answer to moving those discussions quicker is to push the
live-wrapper developers away where they won't bother you?

> It is unfair to people who depend on these tools to let this drag on.
> I'm simply not willing to start releasing iso images for a stable
> system for the South Pacific when the tool I've been building it on
> and getting people to test it with is in a state of limbo and the tool
> that is supposed to replace it isn't usable.

To let what drag on? live-build does what it does the same way that it
did last month. It has excellent documentation (if I do say so myself,
having contributed in a large degree to it), and Debian has a process of
NMUs that allows it to continue receiving patches as needed. People are
continuing to help with problems here on the mailing 

Re: live-wrapper - RFE - Arch boot automatic detection

[Michael .]

I apologise for any confusion caused by my previous reply.

With regards to a couple of points you have made in this, and your
previous, post nothing about Live Build is clear anymore. Actually that is
incorrect, the only thing that is clear is Daniel has given up with it as a
Debian project and as the lead developer it seems Live Build as a Debian
project is discontinued (remember we were told it was deprecated). Your
Previous post on the issue of Live build mentioned something about people
taking Live Build on, has this happened? Are you, personally, keeping Live
Build going?

The splitting of the resource pool had happened well before anyone in Live
Build (thats what the available evidence suggests) or its user community
new anything about it. Debian CD split the pool of resources by making
their own project (which they are entitled to do) and not assisting Live
Build (which they are also entitled to do).

The discussions in coming months are a rather mute point now aren't they?
What has happened has happened, what has been said has been said, and the
users of Live Build are caught in the middle and are going to have to
either wait for someone to fill them in or move to using Live Wrapper
(which isn't really usable at the moment). My point here is this process of
discussions over the coming months really needs to be quicker. It is unfair
to people who depend on these tools to let this drag on. I'm simply not
willing to start releasing iso images for a stable system for the South
Pacific when the tool I've been building it on and getting people to test
it with is in a state of limbo and the tool that is supposed to replace it
isn't usable.

If Live Build lives on then great, if it doesn't then so be it. One day
someone in the Debian project will provide some clear statements as to what
is going on and then downstream projects like mine and many others can get
on with their work without wondering if we can keep using the tool we have
taken time to learn how to use or if we have to switch to another "live"
tool and then learn new things.

Until we actually hear something definitive my project is officially on
hold. The 2 "disjoint groups", as you called them, need to have these
discussions and get to work sooner rather than later so the effects of this
mess don't linger on. Please keep us informed.

On 19 November 2015 at 10:33, Ben Armstrong 
wrote:

> On 18/11/15 07:15 PM, Michael . wrote:
> > Correct me if I am wrong but I'm not sure this is the right list for
> > this. Live Wrapper and Live build are 2 separate projects run by, or
> > at least they were until Live Build has been discontinued, 2 differnt
> > groups.
>
> First of all, to clarify, "Live Build has been discontinued" is not yet
> reality. It is slated to be replace as the software to build official
> Debian Live CDs, but that doesn't mean that the software suddenly ceases
> to exist. It will continue to be supported here the best we can, as I've
> written about here before.
>
> In my opinion, this is also the right list to support live-wrapper. It
> is written here:
>
> https://lists.debian.org/debian-live/
>
>
>   Discussion and maintenance of the Debian Live systems
>
> Development of the Debian Live systems (i.e. live cds).
>
>
> The list is run by the Debian project for the purpose of supporting the
> development and maintenance of "the Debian Live systems". That is not
> clearly defined, but by the use of the definite article "the", some
> specific software is implied. Since live-build is the specific software
> that the current Debian Live CDs is built with, and live-wrapper is the
> specific software that the Debian CD team intends to use to replace it,
> it is a reasonable interpretation of "the Debian Live systems" as being
> systems that are built with either software, the old and the new.
>
> > If you want to message the Live Wrapper group I suggest you contact
> > Debian CD and ask them what list is appropriate for your ideas and
> > patches.
>
> I don't see any justification for splitting our pool of expertise across
> two disjoint groups. In coming months we will likely need to have many
> conversations involving both the old and the new, and the resulting
> cross-posting between groups would just be confusing, and hamper
> development going forward.
>
> Ben
>
>
>

Re: live-wrapper - RFE - Arch boot automatic detection

[Michael .]

>These opinions are my own and do not represent an official statement by
>Debian or any of its subprojects.

That clarifies everything for me. You have been, in effect, posting your
opinion but with an appearance of authority. I can respect that as you are
trying to maintain peaceful relations, which is in everyones best interest.

>Upstream gave up on the project. This is not unique in the software in
>Debian. Upstreams give up all the time, for various reasons. And there
>doesn't need to be confusion about it. The abandoned software remains in
>Debian, and if someone doesn't step up to take it over, it eventually
>goes to Debian QA. If someone does take it over, as often happens with
>software that is useful for which there is no alternative, then
>hopefully it continues to live on in Debian indefinitely under new
>leadership.

I'm well aware that abandoned software remains part of Debian for a time
but that is, for me personally at least, besides the point here. Live Build
is in Jessie, Testing, Sid, and even Experimental. Live Wrapper isn't in
anything so it is not usable. If no one picks up the active development of
Live Build how long will it remain in testing? That's a rhetorical question.


>At the risk of sounding like a broken record ... people are still acting
>as though live-build will be imminently removed from Debian or will
>suddenly lose support, neither of which are true. There's no reason at
>this time to remove it. It is in decent shape, and a significant pool of
>developers and users remain who know enough about it that it will for
>the time being continue to be supported.

It is highly unlikely Debian will move alpha software into Stretch when it
becomes stable. Jessie is 6 moths old so Testing freeze is possibly 12
months away with Stretech's release approximately 6 months after that. I
can only hope Live Wrapper is mature by then.

>I'm not taking a technical leadership role. However, I'm continuing in a
>support role for as long as it looks like that is in Debian's best
>interest. I have a fair bit of experience with it and try to assist
>whenever I can.

I, personally, appreciate that.

>From what I could see, Debian CD made every effort to assist Debian Live
>before striking off on their own. They reported problems and provided
>patches (some of which, like the UEFI one, were rejected, and no
>alternative solution provided for a very, very long time).

So they did provide patches, ok I was unaware of that even though I asked
the Debian CD team if they had done that and did not get any response.

>So I don't
>think it's fair to say they "split the resource pool". That could only
>be true if they actively pulled the existing Debian Live developers off
>the project. That's not what happened. They are now *adding to* what
>we've built with live-wrapper, as I understand it using live-boot and
>live-config at the core, bringing to the table their own resources, to
>try to help Debian (you know, the *whole* project, not two autonomous
>projects Debian Live and Debian CD with opposing goals and interests)
>have sane, non-fragile official live CD builds.

May I ask then what was not sane, what was fragile, and what was
unofficial, with regards to Live Build?

>I think that's an
>excellent goal, and therefore am in support of their efforts. It's a
>more inclusive process than you have portrayed it, which is why I'm
>counseling unity here and not divisiveness.

I am in support of a better product, if it can be done. I am not in support
of the way this appeared to have occurred. I am in support of unity which
is why I asked a couple of times did the Debian CD team try to work with
(providing patches etc) the Live Build team which you have answered now.

>So your answer to moving those discussions quicker is to push the
>live-wrapper developers away where they won't bother you?

Push them away so they wont bother me? I've tried to get answers to simple
questions, you know answers like "yes we did provide patches and they were
ignored-rejected-whatever". If this has, as you appear to be saying and the
other team actually did say, "coming for a long time" the logistics of this
should have been worked out already. Having these discussions after the
fact indicates a whole heap of poor planning.

>To let what drag on? live-build does what it does the same way that it
>did last month. It has excellent documentation (if I do say so myself,
>having contributed in a large degree to it), and Debian has a process of
>NMUs that allows it to continue receiving patches as needed. People are
>continuing to help with problems here on the mailing list, and people
>are continuing to help on irc. What, exactly, is the problem with this
>situation? You can continue to build images and projects based on
>live-build until whenever *you* decide it isn't working well for you and
>you want to switch to something else.

And we are back to will Live Build 5 get out of alpha so it can continue? I
know you can't answer 

Re: live-wrapper - RFE - Arch boot automatic detection

[Michael .]

Correct me if I am wrong but I'm not sure this is the right list for this.
Live Wrapper and Live build are 2 separate projects run by, or at least
they were until Live Build has been discontinued, 2 differnt groups.

If you want to message the Live Wrapper group I suggest you contact Debian
CD and ask them what list is appropriate for your ideas and patches.

On 19 November 2015 at 09:51, adrian15  wrote:

> 1) I make the assumption that live-wrapper currently supports to build an
> x86 system with both a 586 kernel and amd64 kernel in the same iso.
>
> 2)  I would like live-wrapper to have support for arch automatic detection
> at boot. That means that the bootloader chooses the right kernel depending
> on the available architecture.
>
> I already did this work for live-build and the commits can be found here:
>
>
> https://github.com/adrian15/live-build/commit/5852a69976da36abd7bcbbce95807a7a2451a7a6
>
>
> https://github.com/adrian15/live-build/commit/36f781c4dc55e9a0d14cc74df5ff36f9eac2e33f
>
> 3) I don't mind implementing the bits to improve the grub cfg file and
> live cfg file but taking a look at:
>
>
> https://anonscm.debian.org/cgit/debian-live/live-wrapper.git/tree/lbng/vm.py?id=4c908cd1682f5d15912810a33c71c35a54fc7115
>
> where the detect_kernel function is defined and:
>
>
> https://anonscm.debian.org/cgit/debian-live/live-wrapper.git/tree/lbng/grub.py?id=4c908cd1682f5d15912810a33c71c35a54fc7115
>
> which it's one of the places where it is used... well...
>
> I need not only what you currently save on version but also the arch...
> not sure how irl wants to implement it, with two variables,... Should I
> parse myself the detect_kernels output and play from there? Should the
> output be two variables ? A dict variable ?
>
>
> Given these files found:
>
> vmlinuz-3.16.0-4-amd64
> vmlinuz-3.16.0-4-586
> vmlinuz-3.14.0-1-amd64
> vmlinuz-3.14.0-1-586
>
> I need to be able to loop over 3.16.0-4 so that I found that it has two
> architectures. Then if one of them is amd64 I guess I can suppose the other
> one would be 586.
>
> Once that happens I can add my auto entry which if it was a function would
> need to know the kernel filenames and the kernel associated arch.
>
> Additional note: Pae can also be supported by autodetection if pae kernels
> are still available in Debian. I think pae it's supported on syslinux but
> not on grub2.
>
> 4) Hopefully this RFE can improve the current live-wrapper design.
>
>
> adrian15
> --
> Support free software. Donate to Super Grub Disk. Apoya el software libre.
> Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
>
>

Re: live-wrapper - RFE - Arch boot automatic detection

[Ben Armstrong]

On 18/11/15 07:15 PM, Michael . wrote:
> Correct me if I am wrong but I'm not sure this is the right list for
> this. Live Wrapper and Live build are 2 separate projects run by, or
> at least they were until Live Build has been discontinued, 2 differnt
> groups.

First of all, to clarify, "Live Build has been discontinued" is not yet
reality. It is slated to be replace as the software to build official
Debian Live CDs, but that doesn't mean that the software suddenly ceases
to exist. It will continue to be supported here the best we can, as I've
written about here before.

In my opinion, this is also the right list to support live-wrapper. It
is written here:

https://lists.debian.org/debian-live/


  Discussion and maintenance of the Debian Live systems

Development of the Debian Live systems (i.e. live cds).


The list is run by the Debian project for the purpose of supporting the
development and maintenance of "the Debian Live systems". That is not
clearly defined, but by the use of the definite article "the", some
specific software is implied. Since live-build is the specific software
that the current Debian Live CDs is built with, and live-wrapper is the
specific software that the Debian CD team intends to use to replace it,
it is a reasonable interpretation of "the Debian Live systems" as being
systems that are built with either software, the old and the new.

> If you want to message the Live Wrapper group I suggest you contact
> Debian CD and ask them what list is appropriate for your ideas and
> patches.

I don't see any justification for splitting our pool of expertise across
two disjoint groups. In coming months we will likely need to have many
conversations involving both the old and the new, and the resulting
cross-posting between groups would just be confusing, and hamper
development going forward.

Ben