Re: Bug#906016: transition: gjs built with mozjs60

2018-12-24 Thread Ben Hutchings
On Mon, 2018-12-24 at 12:01 +, Simon McVittie wrote:
> On Sun, 23 Dec 2018 at 16:29:31 +0100, John Paul Adrian Glaubitz wrote:
> > Can we postpone the decision until after the holidays? Then I have enough
> > time for trying to whip up a patch.
> 
> That seems fine, but please note that most of the changes necessary to
> remove gjs from s390x happened some time ago (in late September and early
> October); so if you are able to make mozjs60 work correctly on s390x,
> we will likely already need to revert some changes to bring it back.
> If the d-i maintainers remove gjs/GNOME Shell on s390x and then you
> subsequently get mozjs60 working on s390x, the list of changes to revert
> to bring back gjs/s390x just becomes slightly longer.
> 
> I'm also not at all sure whether the GNOME Shell environment works
> on s390x hardware, which as far as I know doesn't have either a
> Mesa-supported GPU or the llvmpipe driver - if it never worked then we
> aren't actually losing anything. Presumably s390 porters would have a
> better idea of what works and what doesn't.

IBM Z (why do they keep renaming it?) supports PCI Express now, so I
think it's *possible* to install a Mesa-supported GPU, if unlikely.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.




signature.asc
Description: This is a digitally signed message part


Re: Porter roll call for Debian Stretch

2016-10-01 Thread Ben Hutchings
On Sat, 2016-10-01 at 15:48 +0200, John Paul Adrian Glaubitz wrote:
> On 10/01/2016 02:17 PM, Ben Hutchings wrote:
> > 
> > > 
> > > This isn't the case for PowerPC32 where upstream development is still very
> > > active because it's part of the PowerPC kernel which is maintained by
> > > IBM.
> > 
> > This is not at all true.  My experience is that IBM doesn't even build-
> > test 32-bit configurations, as evidenced by several stable updates
> > causing FTBFS in Debian.
> 
> They care enough that they are fixing bugs. Just recently, a bug in the
> PowerPC kernel was fixed that affected 32-bit embedded PowerPCs only.

$ git log --author=ibm --grep='ppc-?32|powerpc-?32|32-bit' -i -E arch/powerpc

finds me fewer than ten commits per year.

> > 
> > > 
> > > As for SPARC, Oracle is actually now heavily investing in Linux SPARC
> > > support, so even SPARC is getting back into shape which is why I hope
> > > we can add sparc64 as an official port soon.
> > [...]
> > 
> > Oracle cares about Solaris on SPARC, not Linux on SPARC.
> 
> Well, then you know more than the people at Oracle that I am talking to.
[... much evidence of Oracle supporting Linux on SPARC ...]

OK, I accept this has changed, but I'm quite surprised - Oracle is
ruthlessly commercial, and I'm mystified as to who they expect to buy
it.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.

signature.asc
Description: This is a digitally signed message part


Re: Porter roll call for Debian Stretch

2016-10-01 Thread Ben Hutchings
On Sat, 2016-10-01 at 02:28 +0200, Adam Borowski wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
[...]
> > I have not heard from the ppc64el porters, but I suspect ppc64 will
> > not be a release arch. So you need to take into consideration that for
> > powerpc to remain a release arch, one need minimal working ppc64 port.
> > Could we solve the situation of ppc64 for Stretch, could it be moved
> > to official release arch ?
> 
> What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
> kernels so users don't need multiarch:
[...]

This is only the case because ppc64 has a lower level of support
(unofficial port) than powerpc (release architecture).  The 64-bit
kernel package should be dropped once powerpc is at the same or lower
level of support than ppc64 - just as we've done for i386, s390 and
sparc.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part


[PATCH v2 2/2] deb-pkg: Add automatic support for s390x architecture

2014-06-08 Thread Ben Hutchings
The Debian s390x architecture has 64-bit userland whereas s390 has
32-bit userland.  A 64-bit kernel can be used with either.  Now that
Debian supports multiarch and officially supports s390x, it makes more
sense to assign a 64-bit kernel package to s390x.

