RE: debian testing daily build: installing GRUB/Bootloader and initramfs failing!!

[André Verwijs]

thank you Gioele,


yes i did got this bug to.
but with  https://bugs.debian.org/1040899 is trying to install  Debian 
13, with is VERY unstable and alpha stage,


i hope debian 12 can be fixed...


thank you
André

Re: debian testing daily build: installing GRUB/Bootloader and initramfs failing!!

[Gioele Barabucci]

On 17/09/23 09:46, André Verwijs wrote:
debian testing daily build:  installing GRUB/Bootloader and initramfs 
failing!!


Probably you stumbled upon this problem: https://bugs.debian.org/1040899

The root cause has (hopefully) been fixed by the Debian Installer team 
and will be released soon: https://bugs.debian.org/1031183


Regards,

--
Gioele Barabucci

debian testing daily build: installing GRUB/Bootloader and initramfs failing!!

[André Verwijs]

debian testing daily build:  installing GRUB/Bootloader and initramfs 
failing!!

i will try to generate logfiles and report as bug.

more info later..
thanks

debian testing daily build: installing GRUB/Bootloader and initramfs failing!!

[André Verwijs]

debian testing daily build:  installing GRUB/Bootloader and initramfs  
failing!!

i will try to generate logfiles and report as bug.

more info later..
thanks

debian testing daily build: installing GRUB/Bootloader failing!!

[André Verwijs]

debian testing daily build:  installing GRUB/Bootloader and initramfs  
failing!!

i will try to generate logfiles and report as bug.

more info later..
thanks

Re: Grub Password configuration during install

[Cyril Brulebois]

Hi,

Timothy M Butterworth  (2023-03-04):
> Would it be possible to add a section to the installer when Grub is being
> installed and configured to configure a grub password?

I think that's supported already:

    Template: grub-installer/password
Type: password
# :sl2:
_Description: GRUB password:
     The GRUB boot loader offers many powerful interactive features, which could
 be used to compromise your system if unauthorized users have access to the
 machine when it is starting up. To defend against this, you may choose a
 password which will be required before editing menu entries or entering the
 GRUB command-line interface. By default, any user will still be able to
 start any menu entry without entering the password.
 .
 If you do not wish to set a GRUB password, leave this field blank.

Can be preseeded, or specified during an expert install. Definitely not
something that should be asked during a normal install.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Grub Password configuration during install

[Timothy M Butterworth]

All,

Would it be possible to add a section to the installer when Grub is being
installed and configured to configure a grub password?

Thanks

Tim

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Bug#941627: ITP: grub-btrfs -- provides grub entries for btrfs snapshots (boot environments/restore points)

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 
Control: block -1 by #840248

Package name: grub-btrfs
Version : 4.1
Upstream Author : Antynea 
URL : https://github.com/Antynea/grub-btrfs
License : GPL-3+
Programming Lang: bash
Description : GRUB entries for btrfs snapshots (boot environments/restore 
points)

Grub-btrfs generates grub entries for btrfs snapshots, thus making it
easy to roll back to a known-good state.  Other operating systems call
this functionality "system restore points" or "boot environments"
(aka: BEs).

This package supports booting from manual snapshots stored in a
predefined location, and appears to also support snapper (it seems the
snapper support may be buggy in the v4.1 release).  At present,
snapshots must be the read-write type, but it should be possible to
extend this software to the following from an initramfs: make a rw BE
from a ro snapshot during the premount stage.

I've been waiting for this software to mature for a couple of years
before filing an ITP, and it looks like it's finally ready to
validate.  I've blocked this ITP by "debian-installer: Add btrfs
subvolume setting for snapshot" because I do not believe that this
package is useful until a default Debian installation using btrfs
provides separation between rootfs and user data.  That said, I
believe that it is appropriate to work on it in the experimental
suite.  It is probably most useful for people who want to track sid,
but with insurance against having to back out of an upgrade when they
don't have any free time.

Ideally I'd like to form a btrfs-task force to work on related issues
and maintain this package there, but as of yet no one has shown
interest in such a team.  If you are interested, please speak up!

I will need a sponsor for the initial upload.


Regards,
Nicholas

Bug#912041: grub-cloud-amd64: don't work around being tested by piuparts

[Holger Levsen]

Package: grub-cloud-amd64
Version: 0.0.2
Severity: important

Dear Maintainer,

in your postinst you are trying to detect whether it's being run in a
piuparts test, to workaround #912038 ("grub-cloud-amd64: fails to
install"), which is detected by piuparts but can also be triggered by
anyone installing it manually, with this code:

if [ ${PIUPARTS_TEST:-} ]; then
echo "Running Piuparts detected, exiting." >&2
exit 0
fi

This is bad, don't do that. piuparts tests stuff for a reason and as
#912038 shows, your package is still buggy.

In discussion on #-release before uploading grub-cloud 0.0.2 you claimed
that grub-cloud is only useful to install in cloud environments (which
are chroots) and thus detecting a chroot would not work. Still all packages
(aimed for a stable Debian release) must be installable in chroots, also
yours.

So instead of detecting whether the package is being tested by piuparts
you should detect whether grub-cloud-amd64 is being installed in a
cloud-chroot and only then do whatever it takes to active grub. For that
you can create some file while preparing the cloud chroot (say
/etc/.cloud_env) and only if that file is present you do those things
you now dont do if the variable $PIUPARTS_TEST is defined.

I've also filed a bug against lintian to detect maintainer scripts using this
variable as no maintainer script needs to do this. This is similar to
the lintian test detecting autokpkgtests just running "exit 0" or
"true". The bug against lintian is #912040.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Guillem Jover]

Hi!

On Fri, 2017-06-23 at 12:22:34 +0100, Colin Watson wrote:
> The basic problem in init-select is of course the good old favourite of
> a conffile not behaving correctly when the package has been removed but
> not purged.  This is probably worth fixing in unstable as follows, since
> init-select is still there:
> 
> --- a/init-select.cfg
> +++ b/init-select.cfg
> @@ -1,1 +1,1 @@
> -GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT 
> $(/usr/lib/init-select/get-init)"
> +GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT $([ ! -x 
> /usr/lib/init-select/get-init ] || /usr/lib/init-select/get-init)"

> However, I take Andreas's point that we need to work around this
> somehow, probably in a stretch point release now, and that's where I
> need feedback.  One possible approach would be to change grub-mkconfig
> to do something like this:

> I fully appreciate that this is skating along the edge of policy's
> requirements regarding conffiles, and arguably violates at least 10.7.4
> "The maintainer scripts must not alter a conffile of any package,
> including the one the scripts belong to".  However, I think that this is
> a reasonable case of self-defence, and could be tolerable with
> sufficient commentary and care.  I doubt I would be contemplating it if
> init-select hadn't been removed from stretch.

Isn't the obviously correct and policy compliant approach to just
Conflicts/Replaces (or Breaks/Replaces depending on the force you want
to apply here) with the init-select package from one of the grub
packages, and on that grub package ship a stub init-select.cfg with
just a comment explaining what's going on. And in the next release cycle,
just make that package remove its (now) own conffile?

Thanks,
Guillem

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Colin Watson]

On Sat, Jun 24, 2017 at 07:01:11PM +0200, Michael Biebl wrote:
> Am 24.06.2017 um 17:01 schrieb Simon McVittie:
> > That doesn't solve the problem of the obsolete conffile breaking grub,
> > though. 
> 
> Indeed not. But it answers the question whether init-select should be
> NMUed in unstable.

I agree that that part of it is now moot.

> > Should the grub maintainers edit the conffile in-place as
> > suggested (a Policy violation), or delete it or move it out of the way
> > (also a Policy violation), or is there some other escape route possible
> > here?
> > 
> > It occurs to me that asking the CTTE for advice might be useful: they'd
> > probably find it a refreshing change to have a question that is not a
> > request to choose one side of a heated dispute between developers :-)
> 
> Since it's pretty obvious that init-select is supposed to be removed, I
> wouldn't have a problem with simply forcefully removing the offending
> init-select.cfg conffile (and it's probably safe to drop this migration
> code after one release cycle.
> 
> Asking the CTTE certainly doesn't hurt.

I think I probably agree that removing the file is sensible, but my
experience is that it's a good idea to have an unusual amount of review
of unusual and difficult-to-undo conffile handling ideas: so I've
written this up for the TC's consideration as
https://bugs.debian.org/865929.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Scott Kitterman]

On Saturday, June 24, 2017 07:01:11 PM Michael Biebl wrote:
> Am 24.06.2017 um 17:01 schrieb Simon McVittie:
> > On Sat, 24 Jun 2017 at 16:04:32 +0200, Michael Biebl wrote:
> >> Am 24.06.2017 um 15:09 schrieb Michael Gilbert:
> >>> I entirely lost interest in the problem it was trying to solve when
> >>> the init system "debate" concluded.  It should be removed.
> >> 
> >> FYI, I've filed #865752 for that.
> > 
> > That doesn't solve the problem of the obsolete conffile breaking grub,
> > though.
> 
> Indeed not. But it answers the question whether init-select should be
> NMUed in unstable.
> 
> Should the grub maintainers edit the conffile in-place as
> 
> > suggested (a Policy violation), or delete it or move it out of the way
> > (also a Policy violation), or is there some other escape route possible
> > here?
> > 
> > It occurs to me that asking the CTTE for advice might be useful: they'd
> > probably find it a refreshing change to have a question that is not a
> > request to choose one side of a heated dispute between developers :-)
> 
> Since it's pretty obvious that init-select is supposed to be removed, I
> wouldn't have a problem with simply forcefully removing the offending
> init-select.cfg conffile (and it's probably safe to drop this migration
> code after one release cycle.
> 
> Asking the CTTE certainly doesn't hurt.

It was removed from unstable earlier today:

$ dak ls init-select
init-select | 1.20140921| oldstable  | source, all
init-select | 1.20140921| oldstable-kfreebsd | source, all

Scott K

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

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Michael Biebl]

Am 24.06.2017 um 17:01 schrieb Simon McVittie:
> On Sat, 24 Jun 2017 at 16:04:32 +0200, Michael Biebl wrote:
>> Am 24.06.2017 um 15:09 schrieb Michael Gilbert:
>>> I entirely lost interest in the problem it was trying to solve when
>>> the init system "debate" concluded.  It should be removed.
>>
>> FYI, I've filed #865752 for that.
> 
> That doesn't solve the problem of the obsolete conffile breaking grub,
> though. 

Indeed not. But it answers the question whether init-select should be
NMUed in unstable.

Should the grub maintainers edit the conffile in-place as
> suggested (a Policy violation), or delete it or move it out of the way
> (also a Policy violation), or is there some other escape route possible
> here?
> 
> It occurs to me that asking the CTTE for advice might be useful: they'd
> probably find it a refreshing change to have a question that is not a
> request to choose one side of a heated dispute between developers :-)

Since it's pretty obvious that init-select is supposed to be removed, I
wouldn't have a problem with simply forcefully removing the offending
init-select.cfg conffile (and it's probably safe to drop this migration
code after one release cycle.

Asking the CTTE certainly doesn't hurt.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Simon McVittie]

On Sat, 24 Jun 2017 at 16:04:32 +0200, Michael Biebl wrote:
> Am 24.06.2017 um 15:09 schrieb Michael Gilbert:
> > I entirely lost interest in the problem it was trying to solve when
> > the init system "debate" concluded.  It should be removed.
> 
> FYI, I've filed #865752 for that.

That doesn't solve the problem of the obsolete conffile breaking grub,
though. Should the grub maintainers edit the conffile in-place as
suggested (a Policy violation), or delete it or move it out of the way
(also a Policy violation), or is there some other escape route possible
here?

It occurs to me that asking the CTTE for advice might be useful: they'd
probably find it a refreshing change to have a question that is not a
request to choose one side of a heated dispute between developers :-)

S

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Michael Biebl]

Am 24.06.2017 um 15:09 schrieb Michael Gilbert:
> I entirely lost interest in the problem it was trying to solve when
> the init system "debate" concluded.  It should be removed.

FYI, I've filed #865752 for that.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Michael Gilbert]

On Sat, Jun 24, 2017 at 7:44 AM, Michael Biebl wrote:
> Given how long init-select has been RC buggy, I wonder if it wouldn't be
> better to remove it from the archive completely. Selecting a fallback
> init is something grub already provides today, so I don't see
> init-select as something useful anymore nowadays.
>
> Explicitly CCed Michael: what are your plans for init-select?

I entirely lost interest in the problem it was trying to solve when
the init system "debate" concluded.  It should be removed.

Best wishes,
Mike

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Michael Biebl]

Am 23.06.2017 um 13:22 schrieb Colin Watson:
> --- a/init-select.cfg
> +++ b/init-select.cfg
> @@ -1,1 +1,1 @@
> -GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT 
> $(/usr/lib/init-select/get-init)"
> +GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT $([ ! -x 
> /usr/lib/init-select/get-init ] || /usr/lib/init-select/get-init)"
> 
> I propose to NMU init-select with this change after a bit of testing and
> the usual delay, since it would generally make life easier if there were
> a non-broken version around somewhere.  We might also want to think
> about putting that into jessie-proposed-updates.

> Thoughts?  Can anyone think of a better solution than either of the two
> I've outlined here?

Given how long init-select has been RC buggy, I wonder if it wouldn't be
better to remove it from the archive completely. Selecting a fallback
init is something grub already provides today, so I don't see
init-select as something useful anymore nowadays.

Explicitly CCed Michael: what are your plans for init-select?

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Colin Watson]

On Wed, May 31, 2017 at 01:42:34PM +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.
> It installed fine in 'jessie', then the upgrade to 'stretch' fails.
> 
> >From the attached log (scroll to the bottom...):
> 
>   Setting up grub-coreboot (2.02~beta3-5) ...
>   Installing new version of config file /etc/kernel/postinst.d/zz-update-grub 
> ...
>   Installing new version of config file /etc/kernel/postrm.d/zz-update-grub 
> ...
>   /var/lib/dpkg/info/grub-coreboot.config: 1: 
> /etc/default/grub.d/init-select.cfg: /usr/lib/init-select/get-init: not found
>   dpkg: error processing package grub-coreboot (--configure):
>subprocess installed post-installation script returned error exit status 
> 127
> 
> 
> This is most likely a bug in init-select, but since that package
> does not exist in stretch any more (and it will be removed during the
> upgrade from jessie to stretch due to dependencies/conflicts),
> grub-coreboot will have to work around the bug.

