idea. The current format
> > https://salsa.debian.org/lintian/lintian/-/blob/master/data/fields/obsolete-packages
> > isn't super machine-readable. Perhaps it could be split into one file
> > with human-readable hints, and one with straightforward replacements
> > (e.g.
ages
> isn't super machine-readable. Perhaps it could be split into one file
> with human-readable hints, and one with straightforward replacements
> (e.g. "libtinfo-dev => libncurses-dev" )?
Related, current lintian-brush actually adds lsb-base back if it was remo
On Sat, Jan 21, 2023 at 12:53:17PM -0800, Otto Kekäläinen wrote:
> On Wed, 18 Jan 2023 at 09:00, Andreas Metzler wrote:
> >
> > On 2023-01-18 Otto Kekäläinen wrote:
> > > Lintian just started erroring on 'depends-on-obsolete-package
> > > lsb-base' on
Hi!
On Wed, 18 Jan 2023 at 09:00, Andreas Metzler wrote:
>
> On 2023-01-18 Otto Kekäläinen wrote:
> > Lintian just started erroring on 'depends-on-obsolete-package
> > lsb-base' on many of my packages yesterday. There are no new uploads
> [...]
> >
On Fri, 20 Jan 2023 at 15:52:34 +0100, Marco d'Itri wrote:
> I think that it is time to upgrade the warning, because I understand
> that interest in continuing to maintain systemd-sysv-generator is
> waning.
>
> I will be happy to assist maintainers who want to add a .service unit to
> their pa
(albeit quite a common one); so hopefully if maintainers
> > are removing lsb-base dependencies as prompted by Lintian, they are also
> > adding a corresponding /lib/systemd/system/foo.service for each
> > /etc/init.d/foo in the package.
> I think that it is time to upgrade
On Jan 20, Simon McVittie wrote:
> For the systemd-sysv-generator case, the LSB init script is only run if
> there is no native systemd unit of the same name, which itself triggers
> a Lintian warning (albeit quite a common one); so hopefully if maintainers
> are removing lsb-base
On Fri, 20 Jan 2023 at 12:15:31 +0100, Guillem Jover wrote:
> I don't think it is redundant though? Just removing the lsb-base
> Depends can break packages on partial upgrades in the same way lsb-base
> broke stuff before it grew a versioned dependency on sysvinit-utils.
Yes,
On Wed, 2023-01-18 at 18:23:16 +0100, Adam Borowski wrote:
> On Wed, Jan 18, 2023 at 08:19:15AM -0800, Otto Kekäläinen wrote:
> > Lintian just started erroring on 'depends-on-obsolete-package
> > lsb-base' on many of my packages yesterday.
>
> It's a very
Adam Borowski writes:
> On Wed, Jan 18, 2023 at 08:19:15AM -0800, Otto Kekäläinen wrote:
>> Does somebody know what is going on?
>>
>> Example:
>> E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>= 3.0-10)
> The severity of this warning is gro
On Wed, Jan 18, 2023 at 08:19:15AM -0800, Otto Kekäläinen wrote:
> Lintian just started erroring on 'depends-on-obsolete-package
> lsb-base' on many of my packages yesterday.
It's a very low priority cleanup; the Depends is redundant but
harmless.
> There are no new uplo
On 2023-01-18 Otto Kekäläinen wrote:
> Lintian just started erroring on 'depends-on-obsolete-package
> lsb-base' on many of my packages yesterday. There are no new uploads
[...]
> Does somebody know what is going on?
> Example:
> E: mariadb-server: depends-on-obsolete-
Hi!
Lintian just started erroring on 'depends-on-obsolete-package
lsb-base' on many of my packages yesterday. There are no new uploads
of lsb-base recently and I did not find any news about this topic. The
Lintian page https://lintian.debian.org/tags/depends-on-obsolete-package
is only
❦ 24 mars 2019 14:40 +01, Didier 'OdyX' Raboud :
>> Wouldn't it break chrooted processes? But mostly, as the whole pattern
>> is broken, it seems to be a low-effort solution.
>
> Vincent: what scenario did you have in mind?
For the first part, any daemon chrooting (like HAProxy, lldpd). For the
Le dimanche, 24 mars 2019, 09.42:12 h CET Geert Stappers a écrit :
> What would be the harm to the Buster release
> if lsb-base got NMU
> with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=ini
> t-functions.diff;msg=37 ?
I have now uploaded src:lsb to ex
Thanx in advance
> > >
> > > Harri
> > >
> > > https://bugs.debian.org/888569
> sysv startup script stumbles over smtpd running in a LXC container
>
> > > https://bugs.debian.org/888743
> pidofproc returns PIDs in foreign chroots and containers
&g
❦ 24 mars 2019 09:42 +01, Geert Stappers :
> What would be the harm to the Buster release
> if lsb-base got NMU
> with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=init-functions.diff;msg=37
> ?
Wouldn't it break chrooted processes? But
XC container
> > https://bugs.debian.org/888743
pidofproc returns PIDs in foreign chroots and containers
> > https://bugs.debian.org/858837
lsb-base: pidofproc should limit itself to processes in host system if running
on an LXC host
> > https://bugs.debian.org/924551
start
Hi -devel (and -lsb),
Le mercredi, 4 avril 2012 11.35:49, Didier 'OdyX' Raboud a écrit :
> I have recently uploaded lsb-base 4.1+Debian0+fancy0 to experimental. As
> this version introduces a small change that has a big visual impact on
> the Debian boot, I would like to get
On 04/04/2012 05:35 PM, Didier 'OdyX' Raboud wrote:
> Hi -devel (and -lsb),
>
> I have recently uploaded lsb-base 4.1+Debian0+fancy0 to experimental. As
> this version introduces a small change that has a big visual impact on
> the Debian boot, I would like to get s
On Mié 04 Abr 2012 06:35:49 Didier 'OdyX' Raboud escribió:
> Hi -devel (and -lsb),
>
> I have recently uploaded lsb-base 4.1+Debian0+fancy0 to experimental. As
> this version introduces a small change that has a big visual impact on
> the Debian boot, I would like t
Hi -devel (and -lsb),
I have recently uploaded lsb-base 4.1+Debian0+fancy0 to experimental. As
this version introduces a small change that has a big visual impact on
the Debian boot, I would like to get some feedback on it before
uploading it to unstable.
In short, this version implements a new
pe, 2008-08-29 kello 11:20 -0500, William Pitcock kirjoitti:
> This is DFSG-free, and meets both requirements.
Since I agree with William, I'm closing the bug. If Jari disagrees,
he'll let us know.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
Hi,
On Fri, 2008-08-29 at 18:30 +0300, root wrote:
> Package: lsb-base
> Version: 3.2-19
> Severity: serious
> Justification: Policy 2.1
>
>
> Please investigate if files included in lsb-base conform to DFSG. A lincense
> change to GPL would be better suited for Debian
Package: lsb-base
Version: 3.2-19
Severity: serious
Justification: Policy 2.1
Please investigate if files included in lsb-base conform to DFSG. A lincense
change to GPL would be better suited for Debian.
Policy / 2.1. The Debian Free Software Guidelines:
...
Derived Works
pe, 2008-08-29 kello 18:30 +0300, root kirjoitti:
> Please investigate if files included in lsb-base conform to DFSG. A lincense
> change to GPL would be better suited for Debian.
In what way do you think the lsb-base license does not conform to the
DFSG?
> Policy / 2.1. The Debian Free
Package: lsb-base
Version: 3.1-22
Severity: wishlist
Hi
Yesterday I saw a package which uses the shell functions provided by
lsb-base but did not have a dependency against it and I came across this
topic. Currently lsb-base is required and prodivdes the init script
functions which should be used
On Jul 22, Thomas Hood <[EMAIL PROTECTED]> wrote:
> I have a couple of initscripts that print progress messages and I do
> not want to be too hasty in eliminating them so I am thinking of
> doing the following for now:
Please don't. lsb-base is a tiny package, either use it or
print_warning_msg() { echo -n "$*" >&2 ; }
> print_begin_msg() { echo -n "$*" ; }
> print_progress_msg() { echo -n " $*" ; }
> print_end_msg_and_exit() { case "$1" in (0) echo "${2}." ;; (*) echo
> "
I have a couple of initscripts that print progress messages and I do
not want to be too hasty in eliminating them so I am thinking of
doing the following for now:
...
if [ -r /lib/lsb/init-functions ] ; then
. /lib/lsb/init-functions
print_warning_msg() { log_warning_msg "$*" ; }
On Tue, Jul 19, 2005 at 09:30:33AM +0200, Stig Sandbeck Mathisen wrote:
> Anyway, I like the pretty colours. It makes it very easy to see if
Colours aside, having the last six-or-so characters dedicated to a
PASS/FAIL style string makes summing up the boot process at a glance
much easier, and mak
* Stig Sandbeck Mathisen <[EMAIL PROTECTED]> [050719 09:30]:
> Anyway, I like the pretty colours. It makes it very easy to see if
> something is wrong during boot or service startup with just a glance.
That's one of the reasons I dislike colours. Having other peoples
system display fatal error me
The lsb functions currently only support this:
Doing something...[ ok ]
They don't support:
Doing something...doing something else... [ ok ]
or
Doing something...warning: no foo... [ ok ]
For this a log_progress_msg(
* Stig Sandbeck Mathisen ([EMAIL PROTECTED]) [050719 09:31]:
> Andreas Barth <[EMAIL PROTECTED]> writes:
> > It would be better if there would be some configureable option in
> > lsb-base.
> ,
> | Angry Fruit Salad?
> |
> | [yes] [no]
> `
configurati
Andreas Barth <[EMAIL PROTECTED]> writes:
> It would be better if there would be some configureable option in
> lsb-base.
,
| Angry Fruit Salad?
|
| [yes] [no]
`
Anyway, I like the pretty colours. It makes it very easy to see if
something is wrong during boot or service
* Marco d'Itri ([EMAIL PROTECTED]) [050718 20:17]:
> On Jul 18, "Bernhard R. Link" <[EMAIL PROTECTED]> wrote:
>
> > Is there a way to configure this to not create masses of processes and
> > confusing the user with colors?
> You can write your own pac
On Jul 18, "Bernhard R. Link" <[EMAIL PROTECTED]> wrote:
> Is there a way to configure this to not create masses of processes and
> confusing the user with colors?
You can write your own package which conflicts+provides lsb-base and
implements /lib/lsb/init-funct
* Marco d'Itri <[EMAIL PROTECTED]> [050717 18:50]:
> I am considering switching the init scripts of my packages to lsb-base
> (which means that it will have to be promoted to important priority, at
> least).
> If anybody has objections please voice them now.
Is there a w
On Jul 17, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> I already did this for discover1, but did this in a way to make it use
> lsb-base only if it is installed.
I can't see the point. The package is tiny, so if it should be used then
everybody should install it.
y to get colors in the boot screen, and
besides lsb-base is not a commonly installed package yet. I believe
it is a good idea to standardize the init.d message reporting, to make
it easier to redirect them to a common location, and believe using the
lsb-base functions is a step in the right d
On Sun, 17 Jul 2005 20:33:40 +0200, Petter Reinholdtsen wrote:
> I used this code to make lsb-base optional, and used the lsb functions
> for output:
>
> if [ -f /lib/lsb/init-functions ]; then
> . /lib/lsb/init-functions
> else
> log_begin_msg() { echo "$@
[Marco d'Itri]
> I am considering switching the init scripts of my packages to
> lsb-base (which means that it will have to be promoted to important
> priority, at least).
> If anybody has objections please voice them now.
I already did this for discover1, but did this in a way t
I am considering switching the init scripts of my packages to lsb-base
(which means that it will have to be promoted to important priority, at
least).
If anybody has objections please voice them now.
--
ciao,
Marco
signature.asc
Description: Digital signature
43 matches
Mail list logo