Reported-by: Stephen Powell zlinux...@wowway.com
References: https://bugs.debian.org/750925
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
v2: - add bug reference, since Stephen also found this
- add '|| true', as in recent fixes for other architectures

 scripts/package/builddeb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 6756ed6..8db6dbd 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -35,7 +35,7 @@ create_package() {
sparc*)
debarch=sparc ;;
s390*)
-   debarch=s390 ;;
+   debarch=s390$(grep -q CONFIG_64BIT=y $KCONFIG_CONFIG  echo x 
|| true) ;;
ppc*)
debarch=powerpc ;;
parisc*)

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.


signature.asc
Description: This is a digitally signed message part


[PATCH 2/2] deb-pkg: Add automatic support for s390x architecture

2013-10-06 Thread Ben Hutchings
The Debian s390x architecture has 64-bit userland whereas s390 has
32-bit userland.  A 64-bit kernel can be used with either.  Now that
Debian supports multiarch and officially supports s390x, it makes more
sense to assign a 64-bit kernel package to s390x.

Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
 scripts/package/builddeb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index e14c56e..25c5abd 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -35,7 +35,7 @@ create_package() {
sparc*)
debarch=sparc ;;
s390*)
-   debarch=s390 ;;
+   debarch=s390$(grep -q CONFIG_64BIT=y $KCONFIG_CONFIG  echo x) 
;;
ppc*)
debarch=powerpc ;;
parisc*)

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, reading IRC for the first time


signature.asc
Description: This is a digitally signed message part


Re: Roll call for porters of architectures in sid and testing (Status update)

2013-09-21 Thread Ben Hutchings
On Sat, 2013-09-21 at 19:36 +0200, Émeric MASCHINO wrote:
 Hi,
 
 I'm a long-time ia64 Debian user ( 10 years). I'm mostly focused on
 desktop aspects (GNOME, Iceweasel, LibreOffice, Qt Creator, C++ 3D
 software development) while most other ia64 users that I know are more
 inclined on server use.
 
 I'm not a DD/DM, but daily update my ia64 workstation, report bugs and
 do my best to provide useful information in order to get them fixed.

Thank you for this.

 I've also provided a couple of kernel patches in the past. I'm cross
 testing with Gentoo to ensure that bugs I report are Debian-specific
 or ia64-generic.
 
 I'll continue testing/software development activity on ia64 for the
 Jessie cycle, and more generally, until Debian drops ia64. I'm already
 waiting for Wayland on ia64 and other big updates.
 
 So please, keep ia64 in the bandwagon ;-)

But I don't think ia64 is well-supported even in wheezy.  The kernel
doesn't boot on some common machines and no-one seems to be able to fix
it.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


signature.asc
Description: This is a digitally signed message part


Bug#594127: Fix for bug number 590028 is incomplete

2010-08-29 Thread Ben Hutchings
On Fri, 2010-08-27 at 09:50 -0400, Stephen Powell wrote:
[...]
 Personally, I think that the requirement to maintain symlinks, if used,
 is implicit in the purpose of the boot loader hook script.
[...]

After thinking about this some more and actually trying to implement the
hook scripts, I think I agree.  These symlinks are horrible and by
default we should not create them.  As a stopgap, boot loader packages
may create and then use the links, but I would much prefer that they
construct a menu of all installed kernel versions, as GRUB and extlinux
do.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: Digital signature


Bug#594127: Fix for bug number 590028 is incomplete

