On Sat, Oct 31, 2009 at 05:30:55PM +0100, Alexander Watzinger wrote:
> deborphan's keep file is located in /var/lib/deborphan. According to
> the Filesystem Hierarchy Standard, /var/lib/ is for persistent data
> modified by programs as they run, which isn't really the case for
> deborphan.
The han
Thanks for your bug report.
On Mon, Oct 05, 2009 at 09:25:30AM +0200, Vincenzo Tibullo wrote:
> I used deborphan whit the only option -P, to see the priority of
> packages it considers elegible to remove, and one of the packages was
> 'libusb-1.0-0', that was reported as 'important', but aptitude
Package: grub-imageboot
Severity: wishlist
Currently, there is only one google hit for „"rawimg" linux16"” (a copy
of grub-imageboot's extracted source code) and all documentation I was
able to find, including your blog entry, uses "raw" instead. Thus,
I assume the below quoted line is just a typ
Package: grub-imageboot
Severity: wishlist
If a user sets IMAGEOPTS to an empty string, grub-imageboot sets it to
the default value "rawimg". I think if a user decides to explicitly set
a configuration variable to any value, this decision should be
respected.
In my refactored grub-imageboot, fix
Package: grub-imageboot
Severity: wishlist
debian/control:
===
grub-imageboot is able to boot harddisk images (currently .img files
larger than 4 MB are detected as harddisk images). Please consider
mentioning this ability in the package's description.
| Description: boot iso and f
applied.
* Carsten Hey [2011-06-24 11:49 +0200]:
> Two ways to make grub-imageboot more configurable that come to my mind
> are:
> * read options for ${imagefile} from ${imagefile}.config if it exists
> * let the users add additional file name extensions with custom options
>
* Torbjörn Andersson [2011-05-09 06:18 +0200]:
> This bug report/RFP was closed by the most recent update to
> e2fsprogs. That has to have been by mistake, right? I haven't been
> able to find the proper way to report my concerns, so if I did it
> wrong I apologize, but I hope this is close enough.
* Russ Allbery [2011-05-10 09:41 -0700]:
> Roger Leigh writes:
>
> > Section 10.5 states:
>
> > In general, symbolic links within a top-level directory should be
> > relative, and symbolic links pointing from one top-level directory
> > into another should be absolute. (A top-level
* Russ Allbery [2011-05-10 15:32 -0700]:
> Carsten Hey writes:
>
> > Besides "/usr -> /", are symlinks to directories still supported as
> > top-level directories and are there still people using such a setup?
> > If nobody uses this anymore, the policy
* Carsten Hey [2011-05-11 01:06 +0200]:
> * Russ Allbery [2011-05-10 15:32 -0700]:
> > Carsten Hey writes:
> >
> > > Besides "/usr -> /", are symlinks to directories still supported as
> > > top-level directories and are there still people using s
* Thomas Goirand [2011-06-28 00:42 +0800]:
> On 06/27/2011 11:29 PM, Martin Zobel-Helas wrote:
> > --- nova_sudoers2011-06-27 17:26:14.0 +0200
> > +++ nova_sudoers.new2011-06-27 17:27:30.0 +0200
> > @@ -24,7 +24,7 @@
> >/sbin/vgcreate,
Package: developers-reference
Severity: wishlist
Recently a bug (#631830) was found that was caused by relocating
a binary from /usr/sbin to /sbin without adapting an other package that
uses an hardcoded path to this binary (in /etc/sudoers.d/).
As far as I know, a compatibility symlink would not
Hi,
thanks for adding bad-perm-for-file-in-etc-sudoers.d to lintian 2.5.1 :)
Given that bad permission for files in /etc/sudoers.d/ will break sudo,
I think this check is a good candidate for rejection by ftpmaster,
although this is rather unlikely to happen because dh_fixperms would
catch most c
* Carsten Hey [2011-06-27 22:36 +0200]:
> Package: developers-reference
> Severity: wishlist
>
> …
> the policy, for example, searching the archive for the binary name with
^^
This was a typo, 'developers-reference' is more appropriate for this.
--
To UNSUBSCR
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Filing as bug to help the release team to keep track of this request.
I'm full quoting the mail containing the URL of the repositories web
frontend and the debdiff between the e2fsprogs versions
* Reuben Thomas [2011-03-11 22:57 +]:
> It is possible for a package that has been automatically installed,
> and then marked as “keep” to be removed by apt-get autoremove. If
> editkeep made sure to mark packages that are selected as manually
> installed, this danger would be removed.
Thanks
401 - 416 of 416 matches
Mail list logo