This is a tricky bug, so CCing debian-devel for comments.  (Note that
this applies to all grub- binary packages, not just
grub-coreboot.)

The basic problem in init-select is of course the good old favourite of
a conffile not behaving correctly when the package has been removed but
not purged.  This is probably worth fixing in unstable as follows, since
init-select is still there:

--- a/init-select.cfg
+++ b/init-select.cfg
@@ -1,1 +1,1 @@
-GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT 
$(/usr/lib/init-select/get-init)"
+GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT $([ ! -x 
/usr/lib/init-select/get-init ] || /usr/lib/init-select/get-init)"

I propose to NMU init-select with this change after a bit of testing and
the usual delay, since it would generally make life easier if there were
a non-broken version around somewhere.  We might also want to think
about putting that into jessie-proposed-updates.

However, I take Andreas's point that we need to work around this
somehow, probably in a stretch point release now, and that's where I
need feedback.  One possible approach would be to change grub-mkconfig
to do something like this:

  for x in ${sysconfdir}/default/grub.d/*.cfg ; do
if [ "$(basename "$x")" = init-select.cfg ] && [ ! -x 
/usr/lib/init-select/get-init ]; then
  # work around #863801
  continue
fi
if [ -e "${x}" ]; then
  . "${x}"
fi
  done

But that lumbers me with having to maintain a workaround patch forever,
since there's no guarantee that init-select would ever be purged from
affected systems.  I appreciate that it's only a few lines, but these
things pile up over time.  I also don't think that ignoring errors from
/etc/default/grub.d/*.cfg scripts is a good idea: they might actually be
important to booting the system, even though they aren't in this case.

I'd rather do something like checking in the postinst whether these
conditions hold:

 * init-select is removed but not purged
 * /etc/default/grub.d/init-select.cfg contents match the buggy contents
   shown above

... and if so, replace /etc/default/grub.d/init-select.cfg with the
corrected version, coordinated with the NMU above.  This ought to mean
that if a fixed version of init-select is installed in the future, then
there'll be no conffile prompt because the new version is already in
place.  It would open the possibility of a potential conffile prompt in
future if the conffile in question is changed further, but it doesn't
seem to me that init-select has a sufficiently long likely future
lifespan for this to be very probable.  Replacing the file with a
corrected version is better than removing it, moving it aside, or
commenting out the offending line, since none of those would have the
desired behaviour in the event that a fixed version of init-select is
installed.

The benefit of this approach, even though it's a bit more complicated,
is that I could eventually drop it once users can be expected to have
upgraded through a grub-* package containing this workaround.  That
means that I don't have to carry a permanent patch just because some
other package made use of my package's extension facilities and got it
wrong.

I fully appreciate that this is skating along the edge of policy's
requirements regarding conffiles, and arguably violates at least 10.7.4
"The maintainer scripts must not alter a conffile of any package,
including the one the scripts belong to".  However, I think that this is
a reasonable case of self-defence, and could be tolerable with
sufficient commentary and care.  I doubt I would be contemplating it if
init-select hadn't been removed from stretch.

Thoughts?  Can anyone think of a better solution than either of the two
I've outlined here?

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Le jeudi 24 mars 2016 à 00:56:47+, Ian Jackson a écrit :
> Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
> LVM"):
> > Thanks for your anwser. I understand.
> 
> Thanks.
> 
> > And I intend to become a contributor (currently working on it).
> 
> Thanks, and good luck.
> 
> There are of course many ways to be a contributor to Debian that don't
> involve formally joining the project and gaining some kind of approved
> status.  We have a lot of bugs that could do with investigation and
> perhaps need patches writing and testing, for example :-).

I'm currently working on packaging mailman3 suite, but I'm also following
some packages I've interests in.

Cheers,

-- 
PEB

Re: Bug#782264: grub-install fails in nested LVM

[Ian Jackson]

Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
LVM"):
> Thanks for your anwser. I understand.

Thanks.

> And I intend to become a contributor (currently working on it).

Thanks, and good luck.

There are of course many ways to be a contributor to Debian that don't
involve formally joining the project and gaining some kind of approved
status.  We have a lot of bugs that could do with investigation and
perhaps need patches writing and testing, for example :-).

Regards,
Ian.

Re: Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Le jeudi 24 mars 2016 à 00:23:40+, Ian Jackson a écrit :
> Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
> LVM"):
> > Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> > > You do not even have a right to a reply from a human.
> > 
> > I'm not sure to agree with that.
> 
> There are too many bugs and too few humans to deal with them.  We are
> not able to reply to every bug.  At least, if we prioritised writing a
> reply (even if only a vacuous one) to every bug, there would be other
> more important work that would go undone.
> 
> If you'd like to make a human connection with the project, it is best
> if you do that as a contributor.  Debian has many millions of users,
> and we can't make a personal connection with each one.

Thanks for your anwser. I understand.

And I intend to become a contributor (currently working on it).

Cheers,

-- 
PEB

Re: Bug#782264: grub-install fails in nested LVM

[Ian Jackson]

Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
LVM"):
> Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> > You do not even have a right to a reply from a human.
> 
> I'm not sure to agree with that.

There are too many bugs and too few humans to deal with them.  We are
not able to reply to every bug.  At least, if we prioritised writing a
reply (even if only a vacuous one) to every bug, there would be other
more important work that would go undone.

If you'd like to make a human connection with the project, it is best
if you do that as a contributor.  Debian has many millions of users,
and we can't make a personal connection with each one.

Thanks,
Ian.

Re: Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Hey,

First, I'd like to apologize for the way I asked for a fix or any solution
in that issue. I realize that it was inappropriate.

Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
> LVM"):
> > Anyway, I was more concerned by the non-ack of my report.
> 
> You received an ack of your report from the bug tracking system.
> 
> But it seems that you are concerned that this bug is not getting
> enough human attention.  That is quite possibly true.  Debian as a
> whole has too much work to do with too few people.  Maintainers have
> to choose which packages and which bug reports are going to receive
> their attention.

That's true, but I got used to see at least a human ack on bug reports, that
does not imply any commitment to solve the issue, but that is a way to say
that not only an automatized system received the report.

Maybe I should not get used to that human interaction, but I beleive that it
is exactly what makes a community, and that's what I thought I saw in the
social contract.

> Maintainers will try to work on those tasks which they think will give
> the biggest gain for the lowest effort.  Or - as volunteers - which
> they think are most fun.

That's fair.

> To try to escalate the priority of a bug you are interested in, by
> sending content-free pings, is rude.  Debian contributors should
> ignore a submitter who behaves in that way.

My apologies if that's what I made anybody think. My point was not to
escalate the priority of this bug but really to see a human being at the
other end.

> As a user, or a bug submitter, you do not have a right to a fix.

That's true, and I clearly shouldn't have been that though in my second and
third mail for this bug. Again, I'd like to apologize.

> You do not even have a right to a reply from a human.

I'm not sure to agree with that.

As far as I understood, -- and let me be clear, I *know* that I know less
about Debian than you do --, Debian, by its social contract, intends, as a
community, to focus on users needs and on the fact that nothing is made to
be hidden. In my opinion, there is no community if there is no human
interaction.

As someone becomes maintainer of a package, I'm keen on beleiving that he
chose to, and that he agrees to provide user support regarding the package
(not the software). In a public project, that relies on a community concept,
it appears to me as a very bad move to say "the automatized response is
enough", or to say "I do not have to make user support".

I have no right, but I beleive that there is commitment from a maintainer to
provide support (not fixes, just say that I'm not speaking in the wind). If
I'm wrong, -- and I guess that's your point --, then I'm sorry that I
misbeleived about Debian concept and philosophy.

> If you are dissatisfied with the progress of the work to investigate
> and fix a bug, then the Debian maintainainers will generally welcome
> your constructive help.  In this case that probably means: Feel Free
> To (Investigate And) Submit A Patch.
>
> If neither you nor your friends have the skills to work on the bug
> yourselves, and you would like to ensure you have a right to a reply
> to your emails and bug reports, I suggest you employ someone (an
> individual or a company), on a commercial basis, to provide you with
> the support you require.

I'm not dissatisfied with the progress of the work, I was dissatisfied with
the silence around my report, which seemed like "burying" the issue.

As you can see, I made a lot of investigations, especially to make sure that
the bug was really in the Debian package, but I did not succeed in finding
the exact issue, since I'm not able to reproduce the same behaviour with
bare grub2 software. I guess the issue is hidden in Debian patches, but I've
no proof of that, and not enough skills in that part of packaging to
bissect.

That was in my opinion a good move to ask someone who knows for some help.
The support could have been a simple ack, but at least, I'd have reached a
human.

Anyway, sorry, I shouldn't have been aggressive. I'll try again to find the
exact issue when I'll have some time to.

Cheers,

-- 
PEB

Re: Bug#782264: grub-install fails in nested LVM

[Ian Jackson]

Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
LVM"):
> Anyway, I was more concerned by the non-ack of my report.

You received an ack of your report from the bug tracking system.

But it seems that you are concerned that this bug is not getting
enough human attention.  That is quite possibly true.  Debian as a
whole has too much work to do with too few people.  Maintainers have
to choose which packages and which bug reports are going to receive
their attention.

Maintainers will try to work on those tasks which they think will give
the biggest gain for the lowest effort.  Or - as volunteers - which
they think are most fun.

To try to escalate the priority of a bug you are interested in, by
sending content-free pings, is rude.  Debian contributors should
ignore a submitter who behaves in that way.

As a user, or a bug submitter, you do not have a right to a fix.  You
do not even have a right to a reply from a human.

If you are dissatisfied with the progress of the work to investigate
and fix a bug, then the Debian maintainainers will generally welcome
your constructive help.  In this case that probably means: Feel Free
To (Investigate And) Submit A Patch.

If neither you nor your friends have the skills to work on the bug
yourselves, and you would like to ensure you have a right to a reply
to your emails and bug reports, I suggest you employ someone (an
individual or a company), on a commercial basis, to provide you with
the support you require.

Thanks,
Ian.

Re: Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Le mercredi 27 janvier 2016 à 18:13:29+, Martin Read a écrit :
> On 26/01/16 15:52, Pierre-Elliott Bécue wrote:
> >Bump.
> >
> >It's been more than 10 months and still nothing (even a simple ack).
> >
> >Could you consider adding a stable version of grub in a partial release of 
> >Jessie?
> 
> A cursory inspection of the public browsing interface[1] to the relevant git
> repo makes it clear that there is no newer *version*, despite 2.02 beta 2
> being two years old and there having been significant numbers of git commits
> since then.
> 
> [1] http://git.savannah.gnu.org/cgit/grub.git/

Right, 2.02 beta 3 is out now, maybe it's worth a try.

Anyway, I was more concerned by the non-ack of my report.

Cheers,

-- 
PEB

Re: Bug#782264: grub-install fails in nested LVM

[Martin Read]

On 26/01/16 15:52, Pierre-Elliott Bécue wrote:

Bump.

It's been more than 10 months and still nothing (even a simple ack).

Could you consider adding a stable version of grub in a partial release of 
Jessie?


A cursory inspection of the public browsing interface[1] to the relevant 
git repo makes it clear that there is no newer *version*, despite 2.02 
beta 2 being two years old and there having been significant numbers of 
git commits since then.


[1] http://git.savannah.gnu.org/cgit/grub.git/

Re: Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Le 9 avril 2015 18:05:50 GMT+02:00, "Pierre-Elliott Bécue"  a 
écrit :
>Source: grub
>Version: 2.02~beta2-22
>Severity: important
>
>Dear maintainer,
>
>I've met a bug in GRUB under a Proxmox environment, which I was able to
>reproduce under a clean Debian system (my laptop, under jessie).
>
>With Proxmox, I needed to build a nested LVM storage for my VM, that
>is,
>in the host point of view :
>
>/dev/sdxx (physical) -> first volumegroup (vg1) -> A single logical
>volume (lv1)
>(the guest physical disk) -> a single partition (lv1p1) -> a second
>volumegroup (vg2)
>-> logical volumes containing guest data. (slash, var, swap)
>
>For the guest, the single logical volume (lv1) is seen as the physical
>disk of the VM, named /dev/vda when the VM is started.
>
>Under wheezy, I was able to debootstrap wheezy on the disks, and to
>chroot in them to make a grub-install on lv1.
>
>Under jessie, I get an error :
>grub-install: error: disk
>`lvmid/[VOLUMEGROUPID]/[LOGICALVOLUMEID]'
>not found.
>
>I first thought it was a bug due to Proxmox VE. So I tried to build a
>proof of concept on my Jessie laptop, using an external drive. The
>problem is the same.
>
>I tried to git clone the grub repo and to compile it to try a
>grub-install, and this one worked. So it seems that grub 2.02~beta2-22
>is broken.
>
>I'm not able to say if it comes from Debian patches or from the actual
>upstream code, but it seems this problem is important enough to be
>noticed.
>
>I'll be happy to provide you with more data if I can.
>
>Cheers,

Bump.

It's been more than 10 months and still nothing (even a simple ack).

Could you consider adding a stable version of grub in a partial release of 
Jessie?

Thanks.
-- 
PEB

Re: Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Le jeudi 09 avril 2015 à 18:05:50+0200, Pierre-Elliott Bécue a écrit :
> Source: grub
> Version: 2.02~beta2-22
> Severity: important
> 
> Dear maintainer,
> [bug in grub, with grub-install]

Good evening,

It has been almost seven month since this bug report.

The fact that no update of grub has been done in a partial release of Jessie
seems pretty bad to me. But furthermore, I'm really disappointed that no
maintainer took any time to send me at least an ACK.

Is there any plan for fixing this bug, and putting in jessie an non-beta
version of GRUB?

Thanks, and sorry if I seem rude, but this bug prevents me from upgrading
part of my machines, and also made grub-install not properly usable on some
already upgraded ones.

Cheers.

-- 
PEB

Re: Debian Jessie netinst does not boot from grub/iso

[Cyril Brulebois]

Hi Norbert,

Norbert Preining  (2015-05-14):
> Hi everyone 
> 
> (please Cc)
> 
> I recently switched from a pre-release of the installer images
> .../sid_d-i/current/amd64/iso-cd/firmware-testing-amd64-netinst.iso
> (taken sometime about a year ago, or so)
> 
> to the final version
> ... firmware-8.0.0-amd64-netinst.iso
> 
> and now the system does not boot from USB stick via grub/iso anymore,
> telling be that it cannot find a CDROM drive.
> 
> Is this a known issue? I haven't seen any comments concerning
> this problem besides old ones not related to the released jessie.

Please use the BTS. dd@ really is not where one reports issues with
installation images.

https://www.debian.org/releases/stable/amd64/ch05s04.html.en#submit-bug


KiBi.


signature.asc
Description: Digital signature

Debian Jessie netinst does not boot from grub/iso

[Norbert Preining]

Hi everyone 

(please Cc)

I recently switched from a pre-release of the installer images
.../sid_d-i/current/amd64/iso-cd/firmware-testing-amd64-netinst.iso
(taken sometime about a year ago, or so)

to the final version
... firmware-8.0.0-amd64-netinst.iso

and now the system does not boot from USB stick via grub/iso anymore,
telling be that it cannot find a CDROM drive.

Is this a known issue? I haven't seen any comments concerning
this problem besides old ones not related to the released jessie.

Thanks

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150514051146.gp8...@auth.logic.tuwien.ac.at

Re: Bug#768329: grub-common: Please enable splash for jessie

[Christian Hofstaedtler]

* Jonathan Dowland  [141109 21:04]:
> In other words, plymouth installed but no 'splash' argument to the boot
> results in no change; adding 'splash' results in plymouth being activated
> albeit in text mode

That is my observation, yes.

> (so no modechange?)

Not by the default plymouth setup; the kernel does a KMS init in any
case, whether plymouth is installed or not.

> > Why's there a new boot parameter?
> > 
> > I don't know, but currently at least Ubuntu, Tanglu (both via
> > grub-common), and Fedora do it this way.
> > It's certainly nice to have the parameter so the recovery boot
> > option can skip plymouth (esp. if you were to enable a graphical
> > theme).
> 
> I presume the option is interpreted by systemd or plymouth, rather than the
> kernel. (raises an interesting question, where is this handled, and is it
> handled differently for different init systems?) I see no reason why Debian
> couldn't default to the opposite (plymouth installed? plymouth runs - some
> 'nosplash' command line argument passed? plymouth doesn't run) if that was
> determined to be preferential. IMHO on-by-default is a good idea, especially
> if boot-time password prompts are likely useless without it (at least with
> systemd, but this is functionally a regression from wheezy).

There's sysvinit (/etc/init.d/plymouth) and systemd
(/lib/systemd/system/*/plymouth*) specific code for the 'splash'
command line option, plus some additional code for initramfs-tools.