2010-08-29 Thread Ben Hutchings
On Sun, 2010-08-29 at 21:31 -0400, Stephen Powell wrote:
 On Sun, 29 Aug 2010 16:20:20 -0400 (EDT), Ben Hutchings wrote:
  On Fri, 2010-08-27 at 09:50 -0400, Stephen Powell wrote:
  [...]
  Personally, I think that the requirement to maintain symlinks, if used,
  is implicit in the purpose of the boot loader hook script.
  [...]
  
  After thinking about this some more and actually trying to implement the
  hook scripts, I think I agree.  These symlinks are horrible and by
  default we should not create them.  As a stopgap, boot loader packages
  may create and then use the links, but I would much prefer that they
  construct a menu of all installed kernel versions, as GRUB and extlinux
  do.
 
 Hmm.  Well, I agree that the approach taken by grub-legacy and extlinux
 is more flexible.  It allows more than two kernels to be bootable.
 But boot loaders such as lilo and zipl have historically used
 symlinks, and the symlink maintenance logic in my generic boot loader
 hook scripts,
 http://www.wowway.com/~zlinuxman/kernel/postinst.d/zz-bootloader and
 http://www.wowway.com/~zlinuxman/kernel/postrm.d/zz-bootloader,
 isn't really that complex.  I'm curious as to why you consider symlinks
 to be horrible.

Because of the limitation to two versions, arbitrarily designated
'current' and 'old'; the fact that they could be in /, /boot, or even
configured to be elsewhere; and the problem of stale links.

 For now, on my own systems, I have extracted the symlink maintenance
 logic from the above generic boot loader hook scripts and have created
 new hook scripts which I call zy-symlinks.  It allows me to use the
 new boot loader packages with their kernel hook scripts which only
 invoke the boot loader installer without modifying them.  I also
 have my own generic initramfs hook script which I use with zipl,
 http://www.wowway.com/~zlinuxman/initramfs/post-update.d/bootloader.
 (By the way, I like the way you were able to avoid a bashism,
 namely substring expansion, by using a case statement in lilo's
 initramfs hook.  Very clever!)
 
 But Debian clearly needs to do *something* about this problem
 *somewhere*.

I met Colin Watson last night and he said that he (as GRUB maintainer)
and Daniel Baumann (as syslinux maintainer) had discussed writing a
common boot loader policy.  Due to the interaction with kernel packages
and initramfs builders, I think we could combine this with the extension
of the kernel and initramfs hooks policy.

I don't think this urgently needs to be fixed before squeeze, as it is
only affects unofficial kernel packages.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Bug#594127: Fix for bug number 590028 is incomplete

2010-08-27 Thread Ben Hutchings
On Fri, Aug 27, 2010 at 09:50:47AM -0400, Stephen Powell wrote:
[...]
 Personally, I think that the requirement to maintain symlinks, if used,
 is implicit in the purpose of the boot loader hook script.
[...]

No, that means it has to be repeated in many different packages.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus



-- 
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100827152502.gs5...@decadent.org.uk



Bug#594127: Fwd: Re: Bug#594127: Fix for bug number 590028 is incomplete

2010-08-26 Thread Ben Hutchings
On Thu, 2010-08-26 at 15:04 -0400, Stephen Powell wrote:
 Ben,
 
 I could use your help on bug number 594127.  Am I not understanding
 the policy?  Please read the bug log and advise.  Thanks.

Assuming that s390 kernels normally use an initramfs to boot, I think
you're right about the lack of an initramfs hook.

As for maintaining symlinks, that is not described by the policy at all,
though it should be.  We could perhaps put hook scripts for that in
linux-base.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


[DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process

2010-07-04 Thread Ben Hutchings
I think this incorporates all the comments and corrections for the
previous version.  Please send follow-ups to debian-kernel, and
subscribe to it if you haven't already done so.

Ben.

---
0. The arguments given to all kernel hook scripts are the kernel ABI
version (the string that uname -r reports) and, optionally, the absolute
path to the kernel image.  If the second argument is missing then the
path is either /boot/vmlinuz-$version or /boot/vmlinux-$version,
according to architecture convention.  The environment variable
DEB_MAINT_PARAMS will contain the arguments given to the kernel
maintainer script, possibly single-quoted.  In a shell script, this
variable can be parsed using 'set -- $DEB_MAINT_PARAMS'.

Kernel hook scripts may be run under debconf.  In this case they must
not use stdin and stdout, and should send all output to stderr (fd 2).
[Alternately we should change linux-2.6 and kernel-package to do the
necessary redirection.  Is there any legitimate reason for a hook script
to interact with debconf?]

1. Packages for boot loaders that need to be updated whenever the files
they load are modified (i.e. those that store a block list) must install
hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which
will be called on installation/upgrade and removal of kernel packages,
respectively.

Since these boot loaders should be updated as the last step during
installation/upgrade and removal, hook scripts for boot loaders must be
named using the prefix 'zz-' and no other packages may use this prefix
or one that sorts later by the rules used by run-parts.  A postrm hook
script should warn but exit with code 0 if the boot loader configuration
file still refers to the kernel image that has been removed.

Packages for boot loaders that can provide a menu of kernel versions
should install kernel hook scripts in order to update that menu.

2. Packages for boot loaders that need to be updated whenever the files
they load are modified must also install hook scripts in
/etc/initramfs/post-update.d.  Initramfs builders must call these
scripts using run-parts after they create, update or delete an
initramfs.  The arguments given to these hook scripts are the kernel ABI
version and the absolute path to the initramfs image.

3. Initramfs builders must complete their work before returning from the
kernel postinst hook script.  [initramfs-tools currently uses a trigger
to defer this because it can also be invoked twice, but this means it
also has to know how to update specific boot loaders.  This new
requirement will allow boot loader packages to avoid unnecessary
updates, as described in the following section.]

4. During a kernel package installation, upgrade or removal, various
boot loader hooks may be invoked (in this order):

a. A postinst_hook or postrm_hook command set by the user or the
   installer in /etc/kernel-img.conf
b. A hook script in /etc/initramfs/post-update.d
c. A hook script in /etc/kernel/postinst.d or .../postrm.d

To avoid unnecessary updates, the hooks invoked at step a and b may
check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and
do nothing in this case.

5. Kernel packages must not invoke boot loaders except via hooks.
If /etc/kernel-img.conf contains 'do_bootloader = yes' or equivalent,
maintainer scripts that previously acted on this must warn that they are
ignoring it.  linux-base must also warn on upgrade that the default has
changed.  In squeeze+1, this prohibition extends to initramfs builder
packages.

6. The installer must not define do_bootloader, postinst_hook or
postrm_hook in /etc/kernel-img.conf.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

2010-06-28 Thread Ben Hutchings
Please reply to debian-kernel only.

On Mon, 2010-06-28 at 11:16 -0400, Stephen Powell wrote:
 On Sun, 27 Jun 2010 22:02:35 -0400 (EDT), Ben Hutchings wrote:
[...]
  The environment variable DEB_MAINT_PARAMS will contain
  the arguments given to the kernel maintainer script, single-quoted.
 
 Is this environment variable provided by the maintainer scripts
 that come with kernel image packages created by make deb-pkg?
 (I honestly don't know.  I've never used make deb-pkg.)

It has done since 2.6.31, though without single-quotes.  I'll note that
they may or may not be quoted, and recommend how to use this variable.

[...]
  5. Kernel and initramfs builder packages must not invoke boot loaders
  except via hooks.  If /etc/kernel-img.conf contains an explicit
  'do_bootloader = yes', kernel package maintainer scripts should warn
  that this is now ignored.
 
 At the risk of flogging a dead horse, I would prefer to see
 do_bootloader = yes supported until Squeeze+1, both by the
 kernel maintainer scripts and by update-initramfs -u, particularly
 since we are so close to a freeze.

The release team has stated we are not close to a freeze.  So we have a
little time to sort this out.

 But if
 you're going to drop support for it in Squeeze, then yes,
 a warning message is necessary.  Both the kernel maintainer scripts
 *and* update-initramfs -u *must* issue a warning message if they
 find do_bootloader = yes specified in /etc/kernel-img.conf.
 In fact, since the default value is yes, they should issue
 the warning message unless do_bootloader is *explicitly* set
 to no.

I can put a one-time warning into linux-base.  But the default for
squeeze must be 'no'.  It should not be necessary to create
/etc/kernel-img.conf at all in squeeze.

  6. The installer must not define do_bootloader, postinst_hook or
  postrm_hook in /etc/kernel-img.conf.
 
 Doesn't this conflict with point 4 (a)?

Not at all.  This means postinst_hook and postrm_hook are now strictly
for use by the user.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

2010-06-28 Thread Ben Hutchings
On Mon, 2010-06-28 at 18:45 +0200, maximilian attems wrote:
[...]
 please get your facts right before spamming the world.

Max, this is rude and unjustified.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Re: [RFC] Updating boot loaders in lenny and squeeze

2010-06-27 Thread Ben Hutchings
On Sat, 2010-06-26 at 22:43 -0400, Stephen Powell wrote:
 On Sat, 26 Jun 2010 20:45:58 -0400 (EDT), Ben Hutchings wrote:
  On Sat, 2010-06-26 at 20:35 -0400, Stephen Powell wrote:
  
  Sounds reasonable to me.  This is for Squeeze+1, right?
  
  No, we need something like this for squeeze.
 
 On Fri, 18 Jun 2010 17:51:11 +0200, Maximilian Attems wrote:
  On Fri, 18 Jun 2010 10:55:35 -0400 (EDT), Stephen Powell wrote: 
 
  As for update-initramfs -u, it *will* invoke lilo if lilo is installed
  and do_bootloader = yes is specified in /etc/kernel-img.conf, which I
  highly recommend. 
  
  this fall back will be gone as soon as squeeze is out.
  so you'd really need to gear up.
 
 (The above quotes are from the bug log for Debian bug number 505609.)
 This led me to believe that, for lilo and zipl anyway, specifying
 
do_bootloader = yes
 
 in /etc/kernel-img.conf would be sufficient to get the boot loader
 run when update-initramfs -u is executed at least through and
 including the Squeeze release.  But in Squeeze+1 this fallback, as
 Max put it, will no longer work and therefore a new architecture
 will be needed.  Did I misunderstand something?

Maybe we can scrape along without changing this, but since we already
need to change the boot loader packages for squeeze we may as well sort
this out.  This also gives Jonas a chance to make yaird just work
without having to introduce the same sort of kluge.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Re: [RFC] Updating boot loaders in lenny and squeeze

2010-06-27 Thread Ben Hutchings
On Sun, 2010-06-27 at 10:19 +0200, Jonas Smedegaard wrote:
 On Sat, Jun 26, 2010 at 08:50:27PM +0100, Ben Hutchings wrote:
 On Wed, 2010-06-23 at 23:31 +0200, Jonas Smedegaard wrote:
  On Wed, Jun 23, 2010 at 10:12:42AM -0400, Stephen Powell wrote:
 
  That does seem like a more general-purpose solution, rather than 
  having lilo and zipl treated as special cases.  But please keep the 
  appropriate parties informed of any future design changes to 
  update-initramfs. I myself have never used yaird, but I assume that 
  to be consistent it should have a similar hook system.
 
  A great while back initramfs-tools and kernel packages broke the ABI 
  coordinated across initramfs-tools, linux-2.6, yaird and 
  kernel-package.
 
  Sure would be nice with a stable ABI again, and getting informed if 
  it changes.
 
 That is a separate issue.  What we need here is an interface for the 
 initramfs builder to update the boot loader if necessary.  No such 
 interface exists yet, AFAIK.
 
 Agreed, this is a different ABI.  The wish for such ABI being treated as 
 a cross-package ABI still exist.
 
 One approach would be to create a page at wiki.debian.org which all 
 interested parties could then subscribe to.
 
 I would dislike if (as in the past) we simply rely on whatever internal 
 routines implemented by the most popular packages (initramfs-tools and 
 minux-2.6) which others then need to track sources of.

I agree.

 I suggest something like the following:
 
 1. Boot loaders that maintain block lists install a script under
 /etc/mkinitramfs/post-update.d which takes two arguments: the kernel ABI
 version (uname -r) and the absolute path to an initramfs.
 
 2. Initramfs builders call the scripts in this directory after creating,
 updating or deleting an initramfs by running:
 run-parts --verbose --exit-on-error --arg=$version --arg=$path 
  /etc/mkinitramfs/post-update.d
 or similar.
 
 We could alternately use multiple directories or an argument to
 distinguish creation, update and deletion.  However, I suspect that
 these scripts will need to invoke the same command in all cases.
 
 Seems reasonable to me.

There is a minor problem with this, which is that it will likely result
in updating the boot loader twice during a kernel installation or
upgrade.  We could avoid that by specifying that:

3. Boot loaders must install kernel hook scripts named beginning with
'zz-'. All other packages must use names that sort before this. (This
ensures that the boot loader update happens last.)

4. Initramfs builders may omit calling initramfs hook scripts when they
are invoked from a kernel hook script.

We're still left with the question of how to transition from the current
mess.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Re: [RFC] Updating boot loaders in lenny and squeeze

2010-06-26 Thread Ben Hutchings
On Wed, 2010-06-23 at 23:31 +0200, Jonas Smedegaard wrote:
 On Wed, Jun 23, 2010 at 10:12:42AM -0400, Stephen Powell wrote:
 
 That does seem like a more general-purpose solution, rather than having
 lilo and zipl treated as special cases.  But please keep the appropriate
 parties informed of any future design changes to update-initramfs.
 I myself have never used yaird, but I assume that to be consistent it
 should have a similar hook system.
 
 A great while back initramfs-tools and kernel packages broke the ABI 
 coordinated across initramfs-tools, linux-2.6, yaird and kernel-package.
 
 Sure would be nice with a stable ABI again, and getting informed if it 
 changes.

That is a separate issue.  What we need here is an interface for the
initramfs builder to update the boot loader if necessary.  No such
interface exists yet, AFAIK.

I suggest something like the following:

1. Boot loaders that maintain block lists install a script under
/etc/mkinitramfs/post-update.d which takes two arguments: the kernel ABI
version (uname -r) and the absolute path to an initramfs.

2. Initramfs builders call the scripts in this directory after creating,
updating or deleting an initramfs by running:
run-parts --verbose --exit-on-error --arg=$version --arg=$path 
/etc/mkinitramfs/post-update.d
or similar.

We could alternately use multiple directories or an argument to
distinguish creation, update and deletion.  However, I suspect that
these scripts will need to invoke the same command in all cases.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Re: [RFC] Updating boot loaders in lenny and squeeze

2010-06-26 Thread Ben Hutchings
On Sat, 2010-06-26 at 20:35 -0400, Stephen Powell wrote:
 On Sat, 26 Jun 2010 15:50:27 -0400 (EDT), Ben Hutchings wrote:
  On Wed, 2010-06-23 at 23:31 +0200, Jonas Smedegaard wrote:
  
  A great while back initramfs-tools and kernel packages broke the ABI 
  coordinated across initramfs-tools, linux-2.6, yaird and kernel-package.
  
  Sure would be nice with a stable ABI again, and getting informed if it 
  changes.
  
  That is a separate issue.  What we need here is an interface for the
  initramfs builder to update the boot loader if necessary.  No such
  interface exists yet, AFAIK.
 
  I suggest something like the following:
  
  1. Boot loaders that maintain block lists install a script under
  /etc/mkinitramfs/post-update.d which takes two arguments: the kernel ABI
  version (uname -r) and the absolute path to an initramfs.
  
  2. Initramfs builders call the scripts in this directory after creating,
  updating or deleting an initramfs by running:
  run-parts --verbose --exit-on-error --arg=$version --arg=$path 
  /etc/mkinitramfs/post-update.d
  or similar.
  
  We could alternately use multiple directories or an argument to
  distinguish creation, update and deletion.  However, I suspect that
  these scripts will need to invoke the same command in all cases.
 
 Sounds reasonable to me.  This is for Squeeze+1, right?

No, we need something like this for squeeze.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part


Re: [RFC] Updating boot loaders in lenny and squeeze

2010-06-23 Thread Ben Hutchings
On Wed, Jun 23, 2010 at 10:12:42AM -0400, Stephen Powell wrote:
 On Fri, 18 Jun 2010 22:55:38 -0400 (EDT), Ben Hutchings wrote:
[...]
  In case 1, the boot loader should also be called by update-initramfs
  when it is called outside of kernel package installation and removal.
  This is normally covered by route D, but this seems a little fragile.  I
  would prefer to replace this with a hook system (as already exists for
  building the initramfs itself), but I'm not that involved in
  initramfs-tools development.
 
 That does seem like a more general-purpose solution, rather than having
 lilo and zipl treated as special cases.  But please keep the appropriate
 parties informed of any future design changes to update-initramfs.
 I myself have never used yaird, but I assume that to be consistent it
 should have a similar hook system.
 
yaird is no longer present in testing or unstable, so it is a non-issue
as far as I'm concerned.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100623150405.gx5...@decadent.org.uk



Re: Bug#505609: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)

2010-06-17 Thread Ben Hutchings
On Thu, Jun 17, 2010 at 12:33:58PM -0400, Stephen Powell wrote:
[...]
 I can maybe accept your proposal for Squeeze.  But for Lenny, I believe
 that the maintainer scripts should be changed back they way they
 were.  In other words,

my $loader= lilo; # lilo, silo, quik, palo, vmelilo, 
 nettrom, arcboot, or delo

 should be set in the maintainer scripts.  After all, Lenny does
 not have the generalized hook script environment that Squeeze does.

But it does allow users to configure the loader to be run, using either
the 'loader' or 'postinst_hook' variable.

 I believe that this bug is severe enough to warrant inclusion of the
 fix in stable-proposed-updates.

The fact that the historical bootloader is not automatically run is not a
bug; it is an intentional change.  Only the silent failure is a bug.

  
  All packages that need to react to kernel installation or removal should
  install appropriate hook scripts in the directories under /etc/kernel
  instead of relying on specific support in the kernel maintainer scripts.
 
 
 Again, I can maybe accept that argument for Squeeze, but not for Lenny.
 However, to be consistent, if you're going to leave my $loader set to the 
 null
 string in i386 and amd64 kernel maintainer scripts, you should also set
 it to the null string for s390 kernel maintainer scripts.

Yes. I think that's probably a reasonable change for squeeze.

[...]
 The maintainer scripts' support for the historic boot
 loader should be retained, in my opinion, at least for Squeeze.  Then,
 if you want to change the design of how kernel maintainer scripts
 work, that can be done in Squeeze+1.
 
It cannot be 'retained' because it is not there at present.  Nor will it
be reinstated.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100617221104.gr5...@decadent.org.uk



Re: loader varialbe in kernel maintainer scripts

2010-06-17 Thread Ben Hutchings
On Thu, 2010-06-17 at 20:37 -0400, Stephen Powell wrote:
 On Thu, 17 Jun 2010 18:11:04 -0400 (EDT), Ben Hutchings wrote:
  On Thu, Jun 17, 2010 at 12:33:58PM -0400, Stephen Powell wrote:
  [...]
  I can maybe accept your proposal for Squeeze.  But for Lenny, I believe
  that the maintainer scripts should be changed back they way they
  were.  In other words,
 
 my $loader= lilo; # lilo, silo, quik, palo, vmelilo, 
  nettrom, arcboot, or delo
 
  should be set in the maintainer scripts.  After all, Lenny does
  not have the generalized hook script environment that Squeeze does.
  
  But it does allow users to configure the loader to be run, using either
  the 'loader' or 'postinst_hook' variable.
 
 And how would one go about setting this loader variable?
 The loader variable is not documented in the man page for
 /etc/kernel-img.conf in Lenny, which appears to be the closest thing
 there is to documentation for the variables supported by official
 Debian stock kernel images.  Nevertheless, at your suggestion, I tried
 putting
 
loader = lilo
 
 in /etc/kernel-img.conf.  (do_bootloader = yes was also set.)  Then I
 issued
 
dpkg-reconfigure linux-image-2.6.26-2-686
 
 There was no evidence from the output that lilo was run.
[...]

I'm sorry, you're right.  Most of the other variables at the top of the
postinst script can be overridden by /etc/kernel-img.conf, but not this
one.  Given that, I think you are right that the 'historical' bootloader
setting should be restored in an update to lenny.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part