I think the current behaviour should be retained for these reasons:

 - GRUB has a way of passing additional options to the "default"
   boot option, but it can't do that for the "recovery" option (so
   no way to pass nosplash from /etc/default/grub)
 - We don't unnecessarily deviate from other distros for no good
   reason.

On-by-default is likely a good idea, which is why I'd like to see
'splash' being added to /e/d/g.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



pgpRTnQsG8hCG.pgp
Description: PGP signature

Re: Bug#768329: grub-common: Please enable splash for jessie

[Jonathan Dowland]

On Thu, Nov 06, 2014 at 05:19:40PM +0100, Christian Hofstaedtler wrote:
> Nothing in a default install currently Depends or Recommends
> plymouth, so don't worry about getting a graphical splash screen or
> anything. Anyway, if you were to install plymouth, the default
> "theme" is *text*.

In other words, plymouth installed but no 'splash' argument to the boot
results in no change; adding 'splash' results in plymouth being activated
albeit in text mode (so no modechange?)

> Plymouth is a terminal multiplexer. Without it, if, f.e., there is
> prompting for an encrypted disk passphrase, you'll end up with other
> messages writing over the password prompt and so on. [1] With plymouth
> installed you'll get a nice standalone prompt for the passphrase.
> I imagine this being the same for systemd and upstart and any other
> event-based inits.
> http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/
> has some additional background.
 
I'm reminded that the plymouth package short and long descriptions
need adjusting to reflect this as they are presently quite misleading
(but I'm as guilty as anyone else for not filing a wishlist bug for
this yet, let alone supplying suggested text)

> Why's there a new boot parameter?
> 
> I don't know, but currently at least Ubuntu, Tanglu (both via
> grub-common), and Fedora do it this way.
> It's certainly nice to have the parameter so the recovery boot
> option can skip plymouth (esp. if you were to enable a graphical
> theme).

I presume the option is interpreted by systemd or plymouth, rather than the
kernel. (raises an interesting question, where is this handled, and is it
handled differently for different init systems?) I see no reason why Debian
couldn't default to the opposite (plymouth installed? plymouth runs - some
'nosplash' command line argument passed? plymouth doesn't run) if that was
determined to be preferential. IMHO on-by-default is a good idea, especially
if boot-time password prompts are likely useless without it (at least with
systemd, but this is functionally a regression from wheezy).


-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141109200345.gf29...@chew.redmars.org

Re: Bug#768329: grub-common: Please enable splash for jessie

[Christian Hofstaedtler]

* Colin Watson  [141106 16:32]:
> In principle this makes sense; I'm just a bit nervous about this at this
> point, and changing this will cause a ucf prompt for large numbers of
> people, so I want to get it right first time.  CCing debian-devel; does
> anyone know of reasons why adding "splash" to the default command line
> would be a bad thing?

I just did a test upgrade from wheezy to jessie, and it appears that
there is already a ucf prompt for /etc/default/grub (removal of OS
prober settings).

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



signature.asc
Description: Digital signature

Re: Bug#768329: grub-common: Please enable splash for jessie

[Christian Hofstaedtler]

* Colin Watson  [141106 16:32]:
> In principle this makes sense; I'm just a bit nervous about this at this
> point, and changing this will cause a ucf prompt for large numbers of
> people, so I want to get it right first time.  CCing debian-devel; does
> anyone know of reasons why adding "splash" to the default command line
> would be a bad thing?

To give some context for debian-devel:

Nothing in a default install currently Depends or Recommends
plymouth, so don't worry about getting a graphical splash screen or
anything. Anyway, if you were to install plymouth, the default
"theme" is *text*.


Why does one need plymouth in the first place?

Plymouth is a terminal multiplexer. Without it, if, f.e., there is
prompting for an encrypted disk passphrase, you'll end up with other
messages writing over the password prompt and so on. [1] With plymouth
installed you'll get a nice standalone prompt for the passphrase.
I imagine this being the same for systemd and upstart and any other
event-based inits.
http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/
has some additional background.


Why's there a new boot parameter?

I don't know, but currently at least Ubuntu, Tanglu (both via
grub-common), and Fedora do it this way.
It's certainly nice to have the parameter so the recovery boot
option can skip plymouth (esp. if you were to enable a graphical
theme).


[1] How a passphrase prompt currently looks like:
https://i.imgur.com/DORkOKa.jpg

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



signature.asc
Description: Digital signature

Re: Bug#768329: grub-common: Please enable splash for jessie

[Colin Watson]

Control: reassign -1 grub-common

On Thu, Nov 06, 2014 at 04:11:11PM +0100, Christian Hofstaedtler wrote:
> * Colin Watson  [141106 16:06]:
> > On Thu, Nov 06, 2014 at 03:53:58PM +0100, Christian Hofstaedtler wrote:
> > > Please add the "splash" option to the Linux default command line, as
> > > just installing plymouth otherwise has no effect, and plymouth is the
> > > recommended solution for fixing bootup multiplexing issues (f.e.
> > > password prompting for encrypted disks).
> > 
> > This is supposed to be handled by grub-installer, which is part of d-i.
> 
> I do want to note that the grub packaging appears to have default
> command line handling for different distributions, and adding splash
> there would have the benefit(?) of everybody getting it, regardless
> how the system was installed (d-i, (grml-)debootstrap, etc.)

Hm, right, I guess that is grub2's responsibility.  Sorry for my
misunderstanding.

In principle this makes sense; I'm just a bit nervous about this at this
point, and changing this will cause a ucf prompt for large numbers of
people, so I want to get it right first time.  CCing debian-devel; does
anyone know of reasons why adding "splash" to the default command line
would be a bad thing?

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141106153206.gq5...@riva.ucam.org

Re: grub-mkconfig loop

[Heimo Stranner]

On 2014-07-09 01:05, Colin Watson wrote:
> [For the future, it's generally better to file bug reports about this
> kind of thing.  As luck would have it I manage to read -devel
> occasionally ...]

Yes i will!

> Thanks for your report.  Dropping -x isn't quite the right answer.  The
> bug is that using grep for this interprets regular expression
> metacharacters in the path.  Using fgrep instead fixes this (and quoting
> is of course a good idea too; the whole loop could probably use a
> rewrite IMO, but this will do for now).  I've fixed this upstream:
> 
>   
> http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=0901e7855f922e770cbfeb58262cb8fded518190
> 
> ... and cherry-picked it into the Debian packaging for my next upload:
> 
>   
> http://anonscm.debian.org/gitweb/?p=pkg-grub/grub.git;a=commitdiff;h=4bea8b3e2d4718fca3625d6e9707cbf249cb7aa6;hp=3d7a403d28c23372a4ef17c27622366bd2196670
> 

Thank you very much for fixing!

All the best
Heimo Stranner


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53bf979e.1090...@stranner.org

Re: grub-mkconfig loop

[Colin Watson]

[For the future, it's generally better to file bug reports about this
kind of thing.  As luck would have it I manage to read -devel
occasionally ...]

On Tue, Jul 08, 2014 at 02:21:12PM +0200, Heimo Stranner wrote:
> I use a self compiled linux kernel (make-kpkg) with a somewhat unusual
> name (/boot/vmlinuz-3.15.4+ and /boot/initrd.img-3.15.4+) on debian sid.
>
> It worked previously (sadly I can't be more precise here) but today
> update-grub ran into a loop where my custom kernel was detected by
> /etc/grub.d/10_linux over and over again.
> The variable $list contained the correctly detected installed kernels
> but my kernel would not be removed from $list at the end of the big
> while loop in the line with "list=`echo $list | tr ' ' '\n' | grep -vx
> $linux | tr '\n' ' '` . (line 349 for me)
> Therefore $linux in the next round of this big while loop would be my
> custom kernel again and again.
>
> For me changing the line to "list=`echo $list | tr ' ' '\n' | grep -v
> $linux | tr '\n' ' '` fixed the problem.
> Is there any reason the x option was used in the first place or $linux
> was not put in quotes? Is my fix a bad idea for some reason?

Thanks for your report.  Dropping -x isn't quite the right answer.  The
bug is that using grep for this interprets regular expression
metacharacters in the path.  Using fgrep instead fixes this (and quoting
is of course a good idea too; the whole loop could probably use a
rewrite IMO, but this will do for now).  I've fixed this upstream:

  
http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=0901e7855f922e770cbfeb58262cb8fded518190

... and cherry-picked it into the Debian packaging for my next upload:

  
http://anonscm.debian.org/gitweb/?p=pkg-grub/grub.git;a=commitdiff;h=4bea8b3e2d4718fca3625d6e9707cbf249cb7aa6;hp=3d7a403d28c23372a4ef17c27622366bd2196670

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140708230502.ga31...@riva.ucam.org

grub-mkconfig loop

[Heimo Stranner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I use a self compiled linux kernel (make-kpkg) with a somewhat unusual
name (/boot/vmlinuz-3.15.4+ and /boot/initrd.img-3.15.4+) on debian sid.

It worked previously (sadly I can't be more precise here) but today
update-grub ran into a loop where my custom kernel was detected by
/etc/grub.d/10_linux over and over again.
The variable $list contained the correctly detected installed kernels
but my kernel would not be removed from $list at the end of the big
while loop in the line with "list=`echo $list | tr ' ' '\n' | grep -vx
$linux | tr '\n' ' '` . (line 349 for me)
Therefore $linux in the next round of this big while loop would be my
custom kernel again and again.

For me changing the line to "list=`echo $list | tr ' ' '\n' | grep -v
$linux | tr '\n' ' '` fixed the problem.
Is there any reason the x option was used in the first place or $linux
was not put in quotes? Is my fix a bad idea for some reason?

Best regards
Heimo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTu+IzAAoJEJz2q6aG5VRzU3cQALlqZNHq41j5Plz3CHUY/I41
w5r/sH1vkVCYquF5qxU2YCA/pjnwBYEE7p5QNJoRWuGSU7A890N19Lyi01lu12oF
A6/ezrQIokNyeC0utrR6Fkb095v6yAVHgnDpHcLo0VAKqtc4CK3nfPPT+1/5+xD6
RJ1i/fSkwI1OtKNapDNP0lVKLUH6RPHYThq3zIcvFusPKbnx9CbOO9zb9pVuDs8M
j+misgxtsHHNuBD8mbhtR5Wt5ZuADLviCcu4vQO39YSs2BwtbbuyM2hCLYNFWRAj
vdB1vStCVtnkfWKlGI8ouv4SntlPWlSWkTKk0vs9xb3zkSCyi3ToijPTSG8m7/KV
FhZWkmrAwRfNkvbeLUFUHUTma/lSBccOJzTxUT/B+zIfJn94R5Nosj3Pn9OLHou5
mSuU6ofoibiqD6hV+Ba5EGxUIweYWLZfmvHs5WpbBb77/VilNIn0URzqxFt2LVyj
PbYcNS98X17+xelD4PiuikTgAMbuZMObNRxzRx65a1urzX9wuwMU/QWlfv5w8qbp
0TPd3fyqtoacsZv/AP4UA8pK5zACQOH2xjG4Va4aWDUMz+VSrLHDsPakjGDHFLNF
39QM7JEIhib8aHF4m4zIzKocHU6+2tMmO/5TuQScHtKWCKUZAhGEKedu/boesUjx
U6ZYjld8c5tFIjpVg8sV
=eD/l
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53bbe238.6020...@stranner.org

Bug#745588: ITP: grub-choose-default -- A GUI for easily changing the default in grub2

[David Mohr]

Package: wnpp
Severity: wishlist
Owner: David Mohr 

* Package name: grub-choose-default
  Version : 1.1
  Upstream Author : David Mohr 
* URL : http://de.mcbf.net/david/grubchoosedefault/
* License : GPL
  Programming Lang: C
  Description : A GUI for easily changing the default in grub2

A GUI for changing the default for grub2, either permanently or for the
next reboot only. It is specially useful for making one time excursion
to another OS and safely returning to the Debian homeland on the next
reboot. It can be considered a GUI version of grub-set-default and
grub-reboot.

I think it is feasible to maintain this package by myself: I am the
author, the package is fairly simple, and the grub config is not likely
to change frequently.

A while back I published Ubuntu packages at
https://launchpad.net/~bugs-da/+archive/grub-choose-default/ which I
would use as a basis for the Debian packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140423042900.9997.34383.report...@alucardo.nm.mcbf.net

Re: Danke für das beste OS der Welt, yup, and some grub/boot script suggestions

[Michael Ole Olsen]

Me2 :-)

I have some suggestions:
grub2 , I don't like its/its current integration, and the autogenerated 
files are very ugly - I used to use lilo ... sometimes grub fails with 
raid(even when debian says it has installed fully), auto updating grub after 
upgrading the system can fail sometimes (killed my system many times - 
failed to boot with lvm afterwards)
boot scripts ? - some are pretty some used to be ugly , and using various 
daemons - bash could be so pretty/manageable(debian is GNU after all..), sh 
could be so portable(but a bit ugly), sysv, well...


wish there was an option to not auto run grub after running debian 
upgrades... damn I'm tired of that

especially annoying if you compile kernels yourself
you could set kernels on hold if you got the time/patience for that on every 
new system...


an /etc file would be pretty for this (an apt.conf)... or never enforcing 
grub run unless 100% necessary
even if grub is run it should double or tripple check it has been run 
correctly, it has broken on raid6 before for me(grub2) and lvm2(grub2) , 
failed to boot afterwards (both in official installer and after system 
upgrade)


some suggestions from old debian user since around 2000 :)

grub2 is quite confusing in the start, but gets easier with time lilo 
was so easy

/etc files for your bootloader, comeon? .. no need for that..

/boot is all I need..

ram disks are quite confusing and hard to build, it should be much easier to 
make your own ramdisks.. , you never know if you got the right modules 
compiled in atm. - unless you double check
or unless you assume it assumed right for you :-) - it rarely does on 
lvm/raid systems IME


debian should be easier to use with your own custom kernels(kernel.org), 
instead of compiling them the debian way(dpkg-mkpg?), you should be free to 
make them on your own in /usr/src/linux, without apt messing it all up later 
on!


I miss an apt that doesn't break randomly, seems better in the newest stable 
release, but always manage to break my apt so much it becomes unrecoverable

dependency requirement infinite loop

and the boot routine has changed lately, now I cant custom symlink my stuff 
in /etc/rc2.d ... used to do that all the time

now it does nothing it seems

the init scripts often looked so ugly (yes) that I refused to look at them, 
not all of them, but it looked like different maintainers code? - very 
different code in each

could be much prettier, but seems you are working on it :)
my init scripts looking nice and not autorunning grub on upgrades(or option 
for that) is the only thing I miss in debian


and no fuzz in debian base installs (hopefully no daemons etc.)


thanks from Denmark :)
- Original Message - 
From: "Manuel Studer" 

To: 
Sent: Monday, April 14, 2014 9:49 PM
Subject: Danke für das beste OS der Welt


Sehr geehrtes Debian Dev. Team,

Ich möchte Ihnen allen meinen Dank für Ihre tolle Arbeit aussprechen.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact 
listmas...@lists.debian.org

Archive: https://lists.debian.org/534c3be5.90...@gmail.com


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/001101cf5878$51f34150$e1bca151@mxphome

Bug#744376: ITP: grub-customizer -- Grub Customizer is a graphical interface to configure the GRUB2/BURG settings and menuentries.

[magnus p.]

Package: wnpp
Severity: wishlist
Owner: "magnus p." 

* Package name: grub-customizer
  Version : 4.0.4
  Upstream Author : Daniel Richter 
* URL : https://launchpad.net/grub-customizer/
* License : GPLv3
  Programming Lang: C++
  Description : Customize the bootloader (GRUB2 or BURG).

Grub Customizer is a graphical interface to configure the GRUB2/BURG settings 
and menuentries

Features:
 * move, remove or rename menuentries (they stαy updatable by update-grub)
 * edit the contents of menuentries or create new ones (internally it edits the 
40_custom)
 * support for GRUB2 and BURG
 * reinstallation of the bootloader to MBR
 * settings like default operating system, kernel params, background image and 
text colors etc.
 * changing the installed operating system by running on a live cd


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140413135035.4355.85636.reportbug@debian.magnus

Re: Last call for pv-grub-menu.

[Thorsten Glaser]

Samuel Thibault  debian.org> writes:

> > Isn’t there a GRUB2 port for Xen now?
> 
> Yes, and it will be part of the grub2 source code, but that's not
> released yet.

But it’s in Debian already (which is where I saw it before writing
the above posting):

http://packages.debian.org/experimental/grub-xen

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20131227t155747-...@post.gmane.org

Re: Last call for pv-grub-menu.

[Jonathan Dowland]

On Mon, Dec 16, 2013 at 09:48:29AM -0500, Paul Tagliamonte wrote:
> If you want this package in Debian, you just had to reply to my original
> mail to you with "Yes" and re-dput it. Instead, you've wasted everyone's
> time with these threads, and I'm sitting here, trying to reply to this.

FWIW I don't consider my time wasted. It's been useful data for my
eventual decision on an O/S for a substantial private cloud installation
at $JOB.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131219185916.ga31...@bryant.redmars.org

Re: Last call for pv-grub-menu.

[Colin Watson]

On Thu, Dec 19, 2013 at 09:32:24AM +0100, Samuel Thibault wrote:
> Colin Watson, le Thu 19 Dec 2013 02:29:58 +, a écrit :
> > If we try really hard we might even be able to have compatibility in
> > the other direction as well.
> 
> I've not tested, but there is no reason why it shouldn't work.

The main delicate bit is reading the domU menu.lst that would be in use
in this setup.  GRUB 2 has legacy_configfile et al that should do the
job, but it's not the most broadly-tested area of GRUB so there could be
problems there.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131219104724.ga27...@riva.ucam.org

Re: Last call for pv-grub-menu.

[Samuel Thibault]

Colin Watson, le Thu 19 Dec 2013 02:29:58 +, a écrit :
> If we try really hard we might even be able to have compatibility in
> the other direction as well.

I've not tested, but there is no reason why it shouldn't work.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131219083224.gk5...@type.youpi.perso.aquilenet.fr

Re: Last call for pv-grub-menu.

[Thomas Goirand]

On 12/19/2013 10:29 AM, Colin Watson wrote:
> On Sun, Dec 15, 2013 at 12:11:23AM +0900, Charles Plessy wrote:
>> Le Sat, Dec 14, 2013 at 09:17:58AM +, Ian Campbell a écrit :
>>> Do you have a reference to the conversation you had with the grub(1,2)
>>> maintainers? I don't see it in the pkg-grub-devel archives.
>>
>> Hi Ian,
>>
>> there was no conversation with the GRUB maintainers, however, they have seen
>> http://bugs.debian.org/672104, which was a whishlist bug on GRUB2 before
>> becoming an ITP.  I take their silence as an evidence for their lack of
>> interest, which is totally justified.
> 
> Sorry I never responded to this.  I think it is probably true that we
> have little interest in maintaining this as such, as part of our general
> lack of interest in much more than bare-bones ongoing maintenance for
> GRUB Legacy-related code (I have been doing some minimal amount of this
> but it's really not anyone's focus), so I'm glad that you're doing so
> and I support it being a separate package.
> 
> 
> For what it's worth, we do now have a PV-GRUB2, thanks to considerable
> work upstream; I recently uploaded a new version of grub2 to
> experimental that ships a grub-xen-bin binary package with the raw
> kernel and modules, and a skeletal grub-xen binary package which
> currently does nothing of interest but will hopefully soon install a
> loader in a conventional location within a domU that can be picked up by
> a dom0.  grub-xen-bin can be made to work even now with some manual
> assembly, so I'm happy that we have at least a proof of concept.
> 
> We're still fleshing out the details (see recent threads on grub-devel),
> and I need to write up a proper boot protocol for attention from
> xen-devel, but I hope we can get to the point where it can even be
> loaded by PV-GRUB1 with maybe just a simple shim menu.lst.  If we try
> really hard we might even be able to have compatibility in the other
> direction as well.
> 
> Obviously it will take some time to filter through everywhere, but I
> rather hope that eventually both PV-GRUB1 and pv-grub-menu will be able
> to die a natural death.  In the meantime it certainly serves a useful
> purpose.

Thanks a lot for working on this. I'm looking forward for the time where
all this will be finished and fully useable. Please do self-promote your
work and announce it to this list when you consider it's ready.

Cheers,

Thomas Goirand (zigo)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52b2aefd.1090...@debian.org

Re: Last call for pv-grub-menu.

[Colin Watson]

On Sun, Dec 15, 2013 at 12:11:23AM +0900, Charles Plessy wrote:
> Le Sat, Dec 14, 2013 at 09:17:58AM +, Ian Campbell a écrit :
> > Do you have a reference to the conversation you had with the grub(1,2)
> > maintainers? I don't see it in the pkg-grub-devel archives.
> 
> Hi Ian,
> 
> there was no conversation with the GRUB maintainers, however, they have seen
> http://bugs.debian.org/672104, which was a whishlist bug on GRUB2 before
> becoming an ITP.  I take their silence as an evidence for their lack of
> interest, which is totally justified.

Sorry I never responded to this.  I think it is probably true that we
have little interest in maintaining this as such, as part of our general
lack of interest in much more than bare-bones ongoing maintenance for
GRUB Legacy-related code (I have been doing some minimal amount of this
but it's really not anyone's focus), so I'm glad that you're doing so
and I support it being a separate package.


For what it's worth, we do now have a PV-GRUB2, thanks to considerable
work upstream; I recently uploaded a new version of grub2 to
experimental that ships a grub-xen-bin binary package with the raw
kernel and modules, and a skeletal grub-xen binary package which
currently does nothing of interest but will hopefully soon install a
loader in a conventional location within a domU that can be picked up by
a dom0.  grub-xen-bin can be made to work even now with some manual
assembly, so I'm happy that we have at least a proof of concept.

We're still fleshing out the details (see recent threads on grub-devel),
and I need to write up a proper boot protocol for attention from
xen-devel, but I hope we can get to the point where it can even be
loaded by PV-GRUB1 with maybe just a simple shim menu.lst.  If we try
really hard we might even be able to have compatibility in the other
direction as well.

Obviously it will take some time to filter through everywhere, but I
rather hope that eventually both PV-GRUB1 and pv-grub-menu will be able
to die a natural death.  In the meantime it certainly serves a useful
purpose.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131219022958.ga19...@riva.ucam.org

Re: Last call for pv-grub-menu.

[Charles Plessy]

Le Mon, Dec 16, 2013 at 09:48:29AM -0500, Paul Tagliamonte a écrit :
> 
> If you want this package in Debian, you just had to reply to my original
> mail to you with "Yes" and re-dput it. Instead, you've wasted everyone's
> time with these threads, and I'm sitting here, trying to reply to this.

Paul, your answer lacks references to messages and version numbers.  I answered
to you, re-uploaded the package, got contacted by another member of your team,
answered him, and then nothing happened for three monthes.

Thanks for accepting the pacakge.

In the future, I recommend to better organise the work of the FTP team.  Have
you considered using a public tracking system like in Fedora ?

http://fedoraproject.org/wiki/Package_Review_Process

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131217172319.gb23...@falafel.plessy.net

Re: Last call for pv-grub-menu.

[Thomas Goirand]

On 12/17/2013 08:05 AM, Paul Tagliamonte wrote:
> On Tue, Dec 17, 2013 at 08:02:59AM +0800, Thomas Goirand wrote:
>> On Tue Dec 17 2013 01:33:18 AM HKT, Paul Tagliamonte  
>> wrote:
>>
>>> On Tue, Dec 17, 2013 at 01:29:06AM +0800, Thomas Goirand wrote:
 That's a very good news. However, if this is your view, why don't you
 just accept the package now?
>>>
>>> No one told me "Yes", and let me know it was re-uploaded. I think I left
>>> a note on it, so it wasn't in my usual process-new workflow.
>>>
>>> Someone just tell me "Yes". Literally, that's it.
>>
>> "Yes" :)
>>
>> Thomas
> 
> Marked for ACCEPT
> 
> Now, was that so hard? :)
> 
> Cheers,
>   Paul

It wasn't. U r0x, as always. ;)

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52afa3a1.2020...@debian.org

Re: Last call for pv-grub-menu.

[Paul Tagliamonte]

On Tue, Dec 17, 2013 at 08:02:59AM +0800, Thomas Goirand wrote:
> On Tue Dec 17 2013 01:33:18 AM HKT, Paul Tagliamonte  
> wrote:
> 
> > On Tue, Dec 17, 2013 at 01:29:06AM +0800, Thomas Goirand wrote:
> > > That's a very good news. However, if this is your view, why don't you
> > > just accept the package now?
> > 
> > No one told me "Yes", and let me know it was re-uploaded. I think I left
> > a note on it, so it wasn't in my usual process-new workflow.
> > 
> > Someone just tell me "Yes". Literally, that's it.
> 
> "Yes" :)
> 
> Thomas

Marked for ACCEPT

Now, was that so hard? :)

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Last call for pv-grub-menu.

[Thomas Goirand]

On Tue Dec 17 2013 01:33:18 AM HKT, Paul Tagliamonte  wrote:

> On Tue, Dec 17, 2013 at 01:29:06AM +0800, Thomas Goirand wrote:
> > That's a very good news. However, if this is your view, why don't you
> > just accept the package now?
> 
> No one told me "Yes", and let me know it was re-uploaded. I think I left
> a note on it, so it wasn't in my usual process-new workflow.
> 
> Someone just tell me "Yes". Literally, that's it.
> 
> Cheers,
>     Paul

"Yes" :)

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1387238579.1760.14.camel@Nokia-N900-42-11

Re: Last call for pv-grub-menu.

[Paul Tagliamonte]

On Tue, Dec 17, 2013 at 01:29:06AM +0800, Thomas Goirand wrote:
> That's a very good news. However, if this is your view, why don't you
> just accept the package now?

No one told me "Yes", and let me know it was re-uploaded. I think I left
a note on it, so it wasn't in my usual process-new workflow.

Someone just tell me "Yes". Literally, that's it.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Last call for pv-grub-menu.

[Thomas Goirand]

On 12/16/2013 10:48 PM, Paul Tagliamonte wrote:
> On Sat, Dec 14, 2013 at 01:47:21PM +0900, Charles Plessy wrote:
>> However, it has been three monthes that the package is blocked in the NEW 
>> queue
>> because the FTP team would prefer its contents to be part of an existing
>> package.
> 
> Plessy, I'm finding dealing with these misrepresentations tiresome.
> 
> Please re-read my original reject. Everyone else usually replies "Yes"
> or "No", but you're off making flame-bait on -devel.
> 
> The question asked, Charles, is "Does this need to be it's own package".
> One answer is "yes". Please read my mails to you on this subject that
> you're apparently not reading.
> 
> We could have been done with this months ago, but you're really making a
> big flame-thread and repeating false information.
> 
> If you want this package in Debian, you just had to reply to my original
> mail to you with "Yes" and re-dput it. Instead, you've wasted everyone's
> time with these threads, and I'm sitting here, trying to reply to this.
> 
> Annoyed,
>   Paul

That's a very good news. However, if this is your view, why don't you
just accept the package now?

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52af3862.2070...@debian.org

Re: Last call for pv-grub-menu.

[Ben Hutchings]

On Mon, Dec 16, 2013 at 02:35:54PM +, Thorsten Glaser wrote:
> Philipp Kern wrote:
> 
> >…and Xen in general. I agree with this assessment.
> 
> Isn’t there a GRUB2 port for Xen now?

So I heard.  In fact I remember a conversation with Colin Watson and
Ian Jackson about a month back about how a Xen host could detect and
run a Xen-aware GRUB in domU automatically (with pv-grub as a
fallback).

Ben.

-- 
Ben Hutchings
Life is like a sewer:
what you get out of it depends on what you put into it.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131216171856.gh16...@decadent.org.uk

Re: Last call for pv-grub-menu.

[Samuel Thibault]

Thorsten Glaser, le Mon 16 Dec 2013 14:35:54 +, a écrit :
> Philipp Kern wrote:
> >…and Xen in general. I agree with this assessment.
> 
> Isn’t there a GRUB2 port for Xen now?

Yes, and it will be part of the grub2 source code, but that's not
released yet.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131216171143.gu9...@type.bordeaux.inria.fr

Re: Last call for pv-grub-menu.

[Paul Tagliamonte]

On Sat, Dec 14, 2013 at 01:47:21PM +0900, Charles Plessy wrote:
> However, it has been three monthes that the package is blocked in the NEW 
> queue
> because the FTP team would prefer its contents to be part of an existing
> package.

Plessy, I'm finding dealing with these misrepresentations tiresome.

Please re-read my original reject. Everyone else usually replies "Yes"
or "No", but you're off making flame-bait on -devel.

The question asked, Charles, is "Does this need to be it's own package".
One answer is "yes". Please read my mails to you on this subject that
you're apparently not reading.

We could have been done with this months ago, but you're really making a
big flame-thread and repeating false information.

If you want this package in Debian, you just had to reply to my original
mail to you with "Yes" and re-dput it. Instead, you've wasted everyone's
time with these threads, and I'm sitting here, trying to reply to this.

Annoyed,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Last call for pv-grub-menu.

[Thorsten Glaser]

Philipp Kern wrote:

>…and Xen in general. I agree with this assessment.

Isn’t there a GRUB2 port for Xen now?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/l8n34a$qfj$1...@ger.gmane.org

Re: Last call for pv-grub-menu.

[Charles Plessy]

Le Sat, Dec 14, 2013 at 09:17:58AM +, Ian Campbell a écrit :
> 
> Do you have a reference to the conversation you had with the grub(1,2)
> maintainers? I don't see it in the pkg-grub-devel archives.

Hi Ian,

there was no conversation with the GRUB maintainers, however, they have seen
http://bugs.debian.org/672104, which was a whishlist bug on GRUB2 before
becoming an ITP.  I take their silence as an evidence for their lack of
interest, which is totally justified.

The last message I had from the FTP team asks why the bug became an ITP within
a day.  Frankly speaking, I think I remember why, but it was probably a private
and indirect message.  I spent hours, literally, trying to find a copy on the
archived mailing lists or on my hard drive, and I did not find it.  I am sorry
for this.

As noticed in this thread, the request is anyway pointless, and I also
underlined this in the thread "Nitpicking in the NEW queue" last September.  In
particular, I wrote:

Atcutally, I do not know what is missing from README.Debian to justify the
existence of this package.  It runs a script each time a kernel package is
installed or removed.  I do not see which other package would be fit for
these kernel hooks.

Back to the question about why #672104 was changed to an ITP within a day, out
of frustration, I told the FTP team to ask the GRUB maintainers if they want to
make sure that the functions of pv-grub-menu can not be addeed to existing
binary packages.  Here is my message in full.  By the way, I think that the
package reviews should be publically archived, for instance by CCing the ITP.

   We are just wasting our time trying to micromanage or over-optimise things.  
 
   If you want to know the grub-* maintainers think, ask them directly. 
 

  
   1) grub-legacy will fail if the MBR can not be modified.  pv-grub-menu is a  
 
   package for systems where the MBR can not be modified.   
 

  
   2) grub-legacy is in maintainance mode, no new developments.  This is not my 
 
   decision, but I find it sound, and will not argue agaisnt.   
 

      
   3) In Ubuntu, pv-grub-menu is a binary package of the cloud-init source 
package   
   (with a different name and lots of cruft), but is not related to the 
upstream 
   sources.  Me and the cloud-init upstream+Ubuntu maintainer agreed to 
separate 
   them in independant source packages.   


I admit that the tone is not cooperative, but I am not the FTP team's circus
monkey, and I strongly dislike to have to bug the whole project for hosting the
pv-grub-menu scripts in an existing package despite I already gave arguments
that I think are strong enough to decide that it is the wrong solution.

So, FTP team, please take your decision and let's close this story.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131214151123.ga21...@falafel.plessy.net

Re: Last call for pv-grub-menu.

[Philipp Kern]

On 2013-12-14 05:47, Charles Plessy wrote:

pv-grub-menu is a package that maintains a configuration file in
/boot/grub/menu.lst, that is read by the PV-GRUB boot system.  It can 
not be
part of the grub-legacy package, which is in maintainance mode, and 
GRUB2
maintainers have not expressed an interest for hosting the scripts 
(which are
not relevant to GRUB2).  pv-grub-menu is a specialised package that is 
only

useful for system images booted by PV-GRUB, in particular on the Amazon
platform.


…and Xen in general. I agree with this assessment.

However, it has been three monthes that the package is blocked in the 
NEW queue
because the FTP team would prefer its contents to be part of an 
existing

package.


That's odd. I think in this case it outweighs the trouble of introducing 
a new package. It already needs to get its own binary package that's not 
co-installable with legacy grub, because it owns the menu listing and 
having both grub.cfg and menu.lst because grub2 is installed would be 
confusing as well. So the only additional bit is the source package.


But I didn't look for the real reject rationale, if there was one. 
(Instead of just polite feedback asking if it could done differently, 
which wouldn't be accessibly archived.)


Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/b6a6c99538fddcaa0f4d6d31f89ed...@hub.kern.lc

Re: Last call for pv-grub-menu.

[Thomas Goirand]

On 12/14/2013 12:47 PM, Charles Plessy wrote:
> Dear all,
> 
> pv-grub-menu is a package that maintains a configuration file in
> /boot/grub/menu.lst, that is read by the PV-GRUB boot system.  It can not be
> part of the grub-legacy package, which is in maintainance mode, and GRUB2
> maintainers have not expressed an interest for hosting the scripts (which are
> not relevant to GRUB2).  pv-grub-menu is a specialised package that is only
> useful for system images booted by PV-GRUB, in particular on the Amazon
> platform.
> 
> However, it has been three monthes that the package is blocked in the NEW 
> queue
> because the FTP team would prefer its contents to be part of an existing
> package.
> 
> You can find more about pv-grub-menu at the following link.
> 
> 
> http://anonscm.debian.org/gitweb/?p=collab-maint/pv-grub-menu.git;a=summary

I do really think this package is important, and I want to see it in
Debian as well. Not having it in Debian blocked me from having
openstack-debian-images to support non-HVM Xen systems.

I do also think that it should be separated from GRUB itself, since
that's a completely separated thing. Asking for it to be part of grub2,
would be as if you'd ask mawk to be part of gawk. It makes absolutely no
sense to me, these are completely different implementation.

Could the FTP masters reconsider their view?

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ac2b71.4080...@debian.org

Re: Last call for pv-grub-menu.

[Ian Campbell]

On Sat, 2013-12-14 at 13:47 +0900, Charles Plessy wrote:
> Dear all,
> 
> pv-grub-menu is a package that maintains a configuration file in
> /boot/grub/menu.lst, that is read by the PV-GRUB boot system.  It can not be
> part of the grub-legacy package, which is in maintainance mode, and GRUB2
> maintainers have not expressed an interest for hosting the scripts (which are
> not relevant to GRUB2).

Do you have a reference to the conversation you had with the grub(1,2)
maintainers? I don't see it in the pkg-grub-devel archives.

>   pv-grub-menu is a specialised package that is only
> useful for system images booted by PV-GRUB, in particular on the Amazon
> platform.
> 
> However, it has been three monthes that the package is blocked in the NEW 
> queue
> because the FTP team would prefer its contents to be part of an existing
> package.

Do you have a reference to that conversation with the ftp team? I don't
see it on the ITP for example.

Have you explained to them that neither of the two obvious places where
this could live are willing to accept it (assuming this is the case)? In
the past when they have made this kind of requests it has been more to
check that it has been considered than because it is a hard and fast
rule which they are unwilling to move on.

Ian.


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

Re: Last call for pv-grub-menu.

[Samuel Thibault]

Charles Plessy, le Sat 14 Dec 2013 13:47:21 +0900, a écrit :
> It can not be part of the grub-legacy package, which is in
> maintainance mode, and GRUB2 maintainers have not expressed an
> interest for hosting the scripts (which are not relevant to GRUB2).

Couldn't it be part of the xen package?

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131214071706.gh6...@type.youpi.perso.aquilenet.fr

Last call for pv-grub-menu.

[Charles Plessy]

Dear all,

pv-grub-menu is a package that maintains a configuration file in
/boot/grub/menu.lst, that is read by the PV-GRUB boot system.  It can not be
part of the grub-legacy package, which is in maintainance mode, and GRUB2
maintainers have not expressed an interest for hosting the scripts (which are
not relevant to GRUB2).  pv-grub-menu is a specialised package that is only
useful for system images booted by PV-GRUB, in particular on the Amazon
platform.

However, it has been three monthes that the package is blocked in the NEW queue
because the FTP team would prefer its contents to be part of an existing
package.

You can find more about pv-grub-menu at the following link.

http://anonscm.debian.org/gitweb/?p=collab-maint/pv-grub-menu.git;a=summary

If by 2014, either the scripts are not adopted in another package, or the
package has not been accepted in Debian, I will give up, and also seriously
reconsider my participation to the Debian Cloud project altogether, because in
these conditions (monthes of delays for simple developments) it is just too
hard to keep focus or momentum.

Note that it is not a complain or a menace, but if we can not increase the the
throughput of the NEW queue, then the only solution is to reduce the input.  No
need to try to do the impossible.

Cheers, 

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131214044721.gc20...@falafel.plessy.net

Bug#724474: ITP: grub-legacy-doc -- Documentation for GRUB Legacy

[Colin Watson]

Package: wnpp
Severity: wishlist
Owner: Colin Watson 

* Package name: grub-legacy-doc
  Version : 0.97
  Upstream Author : bug-g...@gnu.org
* URL : http://www.gnu.org/software/grub/grub-legacy.html
* License : GFDL
  Description : Documentation for GRUB Legacy

http://bugs.debian.org/708946 reports that the GRUB Legacy info
documentation is non-free due to the use of the GFDL 1.2 with
Front-Cover and Back-Cover Texts (cf.
http://www.debian.org/vote/2006/vote_001).  The GRUB 2 info
documentation does not have this problem; but GRUB Legacy is
aggressively in maintenance mode and I do not expect to get upstream
approval to adjust its licensing.

I think the most practical resolution involving spending the least
effort on GRUB Legacy is to split off its documentation into a source
package in non-free.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130924060306.ga2...@sarantium.pelham.vpn.ucam.org

Re: Grub 2.00 in testing?

[Paul Wise]

On Wed, Jul 24, 2013 at 10:51 AM, Paul Wise wrote:

> Ok, makes sense, will look if the needed info is in UDD and fix the
> madison CGI if so.

CGI fixed just now.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6h__tx48k+bwtrua07xrdv6zs_z_zdd8jhkg_pao23...@mail.gmail.com

Re: Grub 2.00 in testing?

[Paul Wise]

On Tue, Jul 23, 2013 at 11:01 AM, Cyril Brulebois wrote:

> I want rmadison to be a remote madison, meaning a remote dak ls… which
> is what it's supposed to be! That means behaving like dak ls, and
> showing what matters, that is: not the extra sources.
>
> I hope it clarifies the above "correctness" you mentioned. rmadison
> might currently reflects what's in Sources file, but that isn't the
> point, or its job.

Ok, makes sense, will look if the needed info is in UDD and fix the
madison CGI if so.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6F_zg=od5dQgVSh7oAFFGTqKpgG12ZYySNgaZ=doq0=m...@mail.gmail.com

Re: rmadison vs. dak ls (was: Re: Grub 2.00 in testing?)

[Alexander Reichle-Schmehl]

Hi!

* Ansgar Burchardt  [130723 11:11]:
[..]
> Please also not that the additional source packages included can be at a
> *higher* version than sources included in src_association. This is what
> happened here: grub2_1.99-27+deb7u1 is in jessie, however a package
> embedding a newer version of grub2 migrated to testing. This make
> grub2_2.00-14 appear in jessie's Sources as an additional source package.

Just out of curiosity: Does that also mean, that a user running 'apt-get
source ' may not receive the package version shipped in
testing, but one used by an other package?


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130723224226.gh8...@iara.alphamar.org

Re: Grub 2.00 in testing?

[Carl Johnson]

"Adam D. Barratt"  writes:

> On Sun, 2013-07-21 at 20:42 -0700, Carl Johnson wrote:
>> Does anybody know what is going on with grub in testing?  I have been
>> waiting for 2.00, but it seems to be stuck at 1.99.  Grub-common at
>> http://packages.debian.org/jessie/grub-common shows that it is at
>> 1.99-27+deb7u1, but the source files show 2.00-14.  The qa page at
>> http://packages.qa.debian.org/g/grub2.html shows that 2.00-14 was
>> migrated to testing on 2013-06-14, so there appear to be some
>> inconsistancies.
>
> The migration notification is in error; it's a bug in the script that
> generates the notifications, that doesn't ignore extra entries included
> in the Sources files added by the archive management software in order
> to help with some license compliance. Now that we're aware of it, that
> bug will be fixed.
>
> As you mention checking the Sources files, I suspect you've made the
> same (reasonable) mistake that the script is currently making - if the
> stanza has "Extra-Source-Only: yes" then it is only there for compliance
> and does not indicate that the package is in testing.
>
> Apologies for the confusion; grub2 2.00 has indeed not yet made it to
> testing.

Thank you for the explanation.  I don't really want to use unstable so
I'll just continue waiting.
-- 
Carl Johnsonca...@peak.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87li4x46jo.fsf@oak.localnet

rmadison vs. dak ls (was: Re: Grub 2.00 in testing?)

[Ansgar Burchardt]

On 07/23/2013 09:03, Paul Wise wrote:
> On Mon, Jul 22, 2013 at 10:14 PM, Cyril Brulebois wrote:
>> I've just noticed that #699268 is supposed to be fixed, but last I heard
>> about somebody from QA, that was during the last stages of the wheezy
>> release cycle, and while the issue was known back then, I think not
>> everyone agreed it was the right time to try and get that fixed (that
>> conversation probably happened on #debian-release if memory serves,
>> which I doubt).
> 
> Hmm, ok. So you want madison to hide versions that exist but aren't
> the latest version? The Debian archive has had the ability to have
> multiple versions in the same suite for quite a while, I'm a bit
> surprised this is coming up now. I seem to remember that Built-Using
> isn't the only case where this can happen - library transitions can
> too IIRC.

It's a matter of perspective.

The archive software (dak) has a table that says which source package is
in which suite (src_associations). This is what "dak ls" will show for
which rmadison was an interface in the past.

For a long time this was identical with what ended in the Sources
indices, however dak now may include additional packages there. This is
used to include source packages referenced by the (also new) Built-Using
field which indicates additional source packages to keep as the full
source of a binary package. This way they end up on all mirrors
(including partial mirrors using debmirror) and CD images.
These packages are marked with a "Extra-Source-Only: yes" header.
See [1] and [2] for a bit more details.

  [1] 
  [2] 

But with this there are now two different meanings for a source package
being part of a suite: it can be in both src_associations and Sources OR
it can be only in Sources.  dak ls shows only the former group, rmadison
shows both.

I think that rmadison should behave like "dak ls" and only show source
packages not marked as "Extra-Source-Only: yes".

Please also not that the additional source packages included can be at a
*higher* version than sources included in src_association. This is what
happened here: grub2_1.99-27+deb7u1 is in jessie, however a package
embedding a newer version of grub2 migrated to testing. This make
grub2_2.00-14 appear in jessie's Sources as an additional source package.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ee48c7.7090...@debian.org

Re: Grub 2.00 in testing?

[Cyril Brulebois]

Paul Wise  (2013-07-23):
> On Mon, Jul 22, 2013 at 10:14 PM, Cyril Brulebois wrote:
> 
> > Possibly anything popping up in Built-Using. Random example:
> > kibi@arya:~$ \rmadison busybox -s stable,testing,unstable
> 
> Looks correct:
> 
> pabs@quantz:~$ zcat
> /srv/mirrors/debian/dists/{stable,testing,unstable}/main/source/Sources.gz
> | grep-dctrl -s Version -XP busybox | sort -u
> Version: 1:1.20.0-7
> Version: 1:1.20.0-8.1
> 
> > Or even worse:
> > kibi@arya:~$ \rmadison linux -s stable,testing,unstable
> 
> Looks correct:
> 
> ftp://ftp.debian.org/debian/pool/main/l/linux/
> 
> and this:
> 
> pabs@quantz:~$ zcat
> /srv/mirrors/debian/dists/{stable,testing,unstable}/main/source/Sources.gz
> | grep-dctrl -s Version -XP  linux | sort -u
> Version: 3.10.1-1
> Version: 3.2.32-1
> Version: 3.2.39-2
> Version: 3.2.41-2
> Version: 3.2.41-2+deb7u2
> Version: 3.2.46-1
> Version: 3.9.6-1
> Version: 3.9.8-1
> 
> > I've just noticed that #699268 is supposed to be fixed, but last I heard
> > about somebody from QA, that was during the last stages of the wheezy
> > release cycle, and while the issue was known back then, I think not
> > everyone agreed it was the right time to try and get that fixed (that
> > conversation probably happened on #debian-release if memory serves,
> > which I doubt).
> 
> Hmm, ok. So you want madison to hide versions that exist but aren't
> the latest version? The Debian archive has had the ability to have
> multiple versions in the same suite for quite a while, I'm a bit
> surprised this is coming up now. I seem to remember that Built-Using
> isn't the only case where this can happen - library transitions can
> too IIRC.

I want rmadison to be a remote madison, meaning a remote dak ls… which
is what it's supposed to be! That means behaving like dak ls, and
showing what matters, that is: not the extra sources.

I hope it clarifies the above "correctness" you mentioned. rmadison
might currently reflects what's in Sources file, but that isn't the
point, or its job.

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130723090112.ga22...@mraw.org

Re: Grub 2.00 in testing?

[Paul Wise]

On Mon, Jul 22, 2013 at 10:14 PM, Cyril Brulebois wrote:

> Possibly anything popping up in Built-Using. Random example:
> kibi@arya:~$ \rmadison busybox -s stable,testing,unstable

Looks correct:

pabs@quantz:~$ zcat
/srv/mirrors/debian/dists/{stable,testing,unstable}/main/source/Sources.gz
| grep-dctrl -s Version -XP busybox | sort -u
Version: 1:1.20.0-7
Version: 1:1.20.0-8.1

> Or even worse:
> kibi@arya:~$ \rmadison linux -s stable,testing,unstable

Looks correct:

ftp://ftp.debian.org/debian/pool/main/l/linux/

and this:

pabs@quantz:~$ zcat
/srv/mirrors/debian/dists/{stable,testing,unstable}/main/source/Sources.gz
| grep-dctrl -s Version -XP  linux | sort -u
Version: 3.10.1-1
Version: 3.2.32-1
Version: 3.2.39-2
Version: 3.2.41-2
Version: 3.2.41-2+deb7u2
Version: 3.2.46-1
Version: 3.9.6-1
Version: 3.9.8-1

> I've just noticed that #699268 is supposed to be fixed, but last I heard
> about somebody from QA, that was during the last stages of the wheezy
> release cycle, and while the issue was known back then, I think not
> everyone agreed it was the right time to try and get that fixed (that
> conversation probably happened on #debian-release if memory serves,
> which I doubt).

Hmm, ok. So you want madison to hide versions that exist but aren't
the latest version? The Debian archive has had the ability to have
multiple versions in the same suite for quite a while, I'm a bit
surprised this is coming up now. I seem to remember that Built-Using
isn't the only case where this can happen - library transitions can
too IIRC.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6fti5nwm550vybo0bsvv48geyw5vv2eavk1hjko3f7...@mail.gmail.com

Re: Grub 2.00 in testing?

[Cyril Brulebois]

(Adding -qa@ to the loop.)

Paul Wise  (2013-07-22):
> On Mon, Jul 22, 2013 at 10:03 AM, Cyril Brulebois wrote:
> 
> > rmadison now defaults to querying UDD by default
> 
> There is a projectb mirror accessible from qa.d.o, so we could rewire
> the madison CGI to look at that. It is written in Perl though so it is
> unlikely I'll ever be motivated to do that. Hopefully someone else
> will be willing to make it use projectb when appropriate...

With more than 24 hours a day, I would certainly like to do that… Not in
this life I'm afraid (at least not those weeks).

> > [UDD] is on crack in a bunch of cases.
> 
> Any info about these? Lucas and other UDD folks would probably want to
> fix the issues.

Possibly anything popping up in Built-Using. Random example:
kibi@arya:~$ \rmadison busybox -s stable,testing,unstable
 busybox | 1:1.20.0-7   | wheezy | source, amd64, armel, armhf, i386, ia64, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
 busybox | 1:1.20.0-7   | jessie | source
 busybox | 1:1.20.0-7   | sid| source
 busybox | 1:1.20.0-8.1 | jessie | source, amd64, armel, armhf, i386, ia64, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
 busybox | 1:1.20.0-8.1 | sid| source, amd64, armel, armhf, hurd-i386, 
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, 
sparc
kibi@arya:~$ rmadison busybox -s stable,testing,unstable
   busybox |1:1.20.0-7 | stable | source, amd64, armel, armhf, i386, 
ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
   busybox |  1:1.20.0-8.1 |testing | source, amd64, armel, armhf, i386, 
ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
   busybox |  1:1.20.0-8.1 |   unstable | source, amd64, armel, armhf, 
hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, 
s390, s390x, sparc

Or even worse:
kibi@arya:~$ \rmadison linux -s stable,testing,unstable
 linux | 3.2.32-1| jessie | source
 linux | 3.2.32-1| sid| source
 linux | 3.2.39-2| jessie | source
 linux | 3.2.39-2| sid| source
 linux | 3.2.41-2| wheezy | source
 linux | 3.2.41-2| jessie | source
 linux | 3.2.41-2| sid| source
 linux | 3.2.41-2+deb7u2 | wheezy | source
 linux | 3.2.41-2+deb7u2 | jessie | source
 linux | 3.2.41-2+deb7u2 | sid| source
 linux | 3.2.46-1| wheezy | source
 linux | 3.2.46-1| jessie | source
 linux | 3.2.46-1| sid| source
 linux | 3.9.6-1 | jessie | source
 linux | 3.9.6-1 | sid| source
 linux | 3.9.8-1 | jessie | source
 linux | 3.10.1-1| sid| source
kibi@arya:~$ rmadison linux -s stable,testing,unstable
 linux |  3.2.46-1 | stable | source
 linux |   3.9.8-1 |testing | source
 linux |  3.10.1-1 |   unstable | source

(rmadison is a shell alias to an ssh-based dak ls, \rmadison is the
plain command from devscripts with its default configuration.)

I've just noticed that #699268 is supposed to be fixed, but last I heard
about somebody from QA, that was during the last stages of the wheezy
release cycle, and while the issue was known back then, I think not
everyone agreed it was the right time to try and get that fixed (that
conversation probably happened on #debian-release if memory serves,
which I doubt).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Grub 2.00 in testing?

[Paul Wise]

On Mon, Jul 22, 2013 at 10:03 AM, Cyril Brulebois wrote:

> rmadison now defaults to querying UDD by default

There is a projectb mirror accessible from qa.d.o, so we could rewire
the madison CGI to look at that. It is written in Perl though so it is
unlikely I'll ever be motivated to do that. Hopefully someone else
will be willing to make it use projectb when appropriate...

> [UDD] is on crack in a bunch of cases.

Any info about these? Lucas and other UDD folks would probably want to
fix the issues.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6HLmaBfrXrRCyUD=fNU4DCvUtmber13tEWwjsaTnb=_...@mail.gmail.com

Re: projectb mirror (was: Re: Grub 2.00 in testing?)

[Ondřej Surý]

On Mon, Jul 22, 2013 at 1:53 PM, Ansgar Burchardt  wrote:
>
> Hi,
>
> On 07/22/2013 12:57, Ondřej Surý wrote:
> > dak on coccia.d.o is not in the best shape (yet):
> >
> > $ dak rm -nR ruby-activesupport-2.3
> [...]
> > daklib.dak_exceptions.CantOpenError:
> > /srv/
ftp-master.debian.org/ftp//pool/main//r/ruby-activesupport-2.3/ruby-activesupport-2.3_2.3.14-7_all.deb
>
> Changes to the projectb database are visible almost immediately through
> replication, however the ftp/ directory is only updated when mirrors are
> pushed. So there might be errors when trying to access recently
> installed files.


What is recently? Mentioned package migrated to testing in March.

And there's no ftp/ directory under /srv/ftp-master.debian.org/:

ondrej@coccia:~$ cd /srv/ftp-master.debian.org/
ondrej@coccia:/srv/ftp-master.debian.org$ ls
apache.conf  apache.conf.old  backup  bin  dak  database  export  incoming
 log  mail  misc  new  policy  queue  relscan  scripts  text  tiffani
ondrej@coccia:/srv/ftp-master.debian.org$ cd ftp
-bash: cd: ftp: No such file or directory

> Ideally the dependency check "dak rm -nR" does would no longer access
> any files. All information should be available in the database, however
> nobody had time to adapt the reverse dependency check to use it so far.
>
> We were also considering to make the projectb copy accessible from
> Alioth (if DSA and Alioth admins agree), however I'm not sure how useful
> it is without access to the mirror tree. "dak ls" would work, but as
> mentioned above "dak rm -nR" wouldn't be too useful yet.
>
> Ansgar
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive: http://lists.debian.org/51ed1d48.1000...@debian.org
>



--
Ondřej Surý 

projectb mirror (was: Re: Grub 2.00 in testing?)

[Ansgar Burchardt]

Hi,

On 07/22/2013 12:57, Ondřej Surý wrote:
> dak on coccia.d.o is not in the best shape (yet):
> 
> $ dak rm -nR ruby-activesupport-2.3
[...]
> daklib.dak_exceptions.CantOpenError:
> /srv/ftp-master.debian.org/ftp//pool/main//r/ruby-activesupport-2.3/ruby-activesupport-2.3_2.3.14-7_all.deb

Changes to the projectb database are visible almost immediately through
replication, however the ftp/ directory is only updated when mirrors are
pushed. So there might be errors when trying to access recently
installed files.

Ideally the dependency check "dak rm -nR" does would no longer access
any files. All information should be available in the database, however
nobody had time to adapt the reverse dependency check to use it so far.

We were also considering to make the projectb copy accessible from
Alioth (if DSA and Alioth admins agree), however I'm not sure how useful
it is without access to the mirror tree. "dak ls" would work, but as
mentioned above "dak rm -nR" wouldn't be too useful yet.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ed1d48.1000...@debian.org

Re: Grub 2.00 in testing?

[Ondřej Surý]

Hmm,

dak on coccia.d.o is not in the best shape (yet):

$ dak rm -nR ruby-activesupport-2.3
Working...W: couldn't open '/srv/
ftp-master.debian.org/ftp//pool/main//r/ruby-activesupport-2.3/ruby-activesupport-2.3_2.3.14-7.dsc
'.

Traceback (most recent call last):
  File "/usr/local/bin/dak", line 239, in 
main()
  File "/usr/local/bin/dak", line 219, in main
module.main()
  File "/srv/ftp-master.debian.org/dak/dak/rm.py", line 295, in main
control =
apt_pkg.TagSection(utils.deb_extract_control(utils.open_file(filename)))
  File "/srv/ftp-master.debian.org/dak/dak/daklib/utils.py", line 124, in
open_file
raise CantOpenError(filename)
daklib.dak_exceptions.CantOpenError: /srv/
ftp-master.debian.org/ftp//pool/main//r/ruby-activesupport-2.3/ruby-activesupport-2.3_2.3.14-7_all.deb

O.
P.S.: Previous email on ries down was sent to d-d-a, it would be nice to
announce the replacement of ries by coccia there as well.



On Mon, Jul 22, 2013 at 11:02 AM, Cyril Brulebois  wrote:

> Andrey Rahmatullin  (2013-07-22):
> > On Mon, Jul 22, 2013 at 10:03:48AM +0200, Cyril Brulebois wrote:
> > > Trust dak instead:
> > > | kibi@arya:~$ ssh release.debian.org dak ls grub2 -s testing
> > Permission denied (publickey).
>
> For those having missed [1,2], how much time exactly does one need
> to find coccia.d.o on machines.cgi[3]?
>
>  1.
> http://lists.debian.org/debian-infrastructure-announce/2013/07/msg0.html
>  2. http://lists.debian.org/debian-project/2013/07/msg6.html
>  3. http://db.debian.org/machines.cgi
>
> KiBi.
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20130722090210.ga29...@mraw.org
>
>


-- 
Ondřej Surý 

Re: Grub 2.00 in testing?

[Andrey Rahmatullin]

On Mon, Jul 22, 2013 at 11:02:10AM +0200, Cyril Brulebois wrote:
> > > Trust dak instead:
> > > | kibi@arya:~$ ssh release.debian.org dak ls grub2 -s testing
> > Permission denied (publickey).
> 
> For those having missed [1,2], how much time exactly does one need
> to find coccia.d.o on machines.cgi[3]?
> 
>  1. 
> http://lists.debian.org/debian-infrastructure-announce/2013/07/msg0.html
>  2. http://lists.debian.org/debian-project/2013/07/msg6.html
>  3. http://db.debian.org/machines.cgi
coccia.d.o doesn't allow non-DDs either.

-- 
WBR, wRAR


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130722100454.ga31...@belkar.wrar.name

Re: Grub 2.00 in testing?

[Cyril Brulebois]

Andrey Rahmatullin  (2013-07-22):
> On Mon, Jul 22, 2013 at 10:03:48AM +0200, Cyril Brulebois wrote:
> > Trust dak instead:
> > | kibi@arya:~$ ssh release.debian.org dak ls grub2 -s testing
> Permission denied (publickey).

For those having missed [1,2], how much time exactly does one need
to find coccia.d.o on machines.cgi[3]?

 1. http://lists.debian.org/debian-infrastructure-announce/2013/07/msg0.html
 2. http://lists.debian.org/debian-project/2013/07/msg6.html
 3. http://db.debian.org/machines.cgi

KiBi.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130722090210.ga29...@mraw.org

Re: Grub 2.00 in testing?

[Andrey Rahmatullin]

On Mon, Jul 22, 2013 at 10:03:48AM +0200, Cyril Brulebois wrote:
> Trust dak instead:
> | kibi@arya:~$ ssh release.debian.org dak ls grub2 -s testing
Permission denied (publickey).

-- 
WBR, wRAR


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130722081535.ga28...@belkar.wrar.name

Re: Grub 2.00 in testing?

[Cyril Brulebois]

Andrey Rahmatullin  (2013-07-22):
> On Mon, Jul 22, 2013 at 07:36:22AM +0100, Adam D. Barratt wrote:
> > The migration notification is in error; it's a bug in the script that
> > generates the notifications, that doesn't ignore extra entries included
> > in the Sources files added by the archive management software in order
> > to help with some license compliance. Now that we're aware of it, that
> > bug will be fixed.
> > 
> > As you mention checking the Sources files, I suspect you've made the
> > same (reasonable) mistake that the script is currently making - if the
> > stanza has "Extra-Source-Only: yes" then it is only there for compliance
> > and does not indicate that the package is in testing.
> See also e.g. rmadison:
> 
>  grub2 | 2.00-14   | jessie | source

rmadison now defaults to querying UDD by default, which is on crack in a
bunch of cases.

Trust dak instead:
| kibi@arya:~$ ssh release.debian.org dak ls grub2 -s testing
| W: Archive maintenance is in progress; database inconsistencies are possible.
|  grub2 | 1.99-27+deb7u1 |testing | source, amd64, i386, 
kfreebsd-amd64, kfreebsd-i386, powerpc, sparc

(The warning is here because we're during dinstall.)

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130722080348.ga30...@mraw.org

Re: Grub 2.00 in testing?

[Andrey Rahmatullin]

On Mon, Jul 22, 2013 at 07:36:22AM +0100, Adam D. Barratt wrote:
> The migration notification is in error; it's a bug in the script that
> generates the notifications, that doesn't ignore extra entries included
> in the Sources files added by the archive management software in order
> to help with some license compliance. Now that we're aware of it, that
> bug will be fixed.
> 
> As you mention checking the Sources files, I suspect you've made the
> same (reasonable) mistake that the script is currently making - if the
> stanza has "Extra-Source-Only: yes" then it is only there for compliance
> and does not indicate that the package is in testing.
See also e.g. rmadison:

 grub2 | 2.00-14   | jessie | source

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130722064216.ga24...@belkar.wrar.name

Re: Grub 2.00 in testing?

[Adam D. Barratt]

On Sun, 2013-07-21 at 20:42 -0700, Carl Johnson wrote:
> Does anybody know what is going on with grub in testing?  I have been
> waiting for 2.00, but it seems to be stuck at 1.99.  Grub-common at
> http://packages.debian.org/jessie/grub-common shows that it is at
> 1.99-27+deb7u1, but the source files show 2.00-14.  The qa page at
> http://packages.qa.debian.org/g/grub2.html shows that 2.00-14 was
> migrated to testing on 2013-06-14, so there appear to be some
> inconsistancies.

The migration notification is in error; it's a bug in the script that
generates the notifications, that doesn't ignore extra entries included
in the Sources files added by the archive management software in order
to help with some license compliance. Now that we're aware of it, that
bug will be fixed.

As you mention checking the Sources files, I suspect you've made the
same (reasonable) mistake that the script is currently making - if the
stanza has "Extra-Source-Only: yes" then it is only there for compliance
and does not indicate that the package is in testing.

Apologies for the confusion; grub2 2.00 has indeed not yet made it to
testing.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1374474982.5881.49.ca...@jacala.jungle.funky-badger.org

Re: Grub 2.00 in testing?

[Andreas Metzler]

On 2013-07-22 Carl Johnson  wrote:
> Does anybody know what is going on with grub in testing?  I have been
> waiting for 2.00, but it seems to be stuck at 1.99.  Grub-common at
> http://packages.debian.org/jessie/grub-common shows that it is at
> 1.99-27+deb7u1, but the source files show 2.00-14.  The qa page at
> http://packages.qa.debian.org/g/grub2.html shows that 2.00-14 was
> migrated to testing on 2013-06-14, so there appear to be some
> inconsistancies.
[...]

Hello,

FYI I think your analysis is correct, I cannot find anything obvious.

I guess some manual intervention happened.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130722062315.ga3...@downhill.g.la

Grub 2.00 in testing?

[Carl Johnson]

Does anybody know what is going on with grub in testing?  I have been
waiting for 2.00, but it seems to be stuck at 1.99.  Grub-common at
http://packages.debian.org/jessie/grub-common shows that it is at
1.99-27+deb7u1, but the source files show 2.00-14.  The qa page at
http://packages.qa.debian.org/g/grub2.html shows that 2.00-14 was
migrated to testing on 2013-06-14, so there appear to be some
inconsistancies.

I am not subscribed, so I would appreciate a cc, although I will monitor
the web interface.  I asked this on debian-user, but there were no
answers there.

Thanks.
-- 
Carl Johnsonca...@peak.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871u6r5kg1.fsf@oak.localnet

ITP: grub-loopback-iso -- Boot a compatible loopback ISO from GRUB 2

[Ryan Finnie]

retitle 693774 ITP: grub-loopback-iso -- Boot a compatible loopback
 ISO from GRUB 2
kthxbye

(Please excuse the perfect storm of bugs + multiple lists.)

As it turns out, grml invented a generic way of allowing it to be booted
as an ISO from GRUB 2, with a file in the ISO called
/boot/grub/loopback.cfg.  Other distros/utilities, including Super Grub2
Disk and Ubuntu have adopted this, and Finnix will as well, as of the
forthcoming 108 release.

In that light, I have rewritten grub-finnix as grub-loopback-iso, which
is an update-grub2 hook which scans a directory of ISOs an looks for
/boot/grub/loopback.cfg within them, and will build grub.cfg stanzas
which chain that file.  The method is similar to how Super Grub2 Disk
works, and will support any distro ISO which ships a
/boot/grub/loopback.cfg file.

Package: grub-loopback-iso
Architecture: i386 amd64
Depends: ${shlibs:Depends}, ${misc:Depends}, grub-pc (>= 1.99-1)
Description: Boot a compatible loopback ISO from GRUB 2
 grub-loopback-iso is a GRUB 2 configuration hook to boot compatible
 ISOs stored on the host filesystem. The stanzas built utilize GRUB
 2's loopback mount support to chain a /boot/grub/loopback.cfg file on
 an ISO.

The source archive URL has therefore (once again) been renamed to:
https://code.launchpad.net/~finnix/finnix/grub-loopback-iso-pkg

(loopback.cfg would also be a nice feature for d-i ISOs to ship, as well
as any other derivatives (or any distro at all) which supports the
findiso= or iso-scan/filename= feature.)

RF



signature.asc
Description: OpenPGP digital signature

Re: wheezy update-grub error

[Oleg]

On Tue, Jan 29, 2013 at 04:13:14PM +, Colin Watson wrote:
> On Tue, Jan 29, 2013 at 11:50:29AM +0400, Oleg wrote:
> > ~# update-grub 
> > Searching for GRUB installation directory ... found: /boot/grub
> > Searching for default file ... Generating /boot/grub/default file and 
> > setting the default boot entry to 0
> > entry not specified.
> > Usage: grub-set-default [OPTION] entry
> > Set the default boot entry for GRUB.
> > 
> >   -h, --help  print this message and exit
> >   -v, --version   print the version information and exit
> >   --root-directory=DIRUse the directory DIR instead of the root 
> > directory
> > 
> > ENTRY is a number or the special keyword `default\'.
> > 
> > Report bugs to .
> > 
> >   Is this a bug? Or i do anything wrong?
> 
> Thanks for your report.  This is bug #560417, and was broken in 0.97-59.
> It's IMO clear from the diff that it was unintentional to use $1 here
> rather than 0:
>
> ...
>
> I'll fix this.

  Thank you!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130129184335.GB14159@localhost

Re: wheezy update-grub error

[Colin Watson]

On Tue, Jan 29, 2013 at 11:50:29AM +0400, Oleg wrote:
> ~# update-grub 
> Searching for GRUB installation directory ... found: /boot/grub
> Searching for default file ... Generating /boot/grub/default file and setting 
> the default boot entry to 0
> entry not specified.
> Usage: grub-set-default [OPTION] entry
> Set the default boot entry for GRUB.
> 
>   -h, --help  print this message and exit
>   -v, --version   print the version information and exit
>   --root-directory=DIRUse the directory DIR instead of the root directory
> 
> ENTRY is a number or the special keyword `default\'.
> 
> Report bugs to .
> 
>   Is this a bug? Or i do anything wrong?

Thanks for your report.  This is bug #560417, and was broken in 0.97-59.
It's IMO clear from the diff that it was unintentional to use $1 here
rather than 0:

=== modified file 'debian/changelog'
--- debian/changelog2009-09-04 13:20:44 +0000
+++ debian/changelog2009-09-04 14:41:35 +
@@ -1,3 +1,10 @@
+grub (0.97-59) unstable; urgency=low
+
+  * Use /usr/lib/grub-legacy/grub-set-default if it exists in update-
+grub, in preparation for grub2's grub-set-default.
+
+ -- Felix Zielcke   Fri, 04 Sep 2009 16:41:22 +0200
+
 grub (0.97-58) unstable; urgency=low
 
   * Upgrade path is now GRUB 2.

=== modified file 'debian/update-grub'
--- debian/update-grub  2009-08-12 22:07:07 +
+++ debian/update-grub  2009-09-04 14:41:35 +
@@ -327,7 +327,11 @@ if [ -f "$default_file" ] ; then
   echo "found: $default_file" >&2
 else
   echo "Generating $default_file file and setting the default boot entry to 0" 
>&2
-  grub-set-default 0
+  if [ -f /usr/lib/grub-legacy/grub-set-default ] ; then
+/usr/lib/grub-legacy/grub-set-default $1
+  else
+grub-set-default $1
+  fi
 fi
 
 # Make sure we use the standard sorting order
@@ -1022,7 +1026,11 @@ fi
 # Function to update the default value
 set_default_value() {
 if [ "$use_grub_set_default" = "true" ] ; then
-   grub-set-default $1
+   if [ -f /usr/lib/grub-legacy/grub-set-default ] ; then
+   /usr/lib/grub-legacy/grub-set-default $1
+   else
+   grub-set-default $1
+   fi
 else
value="$1"
newmenu=$(tempfile)

I'll fix this.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130129161314.ga24...@riva.dynamic.greenend.org.uk

wheezy update-grub error

[Oleg]

  Hello.

  I have the next error:

~# update-grub 
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... Generating /boot/grub/default file and setting 
the default boot entry to 0
entry not specified.
Usage: grub-set-default [OPTION] entry
Set the default boot entry for GRUB.

  -h, --help  print this message and exit
  -v, --version   print the version information and exit
  --root-directory=DIRUse the directory DIR instead of the root directory

ENTRY is a number or the special keyword `default\'.

Report bugs to .

  Is this a bug? Or i do anything wrong?

  Thanks.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130129075029.GA28079@localhost

Re: Bug#693774: ITP: grub-finnix -- Build a Finnix bootloader stanza on GRUB 2 systems

[Ryan Finnie]

On 11/20/2012 01:21 AM, Marco d'Itri wrote:
>>   Description : Build a Finnix bootloader stanza on GRUB 2 systems
> I think that you should add one or two lines to explain what Finnix is.
> At least, the word "rescue" would help a lot...

Good idea; looking back, I was writing the description from the view as
a distribution developer, not an end user.  How about:

Description: Boot a Finnix rescue/maintenance ISO from GRUB 2
 grub-finnix is a GRUB 2 configuration hook to boot compatible versions
 of Finnix, a Debian-based rescue and maintenance LiveCD distribution,
 from ISOs stored on the host filesystem. The stanzas built utilize GRUB
 2's loopback mount support to boot a Finnix kernel and initrd, and
 passes the location of the ISO to Finnix.  Finnix's first-stage initrd
 then searches for the partition containing the specified ISO.

>>  Note that there are certain restrictions regarding where the ISO may be 
>>  placed.  Please see README.Debian for installation instructions and 
>>  restrictions.
> Does this really have to be in the package description?
> I think that we can assume the "you should read README.Debian for more 
> information" part for all packages...

True, but that was more to guide the user, given the fact that the
package does absolutely nothing without user configuration.  Perhaps in
postinst I can read in /etc/default/grub-finnix, check if FINNIX_ISO is
set, and if not, mention that it must be configured from
/etc/default/grub-finnix.  The default file itself currently contains
some basic instructions and a mention of README.Debian for more detailed
information.  Suggestions?

RF



signature.asc
Description: OpenPGP digital signature

Re: Bug#693774: ITP: grub-finnix -- Build a Finnix bootloader stanza on GRUB 2 systems

[Marco d'Itri]

On Nov 20, Ryan Finnie  wrote:

>   Description : Build a Finnix bootloader stanza on GRUB 2 systems
I think that you should add one or two lines to explain what Finnix is.
At least, the word "rescue" would help a lot...

>  Note that there are certain restrictions regarding where the ISO may be 
>  placed.  Please see README.Debian for installation instructions and 
>  restrictions.
Does this really have to be in the package description?
I think that we can assume the "you should read README.Debian for more 
information" part for all packages...

> I talked about this briefly with Paul Wise, and while there are several 
> existing packages which do similar GRUB loaders for other projects 
Hopefully the wide availability of well integrated rescue systems will 
make happy the few people who complain that in the future the root file 
system is going to be less and less useful as a rescue system.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#693774: ITP: grub-finnix -- Build a Finnix bootloader stanza on GRUB 2 systems

[Ryan Finnie]

Package: wnpp
Severity: wishlist
Owner: Ryan Finnie 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: grub-finnix
  Version : 107
  Upstream Author : N/A, native package
* URL : N/A, native package
* License : GPL
  Programming Lang: Shell (dash-compatible /etc/grub.d hook)
  Description : Build a Finnix bootloader stanza on GRUB 2 systems

Extended description:
 grub-finnix is a GRUB2 configuration hook to boot Finnix, given a 
 compatible ISO.  The stanzas built utilize GRUB 2's loopback mount 
 support to boot a Finnix kernel and initrd, and passes the location of 
 the ISO to Finnix.  Finnix's first-stage initrd then searches for the 
 partition containing the specified ISO.
 .
 Note that there are certain restrictions regarding where the ISO may be 
 placed.  Please see README.Debian for installation instructions and 
 restrictions.

I talked about this briefly with Paul Wise, and while there are several 
existing packages which do similar GRUB loaders for other projects 
(grub-rescue-pc, grml-rescueboot), they are incredibly specialized to 
the target project.  It may be possible to abstract this sort of 
function into a shared package, but IMHO the shared code between them 
would be very small, and discrete packages for each targeted project 
would be better for maintenance.

The code is currently being developed at:
https://code.launchpad.net/~finnix/finnix/grub-finnix-pkg-debian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQqzdpAAoJEH5go6aGro2YV6cQAJOZaaPGxhjVOnNBRoHnm0IF
xJK6Y/HNEaa8rTaDYhlNHm7HRf0gXq6tjS0wvQ8GM2ZjRzScWSqm6j0RbIElEw8J
tBSVBsigkOWva8C+QY3zYIjAQo47vEe/pak0wVab7iO1nY0VB/BehqhWDoDM9Fvt
hy1oi1lVaRTbFEYZFfFvoyFCA610xPkdR4SFepOc3qXYuZPWK/cV24XxQ4c38sNy
LyAU2ykdutQL9IlJgikrI9ctN3ql1OrDn7xRr5c/Ps7E1c4NmmdwWaRJOnCe7o8e
d1DjA9L/LkkkEp/mdMFaFrfk0G30tEA2IFyoYTc5H8eGLRjWWCatT2Q8i60jB3G3
mRLV+BN4yZN8JQUesq9QI1/Lnreil6gYg6SR/E73dEF/MHKvTtwRscCfKgzIXYO7
U0BTtucsaUA1Nd/MPa4BUhhNLMC9mPx8PeCU2z2laY2rf1wkMQCvVMQAnIYOpxfp
SGFFthhMc75JiSgiCsp0NWkI2qa6ZX2x9/gLGFOPsNjMQQKpJhzrxt4HwTXgtb1m
jKcOJyNcgV2sUwMvK5Oy8QCnMM5LVgkvLNFvEfCPclToNRiKFd2Yv4qKyQPesO4B
igjTXpgucdhqMd5kqwhqqJPQ7YFOaitf8EdztuepK00pp2v3JZ/QWbLoyxYYX9Ra
7OHzoWXXtquwTGm8ZOLH
=0FAP
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121120075523.25161.82358.report...@sid.snowman.lan

ITP: pv-grub-menu.lst

[Charles Plessy]

reassign 672104 wnpp
retitle 672104 ITP: pv-grub-menu.lst

Dear all,

Some systems booted by PV-Grub need a menu.lst file like the one created by
grub1, but without GRUB itself on the MBR.  Such systems include computer cloud
systems like Amazon's Elastic Computer Cloud.  Some methods to create such
systems do not fit well with installing the grub-legacy package, as there may
be no MBR available.
 
In Ubuntu, there is a binary package, called grub-legacy-ec2, that provides
kernel hooks and and update script to maintain the menu.lst file when kernels
are changed.  This package is part of the cloud-init source package, but is
unrelated to the upstream cloud-init source.  In Debian, cloud-init will be
maintained in the Python Applications Packaging Team, and grub-legacy-ec2 does
not fit well there, as it is not a python application.

After discussion with the Ubuntu maintainer of the cloud-init package, our plan
is to provide the functions of grub-legacy-ec2 in a separate source package.  I
send this ITP with a more generic name that I feel is more descriptive, unless
it is only useful on the Amazon EC2.  But I am open to keep the original name
if it helps.

People interested in co-maintaining this package, we welcome you.

Currently my plan is to set up a Git repository on collab-maint, with the
grub-legacy-ec2 part of Ubuntu's cloud-init source package as a starting point.
GRUB Maintainers, I would be happy to place the package under your umbrella if
you are intersted.  I would like to interface well with grub2, perhaps through
depending on grub2-common if possible, in order to be co-installable with
grub-pc without diversions.

For those who wonder why this ITP is not about bioinformatics, this is part of
my long-standing goal of developping a fully debian-contained, preseedable, and
unattended procedure to prepare Debian Med images for computer clouds.

(see 
http://charles.plessy.org/Debian/debiâneries/installeur-debian-dans-un-nuage/ ) 

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120509234133.ga12...@plessy.org

#howmany for grub 2

[linbloke]

Whilst preparing grub 2 for release, could you please look at 
re-implementing the #howmany configuration option that was included in 
grub1. Here is a link to an IMHO excellent blog on how to implement the 
function:


http://www.linuxquestions.org/questions/blog/drask-180603/howmany-for-grub-2-2466/


Kind regards and thanks to all debian devs,
Josh


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c0daabe.6070...@fastmail.fm

Re: Re: For the grub maintainers II

[Mike Hommey]

On Tue, Sep 08, 2009 at 05:35:06PM +0200, Gabor Gombas wrote:
> On Tue, Sep 08, 2009 at 04:35:42PM +0200, Fabian Greffrath wrote:
> 
> > With the namespace issue fixed and a blacklist to avoid mounting
> > partitions in a virtualization environment, would it make sense to
> > make grub-pc recommend (or even depend on) os-prober again?
> 
> The problem is not just virtualization but also exporting the block
> device over the network. E.g. vblade does not open the device with
> O_EXCL, so it is possible to mount it locally while some remote client
> also have it mounted, resulting in data corruption.

I think the best thing to do would be to use some kind of COW scheme
on the device before mounting it. Setting up a device mapper snapshot,
backed by a sparse file in a tmpfs is probably a good though hackish
solution. I can give some help if needed.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: For the grub maintainers II

[Gabor Gombas]

On Tue, Sep 08, 2009 at 04:35:42PM +0200, Fabian Greffrath wrote:

> With the namespace issue fixed and a blacklist to avoid mounting
> partitions in a virtualization environment, would it make sense to
> make grub-pc recommend (or even depend on) os-prober again?

The problem is not just virtualization but also exporting the block
device over the network. E.g. vblade does not open the device with
O_EXCL, so it is possible to mount it locally while some remote client
also have it mounted, resulting in data corruption.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: For the grub maintainers II

[Fabian Greffrath]

There's already a report open on os-prober to make it really read-only
#417407
IIRC Colin Watson already thought in an Ubuntu bug report about
implementing a blacklist for os-prober.


With the namespace issue fixed and a blacklist to avoid mounting 
partitions in a virtualization environment, would it make sense to 
make grub-pc recommend (or even depend on) os-prober again?



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re: For the grub maintainers II

[Felix Zielcke]

Am Dienstag, den 08.09.2009, 16:35 +0200 schrieb Fabian Greffrath:
> > There's already a report open on os-prober to make it really read-only
> > #417407
> > IIRC Colin Watson already thought in an Ubuntu bug report about
> > implementing a blacklist for os-prober.
> 
> With the namespace issue fixed and a blacklist to avoid mounting 
> partitions in a virtualization environment, would it make sense to 
> make grub-pc recommend (or even depend on) os-prober again?
> 

Directly after Colin uploaded the new os-prober I changed it back again
to Recommends in our SVN.

-- 
Felix Zielcke
Proud Debian Maintainer


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: For the grub maintainers II

[Felix Zielcke]

Am Montag, den 07.09.2009, 13:30 +0200 schrieb Vincent Danjean:
> Gabor Gombas wrote:
> > On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
> > 
> >> Robert filed already after the upload of grub-legacy a RC bug so it
> >> doestn't migrate after the usual 10 days to testing.
> >>
> >> Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
> >> does because of 491872
> >> So if anyone want to help that we Recommend it again, then help the
> >> os-prober maintainers to fix that bug.
> > 
> > I don't know the specifics, but wouldn't it be possible for os-prober to
> > create its own private mount name space (see clone(2), CLONE_NEWNS),
> > and do the probing inside that name space? That way the desktop
> > environments would not be able to intercept it.
> 
> Please, take care with auto mounting of most partitions:
> some of my serveur are Xen or kvm host. And some of their partitions
> (mostly LVs) are used by running guest. These partitions MUST NOT be
> mounted on the host. I even change /etc/lvm/lvm.conf so that PV
> for guests are not detected (and activated) on the host.
> 

There's already a report open on os-prober to make it really read-only
#417407
IIRC Colin Watson already thought in an Ubuntu bug report about
implementing a blacklist for os-prober.

-- 
Felix Zielcke
Proud Debian Maintainer


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: For the grub maintainers II

[Mike Hommey]

On Mon, Sep 07, 2009 at 09:53:30AM +0100, Colin Watson wrote:
> On Sat, Sep 05, 2009 at 08:32:02PM +0200, Gabor Gombas wrote:
> > On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
> > > Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
> > > does because of 491872
> > > So if anyone want to help that we Recommend it again, then help the
> > > os-prober maintainers to fix that bug.
> > 
> > I don't know the specifics, but wouldn't it be possible for os-prober to
> > create its own private mount name space (see clone(2), CLONE_NEWNS),
> > and do the probing inside that name space? That way the desktop
> > environments would not be able to intercept it.
> 
> Excellent idea, thanks; I'm looking into doing this now.

FYI, using unshare(2) is easier than clone(2) for this purpose.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: For the grub maintainers II

[Vincent Danjean]

Gabor Gombas wrote:
> On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
> 
>> Robert filed already after the upload of grub-legacy a RC bug so it
>> doestn't migrate after the usual 10 days to testing.
>>
>> Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
>> does because of 491872
>> So if anyone want to help that we Recommend it again, then help the
>> os-prober maintainers to fix that bug.
> 
> I don't know the specifics, but wouldn't it be possible for os-prober to
> create its own private mount name space (see clone(2), CLONE_NEWNS),
> and do the probing inside that name space? That way the desktop
> environments would not be able to intercept it.

Please, take care with auto mounting of most partitions:
some of my serveur are Xen or kvm host. And some of their partitions
(mostly LVs) are used by running guest. These partitions MUST NOT be
mounted on the host. I even change /etc/lvm/lvm.conf so that PV
for guests are not detected (and activated) on the host.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org